# Amazon Quick em rede privada: os dois planos do PrivateLink e onde eles vazam

Deixar o Amazon Quick fora da internet pública não é um recurso que você liga. São dois mecanismos diferentes, um para quem entra e outro para o que o Quick busca, e cada um falha de um jeito. Este texto mostra como cada plano funciona, onde a promessa de "tudo privado" deixa de valer e o que eu configuraria antes de chamar o desenho de compliance.

- URL: https://fernando.moretes.com/blog/amazon-quick-em-rede-privada-os-dois-planos-do-privatelink-e-onde

- Markdown: https://fernando.moretes.com/blog/amazon-quick-em-rede-privada-os-dois-planos-do-privatelink-e-onde/article.md?lang=pt

- Published: 2026-10-23T10:13:57.656Z

- Category: AWS & Cloud

- Tags: amazon-quick, privatelink, vpc-endpoints, zero-trust, network-security, compliance, ai-agents

- Reading time: 7 min

- Source: [Securing Quick access from corporate networks with AWS PrivateLink](https://aws.amazon.com/blogs/machine-learning/securing-quick-access-from-corporate-networks-with-aws-privatelink/)

---

Quando alguém de compliance pergunta se o Amazon Quick "passa pela internet", a resposta honesta tem duas partes, e quase todo desenho que eu revisei responde só uma. O tráfego do usuário até o Quick usa endpoints de interface do PrivateLink. O tráfego do Quick até o seu banco on-premises, ao seu servidor MCP privado ou à sua API interna usa outra coisa: ENIs que o próprio Quick injeta na sua VPC. Sobre esses dois planos ficam DNS, política de endpoint, restrição por IP/VPC e IAM, e cada camada cobre menos do que o nome sugere. A pergunta útil não é "está privado?", é "qual byte ainda sai para a internet, e quem decidiu que tudo bem?".

## Por que isso apareceu agora

Enquanto o Quick era só BI, a VPC connection servia para o Quick Sight ler PostgreSQL, SQL Server ou Oracle atrás de um Direct Connect. O problema era conhecido e o blast radius cabia num dashboard. O que mudou é quem usa essa mesma VPC connection. Agora passam por ela Quick Agents chamando servidores MCP hospedados na sua rede, Quick Flows e Quick Automate acionando action connectors, Quick Research e Apps in Quick buscando fontes privadas. A ENI que antes fazia `SELECT` para um painel agora carrega chamada de ferramenta de um agente.

Em ambiente financeiro isso pesa em dois lugares. **Regulação:** a Resolução CMN 4.893 e o PCI-DSS pedem que você mostre o caminho do dado e controle quem entra no perímetro. O post da AWS cita HIPAA, FedRAMP e PCI-DSS como gatilhos típicos. **Auditoria:** "o tráfego fica no backbone da AWS" só vale como evidência se você souber dizer quais domínios ainda saem por NAT, e eles existem.

O post de 21/10/2026 é um bom passo a passo. O que ele não faz, e não é papel dele, é dizer onde cada controle para de valer. É disso que este texto trata: os limites documentados de cada camada e o custo de manter isso funcionando por anos, não o de montar uma vez.

## Os dois planos do acesso privado ao Quick, e o que continua público

Entrada (usuário até o Quick) por endpoints de interface. Saída (Quick até os seus dados) por ENIs da VPC connection. As linhas tracejadas são o tráfego que nenhum endpoint cobre.

### 🏢 On-premises: rede corporativa

- DNS corporativo forward de <region>.quicksight.aws.amazon.com (network)
- Oracle / SQL Server porta do banco liberada só para o SG do Quick (data)
- Servidor MCP privado API interna por IP (compute)

### 📡 Rede: Direct Connect ou Site-to-Site VPN

- Direct Connect rota para o CIDR da VPC (network)

### 🟧 AWS: VPC do cliente (2 AZs no mínimo)

- Route 53 Resolver inbound 2+ ENIs (network)
- VPCE quicksight-website policy só com aws:PrincipalAccount / aws:OrgId (security)
- VPCE quicksight (API) policy por ação; 13 APIs fora (security)
- ENIs da VPC connection SG QuickSight-VPC, VPC ID imutável (network)
- VPCE secretsmanager / redshift / glue S3 por gateway (security)

### 🤖 AWS: Amazon Quick (Enterprise)

- Quick Sight, Agents, Flows, Automate Identity Center, RLS/CLS (ai)

### 🌐 Externo: saída pública que continua obrigatória

- *.cloudfront.net, *.execute-api, *.kinesisvideo sign-in do Identity Center (external)

### Fluxos

- user -> dns: resolve o nome do site
- dns -> resolver: forward da zona privada
- user -> dx: HTTPS 443
- dx -> vpce-web: console e dashboards
- dx -> vpce-api: chamadas de API
- vpce-web -> quick: PrivateLink (entrada)
- vpce-api -> quick: PrivateLink (entrada)
- quick -> eni: assume execution role, usa ENIs
- eni -> dx: saída de dados e tool calls
- dx -> db: query SQL
- dx -> mcp: action connector / MCP
- eni -> sm: credenciais sem sair da VPC
- user -> public: assets, métricas, login via NAT/proxy

## Plano de entrada: endpoints de interface, DNS e o que a política aceita

A entrada usa dois endpoints de interface com papéis diferentes: `com.amazonaws.<region>.quicksight-website` para o site e `com.amazonaws.<region>.quicksight` para a API (com variante `-fips`). Se administradores entram como usuário IAM, entram também `console` e `signin`. Coloque cada um em pelo menos duas AZs, com security group aceitando só 443 a partir do CIDR corporativo.

**DNS é onde a primeira coisa quebra.** O endpoint da API, com private DNS ligado, assume `quicksight.<region>.amazonaws.com` sozinho. O do site não: o nome privado dele não é a URL pública. Você cria uma private hosted zone para `<region>.quicksight.aws.amazon.com`, com registro A alias apontando para o endpoint. Só que a private hosted zone responde apenas a VPCs associadas, então o DNS corporativo precisa encaminhar essa zona para um Route 53 Resolver inbound endpoint. Sem esse forward, o navegador resolve o IP público, o acesso funciona e ninguém percebe que o PrivateLink está sendo contornado. Teste com `nslookup` de dentro da rede corporativa e espere um IP do CIDR da VPC.

**A política do endpoint do site é quase decorativa.** `Principal`, `Action` e `Resource` precisam ser `"*"`, e a condição só aceita `aws:PrincipalAccount` ou `aws:OrgId`. Ela impede que a sua rede vire porta de entrada para o Quick de outra conta, o que é útil contra exfiltração, mas não controla o que o usuário faz. O endpoint da API aceita restrição por ação, e é ali que vale ser específico.

## Plano de saída: a VPC connection é ENI injetada, não PrivateLink

Quando o Quick precisa buscar dado, ele não passa pelo endpoint de interface. Ao criar uma VPC connection (só no Enterprise), você entrega VPC ID, pelo menos duas subnets em AZs diferentes, ao menos um security group e uma execution role que confia em `quicksight.amazonaws.com`. O Quick assume essa role e cria ENIs nas suas subnets com `ec2:CreateNetworkInterface`. Daí em diante vale a sua rede: route table, NACL, security group e a rota do Direct Connect.

Três detalhes viram incidente se você não souber deles. **O VPC ID não muda depois da criação:** reorganizar a rede significa recriar a conexão e reapontar cada data source. **O status `PARTIALLY AVAILABLE`** indica uma ENI fora com a conexão ainda funcionando. É exatamente o estado que ninguém monitora até a segunda AZ cair. **Conexões criadas antes de 27/04/2023 usam security group não stateful** e precisam de regra de entrada liberando o retorno em todas as portas (0–65535) a partir do SG da fonte. Se a sua ainda é dessa época, recrie.

Para nomes de banco on-premises, informe os IPs do Resolver inbound no campo de DNS resolver endpoints. Sem isso o Quick resolve pelo DNS público e não acha o host. Credenciais vão para o Secrets Manager por endpoint de interface na mesma VPC das ENIs, para que nem a busca da senha saia pela NAT.

Uma limitação muda o desenho: a VPC connection de knowledge base do Quick Index hoje só aceita Amazon Redshift. Confluence, SharePoint, Box, Google Drive, OneDrive e S3 não passam por ela.

> **O security group das ENIs virou a allow-list de rede do agente:** A mesma VPC connection serve o Quick Sight e os Quick Agents chamando MCP privado. Na prática, o egress do SG `QuickSight-VPC` e as rotas dessas subnets definem tudo o que um agente consegue alcançar na sua rede. Se o SG libera o CIDR on-premises inteiro porque "o BI precisava", o agente herda esse alcance. Separe subnets e security groups por finalidade (dados analíticos de um lado, ferramentas de ação do outro), mesmo que isso custe uma segunda VPC connection.

## Forçar só endpoint: onde a restrição para de valer

A restrição de IP/VPC do Quick (`update-ip-restriction --enabled --vpc-endpoint-id-restriction-rule-map vpce-...=Nome`) bloqueia o que não vem do endpoint aprovado. Ela tem quatro propriedades que você precisa conhecer antes de ligar em produção.

**Cobre web, embedded e mobile, mas não a API pública.** Quem tem credencial chama qualquer operação de qualquer IP. Para a API o controle é IAM: uma condição `aws:SourceVpce` ou `aws:SourceIp` em policy de deny, de preferência numa SCP. Aqui está a pegadinha: 13 APIs não funcionam pelo endpoint de interface (as 8 de action connector, como `CreateActionConnector`, e 5 de Flows, como `ListFlows`). Um deny geral por `aws:SourceVpce` quebra a automação que gerencia conectores. Você escreve a exceção com `NotAction` para essas operações e roda essa automação de um caminho controlado com saída pública.

**`UpdateIpRestriction` substitui o mapa inteiro.** Script que manda só a regra nova apaga as outras. Faça `describe-ip-restriction` antes, ou melhor, mantenha o mapa versionado e aplique sempre o estado completo.

**A regra leva até 10 minutos para valer e é global**, aplicada em todas as regiões e gerenciada só pela região da conta. O limite é de 100 regras somadas, com IP e VPC combinados por OR.

**Lockout é real.** Sem regra cobrindo o seu próprio acesso, o console não deixa salvar. Mas quem estava numa origem fora da lista perde o acesso no momento em que você liga. Dashboards com embed público passam a funcionar só pelo endpoint.

## O que continua público, e quanto custa manter o resto privado

A documentação lista os domínios que o navegador acessa, e vários não têm endpoint: `*.cloudfront.net` (CSS e JS), `*.execute-api.<region>.amazonaws.com` (métricas do cliente), `*.kinesisvideo.amazonaws.com` (streaming das automações), `<region>.signin.aws` e, com IAM Identity Center, o login pelo navegador, que exige os endpoints públicos de sign-in e do Identity Center. Não precisa de IP público, mas precisa de NAT ou proxy. O seu relatório de compliance deve dizer "o caminho de dados e de API é privado; assets estáticos, telemetria e autenticação saem por proxy inspecionado". Escrever "zero internet" é afirmar algo que a própria documentação desmente.

Agora o custo recorrente, em `us-east-1`. Endpoint de interface custa US$ 0,01 por hora por ENI, mais US$ 0,01 por GB nos primeiros 1 PB. Site e API em 2 AZs são 4 ENIs, cerca de US$ 29/mês. Somando `console` e `signin`, mais US$ 29. Secrets Manager, Redshift e Glue em 2 AZs, mais uns US$ 44. A peça mais cara é a que ninguém orça: o Resolver inbound endpoint custa US$ 0,125 por ENI por hora, com no mínimo duas, ou cerca de US$ 182/mês, mais US$ 0,40 por milhão de consultas. Se você já tem um Resolver inbound compartilhado numa VPC de rede central, reaproveite: é o maior item da conta e não tem nada de específico do Quick.

## Anti-padrões que eu encontro nesse desenho

- **Endpoint do site sem forward de DNS on-premises:** o PrivateLink existe, o navegador resolve o IP público e o acesso funciona por fora. É uma falha silenciosa que só aparece em `nslookup` ou VPC Flow Logs.
- **Tratar a restrição de IP/VPC como controle da API:** ela não cobre a API pública. Sem `aws:SourceVpce` em IAM ou SCP, uma credencial vazada chama tudo de qualquer lugar.
- **Deny geral por `aws:SourceVpce` sem exceção:** as 13 APIs de action connector e Flows não passam pelo endpoint, e a automação que gerencia conectores para de funcionar sem erro óbvio.
- **Script que chama `UpdateIpRestriction` só com a regra nova:** o mapa é substituído por inteiro, as outras regras somem e uma filial inteira perde acesso em até 10 minutos.
- **Uma VPC connection para BI e agentes com o CIDR on-premises inteiro liberado:** o agente herda o alcance de rede do BI e o blast radius de um prompt injection vira a rede corporativa.
- **Manter VPC connection anterior a 27/04/2023:** o SG não stateful exige retorno liberado em 0–65535, uma regra que nenhum auditor aceita sem pergunta.

## Lente Well-Architected

- **security**: Defesa em camadas com papéis claros: política do endpoint do site limitada por `aws:OrgId`, política do endpoint da API por ação, restrição de IP/VPC para web e mobile, SCP com `aws:SourceVpce` e `NotAction` para as 13 APIs fora do endpoint, RLS e CLS no dado. Mudanças no mapa de restrição ficam no CloudTrail; crie alarme para `UpdateIpRestriction`.
- **reliability**: Duas AZs em todo endpoint e na VPC connection, alarme quando o status sair de `AVAILABLE` (inclusive `PARTIALLY AVAILABLE`) e Direct Connect com VPN de backup, porque a VPC connection não tem outro caminho até o on-premises.

> **O que eu faria:** Eu começaria pelo relatório que vou entregar ao auditor e só depois criaria o primeiro endpoint: quais domínios saem por proxy, quais controles cobrem a API e quais cobrem o navegador. Depois montaria dois security groups e duas VPC connections, uma para dados analíticos e outra para ferramentas de agente, porque já vi um SG "provisório" de BI durar quatro anos. O mapa de restrição iria para código desde o primeiro dia, aplicado como estado completo. A lição que carrego de plataformas financeiras: o controle que custa caro não é o que você configura, é o que você acha que está ativo e não está, e no Quick esse controle se chama forward de DNS.

## Veredito

Use o desenho completo (endpoints de site e API, VPC connection, Resolver inbound, restrição de IP/VPC e SCP com `aws:SourceVpce`) quando você tiver dado regulado on-premises, agentes chamando ferramentas privadas e um auditor que vai pedir o caminho de cada byte. Se o Quick só lê Redshift e S3 na mesma conta e o login é por Identity Center, a VPC connection com endpoints de serviço resolve a maior parte do risco, e a restrição por IP da saída corporativa cobre o navegador por bem menos que US$ 300/mês. Nos dois casos, documente o que continua público. Essa frase é o que separa um desenho defensável de uma promessa que a documentação desmente.

**Rating:** Recomendado com ressalvas / Recommended 

## Referências

- [AWS Machine Learning Blog: Securing Quick access from corporate networks with AWS PrivateLink](https://aws.amazon.com/blogs/machine-learning/securing-quick-access-from-corporate-networks-with-aws-privatelink/)
- [Quick and interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/quicksight/latest/developerguide/vpc-interface-endpoints.html)
- [Managing IP/VPC restrictions in Amazon Quick](https://docs.aws.amazon.com/quicksight/latest/user/enabling-ip-restrictions.html)
- [Configuring VPC connections in Amazon Quick Sight](https://docs.aws.amazon.com/quick/latest/userguide/working-with-aws-vpc.html)
- [AWS PrivateLink pricing](https://aws.amazon.com/privatelink/pricing/)
- [Amazon Route 53 pricing (Resolver endpoints)](https://aws.amazon.com/route53/pricing/)