AHEAD VMC On AWS Guide

VMware Cloud on AWS
A Guide to Successful Adoption of VMC

Table of Contents
Introduction: Benefits and an Overview ...................................................................... 4
Overview .......................................................................................................................................................... 5
Chapter 1: Use Cases .............................................................................................................. 6

Use Case #1: Disaster Recovery as a Service ............................................................................ 6
Use Case #2: Bursting ............................................................................................................................ 7
Use Case #3: Data Center Exit ........................................................................................................... 7
Use Case #4: Application Development ........................................................................................ 8
Use Case #5: Data Locality .................................................................................................................. 8
Use Case #6: Licensing ........................................................................................................................... 9
Chapter Two: Configuring HCX on NSX-T SDDC With Direct Connect ............ 10
Overview ........................................................................................................................................................ 12
Step 1: Configuration Steps ................................................................................................................. 13
Step 2: Configuration Steps .............................................................................................................. 15
Chapter Three: Add-On Capabilities, Site Recovery Manager (SRM) .......... 17
Chapter Four: Add-on Capabilities, Hybrid Cloud Extension (HCX) ..................... 21

Use Cases .................................................................................................................................................... 23
Product Features ...................................................................................................................................... 24
Chapter Five: Interoperability With AWS .................................................................... 29

VMware Cloud on AWS Connectivity ............................................................................................. 30
Placement Decisions ............................................................................................................................. 31
Chapter Six: Firewalls ......................................................................................................... 33

VMC: Distributed Firewall .................................................................................................................. 34
VMC: Gateway Firewall .......................................................................................................................... 35

AWS: Network Access Control Lists .................................................................................................. 37
AWS: EC2 Workloads ............................................................................................................................. 38
Finals Thoughts on Firewalls .............................................................................................................. 38
Chapter Seven: VMC Connectivity .............................................................................. 39

VMC Connectivity with AWS Services ........................................................................................... 39
VMC Connectivity with On-Premises Data Centers ................................................................ 42
AHEAD can help you get the most from VMC on AWS ....................................... 47
Appendix ................................................................................................................................ 48
Has your enterprise successfully integrated
VMware into your environment and are now
looking to reap the benefits of the cloud?
That’s a sound plan, but this migration isn’t
as easy as flipping a switch, especially if
you’re looking to continue running your
VMware environment.
The effort is worth it though. The ability to

utilize your existing VMware tools on an
AWS platform can result in a more cost-
effective, simplified cloud experience,
allowing your organization to begin its cloud
journey by moving workloads closer to native
cloud services.
In this eBook, we will offer a complete view of

what you need to know to make your VMware
Cloud on AWS (VMC) journey successful.
3 | VMC on AWS: an eBook to Help You Succeed with VMware on the Cloud
INTRODUCTION
Benefits and an Overview
VMware Cloud on AWS can provide some great options if you’re
experimenting with the public cloud. If you’re tired of managing resource
capacity and budgeting for hardware, running out of resources for developing
mentor mergers, or if you need to get out of the data center altogether,
VMware Cloud on AWS may be the right path for you.
If you’re considering moving some of your workloads to the public cloud, you
may be aware of some of the benefits of VMware Cloud on AWS and how it
can help your enterprise bridge the gap between data center and cloud.
Some of the advantages of VMC on AWS include:
■■ Simplified operations: Manage both on- and off-premises data

using the same tools, while hypervisor allows accelerated adoption
with minimal re-training. Retain a similar environment in your data
center, but now in VMware on AWS.
■■ Reduced operational cost: Organizations with a restricted

budget or education plan can still have a cloud-like environment
outside of the datacenter. Reduce the need to re-train IT, staff, saving
both time and money.
■■ Accelerated migration: Gain a simplified and streamlined

migration factory with familiar tools. Focus up the stack on the
application and not on the infrastructure.
■■ Increased innovation: Move workloads closer to native cloud

services that drive innovation, such as databases, analytics, IoT,
AI/ML, security, and mobile. Move applications closer to native
cloud PaaS services like RDS for a phased approach to cloud native
refactoring, allowing the business to continue operating while you
reinvent and innovate
vSphere
NSX
vSAN
ESXi
AWS Infrastructure
The entire solution is subscription-based, so you can spin up additional hosts as needed.
VMware is responsible for managing the main components and upgrades, and you are
responsible for your virtual machines.
Overview
If you’re not already familiar with VMware Cloud on AWS, here’s a
1,000-foot-high overview. Essentially, it’s VMware vSphere running on top
of AWS-provided infrastructure and services. VMware ESXi is installed on
AWS Bare Metal servers, and the maintenance for those servers is provided
by AWS and VMware. These ESXi servers are managed by a hosted version
of vCenter, with NSX utilized to provide software-defined networking and
vSAN for the storage layer for your virtual machines.
CHAPTER ONE
Use Cases
Now that you have a good understanding of the
benefits and the core concept behind VMC on AWS,
let’s dive into the use cases.
Use Case #1: Disaster Recovery as a Service

A great place to start with VMware Cloud on AWS is for disaster recovery.
If you’re a big VMware shop, you probably have a primary data center and
a secondary location in case of a major emergency. You might even be
using VMware Site Recovery Manager (SRM) to replicate, test failover, and
perform production failovers/migrations to your second data center. If
that’s the case, VMware Cloud on AWS might be worth looking into.
Also, that second data center can be expensive to maintain. Physical
servers, network equipment, rack space, HVAC, and electricity all cost
money. If it’s your DR site, they’ll probably sit there collecting dust until you
really need it.
VMware Cloud on AWS would allow you to have a small, four-node
cluster on AWS’ infrastructure that could be ready to go for your VMware
workloads—with all still protected through VMware SRM. Those four ESXi
hosts set up in the public cloud would be much cheaper than managing all
that infrastructure in a second data center. And, if you need more than four
hosts, you can expand your clusters in minutes, so there’s no reason to pay
for peak capacity when you’re not having a disaster event.
Use Case #2: Bursting
The term bursting has been overused, but it does have its place in this
conversation. Capacity planning is a difficult process for even the most
mature of IT organizations. Sometimes, we get it wrong and don’t have the
proper capacity to run our workloads. This can be especially difficult for
organizations that go through mergers or acquisitions frequently—and have
no idea how much capacity will be needed for the next 12-to-18 months.
VMware Cloud on AWS may be an option here since you pay only for what
capacity you’re using. Instead of buying an extra storage array or more
physical servers, we can aim for what we think we’ll use—but not buy
that extra “just-in-case capacity.” Now, we can leverage the elasticity of
the cloud to spin up ESXi hosts when we need them permanently—or just
temporarily until we’ve purchased that hardware for our data center.
Use Case #3: Data Center Exit

