AWS 기초 #5 CloudShell과 IAM Identity Center (SSO)

#4 AWS CLI에서 로컬 셋업을 끝냈습니다. 두 가지 도구가 더 있습니다.

• CloudShell. 콘솔 안의 브라우저 터미널. 노트북이 없어도, 임시 환경에서도 즉시 CLI 작업 가능
• IAM Identity Center (SSO). 멀티 어카운트 / 팀 운영의 표준 로그인. 액세스 키 같은 영구 자격을 거의 없앱니다

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

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'])"

# 홈 디렉터리는 1GB 영구
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 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의 정책 묶음 + 세션 시간 + 추가 옵션의 단위.

세션 시간은 보통 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에서 한 일을 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을 직접 빌리는 패턴이 표준 (실전 #3에서 다루겠습니다).

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

이미 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 임시 자격)

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

자주 만나는 함정 #

1) 옛 이름 “AWS SSO"의 흔적 #

자료 / 콘솔 일부에서 옛 이름이 보입니다. 같은 서비스이니 혼동하지 마세요. CLI의 aws configure sso는 새 이름 기준입니다.

2) 처음 활성화 리전을 잘못 고름 #

IAM Identity Center는 활성화 리전을 나중에 바꾸기 매우 어렵습니다. 보통 운영 주 리전 / us-east-1 중 하나. 회사가 한국 중심이면 서울 (ap-northeast-2).

3) Permission Set 세션이 너무 길거나 짧음 #

12시간으로 너무 길면 노출 시 위험하고, 1시간으로 너무 짧으면 매시간 로그인해야 합니다. 일상 개발은 4~8시간, 운영 작업은 1~2시간이 흔합니다.

4) aws sso login의 브라우저 자동 열림 안 됨 #

서버 / 컨테이너 / SSH 환경. 이때 aws sso login --no-browser를 쓰면 URL + 코드를 출력 → 다른 기기에서 열어 인증.

5) CloudShell의 1GB 한도 #

큰 데이터 / 임시 빌드를 CloudShell 안에서 누적하면 한도 초과로 동작 거부. 정기적으로 청소 또는 S3로 옮기기.

6) IAM 사용자 액세스 키와 SSO가 동시에 #

전환 중인 환경에서는 양쪽이 살아 있습니다. 자격 체인 (#4)으로 어느 자격이 도는지 항상 확인하세요. aws sts get-caller-identity가 답입니다.

7) Permission Set 안에서 IAM 정책 제한 #

Permission Set는 결국 IAM Role을 만들어 묶는 방식입니다. 한 Permission Set에 너무 많은 정책 / 인라인 정책을 넣으면 IAM Role 정책 한도에 걸립니다. 과하면 분리하세요.

정리 #

이번 글에서 잡은 것:

• CloudShell. 콘솔 우측 상단의 브라우저 터미널입니다. CLI / Python / git이 미리 설치돼 있고, 자격 자동 연결, 1GB 영구 홈, 무료입니다.
• 리전마다 별도이며, 큰 데이터는 S3를 경유합니다.
• IAM Identity Center (구 AWS SSO). 멀티 어카운트 / 팀 로그인의 표준입니다.
• 한 번 로그인하면 여러 계정 / Permission Set의 임시 자격을 받습니다.
• 영구 액세스 키를 거의 없앱니다.
• 셋업. Organizations → Identity Center 활성화 → 사용자 / 그룹 → Permission Set → 계정 할당 순입니다.
• CLI 통합. aws configure sso와 ~/.aws/config의 sso-session을 쓰고, aws sso login 한 번으로 로그인합니다.
• 마이그레이션. Organizations → SSO 활성화 → 본인 전환 → 팀 → IAM 사용자 콘솔 비활성화 → 키 폐기 순으로 진행합니다.
• 함정. 옛 이름 흔적, 활성화 리전 변경 어려움, 세션 시간 균형, –no-browser 옵션, CloudShell 한도, 양쪽 자격 동시 존재입니다.

다음: 보안 기본 #

콘솔 / CLI / SSO까지 셋업이 끝났습니다. 이제 보안의 기초를 한 번 더 단단히. MFA 강제, 액세스 키 회전, 최소 권한 패턴, 그리고 자주 만나는 사고 사례까지.

#6 보안 기본: MFA, 키 회전, 최소 권한에서는 #2 IAM의 정책 위에, 운영에서 통하는 보안 가드레일을 정리하겠습니다.