@Fs

AWS Credentials: Configuration, Profiles, and Secure Authentication

Learn how AWS credentials, profiles, roles, environment variables, and IAM Identity Center authenticate AWS CLI and SDK requests securely.

AWS credentials let the AWS CLI and SDKs identify a caller and sign requests to AWS services. This guide explains credential types, provider resolution, configuration files, profiles, temporary access, Identity Center, automation, validation, security, and troubleshooting.

Authentication and authorization

Authentication answers “Who is making this request?” AWS credentials identify an AWS principal, such as an IAM user, an assumed IAM role, or an IAM Identity Center session.

Authorization answers “What is that principal allowed to do?” IAM evaluates policies attached to users, roles, groups, permission sets, sessions, and other policy mechanisms. A successful identity check does not guarantee permission to perform every action.

For example, credentials might prove that a request comes from a deployment role, while IAM policies determine whether that role can create an Amazon S3 bucket or modify an EC2 instance.

AWS credential components

Long-term access keys are normally associated with an IAM user and remain valid until they are rotated, deactivated, or deleted. Temporary credentials are issued for a limited session by AWS Security Token Service (STS), IAM Identity Center, federation, or a workload role. They include an access key ID, secret access key, session token, and expiration time.

When using temporary credentials, all three values are required. Omitting AWS_SESSION_TOKEN, using an old token, or mixing values from different sessions commonly produces an invalid-token error.

Credential provider chains

A credential provider chain is the ordered set of sources that a CLI or SDK checks when it needs credentials. Common sources include:

• Explicit command-line options or client settings.
• Environment variables such as AWS_ACCESS_KEY_ID.
• The shared credentials file.
• The shared configuration file.
• IAM Identity Center cached sessions.
• A credential_process command that returns credentials.
• Web identity tokens, commonly used with Kubernetes workload identity.
• Container credentials supplied to ECS tasks or other supported runtimes.
• Instance-role credentials supplied to EC2 workloads.

Exact precedence can differ between the AWS CLI, SDK languages, SDK versions, and application configuration. Always verify the provider-chain documentation for the specific tool. An unexpected environment variable, default profile, container role, or instance role can cause a request to use the wrong account or fail with a permission error.

For a useful overview, think of resolution as: explicit settings are considered first, followed by process and environment sources, local profiles, and finally runtime-provided credentials. This is a conceptual model, not a substitute for the applicable CLI or SDK documentation.

Shared AWS credential and configuration files

The credentials file commonly contains secrets, so protect it carefully. The shared config file may contain non-secret settings, but role and login configuration can still reveal account and environment details.

Profile section names differ between the two files. The credentials file uses [default] and [development]. The config file uses [default] for the default profile and [profile development] for a named profile.

# ~/.aws/credentials
[default]
aws_access_key_id = EXAMPLEDEFAULTKEY
aws_secret_access_key = EXAMPLEDEFAULTSECRET

[development]
aws_access_key_id = EXAMPLEDEVKEY
aws_secret_access_key = EXAMPLEDEVSECRET
aws_session_token = EXAMPLESESSIONTOKEN

# ~/.aws/config
[default]
region = us-east-1
output = json

[profile development]
region = us-west-2
output = table

The locations can be changed when a tool supports the standard overrides. For example, AWS_SHARED_CREDENTIALS_FILE points to a different credentials file and AWS_CONFIG_FILE points to a different config file.

Use the related credentials file reference and config file reference when inspecting local AWS settings. Do not publish their contents.

Creating and selecting profiles

An AWS CLI profile is a named set of credentials and configuration values. Profiles can isolate development, staging, production, separate AWS accounts, or role-assumption paths.

# Configure the default profile interactively
aws configure

# Configure or update a named profile
aws configure --profile development

The interactive command prompts for an access key ID, secret access key, default region, and output format. Prefer temporary or federated credentials instead of entering permanent keys whenever your organization supports them.

# Select one profile for a command
aws s3 ls --profile development

# Select a profile for the current Unix-like shell
export AWS_PROFILE=development

# Stop selecting it automatically
unset AWS_PROFILE

Before a production operation, use an explicit profile and verify the resulting account identity.

Regions and environment variables

Common AWS environment variables include:

• AWS_ACCESS_KEY_ID: access key identifier.
• AWS_SECRET_ACCESS_KEY: secret signing key.
• AWS_SESSION_TOKEN: required for temporary credentials.
• AWS_PROFILE: named profile selection.
• AWS_REGION and AWS_DEFAULT_REGION: region defaults; behavior can vary by tool.

export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1

# Temporary credentials: all three values are required
export AWS_ACCESS_KEY_ID='EXAMPLEKEY'
export AWS_SECRET_ACCESS_KEY='EXAMPLESECRET'
export AWS_SESSION_TOKEN='EXAMPLESESSIONTOKEN'

