S3

AWS S3 Credentials and Access Configuration

Learn how AWS credentials authenticate S3 requests, configure AWS CLI profiles, use IAM roles and temporary credentials, and troubleshoot S3 access securely.

AWS credentials are values or mechanisms that prove the identity of a requester making an AWS API request. Amazon S3 uses those credentials to identify the caller, while IAM policies and related controls determine whether the caller may perform the requested action.

Authentication answers “Who is making this request?” Authorization answers “What is that identity allowed to do?” Valid credentials do not automatically grant access to every bucket or object.

How credentials work with Amazon S3

An S3 request can be public or authenticated. Public access is possible only when the relevant S3 settings and policies allow it. Protected buckets, private objects, and operations such as writing or deleting objects normally require an authenticated AWS principal with appropriate authorization.

1. A user, CLI, SDK, or workload obtains AWS credentials.
2. The AWS CLI or SDK uses the credentials to create a signed request.
3. S3 identifies the authenticated principal.
4. IAM and resource policies evaluate the requested action and resource.
5. S3 allows or denies the operation.

AWS identities that can access S3

The root user has extensive authority and should be protected with MFA, strong account-recovery controls, and minimal use. Applications should not use root credentials.

AWS credential types

A programmatic credential commonly contains an access key ID, a public identifier, and a secret access key, the private signing secret paired with it. Temporary credentials also contain a session token. The access key ID, secret access key, and session token must be used together for a typical temporary session.

A console password cannot authenticate an AWS CLI or SDK request. MFA is an additional security control, not a replacement for the credentials used by an API request. Temporary credentials are issued by AWS STS, the Security Token Service, often through the AssumeRole operation, and expire automatically.

Recommended credential strategy

• Use IAM roles and temporary credentials for workloads running on AWS.
• Use IAM Identity Center, federation, or role assumption for human access.
• Use named AWS CLI profiles when working with multiple accounts, roles, or environments.
• Grant least privilege: separate identities by person, workload, environment, and purpose.
• Do not place permanent access keys in source code, scripts, AMIs, containers, browser-delivered applications, screenshots, logs, or support tickets.
• Separate development, test, and production accounts or profiles where practical.

Obtaining and managing credentials

Create or use an identity with only the permissions needed for the task. If long-term programmatic credentials are unavoidable, create an access key through the approved identity-management process. The secret access key is shown at creation time and cannot be retrieved later. Store it securely at that point.

Deactivate or delete unused keys. Rotate active keys according to organizational procedures, use a secret-management system for applications, and monitor key usage. A role-based design is usually safer because short-lived credentials can be refreshed without distributing a permanent secret.

Configuring AWS CLI credentials

Default profile

The interactive command below configures the default AWS CLI profile and can also set a default region and output format:

aws configure

Use this only with an approved access-key source. The AWS CLI commonly stores long-term credential values in ~/.aws/credentials and non-secret settings such as regions in ~/.aws/config. On Windows, the equivalent directory is typically under the user's profile directory. Do not commit either file to version control or copy it into an image or container.

Named profiles

A named profile is a local configuration that selects credentials, region, role behavior, and output settings. It reduces the chance of using the wrong account:

aws configure --profile development
aws sts get-caller-identity --profile development
aws s3 ls --profile development
aws s3 ls s3://example-bucket/ --profile development

For one command, select a profile through an environment variable. The exact syntax varies by shell:

AWS_PROFILE=development aws s3 ls

Always verify the active identity before making changes:

aws sts get-caller-identity --profile development

Role-based profile example

A profile can use a source profile to assume a role in another account. The source identity must be permitted to assume the role.

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

Use placeholder account IDs and role names in documentation. Confirm the resulting principal with aws sts get-caller-identity.

Credential provider precedence

AWS tools and SDKs use a credential provider chain: an ordered set of sources checked for credentials. The exact order can vary by SDK and configuration, but these sources are common:

