Skip to main content

Choose how Atlan connects to AWS Glue

TL;DR

Pick how Atlan proves its identity to AWS Glue - IAM access keys, a cross-account IAM role, or the self-deployed agent.

Connect

Atlan reads metadata from your AWS Glue Data Catalog by calling AWS APIs - there is no database hostname, port, or JDBC driver involved. What you choose is how Atlan proves who it's to AWS. This page helps you pick in about two minutes.

Good news: no firewall changes needed on your side

Unlike a database connector, the Glue connector talks to AWS's own public API endpoints (glue.<region>.amazonaws.com) over TLS. You don't need to allowlist Atlan IP addresses in your VPC or open any inbound ports. Everything on this page is about identity and permissions, not networking.

Before you start: Three facts you need​

Every path below depends on knowing these. Gather them first.

FactHow to find it
The AWS account ID that holds your Glue Data Catalog (12 digits)Ask your AWS administrator, or check the account menu in the top-right of the AWS console. If your tables live in more than one account, note all of them - see Special cases.
The AWS region of that catalog (for example, us-east-1)The Glue Data Catalog is per-region: a catalog in us-east-1 and one in eu-west-1 are separate catalogs, even in the same account. One Atlan connection reads one region.
Who manages IAM in your organizationBoth methods below need someone who can create IAM policies and either an IAM user or an IAM role. If a security/cyber team must review trust-policy changes, involve them early - it's the longest step.

Compare three methods​

IAM access keysCross-account IAM roleSelf-deployed agent
How Atlan authenticatesA fixed key pair (access key ID + secret) for an IAM user you createAtlan's own AWS identity temporarily "borrows" a role you create (sts:AssumeRole)Extraction runs on infrastructure inside your own network
Long-lived secrets to manageYes - and rotating them without updating Atlan is the #1 cause of sudden failuresNo - credentials are short-lived and issued by AWS automaticallyDepends on your agent configuration
Who is involvedYou + your AWS adminYou + your AWS admin + Atlan support (a two-ticket handshake)Your infrastructure team + Atlan support
Typical setup timeUnder an hour1–3 business days (includes the allowlist handshake)Days
Security postureAcceptable with tight key rotation disciplineRecommended - most security teams prefer itFor strict environments where extraction must stay in-network
Start hereAccess-keys guideCross-account role guideSelf-deployed runtime docs

Which method to pick​

  • Pick the cross-account IAM role if you can. No secret is ever stored, AWS rotates credentials automatically, and it's the pattern most enterprise security teams require. Budget for the two-ticket handshake with Atlan support - it's quick, but it's mandatory and often missed.
  • Pick IAM access keys for a fast proof-of-concept, or when your organization can't approve cross-account trust policies quickly. Set a reminder wherever you track key rotation: when these keys rotate, the Atlan connection must be updated on the same day.
  • Pick the self-deployed agent only if policy forbids Atlan's SaaS from holding any AWS credential - the agent runs extraction inside your network and supports the same credential fields plus an optional External ID.
The role method has two halves - and both are required

A cross-account role needs a change on your side (the trust policy) and a change on Atlan's side (allowlisting your role). Doing only your half produces an "Access denied when assuming role" error even though your setup is correct. The role guide walks through both halves in order.

See also​