Sua aplicação roda em uma subnet privada e chama SQS, SNS ou Secrets Manager. O acesso funciona, mas os bytes passam pelo NAT Gateway e aparecem na fatura. A correção possível é criar um VPC Interface Endpoint para manter esse tráfego dentro da rede da AWS. A parte menos automática é decidir se o endpoint reduz custo ou apenas troca uma linha da conta por outra.
A decisão depende de três dados: quais serviços recebem o tráfego, quantos bytes passam por eles e em quantas zonas de disponibilidade o endpoint precisa existir. Para S3 e DynamoDB, a resposta costuma ser outra: Gateway Endpoint, sem cobrança adicional por hora ou processamento de dados.
O objetivo é sair com uma conta reproduzível, um exemplo em CDK e uma forma segura de confirmar em produção que os bytes deixaram o NAT. Porque descobrir um NAT caro no fim do mês é observabilidade financeira, só que com latência demais.
Versões e pré-requisitos
O exemplo usa aws-cdk-lib 2.268.0 e o pacote de CLI aws-cdk 2.1140.0. A numeração diferente é esperada: os constructs continuam na linha 2.x, enquanto o CLI adotou sua nova numeração. Use AWS CLI v2 para as verificações.
Para validar o template localmente, rode:
npx aws-cdk@2.1140.0 synthIsso sintetiza o stack; não representa um deploy. O cálculo de preços usa us-east-1 (N. Virginia). As tarifas do NAT vêm do CSV AmazonEC2 publicado em 2026-09-04T23:11:17Z, com SKUs efetivos desde 2026-09-01. As tarifas de Interface Endpoint vêm do catálogo AmazonVPC com publicationDate 2026-08-31T09:22:32Z.
Gateway e Interface resolvem problemas diferentes
Os nomes são parecidos, mas os mecanismos e as cobranças não são.
Um Gateway Endpoint atende somente S3 e DynamoDB. Ele adiciona uma rota baseada em prefix list à tabela de rotas da subnet. Não cria ENI, não usa PrivateLink e não tem cobrança adicional por hora nem por processamento de dados. Para uma aplicação dentro da VPC acessando S3 ou DynamoDB, essa deve ser a primeira opção.
Um Interface Endpoint usa AWS PrivateLink e cria uma ENI com IP privado em cada subnet selecionada. Com private DNS habilitado, o hostname público do serviço AWS passa a resolver para esses endereços privados dentro da VPC. É o mecanismo usado para APIs sem Gateway Endpoint, como SQS, SNS e Secrets Manager.
Confundir Gateway com Interface é fácil até a fatura explicar a diferença com notável objetividade.
| Tipo | Serviços e uso comum | Mecanismo | Cobrança do endpoint |
|---|---|---|---|
| Gateway | S3 e DynamoDB dentro da VPC | Rota na route table; sem ENI e sem PrivateLink | Sem cobrança adicional por hora ou dados processados |
| Interface | SQS, SNS, Secrets Manager e outros serviços compatíveis | ENI por subnet/AZ via PrivateLink | Por endpoint por AZ, mais dados processados |
S3 e DynamoDB também oferecem Interface Endpoints, mas isso não torna a opção paga o padrão. Para S3, Interface faz sentido quando o acesso precisa vir de ambiente on-premises, de VPC emparelhada em outra região ou por Transit Gateway. Quando o Gateway Endpoint resolve o caminho dentro da VPC, use o Gateway.
A documentação oficial detalha tanto os Gateway Endpoints quanto a criação de Interface Endpoints.
Preços oficiais e o esboço de payback
Em us-east-1, o NAT Gateway custa US$ 0,045 por hora ativa e US$ 0,045 por GB processado. Um Interface Endpoint custa US$ 0,01 por hora, por endpoint e por AZ. Para dados processados pelo PrivateLink, a primeira faixa, até 1 PB, custa US$ 0,01 por GB; os próximos 4 PB custam US$ 0,006 por GB e o volume acima de 5 PB custa US$ 0,004 por GB.
As referências são as páginas oficiais de preços da VPC e do AWS PrivateLink.
Considere um mês de 720 horas, três AZs, um serviço com Interface Endpoint e um NAT que continuará ativo para acesso real à internet. Isto é um esboço aritmético, não uma medição de produção.
| Componente | Conta mensal sob essas premissas |
|---|---|
| Um NAT mantido | US$ 0,045/h × 720 h = US$ 32,40 |
| Um serviço Interface em três AZs | 3 × US$ 0,01/h × 720 h = US$ 21,60 |
| Diferença por GB movido | US$ 0,045 − US$ 0,01 = US$ 0,035/GB |
| Ponto de equilíbrio do serviço | US$ 21,60 ÷ US$ 0,035/GB ≈ 617 GB/mês |
O custo horário de US$ 32,40 do NAT não entra como economia porque o NAT foi mantido. A redução vem apenas de retirar daquele caminho os bytes destinados ao serviço AWS. Sob essas premissas, um endpoint de SQS em três AZs precisa desviar cerca de 617 GB por mês para compensar seus US$ 21,60 mensais.
Esse limiar muda quando muda o número de AZs, o volume ou a necessidade do NAT. Cada serviço Interface adicional traz sua própria cobrança horária por AZ, mesmo ocioso. Portanto, some SQS, SNS e Secrets Manager separadamente; não trate “PrivateLink na VPC” como uma assinatura única.
CDK: SQS por Interface, S3 e DynamoDB por Gateway
O recorte abaixo usa aws-cdk-lib 2.268.0. O endpoint de SQS recebe uma política que aceita chamadas cujo aws:PrincipalAccount seja a conta do stack. Em seguida, S3 e DynamoDB entram como Gateway Endpoints.
vpc.addInterfaceEndpoint('SqsEndpoint', {
service: ec2.InterfaceVpcEndpointAwsService.SQS,
subnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
policy: new iam.PolicyDocument({
statements: [
new iam.PolicyStatement({
principals: [new iam.AnyPrincipal()],
actions: ['sqs:*'],
resources: ['*'],
conditions: {
StringEquals: { 'aws:PrincipalAccount': Stack.of(this).account },
},
}),
],
}),
});
vpc.addGatewayEndpoint('S3Gateway', {
service: ec2.GatewayVpcEndpointAwsService.S3,
});
vpc.addGatewayEndpoint('DdbGateway', {
service: ec2.GatewayVpcEndpointAwsService.DYNAMODB,
});SNS e Secrets Manager são outros candidatos a Interface Endpoint, mas não vale repetir três vezes o mesmo construct antes de medir três fluxos diferentes.
A política padrão de endpoint permite Principal *, Action * e Resource *. Conveniente, como toda permissão que deixa a revisão de menor privilégio para uma sexta-feira futura. A documentação de políticas de VPC Endpoint deixa dois limites importantes: a política do endpoint não substitui as políticas IAM de identidade, e nem todo serviço aceita endpoint policy.
Para chaves globais com identificadores gerados pelo sistema, como aws:PrincipalAccount e aws:SourceVpc, não use wildcard; aplique StringEquals com um identificador concreto. Em Gateway Endpoints, o Principal precisa ser *; quando for necessário restringir o principal, use uma condição com aws:PrincipalArn. Já aws:SourceVpce costuma pertencer à policy do recurso, como uma bucket policy do S3, e não substitui a policy do endpoint.
Para private DNS funcionar, a VPC precisa ter DNS hostnames e DNS resolution habilitados. O security group do Interface Endpoint também precisa aceitar tráfego de entrada na porta 443 vindo da VPC ou das tasks que farão as chamadas.
Como provar que os bytes deixaram o NAT
A correção concreta para o diagnóstico é criar o Interface Endpoint do serviço que concentra bytes — SQS no exemplo — nas subnets necessárias, com private DNS e policy restrita. Depois, observe o caminho antes e depois sem capturar pacotes da aplicação em produção.
Comece confirmando estado, tipo e serviço dos endpoints:
aws ec2 describe-vpc-endpoints \
--query 'VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}' \
--output tableO estado esperado é available. Isso prova que o recurso está pronto, não que a aplicação o utiliza.
Para a observação adequada à produção, compare no CloudWatch os bytes do NAT Gateway com o namespace AWS/PrivateLinkEndpoints e a métrica BytesProcessed. Como alternativa financeira, use o Cost Explorer para comparar NatGateway-Bytes com VpcEndpoint-Bytes ao longo do mesmo período.
De dentro de uma task na VPC, resolva sqs.us-east-1.amazonaws.com. Com private DNS ativo, a resposta deve apontar para endereços privados RFC1918. Se precisar de uma confirmação adicional, configure VPC Flow Logs nas ENIs do NAT e do endpoint e compare o campo real interface-id entre elas. O registro padrão inclui campos como interface-id, srcaddr, dstaddr, packets e bytes; não filtre por campos fictícios de endpoint.
Esse conjunto separa três perguntas: o endpoint está disponível, o DNS direciona a aplicação para IP privado e os bytes migraram do NAT para o PrivateLink.
Quando não adotar Interface Endpoint
Não crie o endpoint por reflexo. Recuamos da adoção quando:
- o tráfego daquele serviço fica bem abaixo de centenas de GB mensais e uma ENI em cada uma de três AZs coloca o payback longe do limiar aproximado de 617 GB deste cenário;
- S3 ou DynamoDB são o destino e um Gateway Endpoint atende o acesso dentro da VPC;
- o endpoint ficaria ocioso, mas continuaria acumulando cobrança horária;
- o desenho exige apenas uma AZ para economizar, mas a disponibilidade pede três; concentrar ENIs também pode acrescentar custo de tráfego entre AZs;
- o serviço inclui custos de endpoint em seu próprio modelo, caso em que sua página específica de preços precisa entrar na decisão.
E não remova o NAT só porque adicionou um VPC Endpoint de SQS. O endpoint resolve o caminho para aquele serviço; acesso a outros destinos na internet continua precisando de uma saída compatível com a arquitetura.
Próximo passo
Abra o Cost Explorer ou o CloudWatch, isole os bytes de uma API AWS sem Gateway Endpoint e refaça a conta com o número real de AZs. Se um único serviço sustenta volume acima do ponto de equilíbrio e a VPC precisa manter o NAT para outros destinos, adote o Interface Endpoint desse serviço, restrinja sua policy e confirme a migração pelos bytes e pelo DNS. Se o volume estiver abaixo do limiar, mantenha o NAT e meça novamente; para S3 e DynamoDB dentro da VPC, use Gateway Endpoint.