AWS Cloud WAN series · Part 4 of 17

AWS Cloud WAN: Attachment Policies & Tag-Based Automation

Fourth in the AWS Cloud WAN series. The segment matrix you designed in Article 3 is just intent until something places each VPC, VPN, or peering into the right segment. That "something" is the attachment policy — the mechanism that turns onboarding a workload into a tagging exercise, automatically, across hundreds of accounts. Here's how it decides, the one mistake that quietly breaks it, and the gate that keeps automation from becoming a security hole.

Why onboarding becomes a tagging exercise — you declare once, tags place the rest

In a Transit Gateway world, connecting a VPC is a manual act every time: a human or a script explicitly associates the attachment with a route table and sets up propagations — per attachment, in the right Region, in the right order. Cloud WAN inverts that. You don't associate anything. You declare a rule once in the core network policy and let tags drive the mapping.

The flow has three steps. You write attachment-policy rules into the core network policy (the document from Article 2). Someone in a workload account creates an attachment — a VPC attachment, say — and puts tags on it. Cloud WAN evaluates your rules against that attachment's tags and metadata, and maps it to the segment or network function group the rules dictate.

The payoff is organizational, not just technical. The new workload's owner never touches routing. They tag their attachment correctly, and the boundary you designed in your segment matrix enforces itself — the same way, in every account and Region, with no per-device synchronization. In a multi-account organization, that's the difference between an onboarding ticket that takes weeks and one that takes minutes. The catch is that the whole system rests on one assumption about where those tags live, and that's exactly where most people slip.

Why your tag isn't taking effect — attachment tags, not resource tags

This trips up nearly everyone the first time, so it's worth being emphatic: attachment policies evaluate tags on the attachment object, not tags on the underlying resource. The AWS docs say it plainly — the policy analyzes "the tags analyzed by the attachment policy, and not the tags associated with the VPC resource."

So a tag environment: production placed on the VPC does nothing for segment mapping. The same tag placed on the VPC attachment is what gets evaluated (Figure 1). The attachment is its own object with its own tag set, and when you create the attachment is when those tags must be present.

This matters most for your Infrastructure-as-Code. If a VPC module creates the attachment for you, make sure the tags you intend for mapping land on the Cloud WAN attachment resource — not only on the VPC. The AWS reference Terraform module handles this by applying the tags you define under its core_network subnet type to the attachment itself; Article 13 goes into the IaC wiring. The practical rule for every review: when a VPC "won't attach to the right segment," check the attachment's tags first. It's the single error you'll see most often.

What you can match on — and why it's governance, not just convenience

Tags are the common case, but a condition can match on more than tags. There are a handful of condition type values, and knowing the full set is what turns attachment policies from a convenience into a governance control.

The condition types, in plain terms:

• Tags — tag-value (the key equals a value) or tag-name (the key is simply present). The workhorse.
• Account (account) — which AWS account owns the attachment.
• Region (region) — which Region the attachment is in.
• Attachment type (attachment-type) — vpc, site-to-site-vpn, connect, transit-gateway-route-table, or direct-connect-gateway.
• Resource ID (resource-id) — a specific resource, e.g. a particular vpc-id.

The operators are equals, not-equals, contains, begins-with, and any. This richer matching is what makes attachment policies governance, not just plumbing. You can express organization-wide intent without per-resource wiring:

• "Any attachment from the security account → inspection."
• "Any VPC attachment in eu-west-1 tagged data-class: pci → the PCI segment."
• "Any Connect attachment → the hybrid segment."

The crucial property: the rules encode policy, and a workload account can't out-tag them. It can tag its attachment, but it can only land where your rules permit — account and Region conditions in particular aren't something a tag can fake.

How a rule gets chosen — first match wins, so order is everything

Each attachment-policy rule has four parts:

• rule-number — an integer from 1 to 65535. Rules are evaluated lowest to highest, and the first matching rule wins — evaluation stops there ("Rules stop processing when a rule is matched"). An attachment maps to exactly one segment; if nothing matches, it maps to none.
• condition-logic — and (all conditions must match) or or (any one matches). It's mandatory only when a rule has more than one condition, and nested and/or isn't supported. A rule that maps into an NFG must use and.
• conditions — the list of match criteria from the previous section.
• action — what a match does. Associate to a segment via association-method: constant (a named segment) or association-method: tag (the segment is the value of the key named in tag-value-of-key); or, for service insertion, add-to-network-function-group. You can also set require-acceptance (which is only ever settable to true).

Because evaluation is first-match-wins, ordering is the whole game — this behaves exactly like a firewall rule list. Put your most specific rules (a particular account, a PCI tag) at low numbers and broad catch-alls at high numbers. Invert that and the catch-all shadows everything below it: a rule 100 that matches "any attachment with a segment tag" will swallow the PCI attachment you meant to special-case at rule 200, because matching already stopped (Figure 3).

