AWS Cloud WAN series · Part 10 of 17

AWS Cloud WAN: East-West Inspection Across Segments

Tenth in the AWS Cloud WAN series. North-south inspection guards the door between your network and the internet; east-west inspection guards the doors inside it — lateral traffic between VPCs and segments that your policy says must cross a firewall even though it never leaves AWS. This is where send-via earns its place, and where the routing symmetry Cloud WAN maintains for free is the feature that makes the whole thing tractable. Every claim here is sourced.

The firewall that never sees the internet

Article 9 put a firewall at the edge: traffic leaving for the internet gets inspected, then exits. That's north-south — and Cloud WAN does it with a send-to action that drops a default route into your segments and never re-enters the core. East-west is the other half of the security cluster, and it's a different shape. Here the firewall sits in the middle of two internal trust zones and never touches the internet at all. Traffic from one segment to another is inspected and then continues on to its real destination. The appliance is a waypoint, not an exit.

Why bother inspecting traffic that stays inside AWS? Because in a flat network any compromised workload can move laterally to any other. East-west inspection breaks that by forcing traffic between trust zones through a firewall that can allow, deny, log, or deep-inspect it. The usual requirements:

• Inter-segment: production may reach a partner or shared segment, but only through a firewall — the "inspected" cells in the segment matrix from Article 3.
• Intra-segment: even within one segment, workloads must be inspected before they can reach each other — the zero-trust case.
• Hybrid east-west: on-premises-to-VPC traffic inspected before it lands on a workload.

All three use the same verb — send-via — and the mechanism is the through-the-core building block that Article 8 introduced for service insertion generally. This article is about the lateral decision specifically: when to inspect, how the routing stays correct, and what it costs.

Steer segment-to-segment traffic with send-via, not share

This is the workhorse pattern. You have two segments — say production and development — that your matrix says may communicate, but only through inspection. The instinct is to share them. Don't: a plain share creates direct, uninspected routes between the two segments, which is exactly the thing you're trying to prevent. Instead you apply a send-via action naming the pair and the inspection NFG:

"segment-actions": [
 {
 "action": "send-via",
 "segment": "development",
 "mode": "single-hop",
 "when-sent-to": { "segments": ["production"] },
 "via": { "network-function-groups": ["InspectionVpc"] }
 }
]

What Cloud WAN does with that one statement: for the specified pair, it propagates routes into each workload segment's route table with the local NFG attachment as next hop, so traffic from development to production lands at the inspection VPC first, gets inspected, and is then forwarded on to production. You wrote one action; Cloud WAN built every route, in every region the segments span. Figure 1 shows the resulting path: workload, into the core, out to the inspection VPC's Gateway Load Balancer and appliance fleet, back into the core, on to the destination.

Two practical notes that bite people. First, an NFG holds at most one attachment per Region, and an NFG that's referenced by a send-via but has no attachment yet doesn't fail — it deploys and silently blackholes the inspected traffic until you wire an inspection VPC into it. Second, the NFG itself spends one of your 40 segments (the hard, non-adjustable cap), because internally an NFG is implemented as a segment. Budget it like any other segment.

The return path that just works — and the appliance-mode tax it doesn't pay

Here's the property that makes east-west inspection usable at all, and it's the part the docs underplay. Your policy says "inspect when source is development and destination is production" — a one-directional statement. But Cloud WAN generates the routes to keep the flow symmetric, so the return traffic (production back to development) is inspected too, over the same path, through the same firewall. You never configure the reverse direction. send-via is bidirectional by construction: A→B implies B→A. That single guarantee is what prevents the classic "asymmetric routing breaks the stateful firewall" failure — but only at the routing layer.

It does not buy you AZ-level symmetry, and this is the trap. A stateful firewall has to see both directions of a flow on the same appliance — if the forward packet hits the appliance in AZ-a and the reply hits a sibling appliance in AZ-b, the second appliance has no state for the flow and drops it. Cloud WAN's route symmetry gets traffic to the right inspection VPC; it says nothing about which AZ inside that VPC. Pinning a flow to one AZ for its lifetime is a separate control: appliance mode, enabled on the inspection VPC attachment.

So you need both, and they're independent (Figure 2). Service insertion is the routing-layer guarantee; appliance mode is the AZ-layer guarantee. The AWS docs are blunt about it: appliance mode "must be enabled on the Inspection VPC to ensure that traffic moves in both directions." Enable it on every inspection VPC attachment, always — there is no design where you want service insertion without it.

Inspecting inside one segment — isolate first, then insert

Sometimes the boundary you care about is inside a single segment: workload A and workload B share a segment but must still cross a firewall to reach each other. This is supported, with one prerequisite carried over from segmentation design — the segment must have isolate-attachments enabled.

