docs: How routing works between Transit Gateway and Cloud WAN

[pablo19sc]

Description

The 3-transit_gateway pattern showed how to build the Transit Gateway peering but never explained route selection across it. A reader could produce a correct Cloud WAN policy on top of a route-table layout that leaks between environments, and nothing in the repository would catch it.

This adds a "How routing works between Transit Gateway and Cloud WAN" section to the pattern README covering: the peering being dynamic (BGP) with segmentation coming from policy-based routing controlled by the route table attachments; route table attachments extending a segment and a route table into each other (no association or propagation to configure); a pairing matrix of which route-table-to-segment combinations exchange routes; and a callout on blackhole scope and longest prefix match. The SKILLS.md routing table and llms.txt annotation are updated so agents reach the new section.

One deliberate inference, flagged as such in the text: two route tables of the same Transit Gateway attached to the same segment do not exchange routes with each other through Cloud WAN. The behaviour is stated, but AWS documentation does not name the mechanism — the section says it is "most likely" standard BGP loop prevention (both route tables speak from the same Transit Gateway ASN, and a BGP speaker rejects routes carrying its own ASN in the AS_PATH). Every other behavioural claim is cited inline to AWS documentation or an AWS Networking & Content Delivery blog.

Where is the change?

• infra/ — a deployable infrastructure pattern
• policy/ — a policy capability page or its snippets
• SKILLS.md — agent knowledge or generator logic

Checklist for every change

• I have read CONVENTIONS.md and this change conforms to it.
• pre-commit run --all-files passes locally (see CONTRIBUTING.md).
• I reviewed advisory Checkov findings, fixed applicable issues, and included a justification for every new suppression (baseline comment or inline :reason). (Docs-only change — no IaC touched, no findings, no suppressions.)

If the change is in infra/

• CloudFormation and Terraform implementations are in parity, and the pattern is still defined only by the attachment types it creates — it does not encode a use case. (No IaC changed; the new section documents service behaviour, not a use case.)
• Human and agent indexes agree: infra/README.md and the SKILLS.md infrastructure selector reflect this change, and the tags the IaC applies still match what the baseline policy's attachment-policies expect. (Pattern catalog entries unchanged and still accurate; llms.txt annotation extended; tags untouched.)
• Every new IaC source file carries the MIT-0 license header. (No new IaC files.)
• The pattern README's Cost and Cleanup sections reflect any resource changes. (No resource changes.)

If the change is in SKILLS.md

• New content respects the skill's own rules: it sits on the correct side of the knowledge/procedure seam (see Telling the two halves apart), and any intake change keeps the tier tags and flag-report behaviour consistent. (One routing-table row only — knowledge side; no intake changes.)
• The skill still agrees with the repository: the How to use this skill routing table and section anchors resolve, and shared facts (pattern catalogs, association contract, policy version) match infra/ and policy/. (Anchor verified with lychee --include-fragments.)
• I piloted the change with an agent — gave it the updated SKILLS.md and a representative question or generation request — and its behaviour matched the intent. Describe the pilot under Testing.

Testing

Statically validated only — no deployment, since no IaC or policy documents changed. pre-commit run --all-files passes, including the lychee link check with the new section anchor. The new prose was additionally scanned for stray identifiers: the only digits are in existing file paths, with no account IDs, ASNs, or CIDRs introduced.

Agent pilot not yet run (checkbox left unchecked). Suggested pilot before merge: give an agent the updated SKILLS.md and ask "how can I segment my traffic between Transit Gateway and Cloud WAN?" — it should route to the new README section and answer from the policy-table/route-table-attachment model rather than improvising.