View a markdown version of this page

FSx for ONTAP configuration guide - AWS Transform MGN
OverviewPrerequisitesStep 1: Configure security groupsStep 2: Create FSx for ONTAP file systemStep 3: Configure certificate-based authenticationStep 4: Store certificates in AWS Secrets ManagerStep 5: Configure MGN replication settingsStep 6: Configure launch template and launch settingsStep 7: Enable volume integrity validation (recommended)Post-migration optimization

NEW - You can now accelerate your migration and modernization with AWS Transform. Read Getting Started in the AWS Transform User Guide.

FSx for ONTAP configuration guide

Overview

Note

This feature is available as a Public Preview.

This guide provides step-by-step instructions for configuring Amazon FSx for NetApp ONTAP (FSx for ONTAP) as a migration storage target for AWS Transform MGN (MGN) when migrating to AWS. With this setup, you can use the enterprise file storage capabilities of FSx for ONTAP for your migrated workloads. This guide assumes that you are familiar with FSx for ONTAP. For detailed FSx for ONTAP setup instructions, see the FSx for ONTAP Getting Started Guide.

FSx for ONTAP as a target storage type is available in all commercial AWS Regions where both MGN and FSx for ONTAP are available. This storage type is not available in AWS GovCloud (US) Regions, China Regions, or Local Zones.

When you select FSx for ONTAP as the target storage type:

  • All data volumes from a source server are stored on FSx for ONTAP. The boot volume is always stored on Amazon EBS. For more information, see Root volumes for Amazon EC2 instances.

  • If you are migrating from an existing ONTAP storage system, source ONTAP configurations (such as access permissions, quotas, snapshot policies, and schedules) are not migrated automatically. You must reconfigure these settings on the target FSx for ONTAP file system after migration.

Prerequisites

Before integrating FSx for ONTAP with MGN, ensure the following:

  • MGN Setup: MGN initialized in your AWS account with agent-based replication.

    Important

    If you initialized MGN before FSx for ONTAP support was available, you must reinitialize the service to create the required AWS managed roles (AWSApplicationMigrationFsxProxyRole and AWSApplicationMigrationFsxProxyLinkRole). In the MGN console, navigate to Getting started and choose Reinitialize. Without these roles, FSx for ONTAP target storage will not function.

  • VPC Configuration: FSx for ONTAP and MGN instances must be in the same AWS account and Region. They can use the same VPC or different VPCs with proper network connectivity (VPC peering, Transit Gateway, or other connectivity methods). IPv4 connectivity is required. As a best practice, deploy FSx for ONTAP and the target EC2 instances in the same Availability Zone to minimize latency and avoid cross-AZ data transfer costs.

  • Staging area subnet access: The staging area subnet must have outbound access to OS package repositories (for example, through a NAT gateway or internet gateway). MGN replication servers are created on demand in this subnet and require network access to install iSCSI and multipath packages.

  • iSCSI and multipath packages: MGN requires iSCSI initiator and multipath tools on the target instance to connect to FSx for ONTAP. MGN attempts to install these packages automatically during launch using the OS package manager. If the target instance does not have network access to OS package repositories (for example, in air-gapped environments or private subnets without a NAT gateway), or if the operating system uses subscription-based repositories (SUSE, RHEL, CentOS), you must pre-install the packages on the source server before migration. For the required packages by operating system, see Step 6: Configure launch template and launch settings and the Supported Linux operating systems table.

  • iSCSI and multipath packages for subscription-based operating systems: For SUSE (SLES), RHEL, and CentOS source servers, you must pre-install iSCSI and multipath packages on the source server before migration. These operating systems use subscription credentials tied to the source instance that are not valid on the migrated target. See the prerequisites in the Supported Linux operating systems table for the specific commands.

Step 1: Configure security groups

To enable MGN to work with FSx for ONTAP, you must create two security groups that cross-reference each other:

  • MGN-Instances-SG – Attached to the EC2 instances that MGN launches (test and cutover). Allows outbound traffic to the FSx for ONTAP file system on iSCSI (port 3260) and HTTPS (port 443).

  • FSx-ONTAP-SG – Attached to the FSx for ONTAP file system. Controls three types of inbound traffic: (1) iSCSI (port 3260) from MGN-Instances-SG for migration data, (2) optional SSH (port 22) and HTTPS (port 443) from MGN-Instances-SG for management access, and (3) HTTPS (port 443) from the FSx for ONTAP preferred and standby subnet CIDRs, required for MGN to access the ONTAP REST API during replication and launch.

