AWS Improves Security Options With VPC Ingress Routing

Amazon Web Services (AWS) has provided its customers with better options for Virtual Private Cloud (VPC) ingress routing. Customers will have to consider which works best for their needs.

Amazon’s VPC is a software-defined networking service that allows customers to build virtual data centers in the cloud, controlling traffic through a combination of virtual firewalls such as stateful security groups and stateless network access control lists (NACLs).

Security group and NACL rules are powerful forms of controlling traffic, but don’t provide packet inspection to analyze traffic or to detect or thwart attacks that fall within the defined routing rules. This is where ingress routing comes in.

VPC ingress routing allows customers to improve their security posture by routing all traffic within the VPC through a firewall appliance running on a virtual machine in the VPC. The firewall appliance can drop packets of any attacks it detects. Customers can choose their tool from the options on AWS marketplace or even design and build their own custom solution.

Prior to support for VPC ingress routing, many customers would route traffic from the VPC back to their on-premises firewall solutions that enforced their networking controls, leading to additional overhead and latency. Running firewall appliances as virtual machines within AWS’s datacenters is clearly a better approach.

What happens if a customer has multiple VPCs? They could run a firewall appliance within each VPC, but this would require additional costs and overhead. AWS’s recommended solution is to route traffic from private VPCs (VPCs within no routes to internet gateways) to an internet-connected VPC in which the customer runs their firewall appliances.

Customers can route this traffic using an AWS transit gateway, which is a fully managed router allowing for hub-and-spoke connectivity between VPCs in the same region, simplifying management and administration of networking across the customer’s cloud and on-premises infrastructure.

Source: AWS Online Tech Talks, YouTube, Feb. 26, 2020

For ingress routing for internet-destined traffic, customers configure the networking of each VPC to route through the transit gateway by means of a VPC attachment. Internet-destined traffic goes to the internet-facing VPC in which the customer runs their firewall appliances.

Customers have three options to run highly available firewalls for ingress routing: VPC attachments, VPN attachments, and forward proxies. Each has advantages and disadvantages

VPC Attachment Model

In the VPC attachment model, the internet-facing VPC to which the others route contains an internet gateway and two firewall appliances, each in a different subnet. The transit gateway has an elastic network interface (ENI, virtual network card) and an IP in each of the two subnets, each of which is in a separate availability zone (AZ).

Traffic can arrive in either AZ, to either interface. The VPC routes all its traffic to the transit gateway, and the transit gateway sends internet traffic to the VPC containing the firewall appliances. There is a return path to the non-internet-facing VPCs in which the customer runs their workloads.

The main drawback to this architecture is that AWS users need to apply some customization to achieve automatic failover for high availability. If one of the firewalls goes down, this setup will black hole the traffic because of how the route table is configured in the internet-facing VPC. Customers must create a script for failover, which would usually work by automatically updating the route table if one of the firewalls goes down.

VPN Attachment Model

In this setup, instead of using a native attachment to the VPC, users run site-to-site VPN from the transit gateway to each firewall appliance. The VPNs run a routing protocol, so this solution has the advantage of built-in automatic failover, unlike the VPC attachment setup.

The disadvantage of using VPN is that encryption may have a performance impact. Because of the overhead involved in encrypting the traffic, site-to-site VPN will likely not be able to handle as much traffic as the VPC attachment model.

Forward Proxy Model

In the forward proxy model, we set up proxies that we make highly available through the use of a network load balancer on the front end of an auto-scaling group of virtual machines. If one of the virtual machines fails its health check, the load balancer stops forwarding traffic to it. All our connections go to the proxy IP range, and we configure our instances to use the proxy when sending traffic to external sources.

The proxy terminates the connection and initiates another connection out to the internet from its own IP. The proxy model makes it much easier to deal with decrypting traffic and allows for inspection of the encrypted traffic connecting to the proxies.

The main downside with this solution is that the proxy must be configured on all the clients. Every client instance that goes out to the internet must have the proxy configuration, so the forward proxy model requires more configuration to set up than the VPC attachment or VPN attachment architectures.

Our Take

AWS’s transit gateway solution to provide hub-and-spoke connectivity between VPCs and connections back to on-prem provides a great networking solution for its customers. Prior to the transit gateway, customers had to rely on one-to-one peering between VPCs, with no support for transitive peering, and each VPC would require its own internet, VPN, or AWS Direct Connect connection back to the corporate data center (due to a lack of support for edge routing using VPC peering).

All the same, we can see that with three different options, all requiring different degrees of configuration and employing third-party solutions from AWS marketplace, this is clearly an evolving space in which AWS is focusing on releasing new features and services to address the needs of its customers.

Info-Tech expects that AWS will focus on expanding and changing support for this area of its cloud services. Customers should expect to see significant changes in the near-term future to available features and capabilities for ingress routing and for firewall appliances and networking across multiple VPCs and on prem environments.

AWS may work to develop its own firewall solution in the future based on open-source technology, in order to compete with the third-party firewall solutions currently available through AWS Marketplace.