First off, VMC on AWS is fantastic.
With pretty much “the swipe of your credit card,” you can get a login and start building your SDDC and be up and be running in a matter of hours.
It has some great use-cases that I think customers should really consider, especially if you have a cloud initiative, disaster recovery requirements or looking at building out new data centers. Here are some examples of those different use-cases:
- Datacenter Consolidation
- Datacenter Evacuation
- Datacenter Expansion
- Disaster Recovery (DRaaS with vSphere Replication and SRM)
- Cyclical/Burst Capacity
- Development and Testing
I do not want to go into crazy detail here since there are already a lot of guys in the community, who are much smarter than I am, who you should follow if you want to get in-depth knowledge of VMC on AWS. To name only a few:
What I do want to chat about it is how you get started and what do you need to think about from a requirement and architecture perspective during the initial setup.
Let’s start off with due diligence.
As mentioned there are a lot of good use cases for VMC on AWS but what do you need to consider to make the decision if this is the right solution for you. Here are a few things that I can think of, and please provide comments if you can think of any additional ones I can add.
- How large is your team and can they handle the management and maintenance of the hardware and software of an additional data center?
- VMC takes care of all of this
- If moving to a Cloud Provider, does your team have the necessary skills to manage the workload and consume the services?
- VMC requires no additional skill sets
- Do you require the use of AWS services in your environment?
- With VMC on AWS, you can deploy or migrate your VMs to the SDDC and consume the services without any egress costs. AWS service cost still applies.
- How much would it cost to run your current Virtual Machine workload in VMC on AWS or a different Cloud Provider?
- vRealize Business for Cloud provides you with cost comparisons between different Cloud Providers
- vRBC also provides a VMC Assessment which provides a comparative analysis of utilization based cost on Private cloud vs. VMware Cloud on AWS. Sweet!
- How do I take care of billing?
- SDDC consumption will be billed through VMware. Fixed monthly costs which are great because it can be a roll of the dice using a Service Provider.
- Your egress charges from SDDC Edge Gateways will be billed to VMware because the VPC is actually owned and managed by VMware as part of the service.
- Any AWS related services will be billed to your AWS account.
- If you make a decision on using a colo, then you have the following cost considerations:
- Rack or Floor space / Power consumption
- Compute
- Storage
- Licensing
- Networking
- ISP
- Dark Fiber
- Cabling
- If you make a decision on using your own physical datacenter, then you have these cost considerations:
- Compute
- Storage
- Licensing
- Networking
- ISP
- Dark Fiber
- Electricity
- HVAC/Cooling
- UPS Systems
- Cabling
- N+1 redundancy on physical infrastructure
- This list can go on and on and on…
Now, let’s say you performed your due diligence and make the smart decision to purchase VMC on AWS. What’s next?
To sign up, please contact your partner or VMware account team.
After you receive your login for console access, you can start the onboarding process, which has some requirements and upfront considerations.
- AWS requirements and decisions
- You require an existing account on Amazon Web services, and if you do not have one, you can connect to a new AWS account.
- The AWS account will be linked to your Cloud organization and as mentioned earlier and any AWS services consumed will be billed through this account.
- The default VPC assigned subnet might conflict with your internal networks and create a problem when the VPC is linked to your SDDC. Please review your existing subnet and if necessary create a new non-conflicting subnet.
- Make sure your subnet is in the same region as your planned SDDC
- Subnet should have at least 64 IP addresses (/26) in each AZ in your VPC.
- How many hosts do you need?
- This will depend on your use case and workload requirements.
- When you create the SDDC, you have the option to set your number of hosts, with a minimum of 4, which has a total capacity of 8 Sockets, 144 Cores, 2 TB RAM, 42.8 TB Storage.
- Also, think about future growth and the maximum amount of hosts that you might deploy.
- Cost considerations for your subscription
- Select the number of hosts you want as part of the subscription and for what period (on-demand, 1 year, 3 years). Longer-term reservation of hosts gives you up to 50% cost saving!
- Through the Hybrid Loyalty Program discount, you get an additional discount of up to 25% based on the number of eligible on-premises product licenses you own.
- You have to make a decision on the Management IP address schemes that you want to use within your SDDC.
- During the creation of your SDDC, you can configure the management subnet so make sure to pick a range that will not conflict with your existing on-premise networks as well as the AWS subnet that will connect to your SDDC.
- Depending on the maximum future amount of hosts that you might deploy, you have to select the appropriate range. 13 hosts = /23, 125 hosts = /20, 160 hosts = /16.
- Once the management network is created, it cannot be changed, and you would have to destroy your SDDC and start from scratch. Make an informed decision!
- In which AWS region should your SDDC run in.
- This will depend on your use case and current location.
- At the time of writing US East (N. Virginia), US West (Oregon) and London (England) is available.
- After the SDDC is created, you also have to make a decision on how you want to connect to your Management and Compute SDDC networks externally through the Edge Gateway. The following options are available.
- IPsec VPN (L3)
- This is available for both your management and compute network
- L2VPN
- This is only available for your compute network, and provides a secure communications tunnel between an on-premises network and one in your cloud SDDC.
- Direct Connect
- Service provided by AWS that allows you to create a high-speed, low latency connection between your on-premises data center and AWS services with no additional egress charges.
- Either select a colo at AWS Direct Connect locations or will need APN Partners to establish network circuits between the AWS Direct Connect location and on-premises environment.
- IPsec VPN (L3)
- What ports do you require to be open on your Management and Compute network Firewall?
- By default, your gateways are configured with a deny all policy.
The onboarding process is as follow:
- Setup VMware Cloud Organization
- Create an account by signing up
- Log in to your Cloud console
- Click on Invite users
- Add users and pick their Organization role.
- Set your theme, I like mine dark.
- If you are a member of more than one Organization, set your default.
- Create a subscription
- This allows you to save money by committing to buy a certain amount of capacity for a defined period of time.
- Choose wisely
- Create your SDDC
- Link your AWS account and choose your VPC and Subnet.
- Choose the appropriate AWS region
- Enter a name for your new SDDC
- Select the number of hosts
- Set a private subnet range for your management subnet
- This will be used for vCenter Server, NSX Manager, and ESXi hosts.
- Configure access to your Management cluster
- This is required for access to the vCenter Server server as well as ESXi vMotion VMKernel network, for when you want to migrate your VMs into your VMC SDDC.
- Configure the IPsec VPN
- You need to decide if you want to use your existing physical networking gear for connectivity, or if you have NSX implemented you can use an Edge GW, or you can install a standalone Edge GW for free.
- Routing
- Don’t forget routing, your networking team would need to route your on-prem management network to this new network.
- Firewall rules
- Decide on what ports need to be opened for network connectivity to vCenter Server, NSX, ESXi remote console, vMotion, etc
- DNS
- Set DNS IP addresses to resolve computer names.
- Configure access to your Compute cluster
- Configure your logical networks
- Need to decide what type of network you need, routed (default) or extended
- Decide on an IP range and size of the subnet.
- Routed network use the SDDC compute gateway as the default gateway, which means it has connectivity to other logical networks in the same SDDC, as well as to external networks like the Firewall and NAT.
- Extended networks use an on-premises gateway as the default gateway and require L2VPN connectivity to be configured.
- As a note, logical networks can be changed from routed to extended and extended to routed.
- Routing
- If you select a routed logical network, you need to decide which of your local compute networks you want to route for connectivity.
- Firewall rules
- Decide on what ports need to be opened for network connectivity to
- This will probably require a bit more brain power because it will include all your workload application and however you decide where your workload will run. Knowing your mapped application dependencies is crucial and vRNI, as well as the Service discovery management pack for vROPS can help in understanding how your applications talk to each other and provide the necessary firewall rules that need to be created.
- NAT
- Do you need to connect public IP addresses directly to deployed VMs?
- Public IP address
- You need to decide if you require public IP address for maybe web front-end applications running in your SDDC. If so you need to request them and beware there are costs involved.
- Configure your logical networks
Configure Hybrid linked mode
- Do you want to see both your onsite and VMC vCenter Server through a single pane of glass? This is a one-way connection so you always need to connect to your VMC on AWS vCenter Server to see both!
- Definitely worth it and provides that live Cross-vCenter vMotion awesomeness.
Services
- DRaaS
- If your use-case is to protect your on-prem workload and recover them in your SDDC, you can activate Site Recovery.
- The service consists of Site Recovery Manager (SRM) and vSphere Replication
- HCX
- This add-on SaaS offering provides large-scale migration between your on-premises environments running vSphere 5.0+ and VMC on AWS with no re-platforming, retesting, or change in tooling. Cool!
- It also provides high-performance Layer 2 extensions, data synchronization, traffic analysis, WAN optimizations, and built-in IPsec VPN connectivity that will enable secure and efficient cloud migration with no impact on application uptime.
Useful links: