# AWS Cloud WAN core network policy examples Core network policy examples This section provides example JSON AWS Cloud WAN policies. You can modify any of these examples for your own use. For a description of the required and optional parameters in the JSON file, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md). **Topics** + [Example: One segment, one AWS Region](cloudwan-policy-examples-one-segment-region.md) + [Example: Two segments, multiple Regions](cloudwan-policy-examples-two-segments-regions.md) + [Example: Edge consolidation](cloudwan-policy-examples-edge-consolidation.md) + [Example: Development environment with tags and shared services](cloudwan-policy-examples-three-stage.md) + [Example: Distributed WAN](cloudwan-policy-examples-distributed-wan.md) + [Example: Insert firewalls](cloudwan-policy-examples-firewalls.md) + [Example: Service insertion](cloudwan-policy-examples-service-insertion.md) + [Example: Routing Policies](cloudwan-policy-examples-routing-policies.md) # AWS Cloud WAN example: One segment, one AWS Region Example: One segment, one AWS Region This policy sets up one network in `us-east-1` with the name **my-network**. Any attachment is automatically added to the network without requiring approval. ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-1" } ] }, "segments": [ { "name": "mynetwork", "require-attachment-acceptance": false } ], "attachment-policies": [ { "rule-number": 100, "condition-logic": "and", "conditions": [ { "type": "any" } ], "action": { "association-method": "constant", "segment": "mynetwork" } } ] } ``` # AWS Cloud WAN example: Two segments and multiple AWS Regions Example: Two segments, multiple Regions This policy sets up two networks, `Secured` and `Non-Secured`, across three AWS Regions. Attachments with the tag `"Network" : "Secured"` map to `"Secured"`, while attachments with the tag `"Network" : "Non-Secured"` map to `"Non-Secured"`. All attachments require acceptance. Attachments can only talk within their segment but not across segments. ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-1" }, { "location": "us-east-2" }, { "location": "eu-west-1" } ] }, "segments": [ { "name": "secured" }, { "name": "nonSecured" } ], "attachment-policies": [ { "rule-number": 100, "conditions": [ { "type": "tag-value", "key": "Network", "value": "Secured", "operator": "equals" } ], "action": { "association-method": "constant", "segment": "secured" } }, { "rule-number": 200, "conditions": [ { "type": "tag-value", "key": "Network", "value": "Non-Secured", "operator": "equals" } ], "action": { "association-method": "constant", "segment": "non-secured" } } ] } ``` # AWS Cloud WAN example: Edge consolidation with isolated VPCs Example: Edge consolidation This policy creates two segments, `development` and `hybrid`. If an attachment comes from a VPC, it will be mapped automatically to the development segment. VPCs that are attached to the development segment cannot talk to each other, and can talk only to the VPN. The development segment has a default route that points to the two attachments (one for each Region) and routes all traffic back on-premises. ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-1" }, { "location": "eu-west-1" } ] }, "segments": [ { "name": "development", "isolate-attachments": true, "require-attachment-acceptance": false }, { "name": "hybrid" } ], "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "development", "share-with": [ "hybrid" ] }, { "action": "create-route", "destination-cidr-blocks": [ "0.0.0.0/0" ], "segment": "development", "destinations": [ "attachment-12355678901234567", "attachment-23456789012345678" ] } ], "attachment-policies": [ { "rule-number": 10, "conditions": [ { "type": "attachment-type", "operator": "equals", "value": "vpc" } ], "action": { "association-method": "constant", "segment": "development" } }, { "rule-number": 20, "conditions": [ { "type": "attachment-type", "operator": "equals", "value": "vpn" } ], "action": { "association-method": "constant", "segment": "hybrid" } } ] } ``` # AWS Cloud WAN example: Three-stage development environment using both tag values and manual shared services mapping Example: Development environment with tags and shared services This policy creates a common software development lifecycle policy. It includes three development stages: development, testing, and production. VPCs in any one of these segments can’t talk to each other because `isolate-attachments` is set to true. These VPC attachments are tagged with their stage, which directly maps to the name of the segment that they should belong to. If developers use the Development or Testing stages, the VPC is automatically mapped without approval, but Production requires approval. There is an additional `sharedservices` segment, which includes both a VPC and a site-to-site VPN. These attachments don’t use tags, but are instead mapped by their explicit resource-ID. The `sharedservices` segment is shared with the isolated development environments so that they can reach on-premises through VPN and can also reach the shared services VPC. ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-1" }, { "location": "us-west-2" } ] }, "segments": [ { "name": "development", "isolate-attachments": true, "require-attachment-acceptance": false }, { "name": "testing", "isolate-attachments": true, "require-attachment-acceptance": false }, { "name": "production", "isolate-attachments": true, "require-attachment-acceptance": true }, { "name": "sharedServices" } ], "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "sharedservices", "share-with": "*" } ], "attachment-policies": [ { "rule-number": 1000, "conditions": [ { "type": "tag-exists", "key": "Stage" } ], "action": { "association-method": "tag", "tag-value-of-key": "Stage" } }, { "rule-number": 1500, "conditions": [ { "type": "resource-id", "operator": "equals", "value": "vpc-1234567890123456" } ], "action": { "association-method": "constant", "segment": "sharedservices" } }, { "rule-number": 1600, "conditions": [ { "type": "resource-id", "operator": "equals", "value": "vpn-1234567890123456" } ], "action": { "association-method": "constant", "segment": "sharedservices" } } ] } ``` # AWS Cloud WAN example: Distributed WAN without VPCs Example: Distributed WAN This network policy creates a network across four Regions for a global wide area network (WAN). This WAN has no connectivity to AWS workloads, and is using the AWS network only as transport between sites and for internet access for sales offices. The IoT network is still under security scrutiny, so attachments within the IoT segment cannot reach each other. However, in this example, SD-WAN has been deployed to the engineering sites and parts of the IoT network. Engineering needs direct access to the IoT network, which is currently a mixture of VPN and SD-WAN. In some cases, the SD-WAN network takes a direct route between sites. When crossing the engineering and IoT segments, it uses the AWS backbone as transport. Because the SD-WAN solution uses Transit Gateway Connect, there is a general pool assigned for Core Network Edge IP address pools. To reduce effort, the administrators allowed the `Assign-to` tag to define which segment the new attachments should be mapped to, but all attachments need to be approved (using the default value for `require-attachment-acceptance`). ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "inside-cidr-blocks": [ "100.65.0.0/16" ], "edge-locations": [ { "location": "eu-central-1" }, { "location": "us-west-2" }, { "location": "us-east-1" }, { "location": "eu-west-1" } ] }, "segments": [ { "name": "sales" }, { "name": "testing" }, { "name": "iot", "isolate-attachments": true }, { "name": "internet" }, { "name": "engineering" } ], "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "internet", "share-with": [ "sales" ] }, { "action": "share", "mode": "attachment-route", "segment": "iot", "share-with": [ "engineering" ] }, { "action": "create-route", "destination-cidr-blocks": [ "0.0.0.0/0" ], "segment": "sales", "destinations": [ "attachment-12355678901234567", "attachment-23456789012345678", "attachment-35567890123456790", "attachment-4567890123456789a" ] } ], "attachment-policies": [ { "rule-number": 1000, "conditions": [ { "type": "tag-exists", "key": "Assign-to" } ], "action": { "association-method": "tag", "tag-value-of-key": "Assign-to" } } ] } ``` # AWS Cloud WAN example: Insert firewalls between on-premises and VPCs Example: Insert firewalls In this policy, the goal is to send all traffic from on-premises to AWS through a firewall. The customer has a VPC with a firewall (AWS Network Firewall, Gateway Load Balancer, or EC2/Marketplace offering) already configured in the VPC. The firewall is responsible for inspecting traffic from on-premises to AWS, and from AWS VPCs in the internalApps segment to the internet. Similar to [Example: Edge consolidation](cloudwan-policy-examples-edge-consolidation.md), the VPC and VPNs are mapped to segments based on the attachment type. The one exception is the firewall VPC, which needs its own specific segment so that it can be shared separately with the other segments. In order to force the traffic coming in from the VPN to a firewall, static routes are configured that point to the firewall. In this case, the AWS VPCs in the internalApps segment are using the `172.16.0.0/16` CIDR space. All other private (RFC1918) space is advertised from the VPN connection. In this case, the policy uses the share and static-route options to define how each of the three segments receive the correct routes to send traffic through a middle box. ``` { "version": "2021.12", "core-network-configuration": { "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-1" }, { "location": "us-west-2" } ] }, "segments": [ { "name": "internalApps" }, { "name": "firewall" }, { "name": "onPremises" } ], "segment-actions": [ { "action": "create-route", "destination-cidr-blocks": [ "0.0.0.0/0" ], "segment": "internalApps", "destinations": [ "attachment-deadbeef901234567", "attachment-eeeeee00000000000" ], "description": "Send all internet headed on-premises through the firewall" }, { "action": "create-route", "destination-cidr-blocks": [ "0.0.0.0/0" ], "segment": "onPremises", "destinations": [ "attachment-deadbeef901234567", "attachment-eeeeee00000000000" ], "description": "Send all traffic received from the VPN through the firewall" }, { "action": "share", "mode": "attachment-route", "segment": "firewall", "share-with": [ "internalAapps", "onPremises" ] } ], "attachment-policies": [ { "rule-number": 500, "description": "We’ll do our specific policies before we do attachment types.", "conditions": [ { "type": "tag-value", "key": "core-network", "operator": "equals", "value": "firewall" } ], "action": { "association-method": "constant", "segment": "firewall" } }, { "rule-number": 1000, "description": "Let’s assume all VPCs are internal apps", "conditions": [ { "type": "attachment-type", "operator": "equals", "value": "vpc" } ], "action": { "association-method": "constant", "segment": "internalApps" } }, { "rule-number": 1500, "description": "Let’s also assume all VPNs are from on-premises", "conditions": [ { "type": "attachment-type", "operator": "equals", "value": "site-to-site-vpn" } ], "action": { "association-method": "constant", "segment": "onPremises" } } ] } ``` # AWS Cloud WAN example: Service insertion firewalls between on-premises and VPCs Example: Service insertion In this policy, traffic on a segment named *development* is first sent to an Inspection VPC before being sent to a segment named *production* using a network function group named *InspectionVPC*. The on-premises attachment has already been set up and mapped to either the `development` or `production` segments. The segment action uses `send-via`, indicating that this is east-west traffic. The attachment policy rule uses the `and` condition logic with `InspectionVpcs` as the value of the key-value pair associated with the attachment. ``` { "version": "2021.12", "core-network-configuration": { "vpn-ecmp-support": true, "inside-cidr-blocks": [ "10.0.0.0/16" ], "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-2" }, { "location": "us-west-2" } ] }, "segments": [ { "name": "development", "edge-locations": [ "us-east-2" ], "require-attachment-acceptance": true, "isolate-attachments": true }, { "name": "production", "edge-locations": [ "us-east-2" ], "require-attachment-acceptance": true, "isolate-attachments": true } ], "network-function-groups": [ { "name": "InspectionVPC", "description": "Route segment traffic to the inspection VPC", "require-attachment-acceptance": true } ], "segment-actions": [ { "action": "send-via", "segment": "development", "mode": "single-hop", "when-sent-to": { "segments": [ "production" ] }, "via": { "network-function-groups": [ "InspectionVPC" ] } } ], "attachment-policies": [ { "rule-number": 125, "condition-logic": "and", "conditions": [ { "type": "tag-exists", "key": "InspectionVpcs" } ], "action": { "add-to-network-function-group": "InspectionVPC" } } ] } ``` # AWS Cloud WAN example: Routing Policies Example: Routing Policies In this policy example, there are three segments **hybrid**, **production** and **development** with on-premises networks onboarding to **hybrid** segment via VPN or Direct Connect attachments and VPCs onboarding to **production** and **development** segments. There are two routing policies defined for filtering routes. Routing policy `100` only allows inbound routes from CIDR ranges `10.10.0.0/16` and `172.16.0.0/16` and is applied via label **inboundRouteFilterHybrid** to all VPN and Direct Connect attachments that connect to remote sites and onboard to the **hybrid** segment (the allow rule will supersede the drop all routes rule that comes afterwards for all matching routes, thus allowing routes matching `10.10.0.0/16` and `172.16.0.0/16` and dropping everything else, the allow rule number must be lower than the drop rule number). Routing policy `200` only allows inbound routes from CIDR range `10.10.0.0/16` and is applied to the segment share between **production** and **hybrid** segment. As a result only `10.10.0.0/16` network routes from on-premises networks are learnt in the **production** segment and all other routes are filtered. Routing policy `300` will drop all routes contained in the prefix list referenced by the alias **prefixListAlias** see [AWS Cloud WAN prefix list associations](cloudwan-prefix-lists.md) on how to setup a core network prefix list association. Routing policy `300` is applied to the segment **production** across the edge locations `us-east-2` and `us-west-2` since `us-east-2` is the first edge location in the segment action definition and the routing policy is inbounds the drop action will affect all routes coming from `us-west-2` going `us-east-2`. ``` { "version": "2025.11", "core-network-configuration": { "vpn-ecmp-support": true, "dns-support": true, "security-group-referencing-support": false, "inside-cidr-blocks": [ "10.0.0.0/16" ], "asn-ranges": [ "64512-65534" ], "edge-locations": [ { "location": "us-east-2" }, { "location": "us-west-2" } ] }, "segments": [ { "name": "hybrid", "require-attachment-acceptance": false }, { "name": "production", "require-attachment-acceptance": true }, { "name": "development", "require-attachment-acceptance": false } ], "network-function-groups": [], "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "inboundRouteFilterProduction" ] }, { "action": "associate-routing-policy", "segment": "production", "edge-location-association": { "routing-policy-names": [ "edgeToEdgeRouteFilterProduction" ], "edge-location": "us-east-2", "peer-edge-location": "us-west-2" } } ], "attachment-routing-policy-rules": [ { "rule-number": 500, "description": "Attachment Route Filters", "conditions": [ { "type": "routing-policy-label", "value": "hybridAttachmentsRouteFilter" // associate this label to all attachments on the hybrid segment } ], "action": { "associate-routing-policies": [ "inboundRouteFilterHybrid" ] } } ], "routing-policies": [ { "routing-policy-name": "inboundRouteFilterHybrid", "routing-policy-description": "Filter all routes landing in hybrid segment from on-premises network except for allowed routes", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ { "rule-number": 100, "rule-definition": { "match-conditions": [ { "type": "prefix-equals", "value": "172.16.0.0/16" }, { "type": "prefix-in-cidr", "value": "10.10.0.0/16" } ], "condition-logic": "or", "action": { "type": "allow" } } }, { "rule-number": 200, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "or", "action": { "type": "drop" } } } ] }, { "routing-policy-name": "inboundRouteFilterProduction", "routing-policy-description": "Filter routes landing in production segment from hybrid segment", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ { "rule-number": 100, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "10.10.0.0/16" } ], "condition-logic": "or", "action": { "type": "allow" } } } ] }, { "routing-policy-name": "edgeToEdgeRouteFilterProduction", "routing-policy-description": "Filter routes between edge locations us-east-1 and us-west-2", "routing-policy-direction": "inbound", "routing-policy-number": 300, "routing-policy-rules": [ { "rule-number": 100, "rule-definition": { "match-conditions": [ { "type": "prefix-in-prefix-list", "value": "prefixListAlias" } ], "condition-logic": "or", "action": { "type": "drop" } } } ] } ] } ```