Choose how Atlan connects to Amazon S3
Pick the identity Atlan uses to read your Amazon S3 metadata - a cross-account IAM role it borrows, or an IAM user whose keys you hand over.
Atlan reads your S3 metadata over AWS's own APIs - there are no IPs to allowlist and no private links to build. What you choose is an identity: either a cross-account IAM role Atlan borrows, or an IAM user whose keys you hand over. This page helps you pick in two minutes.
Unlike database connectors, there is no hostname, port, firewall, or IP allowlist involved. Every failure mode is an AWS permission decision: who may borrow the role, what the role may read, what the bucket allows, and whether the encryption key cooperates. If you've never touched AWS IAM, read How cross-account access works first - it defines every term.
Before you start: Three facts you need
| Fact | How to find it |
|---|---|
| Which AWS account and region your buckets live in | Ask your AWS administrator. Each bucket has exactly one region - you'll enter it in the crawler form, and a wrong region fails with a PermanentRedirect error. |
| Whether your buckets are encrypted with a customer-managed KMS key (SSE-KMS) | AWS Console → your bucket → Properties → Default encryption. If it names a KMS key you created, the key's policy also needs an Atlan entry - see Bucket policies, KMS keys, and prefix scoping. |
| Roughly how many objects you'll catalog | Under ~1 million: direct ingestion. Over that: set up S3 inventory reports first - direct crawls of multi-million-object buckets time out. See Special cases. |
Compare two methods
| Cross-account IAM role (recommended) | IAM user (access keys) | |
|---|---|---|
| What Atlan gets | Permission to temporarily "borrow" a role in your account - no secret ever leaves AWS | A long-lived Access Key ID + Secret Access Key you paste into Atlan |
| Security posture | Short-lived credentials, revocable instantly, auditable in CloudTrail, External ID protection available | Static secret; you own rotation and leak risk |
| Who is involved | You + your AWS admin + Atlan support (two ticket round-trips today) | You + your AWS admin only - fully self-serve |
| Typical setup time | 1–3 business days (support handshake dominates) | Under an hour |
| Best for | Production - the recommended path | Proof-of-concepts, sandboxes, orgs that can't do cross-account trust |
| Start here | IAM role setup guide | Access keys setup guide |
Both methods are documented in detail in Set up Amazon S3.
Which method to pick
- Pick the IAM role for anything production. No secret is ever created or stored, access is revocable by editing one policy, and your security team can require an External ID. Budget for the support handshake - two values come from Atlan support today (see Atlan identity details).
- Pick access keys when you need to be crawling within the hour (POCs), or your organization prohibits cross-account role trust. Plan to rotate the keys and to migrate to the role later.
Whichever identity you choose, it needs the same S3 permission policy. The single most common failure is a policy missing one action - usually s3:ListAllMyBuckets, which the Test connection button requires and which cannot be scoped to a bucket (it only works with "Resource": "*").
See also
- How cross-account access works: The 5-minute explainer - roles, trust policies, External IDs, and why "AssumeRole" appears in your error messages.
- Atlan identity details: The two Atlan-side values every role setup needs, and exactly how to get them.
- Set up S3 access with a cross-account IAM role: Five phases, each labeled with who performs it and how long it takes.
- Bucket policies, KMS keys, and prefix scoping: The "second doors" that block crawls even when the role works.