Vendor

AWS Credentials: Authentication, Configuration, and Secure Management

Learn how AWS credentials authenticate users and workloads, how CLI and SDKs discover them, how IAM roles provide temporary access, and how to manage credentials securely.

AWS credentials are the evidence that identifies a person, application, or workload making an AWS API request. AWS first authenticates the identity represented by the credentials. IAM and other policy controls then authorize or deny the requested action.

Authentication and authorization

Authentication answers “Who or what is making this request?” For programmatic access, AWS commonly verifies a signed request made with an access key pair and, when required, a session token.

Authorization answers “What is this authenticated principal allowed to do?” IAM policies attached to, or associated with, the principal define allowed actions and resources. Resource policies, permissions boundaries, session policies, organization service control policies, and explicit denies can also affect the result.

AWS credential types

AWS identities that provide credentials

The root user has unrestricted account-level authority and is not an IAM user. Do not create root access keys or use root credentials for ordinary administration. Secure the root account with a strong password and MFA, and use an administrative role or federated identity for daily work.

Credential provider chains

AWS SDKs and the AWS CLI use a credential provider chain: an ordered set of sources checked until usable credentials are found. Common sources include:

• Explicit credentials or configuration supplied by application code or a command invocation.
• Environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN.
• The shared credentials file, commonly ~/.aws/credentials.
• The shared configuration file, commonly ~/.aws/config.
• Web identity token providers, including EKS or other federation workflows.
• Container credential endpoints, commonly used by ECS tasks.
• EC2 instance metadata, when an instance profile supplies a role.
• Other runtime-specific providers, such as IAM Identity Center or an executable configured with credential_process.

Provider precedence and the exact order vary by SDK, CLI, language, and version. Consult the documentation for the tool in use. A high-precedence environment variable or explicit setting can unintentionally override the profile or workload role you intended to use.

AWS CLI shared files and profiles

The shared credentials file commonly stores access-key material. The shared config file commonly stores regions, output formats, role settings, SSO settings, and other profile configuration.

[default]
aws_access_key_id = EXAMPLEACCESSKEY
aws_secret_access_key = EXAMPLESECRET

[development]
aws_access_key_id = EXAMPLEDEVACCESSKEY
aws_secret_access_key = EXAMPLEDEVSECRET

In the credentials file, profile sections are written as [default] or [development]. In the config file, non-default profiles are commonly written as [profile development]. The default profile is used when no other profile is selected. A named profile lets you separate accounts, environments, and roles.

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

aws configure prompts for basic access-key material, a default region, and an output format. Use it only for credentials that are appropriate to store locally. Select a profile for one command with --profile, or set AWS_PROFILE for a shell session or local application run. Restrict file access so other users on the system cannot read secret material, and never commit either shared file to version control.

Environment-based configuration

Common environment variables include:

• AWS_ACCESS_KEY_ID: the public identifier portion of an access key.
• AWS_SECRET_ACCESS_KEY: the confidential signing secret.
• AWS_SESSION_TOKEN: required with temporary security credentials.
• AWS_REGION or, for some tools, AWS_DEFAULT_REGION: the default AWS Region.
• AWS_PROFILE: the named profile to select.

export AWS_ACCESS_KEY_ID=EXAMPLEACCESSKEY
export AWS_SECRET_ACCESS_KEY=EXAMPLESECRET
export AWS_SESSION_TOKEN=EXAMPLESESSIONTOKEN
export AWS_REGION=us-east-1
aws sts get-caller-identity

Environment variables are useful for short-lived local sessions and CI jobs when the values are injected securely and removed after the job. Do not place permanent secrets in shell history, shared build logs, plaintext deployment settings, public repositories, source code, AMIs, container images, or front-end applications. For static application secrets that cannot yet be replaced with roles, use a suitable secret-management system.

Temporary credentials, STS, and IAM roles

Temporary security credentials are time-limited credentials commonly issued by AWS Security Token Service (STS). The AssumeRole operation lets a trusted principal obtain credentials for an IAM role. The response contains an access key ID, secret access key, session token, and expiration time.

A role has two distinct policy concerns:

• Trust policy: defines which principals may assume the role and under what conditions.
• Permissions policy: defines which actions and resources the role may access after it has been assumed.

