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á.
# Redes
A implantação de um Outpost depende de uma conexão resiliente com seu AZ âncora para que as operações de gerenciamento, monitoramento e serviço funcionem adequadamente. Você deve provisionar sua rede local para fornecer conexões de rede redundantes para cada rack Outpost e conectividade confiável de volta aos pontos de ancoragem na nuvem. AWS Considere também os caminhos de rede entre as workloads de aplicativos em execução no Outpost e os outros sistemas on-premises e na nuvem com os quais elas se comunicam. Como você direcionará esse tráfego em sua rede?
**Topics**
+ [Anexo de rede](network-attachment.md)
+ [Conectividade de âncora](anchor-connectivity.md)
+ [Roteamento de aplicativos/workloads](applicationworkload-routing.md)
# Anexo de rede
Cada AWS Outposts rack é configurado com top-of-rack switches redundantes chamados Outpost Networking Devices (). ONDs Os servidores de computação e armazenamento em cada rack se conectam a ambos ONDs. Você deve conectar cada OND a um switch separado chamado Customer Networking Device (CND) em seu data center para fornecer diversos caminhos físicos e lógicos para cada rack Outpost. ONDs conecte-se ao seu CNDs com uma ou mais conexões físicas usando cabos de fibra óptica e transceptores ópticos. As [conexões físicas](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) são configuradas em [links lógicos de grupo de agregação de links (LAG)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation).
![\[Diagrama mostrando o Outpost com vários racks com conexões de rede redundantes\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
Os links OND para CND são sempre configurados em um LAG, mesmo que a conexão física seja um único cabo de fibra óptica. A configuração dos links como grupos de LAG permite aumentar a largura de banda do link adicionando conexões físicas ao grupo lógico. Os links LAG são configurados como troncos Ethernet IEEE 802.1q para permitir a rede segregada entre o Outpost e a rede on-premises.
Cada Outpost tem pelo menos duas redes logicamente segregadas que precisam se comunicar com ou através da rede do cliente:
+ **Rede de link de serviço** — aloca os endereços IP do link de serviço aos servidores do Outpost e facilita a comunicação com a rede local para permitir que os servidores se conectem novamente aos pontos de ancoragem do Outpost na região. Quando você tem várias implementações de rack em um único Outposts lógicos, você precisa atribuir um Service Link /26 CIDR para cada rack.
+ **Rede de gateway local**: permite a comunicação entre as sub-redes VPC no Outpost e a rede on-premises por meio do Gateway local do Outpost (LGW).
Essas redes segregadas se conectam à rede local por meio de um conjunto de [conexões point-to-point IP nos links LAG](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity). Cada link OND para CND LAG é configurado com VLAN IDs, sub-redes IP point-to-point (/30 ou /31) e emparelhamento eBGP para cada rede segregada (link de serviço e LGW). Você deve considerar os links LAG, com suas point-to-point VLANs e sub-redes, como conexões de camada 2 segmentadas e roteadas de camada 3. As conexões IP roteadas fornecem caminhos lógicos redundantes que facilitam a comunicação entre as redes segregadas no Outpost e a rede on-premises.
![\[Diagrama mostrando o emparelhamento de links de serviço\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Diagrama mostrando o emparelhamento do gateway local\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
Você deve encerrar os links LAG de camada 2 (e os deles VLANs) nos switches CND conectados diretamente e configurar as interfaces IP e o emparelhamento BGP nos switches CND. Você não deve preencher o LAG VLANs entre os switches do data center. Para obter mais informações, consulte [Conectividade da camada de rede](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) no *Manual do usuário do AWS Outposts *.
Dentro de um posto avançado lógico de vários racks, ONDs eles são interconectados de forma redundante para fornecer conectividade de rede altamente disponível entre os racks e as cargas de trabalho executadas nos servidores. AWS é responsável pela disponibilidade da rede dentro do Outpost.
## Práticas recomendadas para conexão de rede altamente disponível sem ACE
+ Conecte cada Outpost Networking Device (OND) em um rack do Outpost a um Customer Networking Device (CND) separado no datacenter.
+ Encerre os links de camada 2 VLANs, as sub-redes IP de camada 3 e o emparelhamento BGP nos switches Customer Networking Device (CND) conectados diretamente. Não conecte o OND ao CND VLANs entre a CNDs rede local ou entre ela.
+ Adicione links aos grupos de agregação de links (LAGs) para aumentar a largura de banda disponível entre o Outpost e o data center. Não confie na largura de banda agregada dos diversos caminhos por meio de ambos. ONDs
+ Use os diversos caminhos através do redundante ONDs para fornecer conectividade resiliente entre as redes Outpost e a rede local.
+ Para obter a redundância ideal e permitir a manutenção do OND sem interrupções, recomendamos que os clientes configurem os anúncios e as políticas do BGP da seguinte forma:
+ O equipamento de rede do cliente deve receber anúncios de BGP da Outpost sem alterar os atributos do BGP e habilitar o BGP caso seja necessária manutenção. multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink A rede do cliente deve preferir rotas do Outpost com caminho AS de comprimento 1 em vez de rotas com caminho AS de comprimento 4, ou seja, reagir ao acréscimo do caminho AS.
+ A rede de clientes deve anunciar prefixos BGP iguais com os mesmos atributos para todos no Outpost. ONDs Por padrão, a carga da rede do Outpost equilibra o tráfego de saída (para o cliente) entre todos os uplinks. As políticas de roteamento são usadas no lado do Outpost para afastar o tráfego de um OND específico, caso seja necessária manutenção. Todos os prefixos BGP iguais do lado do cliente ONDs são necessários para realizar essa mudança de tráfego e realizar a manutenção sem interrupções. Quando a manutenção é necessária na rede do cliente, recomendamos usar o acréscimo do caminho AS para afastar temporariamente o tráfego de um determinado uplink ou dispositivo.
## Práticas recomendadas para conexão de rede altamente disponível com ACE
Para uma implantação de vários racks com quatro ou mais racks de computação, você deve usar o rack Aggregation, Core, Edge (ACE), que atuará como um ponto de agregação de rede para reduzir o número de links de fibra para seus dispositivos de rede locais. O rack ACE fornece conectividade com cada rack Outposts, portanto, AWS será o ONDs proprietário da alocação e configuração da interface VLAN entre ONDs os dispositivos de rede ACE e os dispositivos de rede.
Camadas de rede isoladas para redes Service Link e Local Gateway ainda são necessárias, independentemente do uso ou não de um rack ACE, que visa ter uma VLAN point-to-point (/30 ou /31), sub-redes IP e configuração de emparelhamento eBGP para cada rede segregada. As arquiteturas propostas devem seguir qualquer uma das duas arquiteturas da seguinte forma:
![\[Dispositivos de rede para dois clientes\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Com essa arquitetura, o cliente deve ter dois dispositivos de rede (CND) para interconectar os dispositivos de rede ACE, fornecendo redundância.
+ Para cada conexão física, você deve habilitar um LAG (para aumentar a largura de banda disponível entre o Outpost e o data center), mesmo que seja uma única porta física, e ele transportará dois segmentos de rede, com 2 point-to-point VLANs (/30 ou /31), e configurações de eBGP entre e. ACEs CNDs
+ Em um estado estável, o tráfego é balanceado de carga seguindo o to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/load balanceamento de padrões de vários caminhos de custo igual (ECMP) ativado e anunciados os prefixos do cliente com a mesma métrica de BGP nas 4 conexões de emparelhamento eBGP.
+ Para obter a redundância ideal e permitir a manutenção do OND sem interrupções, recomendamos que os clientes sigam estas recomendações:
+ O dispositivo de rede do cliente deve anunciar prefixos BGP iguais com os mesmos atributos para todos no Outpost. ONDs
+ O dispositivo de rede do cliente deve receber anúncios de BGP do Outpost sem alterar os atributos do BGP e habilitar o balanceamento de vários caminhos/carga do BGP.
![\[Dispositivos de rede para quatro clientes\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Com essa arquitetura, o cliente terá quatro dispositivos de rede (CND) para interconectar os dispositivos de rede ACE, fornecendo redundância e a mesma lógica de rede VLANs, incluindo eBGP e ECMP aplicáveis a uma arquitetura de 2 CND.
# Conectividade de âncora
Um [link de serviço Outpost](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) se conecta a âncoras públicas ou privadas (não ambas) em uma Zona de Disponibilidade (AZ) específica na região principal do Outpost. Os servidores Outpost iniciam conexões VPN de link de serviço de saída a partir de seus endereços IP de link de serviço até os pontos de ancoragem na AZ âncora. Essas conexões usam a porta UDP e TCP 443. AWS é responsável pela disponibilidade dos pontos de ancoragem na Região.
Você deve garantir que os endereços IP do link do serviço Outpost possam se conectar por meio de sua rede aos pontos de ancoragem na AZ âncora. Os endereços IP do link de serviço não precisam se comunicar com outros hosts na sua rede local.
Os pontos de ancoragem públicos residem nos [intervalos de IP públicos](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) da região (nos blocos CIDR do EC2 serviço) e podem ser acessados pela Internet ou por interfaces virtuais públicas [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) (). VIFs O uso de pontos de ancoragem públicos permite uma seleção de caminhos mais flexível, pois o tráfego do link de serviço pode ser roteado por qualquer caminho disponível que possa alcançar com êxito os pontos de ancoragem na Internet pública.
Os pontos de ancoragem privados permitem que você use seus intervalos de endereços IP para conectividade de âncora. Os pontos de ancoragem privados são criados em uma [sub-rede privada dentro de uma VPC dedicada](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) usando endereços IP atribuídos pelo cliente. A VPC é criada no proprietário do recurso Outpost e você é responsável por garantir Conta da AWS que a VPC esteja disponível e configurada corretamente. [Use uma Política de Controle de Segurança (SCP) em AWSOrigamiServiceGateway Organizations para impedir que os usuários excluam essa Virtual Private Cloud (VPC). Os pontos de ancoragem privados devem ser acessados usando o Direct Connect private. VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/)
Você deve provisionar caminhos de rede redundantes entre o Outpost e os pontos de ancoragem na região, com conexões terminando em dispositivos separados em mais de um local. O roteamento dinâmico deve ser configurado para redirecionar automaticamente o tráfego para caminhos alternativos quando as conexões ou os dispositivos de rede falharem. Você deve provisionar capacidade de rede suficiente para garantir que a falha de um caminho de WAN não sobrecarregue os caminhos restantes.
O diagrama a seguir mostra três Outposts com caminhos de rede redundantes até sua âncora, bem AWS Direct Connect como conectividade pública AZs com a Internet. O Outpost A e o Outpost B estão ancorados em diferentes zonas de disponibilidade na mesma região. O Outpost A se conecta a pontos de ancoragem privados no AZ 1 da região 1. O Outpost B se conecta a pontos de ancoragem públicos na AZ 2 da região 1. O Outpost C se conecta a âncoras públicas no AZ 1 da região 2.
![\[Diagrama mostrando conectividade de âncora altamente disponível AWS Direct Connect e acesso público à Internet\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
O Outpost A tem três caminhos de rede redundantes para alcançar seu ponto de ancoragem privado. Dois caminhos estão disponíveis por meio de circuitos redundantes do Direct Connect em um único local do Direct Connect. O terceiro caminho está disponível por meio de um circuito do Direct Connect em um segundo local do Direct Connect. Esse design mantém o tráfego do link de serviço do Outpost A em redes privadas e fornece redundância de caminhos que permite a falha de qualquer um dos circuitos do Direct Connect ou a falha de um local inteiro do Direct Connect.
O Outpost B tem quatro caminhos de rede redundantes para alcançar seu ponto de ancoragem público. Três caminhos estão disponíveis por meio de VIFs provisionamento público nos circuitos e locais do Direct Connect usados pelo Outpost A. O quarto caminho está disponível por meio da WAN do cliente e da Internet pública. O tráfego do link de serviço do Outpost B pode ser roteado por qualquer caminho disponível que possa alcançar com sucesso os pontos de ancoragem na Internet pública. O uso dos caminhos do Direct Connect pode fornecer latência mais consistente e maior disponibilidade de largura de banda, enquanto o caminho público da Internet pode ser usado para cenários de recuperação de desastres (DR) ou aumento de largura de banda.
O Outpost C tem dois caminhos de rede redundantes para alcançar seu ponto de ancoragem público. O Outpost C é implantado em um datacenter diferente do Outpost A e B. O datacenter do Outpost C não tem circuitos dedicados conectados à WAN do cliente. Em vez disso, o data center tem conexões de internet redundantes fornecidas por dois provedores de serviços de Internet diferentes ()ISPs. O tráfego do link de serviço do Outpost C pode ser roteado por qualquer uma das redes do ISP para alcançar os pontos de ancoragem na Internet pública. Esse design permite flexibilidade para rotear o tráfego do link de serviço em qualquer conexão pública de Internet disponível. No entanto, o end-to-end caminho depende de redes públicas de terceiros, nas quais a disponibilidade da largura de banda e a latência da rede flutuam.
O caminho de rede entre um Outpost e seus pontos de ancoragem do link de serviço deve atender às seguintes especificações de largura de banda:
+ 500 Mbps - 1 Gbps de largura de banda disponível por rack do Outpost (por exemplo, 3 racks: largura de banda disponível de 1,5 a 3 Gbps)
## Práticas recomendadas para conectividade de âncora altamente disponível
+ Provisione caminhos de rede redundantes entre cada Outpost e seus pontos de ancoragem na região.
+ Use os caminhos do Direct Connect (DX) para controlar a latência e a disponibilidade da largura de banda.
+ Certifique-se de que as portas TCP e UDP 443 estejam abertas (de saída) dos blocos CIDR do Outpost Service Link para os intervalos de [endereços EC2 IP](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) na região principal. Verifique se as portas estão abertas em todos os caminhos de rede.
+ Acompanhe os intervalos de endereços EC2 IP da Amazon em seu firewall se você estiver usando um subconjunto de intervalos CIDR para a região.
+ Verifique se cada caminho atende aos requisitos de disponibilidade de largura de banda e latência.
+ Use o roteamento dinâmico para automatizar o redirecionamento de tráfego em caso de falhas na rede.
+ Teste o roteamento do tráfego do link de serviço em cada caminho de rede planejado para garantir que o caminho funcione conforme o esperado.
# Roteamento de aplicativos/workloads
Há dois caminhos fora do Outpost para workloads de aplicativos:
+ O caminho do link de serviço: considere que o tráfego do aplicativo competirá com o tráfego do plano de controle do Outposts, além de limitar a [MTU a 1300 bytes](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links).
+ O caminho do gateway local (LGW): considere que a rede local do cliente permite acesso a aplicativos locais e também no. Região da AWS
Você configura as tabelas de rotas de sub-rede do Outpost para controlar qual caminho seguir para alcançar as redes de destino. As rotas apontadas para o LGW direcionarão o tráfego para fora do gateway local e para a rede on-premises. As rotas apontadas para os serviços e recursos da região, como Internet Gateway, NAT Gateway, Virtual Private Gateway e TGW, usarão o [link de serviço](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) para atingir essas metas. Se você tiver uma conexão de emparelhamento de VPC com várias VPCs no mesmo Posto Avançado, o tráfego entre elas VPCs permanece no Posto Avançado e não usa o link de serviço para a Região. *Para obter informações sobre emparelhamento de VPC, consulte Conectar [usando emparelhamento de VPCs VPC no Guia do usuário do](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) Amazon VPC.*
![\[Diagrama mostrando uma visualização do link de serviço Outpost e dos caminhos de rede LGW\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
Ao planejar o roteamento de aplicativos, você deve ter cuidado para considerar tanto a operação normal quanto a disponibilidade limitada do roteamento e do serviço durante falhas na rede. O caminho do link de serviço não está disponível quando um Outpost é desconectado da região.
Você deve provisionar caminhos diversos e configurar o roteamento dinâmico entre o LGW do Outpost e seus aplicativos, sistemas e usuários on-premises críticos. Caminhos de rede redundantes permitem que a rede direcione o tráfego para contornar falhas e garantir que os recursos locais possam se comunicar com as workloads em execução no Outpost durante falhas parciais na rede.
As configurações de rota do VPC do Outpost são estáticas. Você configura tabelas de roteamento de sub-rede por meio da Console de gerenciamento da AWS CLI e de outras ferramentas de Infraestrutura como Código (IaC); no entanto, você não poderá modificar as tabelas de roteamento de sub-rede durante um evento de desconexão. APIs Você precisará restabelecer a conectividade entre o Outpost e a região para atualizar as tabelas de rotas. Use as mesmas rotas para operações normais que você planeja usar durante eventos de desconexão.
Os recursos no Outpost podem acessar a Internet por meio do link de serviço e de um Internet Gateway (IGW) na região ou por meio do caminho Local Gateway (LGW). O roteamento do tráfego da Internet pelo caminho LGW e pela rede local permite que você use os pontos de entrada/saída da Internet locais existentes e pode fornecer taxas de saída de AWS dados mais baixas e de latência mais altas MTUs e reduzidas em comparação ao uso do caminho do link de serviço para um IGW na região.
Se seu aplicativo precisar ser executado on-premises e precisar ser acessível pela Internet pública, você deverá rotear o tráfego do aplicativo por meio de suas conexões de Internet on-premises para o LGW para alcançar os recursos no Outpost.
Embora você possa configurar sub-redes em um Outpost como sub-redes públicas na região, essa pode ser uma prática indesejável para a maioria dos casos de uso. O tráfego de entrada da Internet entrará pelo Região da AWS e será roteado pelo link de serviço para os recursos em execução no Outpost.
O tráfego de resposta, por sua vez, será roteado pelo link de serviço e retornará pelas conexões Região da AWS de internet do serviço. Esse padrão de tráfego pode aumentar a latência e incorrer em cobranças de saída de dados à medida que o tráfego sai da região em direção ao Outpost e quando o tráfego volta pela região e sai para a Internet. Se seu aplicativo puder ser executado na região, a região será o melhor lugar para executá-lo.
O tráfego entre os recursos da VPC (na mesma VPC) sempre seguirá a rota CIDR da VPC local e será roteado entre sub-redes pelos roteadores VPC implícitos.
Por exemplo, o tráfego entre uma EC2 instância em execução no Outpost e um VPC Endpoint na região sempre será roteado pelo link de serviço.
![\[Diagrama mostrando o roteamento VPC local por meio dos roteadores implícitos\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Práticas recomendadas para roteamento de aplicativos/cargas de trabalho
+ Use o caminho do gateway local (LGW) em vez do caminho do link de serviço sempre que possível.
+ Direcione o tráfego da Internet pelo caminho do LGW.
+ Configure as tabelas de roteamento de sub-rede do Outpost com um conjunto padrão de rotas: elas serão usadas tanto para operações normais quanto durante eventos de desconexão.
+ Provisione caminhos de rede redundantes entre o LGW do Outpost e os recursos essenciais de aplicativos on-premises. Use o roteamento dinâmico para automatizar o redirecionamento de tráfego em caso de falhas na rede on-premises.