The reason is mechanical. By default, attachments in the same segment reach each other directly, with no route through anything. If you drop a send-via onto that segment without isolation, the direct routes still exist and traffic simply takes them, bypassing the firewall entirely. Turning on isolate-attachments removes the direct spoke-to-spoke routes; now the only path between A and B is the one send-via installs — through the NFG. "Isolate, then insert" is how you build a zero-trust posture where same-segment workloads can't talk except through inspection. Skip the isolate step and you've built an inspection path that traffic quietly routes around.

Where a cross-region flow gets inspected — single-hop vs dual-hop

Article 8 introduced the two modes; the east-west question is which one to put on a given segment pair. The choice is about how many times a cross-region flow is inspected.

Single-hop inspects a cross-region flow once, in one of the two regions, with the region chosen by an ordered priority list. This is the default and the right answer for most designs: one inspection satisfies the policy, each flow is processed a single time, and you avoid paying for inspection twice. Dual-hop inspects in both the source and destination regions, which means you need an inspection VPC in every region the service-insertion-enabled segment touches, and it roughly doubles the inspection cost for those flows. Reach for it only when your security policy genuinely demands independent enforcement at each end — for instance, when each region's security team must apply its own policy to traffic entering its region.

One hard constraint to file away: an NFG used by a dual-hop send-via cannot be reused for a single-hop or a send-to action — dual-hop NFGs are dedicated. Plan your NFG-to-action mapping accordingly; you can't retrofit a dual-hop NFG into a cheaper single-hop path later.

The region-priority trap from Articles 8 and 9 applies identically here, and it's the most common single-hop surprise. The default ordered list is not geography-aware. If a region has no local inspection VPC, single-hop may steer its inspection through a distant region — us-west-1 traffic inspected in us-east-1 instead of nearer us-west-2 — adding latency and a cross-region hop you're paying for. The fix is with-edge-overrides (nested under via): pin the closer region and keep east-west latency and cost sane.

What runs in the inspection VPC — and why Cloud WAN doesn't care

The NFG holds the inspection attachments; what runs inside them is your choice, and it's genuinely decoupled from the Cloud WAN policy:

• AWS Network Firewall — managed and stateful, with URL filtering and deep packet inspection. AWS provisions its endpoint for you. The low-friction native option.
• Third-party NGFW / IDS / IPS (Palo Alto, Fortinet, Cisco, and the like) — deployed as appliances behind a Gateway Load Balancer in the inspection VPC. The GWLB handles scaling and health-checking; Cloud WAN steers to the inspection VPC and the GWLB distributes across the appliance fleet.

In both cases the Cloud WAN configuration is identical — a send-via to the NFG. The entire difference lives inside the inspection VPC. That's a real strength: you can swap firewall vendors, or run Network Firewall in one region and a third-party fleet in another, without touching a line of the core network policy. The policy describes where traffic is inspected; the VPC internals decide how.

When to reach for it — inspect the boundaries that carry risk, and only those

The recurring theme of this series is sharpest in east-west, so let's be honest about it. Service insertion makes lateral inspection operationally elegant — one policy statement instead of a forest of static routes in per-region inspection segments. It does not make it cheaper in appliance terms.

• The firewalls still cost what they cost. Service insertion re-routes traffic; it doesn't reduce instances or licenses. If you run, say, 70 firewall instances for east-west inspection today, you'll run 70 after adopting it. The savings are operator time and routing simplicity — not licenses.
• Inspection adds data-processing charges. Every flow steered through an inspection VPC takes extra hops, and Cloud WAN bills data processing at $0.02/GB per hop on top of the firewall's own processing. Dual-hop doubles the inspection portion; single-hop with same-region locality is the cost-efficient baseline.
• Not inspecting is also a design. Keeping same-segment, same-region traffic that your policy already trusts uninspected saves real money — one migration pattern deliberately extends a segment across regions specifically so intra-segment traffic avoids cross-region firewall hops, cutting both latency and inspection cost.

So the decision is the same one segmentation gave you: design inspection from the segment matrix. Inspect the boundaries that carry genuine, differing risk — the cells your matrix marks "inspected" — and let same-segment traffic your policy trusts flow directly. A representative design lands here: a production and a non-production segment that may exchange specific traffic only through inspection; an InspectionVpc NFG with an AWS Network Firewall VPC in each region, appliance mode on; a single-hop send-via for the pair; and edge-overrides for any region lacking a local inspection VPC. The security team gets enforced, logged, bidirectional inspection; the network team maintains one policy document instead of per-VPC static routes. Inspecting everything "to be safe" is how inspection cost balloons with no security story to justify it.

That closes the security cluster. Next, the series turns to the reality that most teams don't build Cloud WAN greenfield — they migrate to it from Transit Gateway. Article 11 covers Phase 1 of that migration: federating your existing TGWs with Cloud WAN for global dynamic routing while everything else stays in place, including the route-preference behavior that lets you cut over gradually and safely.