AWS Credentials: Configuration, Credential Providers, and Security

Learn how AWS credentials authenticate API requests, configure CLI and SDK profiles, use IAM roles and temporary credentials, troubleshoot access, and secure automation.

AWS credentials identify a caller to AWS. The AWS CLI and SDKs use them to sign API requests so that AWS can determine who is making a request and whether that identity may perform the requested action.

Authentication answers “Who are you?” Authorization answers “What may you do?” Credentials support authentication. IAM policies associated with the authenticated user, role, session, resource, or organization determine authorization. A valid credential can still receive AccessDenied if the applicable policies do not allow the requested action.

Credential types

AWS supports several ways for people, applications, and AWS services to obtain credentials. The safest choice depends on whether the caller is a human, a local development tool, a CI/CD pipeline, or an AWS-hosted workload.

Credential type	Typical source	Expiration behavior	Includes session token	Recommended use
Long-term IAM access key	IAM user	Does not expire automatically; rotate or deactivate it	No	Only when federation or roles are not practical
Temporary security credentials	AWS STS, IAM Identity Center, or a workload role	Expire after a session duration	Yes	Interactive access, role assumption, and automation
IAM role credentials	STS, EC2 instance profile, ECS task role, Lambda execution role, or other workload identity	Automatically refreshed by the service or SDK when supported	Yes	AWS-hosted applications and delegated access
IAM Identity Center access	Browser sign-in and local CLI session cache	Short-lived role credentials expire and can be renewed	Yes	Human access across AWS accounts and permission sets
Federated workload identity	OIDC or another external identity provider	Short-lived role session	Yes	CI/CD and external workloads without stored AWS keys

Long-term access keys

An IAM access key normally consists of an access key ID and a secret access key. The ID identifies the key. The secret is used to sign requests and must be protected. These keys belong to an IAM user and remain usable until they are deactivated, deleted, or otherwise blocked.

Long-lived IAM user keys are difficult to manage safely because they can be copied, forgotten, embedded in code, or left active after a person or system changes. Prefer IAM Identity Center, role assumption, workload roles, or federation whenever possible.

Temporary security credentials

Temporary credentials contain three values: an access key ID, a secret access key, and a session token. The session token is required in addition to the key pair. Temporary credentials are issued by AWS STS or another AWS credential provider and expire at the end of their session.

IAM roles and workload identity

An IAM role is an AWS identity with permissions that can be assumed by a trusted user, service, or workload. Common workload sources include EC2 instance profiles, ECS task roles, Lambda execution roles, EKS pod identity, and external identity providers. These methods allow an application to obtain temporary credentials without storing an IAM user key in its source code or deployment package.

The shared AWS credentials file

The shared credentials file is a local INI-format file. Its default location is ~/.aws/credentials on macOS and Linux, and %UserProfile%\.aws\credentials on Windows.

Each profile is an INI section. The section [default] is used when no other profile is selected. A named profile, such as [development], stores credentials for a particular account, role workflow, or environment.

[default]
aws_access_key_id = EXAMPLEACCESSKEY
aws_secret_access_key = EXAMPLESECRETKEY

[development]
aws_access_key_id = EXAMPLEDEVELOPMENTKEY
aws_secret_access_key = EXAMPLEDEVELOPMENTSECRET

The values above are nonfunctional placeholders. Never replace them with real credentials in an example that will be committed or shared.

Restrict access to the directory and file. On macOS and Linux, a local credentials file should normally be readable only by its owner:

chmod 700 ~/.aws
chmod 600 ~/.aws/credentials

Do not commit the file to source control, paste it into tickets, include it in container images, or share it publicly. Add credential-file patterns to repository ignore rules, enable secret scanning, and check shell history and logs when investigating accidental exposure.

Create and use a named local profile

The AWS CLI can create or update a profile interactively:

aws configure --profile development

The command prompts for an access key ID, secret access key, default region, and output format. For a short-lived development session, prefer signing in through IAM Identity Center or assuming a role instead of entering a long-term IAM user key.

aws sts get-caller-identity --profile development

This command asks AWS STS to identify the account and principal represented by the selected profile.

The AWS configuration file and profiles

The AWS configuration file is separate from the credentials file. Its default location is ~/.aws/config on macOS and Linux and the corresponding .aws\config directory under the Windows user profile.

Aspect	Shared credentials file	AWS config file
Default path	`~/.aws/credentials`	`~/.aws/config`
Typical contents	Access key ID, secret access key, and sometimes session token	Region, output, role settings, Identity Center settings, and credential-process settings
Default section	`[default]`	`[default]`
Named section	`[development]`	`[profile development]`
Secret handling	May contain secrets; protect the file	Usually configuration, but some commands or providers may reference sensitive data

In the credentials file, a named profile is written as [profile-name]. In the config file, the same named profile is written as [profile profile-name]. The word profile is not included in the credentials-file section name.

[profile audit-role]
role_arn = arn:aws:iam::123456789012:role/AuditRole
source_profile = development
region = us-east-1
output = json

This profile tells the CLI to use the development profile as its source credentials and ask AWS STS to assume AuditRole. The source identity must have permission to call sts:AssumeRole, and the target role trust policy must trust that source principal.

