Segmented Cloud WAN: How It Works

Layer 3 Security
Two services are chiefly responsible for enforcing Layer 3 network security in this scenario: Cloud WAN's core network policy, which is documented after the break, and AWS Network Firewall.
Cloud WAN
If you look through the Cloud WAN core network policy, you'll see that we do a couple of things:
- Declare four segments: egress, workloads, islands, and sharedservices
- Isolate VPCs attached to all segments except the workloads segment
- Create static routes to 0.0.0.0/0 through the egress VPC's attachment to Cloud WAN in the following segments:
- workloads
- islands
- egress
- Share routes to connected VPCs between segments:
| Share from | To | Purpose |
|---|---|---|
| Egress | All | Give every network a path to the Internet, and to Route 53 resolver endpoints |
| Workloads | Every segment besides Islands | Provide return routes to the egress segment and shared services segment |
| Islands | Egress, Sharedservices | Provide return routes to the egress segment and shared services segment, maintain isolation |
| Sharedservices | All | Provide routes to shared services to all networks, and provide return routes to the egress segment, for DNS resolution only |
- Finally, we set up rules that automatically assign VPCs to segments based on a Cloud WAN attachment's resource tags. There may be an opportunity to set up a "default" rule that connects a VPC to the Islands segment.
Routing
In the diagram, above, you can see static routes to 0.0.0.0/0 in each VPC's private subnet routing tables, pointing towards Cloud WAN.
On Cloud WAN, each segment (besides the sharedservices segment) has a static route to 0.0.0.0/0, pointing to the egress VPC's attachment to Cloud WAN (the exit path).
In return, the firewall subnets in the egress VPC have static routes to 10.0.0.0/8 (and other non-routable space), pointing back to Cloud WAN.
Because Cloud WAN segments share routes with each other, a return packet destined for a machine in a workload VPC (10.0.8.87, for example) gets dropped back into the workload VPC, where the VPC's local route handles the last hop.
Accidental Transitive Routing
It's critical to realize that Cloud WAN does nothing to enforce network security. While it can shape routes across a software-defined wide area network, it's on us to actually filter traffic. I discovered this when testing to make sure VPCs were properly isolated: they aren't.

The reason for this is transitive routing. Initially, we didn't even have a firewall. When a packet destined for ANY IP address was dropped into the egress VPC because all of the default routes pointed that way, the egress VPC happily handed the packet back to Cloud WAN, since it had routes to all non-routable space in its routing tables.
Network Firewall
Enter AWS Network Firewall. This service provides Layer 3 through Layer 7 packet filtering at an hourly charge. It operates like many third party security solutions one may purchase on the AWS Marketplace, and while it does the job, we may find it worthwhile to investigate the most capable offering. All of these firewalls do one thing: you stand a Gateway Load Balancer in front of them, and you add routes through the resulting VPC endpoints. This forces traffic to go through your appliance.
Simplifying the first network diagram, we get this:

This routing model was called (by AI) "pre- and post- firewall routing." In effect, we force every packet that traverses two subnets in a VPC to go through the VPC endpoint of the firewall, then we put the firewall on its own subnet, with routes back through Cloud WAN core network attachments, and through NAT gateways.
Simplest benefit: east-west filtering
Our firewall policy has three stateful rules:
- Packets from any non-routable IP address to an IP address in the Egress VPC are allowed
- Packets from any non-routable IP address to any other non-routable IP address are blocked
- Packets from anywhere to anywhere are allowed
Like most firewalls, these rules are evaluated in order and packet filtering stops when the first rule matches.
The end result is that we now have a truly segmented network.
Which is pretty cool! But there's more! Read about it in Additional Benefits.
Psst. I have a résumé, it's available here.
Segmented CloudWAN Policy
As of this writing, the Cloud WAN Core Network Policy is:
{
"version": "2025.11",
"core-network-configuration": {
"vpn-ecmp-support": true,
"dns-support": true,
"security-group-referencing-support": true,
"asn-ranges": [
"4200000000-4294967294"
],
"edge-locations": [
{
"location": "us-east-1"
},
{
"location": "us-east-2"
},
{
"location": "us-west-2"
}
]
},
"segments": [
{
"name": "egress",
"description": "VPCs that need isolation but central egress",
"require-attachment-acceptance": true,
"isolate-attachments": true
},
{
"name": "workloads",
"description": "VPCs that can communicate with each other",
"require-attachment-acceptance": false
},
{
"name": "islands",
"description": "VPCs that are isolated",
"require-attachment-acceptance": false,
"isolate-attachments": true
},
{
"name": "sharedservices",
"require-attachment-acceptance": true,
"isolate-attachments": true
}
],
"network-function-groups": [],
"segment-actions": [
{
"action": "create-route",
"segment": "workloads",
"destination-cidr-blocks": [
"0.0.0.0/0"
],
"destinations": [
"attachment-xxx"
]
},
{
"action": "create-route",
"segment": "islands",
"destination-cidr-blocks": [
"0.0.0.0/0"
],
"destinations": [
"attachment-xxx"
]
},
{
"action": "create-route",
"segment": "egress",
"destination-cidr-blocks": [
"0.0.0.0/0"
],
"destinations": [
"attachment-xxx"
]
},
{
"action": "share",
"mode": "attachment-route",
"segment": "egress",
"share-with": "*"
},
{
"action": "share",
"mode": "attachment-route",
"segment": "workloads",
"share-with": {
"except": [
"islands"
]
}
},
{
"action": "share",
"mode": "attachment-route",
"segment": "islands",
"share-with": [
"egress",
"sharedservices"
]
},
{
"action": "share",
"mode": "attachment-route",
"segment": "sharedservices",
"share-with": "*"
}
],
"attachment-policies": [
{
"rule-number": 100,
"conditions": [
{
"type": "resource-id",
"operator": "equals",
"value": "vpc-xxx"
}
],
"action": {
"association-method": "constant",
"segment": "egress"
}
},
{
"rule-number": 150,
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "segment",
"value": "egress"
}
],
"action": {
"association-method": "constant",
"segment": "egress"
}
},
{
"rule-number": 200,
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "segment",
"value": "workloads"
}
],
"action": {
"association-method": "constant",
"segment": "workloads"
}
},
{
"rule-number": 300,
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "segment",
"value": "sharedservices"
}
],
"action": {
"association-method": "constant",
"segment": "sharedservices"
}
},
{
"rule-number": 400,
"description": "Segment name - islands",
"condition-logic": "or",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "segment",
"value": "islands"
}
],
"action": {
"association-method": "constant",
"segment": "islands"
}
}
]
}