CloudShell과 IAM Identity Center (SSO)

4장 CLI와 SDK에서 로컬 셋업을 끝냈습니다. 여기에 두 가지 도구가 더 있습니다. 하나는 CloudShell로, 콘솔 안의 브라우저 터미널입니다. 노트북이 없어도, 임시 환경에서도 즉시 CLI를 씁니다. 다른 하나는 **IAM Identity Center (SSO)**로, 멀티 어카운트 / 팀 운영의 표준 로그인입니다. 영구 액세스 키를 거의 없앱니다.

이 둘은 작은 1 인 학습에는 살짝 과하지만, 두 번째 계정이나 두 번째 동료가 등장하는 순간 자연스럽게 만나는 도구입니다. 미리 알고 있으면 한 단계 부드럽게 넘어갑니다.

본 챕터는 4장의 자격 증명 체인 위에서, 사람이 로그인하는 방식을 한 단계 정교하게 만드는 토픽입니다. 멀티 어카운트 거버넌스 자체는 29장 보안 거버넌스에서 본격적으로 다룹니다.

CloudShell — 브라우저 안의 터미널 #

콘솔 우측 상단의 작은 터미널 아이콘이 AWS CloudShell입니다. 로그인된 상태에서 바로 작동하는 셸이 뜹니다.

무엇이 좋은가 #

• CLI가 미리 설치되어 있음 — aws, python(boto3 포함), node, git.
• 자격이 자동 — 콘솔 로그인 자격이 셸에도 연결되어 aws configure가 불필요합니다.
• 1GB 영구 홈 디렉터리 — 세션을 종료해도 유지됩니다.
• 무료 — 사용 시간 / 출력 트래픽 한도 안에서입니다.

어디에 좋은가 #

빠르게 써보기 #

# 자격이 이미 연결됨
aws sts get-caller-identity

# python도 설치되어 있음
python3 -c "import boto3; print(boto3.client('s3').list_buckets()['Buckets'])"

# 홈 디렉터리는 1 GB 영구
echo "hello" > ~/notes.txt
# 세션 끝내고 다음에 다시 와도 ~/notes.txt 살아 있음

주의 — 리전 종속 #

CloudShell의 홈 디렉터리는 리전마다 별도입니다. 서울에서 만든 파일은 도쿄 CloudShell에서 보이지 않습니다. 그래서 보통 한 리전에서 쓰는 것이 자연스럽습니다.

파일 업로드 / 다운로드 #

CloudShell 우측 상단 메뉴 → Actions → Upload / Download file로 받습니다. 작은 파일은 이걸로, 큰 파일은 S3를 경유합니다.

aws s3 cp my-data.zip s3://my-temp-bucket/
# 다른 환경에서:
aws s3 cp s3://my-temp-bucket/my-data.zip ./

IAM Identity Center (SSO) — 그게 뭐고 왜 쓰는가 #

이름이 자꾸 바뀐 서비스입니다.

AWS Single Sign-On (AWS SSO)  →  IAM Identity Center
                              (2022 년 이후 표준 이름)

옛 글이나 자료에서는 “AWS SSO"라는 이름으로 자주 보이지만 같은 서비스입니다.

무엇을 푸는가 #

2장 IAM에서 본 IAM 사용자 모델에는 한계가 있습니다.

IAM Identity Center는 이걸 한 곳으로 모읍니다.

[직원 한 명]
  └── SSO 포털 (로그인 한 번)
       ├── prod 계정 / AdminAccess
       ├── prod 계정 / ReadOnly
       ├── staging 계정 / DeveloperAccess
       └── dev 계정 / DeveloperAccess

각 계정 안에서 IAM 사용자를 만드는 대신 SSO가 임시 자격을 발급해 줍니다. 회전이 필요한 영구 키도 사라집니다.

누가 쓰는가 #

• Organizations 멀티 어카운트 — 사실상 표준입니다.
• 팀 5명 이상 — 사용자 / 권한 관리가 절감됩니다.
• 무료 — Organizations와 함께 쓰면 추가 비용이 없습니다.

1 인 학습 / 단일 계정에는 살짝 과합니다. 두 번째 계정이 생기는 순간이 셋업 시점입니다.

IAM Identity Center 셋업 — 5단계 #

1) Organizations 활성화 #

IAM Identity Center는 Organizations 위에서 작동합니다. 단일 계정도 Organizations 활성화는 무료입니다.

콘솔 → AWS Organizations → "Create an organization"

