@Fs

AWS Credentials File: Profiles, Configuration, and Secure Usage

Learn how AWS credentials work, where the shared credentials file is stored, how profiles and credential resolution work, and how to configure AWS CLI and SDK access securely.

AWS credentials are authentication material used to sign requests to AWS. They let a tool identify a principal, such as an IAM user, an assumed role, or an IAM Identity Center session, and request AWS services.

Authentication and authorization

Authentication answers “Who is making this request?” Authorization answers “What is that principal allowed to do?” AWS credentials help authenticate the request. IAM policies, resource policies, organization controls, and other AWS security controls determine whether the authenticated principal is authorized to perform an action.

A long-lived access key normally has two values:

• Access key ID: the public identifier portion of the key.
• Secret access key: the sensitive value used to sign requests. Treat it like a password.

Temporary credentials have a third required value: a session token. Temporary credentials also have an expiration time. The access key ID, secret access key, and session token must come from the same session.

The shared AWS credentials file

The shared credentials file is a local INI-style file used by the AWS CLI, SDKs, and other AWS-aware tools. Its default locations are:

• Linux and macOS: ~/.aws/credentials
• Windows: %UserProfile%\.aws\credentials

The file contains credential profiles. You can inspect the topic path at the shared credentials file.

The credentials file is separate from the AWS config file, normally ~/.aws/config. The AWS config file commonly stores regions, output formats, role settings, and other non-secret configuration. Some settings can be read from either file depending on the tool, but credentials and configuration should be treated as separate concerns.

Profiles

A profile is a named set of AWS credential or configuration settings. The default profile is used when no other profile is selected. Named profiles let you separate accounts, environments, roles, or users instead of repeatedly replacing one set of values.

Default profile

[default]
aws_access_key_id = AKIAEXAMPLE
aws_secret_access_key = example-secret-key

Named profiles

[development]
aws_access_key_id = AKIADEVEXAMPLE
aws_secret_access_key = development-secret

[production]
aws_access_key_id = AKIAPRODEXAMPLE
aws_secret_access_key = production-secret

These examples use placeholder values. Never copy real secret keys into tutorials, tickets, repositories, screenshots, or chat messages.

Temporary credentials in a profile

[temporary]
aws_access_key_id = ASIAEXAMPLE
aws_secret_access_key = temporary-secret
aws_session_token = temporary-session-token

A temporary profile is valid only until its session expires. Do not mix an old session token with newly issued key values.

Selecting a profile

For a shell session, select a profile with:

export AWS_PROFILE=development

On Windows PowerShell, the equivalent is $env:AWS_PROFILE = "development". An explicit command option is useful when you want the selected account to be visible in the command itself.

Configuring credentials

The AWS CLI can interactively create or update a default profile:

aws configure

To configure a named profile:

aws configure --profile development

These commands prompt for an access key ID, secret access key, default region, and output format. Use them only with credentials obtained through an approved organizational workflow.

For workforce access, prefer IAM Identity Center sign-in or an approved role-based workflow when available. IAM Identity Center provides federated sign-in and permission sets, while IAM roles provide assumable identities. Creating a new IAM user access key may be appropriate for a narrowly defined local or automation use case, but long-lived user keys require careful protection and rotation.

Role assumption and temporary access

An IAM role is an assumable identity with permissions. AWS STS, the AWS Security Token Service, issues temporary credentials when a user, workload, or other trusted principal assumes a role. Temporary access is often safer than distributing persistent user access keys because it can expire and can be limited to a specific role and session.

A role-based profile generally belongs in the config file and points to a source identity or another approved identity provider:

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

The source_profile supplies credentials that are allowed to assume the role. In other setups, the source may be IAM Identity Center, a web identity provider, or a compute workload identity. Avoid adding another long-lived access key merely to support a role profile.

Credential provider chain and resolution order

The credential provider chain is the ordered set of sources an AWS tool checks for credentials. Exact behavior varies by SDK and CLI version, but the practical rule is that an explicit setting usually wins over less-specific sources. Common sources include:

1. Credentials explicitly supplied in a command, SDK client, or application setting.
2. Environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN.
3. The selected profile in the shared credentials file and AWS config file.
4. IAM Identity Center, role-assumption, web-identity, or other configured identity providers.
5. Workload identity supplied by an AWS compute environment, such as an instance, container, or task role.

Do not assume that the credentials file is always being used. An environment variable, cached sign-in session, role provider, or workload role may take precedence. An unexpected source can make a command run against the wrong account, even when the profile file looks correct.

Verify identity before doing work

Always confirm the active account and principal before creating, deleting, changing, or inspecting sensitive resources:

aws sts get-caller-identity

The response includes the account ID and an ARN identifying the caller. Also inspect the source selected by the CLI:

aws configure list

When the output is unexpected, check the selected profile and the environment variables in the current shell. Run the identity command again after changing the credential source.

Security practices

• Use least privilege: grant only the actions and resources required for the task.
• Prefer short-lived credentials from IAM Identity Center, STS role assumption, or workload roles.
• Use MFA where applicable, especially for privileged human access.
• Rotate long-lived access keys on an approved schedule and remove keys that are no longer needed.
• Store local files under the correct user account and use restrictive permissions. On Unix-like systems, run chmod 600 ~/.aws/credentials.
• Keep secrets out of shell history, debug output, crash reports, and CI logs.
• Use separate profiles and accounts for development and production, and verify identity before impactful commands.

Managing IAM user keys and sign-in methods

IAM user access keys are persistent credentials associated with an IAM user. They are not the same as IAM Identity Center sign-in sessions or role credentials. For human workforce access, IAM Identity Center or federation is generally preferable. For AWS-hosted applications, use a workload role instead of placing an IAM user key on the host.

If a local CLI workflow genuinely requires an IAM user access key, create it through the AWS console or an approved administrative process, grant the user only the required permissions, and save the values using a protected credential mechanism. The secret access key is normally shown only when the key is created, so do not lose it or request that others send it to you.

To rotate a key, create and test an approved replacement, update the consuming profile or environment, verify the new identity, and then deactivate or delete the old key. If a key is compromised, deactivate or delete it immediately, investigate recent activity, remove it from exposed locations and repository history where appropriate, and create a replacement only if the workload still needs one. Removing text from the latest commit is not sufficient if the secret remains in repository history or logs.

Troubleshooting

SDK use

Most AWS SDKs use a credential provider chain similar to the CLI and can read the shared credentials file, AWS config file, environment variables, IAM Identity Center sessions, role providers, or workload roles. This means an application may use a different source than expected if its process environment, profile setting, or runtime identity differs from your terminal.

For local development, select a named profile through the SDK's documented profile configuration rather than copying secret values into source code. For deployed applications, prefer the runtime's IAM role or another short-lived provider.

Exam-relevant notes

• The access key ID identifies the key; it is not a password by itself.
• The secret access key signs requests and must remain confidential.
• Temporary credentials require a session token and expire.
• The shared credentials file and AWS config file are separate files.
• The default profile is used when no profile is explicitly selected.
• Credential provider precedence can cause environment variables or workload roles to override a file profile.
• Authentication does not grant permissions; authorization is determined by applicable AWS policies and controls.