Guia

Conectividade full mesh para muitas VPCs, algumas com CIDRs sobrepostos.

→Implante o Transit Gateway. Corrija os CIDRs sobrepostos adicionando blocos CIDR secundários e únicos às VPCs afetadas.

Por quê: O Transit Gateway fornece roteamento transitivo e escalável, mas não consegue rotear entre faixas de IP sobrepostas. A correção de IP é necessária.

Conectividade híbrida de alta taxa de transferência, baixa latência e resiliente.

→Provisione duas conexões Direct Connect dedicadas em dois locais Direct Connect diferentes.

Por quê: O uso de dois locais diferentes protege contra falhas no nível do local (cortes de fibra, quedas de energia), proporcionando máxima resiliência. Um único local, mesmo com múltiplas conexões, é um ponto único de falha.

Resolução DNS bidirecional entre zonas hospedadas privadas no local e na AWS.

→Use o Route 53 Resolver. Crie Inbound Endpoints para que o ambiente local consulte a AWS. Crie Outbound Endpoints com regras de encaminhamento para que a AWS consulte o ambiente local.

Por quê: Inbound endpoints fornecem IPs acessíveis para encaminhadores DNS no local. Outbound endpoints permitem o encaminhamento condicional de dentro da VPC. O resolvedor padrão da VPC (VPC+2) não é acessível do ambiente local.

Forneça acesso em nível de serviço entre duas VPCs sem criar rotas na camada de rede.

→Use AWS PrivateLink. Crie um VPC Endpoint Service (apoiado por um NLB) na VPC do provedor e um Interface VPC Endpoint na VPC do consumidor.

Por quê: O PrivateLink fornece conectividade unidirecional e específica do serviço usando ENIs na VPC do consumidor, evitando completamente o roteamento em nível de rede e problemas de sobreposição de CIDR.

Forneça acesso à internet apenas de saída para instâncias habilitadas para IPv6 em sub-redes privadas.

→Crie um Egress-Only Internet Gateway (EIGW) e adicione uma rota para `::/0` à tabela de rotas da sub-rede privada apontando para o EIGW.

Por quê: Um EIGW é stateful para conexões IPv6 de saída, permitindo o tráfego de retorno, mas impedindo conexões de entrada não solicitadas, análogo a um NAT Gateway, mas para IPv6.

Inspecione todo o tráfego inter-VPC usando AWS Network Firewall em um modelo centralizado com Transit Gateway.

→Crie uma VPC de inspeção dedicada com Network Firewall. Configure as tabelas de rotas do TGW para enviar todo o tráfego inter-VPC para a VPC de inspeção. Dentro da VPC de inspeção, as tabelas de rotas devem direcionar o tráfego através dos endpoints do NFW para roteamento simétrico.

Por quê: Esta arquitetura exige roteamento cuidadoso: o TGW envia tráfego para a VPC de inspeção; as tabelas de rotas da VPC o enviam para o endpoint do firewall; o firewall o envia de volta para a ENI de anexo do TGW; o TGW o roteia para o destino final.

Segmentar VPCs (por exemplo, prod vs. dev) usando Transit Gateway, permitindo que ambas acessem uma VPC de serviços compartilhados.

→Use múltiplas tabelas de rotas do Transit Gateway. Crie uma tabela de rotas para cada segmento (prod, dev, shared). Associe as VPCs às suas respectivas tabelas. Propague as rotas para criar uma topologia hub-spoke onde os spokes só podem ver o hub.

Por quê: As associações e propagações da tabela de rotas do TGW são o principal mecanismo para segmentação de rede e isolamento de tráfego na camada de rede.

Reduzir a latência para uma aplicação global dinâmica e não armazenável em cache (por exemplo, API, jogos) hospedada em uma única região.

→Use AWS Global Accelerator. Ele fornece IPs anycast que direcionam os usuários para o local de borda AWS mais próximo, então o tráfego atravessa a backbone AWS otimizada até a origem.

