Category Archives: VMConAWS

VMware Cloud on AWS – TMCHAM – Part 16 – Remove External Datastores

Posted on by

In this edition of Things My Customers Have Asked Me (TMCHAM), I’m going to do a (really) short post on removing external datastores on the VMware-managed VMware Cloud on AWS platform. It might seem like a simple thing, but it can be confusing for customers who haven’t done it before.

 

The Problem

If you’ve used an external datastore (either FSx for NetApp ONTAP or the artist formerly known as VMware Cloud Flex Storage) with your SDDC, you’ll know that management of the connection of the datastores to your SDDC is done via the Cloud Console, and not via vCenter. There might come a time when you want to remove that storage, either because you’ve bought more nodes and want to use vSAN, or you’re possibly shrinking your footprint. Whatever the reason, if you do try to remove the datastore via vCenter (assuming you’ve removed your workloads from the datastore), you’ll get an error about insufficient privileges. At first it might seem like it’s because you have VMs still present on the datastore (and if this is the case, contact Global Support to help you if you can’t find them). It’s more likely, however, that you’re not in the right place to do this activity.

 

The Solution

The solution is simple. In the VMware Cloud Console, go to the Storage tab of the SDDC you want to remove the datastore from, and click on Detach Datastore. And that’s it. It won’t work if you’ve got workloads running there, so make sure you’ve cleaned everything up / moved it somewhere else before you attempt this one.

VMware Cloud on AWS – What’s New – April 2026

Posted on by

What’s New?

A new node type is now available for deployment with VMware Cloud on AWS. The i7i.metal-24xl instance type is now generally available for both new and existing SDDCs and cluster deployments on SDDC version 1.26v2. Exciting? Confusing? Let’s dive in.

Specifications

The key specifications of the i7i.metal-24xl are as follows:

Specification i7i.metal-24xl
Processor 5th Gen Intel Xeon (Emerald Rapids)
Hyperthreaded Cores 96
Physical Cores 48
Memory 768 GiB DDR5 (5600 MT/s)
Local NVMe Storage 6 x 3.75 NVMe SSDs
Usable Capacity* vSAN OSA ~ 13 TB*
vSAN ESA ~ 20 TB*
Network Bandwidth 56.25 Gbps

*Note that the capacity of individual nodes will be dependent upon RAID configurations, FTT settings, and factors such as compression. You can check out the VMC Sizer to work out how much capacity a particular cluster configuration will give you.

Where Can I Deploy It?

The i7i.metal-24xl instance type is available today for purchase and deployment in the following AWS Regions:

Geography AWS Regions
Americas US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Central)
Europe Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Stockholm), Europe (Milan)
Middle East Middle East (Bahrain)
Asia Pacific Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Melbourne), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka), Asia Pacific (Mumbai), Asia Pacific (Hyderabad)

Deployment Considerations and Constraints

The i7i.metal-24xl can be deployed in a new SDDC, or deployed as a secondary cluster in an existing SDDC. Note that the i7i instance type is only available for SDDCs running on version 1.26v2. In-place cluster conversions are also supported, with support for converting i3, i4i, and i3en hosts to i7i.metal-24xl. Note that clusters running virtual machines on Virtual Machine Hardware version 21 are not eligible for conversion from i4i to i7i, due to hardware compatibility limitations. Also, if you are converting stretched clusters, these will be converted as OSA stretched clusters, as there is no current support for ESA stretched clusters in VMware Cloud on AWS, nor is there support for converting OSA to ESA in-place.

To better understand your sizing requirements, you can contact your account team to provide a conversion estimate. You can also run the VMC Sizer on your own SDDCs to provide an estimate.

 

Thoughts

The announcement was published on April 1st, but this is no joke. This instance type is a welcome addition to the VMware Cloud on AWS catalogue. Customers looking for a cost-effective replacement for their i3.metal hosts, or a smaller Pilot Light footprint for use with VMware Live Cyber Recovery will be happy, as will customers with processing requirements that want to take advantage of a modern CPU like the Emerald Rapids. The good news is that nothing else changes – your VMware Cloud on AWS service continues as before, managed by Broadcom, and evolving in line with your requirements. You can read the announcement blog post here, and the release notes are here.

VMware Cloud on AWS – What’s New – January 2026

Posted on by

I posted last month about what’s new in VMware Cloud on AWS, particularly as it related to the host usage API and changes to the VMC Sizer tool. It’s a new calendar year, but the team hasn’t stopped, delivering some new updates via a soon to be rolled out VMware Cloud on AWS software bundle. More detail can be found in the VMware Cloud on AWS Release Notes located here, and there’s a great blog post from the team here.

 

What’s New?

The default version for all new SDDC deployments is now 1.26, and it will be rolled out across the fleet in the next little while. A key component of this release is vSphere 8.0 Update 3. This a long-term support release of vSphere, and delivers improved performance and reliability. Notable, also, is the NSX version – in this update it goes to 4.2.3.1. I’ve linked to it before, but check out the timeless classic “Correlating VMware Cloud on AWS SDDC Versions With Their vSphere Components” for more information. So, an update is great, but what do you really get? Let’s dig in.

Support for vSAN Express Storage Architecture

This is the big one – support for vSAN Express Storage Architecture (ESA) is now generally available for VMware Cloud on AWS. Note that “vSAN ESA is supported only for i4i.metal host types on newly deployed single availability zone SDDCs and for new secondary i4i.metal clusters on existing SDDCs that have been upgraded to 1.26”. So, no brownfield support, but there’s still scope to do some pretty cool stuff.

New vSAN ESA features include:

  • Native snapshots for faster backups;
  • A storage pool architecture that reduces fault domains and improves data availability; and
  • For smaller customers, supports for a RAID-5 storage policy starting from 3 hosts gives customers more storage capacity on smaller clusters.

Bring Your Own Keys (BYOK): VMC Now Includes VM Encryption

VMware Cloud on AWS now supports customer-managed VM Encryption through an external KMIP-compliant Key Management Systems (KMS). What does that mean? You can now use your own keys for workload VM encryption – while the VMC control plane continues to use the AWS KMS (managed by Broadcom) for vSAN encryption.

VM Hardware Version 21

VM Hardware Version 21 is pretty cool, offering support for:

  • 256 Disks per VM – Massive storage capacity through 64 disks across 4 vNVMe adapters;
  • NVMe 1.3 – Enhanced performance for Windows 11 and Windows Server 2022 deployments.
  • NVMe for Windows Server Failover Clustering (WSFC) – High-performance shared storage for mission-critical clustered applications.
  • Latest Guest OS Support – Compatibility with RHEL 10, Oracle Linux 10, Debian 13, and FreeBSD 15.

The blog post has an excellent comparison of Version 20 and Version 21.

VMware Tools 12.5.4

VMware Tools 12.5.4 offers improved driver compatibility, enhanced VM performance, and provides better integration with the underlying VMC infrastructure.

 

Thoughts

Software updates aren’t always headlining news, but support for ESA on VMC (finally) is news that’s sure to make quite a few customers happy. I’ve no doubt they’re sick of hearing how cool it is from their on-premises counterparts and are keen to be part of the action. The updates to VMware Tools and VM Hardware version support are also minor, but important updates to the platform.

VMware Cloud on AWS – TMCHAM – Part 15 – Hosts and Subscriptions

Posted on by

In this edition of Things My Customers Have Asked Me (TMCHAM), I’m going to do a short post on hosts and subscriptions on the VMware-managed VMware Cloud on AWS platform. It might seem like a simple thing, but it can be confusing for customers who are new to the service.

 

Definitions

Subscriptions

A subscription entitles you to run a host (or hosts) of a particular type (I3en.metal or I4i.metal) in a particular Region. The SKU of the subscription you purchase determines what you can run. For example, if you’d like to run I4i.metal hosts in the Sydney Region, you would need to purchase the VMC-AWS-I4-APE product. One of these entitles you to one host, and so on. The minimum term is 12 months, and these can be co-termed for longer periods to coincide with other product subscriptions. It’s important to understand that particular hosts aren’t tied to particular subscriptions. The subscription is at an Organization level, and its availability is based on a Region and Host type. So if you had 12 I4i subscriptions, and 6 I4i hosts deployed in the Sydney Region, and six in the Singapore Region, you’d be good to go. What you couldn’t do is use those I4i subscriptions to cover your deployment of I3en hosts in Ireland, for example. For that you’d need the VMC-AWS-I3EN-CCR SKU.

Note also, and this is pretty important, “[I]f you have hosts in excess of your purchased subscriptions, whether through EDRS storage scale-outs or due to expired subscriptions, your access to the VMware Cloud on AWS service and your SDDCs may be paused until the overconsumption is resolved. After 48 hours of excess usage, you will lose access to your SDDC(s) and workloads until you purchase sufficient subscriptions, and soon after that, your SDDC(s) will be irrevocably deleted”.

What’s In The Box?

So what do you get with VMware Cloud on AWS subscriptions? You get access to the following components on a per host basis:

  • A Software-Defined Data Centre (SDDC), consisting of:
    • AWS EC2 bare metal servers (I3en or I4i)
    • VMware vSphere
    • VMware vCenter Server
    • VMware NSX
    • VMware vDefend Gateway and Distributed Firewall (formerly NSX) – note that vDefend Advanced Threat Protection is sold separately.
    • VMware vSAN
    • VMware HCX
  • Self-service provisioning of SDDCs from the VMware Cloud Console at vmc.broadcom.com.
  • Maintenance, patching, and upgrades of the SDDC, performed by VMware by Broadcom

Note that License Portability is not supported with VMware Cloud on AWS.

 

Thoughts

The key thing to remember with subscriptions is that you need to buy subscriptions that match the host type and Region you’ll be deploying into. And you’ll need at least two to get started.

VMware Cloud on AWS – What’s New – December 2025

Posted on by

I posted last month about what’s new in VMware Cloud on AWS, particularly as it related to stretched cluster and HCX enhancements. The team has been working hard on some more new features, and I thought I’d cover them off briefly here. More detail can be found in the VMware Cloud on AWS Release Notes are here, and there’s a great blog post from the team here.

 

What’s New?

New Host Usage Report API

Have you been wondering what’s going on with resources in your VMC on AWS environment? Wonder no more. All the cool cloud kids are using APIs, and VMC on AWS is no different. Now you can retrieve daily host usage reports for any date range and filter by region, instance type, SKU, and other attributes – all via the API. There’s no need to call me and ask for a report on what’s happening, nor do you need to log a ticket to get access to the information. Here’s what a sample query looks like.

curl -H 'Authorization: <value>' https://{api_host}/api/activityanalytic/{org_id}/hosts/{freq}/usage-report?start_date=value&end_date=v

Check out the documentation here.

Redesigned VMware Cloud on AWS UI

The VMware Cloud on AWS UI has also had a facelift, and the interface is more streamlined and easier to navigate. You can access it at https://vmc.broadcom.com.

VMC Sizer & Cluster Conversion Updates

Ever since I started working with VMware Cloud on AWS, I’ve been a huge fan of the VMC Sizer tool. It’s so much better than trying to build solution estimates with a spreadsheet and a dream. If you’re an existing I3.metal customer, you’ve likely (hopefully) been planning a migration to I3en.metal or I4i.metal nodes. The conversion estimates can be a bit of a mystery, and have frequently required involving people like me and folks from the SRE team to provide these estimates. The product team has been working to make the process more streamlined, while giving customers improved visibility into why the numbers are the way they are. The output from sizing estimates now provides clear reasoning behind why a specific number of hosts is required, and this is based on 6 elements (compute, memory, storage utilisation (with both conservative and aggressive options), vSAN storage policies, and NSX Edges). It’s never been a simple matter of saying two I3.metal hosts equals one I4i.metal host, and now the sizer output reflects this more clearly.

The following constraints should be noted:

  • Final host counts and sizing will be validated during the actual cluster conversion. Sometimes you end up with more, sometimes you end up with fewer hosts.
  • Customers should re-run sizing evaluations after any significant configuration, resource, or other changes. Please don’t add another 30TiB workload to your cluster and expect the same result.
  • No RAID policy changes are made during conversion. This is especially notable if you’re using custom storage policies in your environment.
  • Subscription estimates provided as part of this workflow are for planning purposes only and do not represent guaranteed final requirements.
  • Actual subscription needs may be higher than estimated, requiring additional subscription purchase post-conversion. You’re given a small window to make good on this.
  • Refunds or subscription reductions will not be provided if estimates exceed actual needs.

 

Thoughts

As I mentioned in my previous post, VMware Cloud on AWS is not going anywhere, and the product and engineering teams continue to innovate and work hard to ensure that users get the best value from their investment in the VMware Cloud on AWS solution. The Host Usage Report is extremely useful, and for those customers concerned about cluster conversions, the improvements to the VMC Sizer should improve the confidence in the sizing process.

VMware Cloud on AWS – What’s New – November 2025

Posted on by

