AWS Backup logically air-gapped vault now supports Amazon FSx for NetApp ONTAP. Logically air-gapped vaults are a type of AWS Backup vault that allows secure sharing of backups across accounts and AWS Organizations, supporting direct restore to reduce recovery time from a data loss event. You can now protect your Amazon FSx for NetApp ONTAP volumes in logically air-gapped vaults. A logically air-gapped vault stores immutable backups that are locked by default, and isolated with encryption using AWS owned keys or customer-managed keys. You can store your FSx for NetApp ONTAP backups in a logically air-gapped vault in the same account or across other accounts and Regions. This helps reduce the risk of downtime, ensure business continuity, and meet compliance and disaster recovery requirements. You can get started using the AWS Backup console, AWS Command Line Interface (CLI), or AWS SDKs. Target FSx for NetApp ONTAP backups to a logically air-gapped vault by specifying it as the primary target or copy destination in your backup plan. Share the vault for recovery or restore testing with other accounts using AWS Resource Access Manager (RAM), or safeguard vault access during account compromise using Multi-party approval. Once available, you can initiate direct restore jobs from that account, eliminating the overhead of copying backups first. This support is available in all AWS Regions where both logically air-gapped vault and Amazon FSx for NetApp ONTAP are available. For more information and detailed regional availability, visit the AWS Backup documentation. To learn more about logically air-gapped vaults, visit the feature documentation and pricing page.

AWS Backup logically air-gapped vault now supports Amazon FSx for NetApp ONTAP. Logically air-gapped vaults are a type of AWS Backup vault that allows secure sharing of backups across accounts and AWS Organizations, supporting direct restore to reduce recovery time from a data loss event. You can now protect your Amazon FSx for NetApp ONTAP volumes in logically air-gapped vaults. A logically air-gapped vault stores immutable backups that are locked by default, and isolated with encryption using AWS owned keys or customer-managed keys. You can store your FSx for NetApp ONTAP backups in a logically air-gapped vault in the same account or across other accounts and Regions. This helps reduce the risk of downtime, ensure business continuity, and meet compliance and disaster recovery requirements. You can get started using the AWS Backup console, AWS Command Line Interface (CLI), or AWS SDKs. Target FSx for NetApp ONTAP backups to a logically air-gapped vault by specifying it as the primary target or copy destination in your backup plan. Share the vault for recovery or restore testing with other accounts using AWS Resource Access Manager (RAM), or safeguard vault access during account compromise using Multi-party approval. Once available, you can initiate direct restore jobs from that account, eliminating the overhead of copying backups first. This support is available in all AWS Regions where both logically air-gapped vault and Amazon FSx for NetApp ONTAP are available. For more information and detailed regional availability, visit the AWS Backup documentation. To learn more about logically air-gapped vaults, visit the feature documentation and pricing page.

AWS Backup logically air-gapped vault now supports Amazon FSx for NetApp ONTAP. Logically air-gapped vaults are a type of AWS Backup vault that allows secure sharing of backups across accounts and AWS Organizations, supporting direct restore to reduce recovery time from a data loss event. You can now protect your Amazon FSx for NetApp ONTAP volumes in logically air-gapped vaults. A logically air-gapped vault stores immutable backups that are locked by default, and isolated with encryption using AWS owned keys or customer-managed keys. You can store your FSx for NetApp ONTAP backups in a logically air-gapped vault in the same account or across other accounts and Regions. This helps reduce the risk of downtime, ensure business continuity, and meet compliance and disaster recovery requirements. You can get started using the AWS Backup console, AWS Command Line Interface (CLI), or AWS SDKs. Target FSx for NetApp ONTAP backups to a logically air-gapped vault by specifying it as the primary target or copy destination in your backup plan. Share the vault for recovery or restore testing with other accounts using AWS Resource Access Manager (RAM), or safeguard vault access during account compromise using https://docs.aws.amazon.com/aws-backup/latest/devguide/multipartyapproval.html. Once available, you can initiate direct restore jobs from that account, eliminating the overhead of copying backups first. This support is available in all AWS Regions where both logically air-gapped vault and Amazon FSx for NetApp ONTAP are available. For more information and detailed regional availability, visit the https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-region. To learn more about logically air-gapped vaults, visit the https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html and https://aws.amazon.com/backup/pricing/.

