Introduction

The best way to determine the current AWS CLI region is aws configure get region. This returns the effective region for your active profile without making any API calls. If you need to understand where the value comes from (environment variable, config file, or instance metadata), use aws configure list, which shows the source of each configuration setting. This guide covers every method for checking and setting the region, the precedence order AWS CLI follows, and the traps that cause commands to hit the wrong region.

Quick Answer

1# Get the effective region for the current profile
2aws configure get region
3
4# Get the region for a named profile
5aws configure get region --profile production
6
7# See where each setting comes from
8aws configure list

Output of aws configure list:

1      Name                    Value             Type    Location
2      ----                    -----             ----    --------
3   profile                <not set>             None    None
4access_key     ****************ABCD shared-credentials-file
5secret_key     ****************EFGH shared-credentials-file
6    region                us-west-2      config-file    ~/.aws/config

The "Type" and "Location" columns tell you exactly where the region value is coming from, which is essential for debugging unexpected behavior.

Region Precedence Order

AWS CLI resolves the region using this precedence (highest to lowest):

Note that AWS_REGION and AWS_DEFAULT_REGION are both valid, but AWS_DEFAULT_REGION takes precedence when both are set. The AWS SDKs (Python boto3, JavaScript SDK, etc.) may use AWS_REGION, which is why both exist.

Method 1: aws configure get region

The simplest and most portable check:

aws configure get region

This returns the effective region after applying the precedence rules. If no region is configured anywhere, the command produces no output and exits with code 0, which can be misleading in scripts.

To handle the no-region case in a script:

1REGION=$(aws configure get region)
2if [ -z "$REGION" ]; then
3    echo "No region configured. Set AWS_DEFAULT_REGION or run 'aws configure'."
4    exit 1
5fi
6echo "Current region: $REGION"

Method 2: aws configure list

For debugging, aws configure list shows the source of every configuration value:

aws configure list

This tells you whether the region came from an environment variable, the config file, or was not set at all. When a command is hitting the wrong region, this is the first diagnostic to run.

For a specific profile:

aws configure list --profile staging

Method 3: Environment Variable Check

You can inspect the environment variables directly:

echo $AWS_DEFAULT_REGION
echo $AWS_REGION

This is useful for verifying what a CI/CD pipeline or Docker container has set, independent of config files.

Method 4: Config File Inspection

The config file at ~/.aws/config stores per-profile settings:

1[default]
2region = us-east-1
3output = json
4
5[profile production]
6region = eu-west-1
7output = json
8
9[profile staging]
10region = us-west-2

To read this programmatically without parsing the INI file manually:

1# Default profile region
2aws configure get region
3
4# Named profile region
5aws configure get region --profile production

Method 5: EC2 Instance Metadata (IMDS)

On EC2 instances, the region can be derived from the instance metadata service. This is the lowest-precedence source, used only when no other configuration is present.

IMDSv2 (recommended):

1TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
2  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
3
4curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
5  http://169.254.169.254/latest/meta-data/placement/region

IMDSv1 (deprecated but still common):

curl -s http://169.254.169.254/latest/meta-data/placement/region

You can also extract it from the instance identity document:

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/dynamic/instance-identity/document | \
  python3 -c "import sys,json; print(json.load(sys.stdin)['region'])"

Setting the Region

Per-Command

aws s3 ls --region ap-southeast-1

Per-Session (Environment Variable)

export AWS_DEFAULT_REGION=ap-southeast-1
aws s3 ls  # uses ap-southeast-1

Permanent (Config File)

1# Interactive setup
2aws configure
3
4# Non-interactive, set region for default profile
5aws configure set region ap-southeast-1
6
7# Set region for a named profile
8aws configure set region eu-central-1 --profile production

Scripting Patterns

Get Region with Fallback

1get_aws_region() {
2    local region
3    region=$(aws configure get region 2>/dev/null)
4    if [ -z "$region" ]; then
5        # Try EC2 metadata as fallback
6        local token
7        token=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
8          -H "X-aws-ec2-metadata-token-ttl-seconds: 60" 2>/dev/null)
9        region=$(curl -s -H "X-aws-ec2-metadata-token: $token" \
10          http://169.254.169.254/latest/meta-data/placement/region 2>/dev/null)
11    fi
12    echo "${region:-us-east-1}"  # final fallback
13}
14
15REGION=$(get_aws_region)
16echo "Using region: $REGION"

Validate Region Before Operations

1# Check that the region is valid before proceeding
2REGION=$(aws configure get region)
3VALID_REGIONS=$(aws ec2 describe-regions --query "Regions[].RegionName" --output text)
4
5if echo "$VALID_REGIONS" | grep -qw "$REGION"; then
6    echo "Region $REGION is valid"
7else
8    echo "Region $REGION is not a valid AWS region"
9    exit 1
10fi

Docker and CI/CD

In containers and CI pipelines, always set the region explicitly via environment variable rather than relying on config files:

ENV AWS_DEFAULT_REGION=us-east-1

# GitHub Actions
env:
  AWS_DEFAULT_REGION: us-east-1

# GitLab CI
variables:
  AWS_DEFAULT_REGION: us-east-1

This makes the region visible in the pipeline configuration and avoids depending on config files that may or may not exist in the container image.

Troubleshooting Region Issues

When commands hit the wrong region, run through this diagnostic sequence:

1# 1. What region is the CLI actually using?
2aws configure list
3
4# 2. Are environment variables overriding the config file?
5env | grep AWS_REGION
6env | grep AWS_DEFAULT_REGION
7
8# 3. What does the config file say?
9aws configure get region
10aws configure get region --profile "$AWS_PROFILE"
11
12# 4. Is a different profile active?
13echo $AWS_PROFILE

A common scenario: you set the region in ~/.aws/config for the default profile, but AWS_PROFILE is set to a named profile that has a different region (or no region at all).

Common Pitfalls

• Forgetting that AWS_DEFAULT_REGION overrides the config file. If an environment variable is set from a previous session or a shell profile, it silently overrides the ~/.aws/config region.
• Confusing AWS_REGION with AWS_DEFAULT_REGION. Both exist for historical reasons. When both are set, AWS_DEFAULT_REGION wins in the CLI, but some SDKs prefer AWS_REGION. Set both to the same value or use only one.
• Not checking the active profile. If AWS_PROFILE is set to a profile with a different region, aws configure get region returns that profile's region, not the default.
• Relying on EC2 instance metadata in containers. ECS tasks and Lambda functions do not have IMDS access by default. Always set the region explicitly via environment variable in those environments.
• Assuming aws configure get region returns an error when no region is set. It returns an empty string with exit code 0, which can cause scripts to proceed without a region and fail later with a confusing error.

Summary

• aws configure get region is the simplest way to check the effective region.
• aws configure list shows the source of each setting, essential for debugging.
• The precedence order is: command-line flag, AWS_DEFAULT_REGION, AWS_REGION, config file, then EC2 metadata.
• Always set the region explicitly in CI/CD and container environments via environment variables.
• Use aws configure set region for non-interactive permanent configuration.
• When commands hit the wrong region, check environment variables and the active profile first.