Por quê: O Global Accelerator otimiza o "first mile" e o "middle mile" sobre a rede AWS, reduzindo a latência e o jitter para o tráfego TCP/UDP. O CloudFront é melhor para conteúdo armazenável em cache.

Fornecer acesso privado de uma VPC ao S3 e DynamoDB sem atravessar a internet.

→Crie Gateway VPC Endpoints para S3 e DynamoDB. Isso adiciona entradas de lista de prefixos às tabelas de rotas da sub-rede especificada.

Por quê: Os endpoints de gateway são o mecanismo específico, de alto desempenho e sem custo para acesso privado ao S3 e DynamoDB. Outros serviços usam Interface Endpoints (PrivateLink).

Acessar VPCs em múltiplas regiões AWS a partir de uma única conexão Direct Connect no local.

→Use um Direct Connect Gateway com uma Transit Virtual Interface (T-VIF). Associe o DX Gateway com Transit Gateways em cada Região necessária.

Por quê: Uma Transit VIF com um DX Gateway é a solução escalável para conectar-se a múltiplos Transit Gateways entre regiões. Uma Private VIF com um DX Gateway tem limites inferiores.

Integrar um appliance de firewall virtual de terceiros para inspeção transparente de tráfego.

→Use um Gateway Load Balancer (GWLB). Ele opera na Camada 3 e usa o protocolo GENEVE para encapsular o tráfego, preservando o IP de origem/destino original.

Por quê: A encapsulamento GENEVE do GWLB o torna um "bump-in-the-wire", inserindo appliances de forma transparente no caminho da rede sem exigir NAT de origem, o que é crítico para appliances de segurança.

Gerenciar a alocação de endereços IP para centenas de VPCs em uma organização multi-conta para evitar sobreposições e rastrear o uso.

→Use o Amazon VPC IP Address Manager (IPAM). Crie um pool de nível superior e delegue pools regionais para automatizar a alocação de CIDR da VPC.

Por quê: O VPC IPAM é o serviço AWS escalável e construído para gerenciar endereços IP centralizadamente, substituindo métodos manuais propensos a erros.

Integrar um appliance SD-WAN de terceiros com Transit Gateway usando túneis GRE e roteamento BGP dinâmico.

→Use um anexo Transit Gateway Connect.

Por quê: O TGW Connect é projetado especificamente para integração SD-WAN. Ele suporta GRE para maior largura de banda (até 5 Gbps por peer) e BGP para roteamento dinâmico.

Uma VPC somente IPv6 precisa se comunicar com recursos somente IPv4 na internet.

→Habilite o DNS64 nas configurações do Route 53 Resolver da VPC e configure um NAT Gateway em uma sub-rede pública. Encaminhe `64:ff9b::/96` para o NAT Gateway.

Por quê: O DNS64 sintetiza registros AAAA para destinos IPv4. O NAT Gateway realiza a tradução do protocolo NAT64 do endereço IPv6 sintetizado para o endereço IPv4 real.

Conectar centenas de VPCs em muitas regiões com requisitos de segmentação estritos (produção, desenvolvimento, serviços compartilhados).

→Use AWS Cloud WAN. Defina segmentos e ações de segmento em uma única política de rede central para controlar o roteamento intersegmento globalmente.

Por quê: O Cloud WAN fornece uma política de rede global centralizada e declarativa, que é mais escalável e menos complexa do que gerenciar uma malha completa de peerings do Transit Gateway e tabelas de rotas em cada região.

Agregando múltiplas conexões Direct Connect em um único local para maior largura de banda e redundância de link.

→Configure um Link Aggregation Group (LAG). Todas as conexões devem ter a mesma largura de banda e terminar no mesmo dispositivo AWS.

Por quê: LAGs agrupam links físicos em um único link lógico. Isso fornece failover em nível de link, mas não protege contra falhas de dispositivo ou local. Use `minimum links` para definir o limite de failover.

Alcançar failover DNS em menos de 60 segundos para uma aplicação multi-região.

→Use roteamento de failover do Route 53 com verificações de saúde. Configure verificações de saúde com intervalo rápido (10s) e um baixo limite de falha (1). Use registros Alias ou TTLs muito baixos (por exemplo, 10-60s).

Por quê: O failover rápido requer detecção rápida (verificações de saúde rápidas) e atualizações rápidas do lado do cliente (TTLs baixos ou registros Alias que têm TTLs dinâmicos).

Aumentar a taxa de transferência agregada da VPN usando ambos os túneis de uma conexão VPN Site-to-Site simultaneamente.

→Anexe a VPN a um Transit Gateway. Habilite o suporte a ECMP no anexo VPN do Transit Gateway.

Por quê: Por padrão, a VPN para TGW pode usar apenas um túnel. Habilitar o ECMP no anexo do TGW distribui o tráfego por ambos os túneis se as rotas BGP tiverem custo igual.

Garantir que os serviços TCP de backend por trás de um Network Load Balancer vejam o endereço IP original do cliente.

→Registre alvos por ID da instância. Se os alvos forem registrados por IP, habilite o Proxy Protocol v2 no grupo de destino.

Por quê: Quando os alvos são registrados por ID da instância, o NLB preserva o IP do cliente por padrão. Se registrados por IP, o IP do NLB se torna a origem, e o Proxy Protocol v2 é necessário para passar o IP original.

Influenciar como a AWS roteia o tráfego de volta para uma rede no local quando múltiplos caminhos do Direct Connect existem.

→Use BGP AS path prepending no caminho menos preferido a partir do roteador no local.

Por quê: Para o tráfego de saída da AWS, o principal mecanismo controlado pelo cliente é o comprimento do AS path. A AWS prefere o caminho com o AS path mais curto. Não é possível configurar a preferência local no lado da AWS.

Habilitar contas spoke em uma AWS Organization para anexar suas VPCs a um Transit Gateway de propriedade de uma conta central de rede.

→Use AWS Resource Access Manager (RAM). A conta de rede compartilha o Transit Gateway com a Organization ou OUs específicas.

Por quê: O RAM é o serviço AWS específico projetado para compartilhar recursos como Transit Gateways entre contas. Isso permite o gerenciamento centralizado enquanto habilita o anexo de autoatendimento para contas spoke.

Agregar throughput além do limite de 1,25 Gbps de um único túnel VPN.

→Crie múltiplas conexões VPN Site-to-Site para um Transit Gateway com ECMP habilitado.

Por quê: Cada túnel VPN é limitado a ~1,25 Gbps. Para escalar, você deve usar múltiplos túneis/conexões e aproveitar o ECMP em um Transit Gateway para balancear a carga do tráfego entre eles.

Configure verificações de saúde do Route 53 para um recurso interno, não voltado para a internet, como um ALB interno.

→Crie um alarme do CloudWatch que monitora uma métrica para o recurso interno (por exemplo, `HealthyHostCount` para um ALB). Configure a verificação de saúde do Route 53 para monitorar o estado do alarme do CloudWatch.

Por quê: Os verificadores de saúde do Route 53 são externos. Para monitorar recursos internos, eles devem monitorar um sinal de proxy como o estado de um alarme do CloudWatch, que pode ser acionado por métricas internas.

Fazer o failover automático do tráfego do CloudFront para uma origem secundária (por exemplo, um site S3 estático) quando a origem primária (por exemplo, um ALB) retorna erros 5xx.

→Crie um CloudFront Origin Group com o ALB como primário e o S3 como secundário. Configure-o para fazer failover em códigos de status especificados (por exemplo, 500, 502, 503, 504).

Por quê: Os Origin Groups são o mecanismo nativo do CloudFront para alta disponibilidade, fornecendo failover contínuo na borda sem exigir alterações de DNS.

Alcançar failover em sub-segundos para uma conexão Direct Connect para uma VPN de backup ou caminho DX secundário.

→Habilite a Bidirectional Forwarding Detection (BFD) na interface virtual do Direct Connect. Configure BFD no roteador local.

Por quê: O BFD fornece detecção de falha de link muito mais rápida (tão baixa quanto 300ms) em comparação com os temporizadores keepalive do BGP (padrão 90s), permitindo a rápida reconvergência do tráfego.

Habilitar conectividade entre Transit Gateways em duas regiões diferentes.

→Estabeleça uma conexão de peering do Transit Gateway. Adicione manualmente rotas estáticas em cada tabela de rotas do TGW apontando para os CIDRs da região remota via o anexo de peering.

Por quê: Crucialmente, o peering inter-regional do Transit Gateway não suporta propagação dinâmica de rotas. Todas as rotas entre regiões devem ser configuradas estaticamente.

Solucionar problemas de conectividade na AWS identificando o componente de bloqueio específico (por exemplo, rota, NACL, SG).

→Use o VPC Reachability Analyzer. Especifique uma origem e um destino, e ele realiza uma análise estática da configuração do caminho da rede.

Por quê: O Reachability Analyzer fornece uma análise definitiva, hop-by-hop, dos constructos de rede da AWS, o que é mais eficaz do que o traceroute (que pode não funcionar) ou a verificação manual de cada componente.

Armazenamento de longo prazo e consulta ad-hoc de VPC Flow Logs detalhados para conformidade.

→Publique os logs de fluxo diretamente para o S3 no formato Parquet com um layout de campo personalizado. Use o Amazon Athena para consultas ad-hoc baseadas em SQL.

Por quê: O S3 é o armazenamento mais econômico. O formato Parquet é altamente eficiente para consultas Athena, reduzindo custos de varredura e melhorando o desempenho. Este é o padrão serverless e escalável para análise de logs de fluxo.

Impor centralmente regras obrigatórias de grupo de segurança em todas as VPCs em uma AWS Organization e remediar automaticamente a não conformidade.

→Use o AWS Firewall Manager com uma política de auditoria de grupo de segurança. Defina as regras necessárias e configure a política para remediar automaticamente grupos não conformes.

Por quê: O Firewall Manager é a ferramenta de governança centralizada para políticas de segurança (WAF, SG, NFW) em uma Organization. Sua política de auditoria com remediação automática fornece aplicação.

Visualizar e monitorar uma topologia de rede global incluindo Transit Gateways, VPNs e Direct Connect em regiões e contas.

→Use o AWS Network Manager. Registre os Transit Gateways em uma única rede global para obter um painel centralizado, mapa de topologia e monitoramento de saúde.

Por quê: O Network Manager é construído especificamente para fornecer um painel único para redes AWS complexas e globais, consolidando monitoramento e gerenciamento.

Diagnosticar perda de pacote intermitente ou erros em uma conexão Direct Connect.

→Verifique as métricas do CloudWatch do Direct Connect (`ConnectionErrorCount`). No roteador do cliente, verifique os níveis de sinal óptico (níveis de luz Tx/Rx) e os contadores de erro da interface (erros CRC, erros de entrada).

Por quê: A perda de pacotes pode ser um problema na camada física. Tanto as métricas do lado da AWS quanto os diagnósticos do roteador do cliente são necessários para isolar problemas como um cabo de fibra óptica ou transceptor em degradação.

Detectar e remediar automaticamente configurações de rede não conformes, como um grupo de segurança que permite acesso SSH público.

→Use o AWS Config com uma regra gerenciada (por exemplo, `restricted-ssh`) e configure uma ação de remediação automática usando um documento de automação do SSM.

Por quê: Isso fornece um sistema de conformidade em loop fechado. O AWS Config detecta a violação, e sua ação de remediação aciona um documento SSM para corrigir automaticamente a configuração.

Identificar proativamente caminhos de acesso de rede não intencionais para recursos sensíveis da internet ou de outras redes não confiáveis.

→Use o VPC Network Access Analyzer. Defina um escopo de acesso e execute uma análise para obter uma lista de todos os caminhos de rede possíveis que correspondam.

Por quê: Esta ferramenta realiza uma verificação formal de rede, analisando todos os componentes (SGs, NACLs, TGW, IGW) para encontrar caminhos potenciais, o que é mais abrangente do que verificações manuais ou monitoramento reativo.

Coletar VPC Flow Logs, DNS Query Logs e logs do Network Firewall de muitas contas membro em uma conta de logging central.

→Configure os serviços nas contas membro para publicar logs diretamente em um bucket S3 centralizado (para Flow Logs/NFW) ou CloudWatch Log Group (para logs DNS) na conta de logging, usando políticas de bucket e perfis IAM de cross-account.

Por quê: A publicação direta de logs entre contas é o padrão mais eficiente e escalável, aproveitando as capacidades nativas da AWS sem a necessidade de agentes ou pipelines de dados complexos.

Otimizar os custos de rede para tráfego de alto volume entre pares específicos de VPCs em uma arquitetura hub-and-spoke do Transit Gateway.

→Para pares de VPCs com alto tráfego, crie uma conexão de peering VPC direta para contornar o Transit Gateway. Mantenha o TGW para todo o outro tráfego hub-spoke.

Por quê: O peering de VPC não tem cobrança por GB de processamento de dados (apenas transferência de dados padrão), enquanto o Transit Gateway tem. Mover tráfego ponto-a-ponto de alto volume para peering reduz significativamente os custos.

Criptografar o tráfego do Direct Connect na Camada 2 para desempenho em velocidade de linha.

→Habilite o MACsec (IEEE 802.1AE). Requer uma conexão dedicada de 10Gbps ou 100Gbps em um local compatível com MACsec.

Por quê: O MACsec fornece criptografia hop-by-hop entre o roteador do cliente e o dispositivo AWS, protegendo o link físico com sobrecarga mínima de desempenho.

Proteger uma aplicação web contra ataques comuns (SQLi, XSS) e restringir o acesso por país.

→Use AWS WAF. Anexe uma web ACL ao ALB/CloudFront. Use grupos de regras gerenciadas da AWS (por exemplo, `AWSManagedRulesSQLiRuleSet`, `AWSManagedRulesCommonRuleSet`) e crie uma regra de geo-match.

Por quê: As AWS Managed Rules fornecem proteção pronta para uso contra ameaças comuns, enquanto as regras de geo-match fornecem controle geográfico. Este é o padrão de implementação do WAF.

Implementar isolamento de aplicações multi-camadas (por exemplo, web -> app -> db) dentro de uma VPC.

→Crie um grupo de segurança para cada camada. Use referências de ID de grupo de segurança nas regras (por exemplo, o app-sg permite entrada do web-sg).

Por quê: Referenciar grupos de segurança é mais dinâmico e seguro do que usar faixas CIDR. Ele se adapta automaticamente à medida que as instâncias são adicionadas ou removidas de uma camada.

Monitorar e detectar ameaças baseadas em DNS, como DNS tunneling e comunicação com servidores C2.

→Habilite o registro de consultas do Route 53 Resolver. Habilite o Amazon GuardDuty, que analisa os logs de consulta DNS como uma fonte de dados.

Por quê: O GuardDuty possui inteligência de ameaças integrada que analisa logs DNS para detectar domínios maliciosos conhecidos, DGAs e padrões de consulta anômalos indicativos de exfiltração de dados.

Garantir que o conteúdo do S3 possa ser acessado apenas via CloudFront, não diretamente via URL do S3, enquanto ainda permite acesso a outros princípios IAM.

→Use Origin Access Control (OAC). Atualize a política do bucket S3 para permitir acesso do service principal do OAC e de quaisquer outros perfis/usuários IAM necessários.

Por quê: O OAC é o substituto moderno para o OAI. Ele cria um service principal que pode ser referenciado em políticas de bucket, fornecendo controle de acesso mais granular e flexível.