AWS Backup now supports logically air-gapped vaults for Amazon FSx for NetApp ONTAP, enabling secure immutable backups with cross-account sharing and direct restore capabilities.

Introduction This is Part 2 of the series "The Data Foundation for AWS Modernization."...

## Introduction This is Part 2 of the series "The Data Foundation for AWS Modernization." Part 1 set out the lens: migration is not the goal but the entry point, and putting FSx for ONTAP at the data foundation lets you re-choose the compute. This part takes that entry point through AWS Transform, the core of modernization, and verifies hands-on that the data area lands on FSx for ONTAP as part of the migration on AWS. Migration from an on-premises VMware environment will come separately; the idea here is to start modernizing from the tightly coupled EC2 × EBS configuration by decoupling the data store. Until now, when you migrated servers with AWS Transform (MGN), every disk was placed on Amazon EBS. If the source was not ONTAP and you wanted the data area on Amazon FSx for NetApp ONTAP (FSx for ONTAP below), you needed a "two-step migration" — migrate to EBS first, then move the data — or a third-party block storage migration tool. With the update of 30 August 2026, **FSx for ONTAP can now be chosen directly as the MGN target storage type**. * AWS Transform announces general availability of Amazon FSx for NetApp ONTAP support: https://aws.amazon.com/about-aws/whats-new/2026/09/aws-transform-fsx-netapp-ontap-support/ That looked useful, so I tried it hands-on straight away. The source in this test was **not** an on-premises VMware environment but an EC2 instance already on AWS (Amazon Linux 2023). Using that EC2 as the source, I ran the new path that migrates the data area (EBS) directly to an FSx for ONTAP iSCSI LUN. Running it for real turned up several pitfalls that reading the documentation alone does not reveal. Besides sorting out what this new feature can and cannot do, this article records the traps I actually stepped on during the test — errors hidden behind a successful job, and an unexpected capacity spike. Here are the highlights up front, especially the traps to watch for. * Only **data volumes** can be targeted. Boot is always Amazon EBS. * What became GA is "the MGN target storage type". It is a different thing from presenting FSx for ONTAP as a VMware datastore (the Amazon EVS side). * In MGN's phases, "SNAPSHOT" was a volume Snapshot done as a metadata operation, and "LAUNCH" was the creation of a FlexClone (about 44 seconds for 8 GiB). * **[Trap 1] Finalize is not just clean-up; it is the step where physical capacity temporarily peaks (about 2x)**. * **[Trap 2]** Even when the job status becomes `COMPLETED`, **a failed final snapshot (fallback) or the creation of an unbootable target can be hiding behind it**. ### Test Assumptions and Scope The test was run with the following environment and scope. (Region: ap-northeast-1 / Source: Amazon EC2 (AL2023) / ONTAP: 9.18.1P3D1) **[What was run]** The whole flow: agent installation → replication → test launch → cutover → Finalize → teardown. **[Out of scope for this article (not verified)]** * Migration with VMware as the source (no vCenter was prepared, so EC2 stood in as the source) * FSx for ONTAP as an Amazon EVS datastore (a different feature) * Durations at production-scale data volumes (the test used a tiny 16 GiB environment, dominated by fixed overhead) * Windows sources, and access over SMB / NFS * Post-migration optimization with `lun move start` ## The Shape of the Configuration _Figure 1: three EC2 instances and where each volume goes: the boot column is EBS in all three rows, and only the data column changes to FSx for ONTAP from staging on (dark theme)_ _Figure 2: the control path, from AWS Transform to the ONTAP management endpoint (dark theme)_ The point is that the boot area and the data area go to different places. **The boot column stays Amazon EBS in all three rows, and only the data column changes to FSx for ONTAP from the staging row on.** The target instance boots from EBS and receives the data over iSCSI. The source in this test was EC2, but the lower two rows of the configuration are the same whether the source is a VMware datastore or on-premises block storage. For the control path in Figure 2, the official blog says a PrivateLink connection is established automatically, but in practice a Network Load Balancer (NLB) and a VPC endpoint service are created inside your VPC. They incur hourly and LCU charges. Layer | Normal operation (replicating) | After cutover ---|---|--- Source EC2 | Running. The agent keeps sending blocks | Can be stopped Replication server EC2 | MGN launches it automatically | Terminated by Finalize Amazon EBS | Boot staging | Becomes the target's root volume FSx for ONTAP | Staging FlexVol and LUN | Target FlexVol (FlexClone) Network Load Balancer | Running | Remains after Finalize (manual deletion needed) Table 1: each layer after cutover: the one that needs manual deletion is the Network Load Balancer ## The Most Important Distinction: What Became GA Is the MGN Target Mix this up and you will evaluate the wrong product. It is easily confused with "FSx for ONTAP can be used as a VMware datastore". Question | Current support ---|--- Can FSx for ONTAP be used as the MGN target storage type? | **Yes (GA with this release)** Is FSx for ONTAP presented as a VMware datastore? | No. The datastore is a separate feature on the Amazon EVS side Can the boot disk also go on FSx for ONTAP? | No. Boot is always Amazon EBS Can EBS and FSx for ONTAP be mixed within one server? | No. All data volumes use the same type Can you migrate agentlessly? | No. Agent-based replication only Which protocol do clients connect with? | iSCSI. The data is placed as LUNs inside a FlexVol Table 2: questions and current support: the agentless path is not supported The Known limitations in the MGN documentation state `Agent-based replication only`. If you were planning around vCenter's agentless path, the plan has to change. The path depends on whether you leave VMs for EC2, or keep the VMs and move only the storage out. _Figure 3: the FSx for ONTAP settings in the replication template. Only the SVM ID and the Secret ARN are specified, and the note states that boot goes to EBS_ ## Environments This Configuration Suits Whether a migration fits depends on the shape of the workload, not on the product of the source storage. * The boot / root area and the data area are separate, and the data area is on block storage * You want capabilities such as Snapshot and thin provisioning on the data area after migration * You want to turn "migrate, then move the data" into a single step * You already run ONTAP and want the same mechanisms (Snapshot / FlexClone / SnapMirror) after migration Most of these apply whatever the source storage is. Even when the source is ONTAP, however, permissions, quotas and Snapshot policies are not migrated and need to be set up again. ### Environments Where Another Option Fits Better for Now * Boot and data sit on the same volume * You cannot install an agent (agentless is not supported) * The source is Windows and you want to move the data as SMB shares * File-level migration is enough and block-level replication is not needed (a file transfer such as AWS DataSync is sufficient) * The source is ONTAP and you want to take the volumes as they are (SnapMirror takes fewer steps) ## A Mini Glossary Term | Meaning | Where it appears in this article ---|---|--- SVM | A logical server inside the file system | Where MGN creates the FlexVol and LUN FlexVol | A volume that holds data. LUNs live inside it too | MGN creates one for staging and one for the target LUN | A unit of block storage, exposed over iSCSI | One source disk becomes one LUN Snapshot | A point-in-time image inside a volume | MGN's SNAPSHOT phase creates it FlexClone | A writable clone made from a Snapshot | The target FlexVol is one Split | Detaching a FlexClone from its parent and materializing it | Finalize runs it ## The Procedure and the Measured Time for Each Step The entry point is the AWS Transform workspace. MGN runs the migration itself, but it is AWS Transform that handles everything from planning to landing zone and network as a single job. # | Step | Measured ---|---|--- 1 | Initialize MGN | Done from the console. The CLI failed (see below) 4 | Install the agent | Failed once (see below) 5 | Initial full sync (16 GiB / 3 disks) | 226 seconds 6 | Test launch | SNAPSHOT 43 seconds, CONVERSION about 4 minutes 30 seconds 7 | Cutover (correct order) | MGN job 649 seconds; 817 seconds from issuing it to confirming boot 9 | Finalize | Split under 60 seconds; about 33 minutes until clean-up completed (_n=1 measurements at 16 GiB / 3 disks. Fixed overhead dominates, so they cannot be used as a basis for RTO._) ## Snapshot and FlexClone: What AWS Transform's Phase Names Refer To I lined up the ONTAP side by timestamp to see which ONTAP operation each AWS Transform phase name corresponds to. AWS Transform phase | Corresponding ONTAP operation ---|--- SNAPSHOT | Creating a volume Snapshot of the staging FlexVol LAUNCH | Creating a FlexClone from that Snapshot The SNAPSHOT phase is not a plain data copy but a metadata operation (44 seconds for 8 GiB). The target volume is a clone with `is_flexclone: true`. What matters most is that **a FlexClone uses almost no physical capacity when it is created**. Measured just before Finalize, the target volume's logical size was 7.91 GiB while its physical consumption was only 35.5 MiB. Capacity planning has to look at physical values, not logical ones. ## Finalize Is Not Clean-up; It Is Where Capacity Peaks Running Finalize starts a split of the FlexClone (the operation that detaches it and makes it independent), which materializes the data. Elapsed from T0 | Observed change ---|--- Immediately | Lifecycle `CUTOVER`, replication `DISCONNECTED` About 3 minutes | FlexClone split starts. Physical consumption rising from 35.5 MiB → 3.94 GiB About 4 minutes | Split completes. Physical consumption 8.57 GiB About 13 minutes | Staging FlexVol deleted, replication server EC2 terminated There was a gap of about 9 minutes between the split completing and the staging volume being deleted. **During those 9 minutes, physical capacity holds twice the migrated data.** If you run Finalize while the aggregate's free space is below the migrated data size, it is likely to get stuck here. Keep in mind that Finalize is a capacity risk, not an availability risk. ## Four Places I Stumbled ### 1. A Failed Final Snapshot Behind a Successful Job To measure downtime, I shut down the source OS and then ran cutover. The job returned `COMPLETED` and the target `LAUNCHED`. It looked like a success, but the job log recorded this: 09:14:21 SNAPSHOT_START 09:19:22 SNAPSHOT_FAIL timed out after 300 seconds 09:19:23 USING_PREVIOUS_SNAPSHOT The final sync did not complete, and the job fell back to the previous snapshot. The cause was my procedure: shutting down the OS also stopped the replication agent, and taking the crash-consistent snapshot timed out. The correct procedure is to stop only the application's writes and run cutover with the OS and the agent still running. "Stop writes on the source" in the official documentation does not mean shutting down the OS. In this test there were no recent writes, so the data matched, but doing this in a real environment **loses the latest data written after the snapshot it fell back to.** What makes this risky is that it does not show up in the job status (`status` or `launchStatus`) at all. By the API's design, the job returns `COMPLETED` as long as processing finishes, even after a fallback. **Lesson** : After cutover, always check `event` in `describe-job-log-items`. A `COMPLETED` job is not evidence that the final sync succeeded. ### 2. Two Unbootable Targets: NVMe Device Names Re-enumerated I ran cutover in the correct order twice, and both produced instances that would not boot (a UEFI shell reboot loop). The job log showed no abnormal events, and the status was `COMPLETED`. Examining the boot EBS volume of an unbootable instance, **the 8 GiB boot volume held the contents of a 4 GiB data disk.** The boot and data disk assignment had been swapped. The cause: when the source was stopped and restarted as part of the test, **NVMe device names were re-enumerated and the boot disk moved from`/dev/nvme0n1` to `/dev/nvme1n1`**. MGN's staging-type assignment appears to be keyed on the device name, and it is not re-evaluated after the name moves. The official best practices say not to restart the source before cutover in the first place. If a restart does happen, check the disk assignment with a command like the one below and redo the test launch. # Check which device is treated as the boot disk, and its assignment aws mgn get-replication-configuration --source-server-id "$SRC" \ --query 'replicatedDisks[?isBootDisk==`true`].[deviceName,stagingDiskType]' --output table ### 3. No Repair API, and Three Contradicting Errors I called `UpdateReplicationConfiguration` to fix the disk assignment, but whatever parameters I passed, it returned contradicting errors, and the API could not fix it. In the end I deleted the source server and reinstalled the agent, which turned out to be unnecessary: rerunning the installer is the documented procedure. Rerunning the installer re-establishes the list of replicated disks and their mapping against the actual machine. To avoid losing launch template customizations, try rerunning the installer before deleting anything. ### 4. The Installer's Hint Did Not Match the Real Cause When the agent installation failed, the installer displayed `Are kernel linux headers installed correctly?`. Reading the log closely, the real cause was lack of space in `/tmp`. On Amazon Linux 2023, `/tmp` is tmpfs; on a t3.small it has only 955 MiB, which does not meet the installer's requirement (1 GB or more free). sudo env TMPDIR=/var/tmp/mgn-build TEMP=/var/tmp/mgn-build TMP=/var/tmp/mgn-build \ ./aws-replication-installer-init --region ap-northeast-1 --no-prompt Pointing it at `/var/tmp` like this works around it. The installer's hint is not necessarily the real cause, so check the error code in the log. ## Teardown Checklist Finalize does not finish the clean-up. The correct teardown order for leaving nothing behind is as follows (steps 1–7 depend on each other). 1. Terminate the target and source EC2 instances 2. Delete the MGN source server 3. Reject the VPC endpoint connection, then delete the endpoint service 4. **Delete the NLB and its target group (important: charges continue until you delete them by hand)** 5. Delete the target FlexVol with `fsx delete-volume` 6. Delete the SVM with `fsx delete-storage-virtual-machine` 7. Delete the ONTAP `security login` The staging EBS volumes are deleted automatically with a delay, but the target's root EBS volume has no `DeleteOnTermination` and must be deleted manually. ## Initializing AWS Transform from the CLI: Create the IAM Roles First If running `aws mgn initialize-service` from the API or CLI fails, the cause is that the IAM roles have not been created. Initializing from the console creates the IAM roles for you, but on the CLI path you need to create eight roles (including `AWSApplicationMigrationFsxProxyRole` for FSx for ONTAP) and attach their policies first. ## Closing With this GA, a migration now finishes with the data area already on FSx for ONTAP as iSCSI LUNs, and the step of moving the data afterwards is gone. Any server whose boot and data are separate fits the same shape, whatever the original storage. On the other hand, watch for the configuration spanning two kinds of storage, the physical capacity spike during Finalize, and MGN-specific traps such as "a job status of COMPLETED does not mean the final sync succeeded". I hope this test record helps anyone migrating servers with separate boot and data to EC2 while considering FSx for ONTAP as the home for the data area. ## Resources * AWS What's New: AWS Transform announces general availability of Amazon FSx for NetApp ONTAP support * MGN: FSx for ONTAP configuration * MGN: Best practices for AWS Transform MGN * FSx for ONTAP: Using Amazon Elastic VMware Service with FSx for ONTAP * Verification report (GitHub): the test environment configuration, the measured teardown procedure, and the list of feedback sent to AWS, all omitted from this article All test environments have been deleted. The figures are single measurements under a specific environment and conditions, and vary with data size and configuration. The configuration details are in the verification report above. _This article is Part 2 of the series "The Data Foundation for AWS Modernization." The Japanese original is on hatenablog._

