Amazon ANS-C01: Design de VPC e Redes Avançadas — Guia de estudos

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Fundamentos de arquitetura de VPC e sub-redes

Uma VPC é o limite de rede fundamental na AWS, e a forma das suas alocações CIDR define tudo o que vem a seguir. Planeje os blocos CIDR com o crescimento futuro e a conectividade entre contas em mente: aloque espaços de endereço grandes e não sobrepostos por conta/região (por exemplo, um /16 por ambiente) e subdivida em sub-redes /20–/24 para isolar workloads por função e zona de disponibilidade. Lembre-se de que o EKS e outras plataformas de contêineres consomem endereços IP para ENIs de pods ou IPs secundários; o AWS VPC CNI atribui IPs de pods a partir da sub-rede da VPC, e os limites de ENI/IP por instância (DescribeInstanceTypes) restringem a densidade máxima de pods. Para a adoção de IPv6, prefira um design dual-stack para descarregar serviços públicos para IPv6, mantendo o IPv4 para integração legada; associe um bloco CIDR IPv6 fornecido pela Amazon com a chamada de API aws ec2 associate-vpc-cidr-block –vpc-id <vpc> –amazon-provided-ipv6-cidr-block e habilite a atribuição de IPv6 no nível da sub-rede com create-subnet e a opção –ipv6-cidr-block. Planeje recursos de NAT para a saída (egress) de IPv4 e, para IPv6, use um Egress-Only Internet Gateway, criado com CreateEgressOnlyInternetGateway e anexado à VPC.

Tabelas de rotas e o posicionamento de sub-redes são como você impõe a topologia e a resiliência. Crie tabelas de rotas distintas para cada finalidade de sub-rede (pública, privada com NAT, privada com Direct Connect e isolada) usando CreateRouteTable e CreateRoute. Use múltiplos NAT Gateways (ou instâncias NAT com autoscaling) entre AZs para evitar uma falha de saída em uma única AZ; seja explícito sobre as rotas propagadas ao usar um Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable) para que os prefixos on-premises sejam injetados apenas onde desejado. Para descoberta de serviços interna a uma conta, use zonas hospedadas privadas (private hosted zones) do Route 53 e associe-as às VPCs que precisam dos registros para evitar o vazamento de DNS entre limites.

Principais serviços e detalhes de configuração

Para conectividade privada, existem três construções dominantes a serem entendidas: VPC Peering, AWS Transit Gateway e AWS PrivateLink (interface VPC endpoints). O VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) é uma conectividade ponto a ponto simples e de baixo custo que exige entradas na tabela de rotas e não suporta roteamento transitivo. O Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) é o hub escalável que suporta milhares de VPCs, controle central de rotas e integração com o Direct Connect Gateway para conectividade híbrida; use a propagação de tabelas de rotas e as associações de tabelas de rotas no Transit Gateway para controlar o fluxo leste-oeste (east-west). O PrivateLink (CreateVpcEndpointServiceConfiguration para registrar um serviço baseado em NLB e CreateVpcEndpoint para criar interface endpoints) expõe serviços entre contas sem expor uma VPC ao roteamento, fornecendo segurança granular por serviço e controles de security group simplificados; ele escala bem porque os consumidores criam interface endpoints e o tráfego permanece no nível da NIC.

Balanceamento de carga e preservação do IP do cliente são escolhas de design comuns que precisam ser feitas corretamente. O Application Load Balancer (ALB) termina o TLS, roteia na L7 (CreateLoadBalancer Type application) e injeta os cabeçalhos X-Forwarded-For/X-Forwarded-Proto, nos quais os backends devem confiar para o registro do IP do cliente. O Network Load Balancer (NLB) preserva os IPs de origem para os target groups e suporta milhões de conexões; para um verdadeiro pass-through de TLS para os backends, use um NLB com um listener TCP (CreateListener Protocol TCP) e registre os targets por IP para que as sessões criptografadas cheguem intactas aos pods ou instâncias. Para gRPC e contagens de conexão muito altas, prefira um NLB na frente do EKS com o tipo de target ip e a anotação do AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” para registrar os IPs dos pods diretamente; essa combinação retém o IP de origem, suporta a terminação de mTLS no pod e escala com os autoscalers.

VPC endpoints removem a necessidade de saída para a internet para APIs da AWS e serviços populares. Gateway endpoints para S3 e DynamoDB (CreateVpcEndpoint com –service-name com.amazonaws.<region>.s3) adicionam rotas a uma lista de prefixos de endpoint e são gratuitos. Interface endpoints (CreateVpcEndpoint com –vpc-endpoint-type Interface) criam interfaces de rede elásticas (ENIs) com IPs privados e security groups; eles são cobrados por hora e por GB, mas permitem o consumo no estilo PrivateLink e o acesso entre contas quando pareados com um serviço baseado em NLB.

Padrões de design e trade-offs

Para um serviço central compartilhado consumido por muitas unidades de negócio em várias contas, o PrivateLink e os endpoint services são o padrão mais seguro e escalável quando você precisa de controle e isolamento por conexão. Hospede o serviço por trás de um Network Load Balancer na VPC de serviços compartilhados, crie um VPC endpoint service (CreateVpcEndpointServiceConfiguration) e faça com que as contas consumidoras criem interface endpoints que você aprova. Isso evita uma malha completa (full mesh) e impede o roteamento transitivo, e os security groups nos interface endpoints permitem restringir quais consumidores podem se conectar. O trade-off é o custo por endpoint e uma sobrecarga de gerenciamento para aceitar e auditar as conexões dos endpoints.

