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 기반 토큰 발...

Lambda 함수가 오류 없이 실행되는데 S3에서 403을 반환한다면, 대부분의 엔지니어는 즉시 실행 역할(Execution Role)을 의심한다. 맞는 방향이지만, S3의 403은 IAM 권한 하나만의 문제가 아니다. 버킷 정책, 퍼블릭 액세스 차단 설정, KMS 암호화, VPC 엔드포인트 정책까지 여러 레이어가 독립적으로 접근을 거부할 수 있고, 그 중 하나라도 Deny를 내리면 결과는 동일하게 403이다. TL;DR — Lambda S3 403 빠른 진단표 원인 레이어 증상 확인 방법 실행 역할 IAM 권한 누락 s3:GetObject 등 액션 없음 IAM 정책 시뮬레이터 또는 CLI 버킷 정책 명시적 Deny IAM 권한 있어도 거부 버킷 정책 직접 확인 S3 퍼블릭 액세스 차단 퍼블릭 ACL 기반 접근 차단 get-public-access-block KMS 키 권한 누락 SSE-KMS 버킷에서 403 KMS 키 정책 확인 VPC 엔드포인트 정책 VPC 내 Lambda에서만 403 엔드포인트 정책 확인 S3 객체 ACL 불일치 특정 객체만 403 get-object-acl Lambda S3 403 오류의 구조적 이해 S3의 접근 제어는 단일 정책이 아니라 여러 레이어의 평가 결과를 순서대로 합산한다. AWS는 이를 'Authorization Context'라고 부르며, 어느 레이어에서든 명시적 Deny가 발생하면 나머지 Allow는 무효화된다. Lambda 실행 역할에 s3:GetObject 를 추가했는데도 403이 계속 나온다면, 상위 레이어 중 하나가 여전히 Deny를 내리고 있는 것이다. graph TD A["Lambda 함수 실행"] --> B["IAM 정책 평가 (실행 역할 + SCP)"] B ...

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/...