AWS Basics #5: CloudShell and IAM Identity Center (SSO)

In #4 AWS CLI we wrapped up the local setup. Two more tools remain.

• CloudShell — the in-browser terminal inside the console. You get CLI access right away, even on a borrowed machine.
• IAM Identity Center (SSO) — the standard login for multi-account / team operations. It almost eliminates permanent access-key credentials.

These two are slight overkill for solo learning, but the moment a second account or a second teammate shows up, you run into them naturally. Knowing them ahead of time makes that transition smoother.

CloudShell — the in-browser terminal #

The little terminal icon at the top right of the console — that’s AWS CloudShell. A shell springs up right where you’re already logged in.

What’s nice about it #

• CLI is preinstalled — aws, python (with boto3), node, git
• Credentials are automatic — your console login flows into the shell, no aws configure needed
• 1 GB persistent home — survives session ends
• Free — within usage time / outbound data limits

Where it shines #

Try it quickly #

# credentials already wired
aws sts get-caller-identity

# python is also installed
python3 -c "import boto3; print(boto3.client('s3').list_buckets()['Buckets'])"

# 1 GB home is persistent
echo "hello" > ~/notes.txt
# end the session and come back later — ~/notes.txt is still there

Caveat — region-bound #

CloudShell’s home is per region. A file you make in Seoul won’t show up in Tokyo’s CloudShell. Sticking to one region per use is natural.

Upload / download files #

CloudShell top-right menu → Actions → Upload / Download file. Small files via that, larger ones via S3.

aws s3 cp my-data.zip s3://my-temp-bucket/
# elsewhere:
aws s3 cp s3://my-temp-bucket/my-data.zip ./

IAM Identity Center (SSO) — what and why #

The name has shifted over time.

AWS Single Sign-On (AWS SSO)  →  IAM Identity Center
                              (the standard name since 2022)

Older posts / docs say “AWS SSO,” but it’s the same thing.

What it solves #

The limits of the IAM-user model from #2:

IAM Identity Center pulls all of this into one place.

[one employee]
  └── SSO portal (sign in once)
       ├── prod account / AdminAccess
       ├── prod account / ReadOnly
       ├── staging account / DeveloperAccess
       └── dev account / DeveloperAccess

Instead of creating IAM users in each account, SSO issues temporary credentials. Permanent unrotated keys go away.

Who uses it #

• Organizations multi-account — effectively the standard
• Teams of 5+ — cuts user / permission management overhead
• Free — no extra charge when used with Organizations

It’s slight overkill for solo learning / a single account. The moment a second account appears is when you set it up.

IAM Identity Center setup — five steps #

1) Activate Organizations #

IAM Identity Center runs on top of Organizations. Even with a single account, activating Organizations is free.

Console → AWS Organizations → "Create an organization"

2) Activate IAM Identity Center #

Console → IAM Identity Center → "Enable"

The activation region is hard to change later, so choose carefully. Usually your primary operations region (Seoul = ap-northeast-2).

3) Create users / groups #

Use the built-in directory (Identity store) or hook up an external IdP (Google Workspace, Microsoft Entra, Okta, etc.).

IAM Identity Center → Users → Add user
- Enter email / name
- Send invite email → set password + MFA

Admins
Developers
ReadOnly
Billing

4) Create Permission Sets #

A Permission Set is a bundle of #2-style policies, a session duration, and optional extras.

Session duration is usually 1–12 hours (default 1 hour). Short for prod (2 hrs), 8 hours for daily dev.

5) Account assignment — who + where + what #

IAM Identity Center → AWS accounts
- pick the account (e.g., prod)
- "Assign users or groups"
- Group: Developers + Permission Set: PowerUserDeveloperAccess

The three pieces meet here: group × account × Permission Set. The Developers group enters the prod account as PowerUser.

The SSO portal flow #

From the employee’s side:

