How do I secure egress and ingress traffic to my Transit Spoke VPCs and where do I put a cloud-based firewall like Palo Alto Networks VM-series?

As you grow your VPC spokes in a transit network, the security of the workloads in those spokes needs to be addressed. According to the AWS shared responsibility model, the security of the instances and their workloads is yours, lucky you! Handling security for a couple of VPCs tends to be fairly straightforward, but once you have many VPCs in a transit network with on-prem connections…it’s complicated. So, what are your options for securing the egress and ingress traffic and how do you do this with Aviatrix?

Let’s start with the ingress.

This refers to Internet traffic which can reach your VPC(s). If this isn’t needed, it’s easy to simply have all the instances use only private IPs so they’re not reachable and thus secure. But sometimes you do need to allow Internet traffic and don’t want everything to hairpin thru your datacenter. For ingress traffic direct to your VPCs, AWS provides a couple solutions:

1. AWS WAF is a web application firewall that helps protect your web applications from common web exploits
2. AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards web applications running on AWS

For deep packet inspection, that would need to be addressed by a next-generation firewall (NGFW), like the Palo Alto Networks VM-Series.

What about the egress traffic?

There are many reasons why applications within VPCs need Internet access. The reasons range from getting basic software updates from Microsoft, Google or Ubuntu to needing application access to another third party or SaaS service over the Internet. So, this is a common situation that you probably cannot ignore. Though you don’t want your applications reaching out to just anywhere on the Internet. Most start by blocking all traffic and then “opening” up to specific trusted locations. You have a couple of options here:

Trombone Option 1: Egress through your datacenter

This treats AWS as another datacenter or remote site to your primary datacenter. Forcing packets to go on-prem to access the Internet introduces latency and cost. But if you’re looking to be “cloud first” then we suggest other options.

Cloud Option 2: Per-VPC Spoke Security

AWS provides a NAT service gateway. It has limited security rules which provides filtering of traffic, but it is implemented via specified IP addresses only. The IP address list is limited to 250 per NAT service gateway. This could be an issue as common services tend to have many IP addresses associated and it can be tedious to figure out all of them (e.g. Office365). Filtering based on fully-qualified domain names (FQDN) would address this limitation. Depending on the number of VPCs, it’s important to consider both the cost of a pair (for high availability) of virtual firewalls per VPC and the management of those policies.

On the cost side, most full-featured virtual firewalls usually run on pairs of c4.large or larger instances, this can become a prohibitive cost over time. The Aviatrix solution provides light-weight FQDN features that can run on a pair of t2.micro instances. This makes the Aviatrix solution to be a fraction of the cost of a full-featured firewall and associated instance charges:

Not only does the Aviatrix FQDN software have a much lower cost than a full-featured firewall, the management is also much easier with a centralized controller to deploy the solution in each VPC. As VPCs may have different policies (dev, prod, staging, etc. can have different needs and rules), the policy sets can be created centrally and even automated. Audit logs are also centralized.

Screenshot of Aviatrix FQDN central console:

While we recommend a distributed solution using Aviatrix FQDN egress filtering, if a full-function firewall is needed then we recommend a Share Security Service VPC in the next option.

Cloud Option 3: Shared Security Service VPC

Your customer facing production VPC may need higher levels of security in the form of a next-generation firewall for DPI, IDS, and IPS. VDI services like AWS Workspaces could also fall into this category. One approach would be to deploy a firewall in each VPC which this requirement. That approach can become quite expensive as these firewalls usually run on a c4.large or larger instance type and are typically configured in pairs for high availability.

Instead of placing a firewall in each VPC, this approach sends all egress traffic from those VPCs to one global Shared Security VPC or multiple regional Shared Security VPCs.

There are many benefits of this approach, 1) you’ll have fewer firewalls to purchase and 2) you can split off the traffic going to the Internet, reducing your firewall size requirements both in the Shared Security VPC or on-prem.

Keep in mind though, unless you have consistent policies for all traffic, you’ll need to consider the management of different policies per VPC. That management can quickly become complex if there are many policy sets based on the type of VPC (or application group) that is sending the traffic.

Here’s a diagram of this approach using Aviatrix & Palo Alto Networks VM-Series firewall:

This diagram shows a global transit hub design where the 2 rightmost VPCs need next-generation firewall capability. The instances in those VPCs is routed to the Security Service VPC before egressing to the Internet.

This article covered the ingress and egress of traffic. The three other traffic patterns you need to consider are:

• Spoke to On-premises traffic
• Spoke to Spoke traffic
• User Access to the Spoke VPCs