AWS re:Invent 2025 - Deep dive into advanced routing policy with AWS Cloud WAN (NET401)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Deep dive into advanced routing policy with AWS Cloud WAN (NET401)

In this video, AWS introduces routing policy for Cloud WAN, a new capability enabling fine-grained control over route propagations across segments, regions, and attachments. Airbnb's Qijun Zhong shares their successful migration experience, achieving multi-million dollar savings and two-day deployment times. The session demonstrates key features including route filtering, summarization, and BGP property modification through live demos showing VPC CIDR summarization, overlapping route restriction, cross-region filtering, hybrid route isolation using community tags, and traffic path optimization with local preference. The presentation includes practical policy examples and even showcases using Amazon Q to automate policy configuration, providing attendees with real-world implementation patterns for managing complex hybrid network architectures.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction to AWS Cloud WAN Routing Policy at re:Invent 2025

Alright, welcome everyone. I hope you're having a great time at re:Invent 2025. I'm thrilled to talk to you about our exciting new release: routing policy with AWS Cloud WAN. I'm joined here today by my co-speakers, Qijun Zhong, Senior Network Engineer from Airbnb, and Shridhar Kulkarni, Principal Product Manager at AWS.

Building hybrid connectivity, in fact network connectivity in general, is tough and complex, especially when you have multiple on-premises networks that need to connect to VPCs not just in one region but in multiple regions. And then you have ever-changing application connectivity requirements through which you need to start tweaking things. That's where AWS Cloud WAN comes in. It acts as the brain of your network, providing robust connectivity to all your networks.

If you look under the covers, we have core network edges in every region. These are highly available, scalable routing entities where all the magic happens. They let you establish connectivity to your on-premises data centers via AWS Direct Connect or site-to-site VPN, or SD-WAN connectivity using connect attachments. It also connects to your existing transit gateways.

It enables traffic flow not just on-premises to AWS, but also AWS to AWS intra-region as well as inter-region. All these traffic flows can be inspected with a single click using AWS Cloud WAN's service insertion feature. The great thing about Cloud WAN is that everything is dynamic routing, so you don't have to write any static routes. Routes are exchanged dynamically.

Now while that's a great thing to have, we know that when you have hundreds of VPCs and multiple on-premises networks, route exchange can become complex. That's where the new routing policy is really powerful. In today's session, we're going to do a very quick recap of AWS Cloud WAN. This will be rapid fire since this is a 400-level session, so we want to spend most of our time talking about routing policies.

Rapid Fire Recap: Core Features of AWS Cloud WAN

Then we'll hear from Airbnb on how they're using AWS Cloud WAN, and then we'll dive into routing policy along with multiple use cases and a bunch of demos. Let's do a rapid fire recap of what AWS Cloud WAN is. In AWS Cloud WAN, everything is through a policy. Here we define a policy and give it three locations. When you execute this policy, behind the scenes, three core network edges, one in each region, are automatically provisioned and fully meshed.

Then we define segments. Segments are fully isolated routing boundaries. Here we define three segments: Production, Development, and Hybrid. Now we take our remote networks, including VPCs and transit gateways, and attach them to our Cloud WAN. But then we need to associate the right segment. For that, we need an attachment policy. Here we're using tags to automatically associate the right attachment to the right segment.

And then finally, we need to share routes between segments because segments are fully isolated by default. To enable sharing, we have this share segment action. The next feature of Cloud WAN is service insertion, which lets you insert network appliances into your traffic path. There are two traffic paths we'll talk about. The first one is inter-segment traffic path. Here we write a policy saying: when traffic from Production segment is sent to Development, send it via a network function group.

Here we're using the dual-hop mode, which means the traffic is getting inspected at every inspection region in both VPCs. The traffic, both the request and the response, is getting inspected. The next traffic path we have is the single-hop mode. So when traffic from Production segment is sent to Development, send it via a network function group, but as you can see on the bottom with edge overrides, as traffic is flowing between US East 1 and US West 2, use US East 1. So it deterministically always sends traffic for inspection to the inspection VPC in US East 1.

The next one we have is for Internet egress traffic. Here the policy says: any traffic exiting segment Development, send it to a network function group. We also have edge overrides here which says if my region does not have an inspection VPC, in this case US East 2, always use US East 1. So this edge overrides functionality gives you that deterministic way in how you set this up.

I went really fast, I told you it was rapid fire. If you want to learn more on how all of that works, we went into much more depth in last year's re:Invent session, so you can definitely check that out. Now I want to hand it over to Qijun to come and talk about how Airbnb is using Cloud WAN. Thank you.

Airbnb's Journey: From Physical Data Centers to Cloud WAN

Good afternoon, everyone. I'm happy to be here to share our experience with AWS Cloud WAN. I would like to start with a story from over six years ago when I first joined Airbnb. An engineer from another team asked me why configuring a network cannot be as easy as software development. I didn't know how to answer at the time. Configuring a network involves so many different types of devices, and there is no simple and unified way to automate all the configurations. Additionally, version control for network changes is very difficult. This question stuck with me for quite a long time.