I posted a little while ago about what’s new in VMware Cloud on AWS, particularly as it related to stretched cluster enhancements. The team has been working hard on a few new features, and I thought I’d cover them off briefly here. More detail can be found in the VMware Cloud on AWS Release Notes are here.

 

What’s New?

Improved Stretched Cluster Scale Down Support

When working with stretched clusters in VMC previously, there was a rule that, once a stretched cluster grew to 6 hosts, they couldn’t be reduced back down below that number. As requirements change over time, and customers look at alternative solutions and deployment topologies, this has become something of a blocker in terms of flexible deployment options. To combat this challenge, customers can now scale down from 6 or more hosts to 4 hosts (2 hosts per Availability Zone) or 2 hosts (1 host per Availability Zone). Why would you need to do this? You might have had a stretched cluster with I3.metal nodes deployed in it and you’ve recently converted that cluster to I4i.metal nodes. You very likely won’t need as many I4i nodes as you did I3s, so this gives you the option to reduce the cluster to an appropriate size. There are, of course, some constraints:

  • Firstly, if you’re using a “Large” (as opposed to Regular or Medium) management appliance deployment in your primary cluster, you can’t scale down below 6 hosts (3 per site).
  • Secondly, if you’re using custom CPU counts, and that count is 8, you can only scale down to 4 hosts (2 per site).
  • Finally, if you’re trying to scale down your cluster and that would leave the cluster with insufficient resources for your management and workload VMs, you won’t be able to do it. That is, you can’t make away resource constraints.

Note that if you are scaling down to 4 or 2 hosts, the Elastic DRS (EDRS) policy will be changed to “Storage Scale Up Only”. This ensures that EDRS won’t scale in your cluster leaving you with availability issues.

Have a stretched cluster and want to remove hosts? You can use this documentation to get it done. I’ve also covered the process here.

HCX version 4.11.3 Now Available for VMware Cloud on AWS

It is recommended that customers upgrade to HCX 4.11.3 as soon as possible to avoid support issues. It’s important to note that the “WAN optimization feature is no longer available. Before upgrading, users must deselect and remove all existing WAN-OPT appliance services from all Service Meshes and compute profiles. The upgrade will not proceed until the WAN-OPT appliance is removed from all Service Meshes as well as all compute profiles deployed in a given HCX connector / cloud system”. You can find out what’s new in HCX in the Release Notes.

 

Thoughts

Stretched clusters have been a great solution for VMC customers, but have, at times, denied customers the ability to make use of flexible deployment models. The addition of non-stretched clusters in stretched cluster SDDCs in September, and the ability to scale down below the current threshold of 6 hosts, should help customers make the most of their stretched clusters while still enjoying the ability to work with a more flexible topology. I’m also a big fan of HCX, particularly supported versions of HCX. VMware Cloud on AWS is still around, and still doing a great job of hosting VMware-based workloads on AWS infrastructure. The team continues to make enhancements to the product, and I’m looking forward to talking about what’s coming next month as well. If you have any questions, feel free to reach out and I can help, or point you to someone who can.

VMware Cloud on AWS – What’s New – September 2025

Posted on by

It’s been a little while since I’ve posted about what’s new in VMware Cloud on AWS. There have been plenty of enhancements made to the platform, along with a streamlining of capabilities. The more things change, so to speak. That said, I thought I’d put up a short post that covers off some of the key enhancements made available to customers via the SDDC 1.24v5 update that’s currently being rolled out across the fleet. And if you’re trying to work out what on Earth I mean when I refer to 1.24v5, etc., here’s a handy document that’ll help you match up VMware Cloud on AWS releases and the corresponding vSphere components. The VMware Cloud on AWS Release Notes are here.

 

What’s New?

Non-Stretched Secondary Cluster Support in Multi-Availability Zone Stretched Cluster SDDCs

It’s a bit of a mouthful, but let me dig in. I’ve posted about the utility of stretched clusters previously (and I’m thinking of writing about it again based on some conversations in the past month). Stretched clusters have historically been a cool way to ensure that your workloads are protected across multiple Availability Zones in the event that one or more components (or hosts or even the whole Availability Zone) go away. One of the constraints with VMC on AWS stretched clusters, however, has been that an SDDC with a stretched cluster could only ever contain stretched clusters – there was no opportunity to mix topologies within the SDDC construct. So, one organisation I know of has its production workloads running on a stretched cluster on one SDDC, and its non-production workloads running on another SDDC. While it’s not the end of the world, it makes things slightly more fiddly from a management perspective, and duplicates some of the work required when it comes to firewall configurations, user creation, workloads mobility, and so forth. The VMC team has recognised this, and has now announced that VMC on AWS will have support for secondary non-stretched clusters in the same SDDC as stretched clusters.

