Tag Archives: EVS

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.