AWS Cloud WAN Routing Policy: Fine-grained controls for your global network (Part 1)

Today, AWS announces the launch of AWS Cloud WAN Routing Policy, a new capability that gives customers greater control over how traffic is routed across their global networks. With this feature, customers can implement sophisticated routing controls for optimizing network performance and build more resilient hybrid architectures using AWS Cloud WAN. This post is the first in a two-part series. In Part 1, we provide an overview of the new capability including top use-cases, benefits, features and basic configuration workflows. In Part 2, we’ll dive deeper into architectural scenarios that demonstrate how to apply Cloud WAN routing policy in complex, large-scale network designs.

Cloud WAN Routing Policy enables customers to apply techniques such as route filtering, summarization, and path manipulation to fine-tune route management in their global networks. Customers can also configure Border Gateway Protocol (BGP) attributes to influence traffic behavior and meet complex routing requirements at scale. In addition, this feature provides enhanced visibility into Cloud WAN routing tables enabling customers to troubleshoot and quickly resolve issues in complex routing and multi-path environments.

We recommend readers to familiarize themselves with core AWS networking services such as Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, AWS Site-to-Site VPN, and AWS Cloud WAN, as well as the fundamentals of BGP, before implementing Cloud WAN Routing Policies.

Use cases and benefits

Following are a few use-cases and common networking challenges that can be addressed by Cloud WAN Routing Policy. This is not an exhaustive list, but rather a selection of top scenarios where the feature can add significant value.

Granular routing control

While customers value the simplicity of end-to-end dynamic routing across AWS Cloud WAN, there are situations where they need fine-grained control over which networks and resources are routable across their global environments. By managing routing behavior, customers can:

• Prevent suboptimal or asymmetric connectivity patterns
• Avoid overloading route tables with unnecessary propagated routes
• Protect against misconfigurations that could lead to unintended route propagation
• Minimize the blast radius of potential routing issues
• Prevent overlapping IP routes by propagating only non-conflicting CIDR ranges

Cloud WAN Routing Policy enables customers to filter or selectively propagate routes to achieve specific connectivity goals, ensuring their networks remain secure, efficient, and optimized.

Traffic engineering and path optimization

Many organizations build multiple connectivity paths between AWS Cloud WAN and their on-premises networks to achieve resiliency and high availability. In large BGP-based dynamic environments, it is common for the same destination prefixes to be learned over multiple network paths. With Cloud WAN Routing Policy, customers can control which paths network traffic should take via manipulation of BGP attributes. They can configure BGP settings based on their prior knowledge of factors such as availability of bandwidth, historical congestion patterns or contractual considerations with transit providers. This flexibility allows customers to optimize path selection for performance, reliability, and cost efficiency, ensuring that traffic follows the most appropriate route for their business needs.

Regional Internet egress control

Many organizations adopt geo-centric Internet egress architectures, where a centralized inspection VPC in a specific AWS Region handles outbound Internet traffic for an entire geographic area. For example, Internet traffic from all Asia-Pacific Regions may be directed through a centralized inspection VPC in Singapore Region, while traffic from European Regions is routed through an inspection VPC in the Frankfurt Region. Cloud WAN Routing Policy simplifies the design of these geo-specific Internet egress patterns on AWS Cloud WAN. It enables customers to enforce regional routing preferences while maintaining centralized security and compliance controls.

In summary, Cloud WAN Routing Policy for AWS Cloud WAN gives customers the flexibility and control they need to operate complex global networks with confidence. By combining advanced route management and traffic engineering capabilities, customers can build scalable, secure, and highly optimized network architectures on AWS.

Capabilities overview

Cloud WAN Routing Policy supports the following capabilities:

• Route filtering — You can filter (allow or drop) routes from inbound and outbound route propagations over Cloud WAN attachments. You can also filter routes propagated across segments and across Regions on the Cloud WAN core network (CNE-to-CNE) peering mesh.
• Route summarization — You can summarize or aggregate outbound routes on Cloud WAN attachments by specifying the desired summary route.
• Path preferences — You can set path preferences by modifying BGP attributes such as local preference, AS_PATH, and Multi-Exit Discriminator (MED) to influence inbound and outbound traffic paths between your Cloud WAN core network and external networks.
• BGP communities — BGP communities are now transitively passed between inbound and outbound route updates. You can also perform route filtering and path preference actions based on custom inbound BGP communities or attach BGP communities to outbound route updates.

How it works

Cloud WAN Routing Policy enables customers to define one or more routing policies composed of an ordered set of match–action rules. These policies give precise control over dynamic route propagation in AWS Cloud WAN, and between AWS Cloud WAN and external networks.

Customers can associate routing policies at different points within the AWS Cloud WAN network to control how routes are exchanged and propagated. Policies can be applied to routes propagated via Cloud WAN attachments, across segments (segment sharing), or across Regions (CNE-to-CNE peering). This flexibility allows customers to implement consistent, fine-grained routing behavior across their entire global network.

