AWS Cloud WAN series · Part 14 of 17

AWS Cloud WAN: Multi-Account Infrastructure-as-Code

Fourteenth in the AWS Cloud WAN series, and the one where the architecture finally meets the org chart. Cloud WAN's biggest payoff shows up in the exact environment that makes it hardest to run as code: many accounts, many Regions, many teams. Here's how to split ownership so one team owns the core network and policy, every other account self-serves its own attachments, and a bad routing change gets caught in CI before it ships — with every claim sourced to AWS docs.

Article 13 introduced Cloud WAN in Terraform and stated one rule almost in passing: don't deploy the core network and the VPC attachments in the same workspace. This article is that rule, fully developed — why the split exists, how you share the core network so other accounts can even reach it, how an account onboards itself without a central change, and how you stop a one-line policy edit from rerouting your entire global network. The shape that falls out — central policy, distributed attachment — is the operational reason Cloud WAN is worth its premium for a large estate.

Why the core network and its attachments can't share an owner

Article 13's rule was blunt: don't put the core network and the VPC attachments in the same Terraform workspace. The reason most often given by practitioners is a dependency race — within one apply, Terraform can try to create attachments before the core network and its policy have settled, and that ordering is hard to express reliably. I'd flag that the race-condition framing is practitioner lore, not something AWS documents; treat it as the intuition, not the citation.

What AWS does document is the conclusion, and it's the one that matters: decouple the global resources from the regional VPCs into separate stacks. The maintained aws-ia/cloudwan module README says to create the global network and core network in a different module definition than the Central VPCs precisely to decouple them; AWS's blueprints generalize it to "separate network infrastructure, workload VPCs, and inspection resources" so each has its own lifecycle. The two-workspace split is the minimum viable form of that discipline.

The payoff isn't just dodging a race. It's independent lifecycle (Figure 1). The networking team evolves the policy without waiting on a dozen workload teams to run apply; a workload team attaches a new VPC without ever touching — or having permission to touch — the core network. That division also lines up with billing: the core-network owner pays for the per-Region CNEs, and each VPC-owning account pays for its own attachment and its own data processing. Ownership, blast radius, and the invoice all break along the same line. That's not a coincidence; it's the whole reason to draw the boundary there.

How every account gets to see one core network — RAM, and the us-east-1 trap

Here's the structural fact that makes multi-account Cloud WAN possible at all: a VPC in account B can't attach to a core network owned by account A until account A shares it with AWS Resource Access Manager. RAM is the linchpin — without the share, the resource doesn't exist as far as account B is concerned.

You can share with individual accounts or with the whole AWS Organization / OUs, and org-wide is the scalable choice: new accounts inherit access without a per-account RAM grant. A shared core network supports VPC attachments and TGW route-table (peering) attachments from the recipient accounts — recipients can create, get, and delete their attachments, but they can't modify the core network itself.

Once shared, the magic is that nothing about a workload account's attachment is special-cased. Its attachment lands in the core network and is mapped to a segment by the central attachment policy (Article 4) based on the attachment's tags — no manual association, and the same governance applies no matter which account it came from. The boundary you designed in the segment matrix (Article 3) enforces uniformly across every account, because the policy enforces it, not per-account wiring. Figure 2 shows the shape: one core network, shared once, with two accounts' VPC attachments falling into different segments purely on their tags.

How a new account onboards itself — the templated attachment workspace

With the core network shared, Workspace 2 becomes a template that each account stamps out. The pattern, drawn straight from the maintained module:

• A single reusable module creates the account's VPC(s) and the Cloud WAN attachment, tagging the attachment per the org's tag vocabulary — e.g. segment = "production".
• It's parameterized by environment, so the same template deploys a prod VPC in a prod account and a dev VPC in a dev account — differing only in tags and CIDRs.
• Because attachment-to-segment mapping is tag-driven, the template needs to know nothing about the segment topology. It tags correctly; the central policy does the rest.

That's what makes onboarding a near-trivial operation (Figure 3): stamp the template, tag correctly, and the workload joins the right segment automatically — subject to acceptance on sensitive segments, where the attachment sits in Pending attachment acceptance until an owner approves it. The networking team never makes a change to bring a new account online. The attachment policy already anticipated it; the new account just matches a rule that was written months ago.

Two details from earlier articles bite hardest in exactly this multi-account, templated setting:

Tag the attachment, not the VPC. The single most-missed rule in Cloud WAN: the attachment policy analyzes "the tags associated with the attachment, and not the tags associated with the VPC resource." In a templated module this is a real footgun, because Terraform makes it easy to tag the VPC. In the maintained module, tags placed under the core_network subnet type are the ones applied to the attachment — put your segment-mapping tags there, and verify on the attachment object, not the VPC. Rules are evaluated lowest-number first and first match wins, so a too-broad early rule can quietly swallow an attachment you meant for a later one.

Use AZ IDs, not AZ names. AWS randomizes the AZ-name-to-physical mapping per account — us-east-1a is a different physical zone in account A than in account Z. Place attachment subnets by the stable AZ ID (e.g. use1-az1, identical in every account) so attachments from different accounts land in the same physical zone. This is critical for shared-services and inspection segments, where cross-account flows that "look" same-AZ but aren't will cost you latency and, with appliance mode, correctness.

How you stop one line of HCL from rerouting the planet — CI on the policy

The policy is a single document that controls global routing, so a bad change has a broad blast radius — which is exactly the argument for catching it before it goes live. The version-and-rollback safety net (Article 2) saves you after the fact; CI saves you before.

And you get a real assist from the platform here: a new policy version is never deployed automatically. Every change generates a numbered version, only one is LIVE at a time, and AWS gives you a change set with explicit states — Pending generation → Ready to execute ("verified with no issues... can be deployed as the new LIVE policy") or Failed generation, then a human applies it. Rollback is restoring an out-of-date version — effectively one action. That built-in gate is the documented pre-deploy verification surface; build your pipeline to sit in front of it (Figure 4).

What I'd wire into the pipeline for Workspace 1:

• Surface the policy diff in the PR. Render the regenerated policy document so a reviewer sees exactly which segments, shares, or rules changed. A one-line HCL edit can change routing everywhere — make the diff impossible to miss.
• Encode the segment matrix as executable assertions. Cloud WAN ships no native policy linter, so teams write their own — AWS's published Silverflow case study describes exactly this: a custom checker that parses the Cloud WAN definitions and fails the build on logic errors, gated by CODEOWNERS with human approval at each step, "because there are no CloudFormation guard rules for AWS Cloud WAN." The policy is plain JSON, so generic engines (OPA/conftest on the plan, cfn-guard on the rendered .json) work too — but none ship Cloud-WAN-aware rules; you author them.
• Keep changes small and reviewable. Treat policy versions like commits: small diffs are easy to review, reason about, and roll back. Avoid sweeping multi-concern changes in one apply.

One honest caveat. The specific assertion set people reach for — "prod and non-prod share nothing, sandbox is isolated, PCI shares only what it's allowed to" — and the idea of applying the policy to a throwaway core network first are sensible engineering, but they're my recommendation and the community's, not something AWS publishes a recipe for. Silverflow confirms teams encode such checks; it doesn't hand you the rules. So lean on the documented change-set gate as the backstop, and write the assertions that encode your matrix.

Who owns what at org scale — the reference topology

Putting the pieces together into one operational picture:

• Network account runs Workspace 1: global network, core network, policy. It shares the core network org-wide via RAM from us-east-1, and CI validates every policy change against the segment matrix before deploy, with version rollback available.
• Security account owns the inspection VPCs, mapped into a Network Function Group by attachment policy (Articles 4, 8). Egress and inspection stacks live here, or in dedicated stacks, per the same separate-stacks guidance.
• Workload accounts each run the templated Workspace 2: create VPC(s), attach to the shared core, tag the attachment for the right segment. New accounts onboard by stamping the template — no central change required.
• Shared-services account hosts common endpoints in a shared-services segment, reachable non-transitively by exactly the segments your matrix allows.

The networking team manages one policy; every other account self-serves attachments within the guardrails that policy enforces. That division — central policy, distributed attachment — is the operational shape that makes Cloud WAN worth its premium for a large organization. It's also the shape that doesn't fall apart at forty accounts the way a hand-wired hub-and-spoke does.

What to actually do

If you take one thing from this article, make it the boundary. Draw the line between the core network and its attachments, and let everything else follow it — ownership, permissions, blast radius, and the bill all break cleanly along that same seam.

Concretely: stand up Workspace 1 in a dedicated network account (core network + policy), share the core network org-wide via RAM from us-east-1, and make Workspace 2 a parameterized template that every account stamps out — tagging the attachment, never the VPC, and placing subnets by AZ ID. Put a CI gate in front of the policy that renders the diff and asserts your segment matrix, and trust the platform's change-set gate as the backstop that won't auto-deploy. Onboarding a new account should be a pull request in that account's repo and nothing in yours.

You can now build and operate Cloud WAN across an organization as code. But building it is only half the job — you have to run it, watch it, and fix it when traffic misbehaves. Article 15 turns to observability and troubleshooting: the CloudWatch metrics Cloud WAN exposes (including per-AZ), where its visibility differs from TGW flow logs, reading route tables in the console, PMTUD behavior, and the common failure modes — dropped traffic from missing routes, asymmetry, appliance-mode misconfiguration — with how to diagnose each.