Lab: a developer sandbox that cannot surprise you

Step 1: protect the root user

The root user is the email address you signed up with. It can do anything, including closing the account, and no policy in the account can limit it.

1. Sign in to the console as the root user.
2. Choose your account name at the top right, then Security credentials.
3. In the Multi-factor authentication (MFA) section, choose Assign MFA device and follow the prompts. A passkey or security key resists phishing best; an authenticator app is fine. AWS now requires MFA for the root user on every account type, so you may have been asked at sign-up.
4. On the same page, check Access keys. If any exist, delete them. The root user should never have access keys.
5. While still signed in as root, choose your account name, then Account. Find IAM User and Role Access to Billing Information, choose Edit, select Activate IAM Access and choose Update. Without this, the identity you create next cannot see billing or budgets.

What you will see: your MFA device listed, and no root access keys.

Step 2: an everyday admin identity

You need an identity that is not root for everything else. Pick A or B by your account’s plan.

Watch out: enabling IAM Identity Center on an account that is not in an organization creates one. AWS’s Identity Center guide says that on a free-tier account this upgrades the account to the paid plan and the free tier credits expire immediately. A standalone account can instead enable an account instance, which creates no organization, but AWS lists multi-account permissions and the access portal for AWS accounts as unavailable there, so it cannot give you the CLI sign-in this lab needs. On the free plan, use B.

A: IAM Identity Center (paid plan)

IAM Identity Center gives you a sign-in page called the AWS access portal and short-lived credentials through a permission set: a named bundle of permissions that becomes a role in the account.

1. Open IAM Identity Center and choose Enable. Choose the option that enables it with AWS Organizations. If asked, choose a single-Region instance.
2. Under Users, add a user for yourself and choose to send an email with password set-up instructions.
3. Under Permission sets, create one from the predefined AdministratorAccess policy.
4. Under AWS accounts, select your account, choose Assign users or groups, and assign your user with that permission set.
5. Accept the invitation email, set a password and register MFA.
6. Copy the AWS access portal URL from the Identity Center dashboard.

B: an IAM user with MFA (free plan)

1. Open IAM, choose Users, then Create user.
2. Name it study-admin and give it access to the AWS Management Console. If asked what kind of user, choose an IAM user.
3. Set a password, and on the permissions page add the user to a new group named Admins with the AdministratorAccess policy.
4. Create the user and copy the console sign-in URL it shows.
5. Open the user’s Security credentials tab and assign an MFA device.
6. Do not create an access key. Step 4 signs the CLI in without one.

What you will see: you can sign in as your new identity, and the top bar shows its name. Sign out of root and use this identity from now on.

AdministratorAccess is a reasonable choice in a personal sandbox where you build everything yourself. In real accounts, grant only what each job needs; module 2 shows how.

Step 3: a budget that warns you

Signed in with your new identity:

1. Open Billing and Cost Management, choose Budgets, then Create budget.
2. Choose Use a template (simplified), then Monthly cost budget.
3. Name it dva-monthly, enter an amount you are comfortable with (a few US dollars is plenty for this course) and your email address, and choose Create budget.

What you will see: dva-monthly in the budget list. The template alerts on both actual spend and forecasted spend. A budget only sends email; it never stops or deletes anything, so act on an alert when one arrives.

Step 4: sign the CLI in without access keys

An access key is a long-lived secret pair for an IAM user. It works until someone deletes it, so a key copied into a script, a laptop backup or a Git commit stays dangerous for years. This course never creates one. Pick the route that matches where you work.

In AWS CloudShell

Choose the CloudShell icon in the console’s top bar. CloudShell is already signed in as you, with credentials that come from your console session, and it has the AWS CLI, Python, boto3 and the SAM CLI installed. Skip to step 5.

On your own machine, with an IAM user (path B): aws login

aws login turns a console sign-in into short-lived CLI credentials.