When a command behaves unexpectedly, inspect environment variables and the selected profile before changing policies. A default profile can point to a different account, while an environment variable can take precedence over that profile.

Using credentials with S3 requests

AWS Signature Version 4 is the request-signing process commonly used for authenticated S3 API calls. Conceptually, the signer derives a signature from the request method, endpoint, region, headers, request contents, credentials, and request time. S3 verifies the signature before evaluating authorization.

The AWS CLI and AWS SDKs normally sign S3 requests automatically. Application code should use an SDK credential provider chain rather than manually signing requests unless there is a specific advanced requirement. Incorrect regions, endpoints, secret values, or system clocks can cause signature failures.

Authentication and S3 authorization

After S3 authenticates a principal, several policy layers can affect the result:

• Identity policies: permissions attached to an IAM user, group, or role.
• Bucket policies: resource-based policies attached to a bucket.
• Access point policies: policies controlling requests through an S3 access point.
• ACLs: legacy object or bucket controls that may still matter in configurations where ACLs are enabled.
• Service control policies: AWS Organizations guardrails that can limit accounts or organizational units.
• Other controls: permissions boundaries, VPC endpoint policies, encryption-key policies, and policy conditions.

An explicit deny overrides an applicable allow. Therefore, valid credentials do not guarantee access.

Practical credential patterns

Application on an EC2 instance

Attach an IAM role to the EC2 instance and grant it narrowly scoped S3 read or write permissions. The AWS SDK can retrieve and refresh instance-role credentials automatically. The application should not contain an access key or secret.

Cross-account upload

For an upload into a bucket in another account, the caller must be authenticated and the relevant identity and resource policies must authorize the operation. Common designs use a role in the target account that the source principal can assume, or a bucket policy that recognizes the source principal. Use a named role profile or an approved role-assumption workflow, then verify the assumed identity.

Temporary developer session

An approved federation or role-assumption process can provide short-lived credentials. Set all three values together when using environment variables:

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

Do not place real values in documentation, shared scripts, shell history, or tickets. Refresh the session after it expires.

Credential security for S3

• Never expose access keys in public repositories, client-side code, logs, tickets, screenshots, or container images.
• Use MFA for privileged human access and protect the identity provider.
• Limit key lifetime, rotate keys, deactivate unused keys, and monitor use.
• Use AWS CloudTrail and related monitoring to investigate API activity.
• Use separate profiles or accounts for development, test, and production.
• Grant access to only the required bucket, prefix, actions, and encryption resources.

Responding to an exposed secret key

1. Immediately deactivate the exposed key.
2. Review CloudTrail and other audit records for suspicious use.
3. Replace the credential only if the workload still requires it, storing the replacement securely.
4. Remove the disclosure from source files, configuration, logs, and repository history where possible.
5. Treat the original key as compromised even if the visible text is later deleted.

Troubleshooting S3 credentials and access

Diagnostic checklist

1. Run aws sts get-caller-identity with the exact profile or environment used by the failing command.
2. Check for stale values in AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and AWS_PROFILE.
3. Confirm that temporary credentials have not expired and that the SDK can refresh them.
4. Check the AWS Region, bucket name, endpoint, and system clock.
5. Identify the exact S3 action, object prefix, and resource ARN being requested.
6. Review identity policies, bucket or access point policies, organization controls, permissions boundaries, endpoint policies, encryption-key policies, and explicit denies.

Exam-relevant notes

• Authentication identifies a principal; authorization determines permitted actions.
• Temporary credentials generally require an access key ID, secret access key, and session token.
• IAM roles are preferred for AWS workloads because they avoid distributing permanent keys.
• An IAM role is assumed; it is not the same as an IAM user access key.
• Explicit deny overrides allow.
• s3:ListBucket concerns listing a bucket, while object reads, writes, and deletes commonly use s3:GetObject, s3:PutObject, and s3:DeleteObject.
• Always confirm the active principal before troubleshooting an S3 authorization error.

For related configuration guidance, see AWS CLI credential configuration and S3 credential access concepts.