Infrastructure OU – Network account - AWS Prescriptive Guidance

Infrastructure OU – Network account

The following diagram illustrates the AWS security services that are configured in the Network account.

        Security services for Network account

The Network account manages the gateway between your application and the broader internet. It is important to protect that two-way interface. The Network account isolates the networking services, configuration, and operation from the individual application workloads, security, and other infrastructure. This arrangement not only limits connectivity, permissions, and data flow, but also supports separation of duties and least privilege for the teams that need to operate in these accounts. By splitting network flow into separate inbound and outbound virtual private clouds (VPCs), you can protect sensitive infrastructure and traffic from undesired access. The inbound network is generally considered higher risk and deserves appropriate routing, monitoring, and potential issue mitigations. These infrastructure accounts will inherit permission guardrails from the Org Management account and the Infrastructure OU. Networking (and security) teams will manage the majority of the infrastructure here.

Network architecture

Although network design and specifics are beyond the scope of this document, we recommend these three options for network connectivity between the various accounts: VPC peering, AWS PrivateLink, and AWS Transit Gateway. Important considerations in choosing among these are operational norms, budgets, and specific bandwidth needs.

  • VPC peering – The simplest way to connect two VPCs is to use VPC peering. A connection enables full bidirectional connectivity between the VPCs. VPCs across accounts and AWS Regions can also be peered together. At scale, when you have tens to hundreds of VPCs, interconnecting them with peering results in a mesh of hundreds to thousands of peering connections, which can be challenging to manage and scale. VPC peering is best used when resources in one VPC must communicate with resources in another VPC, the environment of both VPCs is controlled and secured, and the number of VPCs to be connected is fewer than 10 (to allow for the individual management of each connection).

  • AWS PrivateLink – AWS PrivateLink provides private connectivity between VPCs, services, and application. You can create your own application in your VPC and configure it as an AWS PrivateLink-powered service (referred to as an endpoint service). Other AWS principals can create a connection from their VPC to your endpoint service by using an interface VPC endpoint or a Gateway Load Balancer endpoint, depending on the type of service. When you use AWS PrivateLink, service traffic doesn’t pass across a publicly routable network. Use AWS PrivateLink when you have a client-server setup where you want to give one or more consumer VPCs unidirectional access to a specific service or set of instances in the service provider VPC. This is also a good option when clients and servers in the two VPCs have overlapping IP addresses, because AWS PrivateLink uses elastic network interfaces within the client VPC so that there are no IP conflicts with the service provider.

  • AWS Transit Gateway – AWS Transit Gateway provides a hub-and-spoke design for connecting VPCs and on-premises networks as a fully managed service without requiring you to provision virtual appliances. AWS manages high availability and scalability. A transit gateway is a regional resource and can connect thousands of VPCs within the same AWS Region. You can attach all your hybrid connectivity (VPN and AWS Direct Connect connections) to a single transit gateway, thereby consolidating and controlling your AWS organization's entire routing configuration in one place. A transit gateway solves the complexity involved with creating and managing multiple VPC peering connections at scale. It is a good default for most network architectures, but specific needs around cost, bandwidth, and latency might make VPC peering a better fit for your needs.

Inbound (ingress) VPC

The inbound VPC is intended to accept, inspect, and route network connections initiated outside the application. Depending on the particulars of the application, we expect to see some network address translation (NAT) in this VPC. Flow logs from this VPC are captured and stored in the Log Archive account.

Outbound (egress) VPC

The outbound VPC is intended to handle network connections initiated from within the application. Depending on the particulars of the application, we expect to see traffic NAT, AWS service-specific VPC endpoints, and hosting of external API endpoints in this VPC. Flow logs from this VPC are captured and stored in the Log Archive account.

Inspection VPC

A dedicated inspection VPC provides a simplified and central approach for managing inspections between VPCs (in the same or in different AWS Regions), the internet, and on-premises networks. For the AWS SRA, ensure that all traffic between VPCs passes through the inspection VPC, and avoid using the inspection VPC for any other workload.

AWS Network Firewall

AWS Network Firewall is a highly available, managed network firewall service for your VPC. It enables you to easily deploy and manage stateful inspection, intrusion prevention and detection, and web filtering to protect your virtual networks on AWS. For more information about configuring Network Firewall, see the AWS Network Firewall – New Managed Firewall Service in VPC blog post.

You use a firewall on a per-Availability Zone basis in your VPC. For each Availability Zone, you choose a subnet to host the firewall endpoint that filters your traffic. The firewall endpoint in an Availability Zone can protect all the subnets inside the zone except for the subnet where it’s located. Depending on the use case and deployment model, the firewall subnet could be either public or private. The firewall is completely transparent to the traffic flow and does not perform network address translation (NAT). It preserves the source and destination address. In this reference architecture, the firewall endpoints are hosted in an inspection VPC. All traffic from the inbound VPC and to the outbound VPC is routed through this firewall subnet for inspection.

Network Firewall makes firewall activity visible in real time through Amazon CloudWatch metrics, and offers increased visibility of network traffic by sending logs to Amazon Simple Storage Service (Amazon S3), CloudWatch, and Amazon Kinesis Data Firehose. Network Firewall is interoperable with your existing security approach, including technologies from AWS Partners. You can also import existing Suricata rulesets, which may have been written internally or sourced externally from third-party vendors or open-source platforms.

