architecture

Amazon EVS, Explained for VCF Architects

VCF on EC2 bare metal inside your own VPC. Not the managed service you may be thinking of, and the networking constraints will shape your design whether you like them or not.

Mohammad Siddiqui

— 7 min read
Share
Amazon EVS, Explained for VCF Architects
VCF on EC2 bare metal inside your own VPC. Not the managed service you may be thinking of, and the networking constraints will shape your design whether you like them or not.

I keep getting asked about Amazon EVS by people who have heard the name, know it has something to do with VMware on AWS, and are not sure whether it is the thing they remember from a few years ago under a different name.

It is not. So here is what it actually is, what you run versus what AWS runs, and the handful of constraints that will shape your design whether you like them or not.

Worth saying up front: this moved quickly. It went GA in August 2025 on VCF 5.2.1, picked up VCF 9.0 and 9.1 support in July 2026, and has been landing in new regions steadily since. Sydney has had it since November 2025. So if you looked at this a year ago and put it aside, the thing you looked at is not the thing that exists now.

What it is

EVS deploys a VCF environment onto EC2 bare metal instances inside your own VPC, in subnets you define. The workloads running on it are ordinary vSphere workloads, so migration does not involve re-platforming anything.

The important word in that sentence is "your". The hosts sit in your VPC. You hold the VCF licences. You run vCenter, NSX Manager and the rest. AWS provides the bare metal, the automation that stands the environment up, and the surrounding services.

How it differs from what you might be thinking of
The older VMware Cloud on AWS arrangement was a managed service where the SDDC was operated for you. EVS is not that. You get full administrative access and you operate the VCF stack yourself, or with a partner. That is the whole design point, and it is also the thing people most often assume wrongly.

The architecture, and one consequence of it

EVS deploys the VCF consolidated architecture model. Management components and customer workloads share one domain, managed from a single vCenter, with vSphere resource pools providing the separation between management and workload.

If your on-premises design uses a separate management domain, and most enterprise designs do, this is a different shape. Not worse, but different, and it changes how you think about isolation, upgrade blast radius and resource contention. Worth knowing before you draw anything.

Instance types and what they lock you into
Bare metal, with i4i.metal, i7i.metal-24xl and i7i.metal-48xl named in the documentation. Two things follow. All hosts in a cluster must use the same instance type, so you cannot mix. And EVC mode has to match the silicon: INTEL_ICELAKE for i4i.metal, INTEL_SAPPHIRERAPIDS for the i7i instances. Get that wrong and you find out during deployment rather than in planning.
The vCPU quota trap
Each i4i.metal instance consumes 128 vCPUs against your EC2 On-Demand Standard instance quota. Four hosts is 512 vCPUs before you have run a single workload. If your account quota has not been raised, environment creation fails. Raise it early, because quota increases are not instant.
Capacity reservations
AWS recommends securing EC2 capacity reservations for bare metal instances before you deploy. Bare metal is not as elastic as the rest of EC2, and discovering that at cutover is an unpleasant way to learn it.

The networking model is where the real work is

This is the part that differs most from on-premises, and it is where I would spend design time.

EVS uses a two-layer model. The underlay is VPC networking: the VPC itself, subnets, route tables, and ESXi hosts attached via ENIs in subnets you choose. The overlay is NSX, doing what NSX does.

Dedicated, non-overlapping CIDRs
EVS needs dedicated non-overlapping CIDR blocks for infrastructure and workload networking, with a minimum /24 per VPC for the underlay. Address planning is a design exercise here rather than an afterthought, particularly if you are extending on-premises networks.
Nothing of yours in the EVS subnets
No customer workloads may be launched in EVS-managed subnets. That includes bastion hosts and monitoring agents, which is exactly the sort of thing somebody adds without thinking. Those subnets are for VCF components only.
VPC Route Server, with BGP
An Amazon VPC Route Server instance with propagation enabled is part of the required configuration. Route propagation between NSX overlay segments and your VPC route tables is how the two layers meet, and it shows up as a cost line as well as a design element.
Three things that are not supported for NSX overlay connectivity
Cross-Region VPC peering, S3 gateway endpoints, and Direct Connect virtual private gateway associations. If your target design assumed any of those, it needs revising. This is the constraint most likely to surprise a network architect late.

