SW BBANG K

EC2 인스턴스를 새로 띄우고 나서 S3에 올려둔 설정 파일을 내려받으려는 순간, Unable to locate credentials 오류나 Access Denied 가 뜨면서 막히는 경험은 누구나 한 번쯤 겪는다. S3에서 EC2로 파일 복사 하는 작업은 명령어 자체는 단순하지만, IAM 인스턴스 프로파일이 제대로 붙어 있지 않으면 자격 증명 문제로 첫 단계부터 실패한다. TL;DR — 핵심 요약 항목 내용 복사 명령어 aws s3 cp s3://버킷명/경로/파일명 /로컬/경로/ 필수 IAM 액션 s3:GetObject (단일 파일), s3:ListBucket (경로 확인 시) 자격 증명 방식 EC2 인스턴스 프로파일 (IAM Role) — 권장 자격 증명 확인 aws sts get-caller-identity 가장 흔한 실패 원인 인스턴스 프로파일 미연결 또는 버킷 정책의 명시적 Deny 동작 원리: S3 파일 복사 흐름 aws s3 cp 는 내부적으로 S3 REST API의 GetObject 를 호출한다. EC2에서 이 호출이 성공하려면 두 가지 레이어가 모두 허용 상태여야 한다. 첫째는 IAM — 인스턴스에 연결된 Role이 해당 S3 액션을 허용해야 한다. 둘째는 S3 리소스 정책(버킷 정책) — 버킷 정책에 명시적 Deny가 있으면 IAM Allow를 덮어쓴다. sequenceDiagram participant CLI as AWS CLI (EC2 내부) participant IMDS as IMDS (169.254.169.254) participant STS as AWS STS participant S3 as Amazon S3 CLI->>IMDS: 임시 자격 증명 요청 IMDS->>STS: Role 기반 토큰 발...

EC2 인스턴스를 시작할 때 IAM Role 연결을 빠뜨리는 건 생각보다 자주 있는 실수다. 인스턴스가 이미 프로덕션 트래픽을 받고 있는 상황에서 재시작 없이 IAM Role을 붙일 수 있는지 확인하는 것이 급선무가 된다. 다행히 AWS는 실행 중인 EC2 인스턴스에 IAM Role을 연결하거나 교체하는 기능을 지원한다. TL;DR — IAM Role을 EC2에 연결하는 핵심 요약 상황 방법 재시작 필요 여부 IAM Role이 없는 인스턴스에 최초 연결 associate-iam-instance-profile 불필요 기존 IAM Role을 다른 Role로 교체 replace-iam-instance-profile-association 불필요 연결된 IAM Role 제거 disassociate-iam-instance-profile 불필요 IAM Role이 EC2에 연결되는 구조 이해 IAM Role을 EC2에 직접 붙이는 게 아니다. 중간에 Instance Profile 이라는 컨테이너가 존재한다. IAM Role을 생성하면 AWS 콘솔에서는 자동으로 동일한 이름의 Instance Profile이 함께 생성되지만, AWS CLI나 CloudFormation으로 Role을 만들면 Instance Profile은 별도로 생성해야 한다. EC2 인스턴스에 실제로 연결되는 것은 IAM Role이 아니라 Instance Profile이다. Instance Profile은 IAM Role을 EC2 인스턴스에 전달하는 봉투라고 생각하면 된다. 봉투(Instance Profile) 없이는 Role을 인스턴스에 넣을 수 없다. 인스턴스가 Role의 임시 자격증명을 얻는 경로는 EC2 메타데이터 서비스(IMDSv2)를 통해서다. 인스턴스 내부 애플리케이션이 http://169.254.169.254/latest/meta-data/...