There are, of course, a few caveats to be mindful of. Firstly, you need to be on 1.24v5. Secondly, the primary cluster needs to be a stretched cluster – you can’t add stretched clusters to non-stretched SDDCs. Thirdly, you can’t convert stretched to non-stretched and vice versa. Once the clusters are configured the way they are, you’ll need to keep them that way. Fourthly, the non-stretched clusters can only be deployed in one of the Availability Zones in which you’ve deployed your stretch cluster. You couldn’t, for example, deploy a stretched cluster in AZ1 and AZ2, and deploy a non-stretched cluster in AZ3, while hoping to keep this all in the same SDDC. Finally, the minimum non-stretched cluster size is three hosts, not two.

Default and Maximum Virtual Machine Hardware Version Increased

From the release notes, “[t]he default virtual hardware version has been increased from Virtual Hardware 14 (vSphere 6.7 compatibility) to Virtual Hardware 19 (vSphere 7.0 U2 compatibility). The maximum virtual hardware version has been increased from Virtual Hardware 19 (vSphere 7.0 U2 compatibility) to Virtual Hardware 20 (vSphere 8.0 compatibility)”. This really helps with compatibility with newer Windows and Linux guest operating systems while still providing the (crucial) ability to move workloads between VMware hosts on various cloud and on-premises platforms.

Increased NFS Throughput

Of note with the 1.24 release, “the MTU on VMK0 has been increased to 8500”. It’s reported that this increases large block throughput by up to 20% for NFS Datastore workloads. This is becoming increasingly important as customers look to leverage NFS-based storage solutions like FSx for NetApp ONTAP for less latency-sensitive storage workloads that don’t need to be hosted on vSAN.

 

Thoughts

While I’m excited about the General Availability of Amazon Elastic VMware Service, that doesn’t mean that VMware Cloud on AWS is dead. The VMware Cloud on AWS product and engineering teams have continued to work on releasing innovative features and important, incremental improvements. The encouraging thing about this is that they are listening to customers, particularly around things like mixed cluster topologies, and continuing to adapt the solution architecture to satisfy those requirements. This is a good thing for both existing and potential customers. If you looked at VMware Cloud on AWS three years ago and ruled it out, I think it’s worth looking at again.

Amazon Web Services – Elastic VMware Service – A Few Notes …

Posted on by

Amazon Web Services (AWS) recently announced the general availability of its Elastic VMware Service (EVS). This is a brief post covering what the service is, how it can be consumed, and why it might be of interest.

 

What Is It?

EVS is a service that provides the ability to run VMware Cloud Foundation (5.2.1) on AWS bare-metal instances (specifically I4i.metal). It’s a by-the-book consolidated architecture (running management and workload domains together), and contains the following VCF management components:

  • ESXi hosts;
  • vCenter Server instance;
  • SDDC Manager;
  • vSAN datastore;
  • Three-node NSX Manager cluster;
  • vSphere cluster; and
  • NSX Edge cluster.

Storage is provided by vSAN (and selected third-party storage integrations), with two discrete network layers being delivered: the Amazon VPC and the VMware NSX overlay network. You can read more about the architecture here.

To consume the service, you’ll need 4 nodes to get started, along with at least 2 VPC Route Servers, and AWS Enterprise Support. There’s a pricing calculator on the AWS website. You’ll also need to procure VCF licensing from Broadcom or an authorised reseller.

 

Where Is It Available?

