Familiarize yourself with these basic Amazon Web Services concepts, including VPC and how AWS handles resources,...
before you attempt to run VMware on AWS.
Now that VMware Cloud on AWS is available, vSphere administrators should familiarize themselves with how Amazon Web Services functions in order to run VMware on AWS.
VMware Cloud on AWS is an on-demand service that enables the VMware software-defined data center (SDDC) stack to run directly on the AWS Cloud. VMware supplies vSphere, vSAN, NSX and vCenter management, as well as support, while Amazon supplies the elastic-bare metal infrastructure and additional components. When configured appropriately, VMware tools such as vRealize Automation can consume standard resources from AWS.
This setup is transparent to the VMware Cloud on AWS administrator; VMware deploys its SDDC into a "shadow" Virtual Private Cloud (VPC) that the customer doesn't see. To the vSphere administrator, the VMware management system appears the same way as it does in the data center.
Even though VMware abstracts much of the complexity associated with AWS, it's still in a vSphere admin's best interest to get familiar with some AWS basics.
AWS VPC architecture for beginners
In order to run VMware on AWS, AWS uses its VPC to provision a logically isolated section of the AWS Cloud where you can launch AWS components.
A VPC is a software-defined network that holds all of AWS' network-related functions. The AWS administrator sets up and controls access to everything in the AWS VPC architecture, though he can use AWS' Identity Access and Management (IAM) service to delegate this responsibility to other administrators. It's a best practice to create subordinate IAM user accounts to handle daily work in the VPC rather than use the primary admin account.
Each VPC lives in a region, which is a cluster of highly redundant data centers that function as a single logical group. In order to use a VPC, the AWS admin must first select a region and then define the VPC. VPCs can't extend across regions, but one of the benefits of AWS VPC architecture is that you can have multiple VPCs within a single region. Using multiple VPCs makes management easier because it can logically isolate infrastructure. This enables multiple customers to live within a single account while retaining privacy and isolation.
AWS chain of command
Each AWS customer has a root user account, which is managed at the AWS account level. The root user account has access to identity and access management and can spin up new resources as needed, create subordinate user accounts and defer responsibilities to these subordinate accounts. By default, subordinate accounts have no rights within the infrastructure until an AWS admin assigns rights to them.
If you log into the root account, you'll see that there are several sizes and types of VMs -- which AWS refers to as instances -- that you can consume. Elastic Block Storage underlies these VMs.
Note that AWS resources do not provide the option to define VM sizes; instead, AWS uses instance sizing, which means the admin can only use the sizes Amazon provides. If server utilization becomes too large for its sizing, the admin can scale it up to a higher level of CPU, RAM and so on. Scaling up is a quick fix but requires downtime and is limited to the resources AWS provides.
AWS provides several images from which the admin can deploy resources. It's also possible to create highly customized images, which can be useful in a larger deployment. A new AWS setup also requires the admin to choose a region in which to place his resources. It's important to choose the right region because different regions have different cost implications.
In summary, in order to run VMware on AWS, the vSphere admin has two ways to use AWS and consume AWS resources directly: vRealize and VMC on AWS. With VMC on AWS, the vSphere admin can simply access the VMC on AWS console, create an SDDC, and get a vCenter login and go about creating VMs, business as usual.