Deep Dive: AWS VPC East-West Traffic Inspection Using Gateway Load Balancer Endpoints (GWLBE) and the importance of Logical Zones in AWS 

By Brandon Prasnicki, Senior Solutions Cloud Architect

For years, network security has primarily focused on controlling access between internal resources and the outside world. Traditional firewall inspection was mostly about North-South traffic—governing what servers could access the internet and preventing unauthorized inbound access from external sources. 

However, as cloud environments have become more dynamic and interconnected, East-West traffic—communications between services within and across VPCs—has become equally critical to secure. In this post, we’ll explore how AWS enables East-West traffic inspection using Gateway Load Balancer Endpoints (GWLBE), and how you can implement this in a multi-account AWS Landing Zone architecture with a centralized networking model. 

 

A Shift in Network Security Paradigms 

Historically, traffic inspection focused on: 

  • Egress control: Preventing sensitive systems from reaching malicious or unauthorized external destinations. 
  • Ingress control: Blocking unwanted traffic from the internet into the private network. 

In today’s cloud-native environments, however, there’s an increasing need to inspect internal traffic. This includes communication: 

  • Across multiple VPCs 
  • Between subnets within a single VPC. 

 

Use Case: Centralized Firewall in Multi-Account Architecture 

In this example, we’ll walk through setting up East-West traffic inspection in a multi-account AWS Landing Zone where: 

  • A dedicated networking account hosts the firewalls and the GWLB Endpoint Service. 
  • Application accounts host workloads that need traffic inspection. 

VPC to VPC inspection 

In the diagram above, the Transit Gateway is routing to the inspection VPC for North-South and also East-West traffic.  As long as the TGW attachment in the workload account has a TGW route table that routes traffic to the inspection VPC, and then the inspection VPC TGW attachment routes to the other VPC’s, VPC to VPC inspection can be handled via TGW routing.  However, what about within a VPC inspection and inspecting traffic between subnets?  This is where Gateway Load Balancer (GWLB) comes into play. 

What Is GWLBE? 

Gateway Load Balancer Endpoints are powered by AWS PrivateLink and allow traffic within a VPC to be routed through a centralized Gateway Load Balancer (GWLB) service, typically backed by third-party firewalls (like Palo Alto, Fortinet, etc.). This enables you to insert inspection transparently into VPC-to-VPC or intra-VPC communication, without needing complex overlays or inline appliances. 

Prerequisites 

  • You are using a third-party firewall that integrates with Gateway Load Balancer (e.g., Palo Alto Networks VM-Series). 
  • All VPCs must have a hub-and-spoke connectivity model or VPC peering/transit gateway set up to route traffic through the centralized firewall VPC. 

Important Considerations for Centralized Networking in Multi-Account Architectures 

Before we get into the details of how to configure GWLB for this specific traffic routing need, an important concept that is relevant here is AZ randomization is achieved during account creation.  What this means is that ‘az1’ in account A is not necessarily ‘az1’ in account B based on the name.  Please see https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html#:~:text=AWS%20maps%20the%20physical%20Availability,%22a%22%20for%20each%20Region. 
 
In short, the AZ name is not the same as the physical location AZ ID, and this is directly affects GWLBE routing across accounts.  I will try to point this out in context when I go through the steps. 

Step-by-Step Deployment 

1. Deploy GWLB and Register the Endpoint Service 

In the networking account: 

  • Deploy your third-party firewalls behind a Gateway Load Balancer.  When you create the GWLB note that you will define your network mapping for the loadbalancer and associate AZ’s and subnets. 
  • Create a target group for the static ip’s of your firewall appliance. 
  • Create a listener on the GWLB that forwards to this target group. 
  • Register a GWLB Endpoint Service targeting your GWLB load balancer.  Note here the AZ name and physical AZ location ID are different.  Also highlighted here is the ‘Allow Principles’ tab used in the next step. 

As seen from the endpoint screen: 

2. Update Access Permissions 

  • In the GWLB Endpoint Service, update the “Allowed Principals” to include the AWS Account IDs of each application account that will consume the service. 

