IAM 역할 vs 사용자: 언제 무엇을 사용할까?

핵심 요약 (BLUF)

IAM 역할(Role)은 임시 자격 증명을, IAM 사용자(User)는 장기 자격 증명을 사용합니다. EC2, Lambda 등 AWS 서비스가 다른 서비스에 접근할 때는 반드시 역할을 사용하세요. 사용자는 콘솔에 로그인하는 실제 사람에게만 사용합니다.

IAM 역할과 사용자의 핵심 차이

한눈에 비교

비교 항목	IAM 사용자	IAM 역할
대상	사람, 특정 애플리케이션	AWS 서비스, 임시 접근 필요 시
자격 증명	장기 (비밀번호, Access Key)	임시 (STS 토큰)
자격 증명 만료	수동 교체 필요	자동 만료 (기본 1시간)
연결 대상	특정 한 사람/시스템과 1:1	필요한 누구나 수임 가능
보안 수준	키 유출 시 영구 위험	토큰 유출 시에도 시간 제한
AWS 권장	제한적 사용	적극 권장

장기 자격 증명 vs 임시 자격 증명

IAM 사용자 (장기 자격 증명)
├── Access Key ID: AKIAXXXXXXXXXXXXXXXX
└── Secret Access Key: 고정값 (교체 전까지 유효)
    └── 위험: 유출 시 삭제할 때까지 악용 가능

IAM 역할 (임시 자격 증명)
├── Access Key ID: ASIAXXXXXXXXXXXXXXXX (임시)
├── Secret Access Key: 임시값
├── Session Token: 필수
└── Expiration: 1시간~12시간 후 자동 만료
    └── 장점: 유출되어도 시간 제한으로 피해 최소화

IAM 역할은 언제 사용할까?

1. AWS 서비스가 다른 서비스에 접근할 때 (필수!)

가장 중요한 사용 사례입니다. EC2, Lambda, ECS 등의 서비스가 S3, DynamoDB 등에 접근해야 할 때 반드시 역할을 사용합니다.

❌ 잘못된 방법 (절대 금지!)
EC2 인스턴스 내 코드에 Access Key 하드코딩
  └── 보안 위험: 코드 유출 시 키도 유출

✅ 올바른 방법 (AWS 권장)
EC2 인스턴스에 IAM 역할 연결
  └── 인스턴스 메타데이터에서 임시 자격 증명 자동 획득

예시 시나리오:

• EC2 인스턴스가 S3 버킷에서 파일 읽기
• Lambda 함수가 DynamoDB에 데이터 쓰기
• ECS 태스크가 Secrets Manager에서 비밀 조회

2. 교차 계정(Cross-Account) 접근

다른 AWS 계정의 리소스에 접근해야 할 때 역할을 사용합니다.

계정 A (리소스 소유)                계정 B (접근 필요)
┌─────────────────┐              ┌─────────────────┐
│  S3 버킷        │              │  IAM 사용자     │
│                 │              │  (개발자)       │
│  IAM 역할 생성  │◄─── 역할 수임 ──│                 │
│  - 신뢰 정책:   │              │  권한:          │
│    계정 B 허용  │              │  sts:AssumeRole │
└─────────────────┘              └─────────────────┘

3. 외부 ID 제공자(IdP) 연동

SAML 2.0이나 OpenID Connect를 통해 기업 SSO로 AWS에 접근할 때 역할을 사용합니다.

기업 사용자
  ↓ (기업 IdP 인증)
Active Directory / Okta / Google
  ↓ (SAML 어설션 또는 OIDC 토큰)
AWS STS (AssumeRoleWithSAML / AssumeRoleWithWebIdentity)
  ↓ (임시 자격 증명 발급)
AWS 리소스 접근

4. 임시 권한 상승

평소에는 읽기 전용 권한만 있다가, 필요할 때만 관리자 역할을 수임하는 패턴입니다.

개발자 (기본 권한: ReadOnly)
  ↓ 관리자 역할 수임 (MFA 필수)
관리자 역할 (임시, 1시간)
  ↓ 작업 완료
다시 ReadOnly 상태

IAM 사용자는 언제 사용할까?

AWS는 IAM Identity Center(SSO) 사용을 우선 권장하며, 불가능한 경우에만 IAM 사용자를 사용합니다.

IAM 사용자가 필요한 경우

사용 사례	설명
역할 미지원 워크로드	WordPress 플러그인 등 임시 자격 증명 사용 불가
타사 도구	IAM Identity Center 미지원 클라이언트
긴급 접근	IdP 장애 시 복구용 비상 계정
CodeCommit SSH 키	Git SSH 인증이 필요한 경우
Amazon Keyspaces	Cassandra 호환 서비스 접근

역할 수임(Assume Role) 동작 원리

역할 수임 과정

1. 요청자 → AWS STS: AssumeRole 호출
   └── 역할 ARN + (선택) 외부 ID, 세션 이름

2. STS: 신뢰 정책 확인
   └── "이 요청자가 역할을 수임할 수 있는가?"

3. STS → 요청자: 임시 자격 증명 반환
   ├── AccessKeyId (ASIA로 시작)
   ├── SecretAccessKey
   ├── SessionToken
   └── Expiration (만료 시간)

4. 요청자: 임시 자격 증명으로 AWS API 호출

신뢰 정책(Trust Policy) 예시

역할을 누가 수임할 수 있는지 정의합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principal 유형:

• "Service": "ec2.amazonaws.com" - AWS 서비스
• "AWS": "arn:aws:iam::123456789012:root" - 다른 계정
• "AWS": "arn:aws:iam::123456789012:user/DevUser" - 특정 사용자

권한 정책(Permissions Policy)

역할이 무엇을 할 수 있는지 정의합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

서비스 역할 vs 서비스 연결 역할

서비스 역할 (Service Role)

• AWS 서비스가 수임하여 작업 수행
• 사용자가 생성하고 관리
• 권한 정책 편집 가능

예시: EC2 인스턴스 역할, Lambda 실행 역할

서비스 연결 역할 (Service-Linked Role)

• AWS 서비스가 자동으로 생성하고 관리
• 권한 편집 불가 (AWS가 관리)
• 관련 리소스 삭제 후에만 삭제 가능

예시: AWSServiceRoleForAutoScaling, AWSServiceRoleForElasticLoadBalancing

서비스 역할 (사용자 관리)
├── 생성: 사용자
├── 권한 편집: 가능
└── 삭제: 자유롭게 가능

서비스 연결 역할 (AWS 관리)
├── 생성: AWS 서비스 (자동)
├── 권한 편집: 불가
└── 삭제: 관련 리소스 삭제 후에만 가능

실전 선택 가이드

시나리오별 선택

시나리오	선택	이유
EC2에서 S3 접근	역할	Access Key 하드코딩 금지, 임시 자격 증명 사용
Lambda에서 DynamoDB 접근	역할	Lambda 실행 역할 필수
개발자 콘솔 로그인	IAM Identity Center 또는 사용자	페더레이션 권장
계정 A에서 계정 B 리소스 접근	역할	Cross-Account 역할 수임
CI/CD 파이프라인 (GitHub Actions)	역할	OIDC 연동으로 역할 수임 권장
긴급 복구 계정	사용자	IdP 장애 대비 비상 계정

의사결정 흐름

AWS 서비스(EC2, Lambda 등)인가?
├── Yes → IAM 역할 사용
└── No
    ↓
사람이 콘솔/CLI를 사용하는가?
├── Yes → IAM Identity Center(SSO) 권장
│         └── 불가능하면 IAM 사용자
└── No
    ↓
다른 계정에서 접근하는가?
├── Yes → 교차 계정 IAM 역할
└── No
    ↓
외부 IdP(SAML/OIDC)를 사용하는가?
├── Yes → IAM 역할 + 페더레이션
└── No → IAM 역할 또는 사용자 검토

역할 체이닝(Role Chaining)

한 역할의 임시 자격 증명으로 다른 역할을 수임하는 방식입니다.

사용자 → 역할 A → 역할 B → 역할 C
        (수임)   (수임)   (수임)

제한사항:

• 최대 세션 지속 시간: 1시간 (역할 설정과 무관)
• 역할 설정에서 12시간을 지정해도 체이닝 시 1시간으로 제한

SAA-C03 시험 출제 포인트

1. ✅ EC2/Lambda에서 다른 서비스 접근: 무조건 IAM 역할 (Access Key 하드코딩 금지)
2. ✅ 임시 vs 장기 자격 증명: 역할 = 임시(자동 만료), 사용자 = 장기(수동 교체)
3. ✅ Cross-Account 접근: 역할 + 신뢰 정책 사용
4. ✅ 서비스 연결 역할: AWS가 관리, 권한 편집 불가
5. ✅ 역할 체이닝 제한: 최대 세션 1시간

자주 묻는 질문 (FAQ)

Q: IAM 사용자의 Access Key가 왜 위험한가요?

Access Key는 영구 자격 증명입니다. 코드에 포함되거나 Git에 커밋되면 삭제하기 전까지 악용될 수 있습니다. 반면 역할의 임시 자격 증명은 자동으로 만료되어 유출 시 피해가 제한됩니다.

Q: EC2 인스턴스에 연결된 역할은 어떻게 자격 증명을 얻나요?

EC2는 **인스턴스 메타데이터 서비스(IMDS)**를 통해 자동으로 임시 자격 증명을 제공받습니다. SDK가 자동으로 이를 처리하므로 코드에서 별도 설정이 필요 없습니다.

http://169.254.169.254/latest/meta-data/iam/security-credentials/역할이름

Q: 역할을 수임하면 기존 권한은 어떻게 되나요?

역할을 수임하면 기존 권한은 일시적으로 포기됩니다. 역할의 권한만 사용할 수 있습니다. 역할 세션이 종료되면 원래 권한으로 돌아갑니다.

Q: 한 사용자가 여러 역할을 동시에 수임할 수 있나요?

동시에는 불가능합니다. 하지만 하나의 역할을 수임한 후 다른 역할로 체이닝(전환)할 수 있습니다. 이때 세션 지속 시간은 1시간으로 제한됩니다.

Q: 서비스 연결 역할을 삭제할 수 없어요.

서비스 연결 역할은 관련 리소스를 먼저 삭제해야 합니다. 예를 들어 Auto Scaling 그룹을 모두 삭제해야 AWSServiceRoleForAutoScaling 역할을 삭제할 수 있습니다.

Q: 교차 계정 접근에서 외부 ID(External ID)는 왜 필요한가요?

Confused Deputy Problem 방지를 위해 사용합니다. 제3자가 당신의 계정을 속여서 다른 고객의 리소스에 접근하는 것을 방지합니다. 특히 외부 조직과 역할을 공유할 때 필수입니다.

관련 글

• IAM 기초: 사용자, 그룹, 역할, 정책
• IAM 정책 평가 로직: 허용과 거부는 어떻게 결정될까?
• AWS Organizations & SCP 가이드

참고 자료

• AWS IAM 역할 공식 문서
• IAM 사용자 공식 문서
• IAM 역할을 사용해야 하는 경우
• 임시 보안 자격 증명