aws --version            # must be aws-cli/2.32.0 or newer
aws login --profile sandbox

1. If the profile is new, the CLI asks for a Region. Press Enter for us-east-1, or type the Region you want to use for the course.
2. A browser opens. Choose your study-admin console session, or sign in with your user name, password and MFA code.
3. Back in the terminal, a message confirms the profile is configured.

The CLI writes a login_session line for the profile into ~/.aws/config and caches the credentials under ~/.aws/login/cache. They refresh about every 15 minutes, for up to 12 hours (or your identity’s shorter session limit). After that, run aws login --profile sandbox again. On a machine with no browser, aws login --remote prints a URL to open on another device and asks you to paste back the code it shows.

What changed recently (November 2025): the AWS CLI 2.32.0 added aws login, which lets you sign in with your console credentials instead of creating access keys. An IAM identity that is not an administrator needs the AWS managed policy SignInLocalDevelopmentAccess. Sources: What’s New post, CLI user guide.

On your own machine, with Identity Center (path A): aws sso login

The CLI guide sends Identity Center users to aws configure sso instead:

aws configure sso
# SSO session name: sandbox
# SSO start URL: <your AWS access portal URL>
# SSO region: <the Region where you enabled Identity Center>
# SSO registration scopes: press Enter for the default
# Pick your account and the AdministratorAccess role,
# then a default Region, json output, and profile name: sandbox
aws sso login --profile sandbox

When the session expires, run aws sso login --profile sandbox again.

Make the profile the default for this terminal

So you do not have to type --profile on every command:

export AWS_PROFILE=sandbox        # PowerShell: $env:AWS_PROFILE = "sandbox"

Skip this in CloudShell, which has no sandbox profile and does not need one.

Step 5: prove who you are, from the CLI and from Python

aws sts get-caller-identity
aws configure list

get-caller-identity needs no permissions and always answers, which makes it the first thing to run when you are unsure which credentials are in use. The Arn tells you who AWS thinks you are:

aws configure list shows the profile, the Region and, in its type column, where the credentials came from. AWS’s guide does not spell out the exact Arn that aws login reports for a console session, so what matters is that it names you and not the root user.

Now do the same from Python. Create a virtual environment so the course’s packages stay separate from everything else, and install boto3 with its crt extra, which boto3 needs to read aws login credentials:

python3 -m venv .venv
source .venv/bin/activate         # Windows: .venv\Scripts\activate
python -m pip install --upgrade "boto3[crt]"

In CloudShell, boto3 is already installed; you can skip the virtual environment.

Save this as whoami.py:

import boto3

session = boto3.Session()          # uses AWS_PROFILE, or CloudShell's own credentials
identity = session.client("sts").get_caller_identity()
creds = session.get_credentials()

print("Account:", identity["Account"])
print("ARN:    ", identity["Arn"])
print("Region: ", session.region_name)
print("Source: ", creds.method)

python whoami.py

What you will see: the same account and ARN as the CLI printed, your Region, and a Source line naming the credential provider boto3 used: login after aws login, sso after aws sso login. In CloudShell it names a different provider, because CloudShell supplies credentials to the shell itself. boto3 and the CLI read the same ~/.aws/config, so one sign-in serves both.

If boto3 stops with a message asking you to install botocore[crt], the extra is missing: rerun the pip install line above inside the virtual environment.

Step 6: check the AWS SAM CLI

The AWS Serverless Application Model (SAM) CLI builds, tests and deploys Lambda applications. You use it from module 4.

sam --version

You should see SAM CLI, followed by a version number. CloudShell has it already. If your machine says the command is not found, install it from the AWS SAM CLI install guide: the .pkg installer on macOS, the .msi on Windows, or the .zip and its install script on Linux, then open a new terminal and run sam --version again. Docker is only needed later, for sam local commands that run a function on your machine.

aws logout --profile sandbox      # path B; path A uses: aws sso logout