Licensing, and the part worth reading twice

You bring your own VCF licences. That is the commercial attraction and it comes with specific mechanics.

Two keys, with minimums
A VCF solution key and a vSAN licence key. The solution key must meet minimum core requirements and the vSAN key must meet minimum capacity requirements, both depending on the instance type you pick. Check this against what you actually hold before you plan a migration around it.
One environment per licence
VCF licences can be used for only one EVS environment. There is no reuse across environments. If your plan involves several environments for separation or staging, that is a licensing conversation, not just a technical one.
Broadcom sees the usage
You supply a Broadcom Site ID, and AWS uses it to meet Broadcom's licence usage reporting requirements. When you create an environment you accept terms confirming you hold and will maintain licences covering all physical cores, and information about your VCF software on EVS is shared with Broadcom for compliance verification. None of that is unreasonable. It is worth knowing it happens rather than discovering it in a true-up.
The connector
For VCF 9.0.x and 9.1.x, EVS uses an Operations Manager connector, which it uses to verify your environment has valid VCF entitlements. So entitlement checking is built into the deployment path rather than being a paperwork exercise after the fact.
The wider licensing picture
EVS was built around bring your own licence from the start, so there's no transition to manage here. That isn't true of Azure, Google Cloud and Oracle, where licence-included pricing is being retired with dates attached. I've written up what changed across all four if you run VMware on more than one of them.

Who operates what

AWS supports the AWS services that EVS deploys and handles direct customer support, engaging Broadcom for advanced needs. You run the VCF stack.

For VCF 9.x there is a detail worth knowing: in self-deployed mode you download and deploy the Broadcom VCF Installer and complete the installation using Broadcom's native workflow. So the experience is closer to a normal VCF build than to a managed service, which is consistent with the rest of the design but different from what the 5.2.x path looked like.

Where the documentation disagrees with itself
The EVS FAQ page still says VCF 5.2.1 and i4i.metal only, while the July 2026 announcement and the user guide cover VCF 9.0 and 9.1 and name additional instance types. The FAQ is simply lagging. There is also a difference between the user guide stating four hosts for initial deployment and the VCF 9.1 automation walkthrough deploying three. Work from the current user guide and the API reference rather than the FAQ, and confirm the host minimum for your target version before you size anything.

Cost, roughly

The components AWS lists are EC2 instance hours, VPC Route Server endpoints, and the EVS control plane. Available on demand and on one or three year terms. It is also eligible for the Migration Acceleration Program, which matters if you are building a funded business case rather than paying list.

The thing I would model carefully is the bare metal. 128 vCPUs per i4i.metal host, four hosts minimum, running continuously. That is the number that decides whether this is cheaper than the data centre you are leaving, and it is very sensitive to how long you intend to stay.

Where it genuinely fits

The scenario AWS is clearly aiming at is the data centre exit with a date attached. Lease ending, hardware out of support, a deadline that will not move. EVS gets workloads out without re-platforming, using the stack your team already knows.

It also fits sovereignty and residency requirements better than people expect, with the Sydney region available and FedRAMP Class C scope added this month for US regions.

Where I would think harder is the long-term steady state. If you are moving because the economics of owning hardware stopped working, you should model whether renting bare metal indefinitely actually solves that, or moves it. Sometimes it does. Sometimes the honest answer is that EVS is a good bridge to something else rather than a destination.

Before you plan anything

Sources

This service is changing quickly. Everything above was accurate against the documentation when I wrote it, and some of it will not be in six months. Check before you design.

Views expressed here are my own.

Read more