VMware Cloud for AWS - Networking and High Availability

Introduction

This is the first article in a series of two articles which aim to be useful when planning a VMware Cloud/multi-cloud deployment, for example when creating an HLD (High Level Design) document. This first article is about the relevant aspects of VMware Cloud for BIG-IP. The second article, VMware Cloud for AWS - BIG-IP in Single-Site, Hybrid, and Multi-Cloud Deployments, will cover several designs.

VMware Cloud Overview

Many public cloud providers offer VMware Cloud (aka VMC), all are based on the same set of technologies mainly vSphere, NSX-T networking and vSAN storage. It is important to check the requisites because not all providers provide the same features or are developed to the same level. At time of this writing AWS is VMware’s preferred public cloud provider.

VMC on AWS is a managed service provided and billed by VMware. It has the additional features of having access to EC2 workloads, AWS services and flexible access to on-premises deployments (private clouds).

VMware Cloud on AWS, networking and high availability

A VMC on AWS deployment has its own VPC. From operations point of view, management is done through a vCenter and NSX-T management is performed with a constrained NSX manager web UI. This VPC can be seen from AWS’s console.

For production environments VMC on AWS deployments should be configured as “stretched cluster” in which case the VMware components and customer workloads are in two AWS Availability Zones. BIG-IPs should be distributed among these Availability Zones. Thanks to NSX-T’s overlays, the segments spawn transparently across these two Availability Zones, greatly simplifying networking.

From vCenter point of view each Availability zone is seen as a Fault Domain as it can be seen in the next picture.

 

When deploying a VM you can choose an ESXi host in the desired Fault Domain/AWS AZ. In case of failure, the VM will stay in its original Fault Domain/AWS AZ if possible.

Likewise all VMC implementations, VMC on AWS uses NSX-T for networking. VMC for AWS uses a prescriptive model with the following characteristics:

• Customer doesn’t have access to the Tier-0 Gateway.
• Only one Tier-1 Gateway is possible. This is called the Compute Gateway in VMC for AWS.
• Overlapping addresses within the VMC’s VPC are not possible.
• The Service Insertion feature is not available.
• No bundled Load Balancer: the native NSX-T LB is not available.

 

These limits the possible topologies out of the 4 sample topologies described in the F5 BIG-IP deployment guide for NSX-T, customers are currently constrained to Topology D which uses SNAT by default.

A detailed view of VMC on AWS networking can be seen in the next diagram.

Given that at present VMC on AWS provides a single Tier-1 Gateway If a customer wanted to have a replica of an existing private cloud design it would require a separate SDDC per existing Tier-1 Gateway in the private cloud with the corresponding increase of cost. A redesign collapsing several Tier-1 Gateways of the private cloud into one Tier-1 Gateway in VMC on AWS will be needed.

Conclusion

VMC on AWS is an enabler on the multi-cloud journey by minimizing the need to adapt existing know-how and existing automations used in the private clouds. Being a managed solution makes it even easier for going to the public clouds.

At present VMC on AWS greatly limits the possible topologies compared to a private cloud of VMware with NSX-T. This is mainly because of only allowing a single Tier-1 Gateway per SDDC. Once this limitation is removed designs used in private and VMC on AWS clouds will be more homogeneous.