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 rede para uma arquitetura de várias contas
## Conectando VPCs
Muitas empresas usam o peering de VPC na Amazon Virtual Private Cloud (Amazon VPC) para conectar desenvolvimento e produção. VPCs Usando uma conexão de emparelhamento VPC, você pode rotear o tráfego entre duas VPCs usando endereçamento IP privado. O conectado VPCs pode estar em diferentes Contas da AWS e em diferentes Regiões da AWS. Para obter mais informações, consulte [O que é emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) (documentação da Amazon VPC). À medida que as empresas crescem e o número delas VPCs aumenta, manter conexões emparelhadas entre todas elas VPCs pode se tornar uma carga de manutenção. Você também pode ser limitado pelo número máximo de conexões de emparelhamento de VPC por VPC. Para obter mais informações, consulte [Cota de conexões de emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) (documentação da Amazon VPC).
Se você tiver vários ambientes de desenvolvimento, teste e preparação que hospedam dados que não sejam de produção em vários Contas da AWS, talvez você queira fornecer conectividade de rede entre todos eles, VPCs mas proibir qualquer acesso aos ambientes de produção. Você pode usar [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)para conectar várias VPCs em várias contas. Você pode separar as tabelas de rotas para evitar que o desenvolvimento VPCs se comunique com a produção VPCs por meio do gateway de trânsito, que atua como roteador centralizado. Para obter mais informações, consulte [Roteador centralizado](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html) (documentação do Transit Gateway).
O Transit Gateway também oferece suporte ao emparelhamento com outros gateways de trânsito, incluindo aqueles em Contas da AWS ou Regiões da AWS diferentes. Como o Transit Gateway é um serviço totalmente gerenciado e altamente disponível, é necessário provisionar somente um gateway de trânsito para cada região.
Para obter mais informações e arquiteturas de rede detalhadas, consulte [Construindo uma infraestrutura de rede multi-VPC escalável e segura ( AWS Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)).AWS
## Conectar aplicações
Se precisar estabelecer comunicação entre aplicativos diferentes Contas da AWS no mesmo ambiente (como produção), você pode usar uma das seguintes opções:
+ O [emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) ou o [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) poderão fornecer conectividade em nível de rede se você desejar abrir um amplo acesso a vários endereços IP e portas.
+ O [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) cria endpoints em uma sub-rede privada da VPC, e esses endpoints são registrados como entradas de DNS no [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html). Ao usar o DNS, as aplicações podem resolver os endpoints e se conectar aos serviços registrados, sem exigir gateways NAT ou gateways da Internet na VPC.
+ [O Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) associa serviços, como aplicativos, em várias contas VPCs e os coleta em uma rede de serviços. Os clientes VPCs associados à rede de serviços podem enviar solicitações para todos os outros serviços associados à rede de serviços, independentemente de estarem na mesma conta. O VPC Lattice se integra com AWS Resource Access Manager (AWS RAM) para que você possa compartilhar recursos com outras contas ou por meio de. AWS Organizations Uma VPC pode ser associada a apenas uma rede de serviços. Essa solução não requer o uso de emparelhamento de VPC ou AWS Transit Gateway para se comunicar entre contas.
## Práticas recomendadas para conectividade de rede
+ Crie um Conta da AWS que você use para a rede centralizada. Nomeie essa conta como **network-prod** e use-a para o AWS Transit Gateway Amazon [VPC IP](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) Address Manager (IPAM). Adicione esta conta à unidade organizacional **Infrastructure\$1Prod**.
+ Use o [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) para compartilhar o gateway de trânsito, as redes de serviços VPC Lattice e os grupos do IPAM com o resto da organização. Isso permite que qualquer Conta da AWS pessoa da sua organização interaja com esses serviços.
+ Ao usar pools IPAM para gerenciar IPv4 e IPv6 endereçar alocações de forma centralizada, você pode permitir que seus usuários finais se autoprovisionem usando. VPCs [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) Isso ajuda você a dimensionar VPCs e evitar a sobreposição de espaços de endereço IP de forma adequada.
+ Use uma abordagem de saída centralizada para o tráfego vinculado à Internet e use uma abordagem de entrada descentralizada para o tráfego que entra em seu ambiente proveniente da Internet. Para obter mais informações, consulte [Saída centralizada](centralized-egress.md) e [Entrada descentralizada](decentralized-ingress.md).
# Saída centralizada
A *saída centralizada* é o princípio de usar um ponto de entrada único e comum para todo o tráfego de rede destinado à Internet. Você pode configurar a inspeção nesse ponto de entrada e permitir o tráfego somente para domínios específicos ou somente por meio de portas ou protocolos especificados. A centralização da saída também pode ajudá-lo a reduzir custos, eliminando a necessidade de implantar gateways NAT em cada um deles para acessar VPCs a Internet. Isso é benéfico do ponto de vista da segurança porque limita a exposição a recursos maliciosos acessíveis externamente, como a infraestrutura de comando e controle (C&C) de malware. Para obter mais informações e opções de arquitetura para saída centralizada, consulte Saída [centralizada para a Internet (Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html)).AWS
Você pode usar o [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html), que é um serviço stateful gerenciado de firewall de rede, detecção de invasões e prevenção, como um ponto de inspeção central para o tráfego de saída. Configure esse firewall em uma VPC dedicada para tráfego de saída. O Network Firewall oferece suporte a regras stateful que podem ser usadas para limitar o acesso à Internet a domínios específicos. Para obter mais informações, consulte [Lista de domínios](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering) (documentação do Network Firewall).
Também é possível usar o [Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) para limitar o tráfego de saída a nomes de domínio específicos, principalmente para evitar a exfiltração não autorizada dos seus dados. Nas regras do DNS Firewall, é possível aplicar [listas de domínios](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (documentação do Route 53) que permitem ou negam acesso a domínios especificados. Você pode usar listas de domínios AWS gerenciados, que contêm nomes de domínio associados a atividades maliciosas ou outras ameaças em potencial, ou você pode criar listas de domínios personalizadas. Você cria grupos de regras do DNS Firewall e depois os aplica ao seu VPCs. As solicitações de DNS de saída são roteadas por meio de um resolvedor na VPC para resolução de nomes de domínio, e o DNS Firewall filtra as solicitações com base nos grupos de regras aplicados à VPC. As solicitações recursivas de DNS que vão para o resolvedor não fluem pelo gateway de trânsito e pelo caminho do Network Firewall. O Route 53 Resolver e o DNS Firewall devem ser considerados um caminho de saída separado para fora da VPC.
A imagem a seguir mostra um exemplo de arquitetura para saída centralizada. Antes do início da comunicação de rede, as solicitações de DNS são enviadas para o resolvedor do Route 53, onde o DNS Firewall permite ou nega a resolução do endereço IP usado para comunicação. O tráfego destinado à Internet é roteado para um gateway de trânsito em uma conta de rede centralizada. O gateway de trânsito encaminha o tráfego para o Network Firewall para inspeção. Se a política de firewall permitir o tráfego de saída, o tráfego será roteado por um gateway NAT, por um gateway da Internet e para a Internet. Você pode usar AWS Firewall Manager para gerenciar centralmente os grupos de regras do Firewall DNS e as políticas do Firewall de Rede em toda a sua infraestrutura de várias contas.
![\[Roteamento de tráfego de outras contas por meio da conta de rede e para a Internet.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## Práticas recomendadas para proteger o tráfego de saída
+ Comece no [modo somente de log](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (documentação do Route 53). Mude para o modo de bloqueio depois de validar que o tráfego legítimo não é afetado.
+ Bloqueie o tráfego de DNS que vai para a Internet usando [AWS Firewall Manager políticas para listas de controle de acesso à rede](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) ou usando AWS Network Firewall. Todas as consultas de DNS devem ser roteadas por meio de um Resolvedor do Route 53, onde você pode monitorá-las com a Amazon GuardDuty (se habilitado) e filtrá-las com o [Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) (se habilitado). Para obter mais informações, consulte [Resolvendo consultas de DNS entre VPCs e sua rede](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) (documentação do Route 53).
+ Use as [Listas de domínios gerenciadas pela AWS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) (documentação do Route 53) no DNS Firewall e no Network Firewall.
+ Considere bloquear domínios de alto nível não utilizados e de alto risco, como .info, .top, .xyz ou alguns domínios com código de país.
+ Considere bloquear portas de alto risco não utilizadas, como as portas 1389, 4444, 3333, 445, 135, 139 ou 53.
+ Como ponto de partida, você pode usar uma lista de negação que inclui as regras AWS gerenciadas. Em seguida, você pode trabalhar ao longo do tempo para implementar um modelo de lista de permissões. Por exemplo, em vez de incluir somente uma lista restrita de nomes de domínio totalmente qualificados na lista de permissões, comece usando alguns curingas, como *\$1.exemplo.com*. Você pode até mesmo permitir apenas os domínios de nível superior que você espera e bloquear todos os outros. Então, com o tempo, reduza-os também.
+ Use os [perfis do Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (documentação do Route 53) para aplicar configurações do Route 53 relacionadas ao DNS em várias VPCs e diferentes. Contas da AWS
+ Defina um processo para lidar com exceções a essas melhores práticas.
# Entrada descentralizada
*Entrada descentralizada* é o princípio de definir em nível de conta individual como o tráfego da Internet chega às workloads dessa conta. Em arquiteturas de várias contas, um dos benefícios da entrada descentralizada é que cada conta pode usar o serviço ou recurso de entrada mais adequado para suas workloads, como Application Load Balancer, Amazon API Gateway ou Network Load Balancer.
Embora a entrada descentralizada signifique que é necessário gerenciar cada conta individualmente, é possível administrar e manter centralmente suas configurações por meio do [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html). O Firewall Manager oferece suporte a proteções como o [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) e [Grupos de segurança da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). Você pode se AWS WAF associar a um Application Load Balancer CloudFront, Amazon, API Gateway ou. AWS AppSync Se estiver usando uma VPC de saída e um gateway de trânsito, conforme descrito em [Saída centralizada](centralized-egress.md), cada VPC spoke contém sub-redes públicas e privadas. No entanto, não há necessidade de implantar gateways NAT porque o tráfego passa pela VPC de saída na conta de rede.
A imagem a seguir mostra um exemplo de um indivíduo Conta da AWS que tem uma única VPC que contém uma carga de trabalho acessível pela Internet. O tráfego da Internet acessa a VPC por meio de um gateway da Internet e chega até os serviços de balanceamento de carga e segurança hospedados em uma sub-rede pública. (Uma *sub-rede pública* contém uma rota para um gateway da Internet.) Implante balanceadores de carga em sub-redes públicas e anexe listas de controle de AWS WAF acesso (ACLs) para ajudar na proteção contra tráfego malicioso, como scripts entre sites. Implante workloads que hospedam aplicações em *sub-redes privadas* sem acesso direto à Internet.
![\[Tráfego da Internet acessando uma VPC por meio de um gateway da Internet e AWS WAF balanceadores de carga.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
Se você tem muitos VPCs em sua organização, talvez queira compartilhar algo em comum Serviços da AWS criando endpoints VPC de interface ou zonas hospedadas privadas em um ambiente dedicado e compartilhado. Conta da AWS Para obter mais informações, consulte [Acessar e AWS service (Serviço da AWS) usar uma interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink documentação) e [Trabalhar com zonas hospedadas privadas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (documentação do Route 53).
A imagem a seguir mostra um exemplo de um Conta da AWS que hospeda recursos que podem ser compartilhados em toda a organização. Os endpoints da VPC podem ser compartilhados em várias contas quando são criados em uma VPC dedicada. Ao criar um endpoint da VPC, você pode opcionalmente fazer com que a AWS gerencie as entradas de DNS para o endpoint. Para compartilhar um endpoint, desmarque essa opção e crie as entradas de DNS em uma zona hospedada privada (PHZ) separada do Route 53. Em seguida, você pode associar o PHZ a todos os da VPCs sua organização para uma resolução centralizada de DNS dos VPC endpoints. Você também precisa garantir que as tabelas de rotas do gateway de trânsito incluam rotas da VPC compartilhada para a outra. VPCs Para obter mais informações, consulte [Acesso centralizado aos endpoints AWS VPC da interface](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) (Whitepaper).
![\[Uma conta compartilhada que hospeda endpoints de serviço e recursos para compartilhar com outras contas de membros.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
Um compartilhamento também Conta da AWS é um bom lugar para hospedar AWS Service Catalog portfólios. Um *portfólio* é uma coleção de serviços de TI que você deseja disponibilizar para implantação AWS, e o portfólio contém informações de configuração desses serviços. Você pode criar os portfólios na conta compartilhada, compartilhá-los com a organização e, em seguida, cada conta membro importa o portfólio para sua própria instância regional do Service Catalog. Para obter mais informações, consulte [Compartilhar com o AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) (documentação do Service Catalog).
Da mesma forma, com o Amazon VPC Lattice, você pode usar a conta compartilhada para gerenciar centralmente seu ambiente e modelos de serviço como entidades e, em seguida, configurar conexões de conta com as contas dos membros da organização. Para obter mais informações, consulte [Compartilhar suas entidades do VPC Lattice (documentação do VPC Lattice)](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html).