AWS Cloud WAN series · Part 3 of 17

Cloud WAN Segmentation: Design From "What Must Never Happen"

Third in the AWS Cloud WAN series. Segments are where Cloud WAN earns its keep and also where most designs go wrong — because teams decide what their segments are before they decide what their segments are for. Here's how to design them as trust boundaries you'll actually defend, inside the hard limits AWS sets.

Design from what must never happen — not the org chart

The single biggest segmentation mistake is defining segments by organizational unit — a Finance segment, a Marketing segment, an IT segment. It mirrors how the company is drawn on a slide, so it feels natural. Three months later Marketing's pipeline needs to read Finance's warehouse, and you're drilling holes in a boundary you just built. Six months on, every segment reaches every other through some exception, and your segmentation exists only on paper.

The right question isn't "who owns this?" It's: what traffic must never happen? Answer that, and the segments fall out as the enforcement of those rules — each plain-English "never" compiles to an isolated or unshared boundary (Figure 1).

This works because of how a Cloud WAN segment behaves by default: it "operates as a completely separate routing domain," and attachments can only reach other attachments in the same segment. There is no explicit "deny" to write — the absence of a route is the deny. A segment boundary is as strong as a firewall rule you never have to maintain, so make those boundaries match rules you're actually willing to enforce. A boundary you'll grant exceptions to within a quarter was never real. Design segments as a security control first, a connectivity convenience second.

How to slice the network — by environment, by application, or both

In practice, two strategies dominate, and the choice sets your segment count for years.

Environment-based segmentation separates by deployment stage: production, development/test, shared services, egress. It's the right default for most organizations because it maps cleanly onto how risk actually differs — production data is more sensitive than dev data — and it keeps the segment count low.

Application-based segmentation separates by workload — isolating critical or public-facing applications from one another to limit lateral movement in a breach. It gives finer-grained, application-specific control without layering in extra appliances, but the cost is scale: it produces far more segments, complicates the policy, and runs into the hard segment cap (next section) much faster.

Most teams land on a middle path: environment-based as the primary axis, with a few application or compliance segments carved out only where a genuine "must never happen" rule demands it — PCI, a regulated workload, a multi-tenant boundary. Start coarse; split only when a real isolation requirement forces it. That's my own bias, but it falls straight out of the cap you're about to meet.

Why you can't have a segment for everything — the 40-segment ceiling

Before you fall in love with a fine-grained design, get the quota straight: a core network supports a maximum of 40 segments, and this limit is not adjustable. A second claim on the same budget is easy to miss — a Network Function Group, the construct service insertion uses to steer traffic through inspection, uses one core network segment internally, drawing from the same 40. So if you plan to inspect east-west or egress traffic, those inspection paths eat into the segment count too (Figure 2). That NFG-to-segment linkage is documented in the AWS service insertion blog, not on the Service Quotas page — worth knowing where it comes from.

The operational wisdom here is blunt and correct: less is more. If dev, QA, and UAT have the same routing characteristics — same shares, same isolation, same reachability — collapse them into one non-production segment. You don't need a segment per environment name; you need a segment per distinct routing-and-trust behavior. Two segments that would always have identical sharing rules should almost always be one segment. Spend your budget on boundaries that carry real, differing security meaning; burning segments on cosmetic distinctions is how teams paint themselves into a corner two years in.

What the boundaries can and can't express — deny-by-default, isolation, non-transitive sharing

Three behaviors determine what your segmentation can and can't say. Get these straight and the matrix in the next section writes itself.

Deny by default (implicit deny). Only attachments in the same segment communicate; everything else is denied by the absence of a route. Your design is fundamentally an allow-list — you enumerate what's permitted and the rest is denied by construction, a strong security posture for free. (Segment names are alphanumeric only — a–z, A–Z, 0–9, no hyphens or underscores — so plan naming before you reference segments everywhere.)

Intra-segment isolation (isolate-attachments). Normally attachments in one segment freely reach each other. Turn on isolate-attachments (it defaults to false) and they can't — they can only reach shared services through a share. This is how you build a strict hub-and-spoke within a single segment: every spoke reaches the hub, no spoke reaches another spoke. It's the right setting for a sandbox segment, for spoke VPCs that should never mesh, and — this part matters later — it is required for same-segment (intra-segment) service insertion to work.

