Expanding Amazon Elastic VMware Service (Amazon EVS) global connectivity with AWS Cloud WAN

Amazon Elastic VMware Service (Amazon EVS) is a native AWS service that allows you to run the standard VMware Cloud Foundation (VCF) stack within your Amazon VPC. With Amazon EVS, you can now run vSphere workloads with familiar VCF software and tools, while taking advantage of the scale, resilience, and performance of AWS global infrastructure.

Since Amazon EVS is directly deployed within a customer VPC, you can leverage AWS cloud networking constructs for easy access to other native services and connectivity expansion to other regions or on-prem sites.

This post will walk you through a demo on how to connect Amazon EVS with other VPCs and VPN sites across different AWS accounts and regions through the integration with AWS Cloud WAN.

 

Architecture Overview

AWS Cloud WAN is a managed WAN service that lets you build, manage, and monitor a unified global network connecting resources across cloud and on-premises environments. It provides a centralized dashboard where you can define network segmentation and consistently propagate them across multiple AWS Regions through a core network policy. With a simple network policy, you can automate network management from a central control point and deploy a Cloud WAN core network in minutes.

Refer to this AWS blog post to learn more about the core components and the associated concepts of AWS Cloud WAN.

The below diagram is a high-level architecture overview of our demo environment.

 

Pre-requisites

For this demo walkthrough, I have prepared & deployed the following resources:

• An Amazon EVS cluster
  • us-east-2 region
  • VPC CIDR: 10.0.0.0/16
  • EVS/NSX overlay CIDR: 192.168.0.0/20
• A workload VPC
  • ap-northeast-1 region
  • VPC CIDR: 10.251.0.0/16
• An on-prem site with an IPsec VPN Gateway
  • ap-southeast-2 region (via S2S VPN connection)
  • on-prem CIDR: 192.168.100.0/24

 

Walkthrough

This post will walk you through the following steps.

• Deploy a Cloud WAN core network
• Attach workload VPC to the core network
• Attach VPN site to the core network
• Attach EVS VPC to the core network (cross-account)
• Update routing
• Configure DNS & Test

 

Deploy a Cloud WAN core network

To begin, we'll first deploy a Cloud WAN core network. Access the AWS Network Manager console and navigate to Connectivity > Global Networks, choose "Create global network" with the following settings:

• Core network name: your core network name
• ASN range: 64900 - 64999
• Edge locations: us-east-2, ap-northeast-1, ap-southeast-2
• Inside CIDR block (optional): 100.64.0.0/16
• Segment name: dev
• Segment require-attachment-acceptance: false

To streamline network automation, I have also enabled auto attachment policy for the "Dev" segment.

• Rule: 100
• Segment: dev
• Conditions: tag-exists
• Condition value: dev

To expedite the Cloud WAN deployment, you can also use the AWS CLI with the following core network policy.

{
  "version": "2021.12",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "dns-support": true,
    "security-group-referencing-support": false,
    "inside-cidr-blocks": [
      "100.64.0.0/16"
    ],
    "asn-ranges": [
      "64900-64999"
    ],
    "edge-locations": [
      {
        "location": "us-east-2",
        "asn": 64900,
        "inside-cidr-blocks": [
          "100.64.0.0/24"
        ]
      },
      {
        "location": "ap-northeast-1",
        "asn": 64901,
        "inside-cidr-blocks": [
          "100.64.1.0/24"
        ]
      },
      {
        "location": "ap-southeast-2",
        "asn": 64902,
        "inside-cidr-blocks": [
          "100.64.2.0/24"
        ]
      }
    ]
  },
  "segments": [
    {
      "name": "dev",
      "require-attachment-acceptance": false
    }
  ],
  "network-function-groups": [],
  "attachment-policies": [
    {
      "rule-number": 100,
      "description": "auto attachment policy for Dev segment",
      "condition-logic": "or",
      "conditions": [
        {
          "type": "tag-exists",
          "key": "dev"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "dev"
      }
    }
  ]
}

 

Attach workload VPC to the core network

I will first attach a workload VPC in the Tokyo region to the Cloud WAN core network via the Core Network Edge (CNE) in ap-northeast-1. Within the AWS Network Manager, click into the Global Network you just deployed and navigate to Core Network > Attachments to create a VPC attachment. Here I'm also providing a tag with the key/value pair of "dev/true" so the VPC will be automatically attached to the Dev segment.

