Designing cloud infrastructures that include security appliances for traffic inspection is easier following Amazon's introduction of a feature called VPC Ingress Routing. In this article and accompanying video, I'll examine the feature and how you can use it to force inbound traffic though security appliances.

Companies that operate in highly regulated environments frequently require security appliances to meet compliance requirements. These appliances might take the form of firewalls, intrusion prevention systems (IPS) and intrusion detection systems (IDS). The AWS Marketplace has a variety of appliances you can choose from.

Prior to VPC ingress routing, there were several models for traffic inspection for a service intended for the public Internet. The first--which I've covered in a previous post--uses Elastic IPs attached to the appliances. Your service is implemented on EC2 instances in the private subnets. Traffic is "drawn" into the VPC with the two EIPs. Here is a diagram.

The firewalls may perform a NAT function is routing symmetry is needed. Otherwise, return traffic will go directly to the Internet Gateway (IGW).

This architecture does not scale as it relies on EIPs, which are limited to five per region. While this limit can be increased, I advise against building a service that relies on EIPs. There are better design such as the load balancer sandwich. Check out Palo Alto Network's reference design for more details.

If you're like me, you may get the impression that using these appliances designed for the data center can feel like "going against the grain" of cloud. I think was definitely true in the early days of the VPC. AWS's introduction of VPC ingress routing in 2019 and its more recent launch of Gateway Load Balancing are significant improvements.

What functionality does VPC ingress routing provide and how does it help in the integration of security appliances? Using VPC ingress routing, we can launch our instances in the private subnet using ephemeral public IPs. Note that these are not EIPs. This fact alone improves the scaling properties of the design.

Using public IPs in private subnets may seem counterintuitive. How does traffic from the Internet get routed to the EC2 instances that power your service? The "secret sauce" is the ability to associate a routing table with the IGW. On ingress, the IGW translates the public IP to the private IP in the VPC, this is always the case and isn't specific to VPC ingress routing. What's different in this scenario is that the destinations for the private subnet prefixes are the Elastic Network Interfaces (ENI) of the security appliances. Let's go to the diagram!

The routing table depicted is linked to the IGW using what AWS calls an "edge association." This is how inbound traffic is forced to traverse the security appliance.

Here's how this looks in the AWS console.

Now we can launch multiple services in the private subnets without being limited by the number of EIPs per region.

That's VPC ingress routing in a nutshell. The feature is designed for a very specific use case that may be applicable to your workloads if you need to inspect North-South traffic for service offered to the public Internet.

Check out the video version of this blog post on the YouTube.