AWS Compute Blog
Implementing network traffic inspection on AWS Outposts rack
This blog post is written by Brian Daugherty, Principal Solutions Architect. Enrico Liguori, Solution Architect, Networking. Sedji Gaouaou, Senior Solution Architect, Hybrid Cloud.
Network traffic inspection on AWS Outposts rack is a crucial aspect of making sure of security and compliance within your on-premises environment. With network traffic inspection, you can gain visibility into the data flowing in and out of your Outposts rack environment, enabling you to detect and mitigate potential threats proactively.
By deploying AWS partner solutions on Outposts rack, you can take advantage of their expertise and specialized capabilities to gain insights into network traffic patterns, identify and mitigate threats, and help ensure compliance with industry-specific regulations and standards. This includes advanced network traffic inspection capabilities, such as deep packet inspection, intrusion detection and prevention, application-level firewalling, and advanced threat detection.
This post presents an example architecture of deploying a firewall appliance on an Outposts rack to perform on-premises to Virtual Private Cloud (VPC) and VPC-to-VPC inline traffic inspection.
Architecture
The example traffic inspection architecture illustrated in the following diagram is built using a common Outposts rack deployment pattern.
In this example, an Outpost rack is deployed on premises to support:
- Manufacturing/operational technologies (OT) applications that need low latency between OT servers and devices
- Information technology (IT) applications that are subject to strict data residency and data protection policies
Separate VPCs, that can be owned by different AWS accounts, and subnets are created for the IT and OT departments’ instances (see 1 and 2 in the diagram).
Organizational security policies require that traffic flowing to and from the Outpost and the site, and between VPCs on the Outpost, be inspected, controlled, and logged using a centralized firewall.
In an AWS Region it is possible to implement a centralized traffic inspection architecture using routing services such as AWS Transit Gateways (TGW) or Gateway Load Balancers (GWLB) to route traffic to a central firewall, but these services are not available on Outposts.
On Outposts, some use the Local Gateway (LGW) to implement a distributed traffic inspection architecture with firewalls deployed in each VPC, but this can be operationally complex and cost prohibitive.
In this post, you will learn how to use a recently introduced feature – Multi-VPC Elastic Network Interface (ENI) Attachments – to create a centralized traffic inspection architecture on Outposts. Using Multi-VPC ENI Attachments you can attach ENIs to Amazon Elastic Compute Cloud (EC2) instances which have been created in different VPCs and subnets. Even ENIs created in subnets that have been shared from other AWS accounts using AWS Resource Access Manager can be attached using this feature.
Specifically, you can create ENIs in the IT and OT subnets that can be shared with a centralized firewall (see 3 and 4).
Because it a best practice to minimize the attack surface of a centralized firewall through isolation, the example includes a VPC and subnet created solely for the firewall instance (see 5).
To protect traffic flowing to and from the IT, OT, and firewall VPCs and on-premises networks, another ‘Exposed’ VPC, subnet (see 6), and ENI (see 7) are created. These are the only resources associated with the Outposts Local Gateway (LGW) and ‘exposed’ to on-premises networks.
In the example, traffic is routed from the IT and OT VPCs using a default route that points to the ENI used by the firewall (see 8 and 9). The firewall can route traffic back to the IT and OT VPCs, as allowed by policy, through its directly connected interfaces.
The firewall uses a route for the on-premises network (192.168.30.0/24) – or a default route – pointing to the gateway associated with the exposed ENI (eni11, 172.16.2.1 – see 10).
To complete the routing between the IT, OT, and firewall VPCs and the on-premises networks, static routes are added to the LGW route table pointing to the firewall’s exposed ENI as the next hop (see 11).
Once these static routes are inserted, the Outposts Ingress Routing feature will trigger the routes to be advertised toward the on-premises layer-3 switch using BGP.
Likewise, the on-premises layer-3 switch will advertise a route (see 12) for 192.168.30.0/24 (or a default route) over BGP to the LGW, completing end-to-end routing between on-premises networks and the IT and OT VPCs through the centralized firewall.
The following diagram shows an example of packet flow between an on-premises OT device and an OT server, and between the OT and IT instances, with both flows being inspected by the firewall:
Implementation on AWS Outposts rack
The following implementation details are essential for our example traffic inspection on the Outposts rack architecture.
Prerequisites
The following prerequisites are required:
- Deployment of an Outpost on premises;
- Creation of four VPCs – Exposed, firewall, IT, and OT;
- Creation of private subnets in each of the four VPCs where ENIs and instances can be created;
- Creation of ENIs in each of the four private subnets for attachment to the firewall instance (keep track of the ENI IDs);
- If needed, sharing the subnets and ENIs with the firewall account, using AWS Resource Access Manager (AWS RAM);
- Association of the Exposed VPC to the LGW.
Firewall selection and sizing
Although in this post a basic Linux instance is deployed and configured as the firewall, in the Network Security section of the AWS Marketplace, you can find several sophisticated, powerful, and manageable AWS Partner solutions that perform deep packet inspection.
Most network security marketplace offerings provide guidance on capabilities and expected performance and pricing for specific appliance instance sizes.
Firewall instance selection
Currently, an Outpost rack can be configured with EC2 instances in the M5, C5, R5, and G4dn families. As a user, you can select the size and number of instances available on an Outpost to match your requirements.
When selecting an EC2 instance for use as a centralized firewall it is important to consider the following:
- Performance recommendations for instance types and sizes made by the firewall appliance partner;
- The number of VPCs that are inspected by the firewall appliance;
- The availability of instances on the Outpost.
For example, after evaluating the partner recommendations you may determine that an instance size of c5.large, r5.large, or larger provide the required performance.
Next, you can use the following AWS Command Line Interface (AWS CLI) command to identify the EC2 instances configured on an Outpost:
The output of this command lists the instance types and sizes configured on your Outpost:
With knowledge of the instance types and sizes installed on your Outpost, you can now determine if any of these are available. The following AWS CLI command – one for each of the preceding instance types – lists the number of each instance type and size available for use. For example:
This command returns:
The output indicates that there are (on average) two c5.xlarge instances available on this Outpost in the specified time period (1 hour). The same steps for the other instance type suggest that there are also two c5.4xlarge, two r5.2xlarge, and no r5.4xlarge available.
Next, consider the number of VPCs to be connected to the firewall and determine if the instances available support the required number of ENIs.
The firewall requires an ENI in its own VPC, in the Exposed VPC, and one for each additional VPC. In this post, because there is a VPC for IT and for OT, you need an EC2 instance that supports four interfaces in total:
To determine the number of supported interfaces for each available instance type and size, let’s use the AWS CLI:
This returns:
The output suggests that the three available EC2 instances (r5.2xlarge, c5.xlarge and c5.4xlarge) can support four network interfaces. The output also suggests that the c5.4xlarge instance, for example, supports up to 8 network interfaces and a maximum bandwidth of 10Gb/s. This helps you plan for the potential growth in network requirements.
Attaching remote ENIs to the firewall instance
With the firewall instance deployed in the firewall VPC, the next step is to attach the remote ENIs created previously in the Exposed, OT, and IT subnets. Using the firewall instance ID and the Network Interface IDs for each of the remote ENIs, you can create the Multi-VPC Attached ENIs to connect the firewall to the other VPCs. Each attached interface needs a unique device-index greater than ‘0’ which is the primary instance interface.
For example, to connect the Exposed VPC ENI:
Attach the OT and IT ENIs while incrementing the device-index and using the respective unique ENI IDs:
After attaching each remote ENI, the firewall instance now has an interface and IP address in each VPC used in this example architecture:
Updating the VPC/subnet route tables
You can now add the routes needed to allow traffic to be inspected to flow through the firewall.
For example, the OT subnet (10.242.0.0/24) uses a route table with the ID rtb- abcdefgh123456789. To send the traffic through the firewall, you need to add a default route with the target being the ENI (eni-07957a9f294fdbf5d) that is now attached to the firewall:
You can follow the same process is used to add a default route to the IT VPC/subnet.
With routing established from the IT and OT VPCs to the firewall, you need to make sure that the firewall uses the Exposed VPC to route traffic toward the on-premises network 192.168.30.0/24. This is done by adding a route within the firewall OS using the VPC gateway as a next hop.
The ENI attached to the firewall from the Exposed VPC is in subnet 172.16.2.0/28, and the gateway used by this subnet is, by Amazon Virtual Private Cloud (VPC) convention, the first address in the subnet – 172.16.2.1. This is used when updating the firewall OS route table:
You can now confirm that the firewall OS has routes to each attached subnet and to the on-premises subnet:
The final step in establishing end-to-end routing is to make sure that the LGW route table contains static routes for the firewall, IT, and OT VPCs. These routes target the ENIs used by the firewall in the Exposed VPC.
After gathering the LGW Route Table ID and the firewall’s Exposed ENI ID used by the firewall, you can now add routes toward the firewall VPC:
Repeat this command for the OT and IT VPC CIDRs – 10.242.0.0/16 and 10.244.0.0/16, respectively.
You can query the LGW route table to make sure that each of the static routes was inserted:
This returns:
With the addition of these static routes the LGW begins to advertise reachability to the firewall, OT, and IT Classless Inter-Domain Routing (CIDR) blocks over the BGP neighborship. The CIDR for the Exposed VPC is already advertised because it is associated directly to the LGW.
The firewall now has full visibility of the traffic and can apply the monitoring, inspection, and security profiles defined by your organization.
Other considerations
- It is important to follow the best practices specified by the Firewall Appliance Partner to fully secure the appliance. In the example architecture, access to the firewall console is restricted to AWS Session Manager.
- The commands used previously to create/update the Outpost/LGW route tables need an account with full privileges to administer the Outpost.
Fault tolerance
As a crucial component of the infrastructure, the firewall instance needs a mechanism for automatic recovery from failures. One effective approach is to deploy the firewall instances within an Auto Scaling group, which can automatically replace unhealthy instances with new, healthy ones. In addition, using host or rack level spread placement group makes sure that your instances are deployed on distinct underlying hardware. This enables high availability and minimizes downtime. Furthermore, this approach based on Auto Scaling can be implemented regardless of the specific third-party product used.
To ensure a seamless transition when Auto Scaling replaces an unhealthy firewall instance, it is essential that the multi-VPC ENIs responsible for receiving and forwarding traffic are automatically attached to the new instance. When re-using the same multi-VPC ENIs, make sure that no changes are required in the subnets and LGW route tables.
To re-attach the same multi-VPC ENIs to the new instance, you can do this using Auto Scaling lifecycle hooks, with which you can pause the instance replacement process and perform custom actions.
After re-attaching the multi-VPC ENIs to the instance, the last step is to restore the configuration of the firewall from a backup.
Conclusion
In this post, you have learned how to implement on-premises to VPC and VPC-to-VPC inline traffic inspection on Outposts rack with a centralized firewall deployment. This architecture requires a VPC for the firewall instance itself, an Exposed VPC connecting to your on-premises network, and one or more VPCs for your workloads running on the Outpost. You can either use a basic Linux instance as a router, or choose from the advanced AWS Partner solutions in the Network Security section of the AWS Marketplace and follow the respective guidance on firewall instance selection. With multi-VPC ENI attachments, you can create network traffic routing between VPCs and forward traffic to the centralized firewall for inspection. In addition, you can use Auto Scaling groups, spread placement groups, and Auto Scaling lifecycle hooks to enable high availability and fault tolerance for your firewall instance.
If you want to learn more about network security on AWS, visit: Network Security on AWS.