Amazon ANS-C01: Automação, IaC e Operações de Rede — Guia de estudos
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.
Conceito principal
A Infraestrutura como Código para redes na AWS transforma a topologia de rede, as políticas de segurança e o roteamento em templates declarativos e operações de ciclo de vida determinísticas. Os templates do CloudFormation (AWS::EC2::VPC, AWS::EC2::Subnet, AWS::EC2::RouteTable, AWS::EC2::TransitGateway, AWS::EC2::TransitGatewayAttachment, AWS::ElasticLoadBalancingV2::LoadBalancer, AWS::EC2::VPCEndpoint, AWS::EC2::NetworkAcl, AWS::EC2::SecurityGroup) codificam o estado desejado, enquanto as APIs do CloudFormation — operações CreateStack, UpdateStack, DeleteStack, DescribeStacks e ChangeSet — aplicam as alterações atomicamente. Use stacks aninhados e templates modulares para isolar domínios de rede (serviços compartilhados, VPCs de aplicação por conta, zonas de entrada/saída) e StackSets para propagar stacks de rede consistentes em todas as AWS Organizations. A detecção de desvio (DetectStackDrift) e os conjuntos de alterações (change sets) fornecem mecanismos de proteção para que a automação possa detectar e exigir revisão humana para alterações de rede feitas fora de banda.
A automação também deve cobrir as partes da rede que o CloudFormation não consegue expressar nativamente ou que exigem ganchos de ciclo de vida (lifecycle hooks): compartilhamento de recursos entre contas, integrações on-premise e configuração em tempo de execução nos hosts. Recursos personalizados (custom resources) do CloudFormation (apoiados por Lambda) ou módulos do CloudFormation podem chamar APIs como CreateResourceShare (AWS RAM) para compartilhar um Transit Gateway ou uma sub-rede, ou chamar o Systems Manager (SSM) SendCommand para injetar certificados ou políticas de roteamento nas instâncias. Para Kubernetes no EKS, o AWS Load Balancer Controller é instalado via Helm e gerenciado por meio de anotações de Service; o CloudFormation pode provisionar a função do IAM, o provedor OIDC e os objetos HelmRelease por meio do AWS::EKS::Cluster e de recursos personalizados, mas o mapeamento em tempo de execução dos IPs dos pods para os grupos de destino (target groups) do NLB é tratado pelo controller.
Principais serviços e configuração
Existem serviços e APIs principais da AWS que você usará repetidamente ao automatizar operações de rede: CloudFormation (CreateStack, UpdateStack, DetectStackDrift), AWS Resource Access Manager (CreateResourceShare, AssociateResourceShare), AWS Transit Gateway (CreateTransitGateway, CreateTransitGatewayAttachment, CreateTransitGatewayRoute), Elastic Load Balancing V2 (CreateLoadBalancer, CreateTargetGroup, ModifyTargetGroupAttributes), AWS Lambda (CreateFunction, AddPermission, Invoke), Systems Manager (PutParameter, SendCommand, CreateDocument) e AWS Config (PutEvaluations, StartConfigurationRecorder). Esses serviços formam uma pilha de automação típica para uma rede segura e auditável.
Ao projetar templates e automação, preste atenção aos atributos de recursos específicos e às anotações do controller. Para load balancers, escolha o tipo e os atributos corretos: um NLB com listeners TCP preserva o IP de origem e suporta o Proxy Protocol v2 por meio de CreateLoadBalancer/ModifyTargetGroupAttributes e da configuração “proxy_protocol_v2.enabled” nos grupos de destino; um ALB (Application Load Balancer) termina o TLS, insere cabeçalhos X-Forwarded-For para os IPs do cliente e suporta gRPC/HTTP2 quando configurado com listeners HTTPS. Para o EKS, você usa anotações como service.beta.kubernetes.io/aws-load-balancer-type: “nlb” ou as anotações de Ingress/Service do AWS Load Balancer Controller para controlar o passthrough versus a terminação do TLS e para definir o tipo de destino (target type) como ip para direcionamento direto aos pods. Para compartilhamento entre contas e redes multi-contas, você usará o AWS RAM para compartilhar Transit Gateways e os CloudFormation StackSets combinados com funções de administrador delegado (delegated admin roles) para criar anexos (attachments) e acesso nas contas consumidoras.
Padrões de design e trade-offs
Dois padrões comuns e contrastantes são o hub-and-spoke com Transit Gateway e a VPC compartilhada (shared-VPC) via AWS RAM. O padrão hub-and-spoke com um Transit Gateway centraliza o roteamento, a inspeção e a conectividade entre VPCs; ele escala porque os anexos (attachments) e as tabelas de rotas (route tables) permitem a segmentação, e você pode compartilhar o TGW usando o RAM para que diferentes contas possam criar anexos sem transferir a propriedade total. O trade-off está na propagação de rotas e nos limites da tabela de rotas: as tabelas de rotas e os limites de anexos do Transit Gateway exigem planejamento e podem introduzir pontos únicos onde a política deve ser aplicada (use várias tabelas de rotas e o AWS Network Firewall para isolar o tráfego). A VPC compartilhada (compartilhamento de VPC com AWS RAM) coloca as sub-redes em uma conta anfitriã (host) e permite que as contas consumidoras lancem recursos nessas sub-redes, o que simplifica os controles de segurança centrais para conectividade, mas reduz a autonomia no nível da conta e complica o isolamento de rede por unidade de negócio, pois a propriedade dos security groups e os limites do IAM devem ser gerenciados com cuidado.
Para tráfego de entrada (ingress) e terminação de TLS, você deve equilibrar a necessidade de criptografia de ponta a ponta com a escala e a preservação do IP do cliente. Se você precisa de terminação de TLS no load balancer (para WAF, centralização de certificados e roteamento HTTP), o ALB é a ferramenta certa; ele adiciona o cabeçalho X-Forwarded-For para que os logs da aplicação possam capturar os IPs do cliente, e o ALB suporta roteamento baseado em caminho e host para múltiplos grupos de destino. Se você precisa de TLS de ponta a ponta verdadeiro ou mTLS, onde o load balancer não deve descriptografar o tráfego, use um NLB em modo TCP para passar o TLS diretamente para os endpoints de backend (pod ou instância) e configure o tipo de destino (target type) como ip e externalTrafficPolicy: Local no Kubernetes para preservar o IP de origem. Para milhares de conexões gRPC bidirecionais e concorrentes com mTLS, um NLB encaminhando o tráfego TLS bruto para as portas dos pods, combinado com os pods terminando o mTLS, fornece escalabilidade e criptografia de ponta a ponta verdadeira, enquanto se utiliza as anotações do AWS Load Balancer Controller para criar os listeners e grupos de destino do NLB adequados.
Armadilhas comuns e critérios de decisão
Uma armadilha frequente é confundir o local de terminação TLS com os requisitos de IP do cliente: o ALB fornece o X-Forwarded-For quando termina o TLS, mas não preserva o IP de origem para o destino como o NLB faz. Se você precisa dos recursos do ALB (roteamento por host/caminho, WAF) e do IP de origem original no backend, considere usar o ALB para terminação HTTP e encaminhamento para proxies reversos ou sidecars que reconstroem os IPs de origem a partir do X-Forwarded-For, ou use uma arquitetura onde um NLB faz o passthrough do TLS para serviços que realizam mTLS e descarregam o roteamento HTTP para proxies no cluster. Outra armadilha é configurar incorretamente as permissões entre contas: ao compartilhar um Transit Gateway ou outro recurso de rede com o RAM, certifique-se de usar um compartilhamento de recurso explícito e a role do IAM e o principal do RAM corretos; não fazer isso resulta em erros opacos de “permission denied”.
Em automação de compliance, não armazene chaves privadas ou material de CA não criptografado em texto plano. Use o SSM Parameter Store SecureString com uma chave do KMS que tenha uma política de chave mínima, permitindo acesso apenas às roles e principais que o exigem. Use as regras gerenciadas do AWS Config (por exemplo, vpc-flow-logs-enabled, restricted-common-ports, security-group-rule-check) e, onde as regras gerenciadas não cobrirem seus critérios, implemente regras do Config baseadas em Lambda que chamam PutEvaluations. A remediação deve ser automatizada por meio de documentos do SSM Automation ou do Systems Manager Run Command que a ação de remediação do Config pode invocar, mas sempre forneça um caminho de alerta e aprovação para alterações de alto risco.
Problema Prático: Cenário de Caso de Uso
Empresa: ApexTelemetrics — desafio: fornecer um serviço gRPC hospedado no EKS, globalmente acessível, que requer TLS mútuo (mTLS) de ponta a ponta verdadeiro (cliente e servidor se autenticam com mTLS), suporta milhares de conexões simultâneas de longa duração sobre TCP 443, deve autoescalar pods e garantir que a distribuição e rotação de certificados sejam automatizadas e auditáveis.
Abordagem:
- Provisionar rede e balanceador de carga com o CloudFormation: criar um NLB via
undefined
configurado com um listener TCP na porta 443 e grupos de destino com targetType definido como “ip” e health checks em TCP. Usar
undefined
/
undefined
do CloudFormation e stacks aninhados modulares para VPC, subnets e NLB. Usar anotações do AWS Load Balancer Controller no Service do EKS (
undefined
,
undefined
) para que cada Service crie o grupo de destino do NLB diretamente nos pods. 2) Garantir o passthrough de TLS e a terminação de mTLS nos pods: configurar o Service do EKS para encaminhar TCP 443 diretamente para as portas dos pods; implementar um proxy sidecar ou envoy dentro de cada pod que realize a terminação de mTLS com o cliente e imponha a autenticação mútua. Definir
undefined
no Service para que o IP de origem seja preservado, se necessário, e usar o autoescalonamento em nível de Pod (Horizontal Pod Autoscaler) com o Cluster Autoscaler para escalar nós e pods juntos. 3) Automatizar o ciclo de vida e a distribuição de certificados: armazenar as chaves privadas do certificado do servidor e da CA no SSM Parameter Store SecureString, criptografadas por uma chave do KMS. Criar um recurso personalizado (custom resource) no CloudFormation baseado em AWS Lambda para criar parâmetros do SSM durante a criação do stack (
undefined
com a role do IAM apropriada e, em seguida, o recurso personalizado do CloudFormation para chamar
undefined
). Usar o SSM Run Command ou um DaemonSet imutável que busca segredos do SSM por meio de uma role do IAM vinculada ao pod (via IRSA) para injetar certificados no sidecar. Para a rotação, agendar funções Lambda (
undefined
- regra do EventBridge) para gerar novos certificados, chamar
undefined
e usar o SSM ou Kubernetes Jobs para realizar rolling restarts.
4) Compliance e auditoria: habilitar regras do AWS Config (regras gerenciadas como vpc-flow-logs-enabled e regras personalizadas baseadas em Lambda usando
undefined
) para verificar se os listeners do NLB são TCP e se nenhum ALB está terminando o TLS para este serviço. Configurar a remediação do Config para invocar documentos do SSM Automation se uma configuração incorreta for detectada e enviar os findings para o AWS Security Hub e o CloudWatch Events.
Justificativa da AWS: O NLB em modo TCP fornece o verdadeiro passthrough de TLS necessário para mTLS de ponta a ponta e escala para milhares de conexões simultâneas com uma pequena pegada de CPU por conexão no balanceador de carga. O direcionamento para pods via targetType=ip remove um salto extra e mantém o autoescalonamento responsivo. Armazenar e rotacionar chaves no SSM Parameter Store protegido pelo KMS fornece gerenciamento de segredos centralizado e auditável com controles do IAM, e usar o CloudFormation mais recursos personalizados do Lambda e o EventBridge garante que todo o ciclo de vida seja codificado, repetível e observável.
← Desempenho de Rede e Monitoramento · Todos os domínios · Redes de Contêineres e Serverless →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →