Designing AWS Modernization with VMware Migration as the Entry Point - Why FSx for ONTAP as the Data Foundation

Introduction What comes "next" for VMware workloads? Hardly a day goes by without the question coming up. The licensing changes that followed Broadcom's acquisition of VMware have pushed many organizations into a fundamental review of their virtualization strategy. But it is worth pausing here: "getting off VMware" is not the goal. The real destination is the modernization beyond the migration - reworking applications and data, up to and including serverless and cloud-native architectures. The AWS Storage Blog, too, frames the migration not as mere license avoidance but as an opportunity to modernize infrastructure. (Reference: AWS Storage Blog - Expedite VMware migration to Amazon EC2 and Amazon FSx for NetApp ONTAP using the BlueXP workload factory migration advisor) The Core of Modernization on AWS - AWS Transform What drives modernization on AWS today is AWS Transform, an agentic-AI service. Beyond rehosting VMware workloads, it can containerize source code (replatforming to Amazon ECS / Amazon EKS) and take .NET Framework applications to cross-platform .NET on Linux - capabilities that run migration and modernization in parallel. It lifts migration from "moving servers" to "reworking applications," and that is what modernization on AWS looks like now. However you rework the compute - EC2, containers, or serverless - one thing is always needed: a place for the data. This is where Amazon FSx for NetApp ONTAP, which I work with, comes alongside. I field questions about FSx for ONTAP every day, and one thing these migrations tend to overlook is the continuity and extensibility of the storage operations model. Keep the storage operations built up over years in VMware and ONTAP environments - Snapshot, Clone, Replication, Storage Efficiency - on AWS too, and let a multi-protocol data hub support everything from migration through to cloud-native. Keep the data layer consistent and you can re-choose the compute as many times as you like. Designing modernization with AWS migration as the entry point and the data foundation at the core - that is the lens of this series. Five Destinations for VMware Workloads AWS officially presents five pathways for VMware workloads. (Reference: AWS for VMware - Comprehensive Pathways) AWS for VMware: The Pathways to Migrate and Modernize on AWS I drew the five official pathways as five rows, combining AWS services with ONTAP: - Row 1 is Migrate to Amazon EC2: Amazon EC2 reaches Amazon FSx for NetApp ONTAP over iSCSI. - Row 2 is Modernize on AWS: Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, AWS Fargate, Amazon WorkSpaces, AWS Lambda, AWS Batch and Amazon FSx for NetApp ONTAP. - Row 3 is Run VMware on AWS: Amazon Elastic VMware Service reaches Amazon FSx for NetApp ONTAP over NFS / SMB. - Row 4 is Run AWS on-premises: AWS Outposts and NetApp ONTAP. - Row 5 is Run third-party hypervisors on AWS: Red Hat OpenShift Service on AWS, Amazon FSx for NetApp ONTAP, and Nutanix Cloud Clusters on AWS. Source: AWS for VMware Partner Offerings - "AWS offers the most comprehensive set of migration and modernization options for VMware-based workloads - from relocating to Amazon EVS, to rehosting on Amazon EC2, containerizing with Amazon EKS, or transitioning to running third-party hypervisors in the cloud like ROSA and NC2 on AWS." (Summarized; rephrased for licensing constraints.) Each Pathway in Detail 1. Rehost to Amazon EC2 The most straightforward path: migrating VMware VMs as EC2 instances. AWS Transform for VMware (an agentic-AI-based migration service) became generally available in May 2025. (Reference: AWS What's New) Separately, on 30 August 2026, FSx for ONTAP became generally available as a target storage type for AWS Transform for migrations (MGN). The former is a service for migrating from VMware; the latter is a target-storage choice for server migration. They are different features, and Part 2 of this series covers the latter. (Reference: AWS What's New) Storage configuration options: - EBS only: Simple. Automated with MGN / AWS Transform - EBS (OS) + FSx for ONTAP (Data): Keeps ONTAP capabilities. Supported by AWS Transform (MGN) / Shift Toolkit / Cirrus Migrate Cloud (the scope of this series) 2. Modernization (Containers / Serverless) As the next step after rehosting to EC2, you can modernize according to the characteristics of each workload. | Target | Suitable workloads | FSx for ONTAP integration | |---|---|---| | ECS / EKS (EC2 mode) | Stateful containers (DB, middleware) | ✅ iSCSI / NFS mount available | | ECS / EKS (Fargate) | Stateless microservices | △ Through EFS only (no iSCSI) | | AWS Lambda | Event-driven, short-running processing | △ EFS mount available, no iSCSI | | AWS Batch | Batch processing / HPC | ✅ iSCSI available in EC2 mode | | Amazon WorkSpaces | VDI (virtual desktops) | ✅ FSx for ONTAP file shares | This is not about containerizing VMs as they are. The journey is "rehost to EC2 → containerize the application → move step by step to Fargate/Lambda". 3. Amazon EVS (Keep VMware on AWS) With Amazon Elastic VMware Service, you can deploy VMware Cloud Foundation (VCF) directly on EC2 bare metal inside your VPC. You keep your existing vSphere skill set and can connect FSx for ONTAP as an external datastore. It suits cases with a large VMware-dependent application estate, where leaving VMware in a short time is impractical. 4. AWS Outposts (On-premises AWS + NetApp External Storage) AWS Outposts is a fully managed service that places AWS infrastructure on premises. Third-party block storage integration was announced in December 2024, and NetApp ONTAP and StorageGRID are available as partners validated through the AWS Service Ready Program. (Reference: AWS Blog) (Reference: NetApp) NetApp ONTAP iSCSI LUNs can be attached directly from the AWS console as data volumes for EC2 instances, and boot volume support was added in July 2025. This gives you separation of compute and storage: "compute is AWS-managed, storage is your existing ONTAP." 5. Partner Solutions (ROSA / Expanding Nutanix + NetApp Integration) - Red Hat OpenShift Service on AWS (ROSA): A fully managed environment based on OpenShift. With the NetApp Trident CSI driver, ROSA Pods can access FSx for ONTAP over NFS/iSCSI. (Reference) - Nutanix + NetApp ONTAP (on-premises Nutanix Cloud Platform): At .NEXT Chicago in April 2026, a partnership was announced that lets the Nutanix Cloud Platform (NCP / AHV) use NetApp ONTAP (AFF / FAS) as external storage. Over an NFS-based connection, compute (Nutanix AHV) and storage (ONTAP) scale independently. GA is planned for the second half of 2026 (NetApp targets Q3 2026, with Early Access underway). The partnership covers on-premises NetApp enterprise storage; integration with Nutanix Cloud Clusters (NC2) on AWS or with FSx for ONTAP is not announced or committed in public sources (NetApp mentions "NetApp cloud storage services for Nutanix Cloud Platform" as a future direction, with the timing and the services undetermined). (Reference: NetApp Blog, GA Q3 2026) (Reference: Nutanix press release) The NetApp ecosystem as a whole: Figure 2: the data layer stays the same when the compute changes. SnapMirror is what crosses the boundary (dark theme) What this figure shows is that ONTAP is a data platform independent of the choice of hypervisor or cloud. Whether you move the compute layer from VMware to EC2 or to Nutanix, the data layer stays consistently available, and SnapMirror moves and protects the data. Where This Series Sits Figure 3: the phases beyond rehosting, and the alternatives to it. This series covers Phase 1 (dark theme) This series concentrates on Phase 1 (rehost), but the EC2 + FSx for ONTAP configuration is designed not to close off the path to Phase 2 and beyond. FSx for ONTAP is reachable over NFS/iSCSI from ECS/EKS as well as from EC2, so the data layer can stay as it is after containerization. Why "EC2 + FSx for ONTAP" Among the five pathways, here is why this series looks at "EC2 + FSx for ONTAP" in particular. An Entry Point for Rehosting and a Foundation for Modernization This configuration is not just a rehost destination; it is designed not to close off future modernization. - Now (Phase 1): Rehost VMs to EC2. Data disks on FSx for ONTAP iSCSI - Next (Phase 2): Containerize the application. Keep accessing FSx for ONTAP over NFS/iSCSI from ECS/EKS - Later (Phase 3): Parts that became stateless move to Fargate/Lambda. The FSx for ONTAP data layer stays as it is The multi-protocol access of FSx for ONTAP (NFS/SMB/iSCSI) is what supports this step-by-step migration. A volume used as an iSCSI LUN for EC2 can later be NFS-mounted by an EKS Pod. The Value of ONTAP Is Capability, Not Capacity Seen as just "large-capacity storage," FSx for ONTAP can look expensive next to EBS. But capacity is not where the value of ONTAP lies. | ONTAP feature | Use on AWS | |---|---| | Snapshot | Point-in-time copies in seconds. Instant test environments | | FlexClone | Clones without copying data. Lower cost for dev/test | | SnapMirror | Block-level replication. Cross-Region DR | | Compression / Dedup | Lower effective capacity. Most effective for databases and logs | | Thin Provisioning | Pay for what is used. Avoid over-provisioning | | Multi-protocol | Access the same volume over NFS/SMB/iSCSI | FSx for ONTAP EC2 Integration Pattern Figure 4: the boot column is Amazon EBS in all three rows; only the data column changes to FSx for ONTAP from staging on (dark theme) This configuration has the following advantages. - Storage and compute scale independently: Change FSx for ONTAP capacity/throughput without stopping EC2 - The ONTAP operations model carries over: Operate snapshots, clones and replication with the same CLI/API as on premises - The limit moves: The ceiling is no longer the per-instance Amazon EBS limit but the EC2 network bandwidth and the FSx for ONTAP throughput capacity. Note: Performance Ceilings and Protocols "The limit moves" abov