AWS Credentials Configuration

Learn how AWS CLI and SDK credentials are stored, selected, configured, verified, and secured using profiles, roles, SSO, and temporary credentials.

AWS credentials let the AWS CLI, SDKs, and other tools authenticate a human user, workload, or application to AWS. Authentication answers “Who is making this request?” Authorization answers “What is that identity allowed to do?” AWS credentials establish an identity; IAM policies, permission boundaries, resource policies, and organization controls determine which actions are permitted.

Credential Components

A programmatic AWS identity commonly uses an AWS access key ID, which is the public identifier for a credential, and an AWS secret access key, which is confidential and must be protected like a password. Temporary credentials also include a session token and an expiration time. Requests are normally directed to an AWS region, such as us-east-1; the region is configuration rather than a secret.

Access key ID: Identifies the credential.
Secret access key: Signs requests and must remain private.
Session token: Required with temporary credentials.
Region: Selects the regional AWS endpoint for a request.

Long-lived IAM user access keys should be avoided when a role or another short-lived method is available. Temporary credentials reduce the time during which an exposed credential can be abused.

AWS Credential Sources

The AWS CLI and SDKs use a credential provider chain: an ordered set of sources that a tool checks for usable credentials. The exact order can vary by tool or SDK version, but environment variables and explicitly selected profiles commonly take precedence over lower-priority sources. The first applicable source is used, so an unexpected environment variable can override the profile you intended to use.

Credential source	Where it is configured	Typical use case	Temporary or long-lived	Security considerations
Environment variables	Shell or process environment	Local sessions, automation, and CI jobs	Either	May override profiles; avoid exposing process environments and logs
Shared credentials file	`~/.aws/credentials` or the Windows equivalent	Local CLI and SDK profiles	Often long-lived, but can contain temporary values	Restrict permissions and never commit the file
Shared config file	`~/.aws/config`	Regions, output, role profiles, and SSO settings	Usually configuration for temporary or stored credentials	Role and SSO settings are safer than storing long-lived keys
IAM role	Attached to an AWS resource or assumed by an identity	EC2, Lambda, and other workloads	Temporary	Prefer least privilege and avoid embedding keys in applications
IAM Identity Center	SSO settings and a local session cache	Browser-based workforce access	Temporary	Sessions expire and must be renewed
Container credentials	Container runtime endpoint	Amazon ECS and compatible container workloads	Temporary	Protect task or pod metadata endpoints and use a narrow role
EC2 instance metadata	Instance metadata service	Applications running on EC2	Temporary	Use an instance role and protect metadata access

Temporary Credentials

AWS STS, IAM roles, and IAM Identity Center commonly issue temporary credentials. The access key ID, secret access key, and session token must come from the same session. After the expiration time, the CLI or SDK must obtain a renewed session. Supplying only the access key and secret without the corresponding session token causes authentication failures.

The Shared Credentials File

The default shared credentials file is ~/.aws/credentials on Unix-like systems and %UserProfile%\.aws\credentials on Windows. It uses INI-style sections. The section [default] is the default profile; other section names are named profiles.

[default]
aws_access_key_id = EXAMPLE_ACCESS_KEY_ID
aws_secret_access_key = EXAMPLE_SECRET_ACCESS_KEY

[development]
aws_access_key_id = EXAMPLE_DEVELOPMENT_KEY_ID
aws_secret_access_key = EXAMPLE_DEVELOPMENT_SECRET
aws_session_token = EXAMPLE_SESSION_TOKEN

The example values are fictional. A real credentials file contains sensitive secrets. Do not commit it to source control, paste it into tickets or chat, or make it readable by unrelated users or processes. A session token is present when the profile contains temporary credentials.

The Shared AWS Configuration File

The shared configuration file is normally ~/.aws/config. It is separate from the credentials file and usually contains non-secret settings and instructions for obtaining credentials. It can contain a region, output format, role-assumption settings, external process settings, and IAM Identity Center settings.

File	Default location	Typical contents	Profile section format	Should contain secrets
Shared credentials file	`~/.aws/credentials`; `%UserProfile%\.aws\credentials` on Windows	`aws_access_key_id`, `aws_secret_access_key`, and sometimes `aws_session_token`	`[default]` or `[profile-name]`	It may contain secrets, so protect it carefully
Shared config file	`~/.aws/config`	`region`, `output`, `role_arn`, `source_profile`, `credential_process`, and SSO settings	`[default]` or `[profile profile-name]`	Prefer no secrets; process and SSO configuration still needs protection

Notice the profile naming difference: the credentials file uses [development], while the config file uses [profile development]. The default profile is [default] in both files.

[default]
region = us-east-1
output = json

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

[profile workforce]
sso_session = company
sso_account_id = 123456789012
sso_role_name = ReadOnly
region = us-east-1

role_arn identifies a role to assume. source_profile identifies the profile that supplies the starting identity. credential_process tells the CLI or SDK to obtain credentials from an approved local process; its output must be protected because it contains credential material. IAM Identity Center profiles contain settings that allow the CLI to obtain a temporary session after browser-based sign-in.

Profiles and Credential Selection

A profile is a named collection of credentials and configuration. Named profiles are useful for separating development and production accounts, different regions, or a base identity from an assumed role.

Selecting a Profile

Use --profile for one command:

aws sts get-caller-identity --profile development