Other useful configuration settings include region, output, role_arn, source_profile, and credential_process. A credential process lets the CLI or SDK invoke an external program that returns credentials in the expected format. Protect that program and its output as carefully as any other credential source.

Select a profile

aws sts get-caller-identity --profile audit-role
export AWS_PROFILE=development
export AWS_REGION=us-east-1

A command-line --profile option selects a profile for that command. AWS_PROFILE selects a profile for the current process and commonly takes effect for commands that do not specify --profile. The exact precedence between options and providers can vary by tool, SDK, and version.

The credential provider chain

The credential provider chain is the ordered set of sources an AWS client checks for usable credentials. The AWS CLI and SDKs do not necessarily use exactly the same order, and details can vary by SDK and version. Verify the behavior for the language runtime and version used by your application.

Source	Typical configuration	Common use case	Security considerations	How to verify
Command-line options	Profile or credential-related command options	One CLI invocation	Values can appear in shell history or process inspection	Review the command and run an identity check
Environment variables	`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`	Short-lived local or CI process	Inherited by child processes; may leak into logs or diagnostics	Inspect variable names without printing values
Shared files	Credentials and config profiles	Local development	Files may be copied, backed up, or committed	`aws configure list`
IAM Identity Center	Configured profile and cached login session	Human workforce access	Protect the local session and sign out or renew appropriately	`aws sso login` and STS identity
External process	`credential_process`	Password managers or enterprise credential tools	Secure the executable, output, and local IPC	Inspect config without exposing returned secrets
Container credentials	ECS task role or container credential endpoint	ECS workloads	Prevent untrusted container access to the endpoint	Check task-role configuration and application identity
EC2 instance metadata	Instance profile role	Applications running on EC2	Restrict metadata access and prevent SSRF paths	Check the attached role and STS identity

An unexpected environment variable or selected profile can override the credentials you intended to use. A program may therefore access a different account or role than expected. Always verify the effective identity before destructive or privileged operations.

Environment variable credentials and settings

The standard temporary credential variables are:

AWS_ACCESS_KEY_ID: the access key ID.
AWS_SECRET_ACCESS_KEY: the secret access key.
AWS_SESSION_TOKEN: required with temporary credentials.

Common selection and configuration variables include:

AWS_DEFAULT_REGION and AWS_REGION: region defaults. SDK-specific precedence can differ.
AWS_PROFILE: selected shared profile.
AWS_SHARED_CREDENTIALS_FILE: alternate credentials-file path.
AWS_CONFIG_FILE: alternate config-file path.

export AWS_PROFILE=development
export AWS_REGION=us-east-1

Using a profile and region variable is safer than exporting static keys. If static keys or temporary credentials must be used, keep them short-lived and scoped to one process. Environment values can be exposed through shell history, process listings, crash reports, debugging output, CI logs, and inherited child processes. Do not print them while troubleshooting.

IAM roles and temporary credentials

Temporary credentials are preferred because their usefulness is limited by an expiration time. An application that uses a role can receive fresh credentials through an SDK provider, rather than embedding a permanent secret.

Role assumption through AWS STS

When a principal assumes a role, AWS STS checks two related permission sets:

The caller's permissions policy must allow the assume-role operation.
The role's trust policy must allow the caller principal to assume it.

After successful assumption, STS returns an access key ID, secret access key, and session token. The session ends at expiration. Supported SDK providers refresh credentials automatically, but an application must use a refreshable provider and must not cache temporary values beyond their lifetime.

External IDs help protect third-party role assumption from confused-deputy scenarios. MFA can be required by a trust policy for interactive or sensitive access. Session duration controls how long a role session may last, subject to service and role limits. Role chaining means assuming another role using temporary role credentials; chained sessions have additional duration limitations, so avoid unnecessarily long chains.

IAM Identity Center authentication

AWS IAM Identity Center provides workforce sign-in and account-role access. A user authenticates through a browser, and the CLI caches a local session. The CLI then obtains short-lived credentials for an assigned account and permission set. This avoids storing IAM user access keys on the workstation.

[profile workforce]
sso_session = organization
sso_account_id = 123456789012
sso_role_name = Developer
region = us-east-1
output = json

[sso-session organization]
sso_start_url = EXAMPLE_START_URL
sso_region = us-east-1

Use the configured profile to sign in and run a command:

aws sso login --profile workforce
aws sts get-caller-identity --profile workforce

The account, role, start URL, and Identity Center region must match the organization configuration. Cached sessions are still sensitive local authentication material; protect the user account and workstation.

Credential security and lifecycle management

Scenario	Preferred authentication method	Method to avoid	Reason
Human access from a workstation	IAM Identity Center with an assigned permission set	Shared IAM user keys	Centralized access, short-lived sessions, and easier removal
EC2 application	EC2 instance profile	Keys in user data or application files	Automatic temporary credentials and no embedded secret
ECS task	ECS task role	Keys in container environment definitions	Task-scoped workload identity
Lambda function	Lambda execution role	Keys in deployment packages	Service-managed role credentials
CI/CD pipeline	OIDC or equivalent federation to a limited role	Permanent keys in CI variables	Short sessions tied to pipeline identity and claims
External system requiring a secret	Managed secret store with rotation and restricted access	Hardcoded values in code, images, or infrastructure definitions	Centralized control, auditing, and rotation

