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

Part 1126 of AWS from Zero.

What we are learning

Every AWS CLI command needs three things resolved before it can do anything: an identity to sign the request with, a Region to send it to, and output preferences for the response. The aws configure command group is how the CLI reads and writes those settings without you hand-editing files. 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 any working profile, even an empty sandbox one. The configure subcommands themselves require no IAM permissions because they only touch local files; the identity check is the one network call here, and it works for any authenticated principal. Data sensitivity is the real concern: ~/.aws/credentials holds secrets, so never paste its contents into terminals you record, tickets, or screenshots.

Cost note: everything in this lesson is read-only and free. The configure subcommands operate on local files and create no AWS resources, and aws sts get-caller-identity has no charge.

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 local files. The final inventory above should match the first run exactly, which is your proof that discovery was truly read-only.

Where this goes later

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