2) IAM Identity Center 활성화 #

콘솔 → IAM Identity Center → "Enable"

리전을 한 번 고르면 변경이 어려우니 신중히 합니다. 보통 운영 주 리전(서울이면 ap-northeast-2)으로 둡니다.

3) 사용자 / 그룹 만들기 #

기본 자체 디렉터리(Identity store) 또는 외부 IdP(Google Workspace, Microsoft Entra, Okta 등)를 연동합니다.

IAM Identity Center → Users → Add user
- 이메일 / 이름 입력
- 초대 메일 발송 → 비밀번호 + MFA 셋업

Admins
Developers
ReadOnly
Billing

4) Permission Set 만들기 #

Permission Set는 2장 IAM의 정책 묶음에 세션 시간과 추가 옵션을 더한 단위입니다.

세션 시간은 보통 1~12시간(기본 1시간)입니다. 운영용은 짧게(2시간), 일상 개발은 8시간으로 둡니다.

5) Account Assignment — 누가 + 어디 + 무엇 #

IAM Identity Center → AWS accounts
- 계정 선택 (예: prod)
- "Assign users or groups"
- Group: Developers + Permission Set: PowerUserDeveloperAccess

이 셋이 모이는 형태는 그룹 × 계정 × Permission Set입니다. Developers 그룹이 prod 계정에 PowerUser로 들어갑니다.

SSO 포털 사용 흐름 #

직원 입장에서의 흐름은 다음과 같습니다.

