Redshift SSO privado com EVR: padrão de teardown
Em 31 de agosto de 2026, a AWS anunciou que o Amazon Redshift passou a aceitar autenticação pelo AWS IAM Identity Center em clusters provisionados e workgroups serverless com enhanced VPC routing. A mudança parece pequena no console, mas fecha uma lacuna recorrente em plataformas analíticas reguladas: antes, era comum tratar dados, COPY/UNLOAD e integrações com S3 por um caminho privado, enquanto parte da autenticação ainda exigia uma exceção de saída. Minha leitura é simples: quando o warehouse é financeiro, sujeito a residência de dados, segregação de rede e evidência operacional, identidade também é tráfego de produção.
O problema: SSO não bastava quando a rede era o controle
Em muitas arquiteturas de dados, SSO é vendido como experiência de usuário, mas o problema real é controle de fronteira. Um analista entra pelo Query Editor v2 ou por um driver JDBC/ODBC, recebe um token do IAM Identity Center e apresenta esse token ao Redshift. O ponto crítico é que o Redshift não deveria aceitar esse token sem validação; ele precisa validar escopos, trocar o token para uma sessão do serviço e resolver usuário e grupos. Se o cluster está com enhanced VPC routing, essa chamada de validação também precisa seguir o desenho privado.
O padrão antigo criava uma incoerência: a organização investia em subnets privadas, endpoint S3, políticas de bucket, KMS, VPC Flow Logs e, em seguida, aceitava uma exceção para identidade porque a autenticação precisava alcançar serviços regionais fora do caminho controlado. Em ambientes de banco, seguros e pagamentos, essa exceção vira pergunta de auditoria: qual fluxo saiu, por qual domínio, com qual justificativa, e como eu provo que só foi usado para autenticação? O novo suporte permite responder de forma melhor: o Redshift conversa com sso-oauth e identitystore via endpoints de interface, com Private DNS, security groups e logs de rede.
Fluxo privado de autenticação com Redshift EVR
O desenho mostra a ideia central: o cliente ainda obtém identidade corporativa, mas as chamadas feitas pelo Redshift para validar e resolver a identidade atravessam endpoints privados dentro da VPC.
- Query Editor v2 / JDBC · presents Identity Center token
- Amazon Redshift · EVR enabled, not public
- Interface endpoint · sso-oauth, Private DNS
- Interface endpoint · identitystore, TCP 443
- S3 gateway endpoint · COPY / UNLOAD path
- IAM Identity Center · OIDC + assignments
- Identity store · groups and users
- VPC Flow Logs · endpoint traffic evidence
- CloudTrail · identity/API evidence
Anatomia do padrão
A anatomia prática tem cinco peças. Primeiro, o cluster provisionado ou o workgroup serverless precisa estar com enhanced VPC routing habilitado e não pode ser publicamente acessível. No caso de cluster provisionado, a documentação confirma um detalhe operacional importante: mudar EVR reinicia o cluster, portanto eu trataria isso como alteração de janela, com comunicação para times de BI e ingestão.
Segundo, a VPC precisa ter DNS hostnames e DNS resolution habilitados, porque os endpoints dependem de Private DNS. Sem isso, o nome padrão do serviço continua resolvendo para endereços públicos e o comportamento observado parece um problema de IAM, quando na verdade é DNS. Terceiro, crio dois endpoints de interface no mesmo desenho de disponibilidade do Redshift: com.amazonaws.<region>.sso-oauth e com.amazonaws.<region>.identitystore. Ambos são obrigatórios; se um estiver ausente ou inacessível, o login pelo IAM Identity Center falha.
Quarto, o security group dos endpoints deve aceitar TCP 443 a partir das subnets ou security groups usados pelo Redshift. Quinto, eu não começaria com endpoint policy restritiva por ação. A própria documentação recomenda manter a policy padrão ou, se houver exigência corporativa, restringir por principal e validar o login. Em identidade, uma policy elegante que bloqueia a troca de token é só uma indisponibilidade bem escrita.
Quando usar: residência, auditoria e lakehouse fechado
Eu usaria este padrão quando a arquitetura já tem uma tese clara de isolamento: Redshift em subnets privadas, S3 acessado por gateway endpoint, Glue e Lake Formation por endpoints de interface quando há Spectrum ou lakehouse, e saída à internet negada por padrão. Esse é o desenho comum em ambientes financeiros que tratam analytics como plano de produção, não como laboratório. A autenticação por IAM Identity Center melhora governança porque centraliza atribuições, grupos e sessões; EVR com PrivateLink melhora a postura de rede porque remove a necessidade de NAT ou allow-list público para autenticação.
Também faz sentido em organizações que precisam operar Redshift em uma Região diferente da Região primária do IAM Identity Center. A documentação de multi-Region do IAM Identity Center permite replicar identidades, permission sets, atribuições, sessões e metadados para Regiões adicionais, com pré-requisitos relevantes: instância organizacional, fonte de identidade compatível, chave KMS multi-Region gerenciada pelo cliente e suporte das aplicações envolvidas. Eu não trataria isso como botão de performance apenas. É uma decisão de resiliência e residência: onde estão os dados, onde estão os usuários, qual Região carrega a autoridade de identidade e qual é o comportamento aceito se a Região primária de identidade ficar degradada.
Leitura arquitetural do antes e depois
| Sem este padrão | Com Redshift EVR + IAM Identity Center privado | |
|---|---|---|
| Fronteira de rede | Dados podem estar privados, mas autenticação exige exceções de egress ou firewall. | Dados e validação de identidade seguem endpoints privados governados pela VPC. |
| Evidência operacional | Auditoria depende de logs de proxy, NAT ou inspeção externa, muitas vezes incompletos. | VPC Flow Logs, CloudTrail e logs do Redshift podem ser correlacionados por janela e usuário. |
| Modo de falha | Falhas aparecem como timeout genérico ou erro de SSO difícil de separar de IAM. | Falhas tendem a se concentrar em DNS privado, endpoint ausente, SG 443 ou Region incorreta. |
Falhas reais que eu testaria antes de chamar de pronto
O primeiro teste é deliberadamente quebrar o endpoint identitystore em um ambiente não produtivo. Se o usuário consegue autenticar, algo está errado: talvez EVR não esteja ativo, talvez a resolução privada não esteja sendo usada, ou talvez exista uma rota pública não documentada. O segundo teste é remover Private DNS e observar se o erro é capturado por runbook. Muitas equipes só percebem esse detalhe quando um incidente de DNS transforma login em falha intermitente.
Eu também validaria Região. A documentação diz para criar os endpoints na Região do IAM Identity Center; quando Redshift e Identity Center estão em Regiões diferentes, deve-se usar a opção cross-Region endpoint ou multi-Region replication, conforme o desenho. Esse ponto é fácil de errar em organizações que padronizaram identidade em us-east-1, mas criaram data warehouses regionais por residência. Em seguida, eu revisaria os caminhos adjacentes: S3 gateway endpoint para COPY/UNLOAD, Glue e Lake Formation se houver data lake, KMS para criptografia e políticas que não quebrem acesso federado.
Por fim, eu colocaria alarmes em sintomas, não só em componentes. Métricas de conexão falhando, p95 de estabelecimento de sessão, eventos CloudTrail de autenticação negada e VPC Flow Logs sem tráfego para os endpoints esperados são sinais melhores do que apenas endpoint available.
Well-Architected aplicado ao padrão
Segurança
O ganho principal é reduzir exceções de egress e alinhar autenticação, autorização e dados ao mesmo perímetro. Eu combinaria SSO com RBAC no Redshift, grupos do IAM Identity Center, KMS gerenciado pelo cliente quando exigido, CloudTrail e endpoint policies só depois de teste funcional.
Confiabilidade
A dependência nova não é o Identity Center em si, mas a conectividade privada até ele. Trate DNS, AZs dos endpoints, security groups e Região como componentes de disponibilidade. Para multi-Region, valide os pré-requisitos do IAM Identity Center e documente comportamento de failover.
Desenho de referência para ambiente financeiro
Meu desenho de referência começa com um Redshift Serverless workgroup ou cluster RA3 em subnets privadas de pelo menos duas AZs, sem acesso público e com enhanced VPC routing. Eu usaria grupos do IAM Identity Center como a fronteira de autorização humana, mapeados para roles no Redshift por função de negócio: leitura regulatória, engenharia de dados, risco, fraude, auditoria. A permissão para obter token deve ser explícita: redshift:GetIdentityCenterAuthToken para cluster provisionado ou redshift-serverless:GetIdentityCenterAuthToken para workgroup serverless, limitada aos ARNs esperados.
Na rede, eu criaria endpoints sso-oauth e identitystore com Private DNS, um security group dedicado aceitando 443 somente das subnets ou SGs do Redshift, e endpoints adjacentes para S3, Glue e Lake Formation quando aplicável. Para S3, eu ainda manteria políticas de bucket condicionadas a origem esperada, criptografia com KMS e prefixos separados por domínio de dados. Para observabilidade, eu correlacionaria quatro fontes: VPC Flow Logs para os ENIs dos endpoints, CloudTrail para chamadas de identidade e administração, logs/auditoria do Redshift para sessões e queries, e métricas de conexão do lado do cliente.
O objetivo não é criar uma fortaleza ornamental. É tornar a arquitetura explicável: quem entrou, por qual identidade, qual grupo autorizou, por qual caminho de rede o token foi validado, quais dados foram consultados e que evidência fica disponível depois.
Anti-padrões que este lançamento não corrige sozinho
- Habilitar EVR em produção sem janela de mudança para cluster provisionado, ignorando que a alteração reinicia o cluster.
- Criar apenas um dos dois endpoints obrigatórios e investigar o erro como se fosse problema de senha, grupo ou driver.
- Desabilitar acesso público, mas manter NAT amplo como caminho silencioso para serviços AWS e SaaS sem evidência de finalidade.
- Copiar endpoint policies restritivas de outro serviço e bloquear chamadas internas de validação ou resolução de identidade.
- Usar SSO como substituto de modelagem de autorização no Redshift; identidade centralizada não elimina RBAC, masking, views seguras e revisão de grants.
Teste de aceite mínimo
Eu só chamaria a mudança de pronta depois de provar três coisas: login SSO funciona sem rota pública, a quebra controlada de cada endpoint falha de forma previsível, e uma consulta COPY/UNLOAD continua usando o caminho privado esperado. Esse teste deve estar no runbook, não apenas na memória de quem implantou.
Eu implementaria este padrão primeiro nos warehouses que carregam dados regulados ou relatórios executivos, não em todos os ambientes por impulso. A lição que aprendi em plataformas financeiras é que exceção de rede envelhece mal: começa como pragmatismo e termina como dívida de auditoria. Quando identidade, dados e evidência operacional seguem o mesmo desenho privado, a discussão com segurança muda de opinião para prova.
Referências verificadas
Veredito
Minha recomendação é adotar Redshift com IAM Identity Center sobre EVR sempre que o warehouse operar sob requisitos de residência, isolamento de rede ou trilha de auditoria forte. O padrão não substitui modelagem de autorização, governança de dados ou observabilidade, mas remove uma incoerência importante: autenticação deixando de ser exceção e passando a ser parte do perímetro privado. Para ambientes menos regulados, eu avaliaria o custo operacional dos endpoints e a maturidade do time antes de padronizar; para dados financeiros sensíveis, eu trataria este desenho como baseline.
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.