DEV Community

Cover image for How to Implement AWS Network Firewall in a Multi-Account Architecture Using Transit Gateway
Cristhian Becerra
Cristhian Becerra

Posted on

How to Implement AWS Network Firewall in a Multi-Account Architecture Using Transit Gateway

#english #aws #networking #cybersecurity

This article will guide you through the implementation of AWS Network Firewall in a multi-account, highly available architecture (spanning 3 Availability Zones) in conjunction with a Transit Gateway to connect VPCs across different accounts within an AWS Organizations structure. The architecture follows a Hub & Spoke pattern, where the Hub Account is the Networking account, and the Spoke accounts include Development, QA, Production, and DevOps.

In a multi-account environment, AWS Network Firewall plays a key role in providing centralized network protection, enabling consistent security controls and traffic inspection across all accounts. This implementation adopts a centralized ingress, centralized egress, and centralized inspection model, ensuring that inbound, outbound, and inter-VPC traffic is securely routed through a single inspection layer managed by the Networking account.

AWS Organization Accounts

Implementation Steps

The following sections provide a step-by-step walkthrough of the network setup process, showing how each component, including the Transit Gateway, shared VPCs, workload VPCs, and AWS Network Firewall, integrates to create a secure and scalable foundation for inter-account connectivity and inspection.

Set Up the Transit Gateway

  1. Create a Transit Gateway.

  2. Create two transit gateway route tables:

    • tgw-default-association-rtb
    • tgw-default-propagation-rtb

  3. Modify the Transit Gateway and assign:

    • tgw-default-association-rtb as the Default Association Route Table
    • tgw-default-propagation-rtb as the Default Propagation Route Table

  4. In AWS RAM, create a Resource Share with:

    • The newly created Transit Gateway as the Shared resource
    • The Spoke accounts as the Shared principals

  5. (Optional) Create a TGW Flow Log for the Transit Gateway to monitor and log the traffic flowing through it.

Transit Gateway

Notes for Subnet Creation and Availability Zone Selection:

  • Subnet Creation: When creating a VPC that will have connectivity with the Transit Gateway (TGW), it is recommended to create a /28 subnet exclusively to host the Elastic Network Interfaces (ENIs) deployed by TGW. This follows best practices for efficient resource management.

  • AZ Selection: Choose the same Availability Zone (AZ) ID, rather than the AZ name, to avoid charges for inter-zone traffic. For example, in this case, we are using use1-az1, use1-az2, use1-az4. It's important to note that us-east-1a and us-east-1b are unique aliases for each AWS account. To ensure that you deploy your resources in the same AZ, use AZ IDs instead of aliases.

  • Network Firewall Support: AWS Network Firewall is not supported in us1-az3, which is why we chose to use use1-az4 instead.

  • Subnet Identification: It is recommended to add the AZ ID in the name tag of the subnet and associated route table for easy identification and management.

Build the Ingress VPC

  1. Create a VPC (e.g., named ingress VPC, CIDR 10.20.0.0/20) with:

    • 3 public subnets (e.g., /22)
    • 3 private subnets for TGW connectivity (/28)
    • 1 Internet Gateway

  2. Create a Transit Gateway attachment between the Transit Gateway and the Ingress VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.

  3. Configure the TGW Connectivity Subnet Route Table (this route table will only have a local route):

    • ingress-vpc-tgw-connectivity-rtb

      Destination Target Description
      10.20.0.0/20 local Ingress VPC

  4. Configure the Public Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Internet Gateway and routes to the CIDRs of the Spoke VPCs to go through the TGW attachment):

    • ingress-vpc-public-rtb

      Destination Target Description
      10.20.0.0/20 local Ingress VPC
      10.21.0.0/16 tgw Development VPC
      10.22.0.0/16 tgw QA VPC
      10.23.0.0/16 tgw Production VPC
      10.24.0.0/16 tgw DevOps VPC
      0.0.0.0/0 igw Internet access

  5. Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Ingress VPC.

Ingress VPC

Build the Inspection VPC

  1. Create a VPC (e.g., named inspection VPC, CIDR 10.20.16.0/20) with:

    • 3 private subnets for Network Firewall (e.g., /22)
    • 3 private subnets for TGW connectivity (/28)

  2. Create a Transit Gateway attachment between the Transit Gateway and the Inspection VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets. Enable Appliance Mode Support.

    • Note: Enabling Appliance Mode on the Transit Gateway attachment ensures that all traffic from a session flows through the same firewall in the same Availability Zone, preventing inter-AZ traffic from being inspected by the firewall. This setting is important to maintain consistent traffic inspection and improve performance in multi-AZ architectures.

  3. Manually edit the Transit Gateway Route Tables:

    • Remove the propagation of the Inspection VPC attachment in the TGW Default Propagation Route Table.
    • Remove the association of the Inspection VPC attachment in the TGW Default Association Route Table.
    • Associate the TGW Default Propagation Route Table with the Inspection VPC Attachment.
    • In the TGW Default Association Route Table, create a static route to 0.0.0.0/0 towards the Inspection VPC Attachment.

  4. In the AWS Network Firewall console:

    • Choose Create firewall.
    • In Describe firewall: Add a name and (optionally) a description.
    • In Attachment Type: Choose “VPC” and select the Inspection VPC.
    • In Firewall subnets: Select the 3 private subnets (not the connectivity subnets).
    • In Associate Firewall Policy: Choose “Create and associate an empty firewall policy” and specify a new firewall policy name.
    • Create the firewall; this will take a few minutes.

  5. Configure the TGW Connectivity Subnet Route Tables (one per AZ). In each route table, add a route to its corresponding AWS Network Firewall VPC endpoint (of type Gateway Load Balancer Endpoint) per AZ:

    • inspection-vpc-tgw-connectivity-rtb-use1-az1

      Destination Target Description
      10.20.16.0/20 local Inspection VPC
      0.0.0.0/0 nfw-use1-az1 Firewall endpoint for use1-az1

    • inspection-vpc-tgw-connectivity-rtb-use1-az2

      Destination Target Description
      10.20.16.0/20 local Inspection VPC
      0.0.0.0/0 nfw-use1-az2 Firewall endpoint for use1-az2

    • inspection-vpc-tgw-connectivity-rtb-use1-az4

      Destination Target Description
      10.20.16.0/20 local Inspection VPC
      0.0.0.0/0 nfw-use1-az4 Firewall endpoint for use1-az4

  6. Configure the Private Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Transit Gateway attachment):

    • inspection-vpc-private-rtb

      Destination Target Description
      10.20.16.0/20 local Inspection VPC
      0.0.0.0/0 tgw Transit Gateway

  7. Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Inspection VPC.

Inspection VPC

Build the Egress VPC

  1. Create a VPC (e.g., named egress VPC, CIDR 10.20.32.0/20) with:

    • 3 public subnets (e.g., /22)
    • 3 private subnets for TGW connectivity (/28)
    • 1 Internet Gateway
    • 1 NAT Gateway per AZ for high availability

  2. Create a Transit Gateway attachment between the Transit Gateway and the Egress VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.

  3. Manually edit the Transit Gateway Route Tables:

    • In the TGW Default Propagation Route Table, create a static route to 0.0.0.0/0 towards the Egress VPC Attachment.

  4. Configure the TGW Connectivity Subnet Route Tables (create one route table per AZ, and in each table add a 0.0.0.0/0 route to its corresponding NAT Gateway):

    • egress-vpc-tgw-connectivity-rtb-use1-az1

      Destination Target Description
      10.20.32.0/20 local Egress VPC
      0.0.0.0/0 natgw-use1-az1 NAT for use1-az1

    • egress-vpc-tgw-connectivity-rtb-use1-az2

      Destination Target Description
      10.20.32.0/20 local Egress VPC
      0.0.0.0/0 natgw-use1-az2 NAT for use1-az2

    • egress-vpc-tgw-connectivity-rtb-use1-az4

      Destination Target Description
      10.20.32.0/20 local Egress VPC
      0.0.0.0/0 natgw-use1-az4 NAT for use1-az4

  5. Configure the Public Subnet Route Table (this route table needs a 0.0.0.0/0 route to the Internet Gateway and routes to the CIDRs of the Spoke VPCs to go through the TGW attachment):

    • egress-vpc-public-rtb

      Destination Target Description
      10.20.32.0/20 local Egress VPC
      10.21.0.0/16 tgw Development VPC
      10.22.0.0/16 tgw QA VPC
      10.23.0.0/16 tgw Production VPC
      10.24.0.0/16 tgw DevOps VPC
      0.0.0.0/0 igw Internet access

  6. Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Egress VPC.

Egress VPC

Build the Workload VPCs

  1. Create a VPC (e.g., named development VPC, CIDR 10.21.0.0/16) with:

    • 3 private subnets for workloads (e.g., /20)
    • 3 private subnets for TGW connectivity (/28)

  2. Create a Transit Gateway attachment between the Transit Gateway and the VPC, selecting the Subnet IDs of the 3 TGW connectivity subnets.

  3. Configure the TGW Connectivity Subnet Route Table — this route table will only have a local route:

    • development-vpc-tgw-connectivity-rtb

      Destination Target Description
      10.21.0.0/16 local Development VPC

  4. Configure the Private Subnet Route Table — add a 0.0.0.0/0 route to the Transit Gateway attachment:

    • development-vpc-private-rtb

      Destination Target Description
      10.21.0.0/16 local Development VPC
      0.0.0.0/0 tgw Transit Gateway

  5. Optional: Create a VPC Flow Log for the VPC to monitor and log the traffic flowing through the Workload VPC.

Workload VPC

Configure the AWS Network Firewall

