Introduction: Amazon Elastic VMware Service (Amazon EVS)
Amazon EVS is a new AWS-managed service which is now available in AWS. It allows organizations to run VMware Cloud Foundation (VCF) environments directly on AWS. In other words, you can deploy a full VMware Software-Defined Data Center (SDDC), including ESXi hosts, vCenter, NSX, and vSAN, within your Amazon Virtual Private Cloud (VPC).
EVS uses dedicated EC2 bare-metal instances, currently only i4i.metal, for ESXi hosts. This setup provides the scale, performance, and resilience of AWS while allowing you to continue using your familiar VMware tools and licenses. You can shift VMware workloads to AWS without the need to re-platform your VMs. Your IP addresses and operational runbooks stay the same, and you maintain full administrative control over the VMware stack in the cloud.
Amazon EVS offers a guided deployment experience, enabling you to set up a complete VMware Cloud Foundation environment in hours instead of weeks. The service integrates directly with AWS EVS environments running inside your VPC and can connect immediately to AWS services such as storage, databases, analytics, and AI without needing complicated networking changes.
At the same time, you keep a familiar VMware vSphere, NSX, and vSAN environment. Features like vMotion, HA, and VMware management appliances remain just as they were on-premises. You also have operational flexibility; you can self-manage the EVS environment with your in-house VMware skills or work with AWS Partners for migration and daily management.
This service bridges the gap between on-premises VMware data centers and the AWS cloud. It lets organizations take advantage of AWS’s agility and global scale while building on their existing VMware investments and expertise.
In short, EVS is “the fastest way to migrate and operate VMware workloads on AWS”
Key Features and Benefits
Amazon EVS offers a complete set of features to make VMware migration and operation on AWS easier. Key capabilities include:
- Automated VCF Deployment: Guided workflows via AWS Console or CLI set up a complete VMware Cloud Foundation SDDC in minutes. EVS automatically adds or removes EC2 bare-metal hosts in your vSphere clusters. It also creates all needed networks, including management, vMotion, vSAN, and NSX uplinks, behind the scenes. This greatly reduces the manual setup and lowers the chances of configuration errors.
- Lift-and-Shift Migration: EVS allows for straightforward migration of current VMware workloads. You can extend on-premises networks into AWS and transfer VMs without altering their IP addresses or modifying applications. Operational practices, such as monitoring, runbooks, and security policies, stay same. This allows your teams to use their existing VMware skills and tools, including vSphere Client, vCenter APIs, and NSX Manager.
- Full VMware Stack Control: Unlike a black-box service, EVS gives you full admin access to all VMware layers on AWS. You have direct access to the ESXi hosts, vCenter Server, NSX Manager, and SDDC Manager VMs, just like you would in your data center. This means you can customize networking, install third-party add-ons, and use your preferred backup or storage integrations, such as Amazon FSx for NetApp ONTAP or Pure Cloud Block Store. In short, you retain 100 percent complete control over your VMware environment while running it on AWS infrastructure.
- Hybrid Flexibility and License Portability: EVS supports VMware’s license portability. You can bring your own VCF licenses and vSAN licenses to AWS. A minimum of 256 CPU cores in your license is required, which is roughly four i4i.metal hosts and at least 110 TiB of vSAN capacity. You can use on-demand or reserved instances for flexible billing, choosing between 1-year or 3-year terms. Importantly, EVS environments can connect to your on-premises site through AWS Direct Connect or Site-to-Site VPN using a Transit Gateway. This setup enables truly hybrid deployments with seamless networking.
- AWS Integration (200+ Services): Since the entire VMware SDDC operates in your AWS account, you have easy access to all AWS services. For example, you can connect VMs and containers to Amazon S3, RDS/Aurora databases, Lambda functions, Amazon SageMaker/Bedrock AI, analytics tools, and more, without data egress or long migrations. EVS environments can use AWS native networking and storage, such as S3 for archiving, FSx for file storage, or EBS for block storage, alongside VMware’s vSAN. In practice, this means you can modernize your applications gradually. You can keep important VMs on VMware on AWS while slowly adopting cloud services around them.
- Scalability and Resilience: EVS uses AWS’s global infrastructure. You can scale out by adding more EC2 instances to your cluster through the console or API. You also benefit from AWS availability zones and high-speed networking. AWS takes care of physical host failures and hardware maintenance. EVS qualifies for AWS programs like the Migration Acceleration Program (MAP) to help lower migration costs. According to AWS, EVS operates in six regions at GA: US East Ohio, N. Virginia, US West Oregon, EU (Ireland), EU (Frankfurt), and APAC (Tokyo), with more regions expected soon. You only pay for the EC2 instances and other AWS resources you use, and there are no EVS-specific license fees.
Common Use Cases
Amazon EVS is suitable for various VMware-based cloud strategies. Typical scenarios include:
- Data Center Exit, Cloud Migration: EVS allows you to retire on-premises vSphere clusters by moving them entirely to AWS. You can transfer whole clusters with their network settings in place. This method meets tight deadlines, such as when closing a data center, without needing to rewrite applications. EVS’s automated SDDC deployment and VMware license portability greatly speed up this process.
- Hybrid Data Center Extension: If you need extra capacity or a broader geographic reach, EVS can extend your current VMware environment. It maintains IPs and connections, allowing you to stretch clusters to AWS or use EVS hosts as failover sites while managing both on-prem and cloud workloads with the same management plane (vCenter).
- Disaster Recovery and Resilience: EVS can act as a disaster recovery site for VMware workloads. You can replicate VMs from on-premises or other vSphere clusters to EVS, for example, using VMware Site Recovery Manager or storage-based replication. Because EVS operates the full VMware SDDC, it offers the same features (vMotion, HA, etc.) for testing failovers. Moreover, in the cloud, you only pay for reserved capacity or during a true failover event.
- Dev & Test and DevOps Bursting: Teams can quickly spin up temporary vSphere environments in AWS for development, testing, or patch validation. EVS allows them to do this using the same VMware APIs and procedures. When the environment is no longer needed, they can easily dismantle it like any other AWS resource.
- Phased Modernization: EVS supports a gradual shift to cloud-native. You can first migrate critical VMs to EVS and then evolve the stack—connecting VMs to AWS-managed databases, containerizing parts of your application, or using AI/analytics services on your data—without needing to refactor the entire VMware platform at once.
Architecture and Network Design
Amazon EVS uses a “consolidated domain” VMware architecture. This means the management components, such as vCenter Server, SDDC Manager, and the NSX Manager cluster, along with your ESXi compute hosts, are all in a single vSphere cluster with one vCenter instance. For example, EVS deploys several EC2 bare-metal hosts running ESXi inside AWS VPC. These hosts share a VMware vSAN datastore for storage and connect to an NSX edge gateway for networking.
Figure: Amazon EVS consolidated SDDC deployed in an AWS VPC. Management VMs (vCenter, SDDC Manager, NSX) and ESXi hosts run on dedicated EC2 i4i.metal instances. Two network layers are used: the AWS VPC underlay for host management, vMotion, vSAN, and NSX uplinks, and NSX overlay networks for VM traffic.
In the AWS VPC, EVS automatically creates several VLAN subnets when setting up the environment. These subnets are for host management, vMotion, vSAN, and the NSX uplink. The VMware environment uses these underlay subnets for infrastructure traffic. An AWS Route Server, which you enable in your VPC, performs dynamic routing using BGP between these VLAN subnets and the NSX overlay networks. This setup allows the VMs to communicate over the VPC. Additionally, you need to configure a transit gateway in your VPC if you want to connect EVS to on-premises networks through Direct Connect or VPN. Currently, EVS supports single-AZ deployments, meaning all EVS subnets and hosts are in one availability zone.
By design, your guest VMs operate on NSX overlay networks, or logical segments; they do not reside on the underlay VLAN subnets. You can set up multiple NSX overlays, known as Tier-1 gateways, for various applications or security zones. The NSX Tier-0 gateway, which has an active/standby configuration, manages all north/south traffic to the AWS VPC. For more details, AWS documentation offers an EVS network topology reference and best practices. This includes the requirement for two Route Server endpoints and BGP peers per Transit Gateway.
Deployment Prerequisites and Setup
Before creating an EVS environment, prepare your AWS account and VMware environment. Here are the key prerequisites:
1. AWS Account and Support Plan: You need an AWS account with either a Business or Enterprise support plan. EVS requires AWS Business/Enterprise On-Ramp or AWS Enterprise support for environment creation. If you don’t have this, you won’t be able to create an environment. Make sure your account has the necessary service quotas. For example, the host count per EVS environment quota must be at least 4.
2. Networking and VPC: Create an Amazon VPC to host your EVS environment. The VPC IPv4 CIDR must be large enough, with a minimum of /22, to fit EVS’s subnets. Within the VPC, allocate:
- A private subnet for EVS service access, which is used by the EVS control plane.
- A main route table that allows routes to DNS servers and any on-prem networks before deployment.
You also need a VPC Route Server instance with propagation enabled in the service subnet. Configure at least two Route Server endpoints and two peers so that EVS’s NSX edge can establish BGP routes to your VPC.
3. DHCP Options: The VPC’s DHCP options must include at least two DNS server IPs and a domain name. You must also create DNS forward and reverse zones for each VCF appliance and ESXi host. EVS will use these DNS settings for host and appliance name resolution.
4. Transit Gateway (for hybrid): If you plan to connect EVS to an on-premises network, set up an AWS Transit Gateway along with a Direct Connect or VPN, if desired. EVS needs the Transit Gateway to connect to on-premises networks. After deployment, add the EVS-created subnets to the TGW route table. Note that EVS does not support direct internet gateway attachments for on-prem connectivity.
5. Compute Capacity Reservations: Amazon EVS requires EC2 i4i.metal instances (Intel Xeon, large local Nitro SSDs) for ESXi hosts. To ensure availability, AWS strongly recommends creating an EC2 Capacity Reservation for the necessary number of i4i.metal instances in your region ahead of time. Plan for at least four i4i.metal hosts (256 vCPU cores) to meet the VCF licensing minimum. You’ll specify these hosts during environment creation.
6. VMware Licenses: You must have VMware Cloud Foundation licenses from Broadcom (VMware).
Specifically, obtain:
- A Site ID from Broadcom and a VCF solution key that covers at least 256 CPU cores.
- A vSAN license key with at least 110 TiB capacity.
These keys and Site ID need to be provided to EVS during environment creation. EVS requires valid license keys to be in place on the SDDC Manager. It does not validate them directly but reports the license usage to Broadcom for compliance.
7. IAM and CLI Tools: Create an IAM user or role with permissions for EVS. AWS provides an “AmazonEVSEnvironmentPolicy” managed policy to grant the necessary EVS actions. Install and configure the AWS CLI if you plan to script or automate EVS. However, you can also use the console.
8. Review VMware Prerequisites: Finally, ensure your setup meets VMware’s own requirements for VCF 5.2.1, which is the only supported version currently. This includes network underlay design, DNS zones, NTP servers, and more, as detailed in VMware’s Cloud Foundation documentation.
Completing these steps AWS support, network, licenses, capacity, and IAM will help you avoid common deployment failures. AWS offers a detailed checklist that covers all these items, which you can find in the EVS Deployment Prerequisite Checklist in the official AWS docs.
Creating an EVS Environment
Once prerequisites are met, you can create an Amazon EVS environment via the AWS Console, AWS CLI (aws evs commands), or CloudFormation (AWS::EVS::Environment resource)
Here are the high level steps:
1. Start Environment Creation: In the EVS console, choose Create environment. Select the target AWS Region; it must match your VPC and subnets. Enter a name.
2. Specify VCF Version and Licenses: Choose the VMware Cloud Foundation version; currently, only 5.2.1 is supported. Enter your Broadcom Site ID, VCF solution key, and vSAN key. EVS will check the keys; they must not be in use elsewhere. Note that the solution key must cover at least 256 cores, and the vSAN key must cover at least 110 TiB. Acknowledge that you will maintain these licenses.
3. Add ESXi Hosts: Next, specify the EC2 instances that will act as ESXi hosts. Choose the i4i.metal instance type for each host. EVS recommends a minimum of four hosts for the initial deployment. For each host, select the subnet within your VPC in the chosen AZ where that instance will run. Assign each a hostname, such as esx01, esx02, etc., and an SSH key pair for support and debugging. EVS will then launch these i4i instances for you.
4. Configure Networking: EVS will ask for your network settings. Select the VPC and the service access subnet, which should be a private subnet. Then specify CIDR blocks for each needed VLAN subnet:
- Host Management VLAN (for ESXi management IPs) – a /28 to /24 range.
- vMotion VLAN – the same size as the management VLAN.
- vSAN VLAN – the same size as the management VLAN.
- NSX Edge VTEP VLAN – the same size as the management VLAN. (You can also add extra VLAN CIDRs for future needs.)
Finally, enter the Uplink VLAN CIDR for the NSX uplink network and select the two Route Server peer IDs, which are the BGP peers you set up earlier, for NSX routing. EVS will create these subnets during deployment; note that they cannot be changed later.
5. DNS and Encryption: Provide the DNS hostnames for the VCF management appliances, such as vCenter, NSX Manager, and SDDC Manager. If using Route 53, select the hosted zone. EVS will also ask whether to use the AWS-managed KMS key or a customer-managed KMS key for encrypting VMware appliance credentials.
6. Review and Launch: Review all settings. Then create the environment. EVS will take several hours to provision everything. During this time, it automatically creates the underlying EC2 hosts, the vSAN datastore across them, the NSX infrastructure, and the VMware control plane.
After deployment, go to your AWS VPC console and link the new EVS VLAN subnets with your VPC route tables, as AWS describes. This step ensures proper NSX routing. Once the environment is ready, log into the vCenter Server and SDDC Manager appliances using the credentials created during setup. From here, you can manage your SDDC like any on-prem cluster: create VMs, apply policies, install guest OS, and so on.
EVS automates the heavy lifting: administrator mainly needs to supply the plan, license keys, and let AWS provision the VMware SDDC.
Pricing and Availability
Amazon EVS launched in public preview at AWS re:Invent 2024 and became Generally Available (GA) now, in August 2025. At GA, EVS is offered in multiple regions including US East, N. Virginia, Ohio, US West (Oregon), EU (Ireland, Frankfurt), and APAC (Tokyo). Pricing for EVS is based entirely on the underlying AWS resources you consume.
This means you pay the normal on-demand or reserved rates for the EC2 i4i.metal hosts which are Amazon EC2 instances and any additional AWS services (such as storage, networking, or management data transfer) that you use. There is no separate EVS software charge – it’s essentially a usage-based offer. You are free to use on-demand billing, or purchase 1‑year or 3‑year Savings Plans for the i4i instances as needed.
EVS is also eligible for programs like the AWS Migration Acceleration Program (MAP) to help offset license and migration costs. It’s important to note that EVS is considered an AWS-managed service so AWS provides support for the EVS integration, while you must maintain at least AWS Business Support for your account. Because EVS bridges AWS with Broadcom licensing, actual VMware support issues may involve collaboration between AWS Support and VMware Support.
Final Note
Amazon Elastic VMware Service (EVS) gives a native AWS path for running VMware workloads in the cloud. By deploying VMware Cloud Foundation directly in your AWS VPC, EVS allows you to reuse existing VMware infrastructure and skills while taking full advantage of AWS’s elasticity, security, and breadth of services.
Its key features automated SDDC setup, license portability, deep AWS integration, and full VM stack control – make it a powerful option for data center migration, hybrid cloud, DR, and modernization scenarios.
Reference : EVS AWS official documentation
Explore more Related articles at vlookuphub !!