Use AWS_PROFILE to select a profile for subsequent commands in a shell session:

export AWS_PROFILE=development
aws sts get-caller-identity

On Windows PowerShell, the equivalent environment-variable assignment is:

$env:AWS_PROFILE = "development"

If AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_SESSION_TOKEN is set, those values can take precedence over file-based profiles. This is a common reason that selecting a profile appears not to work. Check the environment before assuming the profile files are wrong.

Role-Based Profile

A role-based profile avoids storing a second set of long-lived keys. The source profile authenticates first, and the CLI requests temporary credentials for the target role.

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

The source identity must be allowed to call AWS STS to assume the role, and the role trust policy must allow that identity. The resulting permissions are controlled by the role and any applicable session or organization policies.

Configuring Credentials Safely

Interactive CLI Configuration

To create or update the default profile, run:

aws configure

For a named profile, run:

aws configure --profile development

Interactive setup asks for an access key ID, secret access key, default region, and output format. Use an approved temporary or delegated credential method instead of entering a long-lived key when your organization supports it.

IAM Identity Center Configuration

For workforce access through AWS IAM Identity Center, configure an SSO profile:

aws configure sso --profile workforce
aws sso login --profile workforce

The login creates or refreshes a temporary authenticated session. Renew it when it expires rather than copying session values into source code or permanent files.

Inspecting Configuration Without Revealing Secrets

Use the CLI to inspect the resolved source and non-secret settings:

aws configure list --profile development

Review which profile, region, and provider are being used, but do not publish command output if it includes key identifiers, file paths, process output, or other sensitive values. Debug output can reveal provider-chain decisions and is useful during troubleshooting, but treat it as confidential.

File Permissions and Storage

On Unix-like systems, restrict local AWS files to the account that needs them:

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

Use an approved secret store for application secrets, keep credentials outside repositories, add secret-scanning checks to source-control workflows, and ensure backups and build logs do not copy secret material. For workloads, prefer IAM roles, workload identity, or OIDC federation over static keys.

Identity Verification

The safest first check is to ask AWS which identity received the request:

aws sts get-caller-identity

For a specific profile:

aws sts get-caller-identity --profile development

The response identifies the caller and AWS account. Verify the account before changing resources, especially when working with separate development and production environments.

Exam-relevant note: Successful authentication does not prove that an operation is authorized. get-caller-identity confirms the active identity, while an attempted service operation tests whether applicable policies permit that action.

Troubleshooting Credential Problems

Error or symptom	Likely cause	How to confirm	Recommended resolution
Unable to locate credentials	No usable profile or environment variables; wrong home or configuration path; workload has no attached role	Run `aws configure list` and inspect the selected profile and environment	Configure a profile, complete SSO login, or attach an appropriate IAM role
Unexpected AWS account	`AWS_PROFILE` or environment credentials override the intended profile, or default is selected unintentionally	Run `aws sts get-caller-identity` and `aws configure list`	Use `--profile`, correct `AWS_PROFILE`, or remove unintended credential variables
`ExpiredToken` or another token error	Temporary role or SSO session expired; session token is missing; system clock is inaccurate	Check session age, confirm all three temporary values belong together, and verify system time	Renew SSO or role credentials, include the session token, and synchronize the clock
`InvalidClientTokenId` or signature validation failure	Incorrect, disabled, deleted, or rotated key; whitespace or formatting error	Check the active provider and identity without exposing secrets	Provision replacement credentials through the approved process; never paste keys into logs or tickets
`AccessDenied` after successful authentication	The identity lacks permission, or a boundary, service control policy, resource policy, or session policy denies the request	Confirm the identity and identify the denied action and resource	Review applicable policies and grant only the required permission

A Practical Diagnostic Sequence

Run aws sts get-caller-identity to establish which account and identity are active.
Run aws configure list and check the provider, profile, region, and environment-variable indicators.
Compare the command's explicit --profile option with AWS_PROFILE.
Check whether temporary credentials or an SSO session have expired.
For an authorization error, review the denied action, resource, and applicable IAM and organization policies.
Use debug output only when needed to identify provider or profile selection, and redact it before sharing.

Credential Lifecycle and Rotation

Prefer IAM roles and short-lived credentials for people, applications, CI/CD, containers, and compute instances.
Grant least privilege: provide only the permissions required for the task.
Rotate access keys according to organizational policy and remove unused keys.
Immediately disable or delete a key suspected of exposure, review activity, and update dependent systems through a controlled process.
Renew temporary sessions before expiration and ensure applications handle refresh behavior correctly.
Use MFA where supported, especially for sensitive human access and administrative actions.
Audit identities, roles, access keys, and sign-in or API activity regularly.
Use secret scanning, protected CI variables, repository hooks, and log redaction to prevent accidental disclosure.

Key Takeaways

Credentials authenticate an identity; IAM policies authorize actions.
The shared credentials file stores profile credentials, while the shared config file stores settings and credential-acquisition instructions.
Environment variables can override file-based profiles.
Use named profiles, role assumption, and IAM Identity Center to separate environments and reduce long-lived key usage.
Confirm the active identity with aws sts get-caller-identity before troubleshooting permissions or modifying resources.
Treat secret access keys, session tokens, process output, and debug logs as sensitive.

For a focused view of a local credentials file, see the credentials file reference. Configuration settings are covered in the AWS config reference.