Connect with IAM access keys
The fastest path to connect Atlan to Amazon Athena - create a dedicated IAM user, attach the Atlan policy, and paste its access keys into Atlan.
The fastest path: create a dedicated IAM user, attach the Atlan policy, and paste its access keys into Atlan. Fully self-serve - no support ticket - but the keys are a long-lived secret your team must manage.
Prerequisites
- Someone with IAM administrator access in the AWS account hosting Athena.
- Confirmation that your security policy permits long-lived access keys. If not, use the IAM role guide.
- Your Athena region and S3 output location (see the role guide prerequisites).
Two phases at glance
| Phase | What happens | Owner | Typical time |
|---|---|---|---|
| 1. Create the user | IAM user + policy + access keys | Your AWS admin | 20–30 minutes |
| 2. Connect & verify | Enter keys in Atlan and test | Atlan User | 15 minutes |
Phase 1 - Create IAM user
Owner: Your AWS admin
- Create an IAM policy with the permissions in Permissions & the S3 results bucket (Glue + Athena + S3 results bucket, plus Lake Formation / KMS if your account uses them).
- Create an IAM user (suggested name:
atlan-athena-user), attach the policy. No console access needed - programmatic access only. - Create an access key pair and download it immediately - this is your only opportunity to view or download the access keys.
Use a dedicated user for Atlan rather than sharing an existing one. When keys rotate or you offboard the integration, you can do it without breaking anything else - and Athena's login history stays attributable.
Phase 2 - Connect and verify
Owner: Atlan User
- In Atlan, open New workflow → Athena Assets.
- Fill the credential form: Host
athena.<region>.amazonaws.com, Authentication IAM User → paste the access key and secret key, S3 Output Location, and Workgroup (defaultprimary). - Click Test Authentication, then run the same success checklist as the role guide.
Key rotation
When your security team rotates the user's keys, the connection fails with an authentication error at the next run - often months after setup, when nobody remembers the dependency. Two habits prevent surprise breakage:
- Tag the IAM user (e.g.
used-by: atlan) so rotation runbooks flag the downstream update. - Update the keys in the Atlan connection at rotation time: edit the connection's credentials and re-test.
If your Atlan tenant runs on Azure rather than AWS and you see unexpected sts:AssumeRole errors while using access keys, quote that error and your tenant's hosting cloud in a support ticket rather than debugging your IAM setup - a past platform issue caused exactly this signature (since fixed).
Next steps
Crawl Amazon Athena: Configure and run the crawler to extract metadata from Athena