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

Part 1127 of AWS from Zero.

What we are learning

AWS CLI configuration manages no cloud resources, so its operating model looks different from a normal service. But every boundary in this lesson's title still exists; it just lives on your machine and shapes what every other command does.

Regional behavior: a profile stores a default Region, and the CLI resolves the effective Region by precedence: the --region command-line option wins, followed by AWS_REGION, then AWS_DEFAULT_REGION, and finally the profile's region setting in the config file. The Region you think you set and the Region a command actually uses can differ, and aws configure list is the tool that shows which source won.

Endpoint selection: the CLI derives each service endpoint from the resolved Region. You can override it for one command with --endpoint-url; a global endpoint_url setting or AWS_ENDPOINT_URL redirects requests for all services, while a service-specific endpoint setting redirects only that service. These persistent overrides silently change later requests in their scope, which is exactly why they belong in a named sandbox profile rather than in default.

IAM: the local get, set, and list-profiles operations have no IAM actions. Credential-resolving operations such as configure list can cause an expired role profile to call AWS STS AssumeRole, or cause another temporary-credential provider to refresh. The flip side matters more: the credentials a profile resolves decide what every later service command may do. Least privilege is enforced by that principal, not by the configuration file, so pointing a powerful principal at the wrong profile is a local mistake with account-wide consequences.

Quotas and pricing: there are no service quotas and no charges for configuration itself. The cost risk is indirect. A wrong default Region creates resources somewhere you are not looking, and a wrong profile creates them in the wrong account. Both failure modes are cheaper to prevent than to find on an invoice, which is why this series always starts labs by proving identity and Region.

Tagging: profiles cannot be tagged; the equivalent hygiene is naming. Profile names like aws-zero-sandbox encode intent the way tags do on real resources.

Cleanup model: configuration cleanup is local and dependency-aware in a small way. Remove a profile's section from the config and credentials files only after nothing references it: shell exports, scripts, and scheduled jobs are the dependents here. Local file reads reflect saved changes immediately; there is no service-side eventual-consistency window to wait through.

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 the authenticated sandbox profile from the previous lesson. The list-profiles and get commands used below need no IAM permissions and make no service request; the identity call requires valid credentials but AWS documents that the operation itself needs no permission. Treat the config and credentials files as sensitive material even in a sandbox.

Cost note: the configuration inspections are local and free. aws sts get-caller-identity has no charge, and nothing here creates a billable resource.

The command

aws configure list-profiles

This prints every profile name defined across the config and credentials files, one per line, with no values and no secrets. It is the inventory command for the boundary that matters most in this lesson: how many identities and Region defaults this machine can silently switch between.

Inspect the result

aws configure get profile."$AWS_PROFILE".region
echo $?

The qualified name profile.<name>.<setting> reads a specific profile's setting regardless of which profile is currently active. Success is a printed Region value and exit code 0. If the profile section exists but has no region key, you get empty output and exit code 1, which tells you that profile is currently inheriting its Region from the environment or defaulting at call time.

One tiny variation

aws configure get default.region
echo $?

Only the section changed: default. targets the default profile explicitly instead of the sandbox profile. On a machine where you have never configured a default profile, the empty output and exit code 1 are a healthy result, and they demonstrate the difference between "the CLI has a Region right now" and "this specific file section stores a Region".

Common mistake

Assuming aws configure set validates what you give it. It does not: setting a mistyped access key, a Region that does not exist, or credentials for a deleted principal succeeds instantly, because the write is local. The failure appears later, at the first real API call, as an error such as InvalidClientTokenId from STS or a connection failure to a nonexistent regional endpoint. Diagnose from the evidence order: the configure write exited 0, the API call failed, so the stored value, not the network, is the suspect. Re-read it with aws configure get before touching anything else.

Cleanup

aws configure list-profiles

This lesson wrote nothing, so cleanup is a final inventory: the profile list should be identical to the first run. When you eventually retire a sandbox profile, remove its sections from both files only after removing every reference to it, then rerun aws configure list-profiles to prove the empty state.

Where this goes later

Next: AWS CLI configuration: Get with the AWS CLI.