How to use AWS CLI environment variables

AWS CLI environment variables are useful when one shell or one command must use a different profile, Region, or credential set without editing the shared files under ~/.aws. That keeps short-lived admin work, CI jobs, and cross-account checks from silently reusing the wrong defaults.

The CLI resolves settings from more than one layer. Current AWS documentation puts command-line parameters above environment variables and environment variables above profile settings in the config and credentials files. In practice, AWS_PROFILE selects a saved profile, AWS_REGION overrides AWS_DEFAULT_REGION and the profile's region setting, raw credential variables override file-backed credentials, and AWS_CONFIG_FILE plus AWS_SHARED_CREDENTIALS_FILE move the lookup to different files.

Environment variables are inherited by child processes, so an exported value can leak into later tabs, automation, or shared terminals if it is left in place. When only one request needs the override, prefix that single command with the variable assignment instead of exporting it for the whole shell. For shell-wide overrides, use export deliberately and clear the variables with unset when the work is finished.

Steps to use AWS CLI environment variables:

Check which profile, credential source, and Region the shell is using before adding any override.

$ aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************ABCD     : shared-credentials-file :
secret_key : ****************WXYZ     : shared-credentials-file :
region     : ap-southeast-1           : config-file      : ~/.aws/config

Use this baseline again after each change to confirm whether the active value came from a profile, an environment variable, or a command-line option.

Prefix a command with AWS_PROFILE when one request should use a named profile instead of the shell default.

$ AWS_PROFILE=audit aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : audit                    : env              : ['AWS_PROFILE', 'AWS_DEFAULT_PROFILE']
access_key : ****************E001     : shared-credentials-file :
secret_key : ****************0001     : shared-credentials-file :
region     : eu-west-1                : config-file      : ~/.aws/config

If several consecutive commands should use the same profile, run export AWS_PROFILE=audit once and unset AWS_PROFILE when that shell should return to its previous default.

Add AWS_REGION or AWS_DEFAULT_REGION when the command should go to a different Region than the saved profile default.

$ AWS_PROFILE=audit AWS_REGION=us-west-2 aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : audit                    : env              : ['AWS_PROFILE', 'AWS_DEFAULT_PROFILE']
access_key : ****************E001     : shared-credentials-file :
secret_key : ****************0001     : shared-credentials-file :
region     : us-west-2                : env              : ['AWS_REGION', 'AWS_DEFAULT_REGION']

AWS_REGION wins over AWS_DEFAULT_REGION in AWS CLI v2, and --region overrides both for that one request.

Set raw credential variables when the command must use temporary credentials from STS or another external handoff instead of a saved profile.

$ AWS_ACCESS_KEY_ID=ASIAEXAMPLEENV0001 \
  AWS_SECRET_ACCESS_KEY=envSecretExample000000000000000000000001 \
  AWS_SESSION_TOKEN=sessionTokenExampleValue0000001 \
  aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************0001     : env              :
secret_key : ****************0001     : env              :
region     : ap-southeast-1           : config-file      : ~/.aws/config

Raw credential variables override AWS_PROFILE and file-backed credentials until they are unset. aws configure list does not display the session token, so temporary credentials still need AWS_SESSION_TOKEN even though only the access key and secret key appear here.

Set AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE when the command should read a different config and credentials pair.

$ AWS_CONFIG_FILE=/opt/aws-session/config \
  AWS_SHARED_CREDENTIALS_FILE=/opt/aws-session/credentials \
  AWS_PROFILE=audit \
  aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : audit                    : env              : ['AWS_PROFILE', 'AWS_DEFAULT_PROFILE']
access_key : ****************E001     : shared-credentials-file :
secret_key : ****************0001     : shared-credentials-file :
region     : eu-west-1                : config-file      : /opt/aws-session/config

This is safer for task-local automation, CI jobs, or customer-specific sessions than overwriting the normal files under ~/.aws.

Unset the variables after shell-wide testing so later commands fall back to the expected profile or files.
```
$ unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE AWS_REGION AWS_DEFAULT_REGION AWS_CONFIG_FILE AWS_SHARED_CREDENTIALS_FILE
```
One-command prefixes disappear automatically when the command exits. Use unset only for values you exported into the current shell.

Run the baseline check again and confirm the shell is back on the expected default source.

$ aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************ABCD     : shared-credentials-file :
secret_key : ****************WXYZ     : shared-credentials-file :
region     : ap-southeast-1           : config-file      : ~/.aws/config

The returned values should match the normal default profile or the profile selected by your shell startup files. If they do not, another exported variable or command-line wrapper is still overriding the session.