Within a few minutes, we should see the VPC attachment has been provisioned and automatically attached to the Dev segment, as per the attachment policy rule 100.

 

Attach VPN site to the core network

Next, we will attach an on-prem vSphere environment to the Cloud WAN core network via an IPsec VPN gateway. Navigate to the VPC console, under Virtual private network (VPN) > Site-to-Site VPN connections, click "Create VPN connection". Make sure to select Not associated under the target gateway type, as we'll be attaching this VPN connection to Cloud WAN CNE in the Sydney region (ap-southeast-2).

While we are waiting for the VPN connection to be provisioned, create a Cloud WAN VPN attachment using the same tag for the Dev segment.

The VPN attachment is now automatically attached to the Dev segment as expected.

The VPN connection will be automatically updated to inherit the BGP ASN (i.e. 64902) from the CNE at ap-southeast-2. We can go ahead and configure the VPN tunnels at our on-prem gateway.

 

Attach EVS VPC to the core network (cross-account)

In this demo setup, my EVS cluster is provisioned in a separate account ("Acc Y") to the Cloud WAN account ("Acc X"). As such, we need to first share the Cloud WAN core network with the EVS account for creating the VPC attachment.

Within the Cloud WAN account, navigate to your Core Network and select the Sharing tab to enable resource sharing for your core network.

Next, go to the Resource Access Manager (RAM) to create a resource share of your Cloud WAN core network.

Provide the target EVS account (i.e. "Acc Y") for the resource share.

Now log into the EVS account to accept the resource share for the core network.

Within the EVS account, go to AWS Network Manager > Shared by me > Attachments to create a VPC attachment for the EVS VPC. We should be able to select the core network as shared from the Cloud WAN account.

After the EVS VPC attachment is created, we can see its core network status is showing "Shared".

Back at the Cloud WAN account, we can see the EVS VPC attachment is automatically attached to the Dev segment from a different account.

 

Update routing

Within the Cloud WAN account, navigate to your Core Network and select the Topology tree tab, your core network should look like this.

By default, Cloud WAN will automatically propagate all VPC and VPN routes via dynamic routing between all CNEs. We can verify this within the Routes tab under the core network.

However, since the EVS/NSX segments are overlay networks and do not belong to the native VPC CIDR block, we will need to add static routes for the NSX segments via the EVS VPC attachment. You can achieve this by navigating to Core network > Policy versions, and editing the existing network policy under the Segment actions - optional tab.

Make sure to apply the change set so the new Policy version will take effect.

We can see the summarised EVS/NSX route (192.168.0.0/20) appeared within the Cloud WAN route table under the Dev segment.

Finally, we'll need to update the VPC route table to forward traffic for EVS (VPC & NSX overlay) and VPN routes to the Cloud WAN core network. We'll first update the workload VPC route tables in Tokyo.

We repeat the same step for all route tables within the EVS VPC. Note here we are seeing the specific NSX overlay routes automatically learned via the VPC Router Server within the EVS VPC. Refer to this re:Post for details on how to setup VPC Router Server for your EVS cluster.

 

Configure DNS & Test

At this stage, we have already established L3 connectivity for all our VPCs and VPN site across 3x different regions and 2x accounts. However, in order to access the EVS service (i.e vCenter etc), we still need to configure DNS conditional forwarding for the EVS domain. You can find the revenant DNS information under Amazon EVS console > Overview > Environment.

Note the EVS DNS servers are a pair of Route 53 inbound endpoints, since this is a pre-requisite for the NSX overlay (or external networks) to resolve EVS/VCF management services.

Back at the Tokyo VPC within the Cloud WAN account, we will setup a R53 outbound endpoint with the following forwarding rule.

From a jumphost within the Tokyo VPC, we can resolve and ping the EVS vCenter as expected.

For the on-prem environment, we'll need to setup a DNS conditional forwarder at the local AD/DNS manager.

We are now able to access the vCenter from the on-prem environment.

 

Conclusion

In this post, I have walked through an example of integrating Amazon EVS with Amazon VPC and on-prem VPN site across different AWS regions and accounts, through the integration with AWS Cloud WAN.

To learn more, please refer to the following resources:

• AWS re:Invent 2024 - Amazon Elastic VMware Service: Start your modernization journey with AWS
• AWS Blog: Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration
• AWS Blog: Simplify global security inspection with AWS Cloud WAN Service Insertion