
In this case, GWLB’s idle timeout is lower than the timeout value on the firewall, which causes GWLB to remove the flow without the firewall or client being aware it was dropped. Some firewalls have a default timeout of 3600 seconds (1 hour). This can result in the flow timing out on the client side. As a result, the subsequent packets for that flow are treated as a new flow and may be sent to a different healthy firewall instance. Once the idle timeout is reached for a flow, it is removed from GWLB’s connection state table. GWLB has a fixed idle timeout of 350 seconds for TCP flows and 120 seconds for non-TCP flows. Some applications or API requests, such as synchronous API calls to databases, have long periods of inactivity. Tune TCP keep-alive or timeout values to support long-lived TCP flows

Understand when to use Cross-Zone Load Balancing.Enable Appliance Mode on AWS Transit Gateway to maintain flow symmetry for inter-VPC traffic inspection.Tune TCP keep-alive or timeout values to support long-lived TCP flows.This blog post will focus on the most commonly used design patterns and optimal configuration setting as best practices to consider when deploying GWLB:

Since the launch, a lot of customers have deployed GWLB with AWS Partner firewalls in the production environment. These appliances include firewalls (FW), intrusion detection and prevention systems, and deep packet inspection systems in the cloud. At re:Invent 2020, we launched Gateway Load Balancer (GWLB), a service that makes it easy and cost-effective to deploy, scale, and manage the availability of third-party virtual appliances.