One elegant pattern is to derive the segment name straight from a tag value: a single rule that says "associate to the segment named by the segment tag." Now you add new segments without adding new rules, as long as your segment names and tag values stay in lockstep. It's powerful but double-edged — a typo in a tag silently maps the attachment to nowhere (or somewhere wrong), with no error to catch it. Pair that pattern with require-attachment-acceptance on any sensitive segment, which is where we go next.

What stops a workload from tagging itself into production — the acceptance gate

Tag-based automation is powerful precisely because it takes humans out of the loop — which is also its risk. What stops a workload account from tagging its attachment segment: production and dropping itself into your most sensitive routing domain?

The answer is require-attachment-acceptance, set per segment in the policy (Article 2) and defaulting to true. When it's on, an attachment that maps to that segment doesn't go live immediately. It enters a Pending attachment acceptance state, and the core network owner must explicitly accept or reject it. Only on acceptance does it become Available (Figure 4).

This gets you the best of both models at once: automation for the common, low-risk case (dev VPCs flow in untouched) and a human gate on the boundaries that matter (production, PCI, shared services). Design your matrix so sensitive segments require acceptance and routine ones don't. There's a sibling state, Pending tag acceptance, for when an attachment's tags change in a way the owner must review — same governance principle, applied to a change rather than a first join.

For full situational awareness, the attachment lifecycle has eight states: Creating, Pending network update, Pending tag acceptance, Pending attachment acceptance, Available, Rejected, Failed, and Deleting. When an attachment lands in Failed, it's usually an input error or a service-linked-role permission issue — check those two first.

Putting it together — a rule set that reads top to bottom

Suppose your matrix from Article 3 has production (acceptance required), non-prod (automatic), shared services, and an inspection NFG. A coherent rule set, in evaluation order, looks like this. Note the condition type strings: account for the owning account, tag-value for a key/value match, and tag-name for "this tag key is present."

"attachment-policies": [
 {
 "rule-number": 50,
 "condition-logic": "and",
 "conditions": [
 { "type": "account", "operator": "equals", "value": "111122223333" },
 { "type": "tag-value", "operator": "equals", "key": "role", "value": "inspection" }
 ],
 "action": { "add-to-network-function-group": "InspectionNFG" }
 },
 {
 "rule-number": 100,
 "conditions": [
 { "type": "tag-value", "operator": "equals", "key": "segment", "value": "production" }
 ],
 "action": { "association-method": "constant", "segment": "production" }
 },
 {
 "rule-number": 200,
 "conditions": [
 { "type": "tag-name", "operator": "equals", "value": "segment" }
 ],
 "action": { "association-method": "tag", "tag-value-of-key": "segment" }
 }
]

Read it in order. A specific inspection attachment from the security account goes to the NFG first (rule 50, which uses and plus a tag condition, as NFG rules must). Then anything explicitly tagged segment: production maps to production — and because that segment requires acceptance, it still waits for sign-off. Finally a catch-all maps any remaining tagged attachment to the segment named in its own segment tag. Specific rules first, general rules last — exactly what first-match evaluation demands. Reverse rules 100 and 200 and the catch-all would quietly absorb the production attachment before the production rule ever ran.

What to get right before you write a rule — the operational bar

A few hard-won practices decide whether this system stays calm or generates tickets.

Standardize your tag vocabulary before you write rules. The whole mechanism rests on consistent tags. Decide on segment, data-class, role and the rest, document them, and enforce them with tag policies or IaC defaults. Inconsistent tagging is the most common source of "why didn't my VPC connect?" tickets.

Put acceptance on every segment that carries a real boundary. Automation without a gate on a sensitive segment converts a tagging mistake into a security incident. The default is already true — the danger is turning it off for convenience on a segment that deserved the gate.

Keep rules few and ordered deliberately. Like firewall rules, attachment policies are easiest to reason about when there are few of them and the specific-before-general ordering is obvious. Resist the urge to write a rule per team.

Remember the resource-vs-attachment tag distinction in every IaC review. When a VPC "won't attach to the right segment," check the attachment's tags first — it's the error you'll hit most.

Get those four right and onboarding a workload really is a tagging exercise: the owner tags their attachment, your ordered rules place it, and your acceptance gates guard the boundaries that matter. You can now place attachments into segments automatically and safely. The next article turns to the attachments themselves — the full menu of VPC, Site-to-Site VPN, Connect (SD-WAN / GRE), Transit Gateway peering, and native Direct Connect Gateway attachments, plus appliance mode, the AZ-ID mapping trap, and how Cloud WAN picks a winner when the same destination is learned from several sources.