About three years ago, when I learned about AWS Cloud WAN, I thought I might have found an answer. I would like to share our experience with you. For those who don't know me, my name is Qi Jun, and I'm the lead engineer for the Cloud WAN migration project at Airbnb. Airbnb started from a very simple idea: to help everyone find a place to stay and to connect travelers with hosts all around the world. Over the years, this simple idea has grown into a global platform. Today, we are hosting over two billion guests, and Airbnb is a company with 7,300 employees.

My team, the network engineering team, deploys and builds a global network to support all connectivity around the world. Our goal is to provide secure and reliable networks. Let me dive into the network architecture. You may see a graph here that looks very familiar to network engineers. In 2013, Airbnb was growing very fast, and we had a rapidly increasing demand for audio and video traffic. We needed to design a network to support low latency and high reliability, so we built a physical data center network during that time. In the middle part is the physical data center, which serves as our backbone. It interconnects all the network components within our network, including all the services deployed in AWS VPCs, our client VPNs, offices, and many other external networks. This model worked great and provided us with secure and reliable network connectivity.

Fast forward to 2021, when our physical data center was approaching end of life. It was a great time for our team to step back and rethink how we could design the network and what the next generation network would look like. More importantly, we needed to consider how to build a network to support fast-growing cloud-based services. We built an initial proof of concept design, which shows a simple connection for our proof of concept. We used a full mesh connection for AWS Transit Gateways. This design worked great, and the testing was successful. However, at the same time, we discovered that AWS Cloud WAN was maturing very rapidly as a product. We conducted an evaluation and found that AWS Cloud WAN was actually an even better fit for our needs.

Cloud WAN supports dynamic routing and has strong automation support. One important thing is that it has a simpler infrastructure. Here is a graph showing how we currently use Cloud WAN in our network. In this graph, Cloud WAN is in the middle part, serving as our backbone. Because Cloud WAN is a global platform and supports dynamic routing, we no longer need to use full mesh connectivity like the Transit Gateway solution. This solution works great. Because Cloud WAN is in the middle as our main backbone, we can use the Core Network Policy to centrally manage all the network components in our network. You may also see the inspection VPC in the bottom part.

Which is for our Layer 7 firewalls. Security is an important component in our network, so our standard approach is to build Layer 7 firewalls to inspect and control all traffic on our network. This design works very well with Cloud WAN. I also want to mention Terraform Enterprise support, which enables us to deploy and manage our network entirely through code with built-in version control and easy rollback for network changes. This answers a question from six years ago.

The migration to Cloud WAN has been very successful. We have already put our production network in Cloud WAN for over one year, almost two years now, and we have seen significant benefits. The first benefit I would like to mention is cost savings. Because we decommissioned all the physical data centers and the circuits connecting them, we are able to save multi-million dollars every year.

Another major benefit is automation. We really appreciate this aspect. With automation, we are able to use code to deploy and manage our entire network. It is easier for our network team to make changes because they have built-in version control and easy rollback capabilities, which has helped us tremendously. Additionally, we have achieved rapid deployment. Because everything is based on code, we can use modularized coding to spin up a new data center in a new region within two days. Compared to the old days before migration, when physical data centers could take weeks to months and involve multiple teams' efforts to build, we can now accomplish this in just two days.

Another benefit I want to mention is operational efficiency. After we migrated our network to AWS Cloud WAN, we are seeing improved uptime. AWS Cloud WAN also provides a centralized place for us to do monitoring, which helps us significantly. As a network engineer, I used to spend a lot of time addressing network issues like network device hardware issues, cabling issues, SFPs, and circuit issues. After the migration, AWS has helped us handle all the underlying circuits and connectivities, which frees up our efforts and allows our team to focus on more strategic and impactful tasks instead of routine maintenance.

Current Challenges and Future Improvements with Advanced Routing Features

With all these changes, we have basically transformed our way to deploy and manage our network. We are really happy with less routine maintenance effort while still ensuring high reliability networks. We are currently still working with AWS to improve our network further. Here are the challenges we are still facing. One of them is static routes. We still need to configure some static routes, mostly for our firewall inspection because of our environment's requirements. Additionally, our firewalls currently have to perform a double inspection design, which we would like to move away from.

Another challenge is that we have many requests from our trusted teams who would like to self-manage the routing to Cloud WAN. We would also like to have easier route filtering. The good news is that AWS is actively working on this. The Service Insertion feature and Advanced Routing feature could potentially fix these challenges. We are very excited to test and apply these new features, and hopefully we will improve the network even further.

To conclude, our migration to Cloud WAN has been very successful, and we have enjoyed many benefits as I mentioned. We are still working on the challenges I outlined. I will now hand over to Shida, who will talk more about the advanced routing policies.

I hope this talk will inspire you to look into this technology and maybe try it out. Thank you for your time.

Introducing Routing Policy: Advanced Routing Capabilities for Cloud WAN

Hello everyone. My name is Shridhar Kulkarni, and I lead product management here at AWS for a couple of connectivity services: Cloud WAN, Transit Gateway, and Direct Connect. It's great to see you all here, and I want to take this opportunity to thank Fion and the Airbnb team for putting trust in the Cloud WAN service. I know you were early adopters of the service from multiple years back, and it's amazing to see you grow your network with Cloud WAN as the backbone for that. Thank you for that, and I sincerely appreciate all the feedback that your team has provided over the years. It helps us make our products better. By the way, that applies to a lot of the folks in this audience because I have so many familiar faces here. Your feedback makes us come up with better services and better products.

Speaking of making the service better, today I'm excited to talk about a brand new capability that we just launched a couple of weeks ago. It's called routing policy on Cloud WAN, and it gives you advanced routing capabilities in order to essentially control propagations within your network. It helps you manage your routing much better and essentially customize your network as per your individual needs.

Before I get into the feature itself, I'm going to set the stage a little bit and give you some context in terms of why this feature is so important and why this capability is so value driven. Let's look at a typical Cloud WAN network. Let's say three regions, obviously there's a core network endpoint per region, and then you have three environments: production, development, and hybrid. Your production and development VPCs are attached to your production and development segments, and then your hybrid segment is attached to your external networks, right?

Your data center is connected via Direct Connect attachment to the hybrid segment, or you could have remote offices that have site-to-site VPNs coming into the hybrid segment. Alternatively, you could have SD-WAN based networks, so you could use something like a tunnel-less connect attachment from an SD-WAN appliance and then attach that to the hybrid segment. All of these attachments that I'm talking about right now are BGP capable attachments, right? There are propagations, route advertisements, and learnings in both directions dynamically on all these attachments. Similarly, you have Transit Gateway peering attachments. Let's say you have a different group or you do an acquisition and they're using Transit Gateways to attach their VPCs. Then you can take the peering connection from the Transit Gateway and attach it to the production or development segment using route table attachments so that you can maintain the segmentation intent.

The point being, all these routes are propagated not just on these attachments but also across regions, right? Cloud WAN supports dynamic routing as a table sticks feature. It automatically propagates all the routes across regions, and the same thing happens across segments. You can share routes across segments, and routes get propagated. This is amazing. It's a fully dynamic network, and customers love it. But then there are some challenges that this kind of environment can present to you.

The number one challenge is uncontrolled route propagations. We have heard from you and from customers over the years that you want to be able to control route propagations at all these distribution points or attachments across segments or across regions. This could be just to minimize the blast radius of propagations, but you need some control in terms of what routes get propagated globally versus locally. The second thing is indeterministic traffic patterns. Again, in a fully dynamic network, multi-pathing is super common. From a remote site, you could have multiple paths coming into the core network, one via SD-WAN and the other one via Direct Connect. In such a scenario, you want the control to do some sort of path preferences. You want to say, for these prefixes, I really want that traffic to come over SD-WAN, right? Versus these other prefixes where I prefer my Direct Connect path. That level of control so that you can have some deterministic traffic patterns through this dynamic network is super important.

Route scaling is another derivative effect of the uncontrolled route propagation issue. Let's say you're connected to a partner network and you advertise all the routes in your segment to that partner network. There's a chance you're going to overwhelm the routing limits on that router on the other side, or vice versa. So you want to be able to control those propagations to prevent any scaling-related issues.

Last but not least is troubleshooting. It's a super dynamic environment, and you need advanced visibility into your routing databases to figure out where you're learning these routes from and what advanced attributes are associated with these routes. These are some of the challenges that we have addressed in this brand new routing policy capability we just launched a couple of weeks back. It gives you fine-grained routing controls at each of those distribution points I talked about in the previous slide, on the attachments across regions and across segments.

This capability optimizes traffic patterns by giving you the ability to modify advanced BGP attributes like local preference or AS path prepend on Cloud WAN itself so that you can influence paths coming in or influence traffic coming in through all these different paths. You can control asymmetric routing and all of that using this feature. Last but not least, you get full visibility into the routing database, into the RIB, the routing information base, so that you can proactively troubleshoot issues or ensure that the way the network is behaving or the way the traffic is flowing is as per the way you want it according to your policy.

Let's look at the features in a little bit more detail. The first feature we're offering as part of this capability is route filtering. You will be able to allow or drop routes or prefixes in both inbound and outbound directions for all these different attachment types: VPN, Direct Connect, transit gateway route table attachments, or Connect attachments. You can also do the same thing on VPC attachments, although VPC attachment is not classical BGP, but it does automatically propagate routes from VPC into the segment route table, so you can control that by adding filters, inbound only filters on that attachment.

You can also control route propagations across segments or filter routes, essentially allowing or dropping routes across segments. The same applies between core network edge to core network edge. You can put filters on that distribution point. This is based on the classical match-action philosophy, so you can match what prefixes you want to drop or the actions you want to take based on certain attributes. You can match based on prefixes or standard BGP attributes like AS numbers, BGP communities, or MED values, and so on.

The second important feature is route summarization. This goes back to preventing scaling issues by advertising all the routes on certain attachments. You will be able to advertise a summary route instead of multiple prefixes. You can do that outbound across all these BGP-capable attachments like VPN, Direct Connect, or Connect attachments. Here again you can match based on prefixes.

Thirdly, there is BGP property modification. This is where you can manipulate attributes like local preference, MED value, BGP communities, or AS path. You can do that in both directions, inbound and outbound, on all the BGP-capable attachments across segments and regions. Here we can match based on prefixes or standard BGP attributes. This is in a nutshell what some of the detailed features are that we're supporting with this capability.

Defining and Associating Routing Policies: A Step-by-Step Guide

Let's look at how you get started with this feature or what the policy definition looks like. There are two high-level major steps. One is defining the routing policy, and the second step is taking that routing policy and associating it to one of these distribution points.

Let's look at step one where you actually define the routing policy. As I said, it's based on the classic match and action philosophy, so the first thing you do is define match conditions. You define your match conditions, and you have several match conditions that you can use. You can match based on a V4 or V6 prefix. You can match based on a prefix that is part of a CIDR range, or you can match with a prefix list.

A lot of our customers use prefix lists for ease of use rather than having to manage individual prefixes. It's much easier to use a prefix list, which is like a named reference. You can match based on your customer-defined prefix list. You can also match based on AS path, BGP communities, or MED values, so there's a lot of flexibility that this capability offers in terms of what you can match against. Once you do your match condition, the second thing is defining the action. For action, we support classical filtering actions such as dropping the matched prefix or allowing certain matched prefixes in the route updates that are coming in or going out.

You can do summary routes in the outbound direction. That's one of the actions you can add or remove ASNs to the AS path. You can prepend ASN lists, remove ASN lists, or replace ASN lists. You have actions like that. You can add or remove communities, set MED values, or set local preferences. These are the actions that you can use corresponding to the match actions. Let's take an example. Let's say your match condition is prefix equals, which means you're matching on an IPv4 or V6 prefix, and your action is to drop that route or drop that prefix in the outbound route advertisement.

Here's how the policy would look like for that operation. Your policy essentially gets a unique policy number. You give it a policy name, a unique name like here we're calling it outbound route filter. You give a description and then you give the policy direction. This is important. There is a notion of directionality for routing policies. They're either in the outbound direction or in the inbound direction. Let's take an example. When I say outbound from the perspective of an attachment, like if you have a VPN attachment to a remote site, outbound is the route propagations that go from the Core Network segment route table to your remote site. That's the outbound direction.

Inbound is anything that the remote site advertises to the Core Network segment route table. This policy's direction is outbound, which means you're going to control those routes that are advertised from the Core Network to that remote site. You specify the direction, and then you specify the rule. Every routing policy is essentially a collection of match action rules. Here you define a rule, you give it a unique rule number, and then you give the match condition saying your prefix equals 192.168/16. Then you're saying the action is drop. So anything that matches 192.168/16 in the outbound direction gets dropped. That's the filter you define using this policy.

Now, the next step is to associate the policy that you just defined to a distribution point. Let's look at distribution points one at a time. So in inter-segment, when you share routes across segments, what you can do is reference that routing policy that you just defined in the previous slide into this segment action stanza where you're sharing the two segments with each other. Here's an example of segment prod that got shared with segment dev, and then you are referencing the routing policy here. So any outbound propagations, meaning from prod to dev, it's going to filter out the 192.168/16 prefix that you defined in the routing policy. This is giving you that granular control of what routes you want to propagate across segments and which ones you want to filter out.

The next distribution point is between regions. Now here you have a new segment action called associate-routing-policy. You specify the segment, the source region, destination region, and then again you reference the routing policy.

Here's an example of how you do that. The new action associate routing policy edge location is US East 1. Your peer edge location is US West 2, and then you have an outbound route filter that you're attaching or associating to those route propagations. This is how you can do cross-region route propagation control. You can do it in both outbound and inbound directions. The example here is for outbound.

Then the last distribution point is on an attachment. This is the most interesting one. We have come up with a new construct called a routing policy label. At a high level, what you do is you take a routing policy and map it to a label. Your label is just like a tag—it's an identifier that provides indirection for the routing policy. Then what you do is you associate that label with the attachment when you're creating the attachments. This is how the routing policy gets applied to the Cloud WAN attachments.

