For Windows and infrastructure administrators, the significance is less about AWS’s “choice” messaging than about where the operational and licensing boundaries now sit. Amazon EVS remains a self-managed VMware Cloud Foundation deployment running on AWS bare metal. AWS supplies the VPC-connected hardware and underlying service components; customers still own the VCF installation, upgrades, patching, architecture, and the consequences of getting any of those wrong.
AWS launched Amazon EVS generally in August 2025 with VCF 5.2.1 on i4i.metal hosts in six Regions. Its latest recap says EVS has reached 22 Regions, supports VCF 9.0 and 9.1, and can scale an environment from the original 16-host ceiling to 32 hosts. The new i7i.metal-48xl option arrives as AWS is trying to make EVS viable for larger VMware estates facing data-center exits or renewed VCF subscription decisions.
The new host doubles the i7i memory and storage ceiling
AWS’s EC2 specifications list the i7i.metal-48xl with 192 vCPUs, 1,536 GiB of memory, twelve 3.75 TB NVMe drives, up to 100 Gbps of network bandwidth, and up to 60 Gbps of EBS bandwidth. Since the hardware exposes two threads per core, the 192-vCPU figure corresponds to the 96 physical cores cited in AWS’s EVS announcement.
Compared with the i7i.metal-24xl that EVS added in April, the new model doubles the available memory, local NVMe capacity, network capacity, and EBS bandwidth per host. That changes the host-count conversation for clusters constrained by RAM or vSAN capacity rather than raw compute. A workload that needs more than 768 GiB per host, for example, previously had to spread across more EVS nodes or remain on i4i.metal; the 48xl makes a more consolidated design possible.
AWS says its fifth-generation Intel Xeon-based i7i family offers up to 23 percent better compute performance and more than 10 percent better price performance than i4i. Those are AWS comparison figures rather than a VCF benchmark, so administrators should not translate them into a guaranteed per-VM gain. VMware placement behavior, vSAN policy, CPU overcommit, NUMA topology, and the performance profile of the actual guest workloads will decide whether fewer, larger hosts are beneficial.
There is another qualification buried in the launch notice. AWS says i7i.metal-48xl support is available only in Regions where both Amazon EVS and EC2 i7i are available. The company’s claim that EVS itself has expanded to 22 Regions should therefore not be read as a promise that the new host type is in all 22 on day one. Capacity planning teams need to validate the instance type in the specific target Region before treating the new density as an available migration option.
AWS documentation has not fully caught up with the release
The newly published i7i.metal-48xl release is real, but several current Amazon EVS documentation pages still name only i4i.metal and i7i.metal-24xl as supported host types. AWS’s EVS FAQ and API documentation both show that older list, while the August 27 release notice says the 48xl is supported.
That is a documentation lag, not evidence that the announcement is false. Still, it is more than a cosmetic problem for infrastructure teams. The EVS service has specific provisioning requirements, supported VCF versions, host counts, VCF subscription-key requirements, and vSAN capacity requirements that vary by instance type. A team building an automated deployment pipeline should not assume an older API schema, a static infrastructure-as-code module, or an internal runbook already recognizes the 48xl.
AWS’s user guide also makes clear that EVS is not a way to recycle perpetual vSphere licensing. Customers must bring an active VMware Cloud Foundation subscription with appropriate portability rights, and the service validates licensing capacity when an environment is created. That requirement remains a gating cost even if AWS can now reduce the number of physical hosts needed for a given workload.
The service’s VCF 9 model also changes the setup sequence. AWS announced support for VCF 9.0 and 9.1 in July, using what it calls self-deployed mode: EVS provisions the EC2 bare-metal infrastructure and network underlay in the customer’s VPC, while the customer uses the native VCF Installer to build the stack. AWS has also released an EVS Deployment Orchestrator in its Solutions for Amazon EVS repository for organizations that prefer an automated installation.
That split gives VMware teams more control than a fully managed appliance-style offering, but it preserves more responsibility. A VCF 9 deployment on EVS is not a lift-and-forget service. Teams need an owner for certificate lifecycle, DNS, identity integration, VCF patch sequencing, backup integration, capacity management, and support escalation across AWS and Broadcom.
Windows Server licensing is useful, but it adds a control-plane dependency
The most relevant development for Windows-heavy VMware estates arrived in April: AWS now sells Windows Server license entitlements for individual EVS virtual machines. AWS says organizations with eligible licenses and portability rights can bring them to EVS, while customers without those rights can assign AWS-provided Windows Server licensing to selected VMs and pay by vCPU-hour.
This removes one of the least attractive parts of moving Windows guests onto dedicated VMware hosts in public cloud: licensing every core on a large host even when only a subset of its VMs run Windows Server. With EVS entitlements, licensing follows the selected Windows VMs’ configured vCPU count and running time. AWS documents support for Windows Server 2016 and later.
The practical tradeoff is that the license entitlement mechanism depends on an EVS connector to vCenter Server. AWS requires the connector to be active and its reachability check to pass before an administrator can create an entitlement. The service then uses that connector to monitor the guest VM’s power state and vCPU configuration for billing.
That introduces a condition administrators should treat as operationally important: if the connector loses reachability, the linked entitlements enter an at risk state. AWS documents an eight-hour grace period; if connectivity is not restored, the entitlements are dropped and usage tracking stops from the time they entered that state. This is a licensing and service-management dependency, not merely another monitoring alert. Network teams need to account for the connector, its DNS resolution, vCenter credentials stored through AWS Secrets Manager, firewall paths, and recovery procedures.
AWS also limits entitlement creation to 100 at a time, according to its EVS documentation. That does not bar large Windows estates, but it means bulk licensing should be planned as a staged operation rather than an assumption that thousands of VMs can be onboarded in one console action.
AWS’s published Windows licensing example contains a cost mismatch
The licensing model warrants close pricing validation before anyone treats it as a simple pay-as-you-go saving. AWS’s EVS pricing page states a flat Windows Server licensing rate of $0.046 per vCPU-hour and uses an example with 384 vCPUs running for 730 hours in a month. At the listed rate, that calculation comes to $12,894.72 per month.
Yet the same AWS example lists the charge for those 384 vCPUs as $20,937.00. That total implies roughly $0.0747 per vCPU-hour, not $0.046. AWS has not explained the discrepancy on the page.
It would be premature to declare which figure is correct from the public material alone. But the inconsistency is significant enough that organizations should obtain a written, current quote and model the entitlement cost against their own VM inventory before using AWS’s example in a business case. The economics can swing sharply with Windows VM uptime, vCPU allocations, existing Software Assurance or portability rights, and whether consolidation onto 96-core hosts changes the underlying VCF subscription requirement.
The availability of per-VM entitlements also does not eliminate Microsoft licensing due diligence. Microsoft’s April partner guidance says certain Windows Server and SQL Server subscriptions under the Microsoft Customer Agreement through CSP gained License Mobility rights beginning April 1, 2026, while CSP perpetual licenses did not gain those rights. Licensing teams must identify the exact agreement, product, edition, purchase channel, and rights attached to each existing license rather than assuming every Windows Server entitlement can move.
Memory Tiering and NSX Federation expand design options, not automatic capacity
AWS’s wider EVS update also points to VCF 9 Memory Tiering, which uses local NVMe storage as a memory tier. AWS says a cluster can address up to twice the effective memory with the same number of hosts. The feature is supported on both i4i and i7i EVS instance families.
That does not turn NVMe into equivalent DRAM. It is a capacity and consolidation mechanism with workload suitability implications, and it needs testing against latency-sensitive Windows services, database VMs, and infrastructure components before it becomes the basis for an aggressive host-reduction plan. For workloads that are memory-capacity constrained but less sensitive to tiered-memory performance behavior, it may make the larger i7i hosts more useful.
AWS has also added NSX Federation support for linking on-premises NSX and EVS environments through a common control plane. The promised benefits—extended segments, consistent distributed firewall policy, and simpler disaster-recovery failover—are meaningful for hybrid VMware estates. They also bring the usual federation requirements: compatible versions, a deliberate failure-domain design, clear ownership of policy changes, and testing that proves a recovery workflow actually works under a partial outage.
Amazon EVS is becoming a more credible option for enterprises that want to retain VCF operations while moving the physical estate into AWS. The i7i.metal-48xl, VCF 9 self-deployment support, 32-host environments, and VM-level Windows licensing each remove a distinct adoption barrier.
But the first-year update does not make EVS a managed VMware exit ramp. It gives administrators larger hosts and more licensing flexibility while leaving them responsible for the VCF stack—and, in the case of Windows entitlements, for keeping the vCenter connector healthy enough for AWS to track what it is licensing.