LEARN. PRACTICE. GROW.1. Design relationships before writing the policy
In a fictional exercise, three teams manage funds applications, development and shared services. Production and development must reach shared services while remaining separated from each other. Start with a matrix of sources, destinations, protocols and permitted operations. A Cloud WAN segment is a routing domain; it is not an application user role. Sharing common-service attachments with two segments does not transitively share those segments with each other. Include forbidden attempts and the return path in the matrix. If both environments can reach a shared server acting as a proxy, the routing policy does not demonstrate that this server prevents application-level transit between environments. That control needs its own design, owner and evidence. A successful connection to one shared service cannot establish the whole separation requirement.
2. Read association, sharing and filtering as distinct decisions
Attachment-policy rules evaluate the attachment, including its tags and metadata. They do not assume the associated VPC's tags. The first matching rule in ascending numeric order determines association; a broad rule placed too early can prevent a later specific rule from applying. Without a match, the attachment remains unassociated. Manual acceptance adds an association decision and needs an owner with clear criteria. For route sharing, an allow-filter restricts relationships already created; it does not create the intended share by itself. The attachment-route mode does not automatically redistribute static routes or routes received from another segment. Write checks for missing routes and unexpected associations, including a misspelled tag. The local exercise at the end demonstrates precedence for simplified rules only, without evaluating a real AWS policy. Current routing policies require schema 2025.11. Their association uses dedicated labels, managed by the core network owner, rather than the tags selecting segments. During an IaC review, confirm the schema version first, then the referenced resources and rules. A syntactically valid JSON file can remain incompatible with its selected version. Include schema migration in regional impact analysis.
3. Separate creation, application and operational acceptance
A new version can be ready to execute while the earlier policy remains LIVE. Approving the JSON file does not apply the change set. Compare old and new values, confirm affected Regions and execute within the approved window. Follow execution progress, but reserve operational acceptance for connectivity and isolation checks. Regional scope depends on the changed fields: changing the schema version affects every core network edge, whereas editing a description is not an equivalent change. Restoring an older policy creates a new version based on it; review and application are still required. Rollback may recover configuration without restoring sessions or business operations already in progress. Record how to reconcile instructions whose outcomes became uncertain, and identify who can decide whether the window should continue.
4. Insert inspection with a verifiable path
A network function group identifies attachments containing a network or security function. The send-via action steers traffic between VPCs through that function and back into the core network. Send-to represents an outbound path through the function. Selection requires knowledge of the source, destination, inspection Region and return path. In dual-hop mode, the architecture needs inspection attachments in both involved Regions; duplicating names in the policy is insufficient. The limit of one attachment per group per Region does not itself limit the number of appliances inside an inspection VPC. Before accepting the design, demonstrate that permitted traffic reaches the service, forbidden traffic is blocked and records attribute the result to the correct function. Deployment success alone cannot establish that inspection took place on the application path.
5. Assign work to the correct owner in a shared VPC
Sharing a subnet does not transfer administration of all its dependencies. The owner retains route tables, NACLs and Transit Gateway attachments; the participant manages its own resources, such as interfaces and security groups. During an incident, the participant team can describe a route table without being able to change it. Granting broader IAM permissions does not remove this sharing-model boundary. Define beforehand how to escalate network changes to the owner, including destination, port, evidence and deadline. For observability, distinguish subnet flow logs from logs for participant-owned interfaces. The owner can create its own logging resources but should not assume it can describe or delete flow logs created by a participant. Carry this responsibility matrix with the application when it moves between teams or accounts.
6. Plan withdrawal and RUN handover
Unsharing a subnet prevents new participant resources, while existing resources can continue running. This does not prove that autoscaling or node replacement remains possible: managed workflows may require continuous sharing. For decommissioning, inventory resources, recovery dependencies and deletion owners before closing the project. The owner cannot delete the subnet while participant resources remain. The handover should identify the LIVE version, approved associations, tested flows, alarms, contacts and reversal criteria. In the local exercise, change the broad rule's priority and observe which segment is selected. Then discuss what remains before accepting a real network: approval, propagation, routes, traffic controls and application results. The code does not replace those checks or contact AWS services. Existing connectivity is only one part of operational readiness.
def select_segment(rules, attachment_tags):
for priority, key, value, segment in sorted(rules):
if key == "*" or attachment_tags.get(key) == value:
return segment
return None
rules = [(20, "env", "prod", "production"), (90, "*", "", "sandbox")]
assert select_segment(rules, {"env": "prod"}) == "production"
assert select_segment(rules, {"env": "prodd"}) == "sandbox"
assert select_segment(rules[:1], {"env": "prodd"}) is None
assert select_segment(rules, {}) == "sandbox" # VPC tags are not an input
broad_first = [(10, "*", "", "sandbox"), rules[0]]
assert select_segment(broad_first, {"env": "prod"}) == "sandbox"
print("five precedence checks passed; no AWS policy evaluated or changed")
Fictional case: a team declares migration complete because version 12 is Ready to execute. Version 11 remains LIVE and a forbidden test still succeeds. The team reviews the change set, applies the approved version and repeats positive and negative tests before acceptance.
Common pitfalls
Confusing LATEST with LIVE; using VPC tags instead of attachment tags; assuming transitive sharing; withdrawing a subnet without testing resource replacement.
Related topics: Central inspection · Cross-account architecture · Change and decommissioning
Policy defines intent; execution, flow tests and ownership demonstrate delivery.
Reference: Core network policy version parameters · ANS-C01