Private Redshift SSO with EVR: a pattern teardown

In many data architectures, SSO is presented as a user experience feature, but the real problem is boundary control. An analyst signs in through Query Editor v2 or a JDBC/ODBC driver, receives a token from IAM Identity Center, and presents that token to Redshift. The critical point is that Redshift should not accept that token without validation; it must validate scopes, exchange the token for a service-scoped session, and resolve the user and group memberships. If the cluster uses enhanced VPC routing, that validation call must also follow the private design.

The older pattern created an inconsistency: the organization invested in private subnets, an S3 endpoint, bucket policies, KMS, VPC Flow Logs, and then accepted an identity egress exception because authentication had to reach regional services outside the governed path. In banking, insurance, and payments environments, that exception becomes an audit question: what flow left, through which domain, with which justification, and how do I prove it was only used for authentication? The new support provides a cleaner answer: Redshift talks to sso-oauth and identitystore through interface endpoints, with Private DNS, security groups, and network logs.

The practical anatomy has five pieces. First, the provisioned cluster or serverless workgroup must have enhanced VPC routing enabled and must not be publicly accessible. For provisioned clusters, the documentation confirms an important operational detail: changing EVR restarts the cluster, so I would treat it as a maintenance-window change, with communication to BI and ingestion teams.

Second, the VPC must have DNS hostnames and DNS resolution enabled, because the endpoints depend on Private DNS. Without that, the standard service name keeps resolving to public addresses and the observed behavior looks like an IAM problem when it is actually DNS. Third, I create two interface endpoints in the same availability design as Redshift: com.amazonaws.<region>.sso-oauth and com.amazonaws.<region>.identitystore. Both are required; if either is missing or unreachable, IAM Identity Center sign-in fails.

Fourth, the endpoint security group must allow TCP 443 from the subnets or security groups used by Redshift. Fifth, I would not start with an action-restrictive endpoint policy. The documentation itself recommends keeping the default policy or, if corporate policy requires restriction, scoping by principal and validating sign-in. In identity, an elegant policy that blocks token exchange is just a well-written outage.

I would use this pattern when the architecture already has a clear isolation thesis: Redshift in private subnets, S3 accessed through a gateway endpoint, Glue and Lake Formation through interface endpoints when Spectrum or a lakehouse is involved, and internet egress denied by default. This is the common design in financial environments that treat analytics as a production plane, not as a lab. IAM Identity Center authentication improves governance because it centralizes assignments, groups, and sessions; EVR with PrivateLink improves the network posture because it removes the need for NAT or public allow-listing for authentication.

It also makes sense in organizations that need to run Redshift in a different Region from the IAM Identity Center primary Region. IAM Identity Center multi-Region documentation allows replication of identities, permission sets, assignments, sessions, and metadata to additional Regions, with relevant prerequisites: an organization instance, compatible identity source, customer-managed multi-Region KMS key, and support from the applications involved. I would not treat this as a performance button only. It is a resiliency and residency decision: where the data lives, where users are, which Region carries identity authority, and what behavior is acceptable if the primary identity Region is degraded.

The first test is to deliberately break the identitystore endpoint in a non-production environment. If the user can still authenticate, something is wrong: maybe EVR is not active, maybe private resolution is not being used, or maybe there is an undocumented public route. The second test is to remove Private DNS and verify whether the runbook captures the error. Many teams only notice this detail when a DNS incident turns sign-in into an intermittent failure.

I would also validate Region placement. The documentation says to create the endpoints in the IAM Identity Center Region; when Redshift and Identity Center are in different Regions, the design must use the cross-Region endpoint option or multi-Region replication. This is easy to miss in organizations that standardized identity in us-east-1 but created regional data warehouses for residency. Next, I would review adjacent paths: S3 gateway endpoint for COPY/UNLOAD, Glue and Lake Formation if a data lake is involved, KMS for encryption, and policies that do not break federated access.

Finally, I would alarm on symptoms, not only components. Failed connections, p95 session establishment time, CloudTrail denied authentication events, and VPC Flow Logs with no traffic to the expected endpoints are better signals than an endpoint merely being available.

My reference design starts with a Redshift Serverless workgroup or RA3 cluster in private subnets across at least two AZs, with no public access and enhanced VPC routing enabled. I would use IAM Identity Center groups as the human authorization boundary, mapped to Redshift roles by business function: regulatory read, data engineering, risk, fraud, audit. Permission to obtain a token should be explicit: redshift:GetIdentityCenterAuthToken for a provisioned cluster or redshift-serverless:GetIdentityCenterAuthToken for a serverless workgroup, limited to the expected ARNs.

On the network side, I would create sso-oauth and identitystore endpoints with Private DNS, a dedicated security group accepting 443 only from Redshift subnets or SGs, and adjacent endpoints for S3, Glue, and Lake Formation where applicable. For S3, I would still keep bucket policies conditioned on expected origin, KMS encryption, and prefixes separated by data domain. For observability, I would correlate four sources: VPC Flow Logs for endpoint ENIs, CloudTrail for identity and administration calls, Redshift logs/audit for sessions and queries, and client-side connection metrics.

The goal is not to build ornamental fortress architecture. It is to make the architecture explainable: who entered, through which identity, which group authorized it, through which network path the token was validated, which data was queried, and what evidence remains afterward.