Update October 11, 2020 – While the implementations described in this post remain valid, it was written before Gateway Load Balancer became available. Gateway Load Balancer is designed specifically for adding firewalls and other virtual network appliances to your AWS network. If you would like to learn more, Introducing AWS Gateway Load Balancer: supported architecture patterns and Scaling network traffic inspection using AWS Gateway Load Balancer may be of interest.

Many customers have requirements to leverage existing on-premises firewall technology or want to get started in AWS by using their existing firewall expertise. A large number of firewall vendors have versions of their software in the AWS Marketplace that work in either bring-your-own-license (BYOL) or pay-as-you-go pricing models. This makes it easy to get up and running with your preferred firewall vendor leveraging their optimized EC2 instance templates. These appliances integrate nicely with existing AWS technologies like AWS Transit Gateway and Elastic Load Balancing.

In this post, I highlight several common methodologies for implementing third-party firewalls into your AWS environment. Note you should always refer to your firewall vendor for specific implementation details and best practices.

Overview of solutions

This post covers the following architectures for integrating third-party firewall appliances into an AWS environment:

• Single VPC
• Transit VPC
• Transit gateway with a VPN attachment
• Transit gateway with a VPC attachment
• Inbound traffic load balancing (ELB sandwich)

Single VPC

This architecture includes a single VPC and uses a firewall to control traffic flow in and out of the VPC. A firewall serves as the next hop route for all traffic. If there is a requirement for inbound traffic inspection, ingress routing can be used. However we will cover the more general architecture.

High availability is accomplished through an active/passive deployment. However modifications to route tables or failover of elastic network interface (ENIs) must be configured so the passive firewall elastic network interface becomes the default route destination.

This architecture is depicted in the following diagram.

Transit VPC

This architecture uses at least two firewalls appliances for high availability, typically in an active/passive configuration, to build out a transit VPC. This architecture can scale to a larger number of VPCs. Each VPC connects to both the active and passive firewalls using AWS Site-to-Site VPN, a fully managed service.

The primary firewall can quickly become a bottleneck. This architecture is not recommended when more than several Gbps of throughput is required. For these types of environments it is best practice to use architectures that incorporate AWS Transit Gateway, that can achieve higher performance. I discuss these architectures in the following section.

Automatic failover in a transit VPC architecture is achieved using BGP AS path prepending to make the primary firewall more favorable than the passive firewall. Levering BGP allows quick failover and failback.

This architecture is depicted in the diagram below.

Transit gateway with VPN attachment

AWS Transit Gateway is a scalable and highly available AWS service for connecting VPCs and on-premises environments.

This architecture uses a number of firewall appliances, each of which has VPN attachments to a transit gateway. This allows for equal-cost multi-path routing (ECMP) across appliances and within a specific appliance for aggregated throughput. Each VPN attachment has a maximum throughput of 1.25 Gbps.

The use of BGP on the VPN attachments allows for automatic failover in the case of any issues with a particular firewall and facilitates maintenance activities. To maintain route symmetry, source network address translation (SNAT) must be configured on the firewall appliances.

The following diagram depicts this architecture.

In the diagram, there is a default route in each VPC route table with the transit gateway as the destination. The transit gateway VPC-to-VPC route table then has a default route that directs traffic to the ECMP load balanced VPN connections. The traffic then terminates on a firewall and gets source NAT (SNAT) applied to maintain flow symmetry. Internet bound traffic goes out to the Internet Gateway and VPC traffic routes back into the Transit Gateway to the destination VPC.

This architecture combines VPC-to-VPC inspection with outbound internet traffic inspection. However, they are not mutually exclusive and can be implemented independently of each-other.

Transit gateway with VPC attachment

This architecture uses a number of firewall appliances in a VPC that is directly attached to a transit gateway. It provides greater throughput, as a VPC attachment can scale to up to 50 Gbps of throughput per availability zone, and there is no IPsec tunnel overhead. However, it does come with some caveats. Namely, there can only be one active firewall per Availability Zone.

Manual intervention is required to modify route tables if any of the firewalls experience issues. However this can be monitored and remediated automatically through Lambda functions. Similarly to the VPN deployment, SNAT must be configured on the firewall appliances to maintain route symmetry.

This architecture is depicted in the following diagram.

In the diagram, there is a default route in each VPC route table with the transit gateway as the destination. The transit gateway VPC-to-VPC route table then has a default route that directs traffic to the VPC that contains the firewalls. The traffic then terminates on a firewall and gets source NAT (SNAT) applied to maintain flow symmetry. Internet bound traffic goes out to the Internet Gateway. The return traffic routes back into the Transit Gateway to the destination VPC.

Given that we are doing direct attachment to the VPC, we need four separate route tables, one for each transit gateway elastic network interface and one for the firewalls. This allows each elastic network interface to direct traffic to the firewall local to its Availability Zone and allows us to control traffic per Availability Zone.

It’s important to note that in the transit gateway VPC attachment architecture there is no the ability to load balance across firewalls and one firewall may be overloaded, while another is not.

This example combines VPC-to-VPC inspection with outbound internet traffic inspection. However they are not mutually exclusive and can be implemented independently.

Inbound traffic load balancing (ELB sandwich)

This architecture is used to specifically address requirements for inbound traffic firewall inspection. Traffic first passes through a load balancer that is used as a frontend for an Auto Scaling group of firewalls. The destination for each firewall is another load balancer that contains targets behind it (Lambda, EC2 instances, on-premises resources, etc.). This tiered approach allows both the security inspection tier, as well as the web front-end tier, to scale in and out independently of each other in a cost-effective manner.

This architecture is depicted in the following diagram.

This type of architecture can also be used with Transit Gateway to provide a centralized inbound inspection capability for multiple services. This architecture is depicted in the diagram below.

Considerations

Regardless of your firewall architecture, it is important to consider high availability. This can become complicated due to the nature of stateful firewalls. Since session state is maintained for each connection, it can be difficult to deploy an active/active configuration, especially as your infrastructure expands multiple Availability Zones.

AWS best practice is to test out your architecture before deployment to ensure that you can obtain a suitable failover threshold. Further, it is also important to test throughput to ensure that the architecture can meet your performance requirements.

Conclusion

The AWS Marketplace has an extensive selection of third-party firewall appliances that our customers can use to meet their regulatory and security compliance requirements.

In this blog post, I covered common implementation methodologies. There is more to come! Future posts with deep dives on integrating specific architectures outlined in this post.