Because FSx-ONTAP-SG references MGN-Instances-SG as the source in its inbound rules, only MGN-launched instances can reach the file system. All other traffic is denied by default.

1.1 MGN instances security group

Create this security group in the VPC where MGN will launch target instances.

Important

If you use different VPCs for replication and launch, create two security groups with distinct names for clarity. For example, use MGN-Replication-SG (in the staging VPC) and MGN-Launch-SG (in the launch VPC). The rules for both are identical.

Steps to create

  1. Navigate to the Amazon VPC Console → Security Groups → Create security group.

  2. Configure the following settings:

    • Security group name: MGN-Instances-SG

    • Description: Security group for instances launched by MGN to allow communication with FSx for ONTAP

    • VPC: Choose the target VPC where MGN will launch instances.

  3. Inbound Rules: Add any inbound rules as needed based on your application requirements (for example, RDP or SSH for management access). Replace Your admin CIDR with the IP address range from which your administrators connect (for example, your corporate VPN range or bastion host subnet CIDR).

    Type Protocol Port Range Source Description
    SSH TCP 22 Your admin CIDR Management access (Linux)
    RDP TCP 3389 Your admin CIDR Management access (Windows)
    Custom TCP TCP 1500 Source server CIDR Data replication from source servers

  4. Outbound Rules: The default outbound rule (All traffic → 0.0.0.0/0) is sufficient. If you restrict outbound rules, add at minimum the following rules. Reference the FSx for ONTAP security group (created in the next step) as the destination:

    Type Protocol Port Range Destination Description
    iSCSI TCP 3260 FSx-ONTAP-SG iSCSI access to FSx for ONTAP
    HTTPS TCP 443 FSx-ONTAP-SG ONTAP REST API / Management

  5. Choose Create security group.

1.2 FSx for ONTAP security group

You associate this security group with the FSx for ONTAP file system. Use this security group to control which resources can communicate with the file system and to ensure that MGN-launched instances have the necessary access.

Steps to create

  1. Navigate to the Amazon VPC Console → Security Groups → Create security group.

  2. Configure the following settings:

    • Security group name: FSx-ONTAP-SG

    • Description: Security group for FSx for ONTAP file system to allow inbound access from MGN-launched instances

    • VPC: Choose the target VPC used for the FSx for ONTAP file system.

  3. Inbound Rules: Add the following rules. The table is organized into two groups:

    • Migration traffic (iSCSI) – Required for MGN data replication and launch. Reference MGN-Instances-SG as the source.

    • Management access (SSH, HTTPS) – Optional rules for ONTAP CLI and REST API access from MGN-launched instances (for example, for troubleshooting or manual configuration). Reference MGN-Instances-SG as the source.

    • MGN service traffic (HTTPS) – Required for MGN to access the FSx for ONTAP REST API during replication and launch. Use the CIDR blocks of the preferred and standby subnets where the file system is deployed. You can find these CIDRs in the FSx for ONTAP Console under your file system's Network & security tab, or in the VPC Console → Subnets by looking up the subnet IDs.

    Type Protocol Port Range Source Description
    Migration traffic
    iSCSI TCP 3260 MGN-Instances-SG Allow iSCSI from MGN instances
    Management access (optional)
    SSH TCP 22 MGN-Instances-SG ONTAP CLI management from MGN instances
    HTTPS TCP 443 MGN-Instances-SG ONTAP REST API management from MGN instances
    MGN service traffic
    HTTPS TCP 443 FSx preferred subnet CIDR MGN access to ONTAP REST API
    HTTPS TCP 443 FSx standby subnet CIDR MGN access to ONTAP REST API

  4. Outbound Rules: The default outbound rule (All traffic → 0.0.0.0/0) is sufficient.

  5. Choose Create security group.

Step 2: Create FSx for ONTAP file system

