CloudShell and IAM Identity Center (SSO)

You finished the local setup in Chapter 4 CLI and SDK. There are two more tools here. One is CloudShell, a browser terminal inside the console. Even without a laptop, even in a temporary environment, you can use the CLI instantly. The other is IAM Identity Center (SSO), the standard login for multi-account / team operations. It almost eliminates permanent access keys.

These two are slightly overkill for a small one-person learner, but they’re tools you naturally meet the moment a second account or a second teammate appears. Knowing them in advance makes the step over smoother.

This chapter is a topic that, on top of Chapter 4’s credential chain, refines the way people log in one step further. Multi-account governance itself is covered in earnest in Chapter 29 security governance.

CloudShell — a terminal inside the browser #

The small terminal icon at the top right of the console is AWS CloudShell. A shell that works right away while you’re logged in pops up.

What’s good about it #

• The CLI is pre-installed — aws, python (boto3 included), node, git.
• Credentials are automatic — the console login credentials are connected to the shell too, so aws configure is unnecessary.
• 1 GB persistent home directory — it persists even after you end the session.
• Free — within usage-time / output-traffic limits.

Where it’s good #

A quick try #

# Credentials are already connected
aws sts get-caller-identity

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

# the home directory is 1 GB persistent
echo "hello" > ~/notes.txt
# end the session and come back next time — ~/notes.txt is still alive

Caution — Region-bound #

CloudShell’s home directory is separate per Region. A file made in Seoul isn’t visible in the Tokyo CloudShell. So it’s natural to usually use it in one Region.

Uploading / downloading files #

Get files via the CloudShell top-right menu → Actions → Upload / Download file. Use this for small files, and use S3 for large ones.

aws s3 cp my-data.zip s3://my-temp-bucket/
# In another environment:
aws s3 cp s3://my-temp-bucket/my-data.zip ./

IAM Identity Center (SSO) — what it is and why use it #

This is a service whose name has changed several times.

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

In old posts or materials it often appears under the name “AWS SSO,” but it’s the same service.

What it solves #

The IAM user model we saw in Chapter 2 IAM has limits.

IAM Identity Center gathers this into one place.

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

Instead of creating IAM users inside each account, SSO issues temporary credentials. The permanent keys that need rotation disappear too.

Who uses it #

• Organizations multi-account — effectively the standard.
• A team of 5 or more — user / permission management is reduced.
• Free — used together with Organizations, there’s no extra cost.

It’s slightly overkill for one-person learning / a single account. The moment a second account appears is when this setup pays off.

IAM Identity Center setup — 5 steps #

1) Enable Organizations #

IAM Identity Center works on top of Organizations. Enabling Organizations is free even for a single account.

Console → AWS Organizations → "Create an organization"

2) Enable IAM Identity Center #

Console → IAM Identity Center → "Enable"

Once you pick a Region it’s hard to change, so do it carefully. Usually set it to the main operational Region (ap-northeast-2 for Seoul).

3) Create users / groups #

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

IAM Identity Center → Users → Add user
- enter email / name
- send an invitation email → password + MFA setup

Admins
Developers
ReadOnly
Billing

4) Create a Permission Set #

A Permission Set is a unit that adds session duration and extra options to Chapter 2 IAM’s policy bundle.

Session duration is usually 1 ~ 12 hours (1 hour by default). Set production short (2 hours), and 8 hours for day-to-day development.

5) Account Assignment — who + where + what #

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

The form these three come together in is group × account × Permission Set. The Developers group enters the prod account as PowerUser.

The SSO portal usage flow #

From the employee’s side, the flow is as follows.

1. Access the start URL (e.g., https://my-org.awsapps.com/start).
2. Enter the password and MFA.
3. The list of accounts + Permission Sets assigned to you appears.
4. Click “Management console” next to each item to auto-log in to that account’s console.
5. Click “Command line / programmatic access” to receive CLI credential material.

SSO login from the CLI #

aws cli v2 supports SSO natively. Redo what you did in Chapter 4 CLI and SDK with 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]:
# the browser opens and you log 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

