EC2에서 S3에 접근해야 하는데 액세스 키를 인스턴스에 하드코딩해 넣는 경우를 자주 봅니다. 동작은 하지만 키가 유출되면 그대로 사고로 이어집니다. AWS는 이런 상황을 위해 사용자(User) 가 아니라 역할(Role) 을 쓰라고 안내합니다. 둘의 차이는 "누가 쓰느냐"가 아니라 자격증명이 어떻게 전달되느냐에 있습니다.
역할과 사용자의 차이
| 항목 | IAM 사용자 (User) | IAM 역할 (Role) |
|---|---|---|
| 대상 | 사람·고정 ID | 임시로 권한을 빌리는 주체 |
| 자격증명 | 장기 액세스 키 (변하지 않음) | 임시 토큰 (자동 만료·갱신) |
| 소유 방식 | 사용자에 영구 귀속 | 아무도 소유 안 함, AssumeRole로 빌림 |
| 대표 용도 | 콘솔 로그인, 개인 CLI | EC2·Lambda·교차 계정 접근 |
| 유출 위험 | 키 유출 시 무기한 악용 | 토큰 짧은 수명으로 피해 제한 |
핵심은 역할에는 영구 키가 없다는 점입니다. EC2가 역할을 맡으면 메타데이터 서비스가 몇 시간짜리 임시 토큰을 자동으로 발급·교체합니다. 코드에 키를 둘 이유가 사라집니다.
언제 무엇을 쓰나
TEXT
사람이 콘솔/CLI로 직접 접근 → 사용자 (가능하면 IAM Identity Center로 대체)
EC2·Lambda·ECS가 AWS 호출 → 역할 (인스턴스 프로파일)
다른 AWS 계정이 내 리소스 접근 → 역할 (교차 계정 신뢰 정책)
외부 ID(구글·SAML) 연동 → 역할 (페더레이션)
판단 기준은 단순합니다. 사람이 아니거나, 접근이 일시적이거나, 계정 경계를 넘으면 역할입니다. 사람이 매일 쓰는 고정 계정만 사용자로 남기고, 그마저도 요즘은 SSO(Identity Center)로 옮기는 추세입니다.
EC2에 역할 붙이기
- 신뢰 정책으로 역할 생성 — EC2 서비스가 이 역할을 맡을 수 있게 허용합니다.
JSON
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com" },
"Action": "sts:AssumeRole"
}]
}
- 권한 정책 부여 — 필요한 최소 권한만(예: 특정 버킷 읽기) 붙입니다.
- 인스턴스 프로파일로 연결 — 콘솔에서 EC2에 역할을 지정하거나 CLI로 붙입니다.
- 검증 — 인스턴스 안에서 키 없이 호출되는지 확인합니다.
로컬 터미널
aws sts get-caller-identity # 역할 ARN이 나오면 성공
get-caller-identity의 응답에 assumed-role이 보이면 인스턴스가 액세스 키 없이 역할로 인증하고 있다는 뜻입니다.
요점 정리
- 사용자는 영구 키, 역할은 자동 만료되는 임시 토큰을 쓴다.
- 사람·고정 접근만 사용자, 서비스·일시·교차 계정은 역할이 원칙이다.
- EC2·Lambda에 키를 넣지 말고 역할을 붙이면 키 유출 위험이 사라진다.
aws sts get-caller-identity로 역할 적용 여부를 검증한다.
IAM 역할과 사용자를 직접 만들어 EC2에 붙여보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.