O Transit Gateway se destaca quando você tem muitas VPCs que precisam de conectividade ampla, inspeção centralizada e um único local para anunciar prefixos on-premise via Direct Connect (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Use a segmentação de tabelas de rotas e controles de propagação para evitar movimento lateral acidental; o Transit Gateway suporta priorização de rotas e associações de tabelas de rotas para que você possa isolar o tráfego de produção de redes de menor confiança (lower-trust). O trade-off é que o Transit Gateway centraliza o tráfego e pode incorrer em custos para o tráfego entre VPCs que, de outra forma, seria local; ele também altera os domínios de falha e exige um planejamento cuidadoso de CIDR para evitar a sobreposição de endereços.

Para arquiteturas híbridas com reutilização limitada de CIDR, considere combinar o Direct Connect com o Transit Gateway e o Direct Connect Gateway (CreateDirectConnectGateway) para reduzir o número de interfaces virtuais. Se você precisar de isolamento de largura de banda por unidade de negócio no link físico compartilhado, utilize múltiplas interfaces virtuais privadas (VIFs) e monitore as métricas do CloudWatch por VIF (nomes de métricas como AWS/DX: BytesIn, BytesOut) e use alarmes do CloudWatch no nível da VIF. Para identificar grandes consumidores, habilite os VPC Flow Logs (CreateFlowLogs) para o S3 ou CloudWatch Logs e analise com o Athena ou o CloudWatch Logs Insights; para captura de pacotes por VM, use o Traffic Mirroring (CreateTrafficMirrorSession) por curtos períodos.

A adoção do IPv6 e designs dual-stack reduzem a dependência de NAT, diminuem os custos de throughput do NAT Gateway e simplificam o endereçamento voltado para o cliente. Use a chamada de API

undefined

para atribuir um prefixo IPv6 fornecido pela Amazon e criar sub-redes com blocos CIDR IPv6. Esteja ciente de que alguns serviços e appliances de terceiros podem não estar prontos para IPv6; use dual-stack em load balancers (

undefined

com

undefined

undefined

) para suportar clientes IPv4 e IPv6 enquanto os sistemas de backend permanecem em IPv4.

Armadilhas comuns e critérios de decisão

Negligenciar o consumo de endereços IP por pods do Kubernetes é uma fonte frequente de interrupção de serviço. Leve em conta os limites de ENI e IPs secundários por tipo de instância e use configurações do VPC CNI como

undefined

ou delegação de prefixo para melhorar a disponibilidade de IPs. Falhar em preservar os IPs do cliente na L7 é outra lacuna comum: se o TLS precisar ser terminado no load balancer, você deve garantir que a aplicação leia o cabeçalho

undefined

e que os controles de segurança do ALB restrinjam o acesso direto para que os cabeçalhos sejam confiáveis. Assumir que o VPC peering escalará indefinidamente muitas vezes leva a malhas ingerenciáveis; prefira o Transit Gateway para conectividade muitos-para-muitos e o PrivateLink para exposição de serviços um-para-muitos onde você precisa de segurança granular e isolamento de tráfego.

As políticas de segurança devem usar security groups e network ACLs em combinação com controles no nível de namespace. Para uma aplicação rigorosa do acesso via Global Accelerator em vez de URLs diretas do ALB, confie em uma combinação de IP sets do AWS WAF populados com os intervalos de IP do Global Accelerator (automatizado através do arquivo

undefined

publicado) ou arquitete o ALB como interno e coloque um NLB na frente dele como alvo do Global Accelerator, expondo apenas o ponto de entrada do Global Accelerator. Sempre automatize as atualizações de quaisquer controles baseados em IP e valide usando

undefined

e a ingestão regular do

undefined

.

Problema Prático: Cenário de Caso de Uso

undefined

para que os IPs dos pods sejam registrados como targets; 2) terminar o TLS nos pods (não no NLB) e implementar mutual TLS na aplicação (validação de certificados do servidor e do cliente), com Kubernetes Secrets para os certificados e readiness probes para direcionar o registro de targets; 3) usar o tipo de target

undefined

para preservar os IPs de origem do cliente, habilitar o proxy protocol apenas se necessário para appliances intermediários e confiar no logging no lado do pod para capturar o IP do cliente da conexão TCP; 4) configurar health checks como readiness probes TCP ou cientes de gRPC, e garantir que as políticas do Cluster Autoscaler e os tipos de instância dos nós tenham capacidade suficiente de ENIs e IPs; 5) implementar o CloudWatch Container Insights e os VPC Flow Logs (

undefined

) para monitorar a contagem de conexões e a telemetria no nível da VPC. | | Justificativa da AWS | O NLB com listeners TCP preserva as sessões criptografadas e os IPs de origem enquanto escala para milhões de conexões; o tipo de target

undefined

permite que os pods recebam o IP de origem diretamente, sem NAT; terminar o mTLS nos pods satisfaz a criptografia de ponta a ponta e a autenticação de duas vias; o auto-scaling funciona porque a prontidão (readiness) do pod afeta diretamente o registro do target e o NLB escala de forma transparente com a carga de conexões. |

Todos os domínios · Conectividade Híbrida: VPN e Direct Connect →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →