Preserve o espaço IP roteável em projetos de VPC com várias contas para sub-redes sem workload - Recomendações da AWS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Preserve o espaço IP roteável em projetos de VPC com várias contas para sub-redes sem workload

Criado por Adam Spicer (AWS)

Repositório de código: padrão CIDRs secundários não roteáveis

Ambiente: produção

Tecnologias: Infraestrutura DevOps; Gestão e governança; Rede

Serviços da AWS: AWS Transit Gateway; Amazon VPC; Elastic Load Balancing (ELB)

Resumo

A Amazon Web Services (AWS) publicou as melhores práticas que recomendam o uso de sub-redes dedicadas em uma nuvem privada virtual (VPC) para anexos do gateway de trânsito e endpoints do Gateway Load Balancer (para oferecer suporte ao AWS Network Firewall ou dispositivos de terceiros). Essas sub-redes são usadas para conter interfaces de rede elásticas para esses serviços. Se você usa o AWS Transit Gateway e um balanceador de carga do gateway, duas sub-redes são criadas em cada zona de disponibilidade da VPC. Devido à forma como as VPCs são projetadas, essas sub-redes extras não podem ser menores que uma máscara /28 e podem consumir um espaço de IP roteável precioso que, de outra forma, poderia ser usado para cargas de trabalho roteáveis. Esse padrão demonstra como você pode usar um intervalo de Encaminhamento Entre Domínios Sem Classificação (CIDR) secundário, não roteável para essas sub-redes dedicadas para ajudar a preservar o espaço IP roteável.

Pré-requisitos e limitações

Pré-requisitos

Arquitetura

Arquitetura de destino

Esse padrão inclui duas arquiteturas de referência: uma arquitetura tem sub-redes para anexos do Transit Gateway (TGW) e um endpoint do balanceador de carga do gateway (GWLBE), e a segunda arquitetura tem sub-redes somente para anexos TGW.

Arquitetura 1 ‒ VPC conectada ao TGW com roteamento de entrada para um dispositivo

O diagrama a seguir representa uma arquitetura de referência para uma VPC que abrange duas zonas de disponibilidade. Na entrada, a VPC usa um padrão de roteamento de entrada para direcionar o tráfego destinado à sub-rede pública para um dispositivo para inspeção do firewall. bump-in-the-wire Um anexo TGW suporta a saída das sub-redes privadas para uma VPC separada.

Esse padrão usa um intervalo CIDR não roteável para a sub-rede de anexo TGW e a sub-rede GWLbE. Na tabela de rotas do TGW, esse CIDR não roteável é configurado com uma rota de buraco negro (estática) usando um conjunto de rotas mais específicas. Se as rotas fossem propagadas para a tabela de rotas do TGW, essas rotas de buraco negro mais específicas se aplicariam.

Neste exemplo, o CIDR roteável /23 é dividido e totalmente alocado às sub-redes roteáveis.

VPC conectada ao TGW com roteamento de entrada para um dispositivo.

Arquitetura 2 – VPC conectada ao TGW

O diagrama a seguir representa outra arquitetura de referência para uma VPC que abrange duas zonas de disponibilidade. Um anexo TGW oferece suporte ao tráfego de saída (egress) das sub-redes privadas para uma VPC separada. Ele usa um intervalo CIDR não roteável somente para a sub-rede de anexos do TGW. Na tabela de rotas TGW, esse CIDR não roteável é configurado com uma rota blackhole usando um conjunto de rotas mais específicas. Se as rotas fossem propagadas para a tabela de rotas do TGW, essas rotas de buraco negro mais específicas se aplicariam.

Neste exemplo, o CIDR roteável /23 é dividido e totalmente alocado às sub-redes roteáveis.

A VPC abrange duas zonas de disponibilidade com anexo TGW para saída de sub-redes privadas para uma VPC separada.

Ferramentas

Serviços e recursos da AWS

  • A Amazon Virtual Private Cloud (Amazon VPC) ajuda a iniciar recursos da AWS em uma rede virtual definida por você. Essa rede virtual é semelhante a uma rede tradicional que você operaria no próprio datacenter, com os benefícios de usar a infraestrutura escalável da AWS. Nesse padrão, os CIDRs secundários da VPC são usados para preservar o espaço IP roteável nos CIDRs da workload.

  • O roteamento de entrada do gateway da Internet (associações de borda) pode ser usado junto com os endpoints do balanceador de carga do gateway para sub-redes dedicadas não roteáveis.

  • O AWS Transit Gateway é um hub central que conecta VPCs e redes on-premises. Nesse padrão, as VPCs são conectadas centralmente a um gateway de trânsito, e os anexos do gateway de trânsito estão em uma sub-rede dedicada não roteável.

  • Os balanceadores de carga do gateway ajudam você a implantar, escalar e gerenciar dispositivos virtuais, como firewalls, sistemas de detecção e prevenção de intrusões e sistemas de inspeção profunda de pacotes. O gateway atua como um único ponto de entrada e saída para todo o tráfego. Nesse padrão, os endpoints de um balanceador de carga do gateway podem ser usados em uma sub-rede dedicada não roteável.

  • O AWS Network Firewall é um serviço gerenciado e de firewall de rede com estado para detecção e prevenção de intrusões para VPCs na Nuvem AWS. Nesse padrão, os endpoints de um firewall podem ser usados em uma sub-rede não roteável dedicada.

Repositório de código

Um runbook e CloudFormation modelos da AWS para esse padrão estão disponíveis no repositório de padrões CIDR secundários GitHub não roteáveis. Você pode usar os arquivos de amostra para configurar um laboratório de trabalho em seu ambiente.

Práticas recomendadas

AWS Transit Gateway

  • Use uma sub-rede separada para cada anexo da VPC do gateway.

  • Aloque uma sub-rede /28 do intervalo CIDR secundário não roteável para as sub-redes do anexo do gateway de trânsito.

  • Em cada tabela de rotas do Transit Gateway, adicione uma rota estática e mais específica para o intervalo CIDR não roteável como um buraco negro.

Balanceador de carga do gateway e roteamento de entrada

  • Use o roteamento de entrada para direcionar o tráfego da Internet para os endpoints do balanceador de carga do gateway.

  • Use uma sub-rede separada para cada endpoint do balanceador de carga do gateway.

  • Aloque uma sub-rede /28 do intervalo CIDR secundário não roteável para as sub-redes de endpoint do balanceador de carga do gateway.

Épicos

TarefaDescriçãoHabilidades necessárias

Determine o intervalo CIDR não roteável.

Determine um intervalo CIDR não roteável que será usado para a sub-rede de anexo do gateway de trânsito e (opcionalmente) para qualquer sub-rede de endpoint do balanceador de carga do gateway ou do Network Firewall. Esse intervalo de CIDR será usado como CIDR secundário para a VPC. Ele não deve ser roteável a partir do intervalo CIDR primário da VPC ou de uma rede maior.

Arquiteto de nuvem

Determine intervalos de CIDR roteáveis para VPCs.

Determine um conjunto de intervalos CIDR roteáveis que serão usados para suas VPCs. Esse intervalo de CIDR será usado como o CIDR primário para suas VPCs.

Arquiteto de nuvem

Criar VPCs.

Crie suas VPCs e conecte-as ao gateway de trânsito. Cada VPC deve ter um intervalo CIDR primário que seja roteável e um intervalo CIDR secundário que não seja roteável, com base nos intervalos que você determinou nas duas etapas anteriores.

Arquiteto de nuvem
TarefaDescriçãoHabilidades necessárias

Crie CIDRs não roteáveis mais específicos como buracos negros.

Cada tabela de rotas do gateway de trânsito precisa ter um conjunto de rotas blackhole criadas para os CIDRs não roteáveis. Eles são configurados para garantir que qualquer tráfego do CIDR VPC secundário permaneça não roteável e não vaze para a rede maior. Essas rotas devem ser mais específicas do que o CIDR não roteável definido como CIDR secundário na VPC. Por exemplo, se o CIDR secundário não roteável for 100.64.0.0/26, as rotas do blackhole na tabela de rotas do Transit Gateway deverão ser 100.64.0.0/27 e 100.64.0.32/27.

Arquiteto de nuvem

Recursos relacionados

Mais informações

O intervalo CIDR secundário não roteável também pode ser útil ao trabalhar com implantações de contêineres em maior escala que exigem um grande conjunto de endereços IP. Você pode usar esse padrão com um gateway NAT privado para usar uma sub-rede não roteável para hospedar suas implantações de contêineres. Para obter mais informações, consulte a postagem de blog Como resolver o esgotamento de IP privado com a solução de NAT privado.