Design considerations
  • AWS Firewall Manager supports AWS Network Firewall, and makes it easy to centrally configure and deploy Network Firewall rules across your organization. (For details, see AWS Network Firewall policies in the AWS documentation.) When you configure Firewall Manager, it automatically creates a Network Firewall firewall with sets of rules in the accounts and VPCs that you specify. It also deploys an endpoint in a dedicated subnet for every Availability Zone that contains public subnets. At the same time, any changes to the centrally configured set of rules are automatically updated downstream on the deployed Network Firewall firewalls.

  • There are multiple deployment models available with Network Firewall. The right model depends on the use case and requirements. Examples include the following:

    • A distributed deployment model where Network Firewall is deployed into individual VPCs.

    • A centralized deployment model, where Network Firewall is deployed into a centralized VPC for east-west (VPC-to-VPC) and/or north-south (internet egress and ingress, on-premises) traffic.

    • A combined deployment model where Network Firewall is deployed into a centralized VPC for east-west and a subset of north-south traffic.

  • As a best practice, do not use the Network Firewall subnet to deploy any other services. This is because Network Firewall cannot inspect traffic from sources or destinations within the firewall subnet.

AWS Certificate Manager (ACM)

ACM handles the complexity of creating, storing, and renewing SSL/TLS X.509 certificates and keys that protect your applications. In the inbound VPC, ACM-provisioned public certificates are deployed through Amazon Route 53 (by enabling DNS ownership validation by using CNAME). For additional uses of ACM, see the section on the Workloads OU later in this document.

Design consideration

For externally facing certificates, ACM must reside in the same account as the resources for which it provisions certificates. Certificates cannot be shared across accounts.


AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, or an AWS AppSync GraphQL API. AWS WAF also lets you control access to your content. Based on conditions that you specify, such as the IP addresses that requests originate from, or the values of query strings, the fronted service responds to requests either with the requested content or with an HTTP status code 403 (Forbidden) status code. In this architecture, AWS WAF protects CloudFront.

Design considerations
  • CloudFront provides features that enhance the AWS WAF functionality and make the two services work better together.

  • You can use AWS WAF, AWS Firewall Manager, and AWS Shield together to create a comprehensive security solution. It all starts with AWS WAF. You can automate and then simplify AWS WAF management using Firewall Manager. Shield Advanced provides additional features on top of AWS WAF, such as dedicated support from the distributed denial of service (DDoS) Response Team (DRT) and advanced reporting. If you want granular control over the protection that is added to your resources, AWS WAF alone is the right choice. If you want to use AWS WAF across accounts, accelerate your AWS WAF configuration, or automate protection of new resources, use Firewall Manager with AWS WAF. Finally, if you own high visibility websites or are otherwise prone to frequent DDoS attacks, you should consider purchasing the additional features that Shield Advanced provides.

Amazon CloudFront

Amazon CloudFront is a highly secure content delivery network (CDN) that provides both network-level and application-level protection. You can deliver your content, APIs, or applications by using SSL/TLS certificates, and advanced SSL features are enabled automatically. You can use AWS Certificate Manager (ACM) to easily create a custom SSL certificate and deploy content to your CloudFront distribution for free. Additionally, you can restrict access to your content by using a number of capabilities:

  • By using signed URLs and signed cookies, you can support token authentication to restrict access to only authenticated viewers.

  • Through the geo restriction capability, you can prevent users in specific geographic locations from accessing content that you're distributing through CloudFront.

  • You can use the origin access identity (OAI) feature to restrict access to an S3 bucket to be accessible only from CloudFront.

Design considerations
  • CloudFront, AWS Shield, AWS WAF, and Amazon Route 53 work seamlessly together to create a flexible, layered security perimeter against multiple types of attacks, including network and application-layer DDoS attacks. CloudFront provides features that enhance the AWS WAF functionality and make the two work better together. For more information, see How AWS WAF works with Amazon CloudFront features in the AWS documentation.

  • When you deliver web content through a CDN such as CloudFront, a best practice is to prevent viewer requests from bypassing the CDN and accessing your origin content directly. For more information, see the blog post How to enhance Amazon CloudFront origin security with AWS WAF and AWS Secrets Manager.

AWS Shield

AWS Shield is a managed DDoS protection service that safeguards applications that run on AWS. Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there is no need to engage AWS Support to benefit from DDoS protection. In the AWS SRA, Shield Advanced is configured to protect Route 53 and CloudFront.

Design consideration

There are two tiers of Shield: Shield Standard and Shield Advanced. All AWS customers benefit from the automatic protections of Shield Standard at no additional charge. Shield Standard provides protection against the most common and frequently occurring infrastructure (layer 3 and 4) attacks. Shield Standard uses deterministic packet filtering and priority-based traffic shaping to automatically mitigate basic network layer attacks. Shield Advanced provides more sophisticated automatic mitigations for attacks that target your applications running on protected Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB), CloudFront, AWS Global Accelerator, and Route 53 resources. Shield Advanced records metrics that you can monitor in CloudWatch. (For more information, see AWS Shield Advanced metrics and alarms in the AWS documentation.) If you own high-visibility websites or are otherwise prone to frequent DDoS attacks, you should consider the additional features that Shield Advanced provides.

Security service guardrails

In the AWS SRA, AWS Security Hub, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer, AWS CloudTrail organization trails, and Amazon EventBridge are deployed with appropriate delegated administration to the Security Tooling account. This enables a consistent set of guardrails and provides centralized monitoring, management, and governance across your AWS organization.