# Private Redshift SSO with EVR: a pattern teardown

I see this launch as an important architectural correction: authentication now follows the same private path as analytical data. For regulated environments, the gain is not only SSO; it is removing a network exception that is hard to defend in audit.

- URL: https://fernando.moretes.com/blog/redshift-sso-privado-com-evr-padrao-de-teardown-amazon-redsh

- Markdown: https://fernando.moretes.com/blog/redshift-sso-privado-com-evr-padrao-de-teardown-amazon-redsh/article.md?lang=en

- Published: 2026-09-01T20:21:04.962Z

- Category: AI & Agents

- Tags: Redshift, IAM Identity Center, PrivateLink, EVR, Analytics, Zero Trust, Data Governance, AWS

- Reading time: 6 min

- Source: [Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-idc-evr)

---

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

- [AWS What's New: Amazon Redshift now supports AWS IAM Identity Center authentication with enhanced VPC routing](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-redshift-supports-idc-evr/)
- [Amazon Redshift documentation: Using AWS IAM Identity Center authentication with enhanced VPC routing](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-access-control-idp-connect-evr.html)
- [AWS Big Data Blog: Integrate Amazon Redshift and IAM Identity Center with enhanced VPC routing](https://aws.amazon.com/blogs/big-data/integrate-amazon-redshift-and-iam-identity-center-with-enhanced-vpc-routing/)
- [Amazon Redshift documentation: Controlling network traffic with enhanced VPC routing](https://docs.aws.amazon.com/redshift/latest/mgmt/enhanced-vpc-routing.html)
- [Amazon Redshift documentation: Connect with Identity-enhanced IAM role sessions](https://docs.aws.amazon.com/redshift/latest/mgmt/identity-center-authentication.html)
- [AWS IAM Identity Center documentation: Using IAM Identity Center across multiple AWS Regions](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html)
- [Amazon VPC documentation: Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)

## 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