Maybe you’ve already decided that you’re done being in the “data center
business.” You’re going to move all your workloads to AWS and turn off the
lights in the data center. Sounds great, but when you start to move your
applications, are you going to re-architect all of them to take advantage
of cloud elasticity? Will your web servers be part of an auto-scaling group
across Availability Zones? Will your databases be ported over to Amazon
RDS? Will you convert some of your scripts to serverless? Or is some of
this overwhelming to you or your engineers who might not have much
experience with AWS?
VMware Cloud on AWS may provide some additional help in moving to the
cloud. Some of your applications may have been around for a long time,
and no one knows exactly how they operate, so moving them is risky.
Perhaps you can alleviate some of these concerns by using a familiar
platform, such as vSphere and vMotion them to the cloud.
VMware Cloud on AWS behaves similarly to a traditional on-premises
environment. Mechanisms such as cross vCenter migration and long-
distance vMotion have been augmented with HybridCloud Extension (HCX)
to make migrations to the cloud simple. With these tools, moving workloads
to VMware Cloud on AWS is almost as simple as a vMotion activity. There’s
no re-architecture necessary, and the same vSphere constructs you’ve
become acclimated to can be used in your new cloud environment.
Use Case #4: Application Development
Do you have more physical resources available for test and development
workloads than for production resources? Many times, that data center
footprint is vacant until a new project arrives and, after it’s rolled out to
production, it becomes vacant again.
Why not leverage the elasticity that the cloud provides and execute your
application development on VMware Cloud on AWS? You can build your
projects and test them for viability. When you’re done with the project and
have deployed your production servers to your on-premises data center,
you can spin down the resources in the cloud and stop paying for them.
Use Case #5: Data Locality

Maybe you’ve already started down the path of moving some workloads to
AWS. You’re finding great value out of features like multi-AZ load balancing
and autoscaling group. Or you love RDS to manage your databases,
but you’ve got a cranky app server that needs to stay on VMware and,
therefore, needs to be near the data that you’ve placed on AWS.
VMware Cloud on AWS lives within one of your own AWS Accounts and
is connected to an AWS Virtual Private Cloud (VPC). This means that you
can still have your VMware infrastructure talking to your AWS workloads,
but instead of having it over a higher latency WAN connection, they can be
within the same VPC. As a result, you can leverage the AWS networking
backbone to keep your roundtrip time low for your application. With that
said, why not get the best of both worlds by having VMware resources and
AWS resources side-by-side in the cloud?
Use Case #6: Licensing