3. Provision GWLBE in Application Accounts 

  • In each application account, create a Gateway Load Balancer Endpoint (GWLBE) in a dedicated connectivity subnet.  Do not use application subnets.  Using a separate subnet allows for the different route table associations with the route tables as we will see below. 
  • Point the endpoint to the registered GWLB Endpoint Service in the networking account.  
     

Note that the below is where physical AZ ID’s come into play.  In the Dev workload account, ‘AZ/1a’ is in use1-az6 and ‘AZ2/1b’is in use1-az1.  You will notice here in the ‘subnets’ section, it is displaying subnets that the GWLB from the network account has for AZ physical zones.  Since for this dev account ‘use1-az4’ maps to us-east-1d, and I only created subnets in 1a and 1b, I only have one subnet available to me.  If more subnets are required, and you don’t have the same physical AZ ID available, simply create a subnet in a physical AZ that matches the AZ ID from the networking account for your application account GWLBE. 

4. Accept Endpoint Connections 

  • In the networking account, go to the VPC Dashboard > Endpoint Services > Endpoint Connections, and accept the connection requests from all application accounts. 

5. Configure Routes on the Firewall 

  • On the Palo Alto (or your firewall of choice), update the Virtual Router configuration. 
  • Add static routes to each application’s VPC CIDR range.
    • Set the next hop to the gateway IP of the data plane NIC of the firewall for each route. 

6. Update Application Route Tables 

  • In each application VPC, update the application subnet route tables (noting here that your subnet ‘connectivity’ will need a different route table association than your application subnets that require inspection). 
  • Replace the local VPC route (or specific VPC CIDR routes) to target the GWLBE.
    • This ensures traffic between subnets is routed through the firewall for inspection. 

Here you can see the connectivity subnet for which the GLBE resides.  This route table has a simple route utilizing the transit gateway.

 

Key Considerations 

  • Same-subnet traffic cannot be inspected: Traffic between instances within the same subnet is handled at the link layer and does not traverse the route table—this is a fundamental networking limitation. 
  • Performance & latency: Routing through a centralized firewall introduces additional latency. Consider scaling your inspection tier and using high-throughput instances for firewalls. 
  • Cost implications: Using GWLBEs involves data processing charges. Factor this into your budget planning. 

Secure every packet. Control every path.
Schedule a TekStream AWS Security Design Session and build East-West visibility into your architecture.

Conclusion 

As AWS environments grow in complexity, securing East-West traffic becomes just as important as securing traditional ingress and egress flows. By using Gateway Load Balancer Endpoints, you can centralize and streamline traffic inspection across multiple VPCs and accounts without adding operational overhead. 

This approach provides a scalable, secure, and cloud-native method for enforcing inter-VPC and intra-VPC traffic policies—bringing your security posture in line with modern cloud architecture needs. 

About the Author

Brandon Prasnicki is a Senior Solutions Architect at TekStream Solutions with over 20 years of experience designing, architecting, and supporting enterprise cloud and information management technologies. As an AWS Certified Solutions Architect – Professional, Brandon specializes in cloud migrations, infrastructure design, and security for public sector and enterprise clients. His expertise spans a wide range of AWS services, with a primary focus on EC2, VPC architecture, networking, IAM, security groups, load balancing, and creating highly available, secure, and well-architected cloud environments.

Brandon has led and supported more than 20 large-scale AWS migration initiatives. Recent projects include migrations for the Georgia Department of Labor (GDOL), Georgia Student Finance Commission (GSFC), Department of Health Care Finance (DHCF/DCAS), and the State of Delaware. These engagements have included hands-on design and implementation using both AWS Migration Service (MGN) and custom AMI-based migrations. They also encompass full infrastructure buildouts and close collaboration across multiple teams to ensure smooth transitions and optimized cloud performance. Brandon continues to provide long-term architecture, support, and optimization for migrated environments—working closely with customers as they gain independence and maturity in their AWS operations.

Known for his strong customer advocacy, Brandon partners closely with AWS Support, AWS Solution Architects, and AWS Managed Services (AMS) to help clients navigate challenges and achieve successful outcomes. His ability to combine deep technical expertise with clear communication and strategic planning enables him to deliver secure, efficient, and scalable solutions aligned with each client’s goals.

At TekStream, Brandon’s commitment to thoughtful design, practical implementation, and collaborative problem solving continues to help organizations modernize their environments and realize the full value of AWS.