- Newest
- Most votes
- Most comments
While AWS documentation lists Fault Tolerance (FT) as a feature, there is a significant support conflict with the underlying architecture:
- NSX-T Restriction: Per Broadcom’s official support matrix (KB 317806), vSphere FT is explicitly unsupported on any VM utilizing NSX-T created portgroups (both Overlay and VLAN segments).
"Fault Tolerance is currently unsupported to be enabled on any VM utilizing an NSX-T created portgroup (vlan or overlay segment)." -> "Broadcom Support KB 317806"
- AWS EVS Architecture: Since Amazon EVS relies entirely on NSX for workload networking to integrate with the AWS VPC, all VM portgroups are managed by NSX.
AWS EVS Architecture Constraint:
Unlike on-premises deployments where you can choose between standard vSwitches and NSX, Amazon EVS is a managed service where the networking stack is strictly NSX-managed. Every segment (Overlay or VLAN) created in the EVS console or vCenter is an NSX object. Since there is no "non-NSX" workload network available in EVS, you cannot bypass the NSX-T restriction mentioned in KB 317806.
- The Conflict: Technically, you might be able to enable FT in the vCenter UI, but you would be in an unsupported configuration according to Broadcom.
I would do not rely on FT for production workloads in EVS without an explicit, written support exception from both AWS and Broadcom. In a cloud context, leveraging vSphere HA combined with vSAN Storage Policies (FTT=1 or 2) is the standard and fully supported architecture for high availability.
Does that answer your point?
You've identified an important technical consideration. Amazon EVS does support vSphere Fault Tolerance (FT) as a VMware Cloud Foundation resiliency feature, providing continuous availability for mission-critical VMs by creating and maintaining an identical VM that can immediately replace the primary in a failover situation.
However, you're correct that Amazon EVS uses NSX for its networking architecture. The standard deployment includes NSX Manager creating and managing software-defined overlay networks using GENEVE encapsulation for virtual machine connectivity. The NSX Edge appliances bridge these overlay networks with the underlying Amazon VPC subnets.
Given the constraint you've mentioned from Broadcom regarding FT compatibility with NSX-T created portgroups, this does present a potential limitation. For your specific use case where you rely heavily on vSphere FT for critical VMs, I would strongly recommend:
- Engaging directly with AWS support or your AWS account team to clarify the exact networking configurations that support FT in Amazon EVS
- Requesting a technical deep-dive or proof-of-concept to validate FT functionality for your critical workloads before migration
- Exploring alternative resiliency options that Amazon EVS does support, such as vSphere HA for automatic VM failover, or vSAN Failure to Tolerate settings to define redundancy levels
This is a critical architectural question that deserves detailed technical validation before proceeding with your migration planning.
Sources
Resilience in Amazon EVS - Amazon Elastic VMware Service
Multi NSX Edge clusters in Amazon Elastic VMware Service | AWS re:Post
A million thanks for your prompt answer but basically this means the official AWS documentation is providing a wrong support information...
Relevant content
- asked 8 months ago
- asked a year ago
- asked 6 years ago
- AWS OFFICIALUpdated 2 years ago

The Problem here is not AWS, it‘s Broadcom!