Impedir que usuários ignorem o CloudFront e acessem uma origem ALB diretamente.

→Configure o CloudFront para adicionar um cabeçalho HTTP personalizado com um valor secreto às requisições de origem. Crie uma regra de listener do ALB que verifica esse cabeçalho e valor, bloqueando requisições que não o possuem.

Por quê: Isso fornece uma proteção mais forte do que restrições baseadas em IP (usando a lista de prefixos gerenciada), pois verifica se a requisição veio da sua distribuição específica. Use ambos para defesa em profundidade.

Capturar dados completos de pacotes de rede de uma instância EC2 específica para análise forense sem instalar agentes.

→Use VPC Traffic Mirroring. Configure uma sessão de espelhamento na ENI da instância para copiar o tráfego para um destino (por exemplo, um NLB que está à frente de ferramentas de análise).

Por quê: O Traffic Mirroring fornece captura de pacotes completa e sem agente, o que é essencial para análise forense profunda. Os logs de fluxo fornecem apenas metadados.

Fornecer proteção DDoS abrangente para aplicações voltadas para o público.

→Assine o AWS Shield Advanced. Associe a proteção a recursos críticos (CloudFront, ALB, EIPs, Route 53). Use AWS WAF para mitigação da Camada 7. Acione a Equipe de Resposta do Shield (SRT) durante ataques.

Por quê: O Shield Advanced oferece detecção aprimorada, proteção de custos contra escalonamento induzido por DDoS e acesso à SRT para assistência especializada, o que é crítico para aplicações de missão crítica.

Emitir e rotacionar automaticamente certificados TLS para microsserviços internos de uma Autoridade de Certificação privada.

→Use o AWS Private Certificate Authority (Private CA) para criar a CA. Use o AWS Certificate Manager (ACM) para emitir e gerenciar o ciclo de vida (incluindo renovação automática) de certificados privados dessa CA.

Por quê: Esta combinação oferece uma solução PKI privada totalmente gerenciada, automatizando o ciclo de vida complexo de certificados internos sem exposição pública.

Impedir que qualquer usuário em qualquer conta membro de uma AWS Organization crie ou anexe um internet gateway.

→Aplique uma Service Control Policy (SCP) na raiz da Organization que nega as ações `ec2:CreateInternetGateway` e `ec2:AttachInternetGateway`.

Por quê: As SCPs fornecem guard-rails preventivos que não podem ser substituídos por políticas IAM dentro das contas membro, tornando-as a ferramenta definitiva para impor políticas de segurança em toda a organização.

Descriptografar e inspecionar tráfego HTTPS em busca de ameaças usando AWS Network Firewall, e então criptografá-lo novamente.

→Crie ou importe um certificado CA no ACM. Crie uma configuração de inspeção TLS na política de firewall que referencia esta CA. Distribua o certificado CA para sistemas clientes como uma CA raiz confiável.

Por quê: O Network Firewall realiza a inspeção TLS via uma abordagem "man-in-the-middle", usando uma CA que você fornece para re-assinar certificados em tempo real. Os clientes devem confiar nesta CA para evitar erros de certificado.

Bloquear consultas DNS para domínios maliciosos conhecidos em todas as VPCs em uma AWS Organization.

→Crie grupos de regras de DNS Firewall em uma conta central usando listas de domínios gerenciados pela AWS. Compartilhe os grupos de regras via RAM e associe-os a VPCs em contas membro.

Por quê: O DNS Firewall fornece inteligência de ameaças gerenciada e atualizável centralmente para bloquear domínios maliciosos na camada de resolução DNS, um controle de segurança crítico.

Criptografar todo o tráfego de rede entre instâncias EC2 na mesma VPC sem alterações na aplicação.

→Use tipos de instância baseados no AWS Nitro System.

Por quê: As instâncias Nitro criptografam automaticamente todo o tráfego entre instâncias no nível de hardware, fornecendo criptografia transparente e em velocidade de linha sem necessidade de configuração.