Let's look at an example of how you do the policy association to attachments. At the bottom there's an example of creating that label. This is done as part of the attachment routing policy rules. Just like you have attachment policy today, which is an existing construct that maps an attachment to a segment, this is a new construct called attachment routing policy rules which matches the routing policy to a label. Here you're mapping your outbound route filter policy that you defined in step one to the label called attachment filter, and then you can call the association API at the top to associate that label with the attachment. This is how you take a routing policy, map it to a label, and then map that to an attachment, and that's how filters are set on individual attachments.

The relationship between routing policy and label is many to one. You can have multiple routing policies that you can map to a single label. The relationship between the label and the attachments is one to many. You can take the same label and the same outbound route filter, for example, and associate that with multiple attachments. This is the last slide for this section, speaking to the observability piece. Now you have full visibility into the routing information base. You can say for a segment or for an edge location, give me all the routing information, and it's going to dump the entire routing information base with all the advanced BGP attributes so that you can use that for troubleshooting or for management.

Live Demonstrations: Route Summarization and Filtering in Action

With that, I'm going to hand it over to Sid to go into the advanced use cases. Thanks, Shridhar. Now that we all understand how routing policy works, let's look at some use cases and a demo. This is a demo environment in which I'll be illustrating and configuring routing policies. I have three regions and three segments in a standard setup. My prod VPCs are in the 10 range, DB VPCs are in the 172 range. To simulate my on-premises setup, I have SD-WAN connectivity using Tunnelless Connect, and that's advertising 164 routes.

The first scenario we'll look at is route summarization. What we want to do here is the routes which are being learned from the VPC at the Cloud WAN edge location will get summarized as we send it on-premises. My 10.1 and 10.2 prod VPCs routes will get summarized as 10.0/14. To implement this, step one is to create a routing policy to match the VPC CIDR and summarize them. Step two is to apply the routing policy to the relevant attachments.

Let's see how this works. I have a routing policy called SummarizeProdVPCs. I give it a direction of outbound. I'm going to match on a prefix list. As Shridhar mentioned, it's much easier to manage VPC CIDRs using prefix lists, so I have a prefix list for VPCs which I match on. The action is summarize, and I'm summarizing that to 10.0/14. Now let's apply that. Using the attachment routing policy rules, I have a condition where I am associating the routing policy to a label. Then we will associate the label to the attachment. Shridhar just talked about how we do this, so we do all of that.

So I'm going to show this in action. There you go. So we go into our console and you can see I have my setup with three Airbus regions. I go into my topology tree to just verify my setup as you can see I have Dev and Prod VPCs in US East one, Dev and Prod VPCs in US one, and then I have my hybrid attachment. This is my connect attachment with my connect peers, and I can see BGP is up. Everything's running fine. Awesome.

So I go back into my core network. I choose my latest policy. I'll edit the JSON. Now you can see my policy is pretty standard, just defining the edge location segments. There's no routing policies in there. I'll go ahead and add the routing policies. So let's jump back into our presentation and I'll exactly copy the same syntax into my policy. Let's go back and take the attachment route policy rules and add that in as well. Now I am butchering the JSON formatting here, but it's okay. It works. That's all that matters.

So let's go ahead and that now is pending generation. So you can go into my prefix associations and you can see I've already associated prod VPCs prefix list with Aeroblis cloud one. So that's a step in which you need to do. If I look at my prefix list, you can see I already have 100, 101, 102 CIDRs in my prefix list, so everything looks good. I go into my attachment and this is my connect attachment. And here you can see routing policy label new, so I click that and you can see I've already associated the connect label with my attachment. So that step already done.

So now if we go back, this is my SD-WAN appliance, and I can check what routes I'm receiving. So you can see I'm receiving 10, 10.1, 10.2. So the summarization has not happened yet. So for summarization to work and I can also see the exact ASN and the path. So this is all the CNE ASNs. So we go back into the policy and we go ahead and execute it. If you apply change set, I'm sure you guys have done this 100 times and we wait for the policy to get executed. And that should happen. There you go.

And now we'll run the show IP BGP summary and you can see now I have the summary route 100/14 and the previous routes 101, 102, 100 are gone. Right, so this our summarization's working and you can see the route path is just my CNE which I'm directly attached to. So just to summarize what happened here, individual prefixes were suppressed. Only the summary route was advertised, and the non-specified prefixes, that was my 172 routes, still continue to advertise as normal.

So the summary route is created upon the first match. It's advertised dynamically, so it's coming to BGP, and it is retracted once all the matching prefixes are removed. The summary route is treated as a new route, right, so it's originated by the CNE and we saw in the demo that 100/14, the next hop was the CNE. So any other ASNs or any other BGP attributes behind that CNE is all removed. It's not carried forward.

Now let's talk about route summarization policy strategy. So what we did here was global summarization. So all the prod VPCs across the regions, I created one summary route and advertised it down to my SD-WAN appliances. I don't recommend this for direct connect attachments because that's a global attachment and it can lead to non-optimal routing. Let's see how.

So let's say I have the same setup and I'm advertising 10.0/8 down to my direct connect gateway and my on-premises server wants to talk to, let's say 10.1/16. So the traffic goes to the gateway. Now Direct Connect Gateway sees two equal routes, one from CNE1, one from CNE2, both advertising 10/8. All the BGP attributes are the same. What route will Transit Gateway take? I don't know, it might just go to CNE two and then CNE two senses to CNE one. So that's not an optimal routing, right? So don't do this.

So what you can do, and the same thing applies if you're using IPsec VPN and your on-prem router sees two equal routes from the IPsec tunnels to the two different CNEs. So what you would rather do is per region summarization, so you have different summary routes per region. So you can see here it's 10.0/17 and 10.128/17, so two different routes. And you can also go a step ahead and do per region per segment summarization so you can see here I have different routes for prod for development in region one and region two. Or you can do everything, right? So for direct connect you can do per region per segment summarization, and for attachments like tunnel-less connect where it would make sense you can have the global summarization, right? So you can control, mix and match.

Our next scenario is to restrict overlapping VPC CIDR. Let's say you have your SD-WAN set up, you're connecting to remote offices, you make a new office acquisition, and it has a 172.16 range. Oh no, that overlaps with our VPC in US West 2. What do we do? One of the great things about VPCs is that you can add a secondary CIDR. So we add a non-overlapping secondary CIDR, and now the logic we want to implement is that the primary and the secondary CIDR is learned by the CNE, but only the non-overlapping secondary CIDR is advertised on-premises. So how do we do that? There are multiple ways to achieve this. Option one is to apply an inbound route filter on the VPC attachment directly. So if we do that, the primary CIDR is not even inserted into the dev segment. Now you may not want that. You want the other dev VPCs or other VPCs to talk to the primary CIDR. So the second option is to apply that in the segment sharing. So here the route is inserted into the dev segment but does not make it to the hybrid segment. But you may have other hybrid networks like Direct Connect or site-to-site VPN which may want to access the primary CIDR. So what can we do? We can also do option 3, which is apply an outbound route filter on the connect attachment. So the route makes it to the dev and the hybrid segment, but not to that specific attachment. For our demo we'll go with option 2. So here is our policy. It's pretty straightforward. I think you're seeing a policy to filter prefixes and drop it for the third time. So you guys probably are experts now. We match on the primary CIDR and drop it. And this is how we apply it to our segment sharing. So in my share depth to hybrid, I associate the routing policy.

Let's see this in action. What I'll do is copy this exact policy, because I'm going to apply it. But before we do so, let's look at our dev VPC. I've already added the secondary CIDR, 172.172.172.0/24. So that's already done. Great. We can go into our route table for hybrid US East 1 and we can see I'm currently getting the primary VPC CIDR, the 172.16, and I can also verify the same on my SD-WAN appliance. I'm getting the primary CIDR. So the primary CIDR is getting advertised and I need to filter it out. So I go into my policy, I edit my policy, go to JSON. In my routing policies, I'll add the new routing policy, which is dev to hybrid route filter. Perfect. And then the routing policy reference will be added to my segment share. So let's go ahead and do that in the segment actions dev shared with hybrid. I'll go ahead and add that. And I create my policy. All right, it's ready to execute. Let's view and apply the change set. Looks good. Apply. Executing. Execution complete. Perfect. So when we go back into the ISD one appliance and now do show IP BGP, perfect. So now you can see our primary CIDR is no longer being advertised. We can also verify that under routes if we go into our hybrid segment we should not see that route anymore. 172.16, so you can see there's no 172.16 in that list, but if we go into the dev segment, there should be the 172.16 right there, right? So you can see it advertised into dev, but it's not advertised into hybrid and to our SD-WAN appliances. OK, so that filter is working.

Advanced Use Cases: Cross-Region Filtering, Hybrid Route Isolation, and AI-Powered Configuration

Next, let's talk about a scenario where in the European region you have a VPC, but due to some European regulations, you don't want that VPC to be accessed by the VPCs in the US, right? So you don't want that route to be advertised. So the restricted VPC CIDR is learned by the CNE. But as it's advertised cross-region to the other CNE, we will filter that VPC CIDR. So we'll create an outbound route filter to drop the VPC CIDR, and we'll apply that at the segment level cross-region sharing. All right, so this is my policy. Filter EU to US. I match on a prefix, so prefix equals 10.2.0.0/16, and I'm going to drop it. Now the important thing is where I apply it. So Shridhar talked about there's a new segment action. Associate routing policy. So I'll use that. I'll define my segment, which is prod. I reference the filter EU to US. I've defined my edge locations using a broad filter. I referenced the filter EU to US policy, and I define my edge locations.

I'll apply it as the traffic is being sent or the routes are being sent from EU West 1 to US East 1, and I'll do the same when it's sent from EU West 1 to US West 2. So the interregion pairs get defined. Let's see this in action. We go into our policy and now instead of using JSON, I'm going to actually use the visual editor. I've already gone ahead and created the filter EU to US routing policy. As you can see, prefix equals 10.2.16. I'm dropping it. So now I'll go into segment actions. You can see edge location route policy association, which is a new thing we've added. You can click associate. You can choose the segment prod EU West 1 to US East 1 and apply the policy filter EU to US. Now I'll just do it for EU to US East, not for US West yet. So let's go ahead and apply the change set. I'm only blocking the routes propagation from EU to US East 1. If you go to our routes in US East 1 and search routes, you can see I'm still seeing the 10.2 route, so that's not getting filtered. To dive deeper, I can go into my RIB, get routing information, and you can see the 10.2 route is actually coming from US West 2. I can look at the AS path and I can see that 6515 is US West 2 and 6514 is EU West 1. So this 10.2 route is getting filtered from EU, but I'm seeing it from US West 2. What I need to do is go into my edge associate routing policy and now I need to block EU West 1 to US West 2 as well. Once I do that, now hopefully my US East 1 will not see the EU VPC routes come in either from EU or from US West. So to verify that, we jump into our routes in US East 1 and search routes. You can see the 10.2 route is no longer present. We can also verify on US West 2 and the 10.2 route is no longer present. This should give you an example of how you apply a filter to cross-region route sharing for a given segment.

My next scenario is hybrid route isolation. From my on-premises SD-WAN appliances, I've been advertising two routes: 100.64.10 and 100.64.20. In my on-premises environment, 100.64 is for production and 100.64.10 is for production environment and 100.64.20 is for development environment. What I want to do is as those routes are being advertised from on-premises and shared from hybrid to production and development, I only want to advertise 100.64.10 into production and 100.64.20 into development.

When you do route sharing between segments, it's all or nothing. When I do hybrid to prod and hybrid to dev route sharing, both 100.64.10 and 100.64.20 will get advertised, but I want to restrict that. The way I'll do it in this example is I'll tag those routes with different communities. I'll do that on-premises, and in my case I'll do that on the SD-WAN appliance. Then I'll create route policies where I'll match and allow based on that community tag. I'll have two different route policies: one to match hybrid community for dev and one to match hybrid community for prod. Then I'll apply those communities as I'm sharing the routes between hybrid and production and hybrid and development.

Let's see how we can implement step 2.1 and step 2.2. Step 2.1 shows how my policy looks. Match hybrid community dev. Direction is inbound. The direction is very important. Here we are going to match on a community, community in 65000:200, allow. So any routes which are tagged with that community are allowed. Whenever you're doing an allow, you have to do an explicit deny. So here we're putting an explicit deny saying deny everything else. I do the exact same thing for prod: match hybrid community prod. I match on 65000:100 and then allow. And then I put explicit denial in there.

Now step 3, we need to apply those policies in the right place, the right distribution point. So here segment dev when it is shared with hybrid I associate the policy. Remember we need to filter the routes as advertised from hybrid to dev, but here I'm saying dev share with hybrid. That's why the direction becomes very important.

It is shared with hybrid. I associate the policy. Now remember, we need to filter the routes as advertised from hybrid to dev, but here I'm saying dev share with hybrid. That's why the direction becomes very important. Remember the policy direction was inbound, right? But if you had said that to outbound, this would not work. So the direction and how you're doing the segment share is really important. And then I do the same thing for prod to hybrid segment. I associate the match hybrid community prod. And hopefully this works. Let's see. So this is my SD-WAN appliance. As you can see, I've configured some route maps to tag the CIDRs with communities, and I'm advertising that to my cloud one peers. I can also verify that by going to the RIB into my hybrid US West 2, and you can see the communities listed on the right. These are my cloud one peers BGP, and on the right is the community. So I can see those communities come in. When I go to Prod, I can see both 100 and 200 communities. When I go to Dev, same, I can see both 100 and 200, right? But the logic is 100 should be only in Prod and 200 should only be in Dev. So I'll go ahead and here we'll create a routing policy using the visual editor. Match hybrid community dev. We go ahead and add a rule where we will allow routes which have this community tag 65000:200, and then we also have to add an explicit deny so 200 drop prefix inside 0.0.0.0/0. Perfect. So this is how you can do that. Now if you click JSON, what we configured shows up as the JSON syntax as well, so it's a great idea for you to use the visual editor to make changes and then you can go into the JSON and look at how it's done. So for the rest of the stuff I'll quickly speed up. I'll copy everything from my slides into my routing policy. I'll not make you sit through all of that copy paste. So that's all done. I execute my policy. It's getting executed. So what you saw in the slides is what is getting implemented exactly. So let's go back into our core network and now when we go into our RIB, and for Prod US East 1, you can see I only see 65000:100 community routes, and for Dev, I only see 65000:200 community routes, right? So we were able to successfully filter route distribution into our segments based on community tags. All right, so my final scenario here is where I have two different regions with my SD-WAN appliances. Now both are advertising the same routes, 100.64.20.0/24 with that community tag. I spin up a new Aeroblis region US East 2, which does not have on-premises connectivity. So when a VPC in US East 2 has to talk to an on-premises IP, it needs to go via CNE 1 or CNE 2, right? So what do you think? Which CNE will it choose? Will CNE 3 send traffic to CNE 2, or will it send traffic to CNE 1, right? Let's see. So we are going to go into my console where everything is configured. I go into Dev in US East 2. And here I can also add additional filter to only show me routes with community 65000:200. And you can see US East 2 is receiving that prefix from three regions: US East 1, US West 2, and EU West 1. And you can also look at the AS path to see exactly, so 64512 is my on-premises SD-WAN and 65556 is my on-premises SD-WAN. Great. Now if I go to my routing table, you can see the CNE decided to choose US East 1 as the next hop and ignore EU and US West 2. Now I want to change that, right? So what I want to do is for dev traffic originating in US East 1, I want to make US West 2 as the preferred hop, right? So my US West 2 has to be primary for dev traffic. So I want to change what Cloud WAN decided for me. And for my Prod traffic, I want to continue using US East 1. So the way I do it is the routes I receive from US West 2, I'll tag them with high local preference, and the route I receive from US East 1, I'll tag them with low local preference. So here's my policy, set high local preference SD-WAN routes. I match on the community and I set low local preference, so this is high local preference. And then my second policy to match the same routes, and I set low local preference, right? Two different policies, setting the local preferences.

