AWS Public Sector Blog
Simplify firewall deployments using centralized inspection architecture with Gateway Load Balancer
As government organizations transition to Amazon Web Services (AWS), they often seek to maintain operational continuity by using their existing on-premises firewall solutions. Gateway Load Balancer (GWLB) enables seamless integration of these firewall appliances into the AWS architecture, ensuring consistent security policies and minimizing disruptions.
In networking, traffic flows are often categorized as either “north-south” or “east-west.” North-south traffic refers to data moving between the cloud environment and external networks, such as user requests from the internet or data leaving the cloud to external services. East-west traffic describes communication within the cloud environment, such as between different applications or services in various subnets or VPCs. East-west traffic can also include communication between the AWS Cloud and on-premises data centers connected via AWS Direct Connect or other private connectivity solutions.
This post will explore best practices for implementing GWLB to facilitate centralized traffic inspection for both east-west and north-south traffic flows. We’ll discuss key considerations for designing an inspection architecture with Gateway Load Balancer, providing government organizations with guidance to achieve a secure cloud transition while maintaining compliance and security standards.
Traffic inspection with Gateway Load Balancer
In traditional on-premises deployments, firewalls are positioned at the network perimeter to inspect north-south traffic and internally to secure sensitive infrastructure and enforce granular security policies. Similarly, in the AWS Cloud, organizations require additional security measures for east-west traffic flowing between Amazon Virtual Private Cloud (VPC) environments to ensure consistent security controls.
GWLB facilitates both east-west and north-south traffic inspection by leveraging GWLB endpoints powered by AWS PrivateLink. This allows IT departments to provide a centralized inspection service for other lines of business to consume, enforcing the desired security posture. It’s important to note that GWLB operates as a bump-in-the-wire solution, meaning it transparently intercepts and forwards traffic without acting as a proxy. This design, shown in Figure 1, ensures that the original source and destination IP addresses are preserved, maintaining network transparency and compatibility with existing security appliances.
Figure 1. Logical architecture of Gateway Load Balancer with endpoints powered by AWS PrivateLink for traffic inspection.
- East-west traffic inspection: IT departments can deploy their firewall appliances within an inspection VPC utilizing GWLB endpoints to send traffic to these appliances for inspection. Customers can choose between AWS Transit Gateway or AWS Cloud WAN to route their inter-VPC traffic to the inspection VPC. This approach ensures that all inter-VPC communication between resources, such as Amazon Elastic Compute Cloud (EC2) instances, is inspected and monitored, thereby enhancing the overall security posture of the environment. This blog will focus on Transit Gateway architecture; however, for more information on using AWS Cloud WAN, please refer to the “Simplify global security inspection with AWS Cloud WAN Service Insertion” blog post.
- North-south traffic inspection: By configuring GWLB endpoints as the entry and exit points for internet traffic, government customers can route all incoming and outgoing traffic through their firewall appliances for inspection. This approach aligns with traditional on-premises deployment models, where firewalls are positioned at the network perimeter to inspect and control external traffic.
The ability to leverage GWLB for east-west and north-south traffic inspection offers government customers a powerful framework to implement their desired security architecture within the AWS cloud. By integrating their existing firewall solutions, organizations can maintain operational continuity, leverage familiar management interfaces, and ensure consistent enforcement of security policies across their entire infrastructure.
Architectural guidance for Gateway Load Balancer
When designing a comprehensive inspection architecture using GWLB) and your firewall appliances, the Centralized inspection VPC architecture, shown in Figure 2, is a recognized best practice and reference architecture. This approach effectively addresses both east-west and egress traffic inspection requirements, offering flexibility and efficiency in a multi-VPC environment.
Centralized inspection VPC architecture
Figure 2. Centralized inspection data-plane architecture using Gateway Load Balancer and Transit Gateway.
In the Centralized inspection VPC architecture, a dedicated inspection VPC is established to host your firewall appliances. All traffic requiring inspection from your application or spoke VPCs is routed through AWS Transit Gateway to these centralized firewall appliances using GWLB endpoints within the Egress VPC. This includes both east-west traffic between VPCs (traffic flow 1 in Figure 2) and egress traffic bound for the internet (traffic flow 2 in Figure 2).
To facilitate management of the firewall appliances, the inspection VPC can be connected to Transit Gateway—not shown in Figure 2. This connection allows for secure management traffic flow, enabling administrators to access and manage the firewalls from designated management VPCs or on-premises networks through Direct Connect or VPN connections.
For internet-bound traffic, after inspection by the firewall appliances, the traffic egresses via an internet gateway attached to the Egress VPC. Customers have the flexibility to choose between using AWS NAT (Network Address Translation) Gateway (one-arm firewall deployment) or leveraging their own firewall appliances for NAT capabilities (two-arm firewall deployment) for internet egress, depending on their specific requirements and preferences. In a one-arm firewall deployment, there’s a single interface deployed within a private subnet that only receives traffic for inspection. In contrast, a two-arm firewall deployment utilizes two interfaces: one in a private subnet for inspection and another in a public subnet, allowing the firewall to perform NAT—if supported—for internet egress. Customers should be aware that the two-arm approach is only feasible when the firewall vendor supports this architecture.
For customers preferring to use their firewalls for NAT capabilities, a two-arm architecture can be implemented. In this approach, traffic exits directly from the inspection VPC. For more details on one-arm versus two-arm firewall deployments, please refer to the “Best practices for deploying Gateway Load Balancer” blog post.
Distributed vs. centralized internet ingress design
When designing the internet ingress architecture for your AWS environment, there are two primary approaches to consider: distributed ingress and centralized ingress. Each approach has its own set of tradeoffs, and the choice ultimately depends on your organization’s specific requirements, policies, and preferences.
AWS WAF can be integrated into either ingress approach, providing enhanced security for public-facing web applications. Furthermore, AWS WAF can be combined with AWS Shield Advanced, offering comprehensive protection against sophisticated DDoS attacks at both the network and application layers. However, it’s crucial to understand that AWS WAF only secures web applications, and a different solution is necessary for protecting non-web applications that are public-facing.
While AWS WAF and Shield Advanced offer valuable protection for ingress traffic to web applications, this post primarily focuses on the inspection architecture using GWLB and firewall appliances. The integration of AWS WAF and Shield Advanced for web application ingress protection can complement the GWLB-based inspection approach for east-west traffic, egress flows, and non-web application ingress. This combination provides a comprehensive security strategy, addressing both incoming and outgoing traffic flows in your AWS environment.
In the following sections, we’ll explore the two primary approaches to GWLB-based ingress architectures: distributed ingress and centralized ingress. We’ll discuss the characteristics, benefits, and considerations of each approach, helping you determine the best fit for your organization’s specific requirements.
Distributed ingress
Figure 3 is an architectural diagram of distributed internet ingress using GWLB.
Figure 3. Distributed Internet Ingress using Gateway Load Balancer.
A distributed internet ingress architecture relies on each VPC having its own dedicated internet gateway. While this approach offers advantages like simplified management, decreased blast radius, streamlined troubleshooting, and simplified chargeback, it also raises concerns among government IT departments about potential misalignment with the organization’s established security posture.
To mitigate risks associated with a distributed ingress architecture, government IT departments can implement:
- Centralized security policies: Establish and enforce centralized security policies using AWS Organizations, which allows you to manage and govern multiple AWS accounts from a single management account.
- VPC sharing: Utilize AWS Resource Access Manager (RAM) to share VPCs across multiple AWS accounts. This allows for centralized control over network resources while still enabling distributed management of workloads and simplifying security oversight.
- Least privilege access: Use AWS Identity and Access Management (IAM) to implement the principle of least privilege and prevent unauthorized modifications to internet gateways, VPC route tables, and inspection settings.
- Centralized monitoring and auditing: Implement centralized monitoring and auditing mechanisms to maintain visibility over all accounts and workloads. Utilize AWS services like AWS CloudTrail and Amazon GuardDuty to track API calls, detect suspicious activities, and ensure compliance with your organization’s security policies.
- Automated remediation: Leverage AWS Config and AWS Systems Manager Automation to continuously monitor your environment and automatically remediate any deviations from your defined security standards.
By implementing these strategies, government IT departments can effectively mitigate risks while reaping the benefits of a distributed ingress approach.
Centralized ingress
Figure 4 is an architectural diagram of centralized internet ingress using GWLB and Transit Gateway.
Figure 4. Centralized internet ingress using Gateway Load Balancer and Transit Gateway.
In scenarios where a distributed approach is not feasible, a centralized ingress architecture can be explored. This model involves creating a dedicated ingress VPC that hosts your application delivery stack, through which all incoming internet traffic flows are directed for inspection before being forwarded to the target application VPCs using Transit Gateway. Alternatively, customers may also forward traffic to application VPCs using AWS PrivateLink for secure, private connectivity. While a centralized ingress architecture provides a centralized control point, it also introduces drawbacks such as increased complexity, higher costs, increased blast radius, and difficult chargeback.
To mitigate the chargeback challenge, organizations can explore the following strategies:
- Tagging and cost allocation: Implement a consistent tagging strategy across all resources. Utilize AWS cost allocation tags to track and allocate costs based on these tags, enabling more granular cost attribution.
- Cost distribution models: Develop internal cost distribution models that fairly allocate the shared infrastructure costs among the participating workloads.
- Separate ALBs and WAFs: Deploy separate ALBs and WAFs for each workload or group of workloads. While this approach may increase the overall infrastructure costs, it simplifies cost allocation and chargeback processes.
Which ingress architecture to choose?
Ultimately, the choice between a decentralized or centralized internet ingress design should be based on a careful evaluation of your organization’s specific requirements, policies, and risk tolerance. Both approaches have their advantages and trade-offs, and it’s essential to weigh these factors to determine the most suitable architecture for your AWS environment. For more information, please review the “Design your firewall deployment for Internet ingress traffic flows,” blog post.
After choosing between a distributed or centralized ingress approach, you must decide whether to deploy the Elastic Load Balancer (ELB) before or after the GWLB endpoint. This decision impacts your architecture’s security, performance, and flexibility. The following table will help you make an informed decision based on your specific needs.
| Ingress routing versus more specific routing | |
| Ingress routing | More specific routing |
 |
 |
