AWS Cloud WAN series · Part 8 of 17

AWS Cloud WAN: Service Insertion & Network Function Groups

Eighth in the AWS Cloud WAN series. You've connected and segmented the network — now you need to inspect traffic between the parts. Service insertion, built on the Network Function Group, turns what used to be a static route per VPC into a single policy statement. Here's the construct, its two actions, and the multi-region traps, every claim sourced.

Why it exists — the per-VPC static route it kills

Most enterprise networks don't just connect things; they inspect what moves between them — firewalls, IDS/IPS, the usual security stack. On Cloud WAN before 2024, wiring that up was genuinely tedious. You shared an inspection segment, which meant every VPC's CIDR propagated into the inspection segment's route table with that VPC's attachment as the next hop. To actually steer traffic to a firewall, you added a static route in the inspection segment's route table for every new VPC, by hand, forever.

It got worse at multi-region scale. A single global inspection segment gave you no way to force a flow through the firewall in its own Region, so to inspect per-Region and stay symmetric, teams built a separate global inspection segment per Region. It worked. It was also fragile, manual, and scaled badly.

Service insertion replaces all of that with a policy statement. You declare intent — "inspect traffic from dev to prod" — and Cloud WAN populates and maintains the routes. The static entries that used to be your job become the service's job. One expectation to set immediately, because it's the most common misread: this does not reduce your firewall fleet. Service insertion steers traffic to appliances; it doesn't shrink the number of appliances. If you run 70 firewall instances today, you run 70 after. What you get back is the toil, not the licenses.

What a Network Function Group really is — a global container that spends a segment

A Network Function Group (NFG) is a global container for the attachments where your network functions live: the inspection VPCs hosting AWS Network Firewall, a Gateway Load Balancer fronting third-party NGFW/IDS/IPS appliances, or on-premises security infrastructure. Five properties decide how you design around it.

It's global. You can add attachments to one NFG from any Region in the core network — a single NFG can hold inspection VPCs in us-east-1, eu-west-1, and ap-southeast-2 at once.

It quietly spends a segment. Internally an NFG is implemented as a single segment with its own route table, so it draws from the hard ceiling of 40 segments per core network (covered in the segmentation article). There's no separate NFG quota; the segment and route limits just apply. That linkage is documented in the AWS service insertion blog, not on the Service Quotas page — worth knowing where it comes from.

You don't manage its routes. NFG route tables are auto-populated with next-hop redirections derived from your service insertion config. You can view those routes, but you cannot add, delete, or share routes inside an NFG — that's the service's job, and static routes are not propagated into it.

One attachment per NFG per Region. You get at most one inspection attachment per Region in a given NFG. Multiple NFGs can coexist in one core network, but you can't insert multiple NFGs for the same segment or segment pair. All attachment types are allowed as members — VPC, VPN, Connect, peering — though an inspection VPC is by far the common case.

Attachments join the same way they join a segment: by tags. You tag the inspection attachment (say role: inspection), and an attachment-policy rule maps it into the NFG via the add-to-network-function-group action — and as always, the policy reads the tags on the attachment, not on the VPC resource. One safety note worth internalizing now: a service-insertion attachment-policy rule requires a matching attachment, or policy generation fails. And if an NFG has no attachment in a Region where traffic is steered to it, that traffic is silently blackholed until you associate one. Empty NFGs don't error; they drop. Confirm every steered Region has a member.

The two actions — inspect-and-continue vs inspect-and-exit

Service insertion is expressed as a segment action with one of two types, and the distinction is the whole game — it's the difference between east-west and north-south traffic.

send-via is east-west. Traffic goes from one Cloud WAN attachment to another, routed through the NFG for inspection, then re-enters the core network to reach its real destination. Use it for VPC-to-VPC inspection, within one segment or across a segment pair. The action takes a mode (next section) and a when-sent-to list naming the destination segments — and because Cloud WAN keeps route symmetry automatically, inspection configured for source→destination applies to the destination→source return flow too.

send-to is north-south. Traffic flows into the appliance and then out — to the internet or on-premises — and does not re-enter the cloud. Use it for centralized egress inspection. It takes no mode. Mechanically, inserting a send-to NFG adds a default route (0.0.0.0/0 and ::/0) to the source segment's route table with the local NFG attachment as next hop, so all egress from that segment is steered through the firewall.

The mental model that keeps the two straight: send-via is a waypoint — inspect and continue; send-to is the door out — inspect and exit.

East-west inspection — send-via, and the same-segment catch

The common east-west case is inspecting traffic between two segments — say development and production. Here's the entire policy, single-hop:

"network-function-groups": [
 { "name": "InspectionVPC", "require-attachment-acceptance": true }
],
"segment-actions": [
 {
 "action": "send-via",
 "segment": "development",
 "mode": "single-hop",
 "when-sent-to": { "segments": ["production"] },
 "via": { "network-function-groups": ["InspectionVPC"] }
 }
]

Intent: any traffic from development to production is steered through the InspectionVPC NFG first, then on to production — and symmetrically back. The inspection VPC attachment gets tagged and mapped into the NFG by an attachment policy. That's it. Cloud WAN handles every route that used to be a manual static entry per VPC. Figure 2 shows what that looks like physically: the flow detours into the inspection VPC, crosses the appliances behind a Gateway Load Balancer, and re-enters the core to reach prod.