Environment variables can override the profile you intended to use. Permanent keys exported into a shell may be visible to child processes, diagnostic tools, or accidentally captured in CI logs. Do not put real secrets in shell history, scripts, shared terminals, source code, or logs.

# Remove credential variables that may override a profile
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
unset AWS_PROFILE

On systems where environment inspection is permitted, process environments can contain sensitive values. Treat references such as the current process environment and another process environment as sensitive diagnostic locations.

Temporary credentials and IAM roles

An IAM role is an assumable AWS identity with permissions. STS AssumeRole returns temporary credentials for a role session. Short-lived credentials reduce the impact of a leak and avoid managing a permanent secret in every workstation or workload.

A role profile commonly connects an initial identity to a target role with source_profile and role_arn:

[profile production-admin]
role_arn = arn:aws:iam::123456789012:role/ProductionAdmin
source_profile = development
region = us-east-1

The source profile supplies the initial identity. That identity must be allowed to assume the target role, and the role trust policy must allow the source principal. A role session can also have a session name. For cross-account access, an external ID may be required, especially when a third party assumes roles on behalf of customers.

Temporary credentials expire. The CLI or SDK may refresh them automatically when the provider supports refresh; otherwise, sign in or obtain a new session. Never try to extend a session by reusing an expired token.

For AWS compute, prefer attached roles over embedded keys. EC2 instance roles, ECS task roles, EKS workload identity, Lambda execution roles, and equivalent workload identities allow the runtime to obtain credentials through its provider chain.

IAM Identity Center authentication

IAM Identity Center provides workforce sign-in and permission-set-based access to AWS accounts. A configured CLI profile uses browser authentication and token-backed temporary sessions instead of requiring a permanent local access key.

1. Configure an Identity Center profile with the organization’s approved start URL, region, account selection, and permission set.
2. Sign in interactively:

aws sso login --profile workforce

3. Run commands with that profile:

aws sts get-caller-identity --profile workforce
aws s3 ls --profile workforce

The browser login establishes a cached session used to obtain temporary AWS credentials. When the token expires, repeat the approved login process. Do not copy cached token files into source control or share them.

Validating the active identity

STS can report the principal currently used for a request. Run this before changing production resources:

aws sts get-caller-identity --profile development

{
    "UserId": "AID...EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/example"
}

For an assumed role, the ARN identifies the role session. Verify the account ID, principal ARN, selected profile, and region before destructive commands.

# Show where the CLI obtained configuration values
aws configure list --profile development

# Inspect profile definitions without printing secret values
aws configure get region --profile development
aws configure get output --profile development

Use aws configure list as a source diagnostic, but keep its output private and redact any displayed credential material from screenshots and logs. A safe terminal example should replace account numbers and ARNs with placeholders.

Credential types compared

Credentials in automation and CI/CD

Use platform-supported workload identity, OIDC federation, or securely managed short-lived credentials for automation. These approaches avoid storing a permanent AWS secret in a repository or long-lived runner.

Static repository secrets are a fallback, not the preferred design. If unavoidable, limit permissions, restrict where the secret can be used, rotate it, prevent it from appearing in logs, and separate development, staging, and production identities. A production pipeline should not reuse a developer’s personal access key.

Security practices

• Do not create or use root-user access keys.
• Prefer IAM roles, IAM Identity Center, federation, and workload identity over static keys.
• Apply least privilege: grant only the actions and resources required.
• Rotate required long-term keys, deactivate suspected or unused keys, and remove keys that are no longer needed.
• Protect local credential files with user-only permissions. On Unix-like systems:

chmod 600 ~/.aws/credentials ~/.aws/config

• Use equivalent user-only access controls on Windows and other operating systems.
• Never commit credentials to version control, source code, tickets, chat, screenshots, or logs.
• Do not paste secrets into support requests; redact account details and tokens where possible.

If a secret may have been exposed, treat it as compromised: deactivate or delete the affected access key, identify and replace every system using it, inspect audit records for unexpected activity, review related roles and permissions, and notify the account security owner. Then remove the secret from the original source and prevent it from being reintroduced.

Troubleshooting credential failures

Region mismatches can cause commands to target the wrong regional endpoint or fail to find resources. Confirm AWS_REGION, AWS_DEFAULT_REGION, profile region settings, and any SDK-specific region configuration.

When diagnosing, start with safe read-only commands:

aws configure list --profile development
aws sts get-caller-identity --profile development
aws configure get region --profile development

Do not use a credential failure as a reason to print secrets. Inspect names, paths, profile selection, account identity, region, and expiration state without exposing key material.

Practical preflight checklist

1. Select the intended profile explicitly.
2. Confirm the region.
3. Run aws sts get-caller-identity.
4. Verify the account ID and principal ARN.
5. Confirm that the identity is appropriate for the environment and operation.
6. Use the least-privileged command possible and avoid destructive actions until the checks pass.