21st November 2025  

Amazon Elastic VMware Service (Amazon EVS) reached General Availability (GA) on August 5, 2025, introducing a new approach to running and migrating VMware workloads on AWS. Amazon EVS enables the complete VMware Cloud Foundation (VCF) stack — including vSphere, vSAN, NSX, and SDDC Manager — to run directly inside a customer-owned Amazon VPC on EC2 bare-metal infrastructure. This architecture provides organizations with full administrative control of their VMware environment while leveraging the scale, security, operational resilience, and ecosystem integration of AWS.

At launch, the core value proposition of EVS was operational consistency: empowering enterprises to migrate VMware workloads to AWS without re-architecting applications, refactoring networking, or performing IP renumbering, and while continuing to use familiar VMware tools and processes such as vCenter, vMotion, and VMware HCX. This dramatically reduces migration risk and accelerates timelines for both lift-and-shift and modernization-aligned migration strategies.

Since GA, AWS has continued to expand EVS capabilities across global regional availability, storage flexibility, hybrid networking integration, and operational automation, further enabling organizations to modernize infrastructure at their own pace while maintaining existing investments in VMware skills, licensing, and operations.

Supported Regions

At GA and subsequent expansions, Amazon EVS is available in the following AWS Regions:

• US East (N. Virginia)

• US East (Ohio)

• US West (Oregon)

• Europe (Frankfurt)

• Europe (Ireland)

• Asia Pacific (Tokyo)

• Asia Pacific (Singapore)

• Europe (London)

• Asia Pacific (Mumbai)

• Asia Pacific (Sydney)

• Canada (Central)

• Europe (Paris)

Expanded Regional Availability & Global Reach

At general availability (GA) on 5 August 2025, EVS launched in six regions (US East N. Virginia, US East Ohio, US West Oregon, Europe Frankfurt, Europe Ireland, Asia Pacific Tokyo).
Since then, AWS has rapidly expanded its footprint:

• September 2025: Asia Pacific (Singapore), Europe (London)

• November 2025: Asia Pacific (Mumbai), Asia Pacific (Sydney), Canada (Central), Europe (Paris)
  The broader regional coverage helps meet data-residency, latency and regulatory/compliance needs, and enables customers to place VMware workloads closer to their users or AWS native services.

Enhanced Storage Flexibility & Networking Integration

Storage enhancements

Initially, EVS deployed VMware’s vSAN as the primary datastore (via local NVMe on the EC2 bare-metal hosts)
Since GA, AWS (in partnership with storage vendors) has introduced supplemental and external storage options:

• Native support for Amazon FSx for NetApp ONTAP as an external datastore for EVS environments. This allows decoupling of compute and storage, more flexible scaling, and leverages NetApp ONTAP features such as snapshots, replication, etc

• Support for third-party storage solutions such as Pure Storage Cloud Block Store is mentioned in the GA blog (as “preferred external storage”) to accommodate customer-familiar toolchains.
  These enhancements mean that customers aren’t locked into only the vSAN local storage model, but have more flexibility to match storage performance, backup/DR requirements, and cost models in hybrid VMware/AWS contexts.

Networking and hybrid connectivity

EVS is deployed inside a customer’s Amazon VPC, which enables direct access to 200+ native AWS services, and seamless network connectivity between on-premises environments and the EVS environment.
Key networking capabilities:

• Extend on-premises networks (for example via VPN or AWS Direct Connect into AWS Transit Gateway) so that VMs migrated into EVS can retain their IP addresses, maintain operational consistency and minimise application disruption.

• Use of AWS Cloud WAN and AWS Transit Gateway to orchestrate global connectivity between on-premises data centres, EVS regions, and AWS VPCs — simplifying network architecture for multi-region footprint.

• The documentation highlights the EVS architecture: VPC underlay subnets, EVS-created VLAN subnets, NSX overlay networks, Tier-0 gateway on NSX Edge, etc.
  Overall, the networking story is about preserving operational consistency (IP / MAC retention, same VLANs/Subnets) while unlocking cloud scale and AWS-native connectivity.

HCX connectivity options (summary + key tradeoffs)

AWS and VMware HCX together support three connectivity choices for pairing on-prem HCX appliances with HCX appliances deployed inside EVS: Direct Connect, Site-to-Site VPN (TGW termination), and public internet connectivity. The choice is made upfront during the EVS deployment and impacts migration speed, reliability, procurement timelines, and cost. 

• Direct Connect — best for large migrations and production hybrid connectivity: dedicated bandwidth (1 Gbps–400 Gbps for dedicated, 50 Mbps–25 Gbps via partner hosted links), predictable performance and lower latency for bulk VM data transfer. Requires Direct Connect provisioning, Transit VIF, Direct Connect Gateway (DXGW) association to TGW, TGW → VPC attachments and BGP routing configuration. Consider redundancy (multiple DX locations) for production. Also consider transit/GW processing charges and Direct Connect port fees when modeling cost. 

• Site-to-Site VPN (TGW VPN attachment) — faster to provision and useful when bandwidth needs are moderate or time is limited. EVS requires Site-to-Site VPNs to terminate to a Transit Gateway and attach the TGW to the EVS VPC. Use multiple VPN tunnels and ECMP if you need higher aggregate throughput; AWS documents “large” tunnels and achieving >1 Gbps per tunnel patterns (ECMP can aggregate up to ~20 Gbps using multiple tunnels). Consider variable internet performance and TGW processing charges.

• Public internet HCX connectivity — supported where private connectivity is not feasible or rapid migration is required. AWS provides a contiguous /28 public block you can use for assigning public IPs to EVS HCX uplinks. Public internet is simplest to configure but depend on ISP bandwidth and can be less predictable — evaluate ISP caps, throttling, and plan for initial seed + delta transfer phases. For HCX over an already-encrypted IPSec Site-to-Site tunnel, AWS recommends disabling HCX native encryption to avoid double encapsulation performance overhead.
  
  

Architecture & operational notes for HCX + EVS migrations

• HCX appliances in EVS pair to on-prem HCX appliances using private or public routable IPs depending on connectivity. Traffic paths must allow ESXi hosts, VCF management appliances, and HCX appliances to reach each other. EVS documentation and the HCX migration blog show high-level architected patterns using TGW attachments and Transit VIFs. 

• Planning consideration: volume of data to move (seed vs delta), migration windows, and the performance of your connectivity will determine whether vMotion/live migration, replication-assisted or cold-clone migration is the right approach for each workload. HCX offers multiple mobility methods to match operational constraints.

• Cost considerations: Direct Connect reduces internet egress unpredictability but involves port fees and capacity planning; VPN has hourly costs and TGW processing charges; public internet migration has minimal AWS connectivity provisioning overhead but may require higher on-prem ISP capacity and careful bandwidth cost planning

Operational Tooling, Automation, and Management

Guided provisioning, automation & IaC

With EVS, AWS offers a guided console workflow to provision a full VCF environment in a few hours rather than weeks of manual setup.
For automation and infrastructure-as-code (IaC) scenarios:

• Full support via AWS CLI, AWS SDKs for automating environment creation.

• CloudFormation resource specification (AWS::EVS::Environment) is available for template-based provisioning.

• Pre-deploy checklists and prerequisites are documented (IAM setups, VPC CIDR sizing, EC2 capacity reservations, license keys, etc.).
  These capabilities streamline operational onboarding and make EVS more manageable from a DevOps/infra-automation perspective.
  
  

Monitoring, Management and Partner ecosystem

• EVS integrates with standard AWS monitoring and operational tooling (for example, Amazon CloudWatch for observability) although the documentation emphasises users maintain control of vSphere/NSX layers themselves.

• AWS has defined managed policies (for example AmazonEVSServiceRolePolicy) and roles to handle the underlying resource-management on behalf of the customer environment.

• AWS Partner network: The GA blog emphasises that customers can self-manage or engage APN Partners who have built migration/managed-service offers on EVS.
  This gives enterprises flexibility: maintain existing VMware operations model, or partner for managed services.
  
  

Why It Matters – Key Benefits

• Operational consistency: Because EVS runs your existing VCF stack inside AWS, you can move workloads with minimal changes to IP addresses, operations, tooling, and skills.

