AWS CLI configuration from zero: purpose, boundaries, and first CLI inventory

Part 1126 of AWS from Zero.

What we are learning

Most AWS service commands need the CLI to resolve an identity for request signing, often a Region, and an output format. The aws configure command group reads and writes the local settings that participate in that resolution. It manages two plaintext files: ~/.aws/config for settings such as region and output, and ~/.aws/credentials for access keys. Both files are divided into named profiles, and the CLI uses the default profile unless you select another one.

It helps to name the planes precisely, even though this is a local feature. The control plane is the pair of files on your machine plus the configure subcommands that read and write them. The data plane is every later AWS API call, because each one consumes the resolved settings. A one-character mistake in the control plane, such as a wrong Region value, silently redirects the entire data plane.

Be equally clear about what AWS CLI configuration is not. It is not an AWS service: nothing under aws configure creates, changes, or bills for cloud resources, and there is no ARN for a profile. It is also not a general secret store. Long-term access keys in ~/.aws/credentials are the fallback option; identity-center-based sign-in through aws configure sso produces short-lived credentials and is the safer default for human users.

The pinned AWS CLI 2.36.1 reference lists these subcommands: add-model, agent-toolkit, export-credentials, get, import, list, list-profiles, mfa-login, set, sso, and sso-session. Version drift note: the installed 2.31.14 used to draft this lesson does not yet include agent-toolkit, so treat that subcommand as present only in newer releases.

Before you run it

export AWS_PROFILE="aws-zero-sandbox"
export AWS_REGION="ap-south-1"
aws sts get-caller-identity
aws configure get region

You need an authenticated sandbox profile; an empty profile is not enough for the caller-identity check. The two inventory commands taught here, configure list and configure list-profiles, have no IAM action of their own. list-profiles is entirely local. configure list resolves credentials, so a role, IAM Identity Center, login, or credential-process profile can contact its provider when cached credentials need refreshing. The identity check is also a network call, although AWS documents that sts:GetCallerIdentity requires no permission. Data sensitivity is the real concern: ~/.aws/credentials holds secrets, so never paste its contents into terminals you record, tickets, or screenshots. These local inventories have no service quota, regional availability constraint, or eventual-consistency delay.

Cost note: everything in this lesson is read-only and has no direct AWS charge. The inventory commands create no AWS resources, and aws sts get-caller-identity has no charge. A temporary-credential profile can still make an authentication or STS refresh request while credentials are resolved.

The command

aws configure list

This is the safest possible first inventory of your CLI configuration. It prints one row per resolved setting: the profile in use, the access key, the secret key, and the Region. Each row has four columns: Name, Value, Type, and Location. Type and Location answer the question people usually cannot answer about their own machine: not just what value the CLI will use, but where it came from. Secrets are masked in the output; only the last four characters of the access key and secret key are shown.

Inspect the result

aws configure list-profiles

Read the two outputs together. In the aws configure list table, confirm the profile row shows aws-zero-sandbox, and that the region row shows ap-south-1 with type env, because we exported AWS_REGION. Credential rows sourced from files show a type such as shared-credentials-file. Then aws configure list-profiles prints every profile name defined in your config and credentials files, which proves the sandbox profile actually exists as a section rather than only as an environment variable pointing at nothing.

One tiny variation

aws configure list --profile "$AWS_PROFILE"

This resolves the same table for an explicitly named profile instead of relying on the AWS_PROFILE environment variable. The columns and rows are identical; the only thing that changed is how the profile was selected, which now appears in the profile row as type manual with location --profile. Explicit selection is the pattern you will prefer in scripts, where inherited environment variables are a source of surprises.

Common mistake

Expecting aws configure get region to reflect the exported AWS_REGION variable. The get subcommand reads only the config file; it never resolves environment variables or command-line options. If the active profile has no region key in ~/.aws/config, the command prints nothing and exits with code 1, even while aws configure list happily shows a Region sourced from env. The evidence pair to check is the empty output plus echo $? returning 1. Use aws configure list to see effective values, and aws configure get to see file contents.

Cleanup

aws configure list

Nothing to remove: this lesson created no AWS resources and wrote no configuration files. The final inventory should show the same profile and Region sources as the first run. Cached temporary credential values can rotate during a refresh, so byte-for-byte identical masked key suffixes are not required for a successful final check.

Where this goes later

Next: AWS CLI configuration: Regions, endpoints, IAM, quotas, pricing, and cleanup model.