After setup, it goes into ~/.aws/config like this.

[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

Day-to-day flow #

aws sso login --profile prod
# browser opens → log in → credentials cached

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

The session is usually 8 ~ 12 hours. When it expires, do aws sso login again.

Logging in to multiple accounts at once #

Bundle multiple profiles under one sso-session named my-org and one aws sso login logs you into all of them.

[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

The IAM user model vs the SSO model #

See in one table when to use what.

For CI/CD, IAM Identity Center doesn’t grant its own service credentials. So the standard pattern is GitHub Actions or GitLab borrowing an IAM Role directly via OIDC (covered in Chapter 24 CI/CD pipeline).

A realistic migration order #

The order for moving to SSO in an environment already using IAM users.

1. Enable Organizations (free even for a single account)
2. Enable IAM Identity Center + a first user / group / Permission Set
3. Switch yourself to SSO first — run in parallel for 1 ~ 2 weeks
4. Invite teammates to SSO
5. Disable Console access on IAM users — force SSO
6. IAM user access keys — move automation to OIDC / instance profiles, and phase out user access keys gradually
7. Result: everyone uses SSO, every machine uses a role

This order proceeds naturally over a month ~ a quarter.

CloudShell + SSO together #

Once you’re logged in to the console with SSO, opening CloudShell in that environment connects the SSO temporary credentials to the shell. Work right away without handling credentials.

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

In this environment, the temporary credentials are refreshed automatically. It’s convenient for a small check or one-off work.

Common pitfalls #

• Traces of the old name “AWS SSO” — the old name appears in materials or parts of the console. It’s the same service, so don’t be confused. The CLI’s aws configure sso follows the new name.
• Picking the wrong activation Region the first time — IAM Identity Center is very hard to change the activation Region later. It’s usually either the main operational Region or us-east-1. If the company is Korea-centric, it’s Seoul (ap-northeast-2).
• A Permission Set session too long or too short — 12 hours is too long and risky if exposed; 1 hour is too short and you log in every hour. 4 ~ 8 hours for day-to-day development and 1 ~ 2 hours for production work are common.
• aws sso login’s browser not auto-opening — a server / container / SSH environment. Then use aws sso login --no-browser to print a URL and code, and open it on another device to authenticate.
• CloudShell’s 1 GB limit — accumulate large data or a temporary build inside CloudShell and operations are denied for exceeding the limit. Clean up regularly or move to S3.
• An IAM user access key and SSO at the same time — in an environment being switched over, both are alive. Always check which credential is running with Chapter 4’s credential chain. aws sts get-caller-identity is the answer.
• The IAM policy limit inside a Permission Set — a Permission Set ultimately creates and bundles an IAM Role. Put too many policies or inline policies in one Permission Set and you hit the IAM Role policy limit. If it gets too large, split it.

Exercises #

1. Based on the §“Where it’s good” table, classify three things you recently worked on by whether they’re better done in CloudShell or local, and write the reason for each in one sentence.
2. Without looking, write the §“IAM Identity Center setup — 5 steps” in order. Connect which element of Chapter 2 IAM (user · group · policy) each step corresponds to.
3. Based on the CI/CD row in the §“The IAM user model vs the SSO model” table, explain in one paragraph, connecting to Chapter 24 CI/CD pipeline, why GitHub Actions uses OIDC + Role instead of a permanent access key.

In short: CloudShell is a free in-console browser terminal with auto-connected credentials and a 1 GB persistent home, separate per Region. IAM Identity Center is the standard for multi-account / team login: log in once and it issues temporary credentials to multiple accounts, almost eliminating permanent access keys. People on SSO and machines on Roles is the end state of the migration.

Next chapter #

Setup of the console, the CLI, and SSO is done. In the next Chapter 6 security basics, we firm up security fundamentals once more. Enforcing MFA, access-key rotation, least-privilege patterns, and common incident cases — on top of Chapter 2 IAM’s policies, we sort out security guardrails that hold up in operations.