1. Open the start URL (e.g., https://my-org.awsapps.com/start)
2. Password + MFA
3. See the list of accounts + Permission Sets assigned to you
4. Click “Management console” next to an item → auto-login to that account’s console
5. Click “Command line / programmatic access” → CLI credentials appear

SSO login from the CLI #

aws cli v2 natively supports SSO. Redo the #4 work, but via 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]:
# Browser opens → sign in → consent →
# 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

Result in ~/.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

Daily flow #

aws sso login --profile prod
# Browser opens → sign in → credential cached

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

Sessions are usually 8–12 hours. When it expires, aws sso login again.

Login to several accounts at once #

If multiple profiles share one my-org sso-session, a single aws sso login covers them all.

[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-user model vs SSO model #

When to pick what, in one table.

For CI/CD — IAM Identity Center doesn’t issue service credentials by itself, so GitHub Actions / GitLab borrows IAM Roles directly via OIDC (covered in Practice #3).

A realistic migration order #

If you’re already on IAM users and want to move to SSO:

1. Activate Organizations (free even with one account)
2. Activate IAM Identity Center + first users / groups / Permission Sets
3. Switch yourself to SSO first — 1–2 weeks running both
4. Invite the rest of the team
5. Disable Console access on the IAM users — force SSO
6. IAM-user access keys — move automation to OIDC / instance profiles, retire user access keys gradually
7. End state: every human on SSO, every machine on a Role

This usually rolls out over a month to a quarter.

CloudShell + SSO meeting #

When you’re logged into the console via SSO, opening CloudShell flows the SSO temporary credential into the shell. No credential plumbing — start working immediately.

aws sts get-caller-identity
# Arn: arn:aws:sts::123:assumed-role/AWSReservedSSO_AdministratorAccess_xxx/email@example.com
# (assumed-role — SSO temporary credential, not a permanent user)

The credentials auto-refresh here. Very handy for small inspections / one-off work.

Common pitfalls #

1) Traces of the old name “AWS SSO” #

Some materials / parts of the console still show the old name. Same service — don’t let it confuse you. The CLI’s aws configure sso follows the new name.

2) Picking the wrong activation region first #

IAM Identity Center’s activation region is very hard to change later. Usually your primary operations region or us-east-1. Korea-centric companies pick Seoul (ap-northeast-2).

3) Permission Set sessions too long or too short #

12 hours is risky on a credential leak; 1 hour means logging in every hour. 4–8 hours for daily dev and 1–2 hours for prod work is a common balance.

4) aws sso login browser auto-open fails #

Servers / containers / SSH environments. Use aws sso login --no-browser and you’ll get a URL + code to authenticate from another device.

5) CloudShell’s 1 GB ceiling #

Accumulating big data / temp builds in CloudShell hits the limit and breaks. Periodically clean up or move to S3.

6) IAM-user keys and SSO living side by side #

Mid-migration both are alive. Always verify which credential is active via the credential chain (#4) — aws sts get-caller-identity tells you immediately.

7) IAM policy limits inside a Permission Set #

A Permission Set ultimately becomes an IAM Role. Stuffing too many policies / inline policies into one Permission Set hits IAM Role policy size limits. Split when it’s too much.

Wrap-up #

What we covered:

• CloudShell — the in-browser terminal at the top right of the console. CLI / Python / git preinstalled, credentials automatic, 1 GB persistent home, free
• Per region, route big data via S3
• IAM Identity Center (formerly AWS SSO) — the standard login for multi-account / teams
• One login → temporary credentials across many accounts / Permission Sets
• Almost eliminates permanent access keys
• Setup — Organizations → Identity Center activation → users / groups → Permission Sets → account assignment
• CLI integration — aws configure sso + sso-session in ~/.aws/config, one aws sso login
• Migration — Organizations → SSO activation → switch yourself → team → disable IAM-user console → retire keys
• Pitfalls — old-name traces, hard-to-change activation region, balancing session duration, –no-browser, CloudShell ceiling, dual credentials during migration

Next — security basics #

Console / CLI / SSO setup is done. Now for one more pass at the security basics — MFA enforcement, access-key rotation, least-privilege patterns, and the incidents you’ll see in real life.

#6 Security basics — MFA, key rotation, least privilege layers production guardrails on top of #2 IAM policies.