# Core network policy versions in AWS Cloud WAN
Create a version of your current network policy any time you want to make changes to your network. Policy versions can be created using the console, through either the visual editor mode or directly in JSON, or you can download a version of any policy and make changes to that policy in any JSON editor. Once you create a new version of a policy you can compare that version against an older version to view changes.
New versions of policies are not automatically deployed, so once you create a policy version you can deploy that policy at a time of your own choosing. You can also restore any out-of-date policy to become the new current version.
The name of each policy version you create is numbered incrementally from the LATEST version. For example, if the LATEST policy version ID is `1`, and you create a new version of that policy, the new version is numbered `2`. The latest version is displayed on the Policy versions screen with a **LATEST** status, indicating that the new policy is ready to deploy.
Change set states can be any of the following:
+ **Ready to execute** — A policy version change set and a new policy version have been created. This policy version was verified with no issues and is in a state where it can be deployed as the new LIVE policy. You can have multiple policy versions in this state, but you can only have one LIVE policy. When deployed, the policy change set state changes to **Execution succeeded**. For the steps to deploy a policy change set state, see [Deploy an AWS Cloud WAN core network policy version](cloudwan-policy-version-deploy.md).
+ **Execution succeeded ** — The policy version was deployed as the new LIVE policy.
+ **Out of date** — If you have multiple policy version change sets, any policy version that's older than the current LIVE policy is set to out-of-date, indicating that it's older than the LIVE policy. You can restore an out-of-date policy. For instructions, see [Restore an out-of-date AWS Cloud WAN core network policy version](cloudwan-policy-version-restore.md).
+ **Failed generation** — An error prevented the policy from generating. Choose the Failed generation link to see details about the failure.
+ **Pending generation** — A policy version was created and is waiting to be generated. When the version has been generated, the change set state changes to **Ready to execute**. If policy generation failed, this state changes to **Failed generation**.
You can create a core network policy version through either the AWS Cloud WAN console or by creating or modifying a JSON file.
**Topics**
+ [Core network policy sections](#cloudwan-policy-sections)
+ [Service insertion](cloudwan-policy-service-insertion.md)
+ [Routing policies](cloudwan-routing-policies.md)
+ [Create a policy version using the console](cloudwan-create-policy-console.md)
+ [Create a policy version using JSON](cloudwan-create-policy-json.md)
+ [View a core network policy change set](cloudwan-policy-version-view.md)
+ [Compare policy change set versions](cloudwan-policy-version-compare.md)
+ [Deploy a core network policy version](cloudwan-policy-version-deploy.md)
+ [Delete a policy version](cloudwan-policy-version-delete.md)
+ [Download a core network policy](ccloudwan-policy-version-download.md)
+ [Restore an out-of-date core network policy version](cloudwan-policy-version-restore.md)
## Core network policy sections
The following are the parts of a core network policy and describe how each of these work. If you're using either the console or a JSON file, a policy version is always composed of these sections.
**Topics**
+ [Network configuration](#cloudwan-policy-config)
+ [Segments](#cloudwan-policy-create-segment)
+ [Network function groups](#cloudwan-core-network-function)
+ [Segment actions](#cloudwan-policy-create-action)
+ [Attachment policies](#cloudwan-policy-create-attachment)
+ [Routing policies](#cloudwan-policy-routing-policies)
+ [Attachment routing policies](#cloudwan-policy-create-attachment-routing-policy)
### Network configuration
Use **Network configuration** to configure the Border Gateway Protocol (BGP) Autonomous System Number (ASN) for your core network. The valid ranges are **64512 - 65534** and **4200000000 - 4294967294**. You can also configure the Inside CIDR blocks that are used for BGP peering on Connect peers. For more information on Transit Gateway Connect attachment and Connect peers, see the [Transit Gateway Connect](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html) documentation. Using the network configuration, you can also configure the edge locations where you want the Core Network Edges to be available. At any time, you can add or remove edge locations through the network configuration.
See the following for the steps to configure your network:
+ To configure your network using the console, see [Configure the core network settings in an AWS Cloud WAN policy version](cloudwan-core-network-config.md).
+ To configure your network using a JSON file, see [`core-network-configuration`](cloudwan-policies-json.md#cloudwan-network-config-json) in [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
### Segments
The Segments section of a policy allows to divide your global network into separate isolated networks. Here you create a segment, and then define the attachment communication mapping. Each segment creates a dedicated routing domain. You can create multiple network segments within your global network. Resources that are connected to the same segment can only communicate within the segment. Optionally, you can also set resources in the same segment to be isolated from each other, with access only to shared services. With segments, AWS maintains a consistent configuration across AWS Regions for you, meaning that you don't need to synchronize configuration across every device in your network.
See the following for the steps to add segments to your core network:
+ To add a segment using the console, see [Add a segment to an AWS Cloud WAN core network policy version](cloudwan-policy-segments.md).
+ To add a segment using a JSON file, see [`segments`](cloudwan-policies-json.md#cloudwan-segments-json-about) in [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
### Network function groups
A network function group is composed of a group of attachments used to steer those attachments to network security group functions. For example, you might create a network function group that steers traffic from a production segment through an inspection VPC directly to the Internet.
Optionally use the **Network function groups** page to create a group that allows you to insert AWS and third-party networking and security services on Cloud WAN using your policy document. After creating a network function group you'll create a segment action that defines how you want to steer the segments and attachments for the network function group.
+ For the steps to create a network function group using the console, see [Create a network function group in an AWS Cloud WAN policy version](cloudwan-policy-network-function-groups.md).
+ For the steps to create a network function group using JSON, see [`network-function-groups`](cloudwan-policies-json.md#cloudwan-network-functions-json) in [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
### Segment actions
Segment actions allow you to optionally share your segments, create routes, or create a service insertion action for a network functions group.
+ **Segment sharing** — Segment sharing is bidirectional by default. When you create a segment share between two segments, routes from both segments are automatically advertised to each other. For example, you might share a segment named `test` with another segment named `dev`. Routes from `test` are advertised to `dev`, and vice versa. To make routes in shared segments unidirectional, create a deny list filter to share routes from one segment to the other, but not vice versa. Using the previous example, you could make a deny list filter that prevents routes from `test` being advertised to `dev`. For more information on creating the deny list for a segment, see [Add a segment to an AWS Cloud WAN core network policy version](cloudwan-policy-segments.md). In addition, you can optionally associate routing policies that will apply to the segment share.
+ **Edge location routing policy association ** — Associate routing policies to pair of edge locations for a particular segment.
+ **Segment routes** — Create a segment route to define a static route within a segment.
+ **Service insertion** — Create a service insertion action that allows you to insert a network function within a segment or across segments. This action can either be send via (east-west) or send to north-south). For more information about traffic actions and modes see [Traffic actions and modes](cloudwan-policy-service-insertion.md#cloudwan-policy-service-insertion-modes). You can additionally choose to specify which edge locations you want to use. Service insertion uses a default order for choosing the edgte locations. However, you can specify which edges you want to use as well as which edge is the preferred edge.
See the following for the steps to set segment actions:
+ To add a segment using the console, see [Add segment actions in an AWS Cloud WAN core network policy version](cloudwan-policy-network-actions-routes.md).
+ To add a segment using a JSON file, see [`segments`](cloudwan-policies-json.md#cloudwan-segments-json-about) in [`segment-actions`](cloudwan-policies-json.md#cloudwan-segment-actions-json) in [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
### Attachment policies
Attachment policies control how your attachments map to your segments or network function groups. You create a network function group attachment policy using either the AND or OR subset of conditions along with either the full tag name or tag value.
See the following for the steps to create a network functions group attachment policy:
+ To add an attachment policy using the console, see [Create an attachment policy in an AWS Cloud WAN core network policy version](cloudwan-policy-attachments.md).
+ To add an attachment policy using a JSON file, see [`attachment-policies`](cloudwan-policies-json.md#cloudwan-attach-policies-json) in [`segment-actions`](cloudwan-policies-json.md#cloudwan-segment-actions-json).
### Routing policies
Routing policies provide new routing capabilities that allow you to implement fine-grained routing controls, route filtering, summarization, and path preferences. You can create routing policy associations to apply policies to specific segment shares, edge location pairs, and attachments with rules that define how routes are processed.
Routing policy associations can be broken down into two main components:
+ **Segment Share/Edge Location Pairs** — Associate routing policies with specific segment shares or edge location pairs to control traffic flow between different parts of your network.
+ **Attachment routing policies** — Create rules-based policies that determine which routing policies are associated with attachments.
See the following for the steps to configure routing policies:
+ To configure routing policies using the console, see [Create a routing policy and rule](cloudwan-route-policy.md).
### Attachment routing policies
Attachment routing policies control how your attachments map to your routing policies. Attachment routing policies are separate from the attachment policy section and only control associating attachments with routing policies via a label on the attachment.
See the following for the steps to create an attachment routing policy:
+ To add an attachment routing policy using the console, see [Create an AWS Cloud WAN attachment routing policy](cloudwan-policy-attachment-routing.md).
# AWS Cloud WAN service insertion
Service insertion allows you to steer same-segment or cross-segment traffic using network functions deployed in VPCs or on-premises networks attached to Cloud WAN. Network functions can be third-party network or security appliances such as NGFW, IDS, IPS appliances or native AWS network firewall or Gateway Load Balancer services. Using either the AWS Network Manager console or a JSON file, you'll create a version of one of your core network policies, create a network function group that contains a set of core network attachments where your network functions reside, and specify a segment or segment pairs for which traffic needs to be redirected to those network functions. Once the policy version is deployed and your new core network LIVE, Cloud WAN will automatically redirect network traffic between the segments to the specified core network attachments for the respective network function group. This redirection works for both same Region and cross-Region traffic on the core network. Service insertion works on both east-west (VPC to VPC) and north-south (VPC to the Internet or on-premises location) traffic.
To create a core network that includes service insertion, you'll need to do the following:
1. **Create a policy version of a current policy**. The initial policy you deploy when you create your first core network doesn't include any service insertion features. To do this you'll create a version of an existing policy and add the service insertion features. You can do this using either the AWS Network Manager console or through a JSON file.
You can create a policy version containing the service insertion action using either the AWS Network Manager console or through creating a JSON file which you can also create using the console:
+ To create a policy version using the console, see [Create an AWS Cloud WAN core network policy version using the console](cloudwan-create-policy-console.md).
+ To create a policy version using a JSON file, see [Create an AWS Cloud WAN core network policy version using JSON](cloudwan-create-policy-json.md).
1. Using either the console or within the JSON file you'll do the following:
1. **Configure your core network**. Set the BGP and ASN for this core network policy.
1. **Add segments**. Add segments to your core network policy. Segments with cross-segment or same-segment traffic that must be steered via the network functions. Based on your policy configuration, Cloud WAN will automatically propagate routes from VPCs and networks associated to the network function groups and redirect VPC-to-VPC or VPC-to-Internet or on-premises traffic through a network functions group.
1. **Create a network function group**. The network function group is a collection of attachments specifically used for network or security functions.
**Note**
You can only have one attachment per network function group per Region.
1. **Set segment actions**. Segment actions allow you to share segments, create routes, and create a service insertion action.
For the service insertion action, you can create a send via action which sends traffic east-west between all VPCs. Or you can create a send to action, which first sends traffic to a security appliance and then out from the appliance. For example, you might create segment action using send via. With send via (east-west traffic), traffic is routed to the Inspection VPC for security processing and then re-enters the Cloud WAN core network to reach its final VPC destination. See [Traffic actions and modes](#cloudwan-policy-service-insertion-modes) below for more information about traffic actions and modes.
By default, Cloud WAN will select an attachment in one of the two Regions used for the network function. For example, if the network function is steering traffic to an Inspection VPC, and that Inspection VPC exists in only one Region, Cloud WAN uses the Region where the Inspection VPC resides to steer all cross-Region traffic. If the Inspection VPC exists in both Regions, service insertion will deterministically choose which Region to use based on the [default Region priority list](what-is-cloudwan.html#cloudwan-available-regions). However, when setting the segment actions, you can choose the Region priority order as well as choose the preferred Region to use. If the Inspection VPC doesn't exist in either Region, Cloud WAN uses the fallback Region specified in the segment policy. You can only specific a single fallback Region per segment policy.
1. **Create an attachment policy for the network function group**. Add the network function group to an attachment policy. The attachment policy then controls the order in which the network function group runs.
1. Deploy the policy version. See [Deploy an AWS Cloud WAN core network policy version](cloudwan-policy-version-deploy.md).
## Benefits
+ **Simplified routing** — Service insertion allows for more simplified routing. You might need inter-VPC or VPC to internet or on-premises traffic to be routed through network appliances, such as network firewalls or load balancers. With Cloud WAN service insertion you can more easily steer network traffic to network or security appliances deployed in VPCs or in on-premises. This allows you to create and manage sometimes complex routing configurations or third-party automation tools.
+ **Ease of deploying multi-Region inspection** — You might deploy Cloud WAN in multi-Region networks to support Region expansion or disaster recovery use cases. Service insertion simplifies mutli-Region deployment, allowing you to steer both intra-Region and inter-Region traffic through your security infrastructure without having to set up complex multi-Region network configurations.
## Traffic actions and modes
Service insertion supports the following traffic actions and modes for both east-west and north-south traffic.
+ Send via — Traffic flows east-west between VPCs. All traffic for the service insertion action is first sent via a specific segment to the security appliance and then out to other VPCs. Send via is a bi directional action so if you have a send via action from Segment A to Segment B you do not need to also specify a send via action of Segment B to Segment A.
+ Single hop — Traffic traverses a single intermediate attachment, using the deterministically preferred source or destination Region. You can set a list of Regions to use, as well as setting a preferred Region to use as a priority.
+ Dual hop — Traffic traverses inserted attachments in both the source and destination core network edges. For this option, the inspection attachment should be located in both Regions for each service insertion-enabled segment.
+ Send to — Traffic flows north-south. That is, traffic flows into the network appliance, such as an Inspection VPC, and out to the Internet or to an on-premises location. Traffic does not re-enter the AWS cloud.
**Note**
If a network function group is used by a send via dual hop action it cannot be reused for a single hop or a send to action.
## Attachments
Within a network function group you can specify a set of core network attachments where your network functions will reside. For example, the attachment might be a VPC that you use for inspection. You'll then add a segment or segment pair to this attachment that will be redirected to the network functions group and then to the security appliance. Cloud WAN automatically redirects traffic on any segment you add to that VPC when creating a service insertion action to that group both in the same Region and cross-Region within the core network.
In order to make an attachment be part of the network function group correctly, service insertion relies on the key-value pair tags added to an attachment. When creating an attachment you'll need to add the relevant tag to each attachment. For example, you might want to use a particular attachment as an Inspection VPC. You could add a tag with the key name *Inspection VPC* and then a key value of *InspectionVpcs*. The same tag should be applied to any attachment you add to that network function group. When you create a service insertion function, you'll add an attachment policy rule that relies on the key tags and values added to those attachments in order to process the tag key. In this example, you'd add a policy rule that identifies the tag *Inspection VPC* and the key value of *InspectionVpcs*. Attachment policy rules can be created using either the AWS Cloud WAN console or through a JSON file. For the steps for either method, see [Attachment policies](cloudwan-create-policy-version.md#cloudwan-policy-create-attachment).
**Important**
A network function group need not be associated with an attachment in order for the attachment policy to succeed. If you specify segment actions of **send-to** or **send-via** to a network function group with no attachments associated to it, the Cloud WAN policy execution will still be successful; however, all traffic destined to that network function group will be blackholed until you associate attachments to that group in appropriate Regions.
The following are the supported core network attachments:
+ Connect
+ Direct Connect gateway
+ Transit gateway route table
+ VPC
+ VPN
## Considerations
+ **Attachments** — You can associate an attachment either with a segment or with a network function group, but it can't be associated with both.
+ **Isolated mode** — Isolated mode is required for service insertion to work between attachments belonging to the same segment. This setting ensures there is no direct connectivity between attachments associated with the same segment by bypassing the network functions group.
+ **Appliance mode** — Appliance mode must be enabled on the Inspection VPC to ensure that traffic moves in both directions.
+ **Route propagation** — Static routes defined in your Cloud WAN policy are not automatically propagated to Network Function Group route tables. Route propagation to NFGs requires specific configuration in your policy to define which routes should be available to the network functions. In some situations, BGP route updates for Network Function Group route tables may take up to 30 minutes to display in the GetNetworkRoutes API and console. This delay does not affect the actual routing functionality.
+ **Routing Information** — When checking the routing information for a core network segment with Service Insertion send to enabled you may see a 0/0 and ::/0 CIDR block route being blackholed. This is expected behavior and you can confirm that those destinations point to the correct location when viewing the route tab on the console or the get-network-routes API.
## Pricing
There are no additional charges for using service insertion other than the standard AWS Cloud WAN pricing charges. Information about Cloud WAN pricing can be found here: [AWS Cloud WAN Pricing](https://aws.amazon.com/cloud-wan/pricing/).
# AWS Cloud WAN Routing policies
Cloud WAN Routing Policies provide customers fine-grained routing controls to optimize route management and customize network routing behavior per their individual needs. A routing policy is a set of rules that gives you precise control over route propagations in your core network allowing you flexible routes management, optimized performance and greater security by controlling your routing and reachability in your global network. Using this feature, customers can perform advanced routing techniques such as route filtering and summarization to have better control on routes exchanged across Cloud WAN and your external networks connected to Cloud WAN.
This feature allows customers to set advanced Border Gateway Protocol (BGP) attributes to customize network traffic behavior per their individual needs and build highly resilient hybrid-cloud network architectures with multiple connectivity paths to AWS. Furthermore, this feature also provides enhanced visibility into the routing databases to allow rapid troubleshooting of network issues in complex multi-path environments.
## Key use-cases
### Controlled routing environments
While customers benefit from end-to-end dynamic routing across their Cloud WAN, they also want to control which networks and resources (prefixes) can route across their global networks. Controlled routing environments are necessary to:
+ Selectively filter or propagate routes to achieve specific connectivity goals
+ Minimize routing reachability blast radius
+ Prevent sub-optimal or asymmetric connectivity patterns
+ Avoid over-running of route tables due to propagation of unnecessary routes in global networks
+ Protect against misconfiguration that can cause unintended route propagations such as incorrect VPC CIDRs or on-premises route advertisements
### Optimize connectivity in multi-path environments
Customers build multiple connectivity paths between Cloud WAN and their on-premises networks for network resiliency and high availability. It is also common to run into ad-hoc multi-path scenarios where same destination prefixes are learnt over multiple network paths in large BGP-based dynamic networks. In such scenarios, customers want the ability to dictate what paths the network traffic should take by manipulating BGP path preference attributes. Advanced routing policy capability on Cloud WAN allows customers to manipulate standard BGP attributes for selecting optimal path to route network traffic in multi-pathing environments.
## Key benefits
+ **AWS-native advanced routing capability** — Eliminates the need for customers to invest in expensive third-party routing solutions that can be complicated and hard to manage. Providing native advanced routing policy in Cloud WAN removes the need for hard to manage and expensive third-party routing solutions.
+ **Advanced visibility** — Visibility into route exchanges in an end-to-end dynamically routed network such as Cloud WAN is mandatory for customers to perform Day N operations such as network planning and troubleshooting. This feature provides visibility into the BGP routes that are dynamically learnt and advertised along with the advanced BGP attributes enabling customers to troubleshoot and resolve complex network issues in their Cloud WAN based global networks.
## Advanced routing capabilities
Cloud WAN Routing Policy supports the following capabilities:
+ **Route filtering** — Filter (drop) routes from incoming and outgoing route propagations over Cloud WAN attachments. You can set advanced routing policy rules to match one or more prefixes, prefix lists or BGP communities and drop those routes from inbound or outbound route propagations on an attachment. You can also apply these route filtering rules for routes propagated across segments and across regions on the core network (CNE-to-CNE) peering mesh.
+ **Route summarization** — Summarize or aggregate routes outbound on Cloud WAN attachments by specifying the desired summary route. You can set an outbound route policy with rules to match on prefixes or prefix lists and specify a summary route to propagate.
+ **Path preferences** — Set path preferences to influence incoming and outgoing traffic paths between your Cloud WAN (core network) and external networks. You can set path preferences by modifying BGP attributes such as local preference, AS-PATHs and MED on inbound and outbound route propagations.
+ **BGP communities** — Transitively pass BGP communities in outbound route updates, match on BGP communities that are part of inbound route updates, and perform actions such as route filtering, setting path preference attributes or adding and removing BGP communities in outbound route updates.
## Attachment type support
The Cloud WAN Routing Policy feature is supported on all AWS Cloud WAN attachment types, including AWS Site-to-Site VPN, AWS Direct Connect, Connect attachments, peering attachments (Transit Gateway route table), and VPC attachments, as well as on routes propagated across segments and Regions (CNE-to-CNE).
Route summarization and BGP attribute modification are supported only on BGP-capable attachments—Site-to-Site VPN, Direct Connect, Connect, and peering—as well as on inter-segment and inter-Region (CNE-to-CNE) propagated routes. For VPC attachments, support is limited to route filtering rules (“allow” or “drop” actions) for inbound route propagation from the VPC to the core network. BGP communities are supported on Site-to-site VPN and Connect attachments.
## Key considerations
The following is a list of considerations that should be taken into account before using Cloud WAN Routing Policies:
+ VPC attachments don't support BGP attribute modification
+ Summarization only works outbound and on BGP-capable attachments
+ Routing policies associated across segments and regions are unidirectional
+ No BGP community support on Direct Connect and TGW Peering attachments
+ ASNs specified in the routing policy (replace/remove ASN, community tags) cannot overlap with the ASN range specified in the core network configuration. This also means you cannot advertise communities into a core network that contain an ASN currently in use by the core network.
+ Replace ASN is not support cross-region (CNE-to-CNE)
+ Prefix list alias's must be unique per prefix list core network association
+ Prefix list modifications of entry values to the underlying core network routing state may not align with the prefix list state.
+ Routing policies are not supported for NFGs (Service Insertion)
+ Segment share policies are applied after attachment policies
+ External AWS devices cannot advertise routes with BGP communities containing internal ASNs
+ The list-core-network-routing-information API shows the routing information before routing policies have been applied
+ Route summarization will remove all matched prefixes and replace them with a single summarized route. The summarized prefix will be advertised at the same time as matched prefixes are withdrawn.
+ TGW Route Table Attachments that use the same Peering and are associated to the same segment will share the same outbound routing policies across all similar attachments. This means if you have TGW Route Table Attachment attachment-1 with outbound routing policy 1 on segment prod and peering 1 and you have TGW Route Table Attachment attachment-2 with outbound routing policy 2 on segment prod and peering 1, then both attachment-1 and attachment-2 will have both have routing policy 1 and routing policy 2 applied to both of the attachments.
# Create an AWS Cloud WAN core network policy version using the console
Use the Network Manager console to create a core network policy version. The console provides separate tabs for you to configure a network policy version, including the new routing policy capabilities. The following steps describe the high-level process.
1. [Configure the core network settings in an AWS Cloud WAN policy version](cloudwan-core-network-config.md).
You'll first set the network configuration parameters, including adding ASN ranges, CIDR blocks, and the edge locations to include in the policy.
1. [Add a segment to an AWS Cloud WAN core network policy version](cloudwan-policy-segments.md).
After defining the network configuration parameters, you'll add network segments and define the behavior for those segments. For example, you might want to include a segment that requires attachment acceptance.
1. [Create a network function group in an AWS Cloud WAN policy version](cloudwan-policy-network-function-groups.md).
The network function group provides an added level of security if you want to first steer specific segments to a third-party security device or an Inspection VPC. A network function group is the parent object for the segments you want to route to security appliances.
1. [Create an AWS Cloud WAN route policy and rule](cloudwan-route-policy.md).
Create routing policies with rules that define how routes are filtered, summarized, or modified based on specific conditions and actions.
1. [Add segment actions in an AWS Cloud WAN core network policy version](cloudwan-policy-network-actions-routes.md).
Define segment actions, such as sharing a segment, creating a segment route, edge location route policy associations, or creating a service insertion action for the network function group.
1. [Create an AWS Cloud WAN attachment routing policy](cloudwan-policy-attachment-routing.md).
Create attachment routing policies with rules that define how attachments are associated to routing policies.
1. [Create an attachment policy in an AWS Cloud WAN core network policy version](cloudwan-policy-attachments.md).
Finally, you'll create an attachment policy that defines the order when segments or network function groups should be run in the core network policy.
**Topics**
+ [Configure the core network settings](cloudwan-core-network-config.md)
+ [Add a segment](cloudwan-policy-segments.md)
+ [Create a network function group](cloudwan-policy-network-function-groups.md)
+ [Add a segment action](cloudwan-policy-network-actions-routes.md)
+ [Create a core network attachment policy](cloudwan-policy-attachments.md)
+ [Create a route policy and rule](cloudwan-route-policy.md)
+ [Create an attachment routing policy](cloudwan-policy-attachment-routing.md)
# Configure the core network settings in an AWS Cloud WAN policy version
The following steps guide you through configuring a core network for a policy version using the **Policy versions** link on the AWS Network Manager console. For more information about a core network in a policy version, see [Network configuration](cloudwan-create-policy-version.md#cloudwan-policy-config).
**To configure network for a policy version**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. In **Choose policy view mode**, choose **Visual editor**.
1. The **Network configuration** displays general settings for the policy.
1. In** General settings,** choose **Edit**.
1. The **Version** choose any of the following:
+ **2021.12** this version does not support routing policies or bgp community tag propagation through your core network
+ **2025.11** this version enables support for routing policies and bgp community tag propagation through your core network
1. Choose any of the following:
+ **VPN ECMP support** if the core network should forward traffic over multiple-cost routes using VPN.
+ **DNS support** if you want to use DNS resolution for the core network.
+ **Security Group Referencing support** if you want to enable security group referencing for VPC attachments in the core network. For more information about security group referencing, see [Security group referencing](cloudwan-vpc-attachment.md#cloudwan-sg-referencing).
1. Choose **Edit general settings**.
1. In the **ASN ranges** section, do the following:
1. Choose **Create**.
1. For **ASN range**, enter the ASN range for the policy version. For example, enter **64512-65334**.
**Note**
The **ASN range** is left-closed and right-open. This means that the leftmost number is included in the range but the rightmost number is not. For example, if you choose an ASN range of **64900-64903**, the actual available ASN range is **64900** through **64902**. **64903** is not included.
1. Choose **Create ASN range**.
1. In the **Inside CIDR blocks** section, do the following:
1. Choose **Create**.
1. For **CIDR**, enter the CIDR block that you want to use for BGP peering on Connect peers.
1. Choose **Create inside CIDR block**.
1. In the **Edge locations** section, do the following:
1. Choose **Create**.
1. From the **Location** dropdown list, choose the **Region** where you want the Core Network Edge router to be created. You can choose only one Region.
1. For **ASN**, enter the ASN number for the Region.
**Note**
You can't change the ASN of a core network edge. Any transit gateway with the same ASN can't be peered to that core network edge. For example, if you have a core network edge with an ASN of `64512`, you can't peer any transit gateway that also has an ASN of `64512`.
1. For **Inside CIDR block**, enter the CIDR block that you want to use for BGP peering on Connect peers. You can enter multiple CIDR blocks by choosing **Add** for each block that you want to add. Choose **Remove** for any block that you don't want.
**Note**
You can't leave any blank destination CIDR blocks. Choose **Remove** to delete any empty blocks.
1. Choose **Create edge locations**.
# Add a segment to an AWS Cloud WAN core network policy version
The following steps guide you through configuring a core network for a policy version using the **Policy versions** link on the AWS Network Manager console. Before adding a segment you must first have configured your [network settings](cloudwan-core-network-config.md). For more information, about network Segments, see [Segments](cloudwan-create-policy-version.md#cloudwan-policy-create-segment).
**To configure a segment**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose **Segments**.
1. In the **Segments** section, Choose **Create**.
1. Enter the **Segment name** and **Segment description** to identify the segment.
1. From the **Edge locations** dropdown list, choose one or more segments to create.
1. Choose **Require acceptance** if you require approval for attachments to be mapped to this segment.
1. Choose **Isolated attachments** if you need this segment isolated. Attachments in isolated segments can't communicate with other segments, and attachments in other segments can't communicate with the isolated segment.
**Important**
** Isolated attachments** is required if you're adding an intra-segment for use with service insertion.
1. For the **Segment filter**, choose if you want to **Allow all** shared routes from other segments, to **Allowed selected** segments, or to **Deny selected** segments. The default value is to **Allow all** segments.
1. (Optional) If you want to limit your edge locations for the segment, choose **Choose edge locations**, and then choose the edge locations you want to limit the segment to.
1. Choose **Create policy**.
# Create a network function group in an AWS Cloud WAN policy version
The following steps guide you through configuring a core network for a policy version using the **Policy versions** link on the AWS Network Manager console. There are no prerequisites for creating a network functions group. For more information, about network function groups, see [Network function groups](cloudwan-create-policy-version.md#cloudwan-core-network-function).
**To route traffic using a network function group**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. In **Choose policy view mode**, choose **Visual editor**.
1. Choose **Network function groups**.
1. Choose **Create**.
1. Enter a **Name** identifying this function, and then provide an optional **Description**.
1. If the attachment association requires acceptance, choose **Require acceptance**.
**Note**
An attachment can be associated only with a segment or a network functions group, but not both. You can't associate an attachment to a network functions group if that attachment is already associated with a segment.
1. Once you've created the network function group, you can create a service insertion segment action that routes your network functions from source segments to destination segments using this network function group. For more information on creating a segment action, see "Service insertion" in [Add segment actions in an AWS Cloud WAN core network policy version](cloudwan-policy-network-actions-routes.md).
# Add segment actions in an AWS Cloud WAN core network policy version
The following steps guide you through optionally setting segment actions for a core network for a policy version using the **Policy versions** link on the AWS Network Manager console. Before setting segment actions you must first configure your [network settings](cloudwan-core-network-config.md) and [add one or more segments](cloudwan-policy-segments.md). For more information, about segment actions, see [Segment actions](cloudwan-create-policy-version.md#cloudwan-policy-create-action).
**Topics**
+ [Segment sharing](#cloudwan-policy-network-actions-sharing)
+ [Segment routes](#cloudwan-policy-version-routes)
+ [Edge location routing policy associations](#cloudwan-policy-routing-associations-console)
+ [Service insertion](#cloudwan-policy-service-insertion)
## Segment sharing
Create a shared segment between two segments.
Segment sharing is bidirectional by default. When you create a segment share between two segments, routes from both segments are automatically advertised to each other. For example, you might share a segment named `test` with another segment named `dev`. Routes from `test` are advertised to `dev`, and vice versa. To make routes in shared segments unidirectional, create a deny list filter to share routes from one segment to the other, but not vice versa. Using the previous example, you could make a deny list filter that prevents routes from `test` being advertised to `dev`. For more information on creating the deny list for a segment, see [Add a segment to an AWS Cloud WAN core network policy version](cloudwan-policy-segments.md).
**Static route propagation in segment sharing**
Static routes are not propagated between shared segments when using attachment-route mode. Only attachment routes (routes to directly connected attachments) are shared between segments. If there are static routes or routes shared from other segments, those will not be shared through the attachment-route mode. Static routes remain within their intended segment boundaries and must be explicitly created in each segment where they're needed using multiple create-route statements.
**To create a shared segment**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose **Segment actions - optional**.
1. (Optional) In the **Sharing** section, choose **Create**, and then do the following:
1. From the **Segment from** dropdown list, choose the core network segment that you want to share.
1. For the **Segment to**, choose if you want to **Allow all** shared routes from other segments, to **Allowed selected** segments, or to **Deny selected** segments. The default value is to **Allow all** segments.
1. Do one of the following:
+ If you chose **Allow selected**, choose the segments to allow from the **Allow segment list**.
+ If you chose **Deny selected**, choose the segments to disallow from the **Deny segment list**.
1. (Optional) If you've created a routing policy, select the **Routing policy** to choose the routing policies to apply this segment sharing to.
1. Choose **Create sharing**.
## Segment routes
Create a segment route for a policy version.
**To create a segment route**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose **Segment actions - optional**.
1. (Optional) In the **Routes** section, choose **Create**, and then do the following:
1. From the **Segment** dropdown list, choose the core network segment that you want to share.
1. For **Destination CIDR Block**, enter a static route. You can enter multiple CIDR blocks by choosing **Add** for each block that you want to add. Choose **Remove** for any blocks that you don't want.
**Note**
You can't leave any blank destination CIDR blocks. Choose **Remove** to delete any empty blocks.
1. Choose **Blackhole** if you want to "black hole" the route. If you make this choice, you can't add any attachments to the route.
1. From the **Attachments** list, choose any attachments that you want to include in this route.
1. Choose **Create segment route**.
1. (Optional) Add **Attachment policies**. For more information, see [Create an attachment policy in an AWS Cloud WAN core network policy version](cloudwan-policy-attachments.md).
1. Choose **Create route**.
## Edge location routing policy associations
Associating a routing policy to an edge location pair allows you to control how traffic flows between two specific geographic locations in your network, overriding default routing behavior. This provides control for performance optimization, cost management, failover scenarios, and compliance requirements between those specific locations.
**To create routing policy associations**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose **Segment actions - optional**.
1. (Optional) In the **Edge location routing policy associations** section, choose **Associate**, and then do the following:
1. From the **Segment from** dropdown list, choose the segment for the routing policy association.
1. From the **Edge location** dropdown list, choose the source edge location.
1. From the **Peer edge location** dropdown list, choose the destination edge location.
1. From the **Routing policy name** dropdown list, choose the routing policy to associate with this segment and edge location pair.
1. Choose **Associate**.
For more information on the parameters used in the JSON file, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
```
{
"segment-actions": [
{
"action": "associate-routing-policy",
"segment": "prod",
"edge-location-association": {
"edge-location": "us-east-1",
"peer-edge-location": "us-west-2",
"routing-policy-names": ["routingFilter"]
}
}
]
}
```
## Service insertion
Create a segment route for a policy version.
**To set up service insertion for a segment**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose ** Segment actions - optional**.
**Note**
You must first have created your segments and network functions group.
1. If you want to create a service insertion action associated with a network functions group in the **Service insertion** section, choose **Create**, and then choose an **Action**. If you're not creating a service insertion action, this is an optional section.
------
#### [ Send via ]
This **Action** uses an east-west traffic pattern from attachment to attachment. For example, you might create a policy that directs all traffic between a segment named *Production* and all other segments via inspection VPC attachments.
1. For the **Mode**, choose one of the following:
+ **Single hop** — This option steers traffic through a single intermediate attachment.
+ **Dual hop** — Traffic traverses the inserted attachments in both the source and destination core network edges.
1. For **Segment from**, choose the source segment.
1. For **Segment to**, choose the destination segments.
1. For **Send traffic via**, choose the network functions group that you want to use for the service insertion.
1. (Optional) In **Edge overrides**, choose **Add**.
+ From the **Edge 1** and **Edge 2** drop-down lists, choose the edge locations for the overrides. the service the priority order for the edge locations to route traffic.
+ Choose the **Preferred edge** drop-down list to choose which edge location you prefer to use.
+ Choose **Add** to include additional edge overrides.
------
#### [ Send to ]
This **Action** uses north-south traffic, sending traffic to the security appliance, such as an Inspection VPC or firewall, and then out to the Internet or an on-premises location.
1. For **Segment from**, choose the segment coming into the security appliance. For example, you might have a segment named *production* that you want to first go to a security appliance.
1. For **Send traffic via**, choose the network functions group that you want to use for the service insertion.
1. Optional) In **Edge overrides**, choose **Add**.
+ From the **Edge 1** and **Edge 2** drop-down lists, choose the edge locations for the overrides. the service the priority order for the edge locations to route traffic.
+ Choose the **Preferred edge** drop-down list to choose which edge location you prefer to use.
+
+ Choose **Add** to include additional edge overrides.
------
1. Choose **Create service insertion**.
1. (Optional) Add **Attachment policies**. For more information, see [Create an attachment policy in an AWS Cloud WAN core network policy version](cloudwan-policy-attachments.md).
# Create an attachment policy in an AWS Cloud WAN core network policy version
The following steps guide you through configuring a core network for a policy version using the **Policy versions** link on the AWS Network Manager console. For more information about attachment policies, see [Attachment policies](cloudwan-create-policy-version.md#cloudwan-policy-create-attachment).
An attachment policy requires the following:
+ The core network configured. See [Configure the core network settings in an AWS Cloud WAN policy version](cloudwan-core-network-config.md).
+ One or more segments. See [Segments](cloudwan-create-policy-version.md#cloudwan-policy-create-segment).
+ If you are optionally creating a service insertion action, you'll first need the following:
+ A network functions group. See [Network function groups](cloudwan-create-policy-version.md#cloudwan-core-network-function).
+ At least one attachment. Supported attachment types are Connect, Direct Connect gateway, transit gateway route table, VPC, and Site-to-Site VPN. For more information about attachments, see [Attachments in AWS Cloud WAN](cloudwan-create-attachment.md).
**Important**
An attachment is required when creating a policy that includes a service insertion action. If there is no associated attachment in the policy, traffic will be dropped instead of being redirected to a specified network function group.
**To create an attachment policy**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. Choose **Attachment policies**.
1. Choose **Create**.
1. For the **Rule number**, enter the rule number to apply to this attachment. Rule numbers determine the order in which rules are run.
1. Enter an optional **Description** to identify the attachment policy.
1. In the **Action** section, choose how you want to associate the attachment to the segment. Choose one of the following:
+ **Segment name** — associates the attachment by the segment name. After choosing this option, the segment to attach to from the **Attach to segment** dropdown list.
+ **Attachment tag value** — associates the attachment by the tag's value in a key-value pair. Enter the tag value in the **Attachment tag** value field.
+ **Network function group **— creates an attachment policy rule for service insertion. Choose a network functions group for the service insertion policy. This option requires that you choose **Condition logic **and then the **AND** operator. For the **Type** you can choose the **Tag name **, **Tag value**, or both.
1. Choose one of the following:
+ **Inherit segments acceptance value** if the attachment inherits the acceptance setting from a segment when a segment was created. This can't be changed.
+ **Requires attachment acceptance** if you require approval for attachments to be mapped to this segment.
+ If no acceptance option is chosen, attachments are automatically mapped to the segment.
**Note**
If `require-attachment-acceptance` is `false` for a segment, it's still possible for attachments to be added to or removed from a segment automatically when their tags change. If this behavior is not desired, set `require-attachment-acceptance` to `true`.
1. (Optional) For **Condition logic**, further refine how the attachment is associated with the segment.
**Important**
**Condition logic** is required using **AND** for a network functions group attachment policy rule. The **AND** condition must use a **Tag name** or **Tag value** associated with the attachment.
+ Choose **OR** — if you want to associate the attachment with the segment by either the **Segment name**/**Attachment tag value**, *or* by the chosen conditions.
+ Choose **AND** — if you want to associate the attachment with the segment by either the **Segment name**/**Attachment tag value** *and* by the chosen conditions.
If no acceptance option is chosen, attachments are automatically mapped to the segment.
1. In **Conditions**, set the condition logic by doing the following:
1. From the **Type** dropdown list, choose one of the following condition types:
+ **Resource Id ** — Set an **OR** or **AND** condition that uses a Resource ID.
+ **Attachment type** — Set an **OR** or **AND** condition that matches a specific attachment type.
+ **Account** — Set an **OR** or **AND** condition that matches an account.
+ **Tag name** — Set an **OR** or **AND** condition that matches a specific tag name.
+ **Tag value** — Set an **OR** or **AND** condition that matches a specific tag value.
**Important**
**Tag name** and **Tag value** are the only supported and available **Conditions** for a **Network function group** attachment policy.
1. From the **Operator** dropdown list, choose one of the following operators. The operator determines the relationship of the Type.
**Note**
Operators are not supported when for a network function group attachment policy when the **Type** is **Tag name**. The full tag name must be used.
+ **Equals** — Filters results that match the passed **Condition value**.
+ **Not equals** — Filters results that do not match the passed **Condition value**. This option is not used for **Attachment type**.
+ **Begins with** — Filters results that start with the passed **Condition value**. This option is not used for **Attachment type**.
+ **Contains** — Filters results that match a substring within a string. This option is not used for **Attachment type**.
+ **Any** — Filters results that match any field. This option is not used for **Attachment type**.
1. In the **Condition values** field, enter the value that corresponds to the **Type** and **Operator**. This option is not used for **Attachment type**. If you're creating a network function group attachment policy, the full tag name or value are required. Partial C
1. Choose **Add** to include additional conditions or choose **Remove** to delete any conditions.
1. Choose **Create attachment policy**.
1. Choose **Create policy**.
## Example condition logic for a network function group attachment policy
The following shows a partial JSON example using the OR operator for a network function group attachment policy.
+ There are two segments, `production` and `development`.
+ Rule numbers are manually assigned to each attachment policy for rule processing. Rules are then processed in numerical order according to the number assigned to them. In this example, the rule number is assigned `600` .
+ Using the OR Condition logic, the network function group attachment policy looks for any segment with the value `production` or `development`.
For more information on the parameters used in the JSON file, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
```
{
"rule-number": 600,
"condition-logic": "or",
"conditions": [
{
"type": "tag-value",
"operator": "equals",
"key": "segment",
"value": "production"
},
{
"type": "tag-value",
"operator": "equals",
"key": "stage",
"value": "development"
}
],
"action": {
"add-to-network-function-group": "networkfunctiongroupone"
}
}
```
## Example attachment policy
The following shows a JSON containing three attachment policies for a core network.
+ There are three segments, `DevelopmentSegment`, `TestingSegment`, and `ProductionSegment`, which were first created on the **Segments** tab of the **Create policy** page. When these segments were created, `DevelopmentSegment` was set to automatically accept attachments, while `TestingSegment` and `ProductionSegment` were required to accept attachments. `ProductionSegment` was also limited to `us-east-1` only and only `TestingSegment` is allowed to advertise to this segment.
+ Rule numbers are manually assigned to each attachment policy for rule processing. Rules are then processed in numerical order according to the number assigned to them. In this example, the following rule numbers are used: `100` for `DevelopmentSegment`, `200` for `TestingSegment`, and `300` for `ProductionSegment`. This indicates that rule `100` will be run first, followed by rule `200` and then rule `300`. Once an attachment matches a rule, no further rules are processed for that attachment. Rule `300` for `ProductionSegment` additionally indicates that the policy will only accept `vpc` attachments and only if the request comes from `us-east-2`.
For more information on the parameters used in the JSON file, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
```
{
"version": "2021.12",
"core-network-configuration": {
"vpn-ecmp-support": true
},
"segments": [
{
"name": "DevelopmentSegment",
"require-attachment-acceptance": false
},
{
"name": "TestingSegment",
"require-attachment-acceptance": true
},
{
"name": "ProductionSegment",
"edge-locations": [
"us-east-1"
],
"require-attachment-acceptance": true,
"isolate-attachments": true,
"allow-filter": [
"TestingSegment"
]
}
],
"attachment-policies": [
{
"rule-number": 100,
"condition-logic": "or",
"conditions": [],
"action": {
"association-method": "constant",
"segment": "DevelopmentSegment"
}
},
{
"rule-number": 200,
"condition-logic": "or",
"conditions": [],
"action": {
"association-method": "constant",
"segment": "TestingSegment",
"require-acceptance": true
}
},
{
"rule-number": 300,
"condition-logic": "and",
"conditions": [
{
"type": "region",
"operator": "equals",
"value": "us-east-2"
},
{
"type": "attachment-type",
"operator": "equals",
"value": "vpc"
}
],
"action": {
"association-method": "constant",
"segment": "ProductionSegment",
"require-acceptance": true
}
}
]
}
```
Using the **Visual editor**, the same policies display as follows:
![\[Cloud WAN attachment policy using the Visaul editor.\]](http://docs.aws.amazon.com/network-manager/latest/cloudwan/images/cloudwan-attachment-policy.png)
Note that if an attachment policy uses the **and** condition, each condition appears on a separate row of the editor. In this example, since rule number 300 uses **region** and **attachment-type** conditions, each of those conditions appear on separate rows.
# Create an AWS Cloud WAN route policy and rule
A routing policy is a set of rules that gives you precise control over route propagations in your core network allowing you better routes management, optimized performance and greater security. A routing policy rule consists of a match condition and an action used to control route propagations. The match condition determines which route propagations the rule applies to, while the action specifies how to process the route propagations in the core network. This granular control enables you to implement complex routing scenarios, such as blocking specific routes, adding BGP community tags, modifying AS paths, or setting route preferences to influence path selection across your network infrastructure. You can associate these routing policies to a) routes propagated on Cloud WAN attachments b) routes propagated across segments or c) routes propagated across core network edges (CNE) or regions (CNE-to-CNE).
## Create a routing policy
Provide policy details to control traffic flow and optimize your network routing. Before you can create a routing policy you must first have completed the following:
+ Set up the Network configuration. See [Configure the core network settings](cloudwan-core-network-config.md).
+ Defined one or more segments. See [Add a segment](cloudwan-policy-segments.md)
**To create a routing policy**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. In **Choose policy view mode**, choose **Visual editor**.
1. Choose **Routing policies**.
1. Choose **Create**.
1. For **Routing policy number**, enter a priority number. Lower numbers take priority over higher numbers when processing the policy.
1. (Optional) Add a **Description** identifying this policy. The description can be no longer than 256 characters, using a-z, A-Z, 0-9, and hyphens (-). White spaces are not allowed.
1. For the** Routing policy direction** choose one of the following:
+ **Inbound** - An inbound routing policy contains rules that control routes propagated inbound on an attachment (e.g. from an external network to Cloud WAN) into the CNE
+ **Outbound** - An outbound policy contains rules that control routes advertised from a CNE outbound over an attachment (e.g. from Cloud WAN to an external network).
1. Choose **Create routing policy**.
Once you've created one or more route policies, you can create route rules to further control route propagation.
## Create a routing policy rule
A routing policy rule consists of a match condition and an action used to control route propagations.
**To create a routing policy rule**
1. Open the at [https://console.aws.amazon.com/networkmanager/](https://console.aws.amazon.com/networkmanager/).
1. In the navigation pane, choose **Cloud WAN**.
1. Choose the global network ID.
1. In the navigation pane, choose **Routing policies**.
1. Choose the routing policy where you want to add a rule.
1. Choose **Create rule**.
1. For **Routing policy rule number**, enter a priority number. Lower numbers take priority over higher numbers when processing the policy.
1. Set the **Action** for the rule. Available actions include:
+ **Drop** - Block specified routes
+ **Allow** - Allow specified routes that would otherwise be dropped by a drop rule. Allow rules should have a lower rule number than drop rules.
+ **Prepend ASN list** - Add ASNs to make this path less preferred
+ **Remove ASN list** - Remove ASNs to make this path more preferred
+ **Replace ASN list** - Replace AS-PATH with a new ASN list
+ **Add community** - Add a BGP community to routes
+ **Remove community** - Remove a BGP community from routes
+ **Summarize** - Advertise a summary route
+ **Set local preference** - Set priority for route selection (higher value = more preferred path)
1. If adding multiple conditions, choose the logical operator:
+ **AND** - All conditions must be met for the rule to apply
+ **OR** - Any condition can be met for the rule to apply
1. Configure the match conditions for the rule. You can add multiple conditions and specify whether they should be evaluated with AND or OR logic:
+ **Prefix equals** - Matches routes with an exact network prefix specification.
+ **Prefix in CIDR** - Match propagated routes that fall within a specified CIDR range.
+ **Prefix in prefix list** - Matches routes whose prefixes are contained in a predefined prefix list.
+ **ASN in as path** - Matches routes that contain a specific Autonomous System Number in their AS path.
+ **Community in list** - Matches routes that have BGP community attributes present in a specified community list.
+ **MED equals** - Matches routes with a Multi-Exit Discriminator (MED) value equal to the specified number.
1. Choose **Add rule**.
# Create an AWS Cloud WAN attachment routing policy
Attachment routing policies are used to associate one or more route policies to attachments. Attachment route policy consists of a list of match-action rules that map one or more route policies to a route policy label which is a string identifier (max 256 characters). You will need to associate this route policy label with an attachment via the create-attachment-routing-policy-label API.
**To create an attachment routing policy**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. In **Choose policy view mode**, choose **Visual editor**.
1. Choose the **Attachment policies** tab.
1. In the **Attachment routing policies rules** section, choose **Create**.
1. For **Rule number**, enter a unique number from 1 to 9,999. Rules are processed in numerical order.
1. (Optional) Enter a **Rule description**. The description can be no longer than 256 characters, using a-z, A-Z, 0-9, and hyphens (-). White spaces are not allowed.
1. (Optional) Choose the **Edge locations** that this attachment routing rule is applicable to. You can only choose those edge locations that you set up in your network configuration. You can configure this option for Direct Connect attachments that can associate with multiple CNEs. This option allows you to associate the routing policy to a select CNE. By default routing policy applies to all CNEs associated with the Direct Connect attachment.
1. For **Condition - Routing policy label**, enter the label for the routing policy you want to use for attachment association. All attachments with the same routing label will be automatically associated with this attachment routing policy. You can add a label to attachment when you create that attachment, or you can modify an existing attachment to add a routing label. For more information about adding labels to an attachment, see the applicable steps for the type of attachment you're creating in [Attachments](cloudwan-create-attachment.md).
1. For **Action - Associate with these routing policies**, choose the Cloud WAN routing policies you want to associate with label defined in the previous step.
For more information on the parameters used in the JSON file, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
```
{
"attachment-routing-policy-rules": [
{
"rule-number": 500,
"description": "Attachment Route Filters",
"edge-locations": ["us-west-1", "us-east-1"],
"conditions":[
{
"type": "routing-policy-label",
"value": "attachmentRoutingFilter"
}
],
"action": {
"associate-routing-policies": ["routingFilter"]
}
}
]
}
```
# Create an AWS Cloud WAN core network policy version using JSON
You can create a core network policy by creating a JSON file. In the JSON editor, you add the parameters of your core network and policies, including advanced routing policies for fine-grained traffic control. 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).
**Note**
Familiarity with creating JSON files is required.
**To create a policy version using a JSON editor**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity** choose **Cloud WAN**.
1. On the **Global networks** page, choose the global network ID that for the core network you want to create a policy version for, and then choose **Core network**.
1. In the navigation pane, choose **Policy versions**.
1. Choose **Create policy version**.
1. In **Choose policy view mode**, choose **JSON**.
1. In the JSON editor, create your new policy. You can create a new policy version using a blank form, or copy and modify the contents of a policy version that you've downloaded.
+ For the required and optional parameters in your JSON policy, see [Core network policy version parameters in AWS Cloud WAN](cloudwan-policies-json.md).
+ For the steps to download a previous policy version, see
1. Choose **Create policy**.
A new policy version is generated.
The **Change set state** on the **Policy version** page displays **Pending generation** while the new policy generates. The state changes when the policy either generates successfully or fails to generate.
**Topics**
+ [Core network policy version parameters](cloudwan-policies-json.md)
+ [Core network policy examples](cloudwan-policy-examples.md)
# Core network policy version parameters in AWS Cloud WAN
The following sections describe the parameters that you use to create a core network policy version using JSON. Your JSON file contains two sections that describe the policy network settings and segments. You can then add optional sections for defining network function groups and segment actions.
For example JSON policies, see [AWS Cloud WAN core network policy examples](cloudwan-policy-examples.md).
**Topics**
+ [`version`](#cloudwan-version-json)
+ [`core-network-configuration`](#cloudwan-network-config-json)
+ [`segments`](#cloudwan-segments-json-about)
+ [`network-function-groups`](#cloudwan-network-functions-json)
+ [`segment-actions`](#cloudwan-segment-actions-json)
+ [`attachment-policies`](#cloudwan-attach-policies-json)
+ [`attachment-routing-policy-rules`](#cloudwan-attachment-routing-policy-rules-json)
+ [`routing-policies`](#cloudwan-routing-policies-json)
## `version`
You must select a version for your core network from the following options:
+ `2021.12`
+ `2025.11`
**Note**
You must select version 2025.11 to use route policies in your core network policy. Using version 2025.11 will also enable BGP community support on your core network, meaning community tags coming from BGP capable attachments will begin to be propagated through your core network. We will drop the subtype information of community tags propagated through the core network and for community tags propagated outbound of the core network the subtype will be set to Route Target.
## `core-network-configuration`
The core network configuration section defines the Regions where a core network should operate.
For AWS Regions that are defined in the policy, the core network creates a Core Network Edge where you can connect attachments. After it's created, each Core Network Edge is peered with every other defined Region and is configured with consistent segment and routing across all Regions. Regions can't be removed until the associated attachments are deleted. `core-network-configuration` is required.
### Parameters
The following parameters are used in `core-network-configuration`:
+ General settings allow you to create the foundation of a core network, including whether VPN ECMP, DNS, and security group referencing are supported.
+ `vpn-ecmp-support `— (Optional) Indicates whether the core network forwards traffic over multiple equal-cost routes using VPN. The value can be either `true` or `false`. When set to `true`, traffic can be distributed across multiple VPN tunnels for better throughput and redundancy. The default is `true`.
+ `dns-support` — (Optional) Indicates whether DNS resolution is enabled for the core network. The value can be either `true` or `false`. When set to `true`, DNS resolution is enabled for VPCs attached to the core network, allowing resources in different VPCs to resolve each other's domain names. The default is `true`. For more information, see [DNS support](cloudwan-vpc-attachment.md#cloudwan-dns-support).
+ `security-group-referencing-support` — (Optional) Indicates whether security group referencing is enabled for the core network. The value can be either `true` or `false`. When set to `true`, security groups in one VPC can reference security groups in another VPC attached to the core network, enabling more flexible security configurations across your network. The default is `false`. For more information about security group referencing, see [Security group referencing](cloudwan-vpc-attachment.md#cloudwan-sg-referencing).
+ `asn-ranges` — The Autonomous System Numbers (ASNs) to assign to core network edges. By default, the core network automatically assigns an ASN for each core network edge, but you can optionally define the ASN in the `edge-locations` for each Region. The ASN uses an array of integer ranges only from `64512` to `65534` and `4200000000` to `4294967294`. No other ASN ranges can be used.
+ `inside-cidr-blocks` — (Optional) The Classless Inter-Domain Routing (CIDR) block range used to create tunnels for AWS Transit Gateway Connect. The format is standard AWS CIDR range (for example, `10.0.1.0/24`). You can optionally define the inside CIDR in the core network edges section per Region. The minimum is a `/24` for IPv4 or `/64` for IPv6. You can provide multiple `/24` subnets or a larger CIDR range. If you define a larger CIDR range, new core network edges will be automatically assigned `/24` and `/64` subnets from the larger CIDR. an Inside CIDR block is required for attaching Connect attachments to a Core Network Edge.
**Note**
If the ranges provided do not have enough space to create a `/24` for IPv4 or `/64` for IPv6 block when a new edge location is added to the policy a policy exception will occur. Auto assigning CIDR blocks will occur whenever a value for this option is specified. To avoid this exception you would either need to increase the CIDR range provided or have this CIDR range match the CIDRS specified in the core network edges section per Region. Expanding the range will allow the service to be able to auto assign a CIDR range for a new edge location. Having the ranges match the core network edge locations indicates that no auto assigning needs to occur and we will not attempt to auto assign for any new edge locations.
+ `vpn-ecmp-support` — (Optional) Indicate whether the core network forwards traffic over multiple equal-cost routes using VPN. The value can either be `true` or `false`. The default is `true`.
+ `edge-locations` — An array of AWS Region locations where you're creating core network edges. The array is composed of the following parameters:
+ `location` — An AWS Region code, such as `us-east-1`.
+ `asn` — (Optional) The ASN of the core network edge in an AWS Region. By default, the ASN will be a single integer automatically assigned from `asn-ranges`.
**Note**
You can't change the ASN of a core network edge. Any transit gateway with the same ASN can't be peered to that core network edge. For example, if you have a core network edge with an ASN of `64512`, you can't peer any transit gateway that also has an ASN of `64512`.
+ `inside-cidr-blocks` — (Optional) The local CIDR blocks for this core network edge for AWS Transit Gateway Connect attachments. By default, this CIDR block will be one or more optional IPv4 and IPv6 CIDR prefixes auto-assigned from `inside-cidr-blocks`.
**Note**
You can't delete the inside CIDR block once it's assigned to a core network edge.
For example, you might have the following core network configuration. This core network configuration establishes a Cloud WAN core network with VPN ECMP and DNS support enabled, while disabling security group referencing across VPCs. It allocates two internal CIDR blocks (`10.0.0.0/16` and `10.1.0.0/16`) for network connectivity, defines an ASN range of `65000-65100`, and deploys a single edge location in `us-east-1`, providing the foundation for a managed wide area network.
```
{
"version": "2021.12",
"core-network-configuration": {
"vpn-ecmp-support": true,
"dns-support": true,
"security-group-referencing-support": false,
"inside-cidr-blocks": [
"10.0.0.0/16",
"10.1.0.0/16"
],
"asn-ranges": [
"65000-65100"
],
"edge-locations": [
{
"location": "us-east-1"
}
]
}
...
}
```
## `segments`
The segments section defines the different segments in the network. Here you can provide descriptions, change defaults, and provide explicit regional, operational, and route filters. The names defined for each segment are used in the segment-actions and attachment-policies section. Each segment is created and operates as a completely separate routing domain. By default, attachments can only communicate with other attachments in the same segment. `segments` is a required section.
### Parameters
The following parameters are used in `segments`:
+ `segments` — At least one segment must be defined and composed of the following parameters:
+ `name` — The name of the segment. The `name` is a string used in other parts of the policy document, as well as in the console for metrics and other reference points. Valid characters are a–z, A–Z, and 0–9.
**Note**
There is no ARN or ID for a segment.
+ `description` — (Optional) A user-defined string describing the segment.
+ `edge-locations` — (Optional) Allows you to define a more restrictive set of Regions for a segment. The edge location must be a subset of the locations that are defined for `edge-locations` in the core-network-configuration. These locations use the AWS Region code. For example, you might want to use `us-east-1` as an edge location.
+ `isolate-attachments ` — (Optional) This Boolean setting determines whether attachments on the same segment can communicate with each other. The default value is `false`. When set to `true`, the only routes available will either be shared routes through the share actions, which are attachments in other segments, or static routes. For example, you might have a segment dedicated to `development` that should never allow VPCs to talk to each other, even if they’re on the same segment. In this example, you would set the parameter to `true`.
**Note**
Routes coming from a route table attachment are not affected by the `isolate-attachments` parameter. You are responsible for managing routes propagating from their attached route tables. Routes flowing into the route table attachment from other attachments within the segment follow the standard `isolate-attachments` behavior
+ `require-attachment-acceptance` — (Optional) This Boolean setting determines whether attachment requests are automatically approved or require acceptance. The default is `true`, indicating that attachment requests require acceptance. For example, you might use this setting to allow a `sandbox` segment to allow any attachment request so that a core network or attachment administrator does not need to review and approve attachment requests. In this example, `require-attachment-acceptance` is set to `false`.
**Note**
If `require-attachment-acceptance` is `false` for a segment, it's still possible for attachments to be added to or removed from a segment automatically when their tags change. If this behavior is not desired, set `require-attachment-acceptance` to `true`.
+ `deny-filter` — (Optional) An array of segments that disallows routes from the segments listed in the array. It is applied only after routes have been shared in `segment-actions`. If a segment is listed in the `deny-filter`, attachments between the two segments will never have routes shared across them. For example, you might have a financial `payment` segment that should never share routes with a `development` segment, regardless of how many other share statements are created. Adding the `payments` segment to the `deny-filter` parameter prevents any shared routes from being created with other segments.
+ `allow-filter` (optional) — An array of segments that explicitly allows only routes from the segments that are listed in the array. Use the `allow-filter` setting if a segment has a well-defined group of other segments that connectivity should be restricted to. It is applied after routes have been shared in `segment-actions`. If a segment is listed in `allow-filter`, attachments between the two segments will have routes if they are also shared in the `segment-actions` area. For example, you might have a segment named `video-producer` that should only ever share routes with a `video-distributor` segment, no matter how many other share statements are created.
**Note**
You can use either `allow-filter` or `deny-filter`, but you can't use both of them simultaneously. These are optional fields used to more explicitly control segment sharing. These parameters are not required in order to receive or send routes between segments.
## `network-function-groups`
`network-function-groups` defines the container for the service insertion actions you want to include. This will include any attachment policies.
+ `name` — Required. This identifies the network function group container.
+ `description` — Optional description of the network function group.
+ `require-attachment-acceptance` — This will be either `true`, that attachment acceptance is required, or `false`, that it is not required.
## `segment-actions`
`segment-actions` define how routing works between segments. By default, attachments can only communicate with other attachments in the same segment. You can use `segment-actions` to:
+ `share` attachments across segments. Use the `share` action so that attachments from two different segments can reach each other. For example, if you've set a segment to `isolate-attachments`, the segment can't reach anything unless it has a `share` relationship with other segments. The `share` statement creates routes between attachments in the provided segments. If you're creating a share between one segment and an array of segments, the segment to share allows attachments from the segments in the array. However, sharing does not occur between the segments within the array. For example, if a segment named `shared-service` is defined as a segment with a `share-with` array of segments named `prod` and `prod2`, the network policy will allow the attachments in both `prod` and `prod2` to reach `shared-service`. But the network policy will not allow sharing of attachments between `prod` and `prod2`.
+ `create-route` to define a static route in a segment.
**Note**
Sharing routes occurs between segments. All attachments connected to the same segment will share a similar routing behavior globally. If some attachments differ from other attachments in the same segment, those attachments should be within their own segments. This is intentional to prevent a proliferation of segments where one segment equals one attachment.
`segment-actions` is an optional section.
### Parameters
The following parameters are used in `segment-actions`:
+ `action` — The action to take for the chosen segment. The `action` can be any of the following:
+ `share` for a shared route
+ `create-route` for a route
+ `send-via` for service insertion, indicating that traffic is sent from one Cloud WAN attachment to another (east-west).
+ `send-to` for service insertion, indicating that traffic is sent out from the cloud and doesn't re-enter (north-south).
+ `associate-routing-policy` for associating routing policies with edge location pairs within a segment.
The following parameters are described for these actions.
+ `share` parameters. If the action to take is share, the following parameters are required. `share` is the default action behavior.
+ `segment` — The name of the segment created in the `segments` section to share.
+ `mode` — `attachment-route` is the only supported value. This mode places the attachment and return routes in each of the `share-with` segments. For example, if there are static routes or routes shared from other segments, those will not be shared through the `attachment-route` `mode`.
+ `share-with` — An array of segments that will have reachability with the segment defined. The core network will create mutual advertisements between these `share-with` segments and the defined segment attachments.
For example, if you create a `share` between a segment named `shared-services` and share-with "A" and "B", this allows the attachments from "A" and "B" to reach "Shared services". "A" and "B" cannot reach each other, and any static routes or routes propagated from other segments are not shared among these segments.
Use "`*`" as a wild card to reference all segments instead of explicitly calling out segments individually.
+ `except` — Explicitly exclude segments, encapsulated within a `share-with` block. For example,
```
{
"action": "share",
"mode": "attachment-route",
"segment": "segment",
"share-with": {
"except": [
"dev",
"prod"
]
}
}
```
+ `routing-policy-names` — (Optional) An array of routing policy names to apply to the segment sharing. The routing policies control how routes are propagated between the shared segments.
+ `create-route` parameters. If the action is `create-route`, the following are the required and optional parameters.
+ `segment` — The name of the segment created in the `segments` section, which must be a static route. If you need to duplicate the static route in multiple segments, use multiple `create-route` statements.
+ `destination-cidr-blocks` — The static route to create. A segment should have the same routing behavior for a certain destination. This means if one Region has a route to a destination, other Regions should also have that route, but with potentially different paths. You can define the IPv4 and IPv6 CIDR notation for each AWS Region. For example, `10.1.0.0/16` or `2001:db8::/56`. This is an array of CIDR notation strings.
+ `destinations` — Defines the list of attachments to send the traffic to, with up to one `attachment-id` per Region. Because a segment is a global object, you should design your routing so that every AWS Region has an attachment in the destinations list. Regions that do not have attachments in this list will receive a propagated version of this route through cross-Region peering connections, and will use the static route of another Region. This is the same case for multiple attachments that are defined across multiple remote Regions. Instead of an array of attachments, you can also provide a `blackhole`, which drops all traffic to the `destination-cidr-blocks`.
**Note**
AWS Cloud WAN does not propagate blackhole routes.
+ `description` — (Optional) A user-defined description to help further identify this route.
+ `associate-routing-policy` parameters. If the action is `associate-routing-policy`, the following parameters are required:
+ `segment` — The name of the segment where the routing policy association will be applied.
+ `edge-location-association` — Defines the edge location pair and routing policies to associate:
+ `edge-location` — The primary edge location.
+ `peer-edge-location` — The peer edge location that forms the edge location pair.
+ `routing-policy-names` — An array of routing policy names to apply to traffic between these edge locations.
The following example shows associating a routing policy with an edge location pair:
```
{
"action": "associate-routing-policy",
"segment": "prod",
"edge-location-association": {
"edge-location": "us-east-1",
"peer-edge-location": "us-west-2",
"routing-policy-names": ["inboundRoutingFilter"]
}
}
```
+ `send-via` and `send-to` parameters. If the network function group segment `action` is either `send-via` or `send-to`. Use` send-via` if you want to send east-west traffic between VPCs. Use `send-to` for north-south traffic; that is, traffic that first must come into your security appliance and then out to either the Internet or an on-premises location.
The following are the required and optional parameters:
+ `segment` — Required. The name of an existing segment that can be used for the `send-via` or `send-to` action.
+ `mode` — This only applies when the `action` is `send-via`, and indicates the mode used for packets. This will be either `single-hop` or `dual-hop`. `send-to` does not rely on `mode` for traffic.
+ `when-sent-to` parameters are used to list the destination segments for the `send-via` or `send-to` action.
+ `segments` — The list of segments that the `send-via` action uses. `segments` is not used for the `send-to` action.
+ `via` parameters describe the network function groups and any edge overrides associated with the
+ `network-function-groups` — The network function group to use for the service insertion action.
+ `with-edge-overrides` parameters describe any edge overrides and the preferred edge to use.
+ `edge-sets` — The list of edges associated with the network function group.
+ `use-edge` — The preferred edge to use.
The following example shows an example of the `send-via` action:
+ Traffic is sent via a segment named `development`.
+ the `via` parameter, which contains the details of the edge locations and overrides. It uses a network function group named `inspection-vpc` and has two defined `edge-sets`, `corenetwork1`and `corenetwork2`. `corenetwork2` is set as the preferred core network edge (`use-edge`).
```
{
"segment": "SendToInspectionVPC",
"action": "send-via",
"mode": "single-hop",
"when-sent-to": {
"segments ": [
"development"
]
},
"via": {
"network-function-groups": [
"inspection-vpc"
],
"with-edge-overrides ": [
{
"edge-sets ": [
["corenetwork1", "corenetwork2"]
],
"use-edge": "corenetwork2"
}
]
}
}
```
The following example shows an example of the `send-to` action. In this example, traffic is sent to a segment named `development` through a network function group named `inspection-vpc`.
```
{
"action": "send-to",
"segment": "development",
"via": {
"network-function-groups": [
"inspetion-vpc"
]
}
}
]
```
## `attachment-policies`
In a core network, all attachments use the `attachment-policies` section to map an attachment to a segment. Instead of manually associating a segment to each attachment, attachments use tags. The tags are then used to associate the attachment to the specified segment or network function group. A core network supports the following types of attachments:
+ Transit Gateway Connect — `connect`
+ Direct Connect gateway — `direct-connect-gateway`
+ VPC — `vpc`
+ VPN — `site-to-site-vpn`
+ Transit Gateway route table — `transit-gateway-route-table`
For example, to attach a VPC to a core network, either the VPC owner or the core network owner would create a core network attachment in the core network using either the AWS Cloud WAN console or the Network Manager `create-attachment` command line or API. The attachment itself will have tags analyzed by the attachment policy, and not the tags associated with the VPC resource. A tag on the attachment such as `"environment" : "development" ` would then map to a `development` segment. Attachment policy rules can also use available metadata from within the conditions, such as `account ID`, `type` of attachment, the `resource ID` (for example, `vpc-id`), or the AWS Region.
Rules are assigned numbers for processing, and are processed in order by number, from lowest to highest. When a match is made, the action is taken and no further rules are processed. A single attachment can only be associated to a single segment. If no rules are matched (for example, there might be a misspelled tag value), the attachment won't be associated to a segment.
When an attachment matches a rule, the attachment attaches to the segment defined `segment`. Each attachment can either be associated without acceptance or require a separate action to approve the attachment association. By default, every segment requires all attachments to be accepted. The acceptance requirement can be turned off with `"require-attachment-acceptance" : false` in the `segment` definition. When `require-acceptance` is `false`, any attachment that maps to the segment is automatically added. For example, a developer `sandbox` segment might want to allow any attachment with the correct tag to be added to the network. With the `attachment-policies`, you can add additional controls on a per-rule basis. For example, if attachments from the `us-east-2` Region require acceptance but other Regions do not, you can set the `"require-acceptance" : true` setting on a rule that is specific to `us-east-2` .
You can apply multiple conditions using either `and` or `or` logic to create a single rule. For example, you can state that if the account is `111122223333` and includes the tag `"stage" : "development"` it should map to a specified segment. If you don't want to use tags to map attachments, you could use the `resource-id` to manually map each incoming connection to a segment. However, this approach requires changing the policy document every time new attachments are added and can reduce the operability of your current LIVE policy.
If you're creating an attachment policy that includes a network functions group for service insertion, an attachment is required. If you attempt to create a service insertion policy that doesn't include an attachment, policy generation will fail.
`attachment-policies` is an optional section.
### Parameters
The following parameters are used in `attachment-policies`:
+ `rule-number` — An integer from `1` to `65535` indicating the rule's order number. Rules are processed in order from the lowest numbered rule to the highest. Rules stop processing when a rule is matched. It's important to make sure that you number your rules in the exact order that you want them processed.
+ `description` — (Optional) A user-defined description that further helps identify the rule.
+ `condition-logic` — Evaluates a condition on either `and` or `or`.
This is a mandatory parameter only if you have more than one condition. The conditions themselves are unordered, so the `condition-logic` applies to all of the conditions for a rule, which also means nested conditions of `and` or `or` are not supported. Use `and` if you want to the rule to match on all of the conditions, or use `or` if you want the rule to match on one of the conditions.
If you're creating a JSON policy for a network function group `and` and `or` are the only supported `condition-logic` options.
+ `conditions` — An array composed of one of the following types:
+ `type` - Specifies the kind of condition to evaluate for matching attachments. The type determines what attribute of the attachment will be examined and how the matching logic is applied.
+ `any` — This matches any request. For example, you could use any if you're only using one segment that everything should map to. Or, you could use this as a fallback segment if you want all attachments that don't match a rule to map to a known segment.
+ `resource-id` uses the resource associated with the attachment (for example, `vpc-1234567890123456`). Supports additional parameters:
+ `operator` — The operation to perform. Must be one of `equals` \$1 `not-equals` \$1 `contains` \$1 `begins-with`.
+ `value` — The resource ID value to match against.
+ `region` — Matches based on the AWS region where the attachment is located. Supports additional parameters:
+ `operator` — The operation to perform. Must be one of `equals` \$1 `not-equals` \$1 `contains` \$1 `begins-with`.
+ `value` — The Region to match against (for example,` us-east-1`).
+ `attachment-type` — Matches based on the type of attachment. Supports additional parameters:
+ `operator` — The operation to perform. Must be one of `equals` \$1 `not-equals` \$1 `contains` \$1 `begins-with`.
+ `value` — The attachment type to match against. Supported values are: `vpc`, `site-to-site-vpn`, `connect`, `transit-gateway-route-table`.
+ `account` — Uses the account ID of the requesting attachment (for example, `111122223333`). Supports additional parameters:
+ `operator` — The operation to perform. Must be one of `equals` \$1 `not-equals` \$1 `contains` \$1 `begins-with`.
+ `value` — The account ID value to match against.
+ `tag-name` — Match attachments based on the presence of specific tag names without evaluating their values.
+ `tag-value` — Match attachments based on the presence of specific tag values. Supports additional parameters:
+ `operator` — The operation to perform. Must be one of `equals` \$1 `not-equals` \$1 `contains` \$1 `begins-with`.
+ `value` — The tag key value to match against.
+ `action` — One of the following actions to when a condition is true:
+ `association-method` — Defines how a segment is mapped. Values can be `constant` or `tag`. `constant` statically defines the segment to associate the attachment to. `tag` uses the value of a tag to dynamically try to map to a segment.
+ `segment` — The name of the segment to share as defined in the `segments` section. This is used only when the `association-method` is constant.
+ `tag-value-of-key` — Maps the attachment to the value of a known key. This is used with the `association-method ` is `tag`. For example a tag of `"stage" : "test",` will map to a segment named `test`. The value must exactly match the name of a segment. This allows you to have many segments, but use only a single rule without having to define multiple nearly identical conditions. This prevents creating many similar conditions that all use the same keys to map to segments.
+ `require-acceptance` — Determines if this mapping should override the segment value for `require-attachment-acceptance`. You can only set this to `true`, indicating that this setting applies only to segments that have `require-attachment-acceptance` set to `false`. If the segment already has the default `require-attachment-acceptance`, you can set this to inherit segment's acceptance value.
+ `add-to-network-function-group` — The name of the network function group to attach to the attachment policy. The network function group must use `and` for the `condition-logic` and have an associated `Conditions` tag.
A network function group attachment policy requires that you use the `condition` option `tag-exists`, and then either `tag-name` or `tag-value`.
This following example attachment policy routes any attachment that has a `Location` tag to the `SendToInspectionVPC` network function group for traffic inspection, requiring manual acceptance before the attachment is processed:
```
{
"attachment-policies": [
{
"rule-number": 125,
"description": "Send traffic to inspection VPC",
"condition-logic": "and",
"conditions": [
{
"type": "tag-exists",
"key": "Location"
}
],
"action": {
"add-to-network-function-group": "SendToInspectionVPC"
"require-acceptance": true
}
}
```
## `attachment-routing-policy-rules`
`attachment-routing-policy-rules` defines how routing policies are associated with attachments using routing policy labels. This section works similarly to attachment policies but uses a new form of metadata called routing-policy-label instead of tags to map attachments to routing policies.
This approach provides separation between segment association (via tags) and routing policy association (via labels), and ensures only the core network owner can manage routing policy associations.
Before you can create an attachment routing policy rule, you must have routing policies already defined in the `routing-policies` section, as the rules reference these policies by the routing policy names.
`attachment-routing-policy-rules` is an optional section.
### Parameters
The following parameters are used in `attachment-routing-policy-rules`:
+ `rule-number` — An integer from `1` to `65535` indicating the rule's processing order. Rules are processed from lowest to highest number.
+ `description` — (Optional) A user-defined description that helps identify the rule.
+ `edge-locations` — (Optional) An array of edge locations where the routing policy should be applied. This only works with Direct Connect attachments to apply policies to specific regions.
+ `conditions` — An array of conditions that must be met. (since attachments can only have a single routing policy label the conditions are always applied with an or operator)
+ `type` — The type of condition to evaluate. Only `routing-policy-label` is supported. This condition type enables the core network owner to control routing policy associations independently from segment associations, providing more granular control over how routing policies are applied to attachments without relying on potentially changeable tag values.
+ `value` — The specific routing policy label identifier that attachments must have to match this condition.
+ `action` — Defines the action to take when conditions are met:
+ `associate-routing-policies` — The list of routing policy names to be associated with the attachment label.
The following example applies the outbound routing policy `routingPolicyName` only to attachments in us-west-2 that have an `Environment` label:
```
"attachment-routing-policy-rules": [
{
"rule-number": 145,
"description": "Apply outbound routing policy to production attachments",
"edge-locations": [
"us-west-2"
],
"conditions": [
{
"type": "routing-policy-label",
"value": "Environment"
}
],
"action": {
"associate-routing-policies": [
"routingPolicyName"
]
}
}
]
```
## `routing-policies`
`routing-policies` defines advanced routing controls that allow you to filter, modify, and control how routes are propagated throughout your core network. Routing policies provide fine-grained control over route advertisements between segments, edge locations, and attachments, enabling you to implement complex routing scenarios such as route filtering, path preferences, and route summarization.
Each routing policy contains rules that specify match conditions and actions to take on matching routes. Routing policies are directional (inbound or outbound) and can be associated with attachments, cross-region edge locations, and shared segments.
`routing-policies` is an optional section.
### Parameters
The following parameters are used in `routing-policies`:
+ `routing-policy-name` — A unique identifier for the routing policy. Must contain no more than 100 characters and use only alphanumeric characters (a-z, A-Z, 0-9).
+ `routing-policy-description` — (Optional) A user-defined description that helps identify the purpose of the routing policy.
+ `routing-policy-direction` — Specifies the direction of route processing. Must be either `inbound` (for routes being learned from external sources) or `outbound` (for routes being advertised to external destinations).
+ `routing-policy-number` — An integer from `1` to `9999` that determines the priority order when multiple routing policies are associated with the same resource. Lower numbers have higher priority and are processed first.
+ `routing-policy-rules` — An array of rules that define the match conditions and actions for the routing policy. Each rule contains:
+ `rule-number` — An integer from `1` to `9999` that determines the processing order within the policy. Rules are processed from lowest to highest number.
+ `rule-definition` — Contains the match conditions and actions for the rule:
+ `match-conditions` — An array of conditions that routes must match. Supported condition types include:
+ `type` — Specifies the type of match condition.
+ `prefix-equals` — Match specific IPv4 or IPv6 prefixes
+ `prefix-in-cidr` — Match prefixes within a CIDR range (prefixes that are a subset of the specified prefixes will be included only. If you also want to include the prefix specified you must also use the prefix-equals match condition)
+ `prefix-in-prefix-list` — Match prefixes defined in a managed prefix list (must be tied to an existing prefix list alias for a core network prefix list association, see [AWS Cloud WAN prefix list associations](cloudwan-prefix-lists.md))
+ `asn-in-as-path` — Match ASN in the AS path
+ `community-in-list` — Match BGP communities
+ `med-equals` — Match MED (Multi-Exit Discriminator) values
+ `value` — The value to match against for the specified condition type.
+ `condition-logic` — Specifies how multiple conditions are evaluated. Must be either `and` (all conditions must match) or `or` (any condition must match).
+ `action` — Defines the action to take on matching routes.
+ `type` — The type of action to take for the condition logic. Supported actions include:
**Important**
drop and allow result in terminal states, this means if a route matches a policy with a drop/allow action then no other routing poliy rules after that rule will be evaluated. For example, if you have a routing policy with the following rules:
Rule 1: drop, prefix-in-cidr 0.0.0.0/0
Rule 2: allow, prefix-in-cidr 10.0.0.0/8
Rule 3: set-local-prefrence, prefix-in-cidr 10.0.0.0/8
The rule 1 drop rule would be terminal meaning all routes would be dropped and rule 2 and 3 will do nothing. If Rule 1 and 2 are reversed, then 10.0.0.0/8 will be allowed and not dropped but the local preference rule 3 will not work because allow is also terminal. The proper order would be as follows
Rule 1: set-local-prefrence, prefix-in-cidr 10.0.0.0/8
Rule 2: allow, prefix-in-cidr 10.0.0.0/8
Rule 3: drop, prefix-in-cidr 0.0.0.0/0
+ `drop` — Drop matched routes
+ `allow` — Allow specified routes that would otherwise be dropped by a drop rule. Allow rules should have a lower rule number than drop rules.
+ `summarize` — Summarize routes (outbound only)
+ `prepend-asn-list` — Add ASNs to the beginning of the AS path to influence route selection
+ `remove-asn-list` — Remove specific ASNs in the AS path
+ `replace-asn-list` — Replace specific ASNs in the AS path with different values
+ `add-community` — Add BGP community values to routes
+ `remove-community` — Remove BGP community values from routes
+ `set-med` — Set the MED value
+ `set-local-preference` — Set local preference
The following example shows two inbound routing policies: `RP1` is a routing policy that matches on the prefix list alias `prefixListAlias`, drops any cidr that matches the cidrs in that prefix list, and has priority `100`, and `RP2` with priority 26 includes a rule that allows routes withing the cidr block `10.0.0.0/24` using `and` condition logic.
```
{
"routing-policies": [
{
"routing-policy-name": "RP1",
"routing-policy-description": "My routing policy",
"routing-policy-direction": "inbound",
"routing-policy-number": 100,
"routing-policy-rules": [
{
"rule-number": 5,
"rule-definition": {
"match-conditions": [
{
"type": "prefix-in-prefix-list",
"value": "prefixListAlias"
}
],
"condition-logic": "and",
"action": {
"type": "drop"
}
}
}
]
},
{
"routing-policy-name": "RP2",
"routing-policy-description": "My second routing policy",
"routing-policy-direction": "inbound",
"routing-policy-number": 26,
"routing-policy-rules": [
{
"rule-number": 32,
"rule-definition": {
"match-conditions": [
{
"type": "prefix-in-cidr",
"value": "10.0.0.0/24"
}
],
"condition-logic": "and",
"action": {
"type": "allow"
}
}
}
]
}
]
}
```
# AWS Cloud WAN 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
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
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
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
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
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
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
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
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"
}
}
}
]
}
]
}
```
# View an AWS Cloud WAN core network policy change set
View proposed changes to a policy before deploying those changes to become the new live policy.
A policy version is never implemented automatically. After creating a version of a policy, you can implement the policy version as your new **LIVE** policy.
**To view a core policy version change set**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. In the **Policy versions section**, choose the check box that you want to see policy changes for.
1. Choose **View or apply change set**. This creates a new version of the policy. The policy version is incremented by one from the last policy version.
1. The **Change set **page displays the **Type** of change being affected, for example, a core network segment, and the **Action** that's associated with that type, for example, adding a new segment.
1. In **New Values** and **Previous values**, choose **Details** to view the change in a JSON format.
1. In the **Compare** column, choose **Compare** to view a line-by-line comparison of the current live policy with the proposed policy change.
# Compare AWS Cloud WAN core network policy change set versions
Compare two policy versions against each other using the console. The comparison returns line-by-line changes between the two policies in JSON format with changes highlighted.
**To compare policy versions**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. Under **Policy version ID**, choose the policy version that you want to compare against another policy.
1. Choose **View or apply change set**.
1. On the Change set page, choose **Compare with LIVE**.
1. From the **Source** and **Target** dropdown lists, choose the policy versions that you want to compare.
1. (Optional) From the **Policy section** dropdown list, choose a specific policy section to compare. Options are:
+ **All** — Compares all policy changes between the two policies. This is the default view.
+ **Network configuration** — Compares Border Gateway Protocol (BGP), Autonomous System Number (ASN), and core network edge locations.
+ **Segments** — Compares segment additions, deletions, or modifications.
+ **Segment actions** — Compares segment sharing and filtering.
+ **Attachment policies** — Compare how attachments map to segments.
1. Choose **Compare**.
The **Results of comparison** section displays the changes between the two policies. In the following example, the **Segments** of a current LIVE **Source** policy are compared against the segment changes to an undeployed **Target** policy. The comparison shows that a new segment, **sandbox**, will be added when deploying the **Target** policy version.
![\[A comparison of the Segments section between a LIVE policy and a policy version.\]](http://docs.aws.amazon.com/network-manager/latest/cloudwan/images/cwan-policy-compare.png)
1. By default, the changes for each policy display in separate policy windows. To see the results of the comparison line-by-line in a single window, turn the **Split** toggle off.
# Deploy an AWS Cloud WAN core network policy version
fter creating a version of a policy, you can deploy the policy version as your new **LIVE** policy. Deploying a new policy version never occurs automatically.
**To implement a core policy version**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. On the **Policy versions** page, choose the policy that you want to deploy.
1. Choose **View or apply change set**.
1. (Optional) Do either of the following:
+ To review the proposed changes to the policy, choose **Details** in the **New values** column.
+ To review the values of the original policy, choose **Details** in the **Previous values** column.
1. Choose **Apply change set** to deploy the policy to become the new LIVE policy.
1. On the Policy versions page, the status of the policy deployment is **Executing policy**.
1. To view the deployment details and progress, choose the policy link. The **Policy version - X ** page appears.
+ The **Policy details** page displays information about the policy that you're deploying.
+ The **JSON** page displays policy information as a JSON file.
+ The **Execution progress** page displays the status of the policy deployment. You can view all events related to the deployment or you can view specific events. For example, you might want to view the deployment status of core network edges.
1. When finished, the **Alias** changes to **LIVE/LATEST** and the **Change set state** changes to **Execution succeeded**. The **Change set state** of any previous policies that were in a **Ready to execute** change set state change to **Out of date**. This indicates that those policies are now considered older than the current LIVE policy.
# Delete an AWS Cloud WAN policy version
Any policy except your current LIVE policy can be deleted.
**To delete a core policy version**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. Under **Policy version ID**, choose the policy version that you want to delete, and then choose **Delete**.
1. Confirm that you want to delete the policy version, and then choose **Delete** again.
Deleted policy versions are removed from the **Policy versions** page.
# Download an AWS Cloud WAN core network policy
Download any policy version or your current LIVE policy as a JSON file. You can open the downloaded file in any JSON editor.
**To download a core policy**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. Under **Policy version ID**, choose the policy version that you want to download, and then choose **Download**.
The policy downloads to your system as a JSON file. You can make changes to this JSON file as needed. You can create a new policy version using the contents of this file by pasting them into the Cloud WAN JSON editor. For the steps to create a policy using the JSON editor, see [Create an AWS Cloud WAN core network policy version using JSON](cloudwan-create-policy-json.md).
# Restore an out-of-date AWS Cloud WAN core network policy version
An out-of-date policy can be restored as a new version of a policy.
**To restore an out-of-date policy version**
1. Access the Network Manager console at [https://console.aws.amazon.com/networkmanager/home/](https://console.aws.amazon.com/networkmanager/home).
1. Under **Connectivity**, choose **Global Networks**.
1. On the **Global networks** page, choose the global network ID.
1. In the navigation pane, choose **Core network**, and then choose **Policy versions**.
1. Under **Policy version ID**, choose the out-of-date policy version that you want to restore, and then choose **Restore**.
The **Policy version ID** is incremented by one from the last version listed on the **Policy versions** page, and the **Change set state** displays as **Pending generation.**
When generated, the **Change set state** changes to **Ready to execute**, and the **Alias** changes to **LATEST**. If any previous policies were in the **Ready to execute** change set state, those change to **Out of date**. This indicates that those policies are now considered older than the **LATEST**.