Centralized outbound inspection architecture in AWS Cloud WAN

AWS Cloud WAN helps you build a unified network that connects your cloud and on-premises environments. To help secure these networks, organizations use next-generation firewalls (NGFW) and intrusion prevention systems (IPS) as part of a defense in depth strategy. In this post, we describe architectural patterns for centrally managing and inspecting outbound network traffic from AWS workloads in a Cloud WAN network (also called north-south inspection). We go into the details on how to build for both single-Region and multi-Region networks, and how to configure the route tables for each. These architectures can help to ensure that your data and applications remain safe while maintaining a secure cloud environment.

Overview of the solution

The key building blocks of this solution are Cloud WAN and Amazon Virtual Private Clouds (Amazon VPCs). In the role of NGFW or IPS, we use AWS Network Firewall—but other options are available. These include third-party virtual appliances used with Gateway Load Balancer (GWLB). The same architectural patterns apply to both approaches.

Cloud WAN is a managed wide area networking (WAN) service that helps you build, manage, and monitor a unified global network connecting resources running across your cloud and on-premises environments. It provides a central dashboard where you can connect on-premises branch offices, data centers, and Amazon VPCs across the AWS global network.

To get the most out of this post, you must understand some of the fundamental organizing concepts used by Cloud WAN. In particular, you should be familiar with:

• Global networks
• Core networks
• Core network policy
• Attachments
• Core Network Edge
• Network segments

Check the Cloud WAN documentation to learn more about Cloud WAN concepts. The Introducing AWS Cloud WAN blog post also provides a great overview of these concepts in action.

Solution overview

In this post, we will discuss filtering and inspecting egress traffic to the internet, also known as north-south traffic. (Filtering and inspecting traffic within an Amazon VPC or in transit between Amazon VPCs, also known as east-west traffic, is a valid use case, but not discussed here.)

To keep the latency low and to optimize the costs involved with moving traffic across Regions, we recommend keeping your egress traffic within the Region where your resources are deployed. Even though Cloud WAN runs globally, Network Firewall and GWLB instances are deployed within a Region.

Aside: If you are not familiar with data transfer costs, the Overview of Data Transfer Costs for Common Architectures blog post is an excellent introduction.

As we noted earlier, we use Network Firewall in the examples that follow, but the same architecture pattern works when using GWLB along with a supported virtual appliance—just replace Network Firewall with a GWLB endpoint. Under the hood, the Network Firewall endpoint is powered by GWLB, so the Elastic Network Interface (ENI) of the Network Firewall endpoint is of the “gateway_load_balancer_endpoint” type.

Centralized Outbound – Inspection for a production workload in a single AWS Region

The diagram that follows (figure 1) shows a single-Region workload. We have deployed a Cloud WAN Core Network with one Core Network Edge and two network segments, Production and Security. We have also deployed Amazon VPCs named PROD VPC and an Outbound Inspection VPC. These are connected to the Core Network as VPC attachments. The PROD VPC has a workload deployed in two Availability Zones (AZ). We deployed Network Firewall in the Outbound Inspection VPC, with an endpoint in each AZ.

The traffic from PROD VPC goes through the Cloud WAN Core Network to reach the Outbound Inspection VPC where a Network Firewall endpoint filters the traffic before sending it on to a NAT Gateway and then to Internet Gateway (IGW).

Figure 1: Centralized Outbound Inspection for the production workload in a single AWS Region

Now let’s go through the packet flow and look at how traffic from the PROD VPC is routed by the Cloud WAN Core Network, inspected, and egresses to the internet. Detailed Traffic Flow—Outbound and Return (Traffic originates from the Amazon Elastic Compute Cloud (Amazon EC2) instance in PROD VPC and with destination as IGW).

A. Packet leaves the EC2 instance using its Elastic Network Interface (ENI). It travels toward the Cloud WAN Core Network ENI in the PROD VPC private subnet of the PROD VPC and arrives in Production Segment of Cloud WAN Core Network.

B. The Packet leaves the Production Segment of the Cloud WAN Core Network and reaches to the ENI in the Core Network subnet in the Outbound Inspection VPC.

C. The Core Network ENI in the Outbound Inspection VPC forwards packet to the Network Firewall endpoint.

D. The Network Firewall endpoint forwards the packet to a NAT Gateway.

E. NAT Gateway forwards the packet to an Internet Gateway (IGW).

F. When returning, the IGW sends the packet back to the NAT Gateway in the same AZ where the traffic originated.

G. The NAT Gateway sends the packet back to the Network Firewall endpoint.

H. The Network Firewall endpoint sends the packet back to the Core Network ENI in the Outbound Inspection VPC.

I. The Core Network ENI in the Outbound Inspection VPC sends the packet back to the Security Segment of the Cloud WAN Core Network.

J. The Security Segment sends the packet back to the Core Network ENI in the PROD VPC, and then back to EC2 instance.

To build this setup, you must create a Cloud WAN Core Network with one edge location and two network segments: one for Production and one for Security (for details refer to the How to create a segment in AWS Cloud WAN documentation).

Share the Production segment with the Security segment. Then attach the PROD and Outbound Inspection VPCs as VPC attachments to the Cloud WAN Core Network Production and Security segments respectively (refer to the How to create attachments in AWS Cloud WAN documentation). Then, follow these steps to update the route tables:

1. Update the PROD VPC route table and add a route for 0.0.0/0 with the destination as the Core network.
2. Once the Security network segment is shared with the Production segment, routes for these segments are propagated automatically.
3. Update the core network policy to add a Static route (How to add Static route) for the Production segment with the destination CIDR block as 0.0.0/0. Choose Outbound Inspection VPC attachment. This will add a static route in the Production segment for 0.0.0.0/0 with the destination as the Outbound Inspection VPC attachment.
4. Under Outbound Inspection VPC, update the core network subnet Route Table with a route for 0.0.0/0 with the destination as Network Firewall endpoint in respective AZ.
5. Under Outbound Inspection VPC, update the Network Firewall subnet Route Table with two routes, one for 0.0.0/0 with the destination as NAT Gateway in the same AZ and the other for 10.1.0.0/16 with the destination as core network in the same AZ.
6. Under Outbound Inspection VPC, update the NAT Gateway subnet Route Table with two routes, one for 0.0.0/0 with the destination as Internet Gateway and other for 10.1.0.0/16 with destination as the Network Firewall endpoint in the same AZ.

This architecture can be scaled to add more network segments in your Cloud WAN Core Network, as shown in the following diagram (figure 2). For inspecting egress traffic from multiple segments in your Core Network, you can use the same security segment for all egress traffic from all segments, and the same architectural pattern applies. The following diagram shows how outbound traffic from two segments, Production and QA, can use the same Security segment.

Figure 2: Centralized Outbound Inspection for production and QA workload in a single AWS Region

Centralized Outbound – Inspection for production workload in multiple AWS Regions

The diagram that follows (Figure 3) shows the setup for a multi-Region workload. Here we deployed a Cloud WAN Core Network with two edge locations. PROD VPCs and Outbound Inspection VPCs are attached to the Cloud WAN Core Network as VPC attachments. PROD VPCs have a workload deployed in two AZs. Network Firewall is deployed in Outbound Inspection VPCs with an endpoint in each AZ to inspect traffic for the corresponding AZ.

Figure 3: Centralized Outbound Inspection for production workload in multiple AWS Regions

To build this setup, you must create a Cloud WAN Core Network with two edge locations and two network segments: one for the Production workload and one for the Security segment (as before, the How to create a segment in AWS Cloud WAN documentation is helpful).

Share the Production segment with the Security segment. Attach PROD and Outbound Inspection VPCs as VPC attachments to the Cloud WAN Core Network Production and Security segments respectively (as before, the How to create attachments in AWS Cloud WAN documentation is helpful).

We update our route tables using the same steps mentioned under single-Region architecture. The only difference for the multi-Region architecture is to select both the Region 1 and Region 2 Outbound Inspection VPC while adding a Static route in the Production network segment.

Traffic flow is the same as what we used in the single-Region architecture, and traffic remains in the same Region where it originated. Even though the PROD segment has a route 0.0.0.0/0 pointing to two different Outbound Inspection VPCs in different Regions, Cloud WAN will choose the one in the local Region. For example, traffic originating from PROD VPC Region-1 will remain in Region-1 and is inspected by the Region-1 Outbound Inspection VPC, while Region-2 traffic is inspected by the Region-2 Outbound Inspection VPC.

If the Production Segment has the route 0.0.0.0/0 pointing to the Outbound Inspection VPC only in one Region, let’s say Region 1, then traffic originating from PROD VPC in Region 1 and Region 2 is inspected by the Region 1 Outbound Inspection VPC. Note that there will be added latency depending on the physical distance between Regions.

Considerations

Consider the following before implementing this solution:

• To configure routing on Cloud WAN network segments, you must use core network policies not covered in this post. To learn more about how Network policies work, refer to our Create a core network policy version documentation or the Introducing AWS Cloud WAN
• Although Network Firewall is represented by a single firewall endpoint per subnet/AZ in our diagram, it is highly available and based on AWS Hyperplane.  No single component failure of Network Firewall would cause an AZ failure.

Conclusion

In this blog post, we showed you how to implement a centralized outbound inspection architecture in AWS Cloud WAN in single Region and multi-Region using an AWS managed service, AWS Network Firewall. The same architecture can be used to scale to multiple VPCs in the same Region. Also, you can replace AWS Network firewall with Gateway Load Balancer and your preferred Security Appliance if you prefer.