• Control & Choice: Unlike fully managed VMware offerings, EVS gives you full administrative control of vCenter, NSX Manager, SDDC Manager — you can bring third-party add-ons, backup tools, external storage, choose licensing portability, etc.

• AWS integration & scale: Deploy inside your AWS VPC, connect to 200+ AWS services, benefit from cloud elasticity and AWS global infrastructure. 

• Faster migrations and modernization: Whether exiting a data centre, extending on-premises workloads, or modernising, EVS offers a path with less risk and disruption.

• Storage & cost flexibility: With external storage support (FSx for ONTAP, third-party) you can optimise cost/performance, decouple storage scaling from compute.
  
  

 Current Limitations & Considerations

• At GA, EVS supports VMware Cloud Foundation (VCF) version 5.2.1.x. Future VCF versions will become available over time as the service evolves — customers should validate the supported version in the AWS EVS documentation prior to deployment. EVS only supports i4i.metal at this time  to host the ESXi/vSAN/NSX stack.

• Only single-AZ deployments are supported initially (per current architecture docs). Multi-AZ or multi-region SDDC clusters may be planned for future.

• Amazon EVS does not support IPv6 at this time. All management and overlay networks must use IPv4 addresses. 

• Planning and prerequisites remain non-trivial: VPC CIDR sizing, route server endpoints, capacity reservations for bare-metal hosts, licensing keys, on-premises connectivity etc.

Outlook & What’s Next

Given AWS’s rapid roll-out and enhancements so far, you should expect the following directions:

• Broader region coverage (already underway) to support global enterprise footprints, data-sovereignty, lower latency.

• More instance types (beyond i4i.metal) and upgraded VCF version support over time. (Intel/AMD/Graviton, higher core counts)

• Enhanced storage/disaggregated architecture: more external datastore integrations, tiered storage options, improved cost-efficiency and scale.

• Deeper networking/hybrid-cloud capabilities: perhaps native Layer-2 extensions, improved multi-region NSX overlay features, tighter AWS Cloud WAN integration.

• More automation, drift detection, lifecycle management of the VMware stack inside AWS (patching, upgrades, capacity scaling) as customers scale production workloads.

• Greater managed-service offerings around EVS via APN Partners, making it easier for enterprises to hand-off operations if desired.

For your context (leading an EVS migration project with on-premises VMware + NSX-T + HCX + stretched networks), this means: you should actively plan for how and when to leverage the newer storage options (FSx for ONTAP), check region coverage (Mumbai region now available), and align your automation/Infrastructure-as-Code pipelines to use the CLI/SDK/CloudFormation capabilities.

Summary

Amazon Elastic VMware Service is a compelling option for enterprises running VMware workloads who want to migrate to AWS with minimal disruption, while preserving control of their virtualisation stack. With global region expansion, enhanced storage flexibility, and robust networking integration, EVS is maturing quickly as a hybrid-cloud VMware path. As you plan and execute your migration, the key areas to watch are: region availability, storage architecture (vSAN vs external), network topology and connectivity, and automation tooling.

Official Reference URLs

• EVS product page: https://aws.amazon.com/evs/ Amazon Web Services, Inc.

• “What is Amazon EVS?” user guide: https://docs.aws.amazon.com/evs/latest/userguide/what-is-evs.html AWS Documentation

• Architecture documentation: https://docs.aws.amazon.com/evs/latest/userguide/architecture.html AWS Documentation

• Setting up EVS (prerequisites): https://docs.aws.amazon.com/evs/latest/userguide/setting-up.html AWS Documentation

• GA announcement blog: https://aws.amazon.com/blogs/migration-and-modernization/run-vmware-your-way-amazon-elastic-vmware-service-is-now-generally-available/ Amazon Web Services, Inc.

• Additional regions announcement: https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-evs-additional-regions/ Amazon Web Services, Inc.

• FSx for ONTAP integration blog: https://www.netapp.com/blog/amazon-elastic-vmware-service-fsx-ontap/ NetApp

• HCX + EVS migration  https://aws.amazon.com/blogs/migration-and-modernization/accelerate-your-vmware-migration-to-aws-leveraging-amazon-elastic-vmware-service-and-hcx/