The initial launch Regions are:

  • US East (North Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • Asia Pacific (Tokyo)
  • Europe (Frankfurt)
  • Europe (Ireland)

Availability in more Regions is planned for the future.

Other Considerations

Storage

You can leverage NetApp’s FSx for NetApp ONTAP service to provide additional storage for the cluster. There’s some useful guidance here and here. If you like it more orange, Pure Storage’s Cloud Block Store is also available for use with EVS. You can read that announcement here.

Clusters

Cluster sizes are currently limited to between 4 (minimum) and 16 (maximum) nodes. There is currently no support for stretched clusters. This will likely change in the future.

Add-ons

Services that VMware Cloud on AWS users may be familiar with, such as vDefend Advanced Threat Protection, and VMware Live Cyber Recovery, are not currently available with EVS.

Planning and Deployment

Much like VMC on AWS (and most other cloud service deployments, for that matter), there’s a bit of planning you’ll need to do before you jump on the console. There’s a handy checklist that takes you through all of the requirements here. It’s also worth noting that, unlike VMC on aWS, this isn’t a managed service, so some of the VPC constructs you see with VMC on AWS aren’t used with EVS. For example, there’s no shadow VPC deployed for EVS – it’s all done out of the customer account. And features like EDRS aren’t available, you need to manage your capacity yourself, in much the same way as you would do with an on-premises VCF deployment.

 

Thoughts

EVS is the same as VMC on AWS in the sense that it’s running VMware software on top of AWS bare metal servers. There are plenty of differences though, some of which I’ve covered above. I imagine many of the constraints around additional product integrations and scalability will be removed in the near future as the product evolves, and we’ll no doubt see some changes when it comes to partners offering managed services wrapped in with EVS. It’s been a while coming, but now that it’s here, I’m interested to see how the market responds. There are probably plenty of questions I haven’t answered, but there’s a useful FAQ document here.

VMware Cloud on AWS – TMCHAM – Part 14 – Stretched Clusters and Disaster Recovery

Posted on by

In this edition of Things My Customers Have Asked Me (TMCHAM), I’m going to cover some of the things to consider when looking at Disaster Recovery (DR) and availability solutions on the VMware-managed VMware Cloud on AWS platform. It might seem like basic stuff if you’re already using the platform, but there are plenty of customers I talk to that are struggling to distinguish between DR, data availability, and periodic data protection in a VMware Cloud context.

 

Terminology

I’m cheating a little here and re-using some of my older content, but I think it still holds up.

  • Disaster Recovery – Disaster Recovery is the ability to recover applications after a major event (think flood, fire, data centre is now a hole in the ground). This normally involves a failover of workloads from one DC to another in an orchestrated fashion. In a VMware context, you would use VMware Live Recovery (Site or Cyber, depending on the environment).
  • Disaster Avoidance – Disaster avoidance “is an anticipatory strategy that is in place in order to prevent any such instance of data breach or losses. It is a defensive, proactive approach to keeping data safe” (I’m quoting this from a great blog post on the topic here). In a VMware context, this would be a stretched cluster using vSAN on VMware Cloud Foundation or in VMC on AWS.
  • Periodic Data Protection – This is the kind of data protection activity we normally associate with “backups”. It is usually a daily activity (or perhaps as frequent as hourly) and the data is normally used for ad-hoc data file recovery requests. Some people use their backup data as an archive. They’re bad people and shouldn’t be trusted. You should consider PDP as separate to DA or DR solutions.

 

So How Do I Best Protect My Workloads? (Part 1)

Understand Your Workloads

You need to understand how your applications work. And you need to understand what talks to them and what they talk to. There are plenty of ways of doing this, including a variety if applications available that scan network traffic and draw pretty pictures of data flows for you. From experience, there’s a very good chance you won’t get this information by reading current documentation, because it won’t be current.

You need to understand how important your applications are to you. Do you need to recover them immediately if something goes wrong? Can you do without them for a few hours? A few days? How much data can you afford to lose? All of it? (in which case why do you still have this data sitting around?). None of it? Some of it? You need to be disciplined and thorough in your assessment of your workloads and what they mean to your business, because protecting them or recovering them can be an expensive exercise.

Understand What Scares You Most

What do you call a disaster? Is it a data centre turning into a hole in the ground? Do you run most of your workloads in an area prone to natural disasters? Or are you more worried about people in hoodies breaking into your infrastructure and encrypting it and your data protection infrastructure? (Hot tip: you absolutely should be worried about this). You need to be fairly paranoid about the scenarios you’re trying to protect your environment from. No one thought it was a problem keeping workloads in two buildings in New York until it was. At the same time, you’ll need to introduce some pragmatism into your planning. I’ve had customers ask me what they could do if all of the Sydney Region was wiped out (not just the AWS deployment, but the whole city). Could they recover data to Melbourne? Sure. Would they have any staff left to do it? Or want to do it? Depending on the nature of the disaster, the technical aspects of disaster recovery are going to be the easy bits. You still need to make sure the people and process bit is covered.

Who Can Help You? 

Do you want to handle any recovery activities yourself when things go bang? Or are you happy to let someone else do the heavy lifting for you? Some folks don’t trust outsiders to do “important” things, like recover workloads, whilst other organisations would consume absolutely everything as a service if it was an option.

How Much Can You Spend?

You need to answer the questions above before you can answer how much you’re willing to spend on one (or more) solutions to help keep your workloads protected. If your apps aren’t that important, or your business can continue to run without access to these apps for a period of time, then you’re going to be less inclined to go for the “platinum” solution. But if you’re whole business relies on applications being available 24/7/365, then you’re hopefully more understanding that you’ll need to invest.

 

So How Do I Best Protect My Workloads? (Part 2)

Data Availability with VMware Cloud on AWS

As I mentioned earlier in this post, if you’re looking to provide data availability for your workloads on VMware Cloud on AWS, you should be looking at deploying a stretched cluster solution. In short, stretched clusters in VMware Cloud on AWS are designed to protect against an AWS availability zone (AZ) failure. There’s a feature brief available here that goes into more depth on the solution. Key things to note are that the vSAN stretched cluster is deployed across 3 AZs (2 workload, 1 witness). So you could have 3 hosts in one AZ, 3 in another, and VMware deploys a witness node in the third site as part of the deployment. From the document, “vSAN Fault Domains are configured to inform vSphere and vCenter which Hosts reside in which AZ. Each Fault Domain is named after the AZ it resides within to increase clarity. Logical networks are also extended using NSX to support workload mobility across the two AWS availability zones”. You also have the option to keep data using various vSAN storage policies, including:

  • Dual-site mirroring (stretched cluster)
  • None – Keep data on primary (stretched cluster)
  • None – Keep data on secondary (stretched cluster)

Why would you not just mirror everything? Cost. Some applications simply don’t need that level of resilience, but it’s too complicated to deploy multiple SDDCs to support multiple deployment topologies (you can’t have a mix of single AZ and stretched clusters in the same SDDC), so customers can keep a mix of workloads in the same deployment. Note also that external storage solutions (like FSx for NetApp ONTAP) aren’t supported for use with stretched clusters. vSphere HA will restart the VM on the surviving AZ if a site failure is detected. There’s a short video on YouTube that covers a stretched cluster deployment and is worth looking at.

Disaster Recovery with VMware Cloud on AWS

I’ve covered VMware Live Cyber Recovery (and its predecessor, VMware Cloud Disaster Recovery) on this blog before. It’s a great solution to protect on-premises, GCVE, and VMware Cloud on AWS workloads.  It provides protection to a secure cloud filesystem with a Recovery Point Objective as low as 15 minutes, the ability to perform guided ransomware recovery in an isolated environment, and SaaS-based recovery automation. The kind of things you want to consider when evaluating the suitability of VLCR to your needs would be:

  • Recovery Point Objective – the maximum amount of time in which data may have been permanently lost during an incident. VLCR goes down to 15 minutes, but if you need lower than that you need to look at other architectures.
  • Scalability – how many Virtual Machines and how much storage are you trying to protect? And how quickly do you want to recover it? And where do you want to recover it to? Some folks don’t like VMware Cloud on AWS being the only recovery option, but VMware has announced “plans to enhance VMware Live Recovery support for Google Cloud VMware Engine (GCVE) as a cyber and disaster recovery (DR) site, for both on-premises as well as GCVE environments“. You can check out the configuration maximums for VMware solutions here.
  • Networking and security – how will you access your recovery workloads? Will you use HCX to have stretched networks between your protected sites and your recovery site? What does that look like for your core networking infrastructure? Is your CISO happy to recover stuff onto a cloud platform? There are many things you’ll need to work through internally to ensure people are comfortable. I’d also recommend you go with a pilot light deployment as opposed to an on-demand solution. While the pilot light option seems more expensive, it will save you when something goes wrong and you’ve already tested your deployment.
  • Other Considerations – there’s a bunch of info in the legacy VCDR Release Notes that highlight some of the constraints to be aware of from an architectural standpoint, and understanding some of these (like the ability to protect stretched clusters, but not recover to stretched clusters) is key to ensuring your architecture will work when you push the button. And one point that is often missed by folks looking at VLCR for the first time is that, as the recovery SDDC is just a VMware Cloud on AWS deployment, you can use it for other workloads in the meantime, like dev/test stuff, when you’re not in a recovery situation.

Periodic Data Protection with VMware Cloud on AWS

There are a tonne of different things you can do here, and I’d be naive to suggest that I could cover them all effectively in this post. To use periodic data protection solutions with VMware Cloud on AWS, you should check out this KB article, and work with your data protection vendor to ensure that the solution has been tested and works on VMware Cloud on AWS. I’ve encountered a few situations where the vendor has assumed that VMware Cloud on AWS works the same way as VMware on-premises, and with the same ability to do silly things with privileged access to ESXi hosts and things of that nature. There aren’t a lot of restrictions in place, but there are some important ones, like the aforementioned limits on direct host access, restricted account privileges, and so on. Just make sure you test it before you buy it. I’ll try and cover some of the scenarios that do and don’t work in a future post (without naming too many names).

 

Conclusion

I’m sticking with solutions available with VMware Cloud on AWS in this post, mainly because that’s what I’m talking to people about on a daily basis. But there’s plenty here that can be applied more generically to a variety of infrastructure solutions. You’ll have the same questions you’ll need to ask when it comes to protecting workloads on-premises (regardless of your choice of hypervisor), and you’ll need to make some hard decisions ab out what you want to protect depending on the value of what your workloads deliver to the business, and the available budget. You might also need to consider doing a combination of all three options, depending on the importance of the data / workloads you’re looking after. I’d always pick stretched clusters to keep my workloads up and available, but that won’t help me if some hacker decides to dump ransomware in my environment and encrypt all of my stuff. But if I need to go back 24 months to retrieve some file for an auditor, I wouldn’t use VMware Live Cyber Recovery for that. I should also mention that you should be using application-level protection as your first option for application resilience too. This other stuff is all infrastructure level, and potentially not as elegant, depending on your applications. But that doesn’t mean you can’t combine both methods. Unfortunately, there’s no one magical fix for this problem, but with a bit of planning, and some critical evaluation, you can protect your workloads against all manner of bad situations. And if you can’t do everything, at least do something, but just make sure people in your business understand the difference between the two. And remember, you’re only as good as your last recovery.

Book Review – VMware Cloud on AWS Blueprint

Posted on by

Late last year I was approached by the folks at Packt Publishing to be a technical reviewer on a book about VMware Cloud on AWS. I was happy to be involved as VMC is something I’ve been working with quite a bit since I started at VMware. Fast forward to a few months ago and I received my reviewer copy (yes, an actual book, although you can also buy a PDF or access it via a subscription) of VMware Cloud on AWS Blueprint, written by Oleg Ulyanov, Michael Schwartzman, and Harsha Sanku. I thought I’d do a quick review of the book here, as I think it’s something worth diving into if you’re looking at running, or already run, VMware Cloud on AWS.

 

What’s In The Book?

The book weighs in at 388 pages, and is divided into 12 chapters, covering the foundational aspects of the VMware Cloud on AWS service, along with everything you need to know to standup the service, connect to it, run applications on it, and secure it. You’ll get the full view of what nodes go into the software-defined data centre (SDDC), what connectivity options you have available, and the best ways to put it all together. There are also chapters covering native AWS integrations, automation, as well as a chapter on the (now maybe only historically interesting) VMware Cloud on AWS Outposts offering. In short, it covers quite a lot of ground, and fills in a lot of detail that could otherwise be confusing for the first-time user of VMware Cloud on AWS. I’m the first to admit that I’m not the best when it comes to advanced networking and security concepts, being more of a disk slinger in the past than someone who focusses on things that go ping, so I found the chapter on understanding networking and security configurations to be truly helpful. Additionally, there was a great chapter on best practice advice, along with guidance on how to avoid common mistakes when deploying and using VMware Cloud on AWS.

 

Why Read It?

So why bother reading a book about a solution that you’ve probably already deployed? Because chances are there’s going to be some information in there that you haven’t come across, or hadn’t considered when you deployed your VMware Cloud on AWS solution. I’m a big believer in the documentation being able to get you so far, but it is books by specialists that can really open up a topic for you and allow you to see things from a different viewpoint. You might have just deployed your first SDDC, or you might have 20 of them running across multiple AWS Regions. I think you’ll still get some benefits from reading this book. Even if you’re not looking to leverage VMware Cloud on AWS, this book will give you some great insights into how a well-architected, mature, infrastructure-as-a-service offering looks, and provides some great perspectives on design considerations and things to look out for. The authors all have years of field experience, and know what they’re talking about. It was a real pleasure to be involved with this project, and I recommend you check it out.