AWS CloudWAN Segmentation

Greg Swallow

Greg Swallow

— 2 min read
Share

We have several basic initiatives in front of us right now:

  • Remove obvious threats from Cloud WAN
  • Mitigate supply chain attacks on third party package repositories (e.g. npm)

But we also have some improvements we can capitalize on:

  • Improve east-west network security
  • Introduce Next-Generation Firewall capabilities on egress
  • Reduce the number of points of egress we have from our corporate network from hundreds to three per region
  • Proactive guard against sending traffic to rogue sites through DNS firewall

Just the first security concern led to about a dozen simple requests. An example: remove XXX's Sandbox VPC from Cloud WAN

First Snag

Immediately after telling the XXX team that I was going to detach their sandbox VPC from Cloud WAN, I realized two things would break: DNS and application deploys. Furthermore, Coworker and I have been talking about exposing individual services through VPC Lattice, so I created a spike issue in Linear to explore how I would be able to expose DNS to AWS accounts as a service. You can't.

Pivot?

Coworker and I had also talked a while about how we will need to segment our network to offer some services that don't play well with VPC Lattice (or Private Link, or through VPC Endpoint Services) to networks across our organization. But our production Cloud WAN has just one segment. The spike issue took on new meaning as I started to explore options: build a conceptual Cloud WAN that is broken down into multiple segments:

Domain Purpose
egress Contains a network firewall, NAT gateways, an Internet Gateway, Route 53 resolver endpoints, and DNS firewall rule groups
islands Intended for isolated workloads (e.g. sandbox accounts, to start)
workloads Intended for workloads we are not ready to isolate (e.g. an EKS cluster in VPC A may need to connect to a Pulsar cluster in VPC B)
sharedservices Intended for organization-wide network services, like Active Directory, FSx, EFS

Result?

This conceptual network offers multiple layers of security:

  • Egress reduction: three NAT Gateways per region, for the entire AWS organization, rather than at least three NAT gateways per region per AWS account. We have 130 AWS accounts.
  • East/West Layer 3 filtering using a network firewall between VPCs
  • The ability to filter egress traffic (North/South) using custom-built, or even AWS-managed rule groups
  • Layer 7 filtering, if we wish to take advantage of it
  • DNS firewalling, with one point of control
  • Flow logging
  • DNS query logging
  • The ability to use AWS-native security solutions, or to plug in third-party or even open-source network security appliances if we wish

Code

After building the network through various AWS consoles and chatting with ChatGPT in Codex, I asked ChatGPT:

can you create a terraform module in this directory based on the egress VPC,
including the network firewall, resolver endpoints, resolver rules, and the DNS firewall?  Make the CIDR blocks, region, and availability zones variables, and rename the private networks from "private" to "cloudwan."  Do not include any EC2 instances.

* author's note: we had plenty of context where I'd identified logical names of objects (e.g. "egress VPC) by IDs (e.g. vpc-xxxxx)

And it did. I haven't reviewed the code yet, but it's available at https://github.com/KAR-AUTO/ai-generated-egress-vpc. With approval, I plan to integrate it into our sre-tf-aws-vpc module. It's likely a light lift.

For now, see the next page: Segmented Cloud WAN: How It Works

Psst. I have a résumé, it's available here.

Read more