With the multi-region Active Directory foundation in place for your WorkSpaces deployment, the next critical step is securing outbound internet traffic. Instead of placing a firewall in every VPC, a centralized egress model provides consistent policy enforcement and simplifies management. This architecture routes all outbound traffic from spoke VPCs (containing your WorkSpaces) through a dedicated inspection VPC.

This design hinges on three core AWS services working in concert: AWS Transit Gateway (TGW), Gateway Load Balancer (GWLB), and your Palo Alto VM-Series firewalls. The TGW acts as a cloud router, connecting all your VPCs. The GWLB provides a transparent, scalable entry point for traffic inspection, distributing the load across a fleet of firewalls. The result is a single chokepoint for all egress traffic, where you can apply deep packet inspection and unified security policies.

Understanding the traffic path is key. When a user in a WorkSpace attempts to access an external website, the packet flow is precisely controlled.

The spoke VPC's route table sends all outbound traffic (0.0.0.0/0) to the TGW. The TGW attachment's route table then forwards this traffic to the GWLB endpoints deployed in the inspection VPC. GWLB encapsulates the original packet in a GENEVE header and forwards it to a healthy Palo Alto VM-Series instance for inspection. After the firewall applies its policies, it routes the (now permitted) traffic to a NAT Gateway in its own VPC for translation and egress to the internet.

Stateful firewalls must see both the request and the reply packets of a session to function correctly. In a multi-AZ environment with multiple firewall instances, traffic could potentially leave through one firewall and return through another. This breaks the session state and causes traffic to be dropped. This is known as asymmetric routing.

To prevent this, the TGW is configured with Appliance Mode enabled on the inspection VPC attachment. This setting ensures that for the lifetime of a flow, the TGW will always send packets to the same availability zone where the flow originated. The GWLB, in turn, maintains stickiness to a specific firewall instance within that AZ. This guarantees that both outbound and return traffic for a given session traverse the same Palo Alto firewall, preserving state.

Palo Alto VM-Series firewalls are configured with separate sub-interfaces for different traffic zones, often representing each spoke VPC or group of VPCs. This allows for granular policy control. For instance, traffic from the development VPC can be subject to different rules than traffic from the production WorkSpaces VPC, all within the same centralized firewall fleet.

Centralized policy management is handled by Panorama, which allows you to define and push security policies to all VM-Series instances globally from a single console. This ensures consistency and dramatically reduces administrative overhead.

VDI protocols like PCoIP and WSP are sensitive to latency and packet loss. The journey through the TGW, GWLB, and firewall adds a small amount of latency. More importantly, it introduces complexity around the Maximum Transmission Unit (MTU). The GENEVE encapsulation used by GWLB adds 60 bytes of overhead to each packet.

If the original packet from the WorkSpace is 1500 bytes, the encapsulated packet becomes 1560 bytes. This exceeds the standard 1500-byte MTU of most network paths, leading to fragmentation. Excessive fragmentation can severely degrade VDI session performance, causing laggy displays and dropped connections. To mitigate this, you must either enable jumbo frames across the entire path (TGW supports this) or clamp the TCP MSS (Maximum Segment Size) on the Palo Alto firewalls. Clamping the MSS causes the firewall to negotiate a smaller packet size with endpoints, preventing fragmentation before it happens.