Atlan identity & network details
What identity Atlan presents to your AWS account for AWS Glue, which values are tenant-specific, and exactly what to request from support in a single ticket.
What identity Atlan presents to your AWS account, which values are tenant-specific, and exactly what to request from support in a single ticket. For how tenant-specific values work across all connectors and clouds, see Atlan Network Details.
Why there is no IP allowlist page for Glue
Atlan's Glue traffic goes to AWS's public Glue API endpoints (glue.<region>.amazonaws.com) over TLS. Access control happens entirely through AWS IAM - your side never receives an inbound connection, so there is nothing to open in a firewall and no Atlan IPs to allowlist for this connector.
If your organization restricts which identities may call your AWS account (service control policies, IAM boundaries), the values below are what your security team asks about.
Which value applies to me?
| Your setup | The Atlan-side identity involved | Where to get it |
|---|---|---|
| IAM access keys | None - the IAM user lives in your account; Atlan only stores its keys (encrypted) | Nothing needed from Atlan |
| Cross-account IAM role | Node instance role ARN - Atlan's per-tenant AWS identity that assumes your role | Support ticket (role guide, Phase 1) |
| Self-deployed agent | Agent runs with credentials you manage in your own network | Self-deployed runtime docs |
Node instance role - tenant-specific, via support
Each Atlan tenant has its own node instance role. A common mistake in multi-environment setups is reusing the dev tenant's ARN in the prod trust policy - the ARNs differ per tenant even for the same organization.
Raise one support request from within Atlan stating:
- Your tenant URL for every environment you're connecting (for example,
example-corp-dev.atlan.com,example-corp.atlan.com) - That you're setting up AWS Glue with role delegation and need the node instance role ARN per tenant
- (If already known) the role name and 12-digit AWS account ID you'll create for each environment - support can then complete the Atlan-side allowlisting in the same ticket instead of a second round-trip
The ARN support returns looks like this (illustrative):
arn:aws:iam::444455556666:role/example-tenant-nodeinstance-role
Where Atlan's Glue traffic goes
| Destination | Purpose | Direction |
|---|---|---|
sts.amazonaws.com / regional STS endpoints | Assuming your cross-account role (role method only) | Atlan → AWS |
glue.<region>.amazonaws.com | Read-only Glue Data Catalog API calls (GetDatabases, GetTables, …) | Atlan → AWS |
All traffic is TLS-encrypted and initiated by Atlan. Nothing connects inbound to your network, and no table data is read - only catalog metadata.
When values change
- The node instance role ARN is stable for the life of your tenant. It can change during a major infrastructure migration - Atlan announces this to tenant admins in advance, and your trust policies need updating.
- If you rename or recreate your IAM role, the Atlan-side allowlist must be updated too - the allowlist names your exact role ARN. Raise a ticket with the new ARN (this also applies when adding roles for new AWS accounts).