Introduction What comes "next" for VMware workloads? Hardly a day goes by without the...

## 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. _(dark theme)_ > 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" above does not mean the limit goes away. This series has not measured it yet, but verification in a sibling project (F-1 iSCSI measurement and others) has shown the following. 1. **Simple arithmetic between session count and bandwidth misses** Estimating "required bandwidth ÷ 625 MBps = number of sessions" misses in both directions. One TCP connection came out at 1.82x the prediction and sixteen at 0.20x, so the ceiling is not set by the capacity of a single flow alone. 2. **The performance gap between protocols (iSCSI vs NVMe/TCP) depends on the deployment** Measured on the same file system, iSCSI and NVMe/TCP were 0.06% apart — practically the same — while on other configurations their order swapped. Quoting a past ratio as the basis for a protocol choice is unsafe. 3. **ANA multipath is not available on Amazon Linux 2023** `CONFIG_NVME_MULTIPATH` is unset in all three AL2023 kernel series (details). The ANA path makes a large difference to sequential reads, so verifying it enabled needs a different distribution (RHEL 9.3 or similar). _These values come from tests against a raw device and include burst; they do not apply directly to this configuration, which puts a file system on the LUN._ ## Choosing a Migration Tool Even when the destination is "EC2 + FSx for ONTAP," the tool depends on the environment. Condition | Candidate tool | Notes ---|---|--- You want the data volumes on FSx for ONTAP (whatever the source storage is) | **AWS Transform (MGN)** | Set FSx for ONTAP as the target storage type. Generally available since 30 August 2026. Boot is always Amazon EBS. Verified hands-on in Part 2 Already on an ONTAP NFS datastore + small to medium scale | **NetApp Shift Toolkit** | Converts disks without copying them, using FlexClone. EC2 / FSx for ONTAP support is Early Preview. Verified hands-on in Part 4 Already on ONTAP + large scale (100+ VMs) | **Cirrus Migrate Cloud** | YAML-driven automation. Paid, through AWS Marketplace Migration planning and sizing only | **AWS Application Discovery Service** / **AWS Migration Evaluator** | Inventory collection and cost estimation. AWS native ### Where NetApp Shift Toolkit Fits Shift Toolkit converts VMs on an ONTAP NFS datastore without copying their disks. Conversion is done with FlexClone and metadata operations, so the conversion itself is quick. Migrations from VMware ESXi to Hyper-V, OpenShift Virtualization, Proxmox VE and OLVM are GA today, and **support for VMware ESXi → Amazon EC2 / FSx for ONTAP is at the Early Preview stage**. > ⚠️ Early Preview note: The current scope is configurations that place data disks on FSx for ONTAP. Specifications and constraints may change. ## What This Series Covers Starting from migration as the entry point, the series runs four parts through to the modernization beyond it. Parts 2 and 4 are the two migration paths; Part 3 is the modernization that follows. Part | Theme | Status | Source storage ---|---|---|--- Part 2 | AWS Transform Now Supports Block Storage Migration to FSx for ONTAP — Benefits and Pitfalls from a Hands-On EC2 Test | GA (30 August 2026) / verified hands-on | Any Part 3 | Beyond the AWS migration of a VMware environment: serverless, cloud-native, and the data foundation (ECS / EKS, S3 Access Points, DR) | Upcoming | — Part 4 | NetApp Shift Toolkit | EC2 / FSx for ONTAP support is Early Preview / verified hands-on | An ONTAP NFS datastore Of the two migration paths, AWS Transform is already GA and applies more widely, so the one a reader can try today (Part 2) comes first. Shift Toolkit (Part 4), which builds on existing ONTAP assets, comes later because its EC2 support is Early Preview. Part 3 sits between them and covers how to provide the data foundation when migrated workloads are reshaped into containers and serverless. Across the parts, we plan to cover: 1. **Environment setup** : Design and build of VPC + FSx for ONTAP + VPN 2. **Migration** : Migrating Linux / Windows VMs to EC2 3. **Modernization** : Containerization on ECS / EKS, Fargate with S3 Access Points, DR and cyber resiliency 4. **Operational continuity** : Snapshot / Clone / SnapMirror behavior after migration 5. **Cost comparison** : TCO against an EBS-only configuration ## Summary * Migrating from VMware is not only about "where to go" but about "how to carry the storage operations model forward". * For ONTAP users, FSx for ONTAP is a strong option for keeping, and making full use of, the value of ONTAP on AWS. * Choose the tool by source storage and scale. If the source storage does not matter, AWS Transform (MGN); for ONTAP NFS datastores at small to medium scale, Shift Toolkit. * Shift Toolkit's EC2 support is at the Early Preview stage, so those verification results may change at GA. The next article (Part 2) covers the AWS Transform (MGN) path that sets FSx for ONTAP as the target storage, verified hands-on after GA. Part 3 covers the modernization beyond migration (serverless and cloud-native), and Part 4 explains how Shift Toolkit works — how FlexClone changes VM migration. ## Reference Links * AWS for VMware — Comprehensive Pathways * AWS Transform for VMware * AWS What's New: AWS Transform announces general availability of Amazon FSx for NetApp ONTAP support * MGN: FSx for ONTAP configuration * Nutanix Blog: NetApp and Nutanix Announce Technical Partnership * AWS for VMware Partner Offerings (ROSA, NC2) * NetApp Shift Toolkit Overview * AWS Storage Blog: Seamless migration from VMware to FSx for ONTAP and EC2 * AWS Storage Blog: Expedite VMware migration to Amazon EC2 and Amazon FSx for NetApp ONTAP using the BlueXP workload factory migration advisor * Amazon FSx for NetApp ONTAP * Amazon Elastic VMware Service (EVS) * Red Hat OpenShift Service on AWS (ROSA) * Nutanix Cloud Clusters on AWS (NC2) * AWS VMware Migration Accelerator * NetApp Blog: Simplify VM migration with Shift Toolkit _This article is Part 1 of the series "The Data Foundation for AWS Modernization." The Japanese original is on hatenablog. Shift Toolkit's EC2 support is Early Preview, and its specifications are subject to change._