If you do not already have an FSx for ONTAP file system, create one in the same AWS account and Region where MGN will launch target instances. Up to 5 FSx for ONTAP file systems are supported per account, each source server supports up to 63 data volumes, and MGN supports up to 10 snapshots per ONTAP volume.

High-level steps

  1. Navigate to the Amazon FSx for NetApp ONTAP Console and create a new FSx for ONTAP file system.

  2. Choose Standard create option.

  3. Choose deployment type (Multi-AZ for production, Single-AZ for testing).

  4. Configure storage capacity and throughput based on your workload requirements.

  5. Choose the VPC and subnets for FSx for ONTAP deployment.

  6. Choose FSx-ONTAP-SG security group created in 1.2 FSx for ONTAP security group.

  7. Configure FSx for ONTAP admin account and password.

  8. Configure a Storage Virtual Machine (SVM).

  9. Wait for the file system to reach Available status (approximately 30-45 minutes).

Important for MGN integration

  • For Multi-AZ deployments: you must specify an Endpoint IPv4 or IPv6 address range (not unallocated or floating). Use the "Enter an IPv4/IPv6 address range" option and provide a specific range (for example, 192.168.1.0/24). This is required for MGN integration to ensure consistent endpoint addressing.

  • Storage capacity: MGN uses FSx for ONTAP storage for replication, conversion, and cutover. These processes require temporary storage on the file system. Ensure that sufficient space is available on the FSx for ONTAP file system and increase capacity if needed. As a guideline, provision 3x the size of the planned migration data. The 3x factor accounts for three concurrent storage consumers during migration: the replicated data, the converted volumes used for launch, and the original volumes pending deletion. Volume deletion in FSx for ONTAP is a background operation — freed capacity is not available immediately after deletion, so headroom must be provisioned upfront. As a best practice, keep the file system at or below 80% SSD capacity utilization. You can decrease storage capacity after migration is complete. For more information, see Managing storage capacity and provisioned IOPS.

  • Throughput capacity: Higher throughput capacity reduces migration time. Throughput is selected from fixed tiers (for example, 256, 512, 1024, 2048, or 4096 MBps for Gen 1 file systems) and is a billable dimension — higher tiers increase cost. To size throughput for migration, sum the average read throughput and write throughput across all source servers being migrated to the file system, add 15% headroom, and round up to the next available tier. Plan your throughput tier before starting migration, as changes take time to take effect. You can reduce throughput after migration is complete. For more information, see Managing throughput capacity and FSx for ONTAP performance.

Disable Anti-Ransomware Protection (ARP)

If ONTAP ARP is enabled on the file system, disable it before migration. ARP can affect the split clone flow and MGN migration completion. For more information, see Enabling Anti-Ransomware Protection.

For detailed instructions on creating and configuring FSx for ONTAP file systems, see Creating FSx for ONTAP file systems.

Step 3: Configure certificate-based authentication

Certificate-based authentication is required for MGN to access the ONTAP REST API and iSCSI targets. MGN handles TLS validation internally using AWS Certificate Authorities.

Note

CHAP authentication for iSCSI targets is not supported. You must use certificate-based authentication as described in this section.

Create client certificate for API authentication

Generate a client certificate that FSx for ONTAP will require and MGN will use to authenticate to the ONTAP REST API. You have several options:

Certificate options
Option Use Case Documentation
Self-Signed Certificate Testing/Development Generate Self-Signed Certificate with OpenSSL
ACM Private CA Production (Recommended) Request a Private Certificate
External Certificate Authority Production (Enterprise PKI) Use your organization's CA process

Quick Start - Self-Signed Certificate:

For testing, create a self-signed certificate:

  1. Download the FSx for ONTAP certificate bundle (change the region in the URL):

    curl https://fsx-aws-certificates.s3.amazonaws.com/bundle-region.pem \
  -o bundle-region.pem

    See Managing resources using ONTAP applications for details.

  2. Create a Certification Authority (CA):

    # Generate CA private key
openssl genrsa -out ca.key 4096