Temporary credentials expire. Applications using SDK providers normally refresh them before expiration when the provider supports refresh. A process that manually exports values must obtain a new session and replace all three values together. Session duration depends on the role, the issuing workflow, and service limits.

Common role delivery mechanisms

• EC2 instance profiles: associate an IAM role with an EC2 instance; the SDK retrieves rotating credentials from the instance metadata service.
• ECS task roles: provide credentials to a particular container task rather than baking keys into the image.
• Lambda execution roles: provide permissions to Lambda function code.
• EKS or web identity federation: exchange a projected identity token for role credentials.
• CI/CD federation: let a build system exchange an external identity token for a short-lived AWS role session.

Profiles and role-based local development

A local role profile separates source credentials from target permissions. The source profile authenticates the developer or process; STS uses it to assume the target role.

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

The target role trust policy must trust the source principal, and the source identity must be allowed to call sts:AssumeRole. A role profile can instead use credential_process, IAM Identity Center or SSO settings where supported, or another provider mechanism.

For third-party access, an external ID is a value included in the role-assumption request and checked by a trust-policy condition. It helps reduce confused-deputy risks when an outside service accesses multiple customer accounts.

Organize profiles by account and environment, such as development, staging, production-read-only, and production-admin. Choose explicitly for each command:

aws sts get-caller-identity --profile target-account

Secure credential management

• Apply least privilege: grant only the actions and resources required for a task.
• Prefer federation and IAM roles over persistent IAM user access keys.
• Require MFA for sensitive human identities and account-level actions.
• Use separate identities and permissions for people, applications, and environments.
• Track the owner, purpose, creation date, and systems using every access key.
• Rotate, deactivate, and delete unused keys.
• Use a secret-management system when static credentials are unavoidable.
• Do not embed secrets in code, images, AMIs, client-side applications, or committed configuration.
• Limit production access and use separate accounts or roles where appropriate.

Credential lifecycle and incident response

1. Create only when needed. Prefer a role or federation workflow.
2. Record ownership and intended use. An unowned key is difficult to rotate safely.
3. Rotate safely. Create a replacement, deploy it, validate it, then disable the old key. Delete the old key after confirming that dependent systems work.
4. Respond immediately to exposure. Deactivate the exposed key and replace it if continued access is required. Do not wait for evidence of misuse.
5. Remove the source of exposure. Delete secrets from repositories, logs, images, or deployment settings, while remembering that historical copies may still exist.
6. Investigate activity. Review AWS CloudTrail and other security monitoring data for unexpected API calls, regions, resources, and principals.

Verification and troubleshooting

Use AWS STS identity inspection as the first diagnostic step:

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

The result identifies the AWS account and ARN of the active principal. Run it with the same profile, environment, and runtime conditions as the failing command. CLI debug output can reveal which provider path is being considered, but inspect it carefully and redact tokens, signatures, and other sensitive values before sharing logs.

Practical workflow examples

Local development

Create a local profile or use a federation-supported profile, select it explicitly, and verify the identity before running application commands. Keep development permissions separate from production permissions.

aws configure --profile development
aws sts get-caller-identity --profile development
aws s3 ls --profile development

Temporary shell session

When a federation or role-assumption tool provides temporary values, export the access key ID, secret access key, and session token as one set. Commands stop working after expiration, so refresh the session rather than extending the lifetime of copied values.

EC2 and containers

Attach an instance profile to EC2 or configure an ECS task role. Let the SDK use its runtime provider rather than passing keys through user data, environment files, or container images. The same principle applies to Lambda execution roles and EKS workload identity.

Cross-account access

Authenticate with a source profile, assume a target-account role through STS, and use the resulting temporary credentials. The source permissions and target trust policy must both permit the operation.

Exposed access key

Immediately deactivate the key, determine which systems used it, create and deploy a replacement only if necessary, inspect CloudTrail activity, remove the secret from its exposure source, and delete the old key after validation.

Key points

• Credentials authenticate an AWS principal; IAM policies and related controls authorize actions.
• Temporary credentials and IAM roles are safer defaults than persistent access keys.
• Provider precedence can select an unexpected credential source, so verify with STS.
• Temporary credentials require the session token and expire as a set.
• Protect, track, rotate, and promptly deactivate credentials throughout their lifecycle.

For related guidance, see AWS credential configuration and shared AWS credentials files.