Lab: a sandbox account that cannot surprise you

What you will build

The finished account has a root user with MFA and no access keys, an Identity Center user whose CLI commands run in a temporary role session under the sandbox profile, and a monthly budget that alerts you before the course’s labs can cost much. The diagram shows that result.

Step 1: protect the root user with MFA

The root user is the sign-in you created with the account’s email address. It has full access to the account. AWS requires MFA for the root user in every account type, and you must register MFA within 35 days of your first sign-in if it is not already set up.

1. Sign in to the console as the root user.
2. Choose your account name at the top right, then choose Security credentials.
3. In the Multi-factor authentication (MFA) section, choose Assign MFA device. Give the device a name. AWS recommends a passkey or security key, because they resist phishing better. An authenticator app works too.
4. On the same page, look at the Access keys section. If the root user has any access keys, delete them.
5. Sign out.

What you will see: the MFA section lists one device, and the root user’s access keys section is empty.

Watch out: Access keys for the root user can do anything in the account, and the course does not need them. If you find one you did not create, delete it at once.

Step 2: enable IAM Identity Center and create an everyday identity

Use the root user only for this step, then sign in with your Identity Center user from now on.

1. Open the IAM Identity Center console and choose Enable. Choose the organization instance, which is the recommended option. If the account is not in an organization, AWS creates one with this account as its management account (see the cost note above). If the console asks for an instance configuration, choose Single-Region instance. An organization instance is what lets you create permission sets: AWS’s comparison of the two instance types lists multi-account permissions for it and not for an account instance.
2. Under Users, add a user for yourself. Accept the invitation email, and set up MFA for this user when prompted.
3. Create a permission set from the predefined AdministratorAccess policy. In a sandbox, broad rights let you build the labs. In a real account you would scope the permission set down to what each job needs.
4. Assign your user to this account with that permission set.
5. Copy the AWS access portal URL from the Identity Center dashboard. You need it in the next step.

What you will see: the sandbox account listed under AWS accounts with your permission set assigned.

Step 3: connect the CLI with the sandbox profile

Tip: The Solutions Architect – Associate course has a sandbox lab that also creates a profile named sandbox. If you did that lab in this same account, you already have the profile: check it with aws sts get-caller-identity --profile sandbox and skip the wizard. If this course uses a different account, give this profile another name, such as cloudops, and use that name wherever the labs say sandbox.

Run the wizard, and answer each prompt as shown:

aws configure sso
# SSO session name (Recommended): sandbox
# SSO start URL: <the AWS access portal URL from Step 2>
# SSO region: <the Region where you enabled Identity Center>
# SSO registration scopes: sso:account:access
# Then sign in in the browser, choose this account and AdministratorAccess,
# Default client Region: us-east-1
# CLI default output format: json
# Profile name: sandbox

Sign in and check who you are:

aws sso login --profile sandbox
export AWS_PROFILE=sandbox
export AWS_REGION=${AWS_REGION:-us-east-1}
aws sts get-caller-identity

What you will see: three fields, UserId, Account and Arn. The Arn names an assumed role whose name starts with AWSReservedSSO_, followed by the permission set name. IAM Identity Center creates those roles in each account when you assign a permission set. The credentials are temporary, so when a later command fails with an expired-credentials error, run aws sso login --profile sandbox again.

Step 4: check your identity in CloudShell

1. Sign in to the console for the sandbox account, and choose the CloudShell icon on the navigation bar.
2. Wait for the shell prompt, then run:

aws sts get-caller-identity

What you will see: the same Account and the same Arn as in Step 3. CloudShell uses the credentials of the console sign-in, so you do not configure a profile there. It is available at no additional charge, and it keeps up to 1 GB of files in your home folder for each Region.

Tip: If CloudShell shows a root user ARN, you signed in as the root user. Sign out, then sign in through the AWS access portal as your Identity Center user, and check again.

Step 5: create a budget with alerts

Set the variables for this step. Replace the placeholder address with your own:

export AWS_PROFILE=sandbox
export AWS_REGION=${AWS_REGION:-us-east-1}
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
ALERT_EMAIL="you@example.com"   # replace with your address

Write the budget. The limit of 10 USD is an example; choose a monthly limit you are comfortable with:

cat > budget.json <<'EOF'
{
  "BudgetName": "cloudops-sandbox-monthly",
  "BudgetLimit": { "Amount": "10", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
EOF

cat > notifications.json <<EOF
[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "${ALERT_EMAIL}" }]
  },
  {
    "Notification": {
      "NotificationType": "FORECASTED",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 100,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "${ALERT_EMAIL}" }]
  }
]
EOF

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

aws budgets describe-budgets --account-id "$ACCOUNT_ID" \
  --query 'Budgets[].[BudgetName,BudgetLimit.Amount,TimeUnit]' --output table

The first alert fires when actual spend is more than 80% of the limit. The second fires when AWS forecasts that month-end spend will be more than 100% of it.

Confirm the email address. AWS sends a verification email to each new recipient, and it sends no budget notification to an address until that address is verified. Open the email from AWS and choose the link while you are signed in to this account. The link expires after 12 hours, and you can send a new one from the budget’s page. In the console, open Budgets in the Billing and Cost Management console, open your budget, and check that the recipient shows Active rather than Pending.

Watch out: If the Budgets page tells your role it has no access, the root user must activate IAM access to the Billing and Cost Management console. AWS lists that as one of the few tasks that require root. Sign in as root once to do it, then return to your Identity Center user.

Step 6: check the root user from the CLI

aws iam get-account-summary \
  --query 'SummaryMap.[AccountMFAEnabled,AccountAccessKeysPresent]' --output text

What you will see: two numbers separated by a tab. The first is AccountMFAEnabled, which should be 1, and the second is AccountAccessKeysPresent, which should be 0. If the second number is 1, return to Step 1 and delete the root access keys.

AWS’s GetAccountSummary reference lists both keys but does not define them. The AWS Security Blog describes AccountAccessKeysPresent as showing whether the root user has an access key (1 means one exists, even if it is inactive). For AccountMFAEnabled, the AWS Config managed rule root-account-mfa-enabled is the documented check that the root user has MFA, so treat this number as a quick confirmation and trust the Multi-factor authentication (MFA) section of the Security credentials page from Step 1 as the record.

rm -f budget.json notifications.json

aws budgets delete-budget --account-id "$ACCOUNT_ID" --budget-name cloudops-sandbox-monthly
aws sso logout