One subtlety the docs are blunt about, and it's the part teams miss. East-west inspection comes in two flavors with different requirements:

• Inter-segment (dev→prod, across two segments): use send-via instead of a plain share. A share would create uninspected routes between the segments, which defeats the point.
• Intra-segment (two attachments in the same segment): you must also set isolate-attachments on that segment. Isolated mode is required for service insertion to work within a segment — without it, the attachments have direct connectivity and simply bypass the NFG.

The inspection VPC internals are where vendor choice lives, and Cloud WAN doesn't care which you pick. AWS Network Firewall drops straight in; third-party NGFWs from Palo Alto, Fortinet, or Cisco deploy behind a Gateway Load Balancer. The NFG-plus-send-via policy is identical either way — only the inside of the inspection VPC differs.

Egress inspection — send-to and the default route out

Flip the action to send-to and you get centralized internet egress with inspection. The source segment receives a default route — 0.0.0.0/0 and ::/0 — pointing at the local NFG attachment, so everything bound for the internet is pulled through the inspection VPC before it can leave. Inside that VPC the layout is the familiar egress chain: the appliance (AWS Network Firewall, or third-party behind a GWLB) sits before the NAT gateway, which sits before the internet gateway. Figure 3 traces one flow end to end.

Because the next hop is the local regional NFG attachment, same-Region egress stays in-Region rather than hairpinning to a distant firewall — provided you've placed an inspection attachment in that Region. Which is exactly where the multi-region trap lives.

Cross-region inspection — single-hop, dual-hop, and the wrong-Region trap

For send-via, mode decides how many times a cross-region flow gets inspected.

single-hop traverses a single intermediate inspection attachment. For traffic between two Regions, Cloud WAN picks one of the two Regions' inspection VPCs so the flow is inspected once, not twice. It's the default and the cost-efficient choice — you don't pay to inspect the same flow at both ends.

dual-hop traverses inspection attachments in both the source and destination Core Network Edges. For that to work, an inspection attachment must exist in every Region of each service-insertion-enabled segment. Reach for it when your security policy genuinely requires both ends to enforce independently — and accept that it roughly doubles inspection data-processing. One hard constraint to plan around: an NFG used by a send-via dual-hop action cannot be reused for a single-hop or a send-to action. Design your NFGs around their mode.

Now the trap. In single-hop, when a Region has no local inspection VPC, Cloud WAN's default ordered list decides which remote Region inspects the traffic — and that order is not geography-aware. The canonical example: traffic from us-west-1, which has no local firewall, gets inspected in us-east-1 rather than the much closer us-west-2, simply because us-east-1 ranks higher in the default order. The result is latency and cross-country traffic you never asked for — the same regional-presence problem that haunts every multi-region Cloud WAN design.

The fix is the with-edge-overrides clause, nested under the action's via block. It overrides the default next-hop Region selection — "for traffic originating in us-west-1, use the firewall in us-west-2." In policy JSON:

"via": {
 "network-function-groups": ["InspectionNFG"],
 "with-edge-overrides": [
 { "edge-sets": [["us-west-1"]], "use-edge-location": "us-west-2" }
 ]
}

Read it as: route through InspectionNFG, but for the us-west-1 edge specifically, inspect in us-west-2. Edge-override is how you keep inspection local-ish and latency low when you haven't deployed a firewall in every single Region. It's essential for symmetric, cost-effective multi-region inspection — and don't conflate it with the 2025.11 routing-policy edge association, which is a different construct entirely.

What still bites — and when to reach for this

The policy can be perfect and you can still have a broken inspection path. The recurring culprits:

• Appliance mode is a separate switch. Service insertion steers traffic to the inspection VPC, but stateful inspection only works if that VPC's attachment has appliance mode enabled, so both directions of a flow land on the same AZ and appliance. The two are independent — you need both.
• An empty NFG is a blackhole. An NFG referenced by send-to/send-via deploys fine even with no attachment in a steered Region — and silently drops that traffic. Confirm every steered Region has a member.
• NFGs eat your segment budget. Each one is a segment internally; account for them in your 40-segment plan.
• Routing policies don't apply to NFGs. The 2025.11 routing policies can't be used on NFGs — keep your inspection traffic engineering inside the service-insertion constructs (mode, with-edge-overrides).

So here's the decision. Reach for service insertion the moment you need traffic inspected between Cloud WAN attachments and you're tired of hand-maintaining static routes to do it. Use send-via for east-west — and remember isolate-attachments if the two endpoints share a segment. Use send-to for centralized egress. Default to single-hop and reach for dual-hop only when policy genuinely demands inspection at both ends. And in any multi-region design, treat with-edge-overrides as mandatory, not optional — without it, the default ordered list will happily route your west-coast traffic to Virginia.

You now have the construct and its two actions. The next two articles put them to work on concrete designs: Article 9 applies send-to to centralized internet egress and ingress inspection — where to place firewalls regionally, and using edge-override to dodge the latency penalty of inspecting in a distant Region.