Private Redshift SSO with EVR: a pattern teardown

On August 31, 2026, AWS announced that Amazon Redshift now supports authentication through AWS IAM Identity Center for provisioned clusters and serverless workgroups configured with enhanced VPC routing. The change looks small in the console, but it closes a recurring gap in regulated analytics platforms: it was common to keep data, COPY/UNLOAD, and S3 integrations on a private path while part of authentication still required an egress exception. My reading is simple: when the warehouse is financial-grade, subject to data residency, network segregation, and operational evidence, identity is production traffic too.

The problem: SSO was not enough when the network was the control

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.

Private authentication flow with Redshift EVR

The diagram shows the core idea: the client still obtains corporate identity, but the calls made by Redshift to validate and resolve identity traverse private endpoints inside the VPC.

🧑‍💻 Client access

Query Editor v2 / JDBC presents Identity Center token (frontend)

🟧 AWS VPC, analytics subnet

Amazon Redshift EVR enabled, not public (data)
Interface endpoint sso-oauth, Private DNS (network)
Interface endpoint identitystore, TCP 443 (network)
S3 gateway endpoint COPY / UNLOAD path (storage)

🔐 Regional identity plane

IAM Identity Center OIDC + assignments (security)
Identity store groups and users (security)

📊 Evidence layer

VPC Flow Logs endpoint traffic evidence (network)
CloudTrail identity/API evidence (security)

Flows

analyst -> query: signs in with corporate credentials
query -> redshift: opens connection with token
redshift -> ssoep: validates and exchanges token
ssoep -> idc: PrivateLink
redshift -> idstoreep: resolves user and groups
idstoreep -> groups: PrivateLink
redshift -> s3ep: data through EVR
ssoep -> flowlogs: flow metadata
idc -> cloudtrail: authentication events

Anatomy of the pattern

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.

When to use it: residency, audit, and closed lakehouse design

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.

Architectural reading of before and after

Criterion	Without this pattern	With Redshift EVR + private IAM Identity Center
Network boundary	Data may be private, but authentication requires egress or firewall exceptions.	Data and identity validation follow private endpoints governed by the VPC.
Operational evidence	Audit depends on proxy, NAT, or external inspection logs, often incomplete.	VPC Flow Logs, CloudTrail, and Redshift logs can be correlated by time window and user.
Failure mode	Failures appear as generic timeouts or SSO errors that are hard to separate from IAM.	Failures tend to concentrate around private DNS, missing endpoint, SG 443, or wrong Region.

Real failures I would test before calling it done

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.

Well-Architected applied to the pattern

security: The primary gain is reducing egress exceptions and aligning authentication, authorization, and data with the same perimeter. I would combine SSO with Redshift RBAC, IAM Identity Center groups, customer-managed KMS when required, CloudTrail, and endpoint policies only after functional testing.
reliability: The new dependency is not Identity Center itself, but private connectivity to it. Treat DNS, endpoint AZs, security groups, and Region as availability components. For multi-Region, validate IAM Identity Center prerequisites and document failover behavior.

Reference design for a financial-grade environment

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.

Anti-patterns this launch does not fix by itself

Enabling EVR in production without a change window for a provisioned cluster, ignoring that the change restarts the cluster.
Creating only one of the two required endpoints and investigating the error as if it were a password, group, or driver issue.
Disabling public access while keeping broad NAT as a silent path to AWS services and SaaS without purpose-level evidence.
Copying restrictive endpoint policies from another service and blocking internal validation or identity resolution calls.
Using SSO as a substitute for authorization modeling in Redshift; centralized identity does not remove RBAC, masking, secure views, and grant reviews.

Minimum acceptance test: I would only call the change ready after proving three things: SSO sign-in works without a public route, a controlled break of each endpoint fails predictably, and a COPY/UNLOAD query still uses the expected private path. This test belongs in the runbook, not only in the memory of whoever deployed it.

My curator note: I would implement this pattern first in warehouses that carry regulated data or executive reporting, not across every environment by impulse. The lesson I learned in financial platforms is that network exceptions age poorly: they start as pragmatism and end as audit debt. When identity, data, and operational evidence follow the same private design, the conversation with security moves from opinion to proof.

Verified references

Verdict

My recommendation is to adopt Redshift with IAM Identity Center over EVR whenever the warehouse operates under residency, network isolation, or strong audit-trail requirements. The pattern does not replace authorization modeling, data governance, or observability, but it removes an important inconsistency: authentication stops being an exception and becomes part of the private perimeter. For less regulated environments, I would weigh endpoint operational cost and team maturity before standardizing; for sensitive financial data, I would treat this design as a baseline.

Rating: recommended-for-regulated-analytics

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.