This article primarily focuses on configuring the Network Baseline and the necessary routing to use Network Firewall. At a high level, AWS Network Firewall is a managed service that allows you to protect your network by filtering traffic to and from your VPCs. It provides a stateful firewall and intrusion detection and prevention system that can be deployed inline with your network traffic, inspecting and filtering packets in real time.

  1. In the Firewall, enable Alert and Flow logging, and configure CloudWatch as the log destination by creating the necessary log groups.
  2. Optional: Edit the previously created empty Firewall Policy to:
    • Add AWS Managed rule groups
    • Create and add Stateless rule groups
    • Create and add Stateful rule groups

Review the Final Architecture

The deployed architecture follows a centralized inspection model using AWS Transit Gateway and AWS Network Firewall to control and monitor traffic between shared and workload VPCs.

  1. The Transit Gateway Default Association Route Table should look like this:

    • tgw-default-association-rtb

      CIDR Attachment Resource Type Route Type
      0.0.0.0/0 Inspection VPC VPC Static

  2. The Transit Gateway Default Propagation Route Table should look like this:

    • tgw-default-propagation-rtb

      CIDR Attachment Resource Type Route Type
      10.21.0.0/16 Development VPC VPC Propagated
      10.22.0.0/16 QA VPC VPC Propagated
      10.23.0.0/16 Production VPC VPC Propagated
      10.24.0.0/16 DevOps VPC VPC Propagated
      10.20.0.0/20 Ingress VPC VPC Propagated
      10.20.32.0/20 Egress VPC VPC Propagated
      0.0.0.0/0 Egress VPC VPC Static

  3. If the route tables do not appear as expected, detach and remove any incorrect associations or propagations, then re-associate and re-propagate the attachments with the appropriate route tables until the tables reflect the correct configuration.

The following architecture diagram illustrates the final multi-account setup, where traffic from the spoke accounts (Development, QA, Production, and DevOps) is routed through the centralized inspection layer.

Deployed Architecture

Validate Connectivity and Traffic Inspection

  1. Optionally, deploy EC2 instances in the Workload VPCs in private workload subnets across different accounts.

    • Connect using Session Manager and try to ping between the private IPs of the instances.
    • Ensure the security groups allow inbound ICMP and outbound HTTPS (443) to the internet (for Session Manager).
    • The pings should be successful.

  2. Optionally, deploy a client VPN such as OpenVPN or WireGuard on an EC2 instance in a public subnet in the Ingress VPC.

    • Connect through the VPN and try to ping the private IPs of the EC2 instances in the Workload VPCs.
    • Ensure the security groups allow inbound ICMP.
    • The pings should be successful.

  3. Check the CloudWatch Log Groups to verify the Flow type Firewall logs. You should see that all test traffic is successfully passing through the Network Firewall.

    • The Alert type Log Group should be empty for now, since the Network Firewall Policy has not been configured yet or the test traffic does not match any alert rules.

Bonus: Network Firewall Transit Gateway Attachment

During re:Inforce 2025, AWS announced the new Network Firewall Transit Gateway Attachment feature, which replaces the traditional “Inspection VPC” pattern, simplifying deployment and improving traffic visibility.

Instead of step "4. Create Inspection VPC", you would do "4. Create Network Firewall Transit Gateway Attachment".

  1. In the AWS Network Firewall console:

    1. Select Create firewall.
    2. In Describe firewall: Add a Firewall name and description (optional).
    3. In Attachment Type: Choose Transit Gateway and select the Transit Gateway.
    4. In Availability Zones: Select the 3 Availability Zones you have been working with.
    5. In Associate Firewall Policy: Select Create and associate an empty firewall policy and specify a new firewall policy name.
    6. Create the Firewall; it will take a few minutes.

  2. Manually edit the Transit Gateway Route Tables:

    1. Remove the propagation of the Network Firewall TGW attachment in the TGW Default Propagation Route Table.
    2. Remove the association of the Network Firewall TGW attachment in the TGW Default Association Route Table.
    3. Associate the TGW Default Propagation Route Table with the Network Firewall TGW Attachment.
    4. In the TGW Default Association Route Table, create a static route to 0.0.0.0/0 towards the new Network Firewall TGW Attachment.

  3. The Transit Gateway Default Association Route Table will look as follows:

    • tgw-default-association-rtb

      CIDR Attachment Resource Type Route Type
      0.0.0.0/0 AWS Network Firewall Firewall Static

  4. The Transit Gateway Default Propagation Route Table will remain unchanged in this scenario.

Network Firewall Transit Gateway Attachment

Conclusion

In conclusion, implementing AWS Network Firewall in a multi-account architecture with Transit Gateway provides a robust, scalable, and secure network infrastructure. By following the steps outlined in this article, you can effectively deploy and configure Network Firewall to protect your VPCs across different accounts within an AWS Organizations structure. The Hub & Spoke pattern, combined with the high availability of 3 Availability Zones, ensures that your network is resilient and capable of handling various traffic patterns and security requirements. Additionally, the use of VPC Flow Logs and Network Firewall logging allows for detailed monitoring and analysis of network traffic, enabling you to identify and respond to potential security threats promptly.

Top comments (0)