Each policy consists of three main components:

• Match conditions, which define criteria based on route prefixes, or BGP attributes.
• Actions, which determine what happens when a match occurs—such as allowing, dropping, or modifying routes.
• Directionality, which specifies whether the policy applies to “inbound” or “outbound” route propagation.

The following table summarizes the available Match Conditions and Actions that you can apply to inbound and outbound route propagations:

Figure 1: Table of available Match Conditions and Actions

Getting started

Prerequisite: The Cloud WAN Routing Policy feature requires policy version 2025.11. To start using this feature, navigate to your latest Cloud WAN Policy version, select Edit, and upgrade the version in the Network Configuration TAB -> General Settings to version 2025.11. This policy version upgrade is required before you can begin configuring Routing Policies:

Figure 2: Required upgrade to version 2025.11

Once the version upgrade is completed, we can proceed configuring Cloud WAN Routing Policies.

Configuring a Cloud WAN Routing Policy involves four main steps:

1. Define the routing policy in your Cloud WAN policy document.
2. Create or update the attachment routing policy to associate the routing policy with specific attachments (This step is not required when applying routing policies across segments or across Regions).
3. View and apply the Cloud WAN core network policy.
4. Associate routing policy with selected attachments, across segments, or across Regions.

Routing Policy configuration examples – Step by step:

In this first post (Part 1), we walk through a couple of examples. The first example shows how to apply an inbound route filter to a VPC attachment. In this scenario, we prevent the primary VPC CIDR block (10.0.0.0/16) from propagating into the AWS Cloud WAN core network—because it overlaps with an existing route in the segment—while allowing only the secondary CIDR block (10.1.0.0/16) to propagate.

Later in the post, a second example will show how to adjust the local preference for identical CIDR routes learned from two VPNs, where each VPN advertises the same prefix through BGP from two on-premises sites.

You can apply a similar workflow to perform route summarization or to modify other BGP attributes on BGP-capable attachments, including AWS Site-to-Site VPN, AWS Direct Connect, Connect attachments, and peering attachments. Routing policies can also be applied to inter-segment and inter-Region propagated routes.

First example: Inbound route filter for a VPC attachment

Figure 3: Applying an inbound route filter to a VPC attachment

Step 1: Create a routing policy:

1. Open the Network Manager console and go to Global Networks.
2. Choose the Global Network and then the Policy Versions under the Core Network where you want to define the routing policy.
3. Select the Policy version you want to apply the changes to and click Edit.
4. You will see the new tab Routing policies, click Create routing policy.

Figure 4: Routing policies tab

In the following window, you will give it a number, name, description (optional) and direction:

Figure 5: Create routing policy

5. Once a routing policy is created, add a routing policy rule to match and drop prefix 10.0.0.0/16:

Figure 6: Defining a new rule as part of the routing policy configuration

The following Action options are available as shown on the following Figure 7:

Figure 7: Action options while adding a rule in the Routing Policy

We add a Rule number, Action, and Conditions (we can add more than one if needed) → Prefix equals: 10.0.0.0/16, as shown in the following Figure 8:

Figure 8: Adding matching rule to match prefix 10.0.0.0/16

The Condition logic (AND or OR) determines how multiple conditions are evaluated within a routing policy rule. Select AND if the rule should apply only when all specified conditions are met. Select OR if the rule should apply when any condition is met. If the rule includes only one condition, you can keep the default value OR, as it does not affect the evaluation.

Step 2: Create Attachment routing policy rules to associate the routing policy created in Step 1 with specific attachments.

This step is required only when applying routing policies to attachments. When applying routing policies across segments (segment sharing) or across Regions (CNE-to-CNE), a separate step is required to ensure the policy is applied across those segments or CNEs.

The Attachment routing policy rules primitive is new, and differs from the existing Attachment policies primitive, which controls how attachments associate to segments. Attachment routing policy rules instead associates attachments to one or more routing policies via a Routing policy label. The following image (Figure 9) shows both types:

Figure 9: Attachment policies vs Attachment routing policy rules

Attachment routing policy rules include a set of match–action rules that map routing policies to a route policy label which is a simple text identifier of up to 256 characters.

The following example shows an attachment routing policy rule that maps the routing policy FilterPrimaryCIDR to a label named PrimaryVpcCidr:

Figure 10: Creating attachment routing policy rule

The same route policy label, PrimaryVpcCidr, must be used when associating attachments with route policies (Step 4). Finally, once the rule has been created, click on Create policy to generate a new Cloud WAN Policy version.

Step 3: View and apply the new policy.

Changes made in Steps 1 and 2 create a new policy version. To activate the updated configuration, select View or apply changes set:

Figure 11: New Cloud WAN policy version ready to execute

Once the policy is successfully deployed, the status updates to Execution succeeded, indicating that the new routing policies are active in the AWS Cloud WAN core network.

Step 4: Associate routing policies with Cloud WAN attachments, across segments, or across Regions.

