SW BBANG K

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

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은 자격증명을 '소유'하는 개체가 아니라, 특정 조건에서 '위임'받아 사용하는 권한 집합이...