So we reach the end of the VMware Cloud on AWS for the vSphere Admin introductory series. I’ve answered some of your questions as to how you get yourself up and running with VMware Cloud on AWS. In this post, I’ll be summarising what we’ve talked about in the last 5 posts. Feel inspired and want to give it a whirl? There are some links at the bottom which take you to a Hands On Lab or alternatively get started with a single node cluster.
I discussed what VMware Cloud on AWS is in this post. We looked through some of the use cases, such as Cloud Migrations, Next-Gen Apps, and Disaster Recovery. I then focussed in on the critical use case for this blog series, that being Datacenter Extension.
There are many reasons that you may need to extend your existing datacenter. You may have seasonal spiked. If so, you might not want to take the hit from your CapEx budget to satisfy these short term peaks. Next, there’s the possibility that you’re hitting capacity limits in your existing datacenter. These tend to be tricky situations to negotiate. The third important point is data sovereignty. Customers with legislative or policy reasons to hold their data within their on-premises datacenters are unable to leverage cloud services. VMware Cloud on AWS can help! Hold your databases on-premises but connect to the application and web tiers published in the cloud.
The critical thing to take away at this point is consistency. You can manage all of your workloads whether on-premises or in the cloud using the same tools. These might be the vSphere Client, PowerCLI, or some tools that you’ve built in-house to leverage the APIs available.
Our second post covered the initial steps required to deploy your first cloud SDDC. We set up the AWS Customer VPC, which is required to communicate with native AWS services like S3, EC2, and RDS. With this completed, we showed how simple it is to get started with VMware Cloud on AWS by deploying the SDDC. We configured connectivity between the cloud SDDC and the Customer VPC. We finally showed how AWS Cloudformation does the heavy lifting of deploying the bare metal ESXi hosts and bootstrapping everything on top of those to give you the VMware Cloud Foundation deployment.
We looked into the connectivity requirements in post three. To set up the hybrid environment, we need to establish a network link between the on-premises management network and the Cloud Management Gateway. If we want to enable live migrations using vMotion, this needs to be done using an AWS Direct Connect (DX) connection. Alternatively, an IPsec VPN could provide this if cold migrations meet your needs. We looked at setting up network segments for compute workloads, and then extending some on-premises networks into the cloud SDDC. We took that last step to be able to move workloads without needing to change IP addresses.
In the fourth post, we primarily talked about Hybrid Linked Mode and how to set it up. Hybrid Linked Mode enables a few things: firstly (like with traditional Embedded or Enhanced Linked Mode) It gives the single management pane for vSphere. It’s more convenient to manage both your on-premises and your cloud environments from a single interface. Secondly, it allows you to log in to your cloud SDDC using an on-premises identity provider (such as an AD domain account). We also discussed the Content Library, which can help to replicate the same templates and installation media that you use on-premises up into your cloud SDDC. Finally, in this post, we looked briefly at Accounts, Roles, and Privileges and also Log Intelligence.
Post five focussed on Policy-Based Management, and the reasons why moving to a policy-based management approach makes sense in this modern world. We discussed storage policies (which may have been familiar to you already if you were using vSAN). We also talked about compute policies, which I see as the next evolution of DRS policies. Finally, we discussed Elastic DRS and how this can be used to automatically grow or shrink your environment. You can configure policies to meet your performance or cost needs.
Our sixth post focussed on Security Policies. While this could potentially have fit into the previous post on policy-based management, I felt that this was worth a specific focus. Security is super important to every business, and the microsegmentation capabilities that we get from NSX-T enable us to wrap each workload in a secure bubble. Ultimately, security policies allow you to specify the dynamic source and destination objects and build the firewall rules that you need to run each workload securely. You don’t need to be an NSX ninja to understand how to build these policies! They’re not too dissimilar to the way you built traditional firewall policies, but so much more versatile!
My key takeaways from this series?
VMware Cloud on AWS is super easy to manage from the vSphere Administrator’s perspective. You’re not refactoring apps or anything like that. Plus, with Hybrid Linked Mode, you can use your existing credentials and the familiar vSphere Client.
Take advantage of the cloud consumption model and either pay as you go or commit to 3 or 5-year subscriptions for some serious savings.
VMware Cloud on AWS can be a great get out of jail card for when you need to extend beyond your currently available capacity.
Policy-based management can make your life significantly easier. When your workloads are dynamic, build your policies around tags rather than static objects like IP addresses or VM names. Tags are awesome!