Now it's important where I apply what. For my dev segment, I will apply the low local preference for my edge locations US East 1 to US East 2. And I'll apply the high local preference for my edge pair US West 2 to US East 1. So the routes coming from US West 2 will get the high local preference.

You saw how we do this through the CLI, through the JSON. You saw how I do this through the visual editor. Let's do it through AI. The Quiro. So I'm going to take this prompt. I'm going to tell it to look into my Aerob Bliss Cloud One configuration and implement this kind of logic. So I take my prompt, put it into Quiro, and let Quiro do all the work for me.

So now Quiro is going to first call a bunch of CLI commands, look into my turban configuration, understand my existing policy. Then I also asked it to look at Airbus documentation to understand the route policy features. So it's now calling an MCP tool Airbus documentation. It read it. It says perfect. I understand the route preference feature. Then it goes ahead and starts creating a policy. You can see it's creating the policy. And it has now created the policy. The change it's created a change highlighted document so I can see what exactly it wants to add. I can verify it. Everything looks good, very similar to what I had in my slides. So I'll accept that and I'll say let's go ahead and apply this policy.

So when I do that, Quiro will again start, do the apply chain set and go execute this policy. It takes a couple of steps. That's done. We can go check our policy version. We can see execution has succeeded. Now when we go into our routes in depth US East 2, you can see now 106,420. The next stop is US West 2, so we changed it from US East 1 to US West 2 using local preferences. And just to verify, Prod US East 2 is still using US East 1. So I put all my prod traffic via US East 1 and my dev traffic via US West 2 using cross region local preferences. Awesome.

Route Evaluation Logic, Key Considerations, and Session Wrap-Up

Now when Cloud One has to make this routing decision, it follows a route evaluation logic. Most specific routes always wins, but if there's a route with the same destination and different targets, static routes always win, then BGP's propagated routes, and then it looks at dynamic route. So it looks at local preference first, which was our case, and then other metrics. And if all the BGP attributes are the same, then direct connect is preferred, then cloud van, then site to site VPN, then transit gate VPing. And if everything is the same, then it uses a deterministic random approach.

Some key considerations before we wrap up. It requires you to use a new policy version 2 to 2025.11. CNE will transitively pass all BGP communities across all attachments. This is great, but it wasn't the case before, so it's good for you to know. The RIB presents routes before routing policies are applied on the local CNE. Routing policy direction is really important and it's really directional. When you're associating prefix lists with a CNE, they must be unique.

Some applicability considerations: BGP community match and modification are not supported on DX and transitive peering attachments. You cannot replace or remove ASN specified in your CNE configuration. Replace ASN is not supported cross region. Route policies are not supported for network function group service insertion. So if you're using service insertion, continue to use it. And service insertion leverages static routes behind the scenes. So that always takes priority over what you do with BGP.

So just to recap, route filtering, route summarization, BGP route property modification. It opens up a huge world of possibilities. I showed you some examples, but we are really excited to see how you use all of these capabilities to modify your networks and do amazing things in the world of routing. Now with that, we would like to thank you for coming. I know you all are going to open the session app and give us a 5 star CSAT review. Only because of that, I put a tiny URL here, a QR code. If you scan this, you will get access to my entire policy, which I had shown in my presentation, and that's a real policy which works. So you can use the syntax and modify it for your use cases. With that, we are at time. From Shridhar, Chijun, and I, thank you so much for coming and joining us and have a great reinvent.

---

; This article is entirely auto-generated using Amazon Bedrock.