DEV Community

Cover image for Inter-Region Connectivity in AWS using CloudWAN
SHAJAM
SHAJAM

Posted on

Inter-Region Connectivity in AWS using CloudWAN

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.

Key Concepts & How It Works

Global Network
This is the top-level container — it can hold a core network and any associated attachments (VPCs, VPNs, etc.).

Core Network
The core network is the portion of your Cloud WAN that is managed by AWS — essentially the backbone/fabric that ties your network attachments (VPCs, VPNs, Transit Gateways, on-prem links etc.) together.

Core Network Edge
A Core Network Edge is a regional connection point provisioned and managed by AWS in each AWS Region that you include in your core network via your core-network policy. Under the hood, a CNE is similar to AWS Transit Gateway (TGW) — meaning it acts like a regional router that aggregates and routes traffic — but differs in that it is fully managed by AWS.

Core Network Policy
A policy document (in a declarative language) that states how your network should be configured:

  • which AWS Regions to include
  • how attachments map to segments
  • routing rules
  • traffic-isolation rules

Cloud WAN then implements the network configuration automatically.

Attachments
These are the resources you hook into your network — like VPCs, VPN connections, Transit Gateways, SD-WAN links, on-premises branch office links.

Network segmentation
Cloud WAN lets you define segments — isolated routing domains. So you can isolate e.g. production, development, branch offices, or sensitive resources even if they share the same overall network backbone.

Central dashboard & automation
You manage everything — global scope, attachments, routing — from a single dashboard (via AWS Network Manager) or using AWS CLI / APIs. Cloud WAN automates the heavy lifting so you don't manually configure every link.

Let's get started

Create the Global Network namespace

  • Name your Global Network. (AWS > Network Manager > Global network)
  • Add core network. Can have a max of 1 core network.
  • Set ASN setting. Set the range. (The value must be a range between 64512-65534 or 4200000000-4294967294.) This is used by AWS for managing traffic between VPCs.
  • Choose edge locations -> us-east-1, us-west-2...
  • Set default segment name. This will be available in all edge locations.

Once you create it, the default policy will be created.

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64520-64524"
        ],
        "edge-locations": [
            { "location": "us-east-1" },
            { "location": "us-west-2" }
        ]
    },
    "segments": [
        {
            "name": "production",
            "description": "production environment"
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

You can create additional segments and configure attachment policies.

Network Design

Cloud Network using Cloud WAN[src: https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-cloud-wan.html]

In this diagram, there are multiple regions and multiple segments - Development, Shared and Production. Each region is connected using the CNEs. The segments have network connectivity defined by the core network policy.

Based on the diagram, I have created a sample network policy.

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

Understanding the Policy

asn-ranges: You define the asn-ranges where you will later pick the asn for a region.

edge-location: Here you define the edge locations your network will work in.

attachment-policies: This defines the policy for attaching the segments. Here. I am attaching the attachments to the segments based on the tag automatically. The tag key is set to be SEGMENT.

segments: This is a list of segments with edge-location. Note, the DEVELOPMENT segment rule, there is a deny-filter policy to PRODUCTION which makes the traffic uni-directional.

segment-actions: By default, the sharing is bi-directional. That is, for SHARED segment, it is shared with DEVELOPMENT and PRODUCTION. You don't need to share DEVELOPMENT and PRODUCTION with SHARED as it is bi-directional.

More about Attachments

When you build attachments, you can create it for Direct Connect Gateway, VPNs and VPCs.

Direct Connect Gateway

With Direct Connect Gateway, this is a convenient way to connect your Direct Connect to multiple regions. Direct Connect has certain limitations on maximum number of gateways that you can create. With CloudWAN, you just create one, attach to the required edge locations (supports more than 1) and that's it. You never need to worry about Direct Connects.

VPC

With VPCs, we simply add an attachment to the VPC so we could use as part of Core Network as defined by the network policy. One of the coolest feature here is security group referencing which allows referring to security group in one VPC from another, thus making security rules much more streamlined. Previously, I was creating prefix lists for the security group rules, now, you no longer need to do so.

VPN

With Site-to-Site VPN attachment refers to attaching a VPN connection to the core network. In effect, you are bringing an external VPN into your Cloud WAN global network so that it can connect with other attachments.

Conclusion

CloudWAN is an amazing service (or shall I say VPC feature) if you want to centralise global connectivity and connect across the globe. Adding regions and VPCs to core network literally takes less than 30 minutes! This is simply unreal.

Top comments (0)