|
*not supported for NLB with client IP preservation enabled |
This post focuses on the ingress routing option, which involves deploying the ELB after the GWLB endpoint. In traditional cloud architectures, when traffic passes through load balancers or proxies, the original client IP address can be lost. To preserve this information, the X-Forwarded-For (XFF) header is used to retain the original client IP address. However, XFF has limitations: it only works for HTTP traffic and can sometimes face compatibility issues.
The Ingress routing option we’re discussing aligns with on-premises architecture and allows customers to operate their firewalls similarly to their existing deployments. This configuration eliminates the need for XFF header configuration, addressing its limitations. By placing the ELB after the GWLB endpoint, we maintain visibility of the original client IP for all traffic types, not just HTTP. This approach helps maintain comprehensive traffic visibility and simplifies firewall operations in cloud environments.
Both options are protected by AWS Shield, a managed DDoS protection service that safeguards applications running on AWS. However, ELB as an AWS managed service can scale automatically during a DDoS event, providing Shield time to detect and mitigate the attack. With third-party firewall deployments, customers are responsible for scaling their firewalls and ensuring they have the appropriate licenses to handle increased traffic. This may require more proactive management and planning on the customer’s part to achieve comparable scalability during high-traffic events or DDoS attacks.
Alignment with best practices
The centralized inspection VPC architecture aligns with several best practices for cloud security and network design. By routing all traffic through a single inspection point, this architecture provides consistent security policies across your entire AWS environment. Centralizing firewall appliances reduces operational complexity, making it easier to manage, update, and monitor security controls. This approach also eliminates the need for multiple NAT gateways in each VPC, potentially reducing costs. However, it’s important to consider data processing costs associated with Transit Gateway for large data egress.
The architecture demonstrates excellent scalability, easily accommodating growth by allowing new VPCs to be added and secured without significant reconfiguration. It offers flexibility by supporting both distributed and centralized internet ingress, allowing you to secure incoming traffic across multiple application VPCs or a dedicated ingress VPC, based on your organization’s needs.
From a security perspective, this architecture enhances protection by limiting the points of egress to the internet, thereby reducing the attack surface and improving control over external communications. The centralized nature of this approach also facilitates easier auditing and reporting, supporting compliance with various regulatory requirements.
Conclusion
If your organization has unique needs or constraints that are not addressed by this guidance, consult with your AWS account team. AWS solutions architects and networking specialists can provide tailored guidance to ensure your AWS networking architecture aligns with your requirements, compliance standards, and best practices.