Lambda 함수가 3초 만에 끊기는데 실제 작업은 10초가 필요한 상황 — 처음 마주치면 당황스럽지만, 원인은 단순하다. Lambda의 기본 타임아웃이 3초로 설정되어 있고, 이 값을 명시적으로 늘리지 않으면 함수는 작업 완료 여부와 무관하게 강제 종료된다. 이 글에서는 Lambda 타임아웃 설정 위치, 최대 한도, 그리고 단순히 값을 올리는 것 이상으로 놓치기 쉬운 실전 주의사항을 정리한다. TL;DR — Lambda 타임아웃 핵심 요약 항목 내용 기본 타임아웃 3초 최대 타임아웃 900초 (15분) 설정 단위 함수 단위 (버전/별칭별 독립 설정 불가) 타임아웃 측정 범위 전체 호출 시간 — 콜드 스타트 init 단계 포함 설정 방법 콘솔, AWS CLI, IaC (SAM/CDK/Terraform) 연동 서비스 타임아웃 API Gateway(29초), ALB(60초) 등 별도 제한 존재 Lambda 타임아웃이 동작하는 방식 Lambda 타임아웃은 함수 호출이 시작된 시점부터 카운트된다. 중요한 점은 타임아웃이 핸들러 실행 시간만이 아닌 전체 호출 시간에 적용된다 는 것이다. 콜드 스타트가 발생하면 런타임 초기화(init) 단계도 이 시간에 포함된다. 즉, init에 2초가 걸리고 핸들러 로직에 9초가 필요한 함수라면, 타임아웃을 10초로 설정해도 강제 종료될 수 있다. 타임아웃이 초과되면 Lambda는 Task timed out after X.XX seconds 메시지와 함께 호출을 종료하고, 호출자에게 오류를 반환한다. 함수 내부에서 try/catch로 잡을 수 없다 — 런타임 레벨에서 강제 중단되기 때문이다. graph TD A["Lambda 호출 시작 타임아웃 카운터 시작"] --> B{"콜드 스타트?"}; B ...

EC2 인스턴스를 중지(Stop)했는데 다음 날 청구서를 확인하니 Elastic IP 요금이 그대로 붙어 있다. 인스턴스를 껐으니 당연히 IP도 멈출 거라 생각했지만, AWS는 그렇게 동작하지 않는다. Elastic IP 요금 청구 구조를 정확히 이해하지 못하면 아무것도 실행되지 않는 인스턴스에 매달 예상치 못한 비용이 쌓인다. TL;DR — Elastic IP 요금 청구 핵심 정리 상태 요금 발생 여부 이유 실행 중 인스턴스에 연결됨 ❌ 무료 정상 사용 중 중지된 인스턴스에 연결됨 ✅ 요금 발생 IP가 유휴 상태로 낭비됨 어떤 인스턴스에도 연결 안 됨 (미연결) ✅ 요금 발생 IP가 유휴 상태로 낭비됨 연결 해제(Disassociate) 후 릴리스(Release) 완료 ❌ 무료 IP가 AWS 풀로 반환됨 결론: 요금을 완전히 멈추려면 Disassociate(연결 해제) 와 Release(릴리스) 를 모두 수행해야 한다. Disassociate만 하면 IP가 계정에 남아 있어 여전히 과금된다. Elastic IP 요금 구조가 작동하는 방식 AWS가 Elastic IP에 요금을 부과하는 핵심 원칙은 단순하다. 퍼블릭 IPv4 주소는 희소 자원 이며, AWS는 계정이 해당 IP를 실제로 사용하지 않으면서 점유하고 있을 때 요금을 청구한다. '사용 중'의 정의는 실행 상태(running)의 인스턴스 또는 NAT 게이트웨이에 연결되어 있을 때 다. 인스턴스를 중지하면 그 인스턴스에 연결된 Elastic IP는 즉시 '유휴(idle)' 상태가 된다. AWS 입장에서는 이 IP를 다른 고객에게 할당할 수 없는데 계정이 붙잡고 있는 것이므로, 시간당 요금이 발생한다. 요금과 정확한 조건은 변동될 수 있으므로 항상 공식 AWS EC2 요금 페이지 에서 확인해야 한다. stateD...