Avoid root-user access keys. Use the root user only for tasks that require it, with strong MFA protection.
Use least privilege: grant only the actions and resources needed for a task.
Rotate keys that must exist, and deactivate or delete keys that are no longer needed.
Require MFA for appropriate human access and sensitive role assumption.
Enable secret scanning in repositories and CI systems.
Use audit logging, such as CloudTrail, to investigate credential use and unexpected activity.
Keep non-secret configuration, such as a region or output format, separate from credentials. A region is configuration; a secret access key is a secret.

Respond to an exposed access key

Stop treating the key as private. Record where it was exposed and preserve relevant evidence.
Immediately deactivate the exposed key, or delete it when it is no longer needed. If the key is used by a critical system, prepare a replacement before disabling it where operationally necessary.
Check audit logs and recent activity for the key, principal, account, actions, regions, and times involved.
Replace access with IAM Identity Center, a role, workload identity, or a managed secret store.
Review the identity's policies and remove unnecessary permissions. Investigate any resources or data that may have been accessed.
Remove the secret from source files, images, artifacts, logs, and history, while remembering that removal does not make an already exposed value safe.

Credentials in automation and deployments

For CI/CD, configure the platform to present an OIDC or equivalent identity token to AWS. AWS STS can exchange that identity for a limited-duration role session. Restrict the role trust policy using repository, project, branch, environment, or other verified claims as appropriate.

For AWS-hosted compute, attach the appropriate workload role: an EC2 instance profile, ECS task role, Lambda execution role, or EKS pod identity. The AWS SDK provider chain can then retrieve and refresh credentials without application-managed keys.

Use a secret store only when an externally managed secret is genuinely required. Do not hardcode credentials in application code, container images, repositories, build logs, templates, or infrastructure definitions. Redact command output and prevent secrets from being inherited by unrelated build steps.

Validation and troubleshooting

Confirm the effective identity

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

The STS response identifies the AWS account and principal resolved by the current credentials. aws configure list shows the sources of selected configuration values without requiring you to print secret values. You can also inspect whether AWS_PROFILE, region variables, alternate file paths, or static credential variables are set, but display only variable names and safe configuration.

aws sts get-caller-identity --debug

Debug output can reveal request details, profile names, endpoints, and errors. Protect it because diagnostic output may contain sensitive information. Never paste unredacted debug output into a public issue.

Error or symptom	Likely cause	Diagnostic step	Resolution
`Unable to locate credentials`	No provider source, wrong profile, changed file path, or unavailable workload role	Run `aws configure list`; inspect selected profile and safe environment-variable names	Correct the profile or file location, sign in, or attach and permit the workload role
Wrong account or role	`AWS_PROFILE`, static environment credentials, cached Identity Center credentials, or another earlier provider source wins	Run STS identity and explicitly specify the intended profile	Unset unintended variables, select the correct profile, and renew the intended session
`ExpiredToken`	Temporary role or Identity Center session expired, refresh failed, or clock is inaccurate	Check session status, SDK provider behavior, and system time	Reauthenticate or obtain a fresh role session; use a refreshable provider; synchronize the clock
`AccessDenied`	No allow permission, or an explicit deny, boundary, session policy, SCP, or resource policy blocks access	Confirm identity, action, resource, and policy layers	Make a least-privilege policy change instead of granting broad administrator access
`SignatureDoesNotMatch`	Mismatched key pair, missing session token, wrong region, or inaccurate clock	Replace values from a trusted source and check region and time	Use matching credentials, include `AWS_SESSION_TOKEN` for temporary credentials, and correct region/time
Identity Center login or role retrieval fails	Incorrect start URL, region, account, role, assignment, or stale session	Validate profile settings and Identity Center assignments	Correct configuration, obtain the required assignment, and perform a fresh login

Practical workflow

Choose the identity method based on the caller: Identity Center for people, roles for AWS workloads, and federation for CI/CD.
Select a profile or workload role without placing credentials in source code.
Run aws sts get-caller-identity before making account-sensitive changes.
Use aws configure list and safe environment inspection when the source is unclear.
When access is denied, distinguish authentication failure from an authorization policy problem.
When a secret is exposed, deactivate or revoke it first, investigate its use, and replace it with short-lived access.

Exam-relevant notes

Authentication identifies a principal; IAM policies authorize actions.
Temporary credentials require a session token in addition to the access key ID and secret access key.
A role requires both a permissions policy and a trust policy for successful assumption.
Profiles in ~/.aws/credentials use [name]; named profiles in ~/.aws/config use [profile name].
Provider-chain behavior is ordered, but exact order varies by SDK and version. Environment variables and explicit command options can cause an unexpected identity.
Workload roles and federation reduce the need for long-lived IAM user access keys.

For related guidance, see AWS credentials configuration and AWS credential usage patterns.