## Set up S3 access with IAM access keys

URL: https://docs.atlan.com/apps/connectors/storage/amazon-s3/how-tos/set-up-s3-access-with-iam-access-keys

> The fully self-serve way to connect Atlan to Amazon S3 - create an IAM user, attach the permission policy, and paste its keys into Atlan.

The fully self-serve method: create an IAM user, attach the same permission policy, and paste its keys into Atlan. Faster than the role, weaker security posture - best for POCs.

## When to use this

- You need to be crawling today and can't wait for the role handshake.
- Your organization prohibits cross-account role trust.
- Otherwise, prefer the [IAM role](https://docs.atlan.com/llms/connectors/amazon-s3/set-up-s3-access-with-a-cross-account-iam-role/llms.txt) - it's the recommended path for production.

## Steps

1. *Your AWS admin* - Create the permission policy exactly as in [Phase 2 of the role guide](https://docs.atlan.com/llms/connectors/amazon-s3/set-up-s3-access-with-a-cross-account-iam-role/llms.txt) (same actions, same `ListAllMyBuckets`-on-`*` rule).
2. *Your AWS admin* - In the IAM console, create a user (suggested name: `atlan-s3-crawler`) with **no console access**, attach the policy, and generate an access key (type: third-party service).
3. *Atlan User* - **New workflow → Amazon S3 Assets**, choose **IAM User** authentication, and enter the Access Key ID, Secret Access Key, and your buckets' **region** directly in the credential form.
4. Click **Test Authentication**, then configure filters and run.

:::danger Keys are secrets - handle accordingly

Enter keys **only** in the Atlan credential form (they're stored encrypted). Never paste them into a support ticket, email, or chat. If a key is ever exposed, deactivate it in the IAM console immediately and generate a new one - Atlan only needs the new pair entered in the connection's credential settings.

:::

:::tip Set a rotation reminder now

Access keys don't expire on their own. Follow your organization's rotation policy (90 days is a common default): generate a second key for the user, update the Atlan credential, confirm a crawl succeeds, then deactivate the old key - zero downtime.

:::

## Everything else is identical to the role path

Bucket policies, KMS key policies, prefix scoping, region, and inventory ingestion behave exactly the same for a user as for a role - a KMS key policy that only names the role will still block the user. Continue with [Bucket policies, KMS keys, and prefix scoping](https://docs.atlan.com/llms/connectors/amazon-s3/bucket-policies-kms-keys-and-prefix-scoping/llms.txt), and use the same [success checklist](https://docs.atlan.com/llms/connectors/amazon-s3/set-up-s3-access-with-a-cross-account-iam-role/llms.txt).

:::note Known platform quirk - Azure-hosted Atlan tenants

A past Azure-hosted-tenant bug forced role assumption even when IAM *user* auth was chosen, failing with an `AssumeRole` error that made no sense for key-based auth (since fixed). If you see AssumeRole errors while using access keys, it's not your configuration - [raise a ticket](https://docs.atlan.com/support/submit-request) citing that symptom.

:::

## Next steps

[Crawl S3](https://docs.atlan.com/llms/connectors/amazon-s3/crawl-s3/llms.txt): Configure and run the crawler to extract metadata from Amazon S3

---