# Create self-signed CA certificate
openssl req -new -x509 -key ca.key -out ca.crt -days 3650 \
  -subj "/CN=FSx-ONTAP-Client-CA/O=YourOrg/C=US" \
  -addext basicConstraints=critical,CA:TRUE \
  -addext keyUsage=critical,keyCertSign,cRLSign \
  -addext subjectKeyIdentifier=hash

  3. Generate a client key:

    openssl genrsa -out fsx-mgn-client.key 2048

  4. Create an openssl-client.cnf file:

    [ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = cert_usr
O  = YourOrg
C  = US

[ req_ext ]
keyUsage         = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectKeyIdentifier = hash

[ usr_cert ]
keyUsage         = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
authorityKeyIdentifier = keyid,issuer
subjectKeyIdentifier  = hash

  5. Create a new certificate signing request (CSR):

    openssl req -new -key fsx-mgn-client.key -out fsx-mgn-client.csr \
  -config openssl-client.cnf

  6. Sign the CSR with your CA:

    openssl x509 -req -in fsx-mgn-client.csr \
    -CA ca.crt -CAkey ca.key -CAcreateserial \
    -out fsx-mgn-client.crt -days 365 \
    -extfile openssl-client.cnf -extensions usr_cert

  7. Verify the certificate:

    openssl verify -CAfile ca.crt fsx-mgn-client.crt

For Production: Follow the ACM Private CA documentation to request and export a certificate with private key.

Required output files:

  • fsx-mgn-client.crt – Client certificate

  • fsx-mgn-client.key – Private key (PKCS#8 format)

The private key must be in PKCS#8 format (-----BEGIN PRIVATE KEY-----). If your key starts with -----BEGIN RSA PRIVATE KEY----- (PKCS#1), convert it:

openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt \
  -in fsx-mgn-client.key -out fsx-mgn-client.key

Install client certificate on FSx for ONTAP

Install the client certificate on the FSx for ONTAP to enable certificate-based authentication. For more information, see Installing certificates on ONTAP.

  1. Connect to the FSx for ONTAP file system's management endpoint with SSH (requires an EC2 instance that can SSH into FSx for ONTAP):

    ssh fsxadmin@file-system-management-endpoint-ip-address

  2. Install the client CA certificate:

    security certificate install -type client-ca \
  -vserver FsxIdYOUR_FS_ID -cert-name my-client-ca

# Paste the contents of ca.crt when prompted
# Press Enter when done

  3. Create the user with certificate authentication:

    security login create -vserver FsxIdYOUR_FS_ID \
  -user-or-group-name cert_usr -application http \
  -authmethod cert -role fsxadmin

    Verify login creation:

    security login show -vserver FsxIdYOUR_FS_ID \
  -user-or-group-name cert_usr

  4. Verify installation:

    security certificate show -vserver FsxIdYOUR_FS_ID -type client-ca

Test certificate-based authentication

You can run this test from any machine that has network access to the FSx for ONTAP management endpoint (for example, an EC2 instance in the same VPC or an on-premises host connected through Direct Connect or VPN).

# Test authentication using the certificate
# Use -k if testing with a self-signed certificate to skip server certificate validation
curl -sS --cacert bundle-region.pem \
     --cert fsx-mgn-client.crt \
     --key fsx-mgn-client.key \
     https://management.fs-xxxxx.fsx.region.amazonaws.com/api/cluster

Expected: JSON response with cluster information. If you see 401 Unauthorized, verify certificate installation and login creation.

Step 4: Store certificates in AWS Secrets Manager

Store the client certificate and private key in AWS Secrets Manager (Secrets Manager). MGN will retrieve these credentials using the Secret ARN.

Required secret format:

MGN expects the secret to contain exactly two keys:

  • cert: The client certificate content (fsx-mgn-client.crt)

  • key: The private key content (fsx-mgn-client.key)

Store using AWS Console:

  1. Navigate to Secrets Manager in the AWS Console.

  2. Choose Store a new secret.

  3. Choose Other type of secret.

  4. Add key-value pairs with exact key names as key/value (not plain text):

    • cert – content of your fsx-mgn-client.crt

    • key – content of your fsx-mgn-client.key

  5. Choose Next.

  6. On the Configure secret page, under Tags, add a tag with key AWSApplicationMigrationServiceManaged and value True.

  7. Choose Next → Store.

  8. Copy the Secret ARN – you need this for MGN configuration.

Important

  • Use cert (not certificate).

  • Use key (not private_key).

  • Do NOT include a username field.

Example Secret ARN:

arn:aws:secretsmanager:us-east-1:123456789012:secret:mgn/fsx/ontap-api-certificate-AbCdEf

Step 5: Configure MGN replication settings

Configure MGN to use the FSx for ONTAP REST API certificate stored in Secrets Manager.

Configure replication template by using the AWS Console

Important

Changing the storage provider for a source server that is already replicating terminates current replication and restarts the replication process from the beginning.

Note

FSx for ONTAP is supported with agent-based replication only. Agentless replication is not supported.

  1. Navigate to MGN console.

  2. Under Settings, choose Replication template.

  3. Choose Edit.

  4. Choose the required target subnet (subnet that can communicate with FSx for ONTAP).

  5. Choose FSx for ONTAP configuration.

  6. Enter the following configuration:

  7. Choose an additional security group created for AWS FSx for ONTAP (the one created for iSCSI in 1.1 MGN instances security group).

  8. Choose Save changes.

Note

Migration Acceleration Program (MAP) 2.0 tags are applied to the FSx for ONTAP file system but not to individual FSx for ONTAP volumes.

Step 6: Configure launch template and launch settings

The target instance must establish iSCSI connectivity to the FSx for ONTAP SVM over the network.

Requirements:

  • Choose the required target subnet (subnet that can communicate with FSx for ONTAP).

  • Modify the source server's launch template to include the security group that you configured for iSCSI traffic (port 3260) to the FSx for ONTAP file system (see Step 1: Configure security groups).

  • Ensure that target instances have network access to OS package repositories. MGN automatically installs iSCSI initiator and multipath tools using the OS package manager during migration.

    Required packages by package manager (Linux)
    Package Manager Packages Installed
    dnf (Fedora/RHEL 8+) iscsi-initiator-utils, device-mapper-multipath
    yum (RHEL 6/7, CentOS, Amazon Linux) iscsi-initiator-utils, device-mapper-multipath
    apt-get (Debian/Ubuntu) open-iscsi, multipath-tools
    zypper (SLES/openSUSE) open-iscsi, multipath-tools

    On Windows, the iSCSI initiator (MSiSCSI service) is a built-in service that is enabled and started automatically. Only Multipath-IO needs to be enabled:

    Required features (Windows)
    Method Feature Enabled
    Install-WindowsFeature (Server 2012+) Multipath-IO
    Add-WindowsFeature (Server 2008 R2) Multipath-IO

Step 7: Enable volume integrity validation (recommended)

Enable the Volume integrity validation post-launch action to automatically verify iSCSI connectivity and multipath mount configuration after each test or cutover launch. For FSx for ONTAP migrations, this action validates that all expected iSCSI volumes are connected, mounted, and accessible through multipath.

To enable this action, see Post-launch settings.

Post-migration optimization

After successful cutover, optimize your FSx for ONTAP deployment for ongoing operations.

Configure backup strategy

After migration, verify that your FSx for ONTAP backup strategy covers the migrated data. Review automatic backup settings and retention policies for your file system, and confirm that migrated volumes are included in your backup schedule. For more information, see Working with backups.

Re-enable Anti-Ransomware Protection (ARP)

If you disabled ONTAP ARP before migration, re-enable it after cutover is complete. For more information, see Enabling Anti-Ransomware Protection.

Configure storage efficiency

Enable deduplication and compression on FSx for ONTAP volumes:

# Connect to FSx for ONTAP file system (cluster admin)
ssh fsxadmin@svm-xxxxx.fsx.amazonaws.com

# Enable storage efficiency on volumes
volume efficiency on -vserver svm-mgn-migration -volume vol_*

# Enable compression
volume efficiency modify -vserver svm-mgn-migration -volume vol_* -compression true

# Enable deduplication
volume efficiency modify -vserver svm-mgn-migration -volume vol_* -inline-deduplication true

Implement data tiering

Configure snapshot tiering to move snapshot data to the lower-cost capacity pool tier while keeping active block workload data on the performance tier:

# Set snapshot-only tiering policy on volumes
volume modify -vserver svm-mgn-migration -volume vol_* -tiering-policy snapshot-only

# Set minimum cooling days (default: 31 days)
volume modify -vserver svm-mgn-migration -volume vol_* -tiering-minimum-cooling-days 31