AWS announced on July 6, 2026, that VMware Cloud Foundation 9.0 and 9.1 are now supported on Amazon Elastic VMware Service, letting customers deploy EC2 metal hosts into their own Amazon VPC and complete VCF installation through Broadcom’s native installer workflow. That sounds like a version-support bulletin, but it is really a statement about where VMware’s post-Broadcom cloud future is settling. Amazon is not trying to hide VMware behind an opaque managed service; it is offering AWS infrastructure as the landing zone while leaving the VCF control plane recognizably in the customer’s hands. For enterprises still running large Windows and VMware estates, that distinction matters more than the version number.
The most important line in AWS’s announcement is not that VCF 9.0 and 9.1 are available on Amazon EVS. It is that AWS is “decoupling the provisioning of AWS infrastructure from the VCF software.” In plain English, Amazon EVS prepares the metal, networking, and underlay inside AWS; Broadcom’s VCF Installer still owns the actual VMware Cloud Foundation deployment.
That is a deliberate product stance. AWS could have pushed EVS further toward a fully managed VMware-like cloud experience, where customers consume capacity and avoid the plumbing. Instead, Amazon is leaning into the messy reality of enterprise VMware operations: many customers do not want a brand-new operating model during a migration, and many cannot afford one when a data center lease or hardware refresh clock is already ticking.
The result is a service that feels less like a cloud-native reinvention and more like an accelerated relocation platform. Amazon EVS deploys EC2 metal instances running ESX 9.x into a customer’s Amazon Virtual Private Cloud and connects them to private VLANs that act as the underlay for VCF. After that, customers download Broadcom’s installer and proceed through Broadcom’s workflow.
That is not glamorous, but it is strategically sharp. The buyer AWS is courting here is not the startup choosing between Kubernetes distributions. It is the infrastructure organization with sunk VMware skills, operational runbooks, backup tools, Windows licensing questions, and a board-level demand to reduce data center exposure without detonating the application estate.
That timing is important. The VMware world has spent the post-acquisition period absorbing licensing changes, bundling changes, partner-program changes, and a general narrowing of Broadcom’s VMware strategy around VCF. Whether customers love or loathe that consolidation, the market signal has been consistent: Broadcom wants VCF to be the center of gravity.
AWS’s move accepts that reality rather than fighting it. Amazon is not pitching EVS as a way to escape VCF. It is pitching EVS as a way to run VCF where AWS can provide the physical infrastructure, regional footprint, connectivity, and adjacent cloud services.
For administrators, that means VCF 9.x on EVS should be understood as a hybrid compromise. You get the cloud location and AWS infrastructure primitives, but you do not get to pretend VCF disappears. Lifecycle management, design validation, licensing discipline, VMware architecture, and the usual operational burden remain part of the picture.
That may sound like a drawback, but for many VMware shops it is the feature. The whole premise of EVS is that minimizing architectural difference can be more valuable than maximizing cloud purity.
AWS provisions the EC2 metal instances, drops them into the customer’s VPC, and wires the networking underlay. Broadcom’s tools then turn that substrate into a VCF deployment. This boundary keeps AWS from pretending that VMware Cloud Foundation is just another AWS-managed control plane, while also giving customers a more deterministic path to infrastructure readiness than building every host and network element manually.
That model will appeal to teams that have already standardized on VCF design patterns. It also gives cautious enterprises a cleaner mental model: AWS is the infrastructure venue, Broadcom is the VMware platform authority, and the customer remains the operator of the VCF environment.
The risk is that boundaries can become seams. If deployment fails, if a VLAN assumption is wrong, if credentials are mis-scoped, or if a VCF workflow reports an error that depends on AWS infrastructure state, administrators will need clear runbooks and support paths. The announcement points toward automation and examples, but the operational test will come when real customers hit the ugly edge cases.
This is where Amazon’s new Solutions for EVS GitHub repository matters. Templates and infrastructure-as-code artifacts are not just convenience features; they are Amazon’s attempt to standardize the fragile middle ground between AWS provisioning and VMware installation. For shops that already treat CloudFormation or Terraform as production control surfaces, that repository may become the difference between an EVS proof of concept and a repeatable migration factory.
That is a practical improvement. VMware migrations are rarely blocked by one big technical impossibility; they are slowed by a sequence of smaller uncertainties. Does the network design map cleanly? Do existing operational tools behave as expected? Can the team complete a VCF deployment in the target environment? Are the migration waves realistic? Evaluation mode gives teams a way to answer those questions earlier.
But evaluation mode should not be mistaken for a licensing holiday. AWS is explicit that customers remain responsible for appropriate VCF subscription coverage once they move beyond evaluation. In other words, this is a smoother entry ramp, not a change in the economics of Broadcom-era VMware.
That distinction matters because many VMware customers are still recalculating cost models after Broadcom’s licensing and packaging changes. EVS may reduce migration friction, and AWS infrastructure may change the capital-versus-operating-expense conversation, but it does not eliminate the need to understand VCF subscription obligations. If anything, making it easier to deploy quickly increases the need for governance before workloads start moving.
For Windows-heavy estates, the licensing puzzle is even more consequential. AWS introduced Windows Server licensing support for Amazon EVS in April 2026, and the new VCF 9.x connector model builds on that earlier capability. The practical message is that Amazon understands VMware migration is not just a hypervisor problem; it is also a Windows licensing, inventory, compliance, and reporting problem.
That is a narrow role by design. AWS says the connector does not sit in the operational path of the VCF software. In cloud architecture terms, Amazon is trying to observe and entitle without becoming an inline dependency for day-to-day VMware operations.
That separation is sensible. VMware administrators are rightly suspicious of anything that introduces a new control-plane dependency into cluster operations, especially during migrations or recovery scenarios. If the connector is limited to state awareness, licensing enablement, and reporting, it becomes a management integration rather than a new operational choke point.
Still, the connector deserves scrutiny from security and platform teams. It uses stored credentials, reaches management appliances, and links an AWS service to the VMware administrative plane. That is exactly the sort of component that should be documented, monitored, least-privileged, rotated, and included in threat models.
The upside is that Secrets Manager gives AWS a standard place to anchor credential handling. The downside is that “standard” does not mean “automatic.” Enterprises will need to decide who owns the connector, how credential rotation is handled, what logs are reviewed, and how connector health affects compliance reporting.
A fully re-architected migration is attractive in slide decks, but calendar pressure changes the math. When a facility exit date is fixed, when a storage array is near end of support, or when a hardware refresh would require a large capital commitment, “move first, modernize later” becomes the politically viable strategy. EVS exists for that moment.
That is why the Aeroméxico reference in AWS’s announcement is useful even if it remains a customer-proof point rather than an independent benchmark. The selling point is speed and familiarity: run VMware workloads on AWS with fewer architectural differences between source and destination. The more boring the migration feels to the application owner, the more valuable the platform becomes to the infrastructure team.
There is a broader industry pattern here. Public cloud providers have spent years telling enterprises to modernize into native services. Enterprises have spent those same years explaining that not every workload has a business case for refactoring, not every application has a living development team, and not every compliance regime rewards architectural novelty.
EVS is Amazon’s answer to that stalemate. It says: if you are going to keep VMware for now, bring it to AWS, and we will make that landing zone as familiar as possible while keeping you close to the rest of the AWS portfolio.
That makes EVS’s Windows licensing integration more than a side feature. When AWS added Windows Server licensing entitlements to Amazon EVS in April 2026, it acknowledged one of the most stubborn frictions in VMware migrations: operating-system licensing does not become simpler just because the hypervisor moves.
The new VCF 9.x connector workflow carries that forward. The connector lets EVS remain aware of the deployment and report license usage. For administrators, that means the success of an EVS migration will depend not only on whether VMs boot after migration, but whether entitlement, reporting, and compliance processes survive the move.
That is particularly important for organizations with mixed licensing histories. Some Windows Server workloads may have portability rights, some may not, and some may be wrapped in enterprise agreements whose terms require careful interpretation. EVS can provide mechanisms, but it cannot replace licensing diligence.
This is where Windows admins and VMware admins need to work together earlier than they often do. A VMware migration plan that treats Windows licensing as a late-stage checkbox is a plan inviting delay. EVS’s connector model gives teams a technical hook, but inventory accuracy and license governance still start inside the customer’s organization.
Amazon EVS is AWS’s bid to keep those VMware estates from drifting elsewhere. The argument is not merely that AWS can host VMware. It is that AWS can host VMware while giving customers more control over the VCF installation and a direct path into the broader AWS ecosystem.
The control angle is important because some managed VMware cloud offerings abstract away more of the stack. That can be useful for customers who want less operational responsibility. But for organizations with deep VMware skill sets, strict architecture standards, or existing tooling dependencies, too much abstraction can feel like loss of agency.
AWS is threading that needle. It is offering infrastructure speed without insisting on operational amnesia. Customers can deploy and configure VCF much as they would on premises, but they do it on AWS metal, inside their AWS network environment, near AWS services.
That is a powerful pitch, but not a universal one. If your organization is trying to reduce VMware operational dependency, EVS may preserve too much of the old world. If your organization is trying to exit a data center quickly while keeping application risk low, preserving the old world may be precisely the point.
Infrastructure teams do not need another wizard for their tenth environment. They need repeatability, reviewable configuration, source control, change management, and a way to encode hard-won deployment lessons. If the repository matures with reference architectures, storage configurations, and native AWS integrations as AWS promises, it could become the public blueprint for how EVS is actually operated at scale.
There is also a trust-building function. In a service where AWS provisions the substrate and Broadcom’s installer provisions the VMware platform, artifacts can make assumptions visible. Network layout, host configuration, storage patterns, and integration points become things teams can inspect rather than tribal knowledge hidden in a sales-engineering deck.
The repository will need discipline to stay useful. Too many cloud “solutions” repositories become a graveyard of demos that work only in the exact conditions imagined by the author. EVS customers will need production-grade examples that account for identity, logging, failure modes, upgrade paths, backup integration, and security boundaries.
If AWS gets that right, the repository becomes more than a starter kit. It becomes the automation layer that lets customers turn EVS into a migration assembly line.
On premises remains the obvious answer for many regulated, latency-sensitive, or capital-invested organizations. But not every enterprise wants to keep buying and refreshing data center hardware just to keep VMware alive. EVS gives Broadcom’s VCF strategy a cloud venue that still respects the VCF operating model.
That matters for Broadcom as much as AWS. If VCF is to be the center of VMware’s future, it needs credible deployment venues beyond customer-owned data centers. AWS brings global reach, procurement familiarity, and a giant ecosystem of adjacent services.
The relationship is not without tension. Public cloud providers have their own incentives to pull workloads toward native services over time. Broadcom has incentives to keep VCF central. Customers have incentives to avoid lock-in, reduce risk, and preserve optionality. EVS sits at the intersection of those incentives.
The immediate bargain is clear: run VCF on AWS now, keep VMware operational patterns intact, and leave modernization decisions for later. The long-term question is whether “later” ever arrives.
Customers still need a VCF architecture. They still need network design. They still need identity integration, backup strategy, monitoring, patching, certificate management, security controls, and lifecycle planning. They still need to understand how VCF 9.0 and 9.1 differ from their current environment, especially if they are coming from older vSphere or VCF releases.
That is why evaluation mode is useful but insufficient. A proof of concept should not simply prove that the installer runs. It should prove that the operational model works after day one.
The most successful EVS deployments will likely be those that start with boring questions. Who owns the VCF lifecycle? How are Windows licenses tracked? What happens if the connector loses access? Which AWS accounts and VPCs contain the environment? How is network segmentation enforced? What is the rollback plan for each migration wave? Which workloads should not move this way at all?
Those questions are not obstacles to cloud adoption. They are the difference between cloud adoption and cloud-shaped technical debt.
VCF 9.x on Amazon EVS is interesting because it accepts compromise as the product. It lets organizations run the latest VMware Cloud Foundation software in AWS while retaining much of the familiar deployment and operating model. It gives AWS a way to capture VMware workloads without forcing immediate refactoring. It gives Broadcom’s VCF platform another credible landing zone. It gives customers a faster route out of physical constraints without pretending the old complexity has disappeared.
That compromise will frustrate purists. Cloud-native advocates will see too much legacy. Traditional VMware admins may see too much AWS. Finance teams may still see licensing and consumption models that require careful control. Security teams will see new trust relationships to evaluate.
They are all right. The point of EVS is not ideological purity; it is practical continuity under pressure.
AWS Is Selling Control, Not Abstraction
The most important line in AWS’s announcement is not that VCF 9.0 and 9.1 are available on Amazon EVS. It is that AWS is “decoupling the provisioning of AWS infrastructure from the VCF software.” In plain English, Amazon EVS prepares the metal, networking, and underlay inside AWS; Broadcom’s VCF Installer still owns the actual VMware Cloud Foundation deployment.That is a deliberate product stance. AWS could have pushed EVS further toward a fully managed VMware-like cloud experience, where customers consume capacity and avoid the plumbing. Instead, Amazon is leaning into the messy reality of enterprise VMware operations: many customers do not want a brand-new operating model during a migration, and many cannot afford one when a data center lease or hardware refresh clock is already ticking.
The result is a service that feels less like a cloud-native reinvention and more like an accelerated relocation platform. Amazon EVS deploys EC2 metal instances running ESX 9.x into a customer’s Amazon Virtual Private Cloud and connects them to private VLANs that act as the underlay for VCF. After that, customers download Broadcom’s installer and proceed through Broadcom’s workflow.
That is not glamorous, but it is strategically sharp. The buyer AWS is courting here is not the startup choosing between Kubernetes distributions. It is the infrastructure organization with sunk VMware skills, operational runbooks, backup tools, Windows licensing questions, and a board-level demand to reduce data center exposure without detonating the application estate.
VCF 9.x Turns EVS Into a First-Class Broadcom Landing Zone
Broadcom positioned VMware Cloud Foundation 9.0 as a major private-cloud release when it became generally available in June 2025, emphasizing a more unified platform for traditional applications, modern workloads, and AI infrastructure. By adding VCF 9.0 and 9.1 support, Amazon EVS moves from “a VMware-compatible AWS option” toward something more consequential: an AWS-hosted place to run the current Broadcom-defined VMware stack.That timing is important. The VMware world has spent the post-acquisition period absorbing licensing changes, bundling changes, partner-program changes, and a general narrowing of Broadcom’s VMware strategy around VCF. Whether customers love or loathe that consolidation, the market signal has been consistent: Broadcom wants VCF to be the center of gravity.
AWS’s move accepts that reality rather than fighting it. Amazon is not pitching EVS as a way to escape VCF. It is pitching EVS as a way to run VCF where AWS can provide the physical infrastructure, regional footprint, connectivity, and adjacent cloud services.
For administrators, that means VCF 9.x on EVS should be understood as a hybrid compromise. You get the cloud location and AWS infrastructure primitives, but you do not get to pretend VCF disappears. Lifecycle management, design validation, licensing discipline, VMware architecture, and the usual operational burden remain part of the picture.
That may sound like a drawback, but for many VMware shops it is the feature. The whole premise of EVS is that minimizing architectural difference can be more valuable than maximizing cloud purity.
The Installer Boundary Is the Product Boundary
The handoff between Amazon EVS and Broadcom’s VCF Installer is more than an implementation detail. It defines who owns which part of the stack and where customers should expect support, automation, and accountability to begin and end.AWS provisions the EC2 metal instances, drops them into the customer’s VPC, and wires the networking underlay. Broadcom’s tools then turn that substrate into a VCF deployment. This boundary keeps AWS from pretending that VMware Cloud Foundation is just another AWS-managed control plane, while also giving customers a more deterministic path to infrastructure readiness than building every host and network element manually.
That model will appeal to teams that have already standardized on VCF design patterns. It also gives cautious enterprises a cleaner mental model: AWS is the infrastructure venue, Broadcom is the VMware platform authority, and the customer remains the operator of the VCF environment.
The risk is that boundaries can become seams. If deployment fails, if a VLAN assumption is wrong, if credentials are mis-scoped, or if a VCF workflow reports an error that depends on AWS infrastructure state, administrators will need clear runbooks and support paths. The announcement points toward automation and examples, but the operational test will come when real customers hit the ugly edge cases.
This is where Amazon’s new Solutions for EVS GitHub repository matters. Templates and infrastructure-as-code artifacts are not just convenience features; they are Amazon’s attempt to standardize the fragile middle ground between AWS provisioning and VMware installation. For shops that already treat CloudFormation or Terraform as production control surfaces, that repository may become the difference between an EVS proof of concept and a repeatable migration factory.
Evaluation Mode Lowers the First Wall, Not the Real Cost
Support for VCF evaluation mode is the most customer-friendly part of the announcement. AWS says customers can create an EVS environment and begin deploying VCF without providing license keys up front, giving teams time to stand up the design, test the implementation, and validate the migration path before applying subscriptions.That is a practical improvement. VMware migrations are rarely blocked by one big technical impossibility; they are slowed by a sequence of smaller uncertainties. Does the network design map cleanly? Do existing operational tools behave as expected? Can the team complete a VCF deployment in the target environment? Are the migration waves realistic? Evaluation mode gives teams a way to answer those questions earlier.
But evaluation mode should not be mistaken for a licensing holiday. AWS is explicit that customers remain responsible for appropriate VCF subscription coverage once they move beyond evaluation. In other words, this is a smoother entry ramp, not a change in the economics of Broadcom-era VMware.
That distinction matters because many VMware customers are still recalculating cost models after Broadcom’s licensing and packaging changes. EVS may reduce migration friction, and AWS infrastructure may change the capital-versus-operating-expense conversation, but it does not eliminate the need to understand VCF subscription obligations. If anything, making it easier to deploy quickly increases the need for governance before workloads start moving.
For Windows-heavy estates, the licensing puzzle is even more consequential. AWS introduced Windows Server licensing support for Amazon EVS in April 2026, and the new VCF 9.x connector model builds on that earlier capability. The practical message is that Amazon understands VMware migration is not just a hypervisor problem; it is also a Windows licensing, inventory, compliance, and reporting problem.
EVS Connectors Are Quietly Becoming the Control-Plane Glue
The connector concept is easy to skim past, but it may become one of EVS’s most important architectural pieces. AWS describes an EVS connector as a persistent, authenticated link from EVS to VCF management appliances, using credentials stored in AWS Secrets Manager. Once VCF is installed and reachable, that connector lets the Amazon EVS control plane monitor environment state, enable Windows licensing entitlements, and report license usage.That is a narrow role by design. AWS says the connector does not sit in the operational path of the VCF software. In cloud architecture terms, Amazon is trying to observe and entitle without becoming an inline dependency for day-to-day VMware operations.
That separation is sensible. VMware administrators are rightly suspicious of anything that introduces a new control-plane dependency into cluster operations, especially during migrations or recovery scenarios. If the connector is limited to state awareness, licensing enablement, and reporting, it becomes a management integration rather than a new operational choke point.
Still, the connector deserves scrutiny from security and platform teams. It uses stored credentials, reaches management appliances, and links an AWS service to the VMware administrative plane. That is exactly the sort of component that should be documented, monitored, least-privileged, rotated, and included in threat models.
The upside is that Secrets Manager gives AWS a standard place to anchor credential handling. The downside is that “standard” does not mean “automatic.” Enterprises will need to decide who owns the connector, how credential rotation is handled, what logs are reviewed, and how connector health affects compliance reporting.
The VMware Migration Story Is Becoming a Race Against Calendars
AWS’s announcement explicitly calls out customers facing data center contract expirations and infrastructure refresh cycles. That is not marketing filler. It is the real forcing function behind many VMware-to-cloud decisions in 2026.A fully re-architected migration is attractive in slide decks, but calendar pressure changes the math. When a facility exit date is fixed, when a storage array is near end of support, or when a hardware refresh would require a large capital commitment, “move first, modernize later” becomes the politically viable strategy. EVS exists for that moment.
That is why the Aeroméxico reference in AWS’s announcement is useful even if it remains a customer-proof point rather than an independent benchmark. The selling point is speed and familiarity: run VMware workloads on AWS with fewer architectural differences between source and destination. The more boring the migration feels to the application owner, the more valuable the platform becomes to the infrastructure team.
There is a broader industry pattern here. Public cloud providers have spent years telling enterprises to modernize into native services. Enterprises have spent those same years explaining that not every workload has a business case for refactoring, not every application has a living development team, and not every compliance regime rewards architectural novelty.
EVS is Amazon’s answer to that stalemate. It says: if you are going to keep VMware for now, bring it to AWS, and we will make that landing zone as familiar as possible while keeping you close to the rest of the AWS portfolio.
This Is Also a Windows Story
WindowsForum readers should resist the temptation to see this as only a VMware infrastructure announcement. In many enterprises, VMware is the place where Windows Server estates have accumulated for years: domain controllers, SQL Server workloads, line-of-business applications, file services, middleware, vendor appliances, and the odd forgotten server that still runs payroll-adjacent logic.That makes EVS’s Windows licensing integration more than a side feature. When AWS added Windows Server licensing entitlements to Amazon EVS in April 2026, it acknowledged one of the most stubborn frictions in VMware migrations: operating-system licensing does not become simpler just because the hypervisor moves.
The new VCF 9.x connector workflow carries that forward. The connector lets EVS remain aware of the deployment and report license usage. For administrators, that means the success of an EVS migration will depend not only on whether VMs boot after migration, but whether entitlement, reporting, and compliance processes survive the move.
That is particularly important for organizations with mixed licensing histories. Some Windows Server workloads may have portability rights, some may not, and some may be wrapped in enterprise agreements whose terms require careful interpretation. EVS can provide mechanisms, but it cannot replace licensing diligence.
This is where Windows admins and VMware admins need to work together earlier than they often do. A VMware migration plan that treats Windows licensing as a late-stage checkbox is a plan inviting delay. EVS’s connector model gives teams a technical hook, but inventory accuracy and license governance still start inside the customer’s organization.
AWS Wants the VMware Estate Before Someone Else Gets It
There is a competitive subtext here that Amazon does not need to say aloud. VMware customers evaluating their next move have multiple options: renew on premises, move to a hosted VCF provider, consider Google Cloud VMware Engine or Azure VMware Solution depending on strategic alignment, adopt Nutanix or Hyper-V alternatives, or use the migration event as a forcing function for cloud-native modernization.Amazon EVS is AWS’s bid to keep those VMware estates from drifting elsewhere. The argument is not merely that AWS can host VMware. It is that AWS can host VMware while giving customers more control over the VCF installation and a direct path into the broader AWS ecosystem.
The control angle is important because some managed VMware cloud offerings abstract away more of the stack. That can be useful for customers who want less operational responsibility. But for organizations with deep VMware skill sets, strict architecture standards, or existing tooling dependencies, too much abstraction can feel like loss of agency.
AWS is threading that needle. It is offering infrastructure speed without insisting on operational amnesia. Customers can deploy and configure VCF much as they would on premises, but they do it on AWS metal, inside their AWS network environment, near AWS services.
That is a powerful pitch, but not a universal one. If your organization is trying to reduce VMware operational dependency, EVS may preserve too much of the old world. If your organization is trying to exit a data center quickly while keeping application risk low, preserving the old world may be precisely the point.
The GitHub Repository Is a Small Door Into a Bigger Automation Strategy
The new Solutions for EVS GitHub repository may sound like supporting material, but it hints at how AWS expects serious customers to use the service. Examples, templates, and infrastructure-as-code artifacts are the connective tissue between a one-off deployment and an enterprise migration program.Infrastructure teams do not need another wizard for their tenth environment. They need repeatability, reviewable configuration, source control, change management, and a way to encode hard-won deployment lessons. If the repository matures with reference architectures, storage configurations, and native AWS integrations as AWS promises, it could become the public blueprint for how EVS is actually operated at scale.
There is also a trust-building function. In a service where AWS provisions the substrate and Broadcom’s installer provisions the VMware platform, artifacts can make assumptions visible. Network layout, host configuration, storage patterns, and integration points become things teams can inspect rather than tribal knowledge hidden in a sales-engineering deck.
The repository will need discipline to stay useful. Too many cloud “solutions” repositories become a graveyard of demos that work only in the exact conditions imagined by the author. EVS customers will need production-grade examples that account for identity, logging, failure modes, upgrade paths, backup integration, and security boundaries.
If AWS gets that right, the repository becomes more than a starter kit. It becomes the automation layer that lets customers turn EVS into a migration assembly line.
Broadcom’s VCF Strategy Gets a Cloud Escape Valve
Broadcom’s VMware strategy has been controversial, but it has also been coherent: simplify the portfolio, push customers toward subscription bundles, and make VCF the flagship platform. For customers that buy into that direction, the question becomes where VCF should run.On premises remains the obvious answer for many regulated, latency-sensitive, or capital-invested organizations. But not every enterprise wants to keep buying and refreshing data center hardware just to keep VMware alive. EVS gives Broadcom’s VCF strategy a cloud venue that still respects the VCF operating model.
That matters for Broadcom as much as AWS. If VCF is to be the center of VMware’s future, it needs credible deployment venues beyond customer-owned data centers. AWS brings global reach, procurement familiarity, and a giant ecosystem of adjacent services.
The relationship is not without tension. Public cloud providers have their own incentives to pull workloads toward native services over time. Broadcom has incentives to keep VCF central. Customers have incentives to avoid lock-in, reduce risk, and preserve optionality. EVS sits at the intersection of those incentives.
The immediate bargain is clear: run VCF on AWS now, keep VMware operational patterns intact, and leave modernization decisions for later. The long-term question is whether “later” ever arrives.
Enterprise IT Should Treat EVS as a Migration Platform, Not a Magic Wand
The strongest case for VCF 9.x on Amazon EVS is that it reduces migration discontinuity. The weakest case is any claim that it makes VMware complexity vanish. It does not.Customers still need a VCF architecture. They still need network design. They still need identity integration, backup strategy, monitoring, patching, certificate management, security controls, and lifecycle planning. They still need to understand how VCF 9.0 and 9.1 differ from their current environment, especially if they are coming from older vSphere or VCF releases.
That is why evaluation mode is useful but insufficient. A proof of concept should not simply prove that the installer runs. It should prove that the operational model works after day one.
The most successful EVS deployments will likely be those that start with boring questions. Who owns the VCF lifecycle? How are Windows licenses tracked? What happens if the connector loses access? Which AWS accounts and VPCs contain the environment? How is network segmentation enforced? What is the rollback plan for each migration wave? Which workloads should not move this way at all?
Those questions are not obstacles to cloud adoption. They are the difference between cloud adoption and cloud-shaped technical debt.
The Real News Is the Shape of the Compromise
The industry likes clean narratives: cloud replaces data centers, Kubernetes replaces VMs, SaaS replaces line-of-business applications, and automation replaces administrators. Enterprise infrastructure rarely behaves that neatly.VCF 9.x on Amazon EVS is interesting because it accepts compromise as the product. It lets organizations run the latest VMware Cloud Foundation software in AWS while retaining much of the familiar deployment and operating model. It gives AWS a way to capture VMware workloads without forcing immediate refactoring. It gives Broadcom’s VCF platform another credible landing zone. It gives customers a faster route out of physical constraints without pretending the old complexity has disappeared.
That compromise will frustrate purists. Cloud-native advocates will see too much legacy. Traditional VMware admins may see too much AWS. Finance teams may still see licensing and consumption models that require careful control. Security teams will see new trust relationships to evaluate.
They are all right. The point of EVS is not ideological purity; it is practical continuity under pressure.
The EVS Playbook Now Has Sharper Edges
AWS’s VCF 9.x support gives VMware shops a clearer route into AWS, but the details determine whether that route becomes a highway or a cul-de-sac. The announcement is strongest where it narrows ambiguity: EVS handles the AWS substrate, Broadcom’s installer handles VCF, connectors handle awareness and entitlement, and customers remain responsible for subscriptions and operations.- Amazon EVS now supports VMware Cloud Foundation 9.0 and 9.1, with AWS provisioning EC2 metal hosts and networking before customers complete installation through Broadcom’s VCF Installer.
- Evaluation mode lets teams deploy and validate VCF 9.x on EVS before applying license keys, but it does not remove the need for proper VCF subscription coverage.
- EVS connectors create an authenticated management link using credentials stored in AWS Secrets Manager, enabling environment awareness, Windows licensing entitlements, and usage reporting.
- The new Solutions for EVS GitHub repository is positioned as the automation starting point for CloudFormation, Terraform, reference architectures, storage patterns, and AWS service integrations.
- The strongest EVS use case remains time-sensitive VMware migration, especially for organizations facing data center exits, hardware refreshes, or large Windows Server estates that cannot be refactored quickly.
References
- Primary source: Amazon Web Services (AWS)
Published: 2026-07-06T18:40:08.379038
Announcing support for VCF 9.0 and 9.1 on Amazon EVS | Migration & Modernization
We’re excited to share that VMware Cloud Foundation (VCF) 9.0 and 9.1 are now available on Amazon Elastic VMware Service (EVS), giving you complete control over your VCF installation. Our focus with Amazon EVS is to give you the flexibility to deploy and configure VCF to fit your needs, using...aws.amazon.com - Related coverage: blogs.vmware.com
VMware Cloud Foundation 9.0 - What’s in it for the VCSPs - VMware Cloud Provider Blog
Broadcom is officially announcing the General Availability of VMware Cloud Foundation (VCF) 9.0. This significant release will be available starting June 17, 2025. VCF 9.0 marks a major milestone in our commitment to empower our VMware Cloud Service Providers (VCSPs) with a unified, modern...blogs.vmware.com
- Related coverage: news.broadcom.com
Broadcom dévoile le cloud privé nouvelle génération avec VMware Cloud Foundation 9.0 - Broadcom News & Stories - Français
La nouvelle génération de la plateforme cloud privé de Broadcom, permet aux entreprises d’innover plus rapidement, d’optimiser leurs dépenses IT, et de garantir un haut niveau de sécurité et de souveraineté sur leurs données. Paris, FR. — Broadcom Inc. (NASDAQ: AVGO) annonce la disponibilité...
news.broadcom.com
- Related coverage: nasdaq.com
Broadcom Delivers the Modern Private Cloud with VMware Cloud Foundation 9.0 | Nasdaq
--Broadcom Inc. is announcing the general availability of VMware Cloud Foundation 9.0, the platform for the modern private cloud. "With this next generation of our cloud platform, VMware Cloud Foundation 9.0, we are again raising the bar for the modern private cloud by vastly simplifying...www.nasdaq.com - Related coverage: techtarget.com
- Related coverage: techradar.com
VMware reveals major channel partner shake-up - and it's bad news for smaller firms | TechRadar
Broadcom is making more changes to VMwarewww.techradar.com
- Related coverage: itpro.com
Nationwide targets private cloud gains with VMware Cloud Foundation deal | IT Pro
The expanded collaboration will establish a unified private cloud platform for the high street lenderwww.itpro.com