🔐 IAM 역할(IAM Role)이란?
IAM 역할 = 누군가가 ‘잠시’ 빌려 쓰는 권한 묶음
한 줄로:
자격증명(아이디/비밀번호) 없이
AWS 리소스가 AWS 리소스에 접근하게 해주는 방식
👤 IAM 사용자 vs IAM 역할
| 구분 | IAM 사용자 | IAM 역할 |
|---|---|---|
| 로그인 | O (ID/비번) | ❌ |
| 영구 자격증명 | 있음 | ❌ |
| 사용 주체 | 사람 | 사람/서비스 |
| 권한 사용 방식 | 항상 동일 | 임시로 Assume |
📌 역할은 “로그인 계정”이 아니라 “권한 상자”
🧠 왜 IAM 역할이 필요한데?
❌ 나쁜 방식
- EC2 안에 Access Key 박아두기
- 코드에 AWS 키 하드코딩
👉 보안 최악
✅ 좋은 방식
- IAM 역할을 EC2에 연결
- AWS가 임시 자격증명 자동 발급
👉 보안 + 자동 + 관리 편함
🧩 IAM 역할의 핵심 구성 2가지
1️⃣ Trust Policy (누가 이 역할을 쓸 수 있나)
"Service":"ec2.amazonaws.com"→ EC2만 이 역할 사용 가능
2️⃣ Permission Policy (무엇을 할 수 있나)
"s3:GetObject"→ S3 읽기 가능
🔁 Assume Role이란?
Assume Role = “이 역할 좀 빌릴게요”
- EC2 → IAM 역할 Assume
- Lambda → IAM 역할 Assume
- 다른 AWS 계정 → 역할 Assume
📌 이때 임시 보안 자격증명(STS) 이 발급됨
☁️ AWS 서비스별 대표 역할 예시
✅ EC2 Role
- EC2 → S3 접근
- EC2 → DynamoDB 접근
✅ Lambda Role
- Lambda → CloudWatch Logs
- Lambda → DynamoDB
✅ ECS Task Role
- 컨테이너 → SQS, S3 접근
✅ Cross-Account Role
- 계정 A → 계정 B 리소스 접근
🧪 시험에 이렇게 나오면 “IAM 역할”
| 문제 문장 | 정답 힌트 |
|---|---|
| EC2가 S3에 접근 | IAM Role |
| 키를 저장하지 않고 접근 | IAM Role |
| 다른 AWS 계정 접근 | Assume Role |
| Lambda가 DynamoDB 접근 | Lambda Role |
❌ 자주 나오는 오답 포인트
- ❌ IAM 사용자 키를 EC2에 저장 → ❌
- ❌ 역할은 로그인한다 → ❌
- ❌ 역할은 하나의 정책만 가능 → ❌ (여러 개 가능)
🧠 한 줄 암기
IAM 역할 = 로그인 없이, 임시로, 안전하게 권한을 쓰는 방법
🔐 IAM 정책이란?
IAM 정책 = AWS에서 권한을 정의한 규칙 문서(JSON)
한 줄로:
“이 행동은 허용/거부한다”를 명확히 적어둔 약속
🧩 정책의 기본 구조 (시험 핵심)
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}필드 의미
- Effect:
Allow또는Deny - Action: 무엇을 할 수 있나 (API)
- Resource: 어디에 대해?
- Condition: (선택) 언제/어떤 조건일 때?
🧠 정책의 종류 3가지 (자주 헷갈림)
1️⃣ 자격 증명 기반 정책 (Identity-based)
- 사용자 / 그룹 / 역할에 붙임
- 가장 흔함
📌 예:
“이 사용자에게 S3 읽기 권한”
2️⃣ 리소스 기반 정책 (Resource-based)
- 리소스 자체에 붙임
- 대표: S3 버킷 정책, SQS 정책
📌 예:
“이 버킷은 다른 계정에서도 접근 가능”
3️⃣ SCP (Service Control Policy)
- Organizations 전용
- “최대 허용 범위”만 정의 (권한 부여 X)
📌 예:
“이 OU에서는 EC2 Large 금지”
⚖️ Allow vs Deny (시험 100% 출제)
명시적 Deny > 모든 Allow
- Allow가 있어도
- Deny 하나면 무조건 거부
📌 암기:
Deny는 최종 보스
🧪 정책 평가 순서 (간단 버전)
- Deny 있는지 먼저 확인
- Allow 있는지 확인
- 없으면 → 기본값 Deny
🧰 관리형 정책 vs 인라인 정책
| 구분 | 관리형 정책 | 인라인 정책 |
|---|---|---|
| 재사용 | 가능 | ❌ |
| AWS 제공 | 있음 | ❌ |
| 관리 | 쉬움 | 번거로움 |
| 시험 추천 | ✅ | ❌ |
📌 SAA에서는 “관리형 정책”이 거의 정답
🎯 시험에 자주 나오는 패턴
| 문제 표현 | 정답 힌트 |
|---|---|
| 여러 사용자에게 동일 권한 | 그룹 + 관리형 정책 |
| EC2가 S3 접근 | IAM 역할 + 정책 |
| 다른 계정 접근 허용 | 리소스 기반 정책 |
| 특정 리전만 허용 | Condition |
❌ 자주 나오는 오해
- ❌ 정책 = 사용자 → 아님 (역할/그룹도 가능)
- ❌ Allow 없으면 자동 허용 → ❌ 기본은 Deny
- ❌ SCP가 권한을 준다 → ❌ 제한만 함
🧠 한 줄 암기
IAM 정책 = AWS에서 “누가 무엇을 할 수 있는지” 적은 규칙
🔑 한 줄로 차이부터
- IAM 정책(Policy): 👉 “무엇을 할 수 있는지” 적어둔 권한 규칙
- IAM 역할(Role): 👉 그 권한을 ‘누가, 어떻게’ 쓰게 할지 정한 권한 상자
📌 정책 = 내용, 역할 = 담는 그릇
🧩 개념 비교 표
| 구분 | IAM 정책 (Policy) | IAM 역할 (Role) |
|---|---|---|
| 정체 | 권한 규칙 문서 | 권한을 담는 객체 |
| 역할 | 행동 허용/거부 정의 | 권한을 누가 쓸 수 있는지 정의 |
| 단독 사용 | ❌ | ❌ (정책 필요) |
| 붙는 대상 | 사용자 / 그룹 / 역할 | 사용자 / AWS 서비스 |
| 로그인 가능 | ❌ | ❌ |
| 핵심 키워드 | Allow / Deny | Assume Role |
🔐 IAM 정책이 하는 일
정책은 JSON 문서.
{"Effect":"Allow","Action":"s3:GetObject","Resource":"*"}👉 의미:
“S3 객체 읽기 허용”
📌 하지만 이 정책만으로는 아무도 못 씀
→ 누군가(사용자/역할)에 붙여야 함
🎭 IAM 역할이 하는 일
역할은 이렇게 말할 수 있다:
“이 역할을 쓰는 애는, 이 정책들을 쓸 수 있다”
예시: EC2가 S3 접근해야 할 때
- IAM 역할 생성
- S3 접근 정책을 역할에 연결
- EC2에 역할 연결
- EC2가 Assume Role 해서 권한 사용
📌 Access Key 없음, 하드코딩 없음 → 보안 최고
🔁 관계를 그림으로 말하면
[정책] ──(붙는다)──▶[역할] ──(Assume)──▶[EC2 / Lambda / 사용자]🧪 시험에서 이렇게 나오면 이렇게 판단
✅ “무엇을 할 수 있는지 정의”
→ 정책 (Policy)
✅ “EC2/Lambda가 AWS 서비스 접근”
→ 역할 (Role) + 정책
✅ “다른 계정 접근”
→ 역할 (Assume Role) + 정책
❌ 자주 나오는 오해
- ❌ 정책이 있으면 자동으로 권한 생김 → ❌
- ❌ 역할은 정책 없이도 동작 → ❌
- ❌ 역할은 로그인 계정 → ❌
🧠 초압축 암기 문장
정책은 ‘권한 내용’이고,
역할은 ‘그 권한을 쓰게 해주는 방식’이다
순두의 누나입니다