## Special cases: Serverless & more

URL: https://docs.atlan.com/apps/connectors/data-warehouses/amazon-redshift/how-tos/special-cases-serverless-and-more

> Amazon Redshift Serverless, DC2 clusters, multiple clusters, cross-region and cross-cloud tenants, external (Glue/Spectrum) schemas, and sources reachable only from inside your network.

Redshift Serverless, DC2 clusters, multiple clusters, cross-region and cross-cloud tenants, external (Glue/Spectrum) schemas, and sources reachable only from inside your network.

## Redshift serverless

Serverless has no "cluster" - a **workgroup** provides compute and networking, and a **namespace** holds the data. What changes for connectivity:

| Aspect | Provisioned | Serverless |
|---|---|---|
| Deployment Type field | `Provisioned` | `Serverless` - changes which credential fields appear |
| Database permissions | User + group (`atlan_user` / `atlan_users`) | Role-based: `atlan_role` |
| IAM role auth | Username + role ARN | Role ARN only (no username); the IAM role must carry the tag `RedshiftDbRoles: atlan_role` |
| Private access | Managed VPC endpoint via [the guide](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-a-private-network-link-to-amazon-redshift/llms.txt), or optional **Cluster ID** field with IAM auth | Fill the optional **Workgroup** field; the private-link guide covers provisioned RA3 clusters only - for a private Serverless workgroup, raise a support ticket to confirm the path |
| Query-history mining | Full support (with the `stl_*` grants and `SYSLOG ACCESS UNRESTRICTED`) | Supported via `SYS_QUERY_HISTORY`, `SYS_QUERY_TEXT`, and `SYS_CONNECTION_LOG`; the provisioned `SYSLOG`/`stl_*` grants don't apply |

## DC2 clusters

- **No private network link.** Managed VPC endpoints require RA3 with cluster relocation - DC2 clusters must use [IP allowlisting](https://docs.atlan.com/llms/connectors/amazon-redshift/firewall-and-ip-allowlisting/llms.txt) (publicly accessible) or a self-deployed agent.
- **One workflow per database.** DC2 doesn't support cross-database joins, so set up a separate crawler workflow for each database you want cataloged.

## Multiple clusters, one Atlan tenant

Each cluster needs **its own grant and its own Redshift-managed VPC endpoint** - an existing private link to one cluster doesn't carry a second, even in the same AWS account and VPC. To add a cluster to an existing setup:

- Grant Atlan's account/VPC access on the *new* cluster (Phase 2 of [the guide](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-a-private-network-link-to-amazon-redshift/llms.txt)).
- Reply on a support ticket with the new cluster identifier; Atlan builds another endpoint and returns another private hostname.
- Each Atlan connection uses its own hostname. Label multiple clusters clearly in one ticket to avoid mix-ups.

## Cross-region and cross-cloud tenants

Your cluster doesn't need to be in the same AWS region as your Atlan tenant - and the tenant doesn't even need to be on AWS. Atlan deploys region-specific endpoint networks and privately peers (or tunnels, for Azure/GCP tenants) back to your tenant, and configures the cross-region routing on your behalf. See [Cross-region private network connectivity](https://docs.atlan.com/llms/governance/administration/cross-region-private-network-connectivity/llms.txt). The setup steps are identical - just **state both regions/clouds in your support ticket** so Atlan builds the endpoint in the right place.

## External schemas (AWS Glue / Redshift Spectrum)

- Grant `USAGE` on external schemas backed by S3/Glue; for external schemas backed by another Redshift database, also grant `SELECT ON ALL TABLES`.
- Can't grant on the external schema directly? Create a cloned schema containing metadata views and point Atlan at that instead (see [Set up Amazon Redshift](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-amazon-redshift/llms.txt)).

## Reachable only from inside your network

If Redshift can't be made publicly accessible and the private-link prerequisites can't be met, run extraction *inside* your network with the [self-deployed runtime (agent)](https://docs.atlan.com/llms/platform/self-deployed-runtime/llms.txt): the agent connects to Redshift locally and pushes metadata out to Atlan, so no inbound path to your cluster is ever opened. (The older Docker/Kubernetes offline-extraction modes are sunset - use the self-deployed runtime.)

## See also

- [Choose how Atlan connects to Amazon Redshift](https://docs.atlan.com/llms/connectors/amazon-redshift/choose-how-atlan-connects-to-amazon-redshift/llms.txt): Compare public allowlisting, private network link, and self-deployed agent
- [Set up the AWS private network link to Amazon Redshift](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-a-private-network-link-to-amazon-redshift/llms.txt): Step-by-step guide for RA3 clusters
- [Set up access and authentication](https://docs.atlan.com/llms/connectors/amazon-redshift/set-up-access-and-authentication/llms.txt): Database user, permissions, and authentication methods

---