1. 시작 URL(예: https://my-org.awsapps.com/start)로 접속합니다.
2. 비밀번호와 MFA를 입력합니다.
3. 자기에게 할당된 계정 + Permission Set 목록이 보입니다.
4. 각 항목 옆 “Management console” 클릭으로 그 계정의 콘솔에 자동 로그인합니다.
5. “Command line / programmatic access” 클릭으로 CLI 자격 자료를 받습니다.

CLI에서 SSO 로그인 #

aws cli v2가 SSO를 네이티브로 지원합니다. 4장 CLI와 SDK에서 한 일을 SSO로 다시 합니다.

aws configure sso
# SSO session name (Recommended): my-org
# SSO start URL [None]: https://my-org.awsapps.com/start
# SSO region [None]: ap-northeast-2
# SSO registration scopes [sso:account:access]:
# 브라우저가 열리고 로그인 → 권한 동의 →
# Available accounts:
#   prod (123456789012)
#   staging (...)
#   dev (...)
# Choose an account ID: prod
# Choose a role: PowerUserDeveloperAccess
# CLI default Region: ap-northeast-2
# CLI profile name: prod

설정 후 ~/.aws/config에 다음처럼 들어갑니다.

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

[profile prod]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

일상 흐름 #

aws sso login --profile prod
# 브라우저 열림 → 로그인 → 자격 캐시

aws s3 ls --profile prod
aws ec2 describe-instances --profile prod

세션은 보통 8~12시간입니다. 끊기면 다시 aws sso login 합니다.

여러 계정에 한 번에 로그인 #

my-org라는 sso-session 하나에 여러 프로파일을 묶으면 한 번 aws sso login으로 모두 로그인됩니다.

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

[profile prod]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = ap-northeast-2

[profile staging]
sso_session = my-org
sso_account_id = 222222222222
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

[profile dev]
sso_session = my-org
sso_account_id = 333333333333
sso_role_name = PowerUserDeveloperAccess
region = ap-northeast-2

aws sso login --sso-session my-org
aws s3 ls --profile prod
aws s3 ls --profile staging
aws s3 ls --profile dev

IAM 사용자 모델 vs SSO 모델 #

언제 무엇을 쓸지 한 표로 봅니다.

CI/CD의 경우 IAM Identity Center가 자체 서비스 자격을 주지는 않습니다. 그래서 GitHub Actions나 GitLab은 OIDC로 IAM Role을 직접 빌리는 패턴이 표준입니다(24장 CI/CD 파이프라인에서 다룹니다).

현실적인 마이그레이션 순서 #

이미 IAM 사용자를 쓰고 있는 환경에서 SSO로 옮기는 순서입니다.

1. Organizations 활성화(단일 계정도 무료)
2. IAM Identity Center 활성화 + 첫 사용자 / 그룹 / Permission Set
3. 본인부터 SSO로 전환 — 1~2주 병행 운영
4. 동료들 SSO 초대
5. IAM 사용자의 Console access 비활성화 — SSO로 강제
6. IAM 사용자의 액세스 키 — 자동화는 OIDC / 인스턴스 프로파일로 옮기고, 사용자 액세스 키는 단계적으로 폐기
7. 결과: 사람은 모두 SSO, 머신은 모두 Role

이 순서가 한 달 ~ 분기로 자연스럽게 진행됩니다.

CloudShell + SSO의 만남 #

콘솔에 SSO로 로그인했으면, 그 환경에서 CloudShell을 열면 SSO 임시 자격이 셸에 연결됩니다. 자격을 다룰 일 없이 즉시 작업합니다.

aws sts get-caller-identity
# Arn: arn:aws:sts::123:assumed-role/AWSReservedSSO_AdministratorAccess_xxx/email@example.com
# (assumed-role — 영구 사용자가 아닌 SSO 임시 자격)

이 환경은 임시 자격이 자동으로 갱신됩니다. 작은 점검이나 일회성 작업에 매우 편합니다.

자주 만나는 함정 #

• 옛 이름 “AWS SSO"의 흔적 — 자료나 콘솔 일부에서 옛 이름이 보입니다. 같은 서비스이니 혼란하지 않습니다. CLI의 aws configure sso는 새 이름 기준입니다.
• 처음 활성화 리전을 잘못 고름 — IAM Identity Center는 활성화 리전을 나중에 바꾸기 매우 어렵습니다. 보통 운영 주 리전이나 us-east-1 중 하나입니다. 회사가 한국 중심이면 서울(ap-northeast-2)입니다.
• Permission Set 세션이 너무 길거나 짧음 — 12시간으로 너무 길면 노출 시 위험하고, 1시간으로 너무 짧으면 매시간 로그인해야 합니다. 일상 개발은 4~8시간, 운영 작업은 1~2시간이 흔합니다.
• aws sso login의 브라우저 자동 열림 안 됨 — 서버 / 컨테이너 / SSH 환경입니다. 이때 aws sso login --no-browser를 쓰면 URL과 코드를 출력하니 다른 기기에서 열어 인증합니다.
• CloudShell의 1GB 한도 — 큰 데이터나 임시 빌드를 CloudShell 안에 누적하면 한도 초과로 동작이 거부됩니다. 정기적으로 청소하거나 S3로 옮깁니다.
• IAM 사용자 액세스 키와 SSO가 동시에 — 전환 중인 환경에서는 양쪽이 살아 있습니다. 4장의 자격 체인으로 어느 자격이 도는지 항상 확인합니다. aws sts get-caller-identity가 답입니다.
• Permission Set 안의 IAM 정책 제한 — Permission Set는 결국 IAM Role을 만들어 묶는 방식입니다. 한 Permission Set에 너무 많은 정책이나 인라인 정책을 넣으면 IAM Role 정책 한도에 걸립니다. 과하면 분리합니다.

연습문제 #

1. §“어디에 좋은가” 표를 근거로, 본인이 최근 한 작업 세 가지를 CloudShell과 로컬 중 어디서 하는 게 적절한지 분류하고 그 이유를 한 줄씩 적어 보세요.
2. §“IAM Identity Center 셋업 — 5단계"를 보지 않고 순서대로 적어 보세요. 각 단계가 2장 IAM의 어느 요소(사용자 · 그룹 · 정책)와 대응하는지 연결해 두세요.
3. §“IAM 사용자 모델 vs SSO 모델” 표에서 CI/CD 행을 근거로, GitHub Actions가 영구 액세스 키 대신 OIDC + Role을 쓰는 이유를 24장 CI/CD 파이프라인과 연결해 한 단락으로 설명해 보세요.

한 줄 요약: CloudShell은 콘솔 안의 무료 브라우저 터미널로 자격이 자동 연결되고 1GB 영구 홈을 가지며 리전마다 별도다. IAM Identity Center는 멀티 어카운트 / 팀 로그인의 표준으로, 한 번 로그인하면 여러 계정에 임시 자격을 발급해 영구 액세스 키를 거의 없앤다. 사람은 SSO, 머신은 Role로 가는 것이 마이그레이션의 종착점이다.

다음 챕터 #

콘솔과 CLI, SSO까지 셋업이 끝났습니다. 다음 6장 보안 기본에서는 보안의 기초를 한 번 더 단단히 합니다. MFA 강제, 액세스 키 회전, 최소 권한 패턴, 그리고 자주 만나는 사고 사례까지 — 2장 IAM의 정책 위에 운영에서 통하는 보안 가드레일을 정리합니다.