Advance Routing Policy in AWS Cloud WAN

AWS Cloud WAN is a managed wide-area networking (WAN) service from AWS. It lets you build, manage, and monitor a unified global network that spans both cloud and on-premises environments. In practice, Cloud WAN lets you connect your data centres, branch offices, remote sites, and AWS cloud resources (e.g. VPCs) through a central control plane — instead of manually wiring together many VPCs, VPNs, Transit Gateways, and third-party SD-WANs.

---

To learn more about Cloud WAN, read my previous post on Connectivity using Cloud WAN.

---

Recently, AWS has announced advanced routing feature for Cloud WAN. Let's explore Segment routing policy in this post.

Let's assume, we have two segments -> DEVELOPMENT and PRODUCTION and we have the policy.

{
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "asn-ranges": [
      "64520-64524"
    ],
    "edge-locations": [
      {
        "location": "us-west-2",
        "asn": 64521
      },
      {
        "location": "us-east-1",
        "asn": 64522
      }
    ]
  },
  "version": "2025.11",
  "attachment-policies": [
    {
      "rule-number": 100,
      "action": {
        "association-method": "tag",
        "tag-value-of-key": "SEGMENT"
      },
      "conditions": [
        {
          "type": "tag-exists",
          "key": "SEGMENT"
        }
      ]
    }
  ],
  "segments": [
    {
      "name": "DEVELOPMENT",
      "require-attachment-acceptance": false,
      "edge-locations": [
        "us-west-2"
      ]
    },
    {
      "name": "PRODUCTION",
      "require-attachment-acceptance": true,
      "edge-locations": [
        "us-west-2", "us-east-1"
      ]
    }    
  ],
  "segment-actions": [
    {
      "mode": "attachment-route",
      "segment": "PRODUCTION",
      "action": "share",
      "share-with": [
        "DEVELOPMENT"
      ]
    }
  ]
}

---

This is essentially a cut down version of the policy I shared in the previous post. In this policy, PRODUCTION and DEVELOPMENT are shared, all routes are shared between the two segments.

---

Now, let us change the policy and allow only certain CIDR ranges from PRODUCTION to DEVELOPMENT and vice-versa. Specifically, we only want to allow

• 10.200.1.0/20 from PRODUCTION to DEVELOPMENT
• 10.200.2.0/20 from DEVELOPMENT to PRODUCTION

To achieve this, we can use the routing policy as per below.

"routing-policies": [
    {
      "routing-policy-name": "ProductionToDevelopment",
      "routing-policy-direction": "outbound",
      "routing-policy-number": 1,
      "routing-policy-rules": [
        {
          "rule-number": 1,
          "rule-definition": {
            "match-conditions": [
              {
                "type": "prefix-equals",
                "value": "prefix-in-cidr"
              }
            ],
            "condition-logic": "or",
            "action": {
              "type": "allow"
            }
          }
        },
        {
          "rule-number": 2,
          "rule-definition": {
            "match-conditions": [
              {
                "type": "prefix-in-cidr",
                "value": "0.0.0.0/0"
              }
            ],
            "condition-logic": "or",
            "action": {
              "type": "drop"
            }
          }
        }
      ]
    }

This policy allows 10.200.1.0/20 from PRODUCTION to DEVELOPMENT and denies all other traffic. You will need to apply a similar policy for DEVELOPMENT to PRODUCTION. It is important to note the route direction and it is set to outbound. It took me a bit of trialling to figure out the direction.

---

Now, lets say you have multiple direct connect gateways and and multiple default routes are appearing in the same segment, PRODUCTION. The PRODUCTION segment is extended across two regions - us-east-1 and us-west-2. That is, route 0.0.0.0/0 are appearing from the DX gateways.

By default, the same route might be preferred in PRODUCTION segment. We want to make sure, that PRODUCTION segment in us-east-1 get routes from the DX gateway in us-east-1 and vice versa.

Again, we can use routing policy and attachment policy to achieve this. Lets add a routing policy.

{
      "routing-policy-name": "AllowUsEast1",
      "routing-policy-description": "Allow us-east-1 DX G only",
      "routing-policy-direction": "inbound",
      "routing-policy-number": 21,
      "routing-policy-rules": [
        {
          "rule-number": 100,
          "rule-definition": {
            "match-conditions": [
              {
                "type": "prefix-equals",
                "value": "0.0.0.0/0"
              },
              {
                "type": "asn-in-as-path",
                "value": 64600
              }
            ],
            "condition-logic": "and",
            "action": {
              "type": "set-local-preference",
              "value": "300"
            }
          }
        }
      ]
    }

This is an inbound routing policy. It's checking for the default route 0.0.0.0/0 and ASN (ASN from DX gateway). When this matches, the local preference is set to 300. So, what happens is when the route matches prefix and ASN, a local preference is set. Cloud WAN prefers a higher local preference.

Now, you will need an attachment policy.

"attachment-routing-policy-rules": [
    {
      "rule-number": 1,
      "edge-locations": [
        "us-east-1"
      ],
      "conditions": [
        {
          "type": "routing-policy-label",
          "value": "DXDefault"
        }
      ],
      "action": {
        "associate-routing-policies": [
          "AllowUsEast1"
        ]
      }
    }
]

The attachment policy is set for the attachment of the DX gateway. The routing policy label needs to be applies to the attachment as well.

# CloudFormation snippet
Type: AWS::NetworkManager::DirectConnectGatewayAttachment
    Properties:
      CoreNetworkId: !Ref MyCoreNetworkId
      DirectConnectGatewayArn: !Ref MyDxGateway
      EdgeLocations: 
        - us-east-1
      RoutingPolicyLabel: DXDefault

You will need similar policies for us-west-2 location as well. Once this is applied, the route 0.0.0.0/0 will be propagated from the regional DX gateways.