Bidirectional, non-transitive sharing. A share between two segments is two-way by default; to make it one-directional you apply a deny-filter (allow- and deny-filters are mutually exclusive). The property that makes shared segments safe is that sharing is not transitive: if shared-services is shared with both prod and non-prod, that does not let prod reach non-prod through shared-services. Each share is a direct, point-to-point relationship — which is exactly what makes a shared-services or egress segment safe to attach to everything without it becoming an accidental bridge.

One subtlety the docs are explicit about: across a share, only attachment/propagated routes cross — static routes do not. If you need a static route reachable from a shared segment, account for that explicitly; don't assume it rides along.

Turn the design into a policy you can write in one sitting — the segment matrix

The most valuable thing you can produce before touching the policy is a segment connectivity matrix — every segment across the columns and down the rows, each cell marked allow (a share), block (no share; the implicit deny), or inspected (allowed but steered through an inspection device). The diagonal carries its own decision: should attachments within a segment talk to each other, or is the segment isolated? That's your isolate-attachments choice, captured in the same artifact. Figure 3 is a worked example for a common environment-based design.

Read it as enforceable intent: production and non-production each reach shared services and egress, but never each other; shared services and egress are themselves isolated to prevent lateral movement and are not shared with each other (so neither becomes a bridge); sandbox is completely cut off, isolated even internally. The non-transitivity of sharing is what makes the "both reach shared-svcs, neither reaches the other" row legal.

Once the matrix exists, the policy is mechanical transcription: every "allow" becomes a share; every "block" is simply the absence of a share; every "isolated" diagonal becomes isolate-attachments: true. The hard thinking happens in the matrix. It doubles as documentation and as the spec a reviewer checks the policy against.

Make it hold across every account and Region — acceptance, attachment tags, RAM

Segmentation almost always lives in a multi-account world, and a few policy features are what keep your matrix true once dozens of accounts start attaching to it.

Acceptance gates who joins a sensitive segment. require-attachment-acceptance defaults to true, so a workload account can't unilaterally drop itself into production — the attachment sits pending until it's accepted. Keep it on for any segment with a real "never" rule behind it.

Placement is driven by tags on the attachment — not on the resource. This is the single most-missed rule: attachment policies evaluate "the tags analyzed by the attachment policy, and not the tags associated with the VPC resource." That lets you express segment placement as organization-wide rules ("any attachment tagged env=prod joins production") rather than wiring each account by hand — but only if your tagging discipline is on the attachment, which Article 4 goes into.

Share the core network with AWS RAM, and mind the special Regions. You share the core network across accounts via Resource Access Manager, and your segmentation rules enforce consistently no matter which account or Region an attachment lands in. Two Region facts trip people up: Cloud WAN's home Region is always US West (Oregon), us-west-2, regardless of your provider config and not changeable once established; but the RAM share itself must be initiated from N. Virginia, us-east-1, so every other Region can see the global resource. Those are two different Regions — a known trap. Get the share Region wrong and your carefully designed segments simply won't be visible where you need them.

That consistency across Regions, with no per-device synchronization, is the whole point: you define the boundary once in the matrix, and AWS keeps it true everywhere an attachment appears.

When to split a segment — and when to leave it alone

Here's the decision to carry forward. Create a new segment only when a real "must never happen" rule needs its own enforceable boundary — a compliance scope, a tenant isolation requirement, a sandbox, an environment whose routing and trust genuinely differ. Leave it as one segment whenever two candidate segments would always carry identical sharing rules, because that split spends a slot from a hard 40-segment budget (and remember inspection NFGs spend from it too) while adding policy you'll maintain forever and buying you nothing.

A segmentation model is expensive to change once attachments are live and traffic depends on it, so the cheapest place to get it right is the matrix — before any JSON exists. Start from your "never" rules, default to environment-based, keep the count as low as the rules allow, and let the matrix be what a reviewer (and later your CI assertions) checks the policy against.

The model is only as good as the mechanism that places attachments into the right segments. The next article goes deep on attachment policies and tag-based automation — how attachment tags (not resource tags) drive mapping, the account/region/type conditions, rule ordering and first-match evaluation, and the acceptance workflow that keeps these boundaries from being quietly bypassed.