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á.
# Conectividade de VPC para VPC
*Os clientes podem usar dois padrões diferentes de conectividade de VPC para configurar ambientes de várias VPC: *muitas para muitas*, ou hub and spoke.* Na many-to-many abordagem, o tráfego entre cada VPC é gerenciado individualmente entre cada VPC. No hub-and-spoke modelo, todo o tráfego entre VPC flui por meio de um recurso central, que roteia o tráfego com base nas regras estabelecidas.
# emparelhamento da VPC
A primeira maneira de conectar dois VPCs é usar o peering de VPC. Nesta configuração, uma conexão permite a conectividade bidirecional total entre o. VPCs Essa conexão de emparelhamento é usada para rotear o tráfego entre o. VPCs VPCs em diferentes contas e regiões da AWS também podem ser emparelhadas. Toda transferência de dados por uma conexão de emparelhamento VPC que permanece dentro de uma zona de disponibilidade é gratuita. Toda transferência de dados por meio de uma conexão emparelhada de VPC que cruza as zonas de disponibilidade é cobrada de acordo com as taxas de transferência de dados padrão da região. Se VPCs forem sincronizados entre regiões, serão aplicadas taxas padrão de transferência de dados entre regiões.
[O emparelhamento de VPC é point-to-point conectividade e não oferece suporte ao roteamento transitivo.](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering) Por exemplo, se você tiver uma conexão de [emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) entre a VPC A e a VPC B e entre a VPC A e a VPC C, uma instância na VPC B não pode transitar pela VPC A para chegar à VPC C. Para rotear pacotes entre a VPC B e a VPC C, é necessário criar uma conexão de emparelhamento de VPC direta.
Em grande escala, quando você tem dezenas ou centenas de VPCs, interconectá-las com o peering pode resultar em uma malha de centenas ou milhares de conexões de peering. Um grande número de conexões pode ser difícil de gerenciar e escalar. Por exemplo, se você tiver 100 VPCs e quiser configurar um peering de malha completa entre eles, serão necessárias 4.950 conexões de peering [`n(n-1)/2`], onde `n` é o número total de. VPCs Há um [limite máximo](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) de 125 conexões de peering ativas por VPC.
![\[Um diagrama que descreve a configuração da rede usando o emparelhamento de VPC\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)
Se você estiver usando o emparelhamento de VPC, a conectividade local (VPN e/ou Direct Connect) deve ser estabelecida para cada VPC. Os recursos em uma VPC não podem ser acessados localmente usando a conectividade híbrida de uma VPC emparelhada, conforme mostrado na figura anterior.
O emparelhamento de VPC é melhor usado quando os recursos em uma VPC precisam se comunicar com os recursos em outra VPC, o ambiente de ambas VPCs é controlado e protegido e o número de VPCs pessoas conectadas é menor que 10 (para permitir o gerenciamento individual de cada conexão). O peering de VPC oferece o menor custo geral e o maior desempenho agregado quando comparado a outras opções de conectividade entre VPCs.
# AWS Transit Gateway
[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)fornece um design de hub and spoke para conexão VPCs e redes locais como um serviço totalmente gerenciado, sem exigir que você provisione dispositivos virtuais de terceiros. Nenhuma sobreposição de VPN é necessária e AWS gerencia alta disponibilidade e escalabilidade.
O Transit Gateway permite que os clientes conectem milhares de VPCs. Você pode conectar toda a sua conectividade híbrida (conexões VPN e Direct Connect) a um único gateway, consolidando e controlando toda a configuração de AWS roteamento da sua organização em um só lugar (consulte a figura a seguir). O Transit Gateway controla como o tráfego é roteado entre todas as redes spoke conectadas usando tabelas de rotas. Esse hub-and-spoke modelo simplifica o gerenciamento e reduz os custos operacionais porque VPCs somente se conecta à instância do Transit Gateway para obter acesso às redes conectadas.
![\[Um diagrama representando o design do hub e do raio com AWS Transit Gateway\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)
O Transit Gateway é um recurso regional e pode conectar milhares de pessoas VPCs dentro do mesmo Região da AWS. Você pode conectar vários gateways em uma única conexão Direct Connect para conectividade híbrida. Normalmente, você pode usar apenas uma instância do Transit Gateway conectando todas as suas instâncias de VPC em uma determinada região e usar tabelas de roteamento do Transit Gateway para isolá-las sempre que necessário. Observe que você não precisa de gateways de trânsito adicionais para alta disponibilidade, porque os gateways de trânsito são altamente disponíveis por design; para redundância, use um único gateway em cada região. No entanto, há um caso válido para criar vários gateways para limitar o raio de explosão de configuração incorreta, segregar as operações do plano de controle e as administrativas. ease-of-use
Com o peering do Transit Gateway, os clientes podem emparelhar suas instâncias do Transit Gateway na mesma ou em várias regiões e rotear o tráfego entre elas. Ele usa a mesma infraestrutura subjacente do peering de VPC e, portanto, é criptografado. Para obter mais informações, consulte [Criação de uma rede global usando o emparelhamento entre regiões do AWS Transit Gateway. O AWS Transit Gateway agora oferece suporte ao peering](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/) [entre regiões.](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/)
Coloque a instância do Transit Gateway da sua organização em sua conta de Serviços de Rede. Isso permite o gerenciamento centralizado por engenheiros de rede que gerenciam a conta de serviços de rede. Use o AWS Resource Access Manager (RAM) para compartilhar uma instância do Transit Gateway para conexão VPCs entre várias contas em sua organização da AWS na mesma região.AWS RAM permite que você compartilhe AWS recursos de forma fácil e segura com qualquer Conta da AWS pessoa ou dentro da sua organização da AWS. Para obter mais informações, consulte [Automatizar anexos do AWS Transit Gateway a um gateway de trânsito em uma postagem no blog da conta central](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/).
O Transit Gateway também permite estabelecer conectividade entre a infraestrutura SD-WAN e o AWS uso do Transit Gateway Connect. Use um anexo Transit Gateway Connect com o Border Gateway Protocol (BGP) para roteamento dinâmico e o protocolo de túnel Generic Routing Encapsulation (GRE) para alto desempenho, oferecendo até 20 Gbps de largura de banda total por anexo Connect (até quatro pares do Transit Gateway Connect por anexo Connect). Ao usar o Transit Gateway Connect, você pode integrar a infraestrutura SD-WAN local ou os dispositivos SD-WAN executados na nuvem por meio de um anexo de VPC ou Direct Connect anexo como camada de transporte subjacente. Consulte [Simplifique a conectividade SD-WAN com o AWS Transit Gateway Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/) para obter arquiteturas de referência e configuração detalhada.
# Solução Transit VPC
O [Transit VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) pode criar conectividade entre VPC VPCs por um meio diferente do peering de VPC, introduzindo um design de hub and spoke para conectividade entre VPCs. Em uma rede VPC de trânsito, uma VPC central (o hub VPC) se conecta a todas as outras VPC (falei VPC) por meio de uma conexão VPN que normalmente aproveita o BGP over. [IPsec](https://en.wikipedia.org/wiki/IPsec) A VPC central contém instâncias do [Amazon Elastic Compute Cloud (](https://aws.amazon.com/ec2/)Amazon EC2) executando dispositivos de software que roteiam o tráfego de entrada para seus destinos usando a sobreposição de VPN. O peering de VPC Transit tem as seguintes vantagens:
+ O roteamento transitivo é habilitado usando a rede VPN de sobreposição, permitindo um design de hub and spoke.
+ Ao usar software de um fornecedor terceirizado na EC2 instância na VPC de trânsito do hub, a funcionalidade do fornecedor está relacionada à segurança avançada (experiência de camada 7). firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) ) can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring
+ A arquitetura Transit VPC permite a conectividade que pode ser desejada em alguns casos de uso. Por exemplo, você pode conectar uma GovCloud instância da AWS e uma VPC de região comercial ou uma instância do Transit Gateway a uma VPC de trânsito e habilitar a conectividade entre VPCs entre as duas regiões. Avalie seus requisitos de segurança e conformidade ao considerar essa opção. Para segurança adicional, você pode implantar um modelo de inspeção centralizado usando os padrões de projeto descritos posteriormente neste whitepaper.
![\[Um diagrama que descreve uma VPC de trânsito com dispositivos virtuais\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)
O Transit VPC apresenta seus próprios desafios, como custos mais altos para operar dispositivos virtuais de fornecedores terceirizados com EC2 base no tamanho/família da instância, taxa de transferência limitada por conexão VPN (até 1,25 Gbps por túnel VPN) e sobrecarga adicional de configuração, gerenciamento e resiliência (os clientes são responsáveis por gerenciar o HA e a redundância das instâncias que executam os dispositivos virtuais de fornecedores terceirizados). EC2
## Emparelhamento de VPC versus Transit VPC versus Transit Gateway
*Tabela 1 — Comparação de conectividade*
| Critérios | emparelhamento da VPC | VPC de trânsito | Gateway de trânsito | PrivateLink | Cloud WAN | VPC Lattice |
| --- | --- | --- | --- | --- | --- | --- |
| Escopo | Regional/Global | Regional | Regional | Regional | Global | Regional |
| Arquitetura | Malha completa | Baseado em VPN hub-and-spoke | Baseado em anexos hub-and-spoke | Modelo de fornecedor ou consumidor | Baseado em anexos, multirregional | Conectividade de aplicativo para aplicativo |
| Escala | 125 pares ativos/VPC | Depende do roteador virtual/ EC2 | 5000 anexos por região | Sem limites | 5000 anexos por rede principal | 500 associações de VPC por serviço |
| Segmentação | Grupos de segurança | Gerenciado pelo cliente | Tabelas de rotas do Transit Gateway | Sem segmentação | Segmentos | Políticas de serviço e rede de serviços |
| Latência | Menor | Extra, devido à sobrecarga de criptografia da VPN | Shop adicional do Transit Gateway | O tráfego permanece no backbone da AWS, os clientes devem testar | Usa o mesmo plano de dados do Transit Gateway | O tráfego permanece no backbone da AWS, os clientes devem testar |
| Limite de largura de banda | Limites por instância, sem limite agregado | Sujeito aos limites de largura de banda da EC2 instância com base no tamanho/família | Até 100 Gbps (rajada) /conexão | 10 Gbps por zona de disponibilidade, escalável automaticamente até 100 Gbps | Até 100 Gbps (rajada) /conexão | 10 Gbps por zona de disponibilidade |
| Visibilidade | Logs de fluxo da VPC | Registros e métricas de fluxo de VPC CloudWatch | Gerenciador de rede do Transit Gateway, registros de fluxo de VPC, métricas CloudWatch | CloudWatch Métricas | Gerenciador de rede, registros de fluxo de VPC, métricas CloudWatch | CloudWatch Registros de acesso |
| Grupo de segurança referência cruzada | Compatível | Sem compatibilidade | Sem compatibilidade | Sem compatibilidade | Sem compatibilidade | Não aplicável |
| IPv6 apoio | Compatível | Depende do dispositivo virtual | Compatível | Compatível | Compatível | Compatível |
# AWS PrivateLink
[AWS PrivateLink](https://aws.amazon.com/privatelink/)fornece conectividade privada entre VPCs os serviços da AWS e suas redes locais sem expor seu tráfego à Internet pública. Os endpoints VPC de interface, alimentados por AWS PrivateLink, facilitam a conexão com outros serviços em diferentes contas AWS e simplificam significativamente sua arquitetura VPCs de rede. Isso permite que os clientes queiram expor de forma privada um serviço/aplicativo residente em uma VPC (provedor de serviços) a VPCs outra (consumidor) de Região da AWS uma forma que somente o consumidor inicie conexões com a VPC VPCs do provedor de serviços. Um exemplo disso é a capacidade de seus aplicativos privados acessarem o provedor de serviços APIs.
Para usar AWS PrivateLink, crie um Network Load Balancer para seu aplicativo em sua VPC e crie uma configuração de serviço de VPC endpoint apontando para esse balanceador de carga. Em seguida, um consumidor de serviços cria um endpoint de interface para seu serviço. Isso cria uma interface de rede elástica (ENI) na sub-rede do consumidor com um endereço IP privado que serve como ponto de entrada para o tráfego destinado ao serviço. O consumidor e o serviço não precisam estar na mesma VPC. Se a VPC for diferente, o consumidor e o provedor de serviços VPCs podem ter intervalos de endereços IP sobrepostos. Além de criar a interface VPC endpoint para acessar serviços em outros VPCs, você pode criar endpoints VPC de interface para acessar de forma privada os [serviços compatíveis da AWS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) AWS PrivateLink, conforme mostrado na figura a seguir.
Com o Application Load Balancer (ALB) como alvo do NLB, agora você pode combinar os recursos avançados de roteamento do ALB com o. AWS PrivateLink Consulte o [Grupo de destino do tipo Application Load Balancer para Network Load Balancer para obter](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) arquiteturas de referência e configuração detalhada.
![\[Um diagrama que mostra a AWS PrivateLink conectividade com outros serviços VPCs e com os da AWS\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)
A escolha entre Transit Gateway, emparelhamento de VPC e depende da AWS PrivateLink conectividade.
+ **AWS PrivateLink**— Use AWS PrivateLink quando você tiver um cliente/servidor configurado para permitir que um ou mais consumidores acessem VPCs unidirecionalmente um serviço específico ou conjunto de instâncias na VPC do provedor de serviços ou em determinados serviços. AWS Somente os clientes com acesso na VPC do consumidor podem iniciar uma conexão com o serviço na VPC ou no serviço do provedor de serviços. AWS Essa também é uma boa opção quando o cliente e os servidores dos dois VPCs têm endereços IP sobrepostos porque os AWS PrivateLink usos ENIs na VPC do cliente garantem que não haja conflitos de IP com o provedor de serviços. Você pode acessar AWS PrivateLink endpoints por meio de emparelhamento de VPC, VPN, Transit Gateway, Cloud WAN e. AWS Direct Connect
+ **Emparelhamento de VPC e Transit Gateway** — Use o emparelhamento de VPC e o Transit Gateway quando quiser habilitar a conectividade IP de camada 3 entre eles. VPCs
Sua arquitetura conterá uma combinação dessas tecnologias para atender a diferentes casos de uso. Todos esses serviços podem ser combinados e operados entre si. Por exemplo, AWS PrivateLink lidar com conectividade cliente-servidor no estilo API, emparelhamento de VPC para lidar com requisitos de conectividade direta, onde grupos de posicionamento ainda podem ser desejados na região ou entre regiões, e o Transit Gateway para simplificar a conectividade VPCs em grande escala, bem como a consolidação de borda para conectividade híbrida.
# Compartilhamento da VPC
VPCs O compartilhamento é útil quando o isolamento da rede entre as equipes não precisa ser gerenciado estritamente pelo proprietário da VPC, mas os usuários e as permissões no nível da conta devem ser. Com a [VPC compartilhada, várias](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) contas da AWS criam seus recursos de aplicativos (como EC2 instâncias da Amazon) na Amazon compartilhada e gerenciada centralmente. VPCs Nesse modelo, a conta proprietária da VPC (proprietário) compartilha uma ou mais sub-redes com outras contas (participantes). Quando uma sub-rede é compartilhada, os participantes podem visualizar, criar, modificar e excluir os recursos de seus aplicativos nas sub-redes compartilhadas com eles. Os participantes não poderão visualizar, modificar ou excluir recursos que pertencerem a outros participantes ou proprietários da VPC. A segurança entre recursos compartilhados VPCs é gerenciada usando grupos de segurança, listas de controle de acesso à rede (NACLs) ou por meio de um firewall entre as sub-redes.
Benefícios do compartilhamento de VPC:
+ Design simplificado — sem complexidade em relação à conectividade entre VPCs
+ Menos gerenciado VPCs
+ Segregação de tarefas entre equipes de rede e proprietários de aplicativos
+ Melhor utilização IPv4 do endereço
+ Custos mais baixos — sem cobranças de transferência de dados entre instâncias pertencentes a contas diferentes na mesma zona de disponibilidade
**nota**
Quando você compartilha uma sub-rede com várias contas, seus participantes devem ter algum nível de cooperação, pois estão compartilhando espaço IP e recursos de rede. Se necessário, você pode optar por compartilhar uma sub-rede diferente para cada conta de participante. Uma sub-rede por participante permite que a ACL de rede forneça isolamento de rede, além dos grupos de segurança.
A maioria das arquiteturas de clientes conterá várias VPCs, muitas das quais serão compartilhadas com duas ou mais contas. O Transit Gateway e o VPC peering podem ser usados para conectar o compartilhado. VPCs Por exemplo, suponha que você tenha 10 aplicativos. Cada aplicativo exige sua própria conta da AWS. Os aplicativos podem ser categorizados em dois portfólios de aplicativos (aplicativos dentro do mesmo portfólio têm requisitos de rede semelhantes, aplicativo 1—5 em 'Marketing' e aplicativo 6—10 em 'Vendas').
Você pode ter uma VPC por portfólio de aplicativos (dois no VPCs total), e a VPC é compartilhada com as diferentes contas do proprietário do aplicativo dentro desse portfólio. Os proprietários de aplicativos implantam aplicativos em sua respectiva VPC compartilhada (nesse caso, nas diferentes sub-redes para uso de segmentação e isolamento de rotas de rede). NACLs Os dois compartilhados VPCs são conectados por meio do Transit Gateway. Com essa configuração, você pode deixar de conectar 10 VPCs para apenas dois, conforme mostrado na figura a seguir.
![\[Um diagrama que descreve um exemplo de configuração para VPC compartilhada\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)
**nota**
Os participantes do compartilhamento de VPC não podem criar todos os recursos da AWS em uma sub-rede compartilhada. Para obter mais informações, consulte a seção [Limitações](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) na documentação de compartilhamento de VPC.
Para obter mais informações sobre as principais considerações e as melhores práticas para o compartilhamento de VPC, consulte a postagem do blog [Compartilhamento de VPC: considerações principais](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/) e melhores práticas.
# Gateway NAT privado
As equipes geralmente trabalham de forma independente e podem criar uma nova VPC para um projeto, que pode ter blocos de roteamento entre domínios (CIDR) sobrepostos sem classes. Para integração, talvez eles queiram permitir a comunicação entre redes com sobreposição CIDRs, o que não é possível por meio de recursos como emparelhamento de VPC e Transit Gateway. Um gateway NAT privado pode ajudar nesse caso de uso. O gateway NAT privado usa um endereço IP privado exclusivo para realizar o NAT de origem para o endereço IP de origem sobreposto, e o ELB faz o NAT de destino para o endereço IP de destino sobreposto. Você pode rotear o tráfego do seu gateway NAT privado para outras redes VPCs ou redes locais usando o Transit Gateway ou um gateway privado virtual.
![\[Um diagrama que descreve um exemplo de configuração para um gateway NAT privado\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)
A figura anterior mostra duas sub-redes não roteáveis (sobrepostas`100.64.0.0/16`) nas VPC A e B. Para estabelecer uma conexão entre elas CIDRs, você pode adicionar sub-redes secundárias não sobrepostas/roteáveis (sub-redes roteáveis e) às VPC A e B, respectivamente CIDRs . `10.0.1.0/24` `10.0.2.0/24` O roteável CIDRs deve ser alocado pela equipe de gerenciamento de rede responsável pela alocação de IP. Um gateway NAT privado é adicionado à sub-rede roteável na VPC A com um endereço IP de. `10.0.1.125` O gateway NAT privado realiza a conversão do endereço de rede de origem em solicitações de instâncias na sub-rede não roteável da VPC A `100.64.0.10` () `10.0.1.125` como a ENI do gateway NAT privado. Agora, o tráfego pode ser direcionado para um endereço IP roteável atribuído ao Application Load Balancer (ALB) na VPC B `10.0.2.10` (), que tem como destino. `100.64.0.10` O tráfego é roteado pelo Transit Gateway. O tráfego de retorno é processado pelo gateway NAT privado de volta para a EC2 instância original da Amazon que está solicitando a conexão.
O gateway NAT privado também pode ser usado quando sua rede local restringe o acesso aos aprovados. IPs A conformidade exige que as redes locais de poucos clientes se comuniquem somente com redes privadas (sem IGW) somente por meio de um bloco contíguo limitado de propriedades aprovadas pelo IPs cliente. Em vez de alocar para cada instância um IP separado do bloco, você pode executar grandes cargas de trabalho AWS VPCs por trás de cada IP da lista de permissões usando um gateway NAT privado. Para obter detalhes, consulte a postagem do [blog Como resolver a exaustão de IP privado com a solução NAT privada](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/).
![\[Um diagrama que mostra como usar um gateway NAT privado para fornecer uma rede local aprovada IPs\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)
# AWS WAN em nuvem
O AWS Cloud WAN é uma nova forma de conectar redes que antes podíamos fazer com Transit Gateways, VPC Peering e túneis IPSEC VPN. Anteriormente, você configurava um ou mais VPCs, os conectava com um dos métodos anteriores e usava a VPN IPSEC ou Direct Connect se conectava a redes locais. Você teria suas construções de postura de rede e segurança definidas em um lugar e suas redes em outro. O Cloud WAN permite que você centralize todas essas construções em um único local. Por política, você pode segmentar suas redes para determinar quem pode falar com quem e isolar o tráfego de produção por meio desses segmentos das cargas de trabalho de desenvolvimento ou teste ou de suas redes locais.
![\[Um diagrama que descreve a conectividade da AWS Cloud WAN\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)
Gerencie sua rede global por meio da interface de usuário do AWS Network Manager APIs e. A rede global é o contêiner de nível raiz para todos os seus objetos de rede; a rede principal é a parte da sua rede global gerenciada pela AWS. Uma política de rede central (CNP) é um documento de política com versão única que define todos os aspectos da sua rede principal. Anexos são todas as conexões ou recursos que você deseja adicionar à sua rede principal. Uma borda de rede central (CNE) é um ponto de conexão local para anexos que estão em conformidade com a política. Os segmentos de rede são domínios de roteamento que, por padrão, permitem a comunicação somente dentro de um segmento.
Para usar o CloudWAN:
1. No AWS Network Manager, crie uma rede global e uma rede principal associada.
1. Crie um CNP que defina segmentos, intervalo de ASN Regiões da AWS e etiquetas a serem usadas para anexar aos segmentos.
1. Aplique a política de rede.
1. Compartilhe a rede principal com seus usuários, contas ou organizações usando o gerenciador de acesso a recursos.
1. Crie e marque anexos.
1. Atualize as rotas em seu anexo VPCs para incluir a rede principal.
A Cloud WAN foi projetada para simplificar o processo de conectar sua infraestrutura da AWS globalmente. Ele permite que você segmente o tráfego com uma política de permissões centralizada e use sua infraestrutura existente nas instalações da sua empresa. A Cloud WAN também conecta seus recursos VPCsWANs, SD- VPNs, Client VPNs, firewalls e data center para se conectar à Cloud WAN. Para obter mais informações, consulte [as postagens do blog AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/).
O AWS Cloud WAN permite uma rede unificada conectando ambientes locais e na nuvem. As organizações usam firewalls de próxima geração (NGFWs) e sistemas de prevenção de intrusões () para segurança. IPSs A postagem do blog sobre [padrões de migração e interoperabilidade da AWS Cloud WAN e do Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/) descreve padrões arquitetônicos para gerenciar e inspecionar centralmente o tráfego de rede de saída em uma rede WAN na nuvem, incluindo redes de região única e multirregional, e configura tabelas de rotas. Essas arquiteturas garantem que os dados e os aplicativos permaneçam seguros e, ao mesmo tempo, mantenham um ambiente de nuvem seguro.
Para obter mais informações sobre a WAN na nuvem, consulte a postagem do blog sobre a [arquitetura de inspeção de saída centralizada na AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/).
# Amazon VPC Lattice
O Amazon VPC Lattice é um serviço de rede de aplicativos totalmente gerenciado que é usado para conectar, monitorar e proteger serviços em várias contas e nuvens privadas virtuais. O VPC Lattice ajuda a interconectar serviços dentro de um limite lógico, para que você possa gerenciá-los e descobri-los com eficiência.
Os componentes do VPC Lattice consistem em:
+ **Serviço** - Essa é uma unidade de aplicativo executada em uma instância, um contêiner ou uma função Lambda e consiste em ouvintes, regras e grupos-alvo.
+ **Rede de serviços** - Esse é o limite lógico usado para implementar automaticamente a descoberta e a conectividade de serviços e aplicar políticas comuns de acesso e observabilidade a uma coleção de serviços.
+ Políticas de **autenticação — políticas** de recursos do IAM que podem ser associadas a uma rede de serviços ou serviços individuais para oferecer suporte à autenticação em nível de solicitação e à autorização específica do contexto.
+ **Diretório de serviços** — Uma visão centralizada dos serviços que você possui ou que foram compartilhados com você por meio do AWS Resource Access Manager.
Etapas de uso do VPC Lattice:
1. Crie a rede de serviços. A rede de serviços geralmente reside em uma conta de rede na qual o administrador da rede tem acesso total. A rede de serviços pode ser compartilhada entre várias contas dentro de uma organização. O compartilhamento pode ser realizado em serviços individuais ou em toda a conta de serviço.
1. VPCs Conecte-se à rede de serviços para habilitar a rede de aplicativos para cada VPC, para que diferentes serviços possam começar a consumir outros serviços registrados na rede. Os grupos de segurança são aplicados para controlar o tráfego.
1. Os desenvolvedores definem os serviços, que são preenchidos no diretório de serviços e registrados na rede de serviços. O VPC Lattice contém o catálogo de endereços de todos os serviços configurados. Os desenvolvedores também podem definir políticas de roteamento para usar implantações azul/verde. A segurança é gerenciada no nível da rede de serviço em que as políticas de autenticação e autorização são definidas e no nível do serviço em que as políticas de acesso com o IAM são implementadas.
![\[Um diagrama que descreve os fluxos de comunicação do VPC Lattice\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)
Mais detalhes podem ser encontrados no guia do usuário do [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html ).