You may have found that you’ve got Enterprise License Agreements (ELAs)
that prohibit you from moving your already-licensed workloads to the
cloud. Some licenses were sold as host-based licenses, where you license
the entire VMware ESXi host, and then any machines running on that host
are covered. If you try to move the VM to a shared tenancy model that is
commonly used in the public cloud, you can no longer license an entire
host—and may need to change how your licenses are managed.
If you’re in the middle of an ELA, this might prohibit you from making the
jump to the public cloud until you can pay for the change to licenses. But
VMware Cloud on AWS might be a solution for you since each ESXi host
can still be managed. You may be able to port your host license over to
your VMware Cloud on AWS ESXi hosts and then keep your licensing intact
as you move workloads to the cloud.
CHAPTER TWO
Configuring HCX on NSX-T
SDDC With Direct Connect
VMware Cloud on AWS is evolving on a weekly—maybe even daily—basis.
So, not unexpectedly, one of the foundational components of VMware
Cloud on AWS—NSX—has also undergone transformational change. The
original release of VMware Cloud on AWS was underpinned by NSX-V, a
tried and true SDN solution.
However, VMware recognized that NSX needed to support more than
just vSphere—and that it also needed to meet the demands of web-scale
environments like AWS. So, NSX-T was born, and it’s now the default for
VMware Cloud on AWS. In addition to NSX-T, VMware has also expanded
the connectivity options for VMware Cloud on AWS.
With an NSX-V-based VMware Cloud SDDC, connectivity to the
Management Gateway (MGW) and the Compute Gateway (CGW) had to
run across separate connections. In this scenario, only ESXi Management,
cold migration or network file copy/NFC, along with live migration/
vMotion traffic is supported across a Direct Connect. All other traffic, like
management appliance traffic (e.g., vCenter, HCX Cloud Manager) and
compute/workload traffic, is carried over VPN connected to the public side
of the SDDC VPC.
Now, with the NSX-T-based VMware Cloud SDDC, all traffic to the Management Gateway and
the Compute Gateway can be passed across a Direct Connect.
Overview
When switching to a Direct Connect-only design, some things need to
be considered. For example, when you try to access the SDDC vCenter
for configuring things like HLM or when trying to access the HCX Cloud
Manager after it is deployed—both of which default to using their Public
interface for management access when they are deployed—you will likely
need to reconfigure the communication interface with your on-premises
data center.
Changing the configuration for the SDDC vCenter to have it resolve to its
Private Interface—versus its Public Interface—is easy to do. You simply go
into the “Settings” section of the VMware Cloud Console and change the
vCenter FQDN to use the Private IP that is assigned.
If you’re using a VPN that has split tunnel disabled to execute all of the configuration, additional
routing, and name resolution configuration may need to be done to pass traffic from the SDDC
back to the data center (through the AWS Direct Connect) and then through the VPN.
With that said, HCX is a little more involved. Unlike the SDDC vCenter, the
HCX management console doesn’t have an entry under “Settings” like
vCenter does. So, when you reach the point in the HCX deployment where
you are instructed to “click the Open HCX button” under the “SDDCs” tab,
you may not be able to connect to it (e.g., You’ll get a “connection timed
out” message in your browser). The most likely cause of this is because the
link defaults to using the Public interface for connecting to the HCX Console.
A temporary workaround for this is to go into the VMware Cloud SDDC
vCenter (not the VMware Cloud Console) and find the Private IP for the
hcx_cloud_manager VM under Hosts and Clusters and use that to connect
to the HCX Cloud Console in your web browser (It should be something like
https://<vm_local_ip>/hybridity/ui/services-1.0/hcx-cloud/index.html#/login).
Assuming all else is correct with routing between your on-premises data
center and the VMware Cloud SDDC, you should be able to access the HCX
Cloud Management Console successfully.
The tasks for getting everything configured and working can be broken
down into two sections. The first section covers what is provided in the
VMware documentation, along with some clarification on several of the
configuration steps. The second section will outline some additional
steps that will need to be taken to configure the Edge Firewall (a.k.a., the
Gateway Firewall) that are not documented as of this time.
Step 1: Configuration Steps

Follow the configuration steps listed in the Configuring HCX for Direct
Connect Private Virtual Interfaces section of the VMware NSX Hybrid
Connect User Guide here.
The documentation below shows the procedure for re-configuring the HCX
Interconnect as follows:
1. Log in to the VMware Cloud Console at vmware.com.
2. On the Add-ons tab of your SDDC, click “OPEN HYBRID CLOUD
EXTENSION” on the Hybrid Cloud Extension card.
3. Navigate to the SDDCs tab and click “OPEN HCX.”
The first issue you will need to address is at step three when you are instructed to
“Open HCX.” If you connect to the VMC SDDC through a VPN that has Split Tunnel
disabled, you won’t be able to connect to the HCX Console via its Public Interface
to complete the configuration. There are also some other scenarios where you
may not be able to access the HCX Console, such as not being able to access the
Internet from where you are connected to your on-premises data center.
As mentioned earlier, you can use the Private Interface IP to access the HCX Cloud
Console, but ideally, you will want that to work as intended when you click the
“Open HCX” button in the VMware Hybrid Cloud Extension UI.
To access the HCX Cloud Console on its Private interface, some changes need
to be made to force HCX to pass all traffic across the Direct Connect—including
console traffic. This is where things get a little confusing.
Based on the instructions in the VMware documentation (as shown above) the
procedure makes sense until you reach steps 4 – 8, where you end up in a bit of a
chicken-and-egg situation. For HCX to send all traffic over the Direct Connect, you
need to reconfigure the Interconnect interface, which requires you to log in to the
HCX Cloud console as administrator@vmc.local: “Wait … neither customers nor
partners are given administrator@vmc.local credentials”.
Next, when it says, “This procedure requires a VMware Support account,” does that
mean if you’re listed as a support contact for your company’s VMware account,
you should be able to do this? The answer to that question is no.
What all of that actually means is that you will need to contact VMware’s Cloud
Support team to make the change—at least until they make that capability
available for the “cloudadmin” account. The easiest way to do this is through the
online chat support in the VMware Cloud Console.
4. Enter the administrator@vmc.local user and credentials and click “LOG

IN.” (Note: In the current release, this procedure requires a VMware
Support account, in the upcoming release, the cloud administrator will
be able to perform this operation).
5. Navigate to the Interconnect Configuration section of the
Administration tab and click Edit.
6. Locate the Network Profile with Type: Internet and click the X to delete it.
7. Create a Network Profile:
■■ Select the “Distributed Portgroup” Network Type
■■ Select the “Direct Connect Network” Network Type
■■ Enter the private IP address ranges reserved for HCX.
■■ Enter the Prefix Length and the Gateway IP address.
8. Click Next and then click Finish.
When you’re ready to proceed with step 4, you’ll need to make sure you have
already removed any HCX Interconnects that were previously deployed for
the specific VMware Cloud SDDC you’re working with. This is because those
components will need to be re-deployed once you get to the on-premises portion
of the HCX deployment. VMware support will also ask you to confirm that any
previously deploy HCX Interconnects for this SDDC have been removed and will
then ask for the CIDR range you want to use with HCX.
Once you have provided VMware Cloud Support with the pertinent information,
they will make the changes on the backend, which usually takes 2-to-4 hours.
In addition to the changes VMware Cloud Support needs to make to have HCX
Cloud use the Direct Connect, some other changes will need to be made in the
Gateway Firewall.
Step 2: Configuration Steps
For the HCX Enterprise Manager—that you will deploy in your on-
premises data center—and the HCX Provider to communicate
with the HCX Cloud Manager, some Edge Firewall rules will need
to be configured.
First, you will need to create entries in the Networking & Security > Inventory > Groups >
Management Groups section for the HCX activation and update servers (connect.hcx.
vmware.com and hybridity-depot.vmware.com) to use with the rules for allowing the HCX
Cloud Manager to communicate with the Mothership
Second, you will want to create a rule in the SDDC Gateway Firewall that allows the HCX
Cloud Manager to communicate on port TCP-443 to the HCX provider sites you just created
for activation and updates. (Note: The image shows “ANY” as the services, but 443 is all that
is needed).
Third, you will create a rule in the Management Gateway Firewall that allows inbound access
from your on-premises networks (the ones where the HCX Enterprise components will
reside and any that will be stretched by HCX to the VMware Cloud SDDC).
Next, you will create a Gateway Firewall rule that allows inbound access to the HCX Cloud
Manager from external (in this case ANY) on port TCP-443.
Once these steps have been completed, you should be able to access
the HCX Cloud Management Console using the OPEN HCX button on the
SDDCs tab, and all traffic for HCX (except its communication with the
provider) should be sent across the Direct Connect between your on-
premises data center and the VMware Cloud SDDC.
One final note, particularly if your VMware Cloud SDDC has been configured
to use on-premises DNS servers: Make sure all of the other solutions that
are deployed to support on-premises to VMC failover, DR or migration
(e.g., SRM, vR, etc.) are configured to use the Private IP address of the
corresponding components hosted in the VMware Cloud SDDC.
CHAPTER THREE
Add-On Capabilities, Site
Recovery Manager (SRM)
It’s time to get used to a world where our infrastructure lives on someone
else’s hardware. This now includes running our vSphere hypervisor on
Amazon’s servers, along with giving up the ongoing maintenance of our
vSphere environment. It will be a difficult time for us to get used to not
performing patch management and upgrades of our ESXi servers, but rest
assured that VMware will be handling this task for us when we move to the
VMware Cloud on AWS solution.
What about those auxiliary components that we’re accustomed to
managing alongside our vCenter servers though? You remember those
things—like VMware Site Recovery Manager (SRM), for example.
If you’re not familiar with SRM, it’s a licensed tool by VMware used for
migrating workloads from one vCenter to another. These migrations could
be for a planned outage or a data center move—or the tool can be used to
recover protected VMs in the case of a data center outage. Version 1 of
SRM has been around since 2008, so the tool is a very mature migration
and disaster recovery solution used by many organizations around the
world. The tool requires you to deploy a Site Recovery Manager server
in each of your sites and then pair them together. The SRM servers
communicate with their local vCenter and handle the orchestration of your
migrations or failovers.
Protected Site vCenter Recovery Site vCenter
vCenter Connection vCenter Connection
SRM Site
Pairing
Protected Site SRM Server Recovery Site SRM Server
Protected Site VMs Failover Recovery Site VMs
Protected Site Recovery Site
How does this change in the cloud world? Well, remember that VMware
now manages our vCenter, so we don’t have to deploy it any longer, but
some of our auxiliary tools—like SRM—can still be used with our cloud
version of vCenter and even better, VMware will manage this for you, as
well! VMware has added some “Add-Ons” for VMwareManagedCloud onbyAWS VMware
so
that you no longer have to manage the components on the cloud side. Two
Add-Ons are available for VMware Cloud on AWS: Hybrid Cloud Extension
and Site Recovery.
SRM Site
Pairing
From within the VMware Cloud on AWS SDDC console, you only need to click the “Activate”
button to add Site Recovery to your VMware Cloud on AWS environment.
Clicking the Activate button will give you further direction on what needs to be completed for
the on-premises side, which would include downloading components for deploying the Site
Recovery server for your on-premises vCenter.
After activating, you’ll need to wait a few minutes before the Site Recovery server appears in
your VMware Cloud on AWS environment.
Once complete, you can see the Add-On is activated, and you have a link to download the
components. Here, you’ll download and install the components on-premises, and when you’re
done, you’ll notice the architecture for Site Recovery looks a lot like what you might have been
used to with Site Recovery Manager. The main difference being that you don’t need to deploy
or manage some components yourself—just activate an Add-On.
Managed by VMware
SRM Site
Pairing
This is focused on the Site Recovery example Add-On, but HCX would
follow a similar path where you activate the Add-On within the SDDC side
and deploy your HCX components yourself on the on-premises side. Right
now, there are only two Add-Ons available for VMware Cloud on AWS, but
it’s pretty reasonable to assume that VMware will also introduce new Add-
Ons for their other products, like vRealize Automation (vRA) or vRealize
Operations Manager (vROps).
If you plan to use the HCX Add-On, it’s provided for free to use with
migrations to VMware Cloud on AWS. The Site Recovery Add-On has a fee
associated with it, but currently, there is a promotion running to allow the
first 200 VMs protected—free of charge! For more details on the promotion,
reach out to your VMware account manager or better yet, contact the
AHEAD team to leverage our partnerships with VMware and AWS.
CHAPTER FOUR
Add-on Capabilities, Hybrid
Cloud Extension (HCX)
VMware Hybrid Cloud Extension (HCX) removes many of the barriers to
keeping businesses from realizing a variety of multi-site and multi-cloud
solutions. HCX is probably one of the coolest VMware products that many
people still don’t know about. Even among virtualization experts, very few
people really know what it is and what it can do. In our view, HCX is going
to become a key component in VMware’s push to pave the way to not only
Public and Hybrid Cloud but on-premises multi-site designs as well.
In a nutshell, VMware HCX is a SaaS offering that combines a set of
network features that provide what is referred to as “Infrastructure
Hybridity.” These features ease the challenges around connecting on-
premises data centers and cloud, delivering infrastructure hybridity for
vSphere 5.0 and newer versions.
Any to Any vShpere Version
Hybrid Interconnect
Large Scale Migration
Cross Version Hybridity Security
For anyone who has had to do migrations from one environment to another
with minimal downtime (that means no downtime to management and the
AppDev teams), you know that there is a myriad of networking variables
that can affect even the best plan. Well, good news! VMware HCX can solve
those challenges, making migrations simple and pain-free.
HCX provides a solution for two use cases: on-premises to Public Cloud
and on-premises to on-premises connectivity. Despite on-premises to
Public Cloud being useful, we believe the on-premises to on-premises use
case will see more demand overall, particularly for migration purposes.
To that point, VMware has added HCX to NSX Enterprise Plus edition and
has changed the name to NSX Hybrid Connect. No confusion there, right?
We’ll cover the details of common use cases and then do an overview of
the components that make up the solution. Finally, we’ll call out a couple of
things to be aware of with certain configurations.
Use Cases
Migration
This is, hands down, the most common use case for HCX. Modern data
centers have become very complex, sometimes having hundreds of
dependencies for the virtual infrastructure and applications. Anyone who’s
gone through an application dependency mapping exercise knows it’s not
trivial. And, with all of the integrations that are now so prevalent in virtual
environments, it’s nearly impossible to upgrade one product or solution
without affecting other components or solutions.
And then, what happens when upgrading isn’t an option? For instance,
perhaps you still run vSphere 5.1 or have hardware that is well past EOL. In
cases like these, choosing migration over upgrading may be the best way
for you to move forward with modernizing your environment.
For those that have chosen to accept an excessive amount of technical
debt (those that have chosen to stay on vSphere 5.x), fear not, all of the
HCX features are supported with vSphere 5.x and above.
Hybrid Cloud
Another area that customers are looking at very closely right now is Hybrid
Cloud Adoption. HCX helps solve several challenges associated with
adopting a Hybrid Cloud. For example, with HCX there is no need to wait
for carriers to provision WAN circuits for things like AWS Direct Connect,
and no need to upgrade networking hardware or modify on-premises
networking to extend L2 networks to the cloud.
Disaster Recovery
HCX also provides the ability to protect workloads at primary or secondary
sites for Disaster Recovery. You can even run test and planned failovers,
then reverse the replication and execute failback. If you have experience
with VMware Site Recovery Manager, this will sound familiar. However, HCX
is not (currently) a replacement for SRM, more like a lite version. HCX can
do scheduled migrations between source and destination sites, but it does
not have the robust orchestration capabilities of SRM.
Product Features
Moving on to more specifics about HCX product features, here’s
what it currently offers:
Bulk Migration
This migration method uses the VMware vSphere Replication to move
virtual machines to a remote site.
■■ This option is designed for moving many (up to 100) VMs at the
same time.
■■ Migrations can be set up to run on a pre-defined schedule.
■■ Virtual machines run at the source site until the migration begins. The
service interruption with this type of migration is equivalent to a reboot.
HCX vMotion
This type of migration is just like the vMotion most of us have come to know
and love, even allowing virtual machines to keep their IP and MAC addresses.
■■ This option is designed to move a single virtual machine at a time.
■■ Virtual machine state is migrated, with no service interruption during

the migration.
HCX Cold Migration

This migration method uses the VMware NFC protocol. NFC is
automatically selected when the source virtual machine is powered off.
HCX Replication Assisted vMotion

Also known as Cloud Motion, this new migration combines the capabilities
of Bulk Migration (parallel operations, resiliency, and scheduling) with HCX
vMotion (zero downtime virtual machine state migration).
■■ The migration begins with the replication of the virtual machine’s
disks. As with Bulk migration, virtual machines can be migrated in
parallel, and the switchover is configurable on a schedule.
■■ During the RAV switchover phase, vMotion is engaged for migrating

the disk delta data and virtual machine state.
■■ This is currently in preview for VMware Cloud on AWS customers and

has additional requirements.
HCX Network Extension (VLAN and VXLAN)
HCX Network Extension provides a High-Performance (4–6Gbps) service
to extend Virtual Machine networks to an HCX enabled remote site. Virtual
Machines that are migrated or created on the extended segment at the
remote site are Layer 2 adjacent to virtual machines on the source network.
■■ Allows your virtual machines to retain their IP and MAC addresses
and retain their existing network policies (when used with HCX
Migration)
■■ Can extend VLAN and VXLANs networks (extending VXLAN requires

NSX integration at the source site)
■■ Extend Cisco Nexus 1000v networks
HCX automatically deploys the Remote Site appliance whenever a local

appliance is deployed (e.g., the Network Extension service appliances are
always deployed as a pair).
Target Site
NSX Edge Router
Local Site HCX Target

Gateway Manager
HCX Source
Manager P
VPN V VM-A21
192.168.10.20/24
VM-A20
192.168.10.20/24 Network A
First Hop Gateway
192.168.10.1/24
Virtual Machine Network A Virtual Machine Network A Extended
Virtual Machine Network B Virtual Machine Network B Native

Secure HCX
WAN Transport
vSphere Distributed Switch vSphere Distributed Switch
Local HCX Remote HCX

NET-EXT NET-EXT
Or Private Circuit WAN Boundary:

Data Center A (On-Premises) Internet Data Center B (Cloud)
HCX Enabled Source Site HCX Enabled Target Site
By default, when using Network Extension, the default gateway for the extended network only
exists at the source site. Routed traffic from Virtual Machines on the remote side of extended
networks will return to the source site gateway.
HCX Network Extension with Proximity Routing
Proximity Routing builds on HCX Network Extension by integrating with
NSX Routers at the HCX Cloud destination site and dynamically injecting
VM routes into the routing protocols. This allows ingress traffic from the
local and remote data centers to use an optimal path to reach the extended
Virtual Machine while ensuring all flows remain symmetric.
The Proximity Routing feature is toggled on during the HCX Network
Extension operation but be aware that there are additional requirements to
leverage this feature.
HCX Disaster Recovery

HCX Disaster Recovery provides a simple and easy to manage solution that
can protect VMs deployed on-premises or in a public cloud like VMC on AWS.
HCX Disaster Recovery provides the following:
■■ Secure, asynchronous replication and recovery of virtual machines
■■ Self-service RPO settings from 5 minutes to 24 hours per virtual

machine
■■ Reverse failover of workflows to the source site
■■ Multiple points in time recovery snapshots that allow recovery for up

to 24 previous replication points in time
■■ Optimized replication throughput by use of WAN Optimizer
■■ Ability to route replication traffic across a direct connect network
■■ On-premises monitoring and management with the vSphere Web

Client integration plug-in
HCX Components
HCX is the management plane of the platform and is comprised of a virtual
management component at the source and destination site, and up to
three types of HCX Interconnect service appliances which, when combined,
provide Infrastructure Hybridity.
HCX services are deployed as virtual appliances at the source site, with a
corresponding peer appliance deployed at the remote site.
HCX Manager
There are two versions of HCX Manager defined for HCX Architecture –
Source or Destination. The key differences between them are pretty minor
but important to understand.
HCX Enterprise Manager is always a source type. It is responsible for
integration with the on-premises vCenter and installation of the HCX plugin
into the vSphere Web Client. After HCX Enterprise Manager is paired with a
remote site, it enables the deployment of the other HCX components.
HCX Cloud Manager is part of VMware’s HCX for Cloud model. With this
model, the CSP deploys HCX Cloud, and a tenant deploys HCX Enterprise
on-premises. HCX Cloud is always deployed as a destination type.
NSX Hybrid Connect is VMware’s HCX for Private Cloud model. With this
model, the tenant deploys both source and destination HCX Managers.
To clarify, here’s what that looks like in the different scenarios:
HCX Enterprise HCX Cloud

Manager Manager
On-premises to Public Cloud
App Mobility
Infrastructure Hybridity
Infrastructure Abstraction
VMware Cloud
on AWS
Legacy DC
Internet/WAN
HCX Enterprise NSX Hybrid

Manager Manager
On-premises to on-premises
App Mobility
Infrastructure Hybridity
Infrastructure Abstraction
Legacy DC SDDC with

Internet/WAN NSX Enterprise Plus
From a management standpoint, there are a couple of things to consider.
First, even though HCX Manager is paired with a vCenter server when it is
deployed at the remote site, there is no HCX Web Client plugin installed in
the remote vCenter, so all HCX configuration and migration activities must
be completed from the source site.
Second, the HCX Manager GUI at the remote site does provide disaster
recovery capabilities, but it can only be used during an actual disaster
recovery event where the source site is unavailable.
HCX WAN Interconnect

VMware has taken vMotion and vSphere Replication and merged them into
a single appliance solution that provides encrypted replication and vMotion
based migration capabilities over the Internet and direct connect to a target
site, along with traffic engineering, and virtual machine mobility.
HCX WAN Optimization

If you look at the details, you may notice that it is a customized Silverpeak
WAN Optimization virtual appliance. It improves the performance of the
WAN and Internet links by compressing and deduplicating the migration
traffic. On top of that, the WAN Optimization appliance uses path
conditioning techniques, such as Adaptive Forward Error Correction and
Real-Time Packet Order Correction, to minimize the number of retransmits
and increase the overall performance of the network between sites.
HCX Network Extension

The HCX Network Extension virtual appliance extends L2 broadcast
domains to the remote sites over an encrypted tunnel. This allows VMs to
keep the same IP and MAC address during migration.
Network Extension with Proximity Routing enabled ensures that forwarding
between virtual machines connected to extended and routed networks,
both on-premises and in the cloud, is symmetrical.
CHAPTER FIVE
Interoperability With AWS
Here’s the scenario: You’re thinking of migrating some of your
workloads to VMware Cloud on AWS from your on-premises
data center. You’re also doing a bit of dabbling in the AWS cloud
using some of their native services, such as Relational Database
Services (RDS) or Elastic Container Services for Kubernetes (EKS).
So, now you’re wondering, “Can I use these two cloud environments
together?” The short answer is, “Of course you can.”
VMware Cloud on AWS Connectivity
It’s very important to know that your Software Defined Data Center (SDDC)
will live within an AWS Virtual Private Cloud (VPC). Your SDDC will be
deployed with a gateway appliance, which is managed by VMware. There is
no deployment configuration to worry about from the customer side except
for providing the firewall rules that live within it. Internal to VMware Cloud
on AWS, this gateway serves as a router for the port groups in which the
VMware virtual machines live. This Gateway will have a network interface,
which is located within one of the AWS subnets (AWS calls this an elastic
network interface or ENI).
This ENI gives us all the connectivity that we need for our virtual machines
in the SDDC to communicate with services in an AWS VPC. Additionally,
this gateway contains an edge firewall for blocking traffic between the
SDDC and outside resources like those within your AWS VPCs or other
external networks.
The edge gateway is broken into two parts. The first part is for the
management components for your SDDC such as vCenter, Site Recovery
appliances, NSX managers, etc. The second part is a firewall for the
workloads that are deployed within the SDDC, like your production web
servers, for example.
The VMware SDDC console allows you to independently create your own firewall rules to meet
your needs.
Placement Decisions
The real question isn’t whether you can connect resources together,
but rather which workloads should be placed in the VMware Cloud
versus the AWS cloud.
This can go a myriad of ways, but a common scenario would be to focus
on applications that are critical to the business generating revenue and
your internal development desires. For example, let’s assume you need to
move your workloads to the cloud, but many of your applications are just
some software you bought from a vendor and live on a server operating
system. That old application used by the sales team to store documents is
important to the business, but very little development is done on it since it’s
purchased from a third party and doesn’t add much value when improved.
It’s not worth doing too much to this application, so a quick migration to
VMware Cloud on AWS probably makes sense here.
On the other hand, let’s say your corporate web page is updated often
and has many moving parts, including sales leads, a shopping cart, and
marketing information. Your web page is mission-critical to the business.
This site is being developed by internal development teams and is the
centerpiece to your organization’s money-making strategy. This is an
application where breaking it into microservices might make sense so that
each part of the application can scale independently. Here we can take
advantage of AWS managed services, like CloudFront, S3,
ElasticBeanstalk, and others.
The main point is that, with VMware Cloud on AWS, you have the
flexibility to choose where your workloads will live and determine the
applications that deserve application development time—and which ones
you’re just maintaining.
VMware Cloud on AWS and AWS VPC resources can certainly be used
in conjunction with each other. Maybe you split resources up based on
licensing needs, maybe you split them up based on your development
goals, or maybe you start testing out new services once you get into
the cloud. Either way, VMware Cloud on AWS gives you the flexibility to
intermingle these services in the way your organization sees fit.
CHAPTER SIX
Firewalls
If you’re getting started with VMware Cloud on AWS, then you should be
aware of all the points in which you can block traffic with a firewall. Or, if
you look at it another way, the places where you might need to create allow
rules for traffic to traverse your cloud. This chapter covers where those
choke points live both within your VMware Cloud on AWS SDDC, as well as
the Amazon VPC in which your SDDC lives.
Let’s take a look at each of the items to discuss what they are and where
they are configured.
The diagram above shows each of the firewalls that might live between a virtual machine
within your VMware Cloud on AWS environment and an Amazon EC2 instance in a subnet
within the same VPC.
VMC: Distributed Firewall
The first firewall is within the VMware Cloud on AWS environment and is
the distributed firewall provided by NSX-T. Much like NSX on premises,
you can create firewall rules at the NIC level of the virtual machines in
the VMware environment. This firewall is optional and doesn’t need to be
configured to allow traffic by default. It also requires that you have the NSX
Advanced Add-On feature for your VMware Cloud on AWS environment.
Again, this firewall is optional.
To configure these firewall rules, you would use your SDDC Console for VMC.
VMC: Gateway Firewall
The second firewall we’ll discuss is the gateway firewall. This is like a
perimeter firewall for your VMware Cloud on AWS environment. If you
want to be able to access your vCenter and your workloads, this firewall
will need to be configured. The gateway firewall consists of two parts,
a management gateway firewall and the compute gateway firewall. The
rules created for vCenter, SRM, and any of the components that VMware
manages for you in the cloud are built in the management gateway firewall.
Any of your workloads that would get deployed in the VMC would be done
in the compute gateway firewall.
Each of these is configured in the SDDC console.
AWS: Elastic Network Interface for VMC
Security Group
VMware Cloud on AWS lives within an AWS Virtual Private Cloud (VPC).
The gateway we discussed in the previous section is connected to the AWS
VPC with an elastic network interface. Think of this as a VM’s network
adapter that lives in AWS. This is the network bridge between your VMware
environment and your AWS environment. We discussed that we need to
create firewall rules in the gateway, but we also need to create the security
group rules on the network interface on the AWS side.
This is configured in the AWS console under the EC2 screen. It should also
be noted that the VMC may create several of these ENIs when it’s first built,
so you’ll need a security group attached to all of them with your configured
rules. By default, VMware creates the rules for you, but it uses a default
security group from AWS. Be aware of this because many customers don’t
want to use a default security group and want to create their own.
AWS: Network Access Control Lists
This item is another optional component. An AWS Network Access Control
List (NACL) is a stateless firewall that is applied at the subnet level of an
AWS VPC. These NACLs provide an extra level of protection within a VPC to
block traffic for resources within the entire subnet.
AWS NACLs are configured in the AWS Console under the VPC screen.
AWS: EC2 Workloads
The last one is an example of a resource in AWS that is trying to
communicate to VMC resources. AWS requires that a security group (even
an allow all group) be assigned to each EC2 instance that is deployed. In
fact, currently, you can add five security groups to an EC2 instance at a time.
This is the same type of security group that was applied earlier to the ENI
for the VMware Cloud Gateway. This firewall rule is optional unless you want
your EC2 instances to be able to communicate with your VMC environment.
If you require VM to EC2 instance connectivity, it must be configured.
Again, security groups can be added in the AWS console under the EC2 screen.
Final Thoughts on Firewalls

Hopefully, this chapter gave you a good idea of the different firewalls that
might be in place in your VMware Cloud on AWS environment and AWS
VPC. Our suggestion is to carefully plan out if you need all these firewalls,
including the optional ones. From there, you can decide if you need granular
rules in each choke point, or if you will allow all traffic through some.
For instance, maybe your compute gateway firewall allows all traffic by
default and you leave the firewall responsibilities to the distributed firewall.
That may be an extreme case, but it is likely that some of these firewalls
will have more open rules than others.
And, if you’re still having connection issues after reading this chapter, don’t
forget about your client firewalls as well. A Windows firewall can ruin your
whole day sometimes.
CHAPTER SEVEN
VMC Connectivity
If you’ve deployed and managed a vSphere environment before,
then setting up a VMware Cloud on AWS environment should
be a snap. You enter your sizing into the SDDC portal and then
submit your cluster request and grab some coffee. But after its
deployed, you’ll likely need to do some configuration of your network
connections to tie it in with the rest of your environments that
already have workloads running in them.
VMC Connectivity with AWS Services

Before we get to networking topologies, we need to know how the VMware
Cloud on AWS cluster is connected to our AWS VPC by default.
When we first deploy VMC, it will need to be placed in an AWS Virtual
Private Cloud, which is Amazon’s networking construct. The VMC
environment contains an edge gateway that provides the VMC environment
with a perimeter firewall, a VPN Endpoint, routing capabilities and Network
Address Translation (NAT). This edge router in the VMC environment has a
network interface that is housed within the AWS VPC, and this is used for
connecting with other AWS services such as S3, NFS, and EC2.
Above, you can see the VMC has an edge gateway appliance with an elastic network interface
(ENI) that resides in the AWS VPC construct.
If we dive deeper into this idea, we’ll see that each of the ESXi hosts have an ENI living within
AWS, but not all those ENIs are active. Only the host that is physically housing the edge
gateway will have an active connection to AWS.
If the host housing the edge gateway fails, or the gateway is moved to
another host, then that host becomes the new active ENI. An automation
routine provided by VMware when you set up your VMC cluster will
automatically update the AWS default route table so that resources in your
VPC will know where to route traffic destined for the VMC networks hidden
behind the edge gateway. This automation makes things seamless to
workloads that are in the VMC connected VPC.
What you should pay close attention to is what happens to any other AWS
VPCs that might also need to access those resources.
Here the edge gateway moved, routes in the attached VPC were updated, but we have a
second VPC that’s peered and might need access to those workloads as well.
For other AWS VPCs, you’ll need to come up with your own solution
to make sure that they always know the proper routes to the VMC
environment. Luckily, we have a few options.
Option 1: Add your own automation.

The first way this could be accomplished is to trigger some of your custom
scripts to change the routing tables. You could use native services like
Amazon CloudWatch Events to listen for a route change that would trigger
your own serverless (AWS Lambda) function to run and update the default
route tables across all your VPCs so that they know about the active ENI.
Option 2: Setup VPNs
The second option would be to use the VPN endpoint capability of the
VMware Edge gateway. To do this, we’d simply set up a VPN tunnel from
each of our AWS VPCs to the VMC edge gateway to handle the routing
automatically. In this scenario, we don’t have to automate any route
changes if the active ENI changes because we tunneled directly to VMC
instead of going through an ENI. The criticism of this method is having to
pay for multiple VPN tunnels for each of the VPCs, but this does make the
environment easier to operate.
Option 3: VPN Tunnels with Hub/Spoke
Topology
The last option we’ll cover is a modified version of option 2. Here we’ll
still setup VPN tunnels, but we’ll go through an intermediary like an AWS
Transit Gateway. In this scenario, you would set up a Transit Gateway or a
homemade transit router to act as a hub for all network connections. VMC
and each of your AWS VPCs would have a connection to this transit device,
through a VPN or Transit Gateway attachment, and the transit router would
make the routing decisions for the environment.
The cons of this solution are that you’re making an extra hop to get to and
from the VMC and you get billed for VPC egress charges. However, this
option gives you a mechanism to not only connect to VMC but also allows all
your VPCs to use this hub/spoke topology to communicate with one another
as well. Without this topology, you’d be looking at a full mesh that would
include many more VPN tunnels or peering connections between your VPCs.
VMC Connectivity with On-Premises
Data Centers
Let’s tackle the simple options for connecting your VMC with your
on-premises environment first.
Option 1: VPN Tunnels

The simplest way to get your connections working with your on-premises
environment is to set up a VPN connection between your on-premises
VPN endpoint and the VMC Edge gateway. You can set up an IPSEC VPN
Tunnel between your on-prem router and the VMC Edge gateway, as well
as connect any optional AWS VPCs. This is a simple solution and probably
what you’d do if you needed to connect to any type of external environment,
like a new data center, that ran workloads.
Option 2: Direct Connect
Sometimes a VPN tunnel just isn’t going to cut it. Whether it’s a lack of
consistent latency metrics or data transfer costs being too high, you’ll
sometimes need a more robust solution, and that’s where an AWS Direct
Connect comes into play.
Direct Connect circuits are typically the preferred method of setting up a
connection with AWS because it provides a consistent level of latency and
lowers costs per transferred GiB. Luckily, VMC allows us to use this direct
connect circuit to connect directly to VMC from on-premises if we have a
circuit provisioned already. The topology would be very similar to the VPN
connection example we saw before, but the transport mechanism is a
physical circuit and not a VPN.
There are plenty of ways that you can connect your VMware Cloud on AWS
environment with the rest of your corporate resources. The trick is to find
the topology and medium that provide your organization with the proper
cost structure and performance characteristics that meet your use cases.
Take some time to sort out these options out before deploying your SDDC,
and you’ll thank yourself for it later.
AHEAD can help you get the
most from VMC on AWS.
AHEAD’s unique expertise and solutions –
coupled with our deep knowledge of VMware,
AWS, and the integration of the two – mean
we’re perfectly positioned to get you started
on your journey to the cloud.
AHEAD’s VMware on AWS framework focuses

on an end-to-end enterprise solution
encompassing integration to on-premises
and native AWS, allowing for application
interdependencies connectivity and access
to cloud-native services. AHEAD’s VMware on
AWS certified experts (certified in both AWS
and VMware) collaborate with our clients
to build an enterprise-grade operational
environment focused using automation.
About AHEAD
AHEAD builds platforms for digital business. By stitching together
advances in Cloud, Automation, Operations, Security, and DevOps, we
help clients deliver on the promise of digital transformation.
Headquartered in Chicago, AHEAD maintains offices in Michigan,
Minnesota, North Carolina, Ohio, and Wisconsin. Learn more at www.
ThinkAhead.com and follow on Twitter @ThinkAheadIT.
Appendix
Explore this poster from VMware that offers further insight into many of
the topics discussed in this eBook and how they stitch together.
AHEAD
401 Michigan Ave.
#3400
Chicago, IL 60611
(312) 924-4492
www.thinkahead.com
In partnership with

AHEAD VMC On AWS Guide

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

AHEAD VMC On AWS Guide

Caricato da

Copyright:

Formati disponibili

VMware Cloud on AWS

A Guide to Successful Adoption of VMC

Chapter 1: Use Cases .............................................................................................................. 6

Chapter Three: Add-On Capabilities, Site Recovery Manager (SRM) .......... 17

Chapter Four: Add-on Capabilities, Hybrid Cloud Extension (HCX) ..................... 21

Chapter Five: Interoperability With AWS .................................................................... 29

Chapter Six: Firewalls ......................................................................................................... 33

Chapter Seven: VMC Connectivity .............................................................................. 39

The effort is worth it though. The ability to

In this eBook, we will offer a complete view of

Some of the advantages of VMC on AWS include:

■■ Simplified operations: Manage both on- and off-premises data

■■ Reduced operational cost: Organizations with a restricted

■■ Accelerated migration: Gain a simplified and streamlined

■■ Increased innovation: Move workloads closer to native cloud

Use Case #1: Disaster Recovery as a Service

Use Case #3: Data Center Exit

Use Case #5: Data Locality

Use Case #6: Licensing

Step 1: Configuration Steps

4. Enter the administrator@vmc.local user and credentials and click “LOG

■■ Select the “Direct Connect Network” Network Type

■■ Enter the private IP address ranges reserved for HCX.

■■ Enter the Prefix Length and the Gateway IP address.

8. Click Next and then click Finish.

vCenter Connection vCenter Connection

Protected Site VMs Failover Recovery Site VMs

Protected Site Recovery Site

Protected Site VMs Failover Recovery Site VMs

Protected Site Recovery Site

Protected Site vCenter Recovery Site vCenter

vCenter Connection vCenter Connection

Protected Site VMs Failover Recovery Site VMs

Protected Site Recovery Site

Large Scale Migration

Cross Version Hybridity Security

■■ Migrations can be set up to run on a pre-defined schedule.

■■ Virtual machine state is migrated, with no service interruption during

HCX Cold Migration

HCX Replication Assisted vMotion

■■ During the RAV switchover phase, vMotion is engaged for migrating

■■ This is currently in preview for VMware Cloud on AWS customers and

■■ Can extend VLAN and VXLANs networks (extending VXLAN requires

■■ Extend Cisco Nexus 1000v networks

HCX automatically deploys the Remote Site appliance whenever a local

Local Site HCX Target

Virtual Machine Network B Virtual Machine Network B Native

Local HCX Remote HCX

Or Private Circuit WAN Boundary:

HCX Disaster Recovery

■■ Self-service RPO settings from 5 minutes to 24 hours per virtual

■■ Reverse failover of workflows to the source site

■■ Multiple points in time recovery snapshots that allow recovery for up

■■ Optimized replication throughput by use of WAN Optimizer

■■ Ability to route replication traffic across a direct connect network

■■ On-premises monitoring and management with the vSphere Web

HCX Enterprise HCX Cloud

HCX Enterprise NSX Hybrid

Legacy DC SDDC with

HCX WAN Interconnect

HCX WAN Optimization

HCX Network Extension