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

IAM User와 IAM Role의 차이를 명확히 이해하지 못하면, EC2 인스턴스에서 S3에 접근할 때 자격증명을 하드코딩하거나 불필요하게 장기 키를 발급하는 실수를 반복하게 된다. 이 글은 두 개념의 구조적 차이와, EC2 인스턴스가 S3에 접근하는 실제 운영 시나리오 에서 어떤 선택이 올바른지를 명확히 설명한다. TL;DR — IAM User vs IAM Role 핵심 비교 EC2 인스턴스에서 S3에 접근할 때는 IAM Role(인스턴스 프로파일)을 사용하는 것이 AWS 공식 권장 방식이다. IAM User의 액세스 키를 인스턴스에 직접 저장하는 방식은 키 노출 위험이 있고, 자격증명 교체 비용이 높다. 항목 IAM User IAM Role 자격증명 유형 장기 액세스 키 (Access Key ID + Secret) 임시 보안 토큰 (STS 발급) 주체(Principal) 사람 또는 애플리케이션 AWS 서비스, 계정, 사람 등 자격증명 수명 명시적으로 삭제하기 전까지 유효 기본 1시간, 최대 12시간 (설정에 따라 다름) EC2 사용 권장 여부 ❌ 비권장 (키 하드코딩 위험) ✅ 권장 (인스턴스 프로파일) 자격증명 자동 교체 수동 교체 필요 STS가 자동 갱신 멀티 계정 접근 제한적 Cross-account Role Assumption 지원 IAM User와 IAM Role의 작동 원리 IAM User는 AWS 계정 내에 영구적으로 존재하는 자격증명 주체다. 콘솔 로그인용 패스워드와 API 호출용 액세스 키를 가지며, 이 키는 명시적으로 비활성화하거나 삭제하지 않는 한 계속 유효하다. 사람이 직접 AWS 콘솔이나 CLI를 사용하는 경우에 적합하다. IAM Role은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...