Deployment models for AWS Network Firewall with VPC routing enhancements

Introduction

Amazon Virtual Private Cloud (VPC) is a logically isolated virtual network. It has inbuilt network security controls and implicit routing between VPC subnets by design. Network security controls such as security groups (SGs) and network access control lists (ACLs) provide you with options to control network traffic. However these controls operate at network and transport layers of OSI model, and filter traffic based on IP addresses, transport protocols, and ports. You may have additional requirements to have network security controls at application layer. As an example, application protocol detection and filtering based on application protocol properties such as HTTP headers and TLS version. Previously, you could implement such control with AWS Network Firewall in select deployment models as per part 1 of “Deployment models for AWS Network Firewall”. With a recent enhancement to VPC routing primitives, you can insert AWS Network Firewall between workloads in different subnets of the same VPC. In this blog post, we will review how the enhancement helps a middlebox insertion based on AWS Network Firewall example, and also available deployment models.

VPC routing enhancements

With the launch of VPC routing enhancements, you now have additional agility, programmability, and control over the forwarding path of VPC traffic. VPC has an implicit router and route tables are pre-configured with a local route, a default route for communication within the VPC. By default, any traffic from a source within a VPC destined to a target within the same VPC is covered by the local route and therefore directly routed. The enhancement allows you to configure more specific routes at a subnet route table level or replace target for the “local” destination with a middlebox such as firewall endpoint. The key use case is insertion of a middlebox between two subnets for inter-subnet traffic (east-west) inspection. For example, you can create routing rules to send all traffic from a subnet to a network firewall endpoint when the destination is a specific subnet as per figure 1.

Figure 1: Traffic from subnet A to subnet B is sent via firewall endpoint, return traffic path is via the same endpoint

A couple of noteworthy items to clear upfront about any middlebox insertion described in figure 1:

• For communication to work, SGs and network ACLs must allow traffic in addition to the middlebox itself. The flow from a source in subnet A to destination in subnet B is effectively broken into two parts, source to middlebox, and middlebox to destination flows. With such configuration, workloads cannot use SG referencing to allow traffic through the firewall endpoint as a middle box.
• Traffic return-path must be symmetric. Asymmetric traffic will not be returned to source. Traffic symmetry can become complex in scenarios where traffic is crossing multiple availability zones (multi-AZ) and we will focus on it in the next section.

Routing strategy with multi-AZ deployments

When you build highly available applications on AWS, you can partition your application to run across multiple AZs. At AWS, we have a principle of keeping AZ independence (AZI) which means all packet flows stay within the Availability Zone rather than crossing boundaries. Network traffic is kept local to the AZ as per figure 2. In such scenario, it is easy to maintain traffic symmetry.

Figure 2: Traffic symmetry in multi-AZ deployments

There are however scenarios where traffic must cross AZ boundaries and it is critical to have a guiding principle on how to arrange your routes tables and corresponding routes. The principle is to keep the inter-AZ traffic inspection local to client’s AZ. With such a principle applied, you avoid unnecessary inter-AZ traffic cost in case traffic has to be dropped (as it drops closer to the client). In figure 3, you can see this principle in action with a load balancer sending traffic to application tier, and similarly an application tier sending traffic to a database.

Figure 3: inter-AZ traffic inspection local to client’s AZ
(click for larger image)

In the figure 3 example, an Application Load Balancer (ALB) enables you to offload TLS. Decrypted HTTP traffic is sent to backend application targets which could be in a different AZ enabling HTTP header and payload inspection. Following our principle, traffic from ALB to backend target is inspected in the same AZ as the client (ALB). The application in turn requires connectivity to the relational (main/active node) database. This traffic once again is processed closer to the client (application EC2 instance) and traffic is returned symmetrically.

Deployment models with VPC routing enhancements

Keeping in mind the guiding principle for traffic symmetry – let’s take a look at available deployment models using VPC routing enhancements:

1) AWS Network Firewall is deployed to protect traffic between two different subnets in the same VPC.

This model allows traffic inspection between two or more subnets within the same VPC. These subnets may reflect different application tiers and trust levels between workloads such as web tier (low trust), application tier (medium trust) and database tier (high trust) which requires policy enforcement using AWS Network Firewall. The model is suitable for architectures where additional traffic inspection is required and it resembles classic network segmentation as oppose to micro-segmentation more common to cloud native applications.

As shown in figure 4, in a single AZ deployment, you can implement this mode with three distinct subnet route tables. Public route table for incoming traffic from Internet Gateway towards a public workload such as web server or a load balancer. AWS Network Firewall endpoint is provisioned in its own subnet also known as “Firewall subnet” which also has a dedicated route table with the original local VPC route to send traffic to workloads in VPC. This ensures that traffic remains symmetric and both legs of the traffic are passed via AWS Network Firewall. Finally, private route table is associated with App subnet as well as DB subnet forwarding all traffic to Network Firewall endpoint in Firewall subnet.

Figure 4 : AWS Network Firewall deployed in Single AZ to protect traffic between multiple subnets

This model can be further expanded to include multi-AZ deployments which are following AZI principles as shown in figure 5 below. Depending on how many availability zones are used, this would require two unique subnet route tables as well as a common firewall subnet route table between all availability zones.

Figure 5: AWS Network Firewall deployed in Multi-AZs with AZ Independent workloads
(click for larger image)

Workloads which are dependent on resources in other availability zones should follow the routing principle outlined in the routing strategy with multi-AZ deployments section. It ensures that traffic is symmetric and inspected close to the client as shown in figure 3.

2) AWS Network Firewall deployed to protect traffic between a workload private subnet and NAT gateway

With this deployment model, traffic sourced in private subnet towards internet is inspected. Prior to the ability to override local routes in subnet route tables, AWS Network Firewall could only be placed between internet gateway and NAT gateway which obscured the source IP addresses of workloads.

With VPC routing enhancements, now we are able to place Network Firewall between private workloads and NAT gateway by replacing target of the “local” route with the firewall endpoint in public subnet route table. This allows us to have complete visibility of IP addresses of the workloads which further allows you to build 5-tuple rules.

Figure 6: AWS Network Firewall deployed in between NAT gateway and private workloads

For multi-AZ deployments of this model, each availability zone requires three unique subnet route tables for each subnet i.e. public, private and firewall as shown in figure 7. This ensures traffic is symmetric and remains within the originating availability zone.

Figure 7: AWS Network Firewall deployed in between NAT gateway and private workloads for Multi-AZ deployments
(click for larger image)

3) AWS Network Firewall deployed to protect traffic from an ingress or shared services VPC to the rest of network connected via AWS Transit Gateway 

In this deployment model, traffic from an ingress VPC can be inspected and filtered before it enters the rest of the network connected via AWS Transit Gateway e.g. other VPCs, on-premises or branch offices.

For ingress purpose, you can use ALB or NLB (Network Load Balancer) targeting workloads by IP addresses or any other self-managed reverse proxy solutions. The benefit is that traffic is inspected very early on the network before traversing your Transit Gateway to other parts of your network. This could be compelling for use cases where 3rd parties are accessing your workloads. The model also minimizes data processing cost as the traffic does not have to traverse in and out of Transit Gateway to an inspection VPC.

Figure 8: Ingress workloads and traffic to the rest of network is inspected using AWS Network Firewall
(click for larger image)

Similarly, another use case is shared services. AWS PrivateLink-enabled SaaS offerings can be hosted within the same VPC. Directory Services, Client VPN, hosted document management system are additional examples of shared services. Once again, you can avoid setting up a separate inspection VPC if all your care about is additional inspection for your shared services and you might be already using Transit Gateway route tables for network segmentation. Figure 9 below, shows an example for traffic from Transit Gateway entering shared services VPC and is being inspected/filtered by AWS Network Firewall.

Figure 9: AWS PrivateLink-enabled SaaS offering and shared service combined together and traffic from the rest of network is inspected (click for larger image)

For multi-AZ deployments, each AZ requires three unique subnet route tables as well as a common firewall subnet route table which allows the traffic to be symmetric.

An important change in this model is return routes configuration for traffic coming from AWS Transit Gateway and ensuring the symmetrical routing. Using the guiding principle discussed earlier in the blog, you can configure more specific routes in each Transit Gateway subnet route tables to ensure the traffic goes to local AWS Network Firewall endpoint where the destination belongs.

Figure 10: Multi-AZ ingress and shared service combined together and traffic to the rest of network is inspected
(click for larger image)

Shared VPC

With ability to create more specific routes or replace the destination of the local route, a VPC owner have additional options to inspect and secure traffic between shared subnets. VPC owner can effectively segregate VPC participants and only allow traffic as permitted by your security policy. You can find more information about Shared VPCs best practices and network segmentation in this blog post.

Considerations

• Use SGs and network ACLs where possible and implement inter-subnet (east-west) inspection only where necessary.
• Once a firewall endpoint (or any other middelbox) is inserted into your traffic flow, security group referencing cannot be used to allow source to connect to your destination. You can use IP addresses of your source in the security groups to permit the incoming traffic.
• Traffic between NLB and backends of instance target type does not follow VPC route table routes. If you want to inspect traffic between NLB and backends, use IP target type.
• When adding routes more specific than VPC CIDR, each route destination must match existing subnet CIDR.
• Network Firewall endpoint requires a dedicated subnet.
• You cannot inspect traffic coming from VPC peering.
• Deploying a large number of firewall endpoints in a distributed model and across many VPCs could be costly. Consider centralized deployment models for your firewall deployment or Shared VPCs.
• Default number of routes per route table is 50. You can increase it up to 1,000.
• Default number of firewalls per account per Region is 5. You can view more details on Network Firewall quotas and request a modification to these here.

Conclusion

AWS Network Firewall is an easy to deploy, transparent firewall, and IPS service which can be inserted to achieve desired network segmentation and application layer traffic filtering. With VPC routing enhancements, you can insert AWS Network Firewall between VPC subnets in a variety of deployment models. You have flexibility in selecting your network topology. Prior to VPC routing enhancement, you had to place workloads in different VPCs to perform East-West traffic inspection. After VPC routing enhancement, workloads in the same VPC and different subnets can have traffic flows inspected transparently by a middlebox such as AWS Network Firewall.