# Network connectivity for a multi-account architecture
## Connecting VPCs
Many companies use VPC peering in Amazon Virtual Private Cloud (Amazon VPC) to connect development and production VPCs. Using a VPC peering connection, you can route traffic between two VPCs by using private IP addressing. The connected VPCs can be in different AWS accounts and in different AWS Regions. For more information, see [What is VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) (Amazon VPC documentation). As companies grow and the number of VPCs increases, maintaining peering connections between all of the VPCs can become a maintenance burden. You might also be limited by the maximum number of VPC peering connections per VPC. For more information, see the [VPC peering connection quota](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) (Amazon VPC documentation).
If you have multiple development, test, and staging environments that host non-production data across multiple AWS accounts, you might want to provide network connectivity between all of those VPCs but disallow any access to production environments. You can use [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) to connect multiple VPCs across multiple accounts. You can separate the route tables to prevent development VPCs from communicating to production VPCs through the transit gateway, which acts as centralized router. For more information, see [Centralized router](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html) (Transit Gateway documentation).
Transit Gateway also supports peering with other transit gateways, including those in different AWS accounts or AWS Regions. Because Transit Gateway is a fully managed, highly available service, you need to provision only one transit gateway for each Region.
For more information and detailed network architectures, see [Building a Scalable and Secure Multi-VPC AWS Network Infrastructure](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) (AWS Whitepaper).
## Connecting applications
If you need to establish communication between applications in different AWS accounts in the same environment (such as production), you can use one of the following options:
+ [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) or [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) can provide connectivity at the network level if you want to open broad access to multiple IP addresses and ports.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) creates endpoints in a private subnet of the VPC, and these endpoints are registered as DNS entries in [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html). By using DNS, applications can resolve the endpoints and connect to the registered services, without requiring NAT gateways or internet gateways in the VPC.
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) associates services, such as applications, across multiple accounts and VPCs and collects them into a service network. Clients in VPCs associated with the service network can send requests to all other services that are associated with the service network, regardless of whether they’re in the same account. VPC Lattice integrates with AWS Resource Access Manager (AWS RAM) so that you can share resources with other accounts or through AWS Organizations. You can associate a VPC with only one service network. This solution doesn’t require use of VPC peering or AWS Transit Gateway to communicate across accounts.
## Best practices for network connectivity
+ Create an AWS account that you use for the centralized networking. Name this account **network-prod**, and use it for AWS Transit Gateway and [Amazon VPC IP Address Manager](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) (IPAM). Add this account to the **Infrastructure\$1Prod** organizational unit.
+ Use [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) to share the transit gateway, VPC Lattice service networks, and IPAM pools with the rest of the organization. This allows any AWS account within your organization to interact with these services.
+ By using IPAM pools to centrally manage IPv4 and IPv6 address allocations, you can allow your end-users to self-provision VPCs by using [AWS Service Catalog](https://aws.amazon.com/servicecatalog/). This helps you appropriately size VPCs and prevent overlapping IP address spaces.
+ Use a centralized egress approach for traffic bound to the internet, and use a decentralized ingress approach for traffic coming into your environment from the internet. For more information, see [Centralized egress](centralized-egress.md) and [Decentralized ingress](decentralized-ingress.md).
# Centralized egress
*Centralized egress* is the principle of using a single, common entry point for all network traffic that is destined to the internet. You can set up inspection at this entry point, and you can allow traffic only to specified domains or only through specified ports or protocols. Centralizing egress also can help you reduce costs by eliminating the need to deploy NAT gateways in each of your VPCs in order to reach the internet. This is beneficial from a security perspective because it limits exposure to externally accessible malicious resources, such as malware command and control (C&C) infrastructure. For more information and architecture options for centralized egress, see [Centralized egress to internet](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html) (AWS Whitepaper).
You can use [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html), which is a stateful, managed, network firewall and intrusion detection and prevention service, as a central inspection point for egress traffic. You set up this firewall in a dedicated VPC for egress traffic. Network Firewall supports stateful rules that you can use to limit internet access to specific domains. For more information, see [Domain filtering](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering) (Network Firewall documentation).
You can also use the [Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) to limit egress traffic to specific domain names, primarily to prevent unauthorized exfiltration of your data. In DNS Firewall rules, you can apply [domain lists](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (Route 53 documentation), which allow or deny access to specified domains. You can use AWS managed domain lists, which contain domain names that are associated with malicious activity or other potential threats, or you can create custom domain lists. You create DNS Firewall rule groups and then apply them to your VPCs. Outbound DNS requests route through a Resolver in the VPC for domain name resolution, and DNS Firewall filters the requests based on the rule groups applied to the VPC. Recursive DNS requests going to the Resolver don’t flow through the transit gateway and Network Firewall path. Route 53 Resolver and DNS Firewall should be considered to be a separate egress path out of the VPC.
The following image shows a sample architecture for centralized egress. Before network communication begins, DNS requests are sent to the Route 53 Resolver, where the DNS firewall allows or denies resolution of the IP address used for communication. Traffic destined to the internet is routed to a transit gateway in a centralized networking account. The transit gateway forwards the traffic to Network Firewall for inspection. If the firewall policy permits the egress traffic, the traffic routes through an NAT gateway, through an internet gateway, and to the internet. You can use AWS Firewall Manager to centrally manage DNS Firewall rule groups and Network Firewall policies across your multi-account infrastructure.
![\[Traffic routing from other accounts through the network account and to the internet.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## Best practices for securing egress traffic
+ Start in [logging-only mode](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (Route 53 documentation). Change to block mode after you have validated that legitimate traffic isn’t affected.
+ Block DNS traffic going to the internet by using [AWS Firewall Manager policies for network access control lists](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) or by using AWS Network Firewall. All DNS queries should route through a Route 53 Resolver, where you can monitor them with Amazon GuardDuty (if enabled) and filter them with [Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) (if enabled). For more information, see [Resolving DNS queries between VPCs and your network](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) (Route 53 documentation).
+ Use the [AWS Managed Domain Lists](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) (Route 53 documentation) in DNS Firewall and Network Firewall.
+ Consider blocking high-risk, unused top-level domains, such as .info, .top, .xyz, or some country code domains.
+ Consider blocking high-risk, unused ports, such as ports 1389, 4444, 3333, 445, 135, 139, or 53.
+ As a starting point, you can use a deny list that includes the AWS managed rules. You can then work over time toward implementing an allow-list model. For example, instead of including only a strict list of fully qualified domain names in the allow list, begin by using some wildcards, such as *\$1.example.com*. You can even allow only the top-level domains you expect and block all others. Then, over time, narrow those down too.
+ Use [Route 53 Profiles](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (Route 53 documentation) to apply DNS-related Route 53 configurations across many VPCs and in different AWS accounts.
+ Define a process for handling exceptions to these best practices.
# Decentralized ingress
*Decentralized ingress* is the principle of defining, at an individual account-level, how traffic from the internet reaches the workloads in that account. In multi-account architectures, one of the benefits of decentralized ingress is that each account can use the most appropriate ingress service or resource for its workloads, such as an Application Load Balancer, Amazon API Gateway, or Network Load Balancer.
Although decentralized ingress means that you have to manage each account individually, you can centrally administer and maintain your configurations through [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html). Firewall Manager supports protections such as [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) and [Amazon VPC security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). You can associate AWS WAF to an Application Load Balancer, Amazon CloudFront, API Gateway, or AWS AppSync. If you are using an egress VPC and transit gateway, as described in [Centralized egress](centralized-egress.md), each spoke VPC contains public and private subnets. However, there is no need to deploy NAT gateways because traffic routes through the egress VPC in the networking account.
The following image shows an example of an individual AWS account that has a single VPC that contains an internet-accessible workload. Traffic from the internet accesses the VPC through an internet gateway and reaches load balancing and security services hosted in a public subnet. (A *public subnet* contains a default route to an internet gateway). Deploy load balancers into public subnets, and attach AWS WAF access control lists (ACLs) to help protect against malicious traffic, such as cross-site scripting. Deploy workloads that host applications into *private subnets*, which don't have direct access to and from the internet.
![\[Traffic from the internet accessing a VPC through an internet gateway, AWS WAF, and load balancers.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
If you have a lot of VPCs in your organization, you might want to share common AWS services by creating interface VPC endpoints or private hosted zones in a dedicated and shared AWS account. For more information, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink documentation) and [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (Route 53 documentation).
The following image shows an example of an AWS account that hosts resources that can be shared across the organization. VPC endpoints can be shared across multiple accounts by creating them in a dedicated VPC. When you create a VPC endpoint, you can optionally have AWS manage the DNS entries for the endpoint. To share an endpoint, clear this option, and create the DNS entries in a separate Route 53 private hosted zone (PHZ). You can then associate the PHZ to all of the VPCs in your organization for centralized DNS resolution of the VPC endpoints. You also need to ensure that the transit gateway route tables include routes for the shared VPC to the other VPCs. For more information, see [Centralized access to interface VPC endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) (AWS Whitepaper).
![\[A shared account that hosts service endpoints and resources for sharing with other member accounts.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
A shared AWS account is also a good place to host AWS Service Catalog portfolios. A *portfolio* is a collection of IT services that you want to make available for deployment on AWS, and the portfolio contains configuration information for those services. You can create the portfolios in the shared account, share them to the organization, and then each member account imports the portfolio into its own regional Service Catalog instance. For more information, see [Sharing with AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) (Service Catalog documentation).
Similarly, with Amazon VPC Lattice, you can use the shared account to centrally manage your environment and service templates as entities and then set up account connections with the organization member accounts. For more information, see [Share your VPC Lattice entities](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html) (VPC Lattice documentation).