In this final step, the routing policies created in Step 1 are associated with selected AWS Cloud WAN attachments using the label PrimaryVpcCidr defined in Step 2. Labels enable customers to apply consistent routing behavior across multiple attachments without the need to configure each one individually.

In this example, routing policies are associated with an attachment, but they can also be applied across segments or across CNEs.

When creating a new AWS Cloud WAN attachment, customers can associate a routing policy by selecting the corresponding Routing policy label, as shown in the following image (Figure 12):

Figure 12: Selecting a routing policy label during attachment creation

Alternatively, you can edit an existing Cloud WAN attachment and associate a Routing policy label, allowing you to apply a routing policy without recreating the attachment:

Figure 13: Updating a routing policy label for an existing attachment

Once a routing policy label is applied to an attachment, AWS Cloud WAN enforces the routing behavior defined by the associated routing policy until the label is removed.

Second example: Applying local preference for optimal path selection

In this second example, two VPN connections are advertising the default route 0.0.0.0/0 to AWS via BGP. One VPN is connected in the ap-southeast-2 Region, and another VPN is connected in the us-east-1 Region. The us-west-2 Region does not have a local VPN connection on its CNE, so it learns the default route through the two remote Regions that have active VPN connections.

To avoid nondeterministic routing and to prevent suboptimal routing through a distant Region, we configure the local preference so that the CNE in us-west-2 prefers the VPN endpoint in the closer Region, us-east-1:

Figure 14: Adjusting local preference in us-west-2 for the default route (0.0.0.0/0)

This can be achieved by creating an inbound routing policy with a rule that sets the local preference to 300 (a higher local preference is preferred). The default local preference is 0. The rule includes a single condition that matches the prefix 0.0.0.0/0:

Figure 15: Adjusting local preference

Finally, associate the routing policy containing the rule shown in Figure 15 to route propagations across two edge locations (two CNEs) within a segment. This can be configured under Segment actions → Edge location routing policy associations:

Figure 16: CNE-to-CNE Routing Policy

The previous Figure 16 shows how the routing policy is applied to the us-west-2 edge location (CNE) for routes originating from us-east-1 within the production segment.

Now, the CNE in us-west-2 will have a higher preference for the default route 0.0.0.0/0 via us-east-1 compared to the same default route received from ap-southeast-2.

Enhanced route visibility

With this launch, we’re also introducing a new Route information base tab. This tab provides enhanced visibility into all learned routes and their associated BGP attributes, like a traditional Routing Information Base (RIB) view before routing policies are applied. Attribute modifications made by inbound or outbound policies are not reflected in the Route information base. After routing policies are evaluated, AWS Cloud WAN selects the single best route and installs it into the Routes tab, which represents the Forwarding Information Base (FIB) used for packet forwarding.

Figure 17 shows the Route information base tab, which displays the routes learned by the us-west-2 CNE. In this example, the default route 0.0.0.0/0 is learned from both the us-east-1 and ap-southeast-2 Regions. Note that although we configured a local preference of 300 for the route learned from us-east-1, this change is not reflected in the RIB. As mentioned earlier, the Route information base presents routes before routing policies are applied on the local CNE:

Figure 17: RIB view, before Routing policies are applied

However, when we check the Routes tab (FIB), we will see the best route is being installed, that is the route learned from us-east-1, as it has a higher local preference configured:

Figure 18: FIB view – Routes tab used for packet forwarding

Things to know

• 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 inter-segment (segment sharing) and inter-Region (CNE-to-CNE) routes. Route summarization and BGP attribute modifications are available for all BGP-capable attachments—Site-to-Site VPN, Direct Connect, Connect, and peering—and for inter-segment and inter-Region routes. For VPC attachments, support is limited to route filtering (“allow” or “drop” actions) for inbound route propagation from the VPC to the core network.
• BGP community support is available for Connect, VPN, and Peering attachments. It is not available for Direct Connect attachments at the time of this launch.
• Route summarization is supported only for outbound routes on BGP-capable attachments.
• Routing Policy does not support controlling route propagations to Network Function Groups (Service Insertion).
• There are no additional charges to use this feature.
• Quotas about this new feature will be added in the AWS documentation.

Conclusion

In this blog (Part 1), we introduced Cloud WAN Routing Policy, a new capability that gives customers fine-grained control over dynamic route propagation and traffic engineering across their global networks. We explained how the feature works and walked through the steps to configure basic routing policies using the AWS Console.

With Cloud WAN Routing Policy, customers can define custom routing behavior across AWS Cloud WAN attachments, segments, and Regions – enhancing network visibility, performance, and control without adding complexity.

In Part 2 of this series, we will explore architectural scenarios that show how to apply route filtering, summarization, and path manipulation using BGP attributes across multi-Region and hybrid environments, enabling customers to design highly scalable and resilient networks on AWS.

To get started, refer to the AWS Cloud WAN documentation.

About the authors