AWS Backup now copies FSx for ONTAP backups across Regions and accounts — a new option, measured Tokyo to Osaka

Introduction

How do you approach disaster recovery and backup for your file systems on AWS? Take FSx for ONTAP and a pair of Japanese Regions as the example: if Tokyo is primary, standing up a file system in Osaka and replicating into it continuously with SnapMirror is probably the first shape that comes to mind for anyone who has run ONTAP, or is about to evaluate it. Plenty of AWS users run exactly that in production, and as a way to hold availability it is still the best answer. RPO comes down from the 60 minutes AWS Backup offers at its shortest to SnapMirror's 5-minute minimum interval, switching between active and standby is breaking the relationship and promoting the destination, and cutting data back the other way is a snapmirror resync in the reverse direction.

The trouble was that "I just want the data sitting on the DR side, without operating a file system there until I actually restore" required the same shape. Amazon FSx for NetApp ONTAP volume backups were created and restored inside the file system's own Region and account, and could not cross a Region boundary. AWS Backup could already copy backups across Regions and accounts for FSx for Windows File Server, FSx for OpenZFS, and FSx for Lustre (AWS Backup extends Amazon FSx support to 5 additional AWS Regions and expands cross-Region and cross-account copy to 14 AWS Regions, April 2026), but FSx for ONTAP was not in that set at the time.

Then on 27 August 2026 that gap closed along the two paths below. One more shape became available to choose from in a backup strategy. The two were announced separately.

• Amazon FSx for NetApp ONTAP now supports copying backups across AWS Regions and accounts
• AWS Backup adds cross-Region and cross-account backup support for Amazon FSx for NetApp ONTAP

Path	What it does	Scheduling	Cross-account
FSx for ONTAP backup copy (CopyBackup)	Copies a volume backup to another Region	None. Run it each time	No. Same account only
AWS Backup (policy-based backup management service)	Copies FSx for ONTAP backups to another Region and another account	Yes. Copy rules in a backup plan	Yes. Requires AWS Organizations

So I copied a backup from Tokyo to Osaka, restored it at the destination, and confirmed the content matched. This post covers that procedure, along with the design and operational considerations that came with it.

Up front:

• AWS Backup now copies FSx for ONTAP backups to another Region and another account (27 August 2026). The FSx for ONTAP CopyBackup also reaches another Region, but it is same-account and manual.
• Moving them to another account needs a CMK. AWS managed keys cannot be used for a cross-account copy, and a file system's KMS key is set at creation — so it is a decision made before the file system exists (below).
• What matters is that you no longer need a file system at the destination until you recover. The restore target is still the Region the backup lives in, so creating that file system at recovery time lands on your RTO — 20 minutes, measured (below).
• CopyBackup has no scheduler. Recurring copies mean an AWS Backup backup plan or your own automation. The AWS Backup copy and restore were measured too — 6 m 31 s to 8 m 35 s to copy, 16 m 16 s to restore, at 9 MB.
• This does not replace SnapMirror. If a minutes-level RPO and a failback procedure are requirements, SnapMirror still is the answer. Replication and copy are different operations and leave different things at the destination (below).
• Restore time is proportional to capacity. My 13 minutes was a figure for 9.4 MiB. Restoring 10 TB on a minimum configuration is 22 hours at the floor, calculated from AWS published rates. I could not find a measured figure at 10 TB or above in public sources (below).
• Cost inverts with scale. A Single-AZ capacity pool is 47.6% of backup storage ($0.0238 against $0.050, retrieved from the Price List API), so past roughly 4.8 TB a standing destination file system is lower monthly. Choosing to keep one running is not choosing the more expensive option (below).

Scope: within one account, copying a volume backup from ap-northeast-1 to ap-northeast-3, restoring it into a file system there, and verifying the content. Both CopyBackup and AWS Backup were measured.

Out of scope: cross-account copies (they require AWS Backup with AWS Organizations — I show the shape but did not measure it), building or failing back a SnapMirror relationship, durations at production data volumes, and reconciling inter-Region transfer charges against a bill.

---

Shape of the setup

(Dark theme: [e-mail])

The right-hand side being empty in normal operation is the whole point. With SnapMirror, that right-hand side holds an equivalent file system at all times.

Layer	Day to day	When recovering
Tokyo (production)	file system + RW volume + backups	unchanged, or lost if the Region is affected
Osaka (destination)	the backup copy only. No file system	file system → SVM → restore into a new volume
Billing	Osaka pays backup storage only	Osaka's file system starts billing once it exists
Running the copy	CopyBackup each time, or an AWS Backup copy rule	—

On vendor neutrality: this post evaluates FSx for ONTAP backup copies on technical grounds only. The section on existing backup products touches other options, but not in a framing where one is better than another. Each suits a different context, and the goal here is to record what actually works and what does not.

---

Test environment

Item	Value
Date	2026-08-28 (CopyBackup path), 2026-08-29 (AWS Backup path)
Runs	One per step (n=1). Variance was not measured
Interface	AWS CLI v2 and the AWS Management Console. Japanese locale for the CopyBackup path, English locale for the AWS Backup path (the setting at capture time). CloudFormation untested
Source	ap-northeast-1, first-generation SINGLE_AZ_1, 1,024 GiB SSD, 128 MBps
Destination	ap-northeast-3, same shape, created for this test
ONTAP version	9.17.1P7D1
Source volume	FlexVol RW, 1 GiB, tiering NONE, storage efficiency off
Dataset	5 files / 9.4 MiB (nested directory, symlink, UTF-8 filename, one file at 0640). The AWS Backup run used an equivalent 9,458,747 B set
AWS Backup	one vault per Region, one backup plan (one rule, one copy rule), selection scoped to the single verification volume ARN, existing AWSBackupDefaultServiceRole
KMS	Defaults in each Region: aws/fsx for the source file system, alias/aws/backup (KeyManager: AWS) for the AWS Backup vaults. CMKs untested, and this configuration cannot do a cross-account copy (below)
Clients	one t3.micro (AL2023) per Region, NFS
Actual spend	~$0.55 for the CopyBackup run (destination file system ran 1 h 24 m); under $2 for the AWS Backup run (destination file system ran ~1 h 21 m, two t3.micro)
Data used	Synthetic data from /dev/urandom. No real or personal data
Not verified	Cross-account copies (covered by the earlier post), CMKs, copying AUTOMATIC backups, incrementality, residue from a failed copy, deploying the CloudFormation template, restoring into an AD-joined SVM, reconciling inter-Region transfer charges, AWS Backup restore testing

Do not use these durations as an RTO basis for your environment. They are measured against 9.4 MiB, where fixed overhead dominates.

---

When this fits

• You want a copy of your data in another Region but want to avoid running a file system there
• Compliance requires retaining a copy that is logically separated from production
• You want an isolated-account layer against credential compromise or a KMS key compromise
• Recovery measured in tens of minutes to hours is acceptable
• You already take volume backups and only want to add a destination for them
• SnapMirror already covers availability, and you want a separate retention layer detached from production

When to look at something else for now

• RPO in minutes is required (the guidance figure for backups is 60 minutes)
• RTO in single-digit minutes is required (creating the destination file system took 20 minutes)
• You need a documented path back to production (backup copies have none — see below)
• FlexGroup volumes are in scope (copy is unsupported, and creation failed in my environment — see below)
• You need copies spanning China Regions, or cross-account copies in the China Regions (unsupported)

If any of those apply, a SnapMirror-based design fits the requirement better. Running both together is also coherent, covered below.

---

The distinction that matters most — what changed is where a backup can live

Blur this and the runbook comes out wrong.

Claim	Status
A backup can be stored in another Region	now possible (CopyBackup or AWS Backup)
A backup can be stored in another account	now possible, but only through AWS Backup. The FSx for ONTAP CopyBackup stays inside one account
A backup can be restored to a file system in a different Region than the backup	no (unchanged)
A restore produces a new volume	unchanged. There is no restore-in-place path

using-backups.html still states that a backup can only be restored to a file system in the Region where the backup is stored. That is not a contradiction — copying increases the set of Regions where a backup is stored.

So recovery in Osaka is three steps:

1. A copied backup is already in Osaka (this is what you prepare in advance)
2. Create a file system and an SVM in Osaka
3. Restore as a new volume

Step 2 lands on your RTO. Not paying for a standby file system means paying for its creation when you need it. That is the trade you are choosing.

---

How CopyBackup and AWS Backup relate

Two different things are called "copy a backup to another Region" here, so it is worth separating them first. They are separate mechanisms. Neither calls the other, and their control planes and storage locations differ.

	FSx for ONTAP CopyBackup	AWS Backup
Whose API	Amazon FSx (fsx:CopyBackup)	AWS Backup (backup plans / copy jobs)
What it copies	An existing FSx for ONTAP volume backup, which must be AVAILABLE	A recovery point AWS Backup took itself
Where the copy lands	As an FSx for ONTAP backup in the destination Region	An AWS Backup backup vault
BackupType	USER_INITIATED	AWS_BACKUP
Scheduling	None. Called each time	Yes. Backup rules and copy rules
Cross-account	No	Yes, with AWS Organizations
Link back to the source	Keeps SourceBackupId and SourceBackupRegion	Followed through the recovery point ARN

Here is where the two get conflated. You cannot point CopyBackup at an AWS Backup backup vault, and an AWS Backup copy rule does not call fsx:CopyBackup on your behalf. Answering "I want CopyBackup on a schedule" with "use AWS Backup" is right not because the same call can be scheduled, but because the same goal is reachable through a different mechanism.

The restore constraint, on the other hand, is shared. Both paths ask you to pick an existing file system and SVM in the destination Region and both produce a new volume. The AWS Backup restore screen asks for a File system and a Storage virtual machine too (documented). So the benefit — no standby file system while nothing is wrong — holds for AWS Backup as well, and so does the cost: file system creation lands on the RTO either way.

On terminology: AWS Backup's own word is copy. How that differs from replication is the next section.

---

Replication and copy are different words for different things

Two words get used for "keep the data in another Region": replication and copy. They are different operations, and what sits at the destination differs. Without agreeing on that, a requirements conversation goes past itself.

	SnapMirror replication	AWS Backup / CopyBackup copy
What sits at the destination	A volume. A DP volume exists on the destination SVM	A backup (recovery point). No volume
When the source changes	It follows. Deltas are sent each schedule	It does not. A point-in-time image; later changes wait for the next backup
To use the destination	Break the relationship and promote it to become writable	A restore is required, and what you get is a new volume
Does the relationship persist	Yes. Having it in place is the normal state	No. Each copy is an independent artefact
What sets the RPO	The replication schedule (down to 5 minutes)	The backup interval (guidance: 60 minutes)
What the destination costs while idle	File system capacity and throughput	Backup storage only
Path back to production	snapmirror resync in the other direction	There is none

AWS's own wording splits the same way. The AWS Backup console and documentation call this operation copy throughout — the screens read Copy jobs, Copy rule, Copy type: Manual (screenshots above). The FSx for ONTAP API is named CopyBackup. Replication is the word for mechanisms where the destination exists and tracks the source, as in Amazon S3 Cross-Region Replication.

So "replicate cross-Region with AWS Backup" reads as though a volume at the destination is tracking the source. There isn't one. What is at the destination is a recovery point, and using it takes a restore. The difference lands directly on the RTO: replication promotes a volume that is already there, while a copy starts from creating a file system and an SVM and then restoring.

The reverse mistake is calling SnapMirror a backup. The destination tracks the source, so a file deleted on the source is gone from the destination's current state after the next transfer — what remains is whatever the destination's snapshots still hold. Retaining generations is the job of snapshots or SnapVault, not of the replication itself.

SnapVault is a third mechanism. ONTAP's SnapVault is a relationship that accumulates generations at the destination. It rides the same transport as SnapMirror with a different purpose. The backup copies in this post do not create an ONTAP SnapVault relationship.

Which one suits which requirement is in choosing between this and SnapMirror.

---

A short glossary

Only the terms this post uses. Skip if you already know them.

Term	What it is	Why it matters here
File system	The billing and performance unit. SSD capacity and throughput are provisioned here	This is what you no longer need at the destination
SVM (Storage Virtual Machine)	A logical server inside a file system, holding the NFS / SMB endpoints and auth config	Required to restore. A file system alone is not enough
Volume	Where data lives, and the unit of backup and restore	A restore produces a new volume
Junction path	Where a volume attaches in the SVM namespace (e.g. /dr_restored); the NFS mount path	Specified at restore
FlexVol / FlexGroup	Volume styles. FlexVol sits on one aggregate; FlexGroup spreads across several for capacity and parallelism	FlexGroup backup copies are unsupported
RW / DP	Volume type. RW is read-write, DP is read-only and used for SnapMirror destinations	DP cannot be backed up. A restoring volume transiently reads as DP
Tiering	Moving cold data from SSD to the cheaper capacity pool. NONE / AUTO / SNAPSHOT_ONLY	Affects read latency right after a restore
Snapshot vs backup	A snapshot lives inside the file system; a backup is an independent copy outside it	Only the backup can cross a Region boundary

If you run ONTAP on-premises

ONTAP concept	Relationship to this capability
SnapMirror	A different mechanism. Needs cluster peering and a standing destination file system
SnapVault	A different mechanism. Backup copies do not create a SnapVault relationship
Cluster peering	Not required for backup copies. Operationally this is the largest difference from SnapMirror
Driving it from ONTAP CLI / REST	Backup copies are an AWS-side feature with no corresponding ONTAP CLI command. Use the AWS CLI, API, or console
Trace left on the volume	A backup leaves a snapshot named backup-<backup-id> on the volume

---

Prerequisites and permissions

Prerequisites

Item	Condition
Source backup	must be AVAILABLE
Source volume type	RW (DP, LSM, and FlexCache destinations cannot be backed up at all)
Volume style	FlexVol. FlexGroup copies are unsupported
Partition	Between commercial Regions, between the two China Regions, and between the two GovCloud (US) Regions — but not across those sets
KMS	Encrypted with a key in the destination Region. No parameter needed if the default key is fine

A backup whose source volume has already been deleted can still be copied (measured). That is useful after an accidental deletion.

IAM

The requester must be able to reach the backup in the source Region. Following the shape in the AWS documentation:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CopyBackupAcrossRegions",
      "Effect": "Allow",
      "Action": "fsx:CopyBackup",
      "Resource": "arn:aws:fsx:*:<your-account-id>:backup/*"
    },
    {
      "Sid": "DescribeAndRestore",
      "Effect": "Allow",
      "Action": [
        "fsx:DescribeBackups",
        "fsx:DescribeFileSystems",
        "fsx:DescribeStorageVirtualMachines",
        "fsx:DescribeVolumes",
        "fsx:CreateVolumeFromBackup",
        "fsx:TagResource"
      ],
      "Resource": "*"
    }
  ]
}

The "Resource": "*" on the second statement is a simplification for readability. Narrow it in production. Some Describe* actions do not support resource-level scoping, but fsx:CreateVolumeFromBackup can be limited to the destination file system and SVM ARNs. To pin the destination Region, use the aws:RequestedRegion condition key:

{
  "Sid": "RestrictCopyDestination",
  "Effect": "Deny",
  "Action": "fsx:CopyBackup",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["ap-northeast-3"] }
  }
}

If you have a data residency requirement, put this guard in IAM or an SCP. "We have a rule that says not to" does not hold.

With a customer managed key (CMK), you will additionally need permissions such as kms:CreateGrant and kms:DescribeKey on the destination-Region key. I used the default key, so I have not verified this. If you are building on a CMK, prove it with a small volume first.

---

Values to replace with your own

Every command below works once you substitute these.

Placeholder	Meaning	How to get it
<SRC_REGION>	Source Region	e.g. ap-northeast-1
<DST_REGION>	Destination Region	e.g. ap-northeast-3
<SRC_VOLUME_ID>	The RW volume to back up	aws fsx describe-volumes --region <SRC_REGION> --query 'Volumes[?OntapConfiguration.OntapVolumeType==RW].[VolumeId,Name]' --output table
<SRC_BACKUP_ID>	The backup to copy	output of step 1
<DST_SUBNET_ID>	Subnet for the destination file system	aws ec2 describe-subnets --region <DST_REGION> --query 'Subnets[].[SubnetId,AvailabilityZone,CidrBlock]' --output table
<DST_SG_ID>	Security group for the destination file system	Must allow NFS / SMB. Sharing one SG with the client plus a self-referencing rule is enough
<DST_FS_ID>	Destination file system	output of step 4
<DST_SVM_ID>	Destination SVM	output of step 5
<DST_VOLUME_SIZE_BYTES>	Restored volume size, in bytes	Must be at least the data in the backup. Reusing the source SizeInBytes is safest. 1 GiB = 1073741824

Two notes on sizing. The destination file system's SSD capacity must exceed the data being restored — restored data is written to SSD first. And a FlexVol cannot span more than one HA pair. For a large volume, settle the destination SSD capacity and generation (second-generation Single-AZ can add HA pairs) before you start.

---

Walkthrough — Tokyo to Osaka

1. Create a backup (skip if you already have one)

aws fsx create-backup \
  --region <SRC_REGION> \
  --volume-id <SRC_VOLUME_ID> \
  --tags Key=Name,Value=dr-source Key=Purpose,Value=cross-region-copy \
  --query 'Backup.{Id:BackupId,Life:Lifecycle}' --output table

Wait for AVAILABLE:

aws fsx describe-backups \
  --region <SRC_REGION> --backup-ids <SRC_BACKUP_ID> \
  --query 'Backups[0].{Life:Lifecycle,Pct:ProgressPercent}' --output table

2. Copy it

--region is the destination; --source-region is where the backup is now. This reads backwards at first — the copy is requested against the destination Region.

aws fsx copy-backup \
  --region <DST_REGION> \
  --source-backup-id <SRC_BACKUP_ID> \
  --source-region <SRC_REGION> \
  --copy-tags \
  --tags Key=Name,Value=dr-copy \
  --query 'Backup.{Id:BackupId,Life:Lifecycle,Src:SourceBackupId,SrcRegion:SourceBackupRegion}' \
  --output table

Add --kms-key-id <destination-region-key-arn> for a CMK. Incrementality is conditional on using the same KMS key, so changing keys mid-stream makes the next copy full.

Watch progress:

aws fsx describe-backups \
  --region <DST_REGION> --backup-ids <DST_BACKUP_ID> \
  --query 'Backups[0].{Life:Lifecycle,Pct:ProgressPercent}' --output table

COPYING → AVAILABLE means done. Mine took 7 m 15 s for a 9.4 MiB volume.

Day-to-day operation ends here. Steps 3 to 6 run only when you are recovering.

3. [Recovery] Check which generation the destination Region offers

Check the available deployment types before you need them. If first generation (SINGLE_AZ_1) is available, the minimum throughput is 128 MBps; where only second generation exists it is 384 MBps, which makes standby cost roughly 1.9× higher.

SINGLE_AZ_1 was accepted in Osaka (measured 2026-08-28). This varies by Region — confirm it for your destination before writing the runbook.

4. [Recovery] Create the destination file system

Billing starts here. Even at the minimum, Osaka costs roughly $0.37 per hour, and forgetting it runs about $270 a month. If you are doing this as a drill, open the teardown commands from step 8 first. During my own run I mistyped an option on delete-file-system and polled for 8 minutes while the command had already failed.

This is the 20 minutes that lands on RTO.

aws fsx create-file-system \
  --region <DST_REGION> \
  --file-system-type ONTAP \
  --storage-capacity 1024 \
  --storage-type SSD \
  --subnet-ids <DST_SUBNET_ID> \
  --security-group-ids <DST_SG_ID> \
  --ontap-configuration '{
    "DeploymentType": "SINGLE_AZ_1",
    "ThroughputCapacity": 128,
    "PreferredSubnetId": "<DST_SUBNET_ID>"
  }' \
  --tags Key=Name,Value=dr-restore-target \
  --query 'FileSystem.{Id:FileSystemId,Life:Lifecycle}' --output table

1,024 GiB and 128 MBps are the first-generation minimums. Raise them if your restore exceeds that. A restore pauses when SSD space runs out and resumes automatically once space is available.

5. [Recovery] Create the SVM

aws fsx create-storage-virtual-machine \
  --region <DST_REGION> \
  --file-system-id <DST_FS_ID> \
  --name dr_svm \
  --root-volume-security-style UNIX \
  --query 'StorageVirtualMachine.{Id:StorageVirtualMachineId,Life:Lifecycle}' --output table

For SMB you also need the Active Directory join here. If AD join is part of your recovery, verify separately that the destination Region can reach your domain controllers, and budget the time. My verification was NFS only.

6. [Recovery] Restore

A restore always produces a new volume. There is no in-place path.

aws fsx create-volume-from-backup \
  --region <DST_REGION> \
  --backup-id <DST_BACKUP_ID> \
  --name dr_restored \
  --ontap-configuration '{
    "StorageVirtualMachineId": "<DST_SVM_ID>",
    "JunctionPath": "/dr_restored",
    "SizeInBytes": <DST_VOLUME_SIZE_BYTES>,
    "OntapVolumeType": "RW",
    "TieringPolicy": { "Name": "NONE" }
  }' \
  --query 'Volume.{Id:VolumeId,Life:Lifecycle}' --output table

TieringPolicy: NONE follows the AWS recommendation for consistent read latency after a restore — it assumes you wait for the data to land on SSD before accessing it. Change it if you want the capacity pool.

Mine reached CREATED in 13 m 21 s for 9.4 MiB.

Three conditions drive restore and post-restore performance. Check these when it feels slow:

Condition	Detail
SSD capacity	Restored data is written to SSD first. The restore pauses when space runs out and resumes when it frees up
Generation	Second generation is readable during a restore (after metadata loads). First generation makes you wait for completion — mine was first generation
Background priority	Backup and restore are lower priority than client I/O and consume unused throughput capacity. They progress slowly while production I/O is saturated

The third one has an operational consequence: overlapping backups with a nightly batch window slows both. Separate the backup window from your peak.

7. Verify the content

Skip this and you cannot claim you restored anything. Order matters: take the hashes before you create the backup. Taking them afterwards mixes in every change since, and you can no longer separate that from a copy problem.

# On the source, BEFORE creating the backup
cd /mnt/src && find . -type f -exec sha256sum {} + | LC_ALL=C sort -k2 > /tmp/before.txt

# On the restored volume
cd /mnt/restored && find . -type f -exec sha256sum {} + | LC_ALL=C sort -k2 > /tmp/after.txt
diff /tmp/before.txt /tmp/after.txt && echo "MATCH"

Check permissions and symlinks too:

find . -mindepth 1 -printf "%y %m %s %p\n" | LC_ALL=C sort -k4

All five sha256 digests matched in my run, and mode 0640, the symlink target, and a UTF-8 (Japanese) filename all survived. I also used the ordering deliberately: a 2 MiB file added after the backup was absent from the restored volume, which is what makes it a point-in-time image rather than a mirror.

8. Delete what the test created

Forgetting the destination file system costs roughly $270 a month. The order matters.

# 1. volume (do not let it create a final backup)
aws fsx delete-volume --region <DST_REGION> --volume-id <DST_VOLUME_ID> \
  --ontap-configuration '{"SkipFinalBackup":true}'

# 2. SVM (after the volumes are gone)
aws fsx delete-storage-virtual-machine --region <DST_REGION> \
  --storage-virtual-machine-id <DST_SVM_ID>

# 3. file system (after the SVM is gone)
aws fsx delete-file-system --region <DST_REGION> --file-system-id <DST_FS_ID>

# 4. the copied backup, if you no longer need it
aws fsx delete-backup --region <DST_REGION> --backup-id <DST_BACKUP_ID>

Without SkipFinalBackup a final backup is created, and that backup then blocks the next deletion. I have been stuck on this before.

And confirm the deletion through the API. During this run I passed an unsupported option to delete-file-system and polled for 8 minutes while the command had already failed. Waiting without reading the response only advances the bill.

---

Measured through AWS Backup as well

Everything above is the CopyBackup path. The same route, Tokyo to Osaka, was also measured through AWS Backup. That is the path that carries scheduling and cross-account copies, so its behaviour is what matters for production.

Two ways round. An on-demand backup job followed by an on-demand copy job, and a backup plan with a copy rule left to fire on its schedule. Both used the same source volume (1 GiB, 9,458,747 bytes, 5 files).

Step	Elapsed
On-demand backup job	4 m 02 s
On-demand copy job, Tokyo to Osaka	8 m 35 s
Plan-triggered backup job	30 m 06 s, of which about 24 minutes was the start window
Copy rule copy job (automatic)	6 m 31 s
Restore from the AWS Backup console	16 m 16 s

The copy rule fired without being touched. The schedule came round, a job was created, the backup completed, and a copy job followed on its own to put a recovery point in the Osaka backup vault.

A plan-triggered job waits in CREATED

This changes an operational assumption. The on-demand job went to RUNNING immediately. The plan-triggered one stayed CREATED for about 24 minutes. When it starts inside the start window — 60 minutes in this configuration — is AWS Backup's decision.

So a runbook that reads "the scheduled time has passed, therefore the backup exists" is wrong by the length of that window. Confirm a generation by job state or by the recovery point, not by the clock.

The recovery point in Osaka points at the source

The Resource ID column names the Tokyo file system and volume. It sits in the Osaka vault and points at where it came from.

Open the recovery point and the copy is visible as such.

Source region reads Asia Pacific (Tokyo). That is the evidence this artefact came from a cross-Region copy. Copy type is Manual because this one was run on demand; the copy-rule one arrives as a separate recovery point.

The restore form makes you pick a destination file system and SVM

The "File system ID" at the top is the source. The destination is chosen separately, below. Read the two as the same thing and the restore target looks already decided. It is not.

Open the dropdown and only file systems in the destination Region are listed.

With no file system in Osaka this list is empty. Exactly the same constraint as the CopyBackup path: not holding a destination day to day is paid for here.

Storage efficiency is checked by default

Two things.

Volume size is pre-filled from the source (1024 MiB). The FSx for ONTAP console defaults the same field to 1 TiB (below), so AWS Backup is the more predictable of the two here.

"Enable storage efficiency" is checked by default. The source volume had it off, and the restored volume came back with StorageEfficiencyEnabled: true. The FSx for ONTAP console restore form pre-selects the source value, so the two consoles behave differently. Uncheck it to match the source.

Attribute	Source	After the AWS Backup restore
OntapVolumeType	RW	RW
SizeInBytes	1 GiB	1 GiB
TieringPolicy	NONE	NONE
StorageEfficiencyEnabled	false	true (the form's default)
SecurityStyle	UNIX	empty

SecurityStyle coming back empty had been seen once on the CopyBackup path. It reproduced through AWS Backup, so it is no longer a single-path observation.

The content matched

Mounted from an EC2 instance in Osaka and compared. All five sha256 values matched, and the symlink target, the 0640 mode, the UTF-8 filename, the nested directories and the mtimes were preserved.

The restored volume carries .snapshot/backup-<id>/. That <id> is the source FSx for ONTAP backup, not the Osaka recovery point ID. The destination volume's default snapshot policy starts running too, so hourly.* snapshots appear beside it.

What cannot be monitored, and what catches you on teardown

BackupSizeInBytes was 0 on both backup jobs. Not a size to alert on.

Restore progress read 0.00% for the whole 16 minutes, then 100%. Anything that estimates remaining time from the percentage will not work.

One thing caught me on teardown. A vault cannot be deleted until an EXPIRED recovery point is fully gone. After delete-recovery-point the entry stayed listed as EXPIRED for about six minutes, and delete-backup-vault refused with "contains recovery points" throughout. The underlying FSx for ONTAP backup was still AVAILABLE at that point. Teardown automation has to poll; taking the delete request's success as done leaves you stuck.

On the console language: the screens in this section are in English. That was the setting at capture time; the other sections show the FSx for ONTAP console in Japanese. Field names are quoted in English either way.

Cross-account copies were not measured. They require AWS Organizations, so this verification stayed inside one account.

---

For the cross-account half — an earlier post, and what this one adds

There is a post on the NetApp Community that goes further on cross-account copies than this one does.

• Cross-Region and Cross-Account Backup for Amazon FSx for NetApp ONTAP (Jordan Roth, NetApp Community)

It walks the cross-account path I did not measure, having actually run it. It sets out the protection layers (Snapshot copies, Multi-AZ HA, SnapMirror, AWS Backup copies), four architecture patterns — fan-in into an isolated vault account, fan-out to several, crossing Region and account in one hop, and a clean room for incident work — and the organization, key and IAM prerequisites behind them. If cross-account is going to production, read that first. What follows here is only where it meets my own measurements.

What this post was missing — cross-account needs a customer managed key

This is the one that matters. A cross-account copy requires a customer managed key (CMK). The AWS Backup documentation states that for resource types not fully managed by AWS Backup, cross-account copy with AWS managed keys is not supported, because an AWS managed key's key policy is immutable and cannot be shared across accounts (Encryption for backups in AWS Backup). FSx for ONTAP sits on the "not fully managed" side.

My verification did not meet that condition. The destination vault was created with defaults, so its key was alias/aws/backup (KeyManager: AWS). The cross-Region copy still succeeded. That is looser than the documentation's general statement, and it is the reason for measuring rather than assuming.

	Key used	Result
Cross-Region copy (Tokyo to Osaka, one account)	Defaults on both the source file system and the vaults (aws/fsx / aws/backup)	Succeeded (measured)
Cross-account copy	AWS managed keys cannot be used	Not measured. Unsupported per the documentation

There is a design consequence. A file system's KMS key is chosen at creation, and update-file-system has no parameter for changing it (checked in the AWS CLI). So if a cross-account copy might ever be needed, the CMK decision happens before the file system exists. It is not the kind of thing to switch on later. The destination vault has its own constraint: the default vault cannot be used, because its key cannot be shared.

The Region exceptions are listed individually

Earlier I wrote "commercial Regions where both services are available". AWS Backup feature availability lists the exceptions one by one.

Exception	Scope
Cross-Region copy not supported	Middle East (Bahrain), Middle East (UAE) — for all four of FSx for ONTAP, Lustre, Windows File Server and OpenZFS
Cross-Region and cross-account copy not supported	Asia Pacific (New Zealand), China (Beijing), China (Ningxia) — FSx for ONTAP

The China Regions need reading carefully. The AWS Backup document history carries an entry dated the same 27 August 2026 saying cross-account backup copy and cross-account management are now supported in the China Regions. That is about AWS Backup generally; FSx for ONTAP is excluded there, per the table above. Merge the two same-day announcements and you reach the opposite conclusion.

On "what was possible before", that post and I read it differently

Its table of changes records cross-Region CopyBackup within one account as already available before the launch. This post has been saying a backup could not cross a Region boundary before. Rather than assert, here is what I checked.

What I checked	What it says
ONTAP User Guide, "Protecting your data with volume backups" (archived 2026-07-05)	The sub-page list has no "Copying backups" — only "Copying tags to backups". The body says a backup restores to a file system in the same Region where it is stored
copy-backups.html in the ONTAP User Guide	No snapshot at all in the Internet Archive
The FSx for ONTAP What's New	"Previously, you could create and restore backups in the same Region and account as your file system"

What I cannot test now is whether the CopyBackup API would have accepted an ONTAP backup before the launch. That API is not specific to FSx for ONTAP, and has supported cross-Region copies for FSx for Windows File Server and FSx for Lustre for years, so reading the API reference alone and concluding it was already possible is a reasonable reading. Documentation not describing something is not the same as an API refusing it, so I am leaving that unverified.

For a reader today the practical answer is the same either way. What is unambiguously new is the AWS Backup half: cross-Region copy through AWS Backup, and any cross-account copy, from 27 August 2026.

What this post adds

The parts that do not overlap.

Here	What
Measured durations	Backup, copy and restore on both paths, to the second — including a plan-triggered job waiting about 24 minutes in the start window
Two consoles behaving differently	The AWS Backup restore form checks storage efficiency by default; the FSx for ONTAP one pre-selects the source value
A single-path observation reproduced	SecurityStyle coming back empty
What cannot be monitored	BackupSizeInBytes reads 0; restore progress sits at 0.00% for 16 minutes
Where teardown sticks	An EXPIRED recovery point blocks vault deletion for minutes
Cross-Region copy on default keys	It works with aws/backup (above)
Replication and copy as terms	Covered in its own section
Regional DR inside one country	Tokyo to Osaka, with the cost of keeping data in-country

---

The two things that caught me out

1. A restoring volume reads as DP, not RW

I read the attributes right after the restore reached CREATED and got OntapVolumeType: DP. DP volumes are read-only and cannot be backed up. I started writing "a restore produces a read-only volume".

Then I tried touch from the client. It succeeded. A re-read returned RW. To be sure, I ran a second restore passing OntapVolumeType: RW explicitly — and it also reported DP while CREATING.

State	OntapVolumeType
Restoring (CREATING)	DP
Restore complete (CREATED)	RW

It is transient. If monitoring or automation reads this field, it sees DP during a restore. Since DP volumes cannot be backed up, a naive "back up as soon as the restore finishes" step behaves differently depending on when it reads. Gate on Lifecycle reaching CREATED first.

Without the write probe I would have published the wrong claim.

2. FlexGroup backup creation failed asynchronously

The documented limitation is that copying backups of FlexGroup volumes is unsupported. It attaches to the copy and says nothing about creation. I misread it and built the test on the creation side.

CreateBackup against a FlexGroup volume was accepted and returned CREATING, then went FAILED about 30 seconds later. The message names no cause:

Backup failed. Please delete the backup and try again.

As a control, a FlexVol RW backup created in the same session with the same credentials succeeded — so this is not permissions.

But this is one observation on one volume. I am not claiming FlexGroup backups cannot be created. AWS documentation describes the restore behaviour of FlexGroup backups (adding constituents when the HA pair count differs), which does not read as creation being unsupported. Separately it states only that a SnapLock FlexGroup volume cannot be backed up. My target was a non-SnapLock FlexGroup, single constituent, one aggregate, 113 GiB provisioned.

The consequence: no AVAILABLE FlexGroup backup was produced, so the documented copy restriction was never exercised. If FlexGroup is in scope, verify it from the creation side in your own environment.

3. The attribute I called "not carried over" was a CLI default

Seeing StorageEfficiencyEnabled: true on the restored volume, I wrote that storage efficiency is not carried over by a restore. That was wrong too.

Running the same restore through the console showed the field pre-selected to the source value (disabled), and it restored as false. The initial true came from omitting the field in the CLI --ontap-configuration. It is an API default when omitted, not restore behaviour. State it explicitly if you script the restore.

That is twice in one exercise that I nearly published a behaviour inferred from a single observation. Running the same operation through a second interface is what exposed both.

Attribute	Source	Restored
StorageEfficiencyEnabled	false	true if omitted in the CLI, false when stated
SecurityStyle	UNIX	empty in the API response (both CLI and console; UNIX mode bits behaved correctly over NFS)

Check storage efficiency after a restore — omitting the field enables it even when the source had it off. The empty SecurityStyle reproduced across both paths, but against the same UNIX-style source; other security styles were not tested.

---

What the console shows that the CLI does not

Four behaviours only visible in the console.

A note on the screenshots: my console is set to Japanese, so that is what you will see. The field
positions and the behaviour are identical in any locale, and each caption names the field in English.
If you would rather follow along in English, switch your own console language under Unified
Settings → Language.

The copy form defaults to the same Region

Backups list. Select a backup, then **Actions → Copy backup* (バックアップをコピー), alongside restore
(バックアップを復元) and delete (バックアップを削除).*

Copy backup form. *送信先リージョン (destination Region) defaults to the current Region** — leaving it
alone produces an in-Region copy. タグをコピー is "copy tags".*

The destination Region list. Commercial Regions only; the China and GovCloud sets cannot be crossed.

With Asia Pacific (Osaka) selected, the **KMS キー ID (KMS key ID) changes to that Region's default
key. This is what "incrementality requires the same KMS key" means in practice: the key in the
destination Region.

While the copy runs

Destination Region's Backups list. ステータス reads コピー中 ("copying"), and the entry is labelled
*(コピーされたバックアップ) — "(copied backup)"*. Tag copying carried the name across.

The completed copy. *ソースバックアップ ID (source backup ID)** and ソースバックアップリージョン
(source backup Region) = ap-northeast-1 are the two fields that establish this is a copy. タグ shows
the copied tags.*

Restore needs more than a file system

The dialog is titled *バックアップからボリュームを作成 — "Create volume from backup"*. The title states
plainly that a restore produces a new volume. ファイルシステム (file system) starts empty.

The ファイルシステム dropdown lists **only file systems that already exist in the destination Region. If
you have not created one, there is nothing to select — which is where the "create the file system first"
step announces itself.

After picking the file system, *ストレージ仮想マシン (storage virtual machine) appears with a red 必須
("required")** and blocks submission. This is the concrete form of "the destination needs a file system
and an SVM". Note the SnapLock section at the bottom — irreversible, and not a field to set in
passing during a restore.*

The volume size default is 1 TiB

The same form filled in. *ボリュームサイズ (volume size) defaults to 1 TiB** even though the source
volume is 1 GiB — I changed the unit to GiB here. ボリューム名, ジャンクションパス, and ストレージ効率
are all pre-filled from the backup; size is not. On a 1,024 GiB destination the default consumes the
entire file system.*

The console shows DP too, and does not refresh

During the restore. *ライフサイクルの状態 (lifecycle) = 作成 ("creating")** and ONTAP ボリュームタイプ
(ONTAP volume type) = DP — with Read-Write (RW) selected in the form. ジャンクションパス and
ストレージ効率 are absent, and セキュリティスタイル (security style) is blank.*

The same page after a reload: *作成済み ("created")** and RW, with junction path, storage efficiency,
and snapshot policy now shown. The page does not auto-refresh — it kept showing DP after the API had
already returned RW, so judging completion by eye alone misses it. セキュリティスタイル stayed blank.*

---

Designing this for production

Everything above was one manual copy. Six things still need deciding.

1. Scheduling — CopyBackup has none

The AWS documentation describes the FSx for ONTAP path as "manually copy volume backups". It runs from the console, CLI, or API on demand and carries no scheduler. Two ways to make it periodic:

Path	Shape	Fits when
AWS Backup backup plan	Adding a copy rule to a plan's rule writes each backup to a backup vault in the chosen Region, and optionally the chosen account, as it is taken. On-demand copy jobs are available too	You want policy control, or the same protection applied across an organization. The only path if the copy has to land in another account
Your own automation	EventBridge Scheduler → Lambda → create-backup → wait → copy-backup	You want to keep using FSx for ONTAP backups directly and manage generations yourself

AWS Backup is a managed service that centralizes taking, copying, and retaining backups under policy. FSx for ONTAP joined its cross-Region and cross-account copy targets in August 2026. Applied across an organization it pairs with AWS Organizations, and the account boundary is defined by Organizations policies; the documentation describes fan-in (many production accounts into one isolated account) and fan-out (one production account into several isolated accounts).

The cross-Region copy and the restore were measured (Measured through AWS Backup as well). The copy rule fired without being touched and the restore went through. A plan-triggered job does wait inside the start window, though — about 24 minutes here — so the scheduled time is not when the generation exists.

AWS Backup's Region coverage here is "all commercial Regions where both services are available", but the feature availability page lists individual exceptions (below). That page also states that when a resource type has no checkmark in the copy columns, copy operations are unsupported in every scenario, including a same-Region same-account copy to a different vault.

If you build it yourself, calling copy-backup before create-backup completes fails — the source must be AVAILABLE. Poll, or use a Step Functions wait.

Whether AUTOMATIC backups can be copied is unverified. The What's New post says "new and existing backups" without qualifying the type. If automatic backups are your evacuation source, prove it with one generation first.

2. Make recovery declarative — CloudFormation can express the restore

Typing six steps during an incident is not realistic at any team size. This can be declarative.

AWS::FSx::Volume has a BackupId property ("the ID of the volume backup to use to create a new volume"). So the file system, the SVM, and the restore all fit in one template:

Parameters:
  CopiedBackupId:
    Type: String
    Description: ID of the backup in the destination Region

Resources:
  DrFileSystem:
    Type: AWS::FSx::FileSystem
    Properties:
      FileSystemType: ONTAP
      StorageCapacity: 1024
      StorageType: SSD
      SubnetIds: [!Ref DrSubnetId]
      SecurityGroupIds: [!Ref DrSecurityGroupId]
      OntapConfiguration:
        DeploymentType: SINGLE_AZ_1
        ThroughputCapacity: 128
        PreferredSubnetId: !Ref DrSubnetId

  DrSvm:
    Type: AWS::FSx::StorageVirtualMachine
    Properties:
      FileSystemId: !Ref DrFileSystem
      Name: dr_svm
      RootVolumeSecurityStyle: UNIX

  DrRestoredVolume:
    Type: AWS::FSx::Volume
    Properties:
      Name: dr_restored
      VolumeType: ONTAP
      BackupId: !Ref CopiedBackupId
      OntapConfiguration:
        StorageVirtualMachineId: !Ref DrSvm
        JunctionPath: /dr_restored
        SizeInBytes: 1073741824
        OntapVolumeType: RW
        TieringPolicy:
          Name: NONE

Keeping this template undeployed in the destination Region is the cold-standby-IaC shape. Zero cost while idle, one deploy at recovery, and no step to forget.

I have not deployed this template — I ran the same sequence through the CLI. Deploy it once and time it before it becomes your runbook. An undeployed recovery template is a draft, not a procedure.

3. RTO breakdown — "20 minutes" is one line of it

I measured file system creation (20 min) and the restore (13 min). Your RTO is not the sum of those two. Fill this in for your environment.

Step	My measurement	Yours
Decision to recover (detection to action)	not measured
Destination file system creation	~20 min
SVM creation	a few minutes
AD join (if using SMB)	not performed
Restore to CREATED	13 m 21 s (9.4 MiB)
Export policy / share reconfiguration	not measured
Client remount, DNS cutover	not measured
Business-side validation	not measured

If you use SMB, the AD join is in there. Confirm destination-Region reachability to your domain controllers while nothing is wrong. Discovering that mid-incident is a dead end.

Restore time gets longer with capacity

The 13 m 21 s and 16 m 16 s I measured were on a 9.4 MiB volume. Treat those as reference points only. Restore time for FSx for ONTAP backup, through either path, scales with capacity.

AWS publishes the rates (Backup and restore performance).

Operation	Mostly large files	Mostly small files
Backup creation	750 MBps	100 MBps
Restore	250 MBps	100 MBps

Two conditions come attached to those numbers, and both push an estimate to the longer side.

• They are values "across several concurrent restores" — that is AWS's wording. Nothing says a single restore runs at that rate.
• Backup and restore are background work and use only unused throughput capacity. Throughput capacity is therefore the ceiling. A 128 MBps file system will not reach 250 MBps.

Applying both, the calculation is min(published rate, throughput capacity). These are floors, on the optimistic assumption that client I/O is zero.

Logical data	128 MBps / large files	256 MBps+ / large files	Mostly small files (any throughput)
1 TB	2 h 10 m	1 h 6 m	2 h 46 m
5 TB	10 h 51 m	5 h 33 m	13 h 53 m
10 TB	21 h 42 m	11 h 6 m	27 h 46 m
20 TB	43 h 24 m	22 h 13 m	55 h 33 m
50 TB	108 h 30 m	55 h 33 m	138 h 53 m

Restoring 10 TB on the minimum configuration (128 MBps) is 22 hours at the floor. Mostly small files is 28 hours, and that one does not shrink by adding throughput, because the published 100 MBps binds first. At 50 TB it passes four days.

I could not find a measured figure at 10 TB or above in any public source. I searched AWS blogs, re:Post, the Knowledge Center, and the documentation, and found no article that publishes a measured restore duration with the capacity stated. The table above is calculated from AWS published rates — it is not something anyone measured. If you need a meaningful number for your own environment, the only way is to measure once at production-equivalent capacity and file mix.

And this can overturn "generation 1 is enough"

The section below says gen 1 is enough for a DR standby. At scale that reverses.

	Gen 1	Gen 2
Monthly at minimum throughput	$115.97 (128 MBps)	$772.99 (384 MBps)
Reads while restoring	No. You wait for completion	Yes, once metadata has loaded
Time to service at 10 TB	21 h 42 m (floor)	6–46 min (after 1–7% of metadata loads; the rest loads in the background)

Metadata is documented as 1–7% of the backup data, depending on file size — the smaller the files, the larger the share. At 10 TB, loading just that 1–7% first lets clients mount and start reading. A first access to a block that has not loaded yet costs tens of milliseconds, and it is cached on SSD after that.

So $657 a month of difference can turn a 21-hour outage into something closer to 30 minutes. If you hold 10 TB or more and your RTO is constrained in hours, choosing gen 2 for the standby too is a defensible call. Gen 1 is enough when either the capacity is small or the RTO can absorb waiting for the restore to finish.

• A few TB or less, or an RTO in days → gen 1
• 10 TB or more with an RTO in hours → gen 2's reads-while-restoring earn their keep
• Both are a longer RTO than SnapMirror (neither reaches a shape where the destination volume already exists)

4. Application consistency — this does not replace a database backup

A backup is a point-in-time copy of a volume. It does not quiesce an application.

Workload	What you need
File servers, shared storage	A volume point-in-time is usually enough
Databases (Oracle, SQL Server, …)	A database-level backup, or quiescing before the backup
Anything with constantly open writes	Application-level consistency checks after restore

Reading "we copy volume backups to another Region, so DR is covered" for a database workload can end with a volume that restores and a database that will not start.

5. Concurrency limits at scale

The limits are on operations in flight, not on how much you can keep.

Limit	Value	Consequence
Copies in flight (per volume, per destination Region, per KMS key)	5	Parallelizing one volume's generations stops at 5
Copies in flight (per account)	1,000	Firing off hundreds or thousands of volumes at once exceeds it. Excess requests are rejected
Backups per volume	4,091	Work your generation plan backwards from here

In a multi-tenant design with one volume per tenant, tenant count becomes your concurrency. Batch the submissions and retry rejections with exponential backoff.

6. Monitoring and control

Copies are asynchronous. When copy-backup returns, nothing has finished yet.

Decide	Options
Where failures are detected	With AWS Backup you can follow job state. For CopyBackup, polling describe-backups is the dependable route. Whether CloudWatch or EventBridge can carry this is unverified
How success is evidenced	Store the describe-backups response (BackupId, SourceBackupId, SourceBackupRegion, CreationTime)
Who approves a restore	A restore creates a new volume and destroys nothing, but it consumes destination SSD and starts billing. Put it in an approval flow where that is expected
Which destinations are allowed	Enforce it in IAM or an SCP, not in a written rule

One note on tags. --copy-tags carries source tags to the destination. If your tags name systems or departments, that naming appears in the isolated account too. Depending on why you are isolating, re-tagging may be the better choice.

---

Cost

The $0.55 I spent was a test bill. What is useful in your environment is a monthly figure, so this builds one up from unit rates.

Unit rates — queried from the AWS Price List API

The rates below were queried from the AWS Price List API on 2026-08-29 (effective 2026-07-01). Tokyo and Osaka were identical on all four of the items that appear in both.

Charged item	Tokyo / Osaka rate	Nature of the charge
SSD storage (Single-AZ)	$0.150 / GB-month	provisioned
SSD storage (Multi-AZ)	$0.300 / GB-month	provisioned
Capacity pool Standard (Single-AZ)	$0.0238 / GB-month	consumed
Capacity pool Standard (Multi-AZ)	$0.0476 / GB-month	consumed
Backup storage	$0.050 / GB-month	consumed (incremental)
Throughput capacity (Single-AZ, gen 1)	$0.906 / MBps-month	provisioned
Throughput capacity (Single-AZ, gen 2)	$2.013 / MBps-month	provisioned
Capacity pool read requests	$0.00037 / 1,000 requests	consumed
Capacity pool write requests	$0.0047 / 1,000 requests	consumed

Going through AWS Backup does not change the backup storage rate. FSx for ONTAP is not a resource type that AWS Backup fully manages, so the storage charge appears on the FSx for ONTAP side rather than on AWS Backup (Metering, costs, and billing for AWS Backup). The rate is therefore $0.050 / GB-month on the native path and on the AWS Backup path alike. Only when you use a logically air-gapped vault (LAG vault) does all of the storage and transfer land on the AWS Backup side.

FSx for ONTAP backup is not the cheap option

$0.050 / GB-month is 2.1× the Single-AZ capacity pool ($0.0238). Put the other way round, the capacity pool is 47.6% of backup storage — less than half.

AWS makes the same comparison. AWS Prescriptive Guidance puts fully managed backup at $0.05 / GB-month, against $0.03221 / GB-month for SnapVault aimed at a capacity pool at an SSD-to-pool ratio of 1:10 (Choose the right SMB file storage, US Region example).

That 47.6% is Single-AZ only. A Multi-AZ capacity pool is $0.0476, which is 95.2% of backup storage, and the advantage all but disappears. Carrying "the capacity pool is less than half" into a Multi-AZ estimate will put your numbers wrong.

Running one continuously has a floor

Read the rate table straight and it seems to say "if the capacity pool is cheap, then keeping a destination file system running is cheap too". It does not work out that way. The minimums on the provisioned charges set the floor for anything kept running.

Constraint	Value	Source
Minimum SSD capacity	1,024 GiB per HA pair	Quotas
Minimum throughput capacity (gen 1)	128 MBps	same
Minimum throughput capacity (gen 2, 1 HA pair)	384 MBps	same

Monthly cost of a Single-AZ minimum configuration:

Generation	Components	Monthly at minimum
Gen 1 (128 MBps)	1,024 GiB × $0.150 + 128 MBps × $0.906	$269.57
Gen 2 (384 MBps)	1,024 GiB × $0.150 + 384 MBps × $2.013	$926.59

The same "minimum configuration" differs by 3.4× between generations, because gen 2's minimum throughput is 384 MBps and its per-MBps rate is 2.2× gen 1. For backup and a DR standby, gen 1 is the choice (below).

All-tiering does not remove this floor either. Metadata always stays on SSD, so the 1,024 GiB SSD minimum remains provisioned.

It inverts with scale

Assumptions: 30 daily backup generations, 2% daily change rate, no dedupe or compression benefit assumed, Single-AZ gen 1 at the 128 MBps minimum, the Osaka rates above. The all-SSD column provisions capacity to the recommended 80% SSD utilisation.

Logical data	Backup copies (no destination FS)	Standing + all-tiering	Standing + all SSD
1 TB	$80	$293	$303
2 TB	$160	$317	$491
5 TB	$400	$389	$1,053
10 TB	$800	$508	$1,991
20 TB	$1,600	$746	$3,866
50 TB	$4,000	$1,460	$9,491

The crossover is around 4.8 TB. That is the $269.57 floor divided by the per-GB difference: 1.6 generations of backup at $0.050 ($0.080) against the capacity pool at $0.0238, a gap of $0.0562.

This is what backs up "we keep one running for RTO and RPO". Past 4.8 TB a standing destination file system is lower monthly, and a minutes-level RPO, a single-digit-minute RTO, and a failback path come with it. Improving recoverability is not an increase in monthly cost at that size. At 1 TB it is the other way round, and the gap between $80 and $293 has to be explained as a difference in requirements.

Why a DR standby takes generation 1

For backup and a DR standby, gen 1 is enough. The reason is the throughput increments.

	Gen 1	Gen 2 (1 HA pair)
Selectable throughput	128 / 256 / 512 / 1,024 / 2,048 MBps (Tokyo and Osaka cap at 2,048)	384 / 768 / 1,536 / 3,072 / 6,144 MBps
Monthly at minimum throughput	128 MBps × $0.906 = $115.97	384 MBps × $2.013 = $772.99

A standby's throughput is sized by SnapMirror transfer volume and the reads right after a failover, not by production load. Gen 2 still floors at 384 MBps for that use, which is 6.7× on the throughput line alone. With gen 1 you start at 128 MBps and move up to 256, then 512, when you need it.

Deployment type cannot be changed after creation (documented). Going from gen 1 (SINGLE_AZ_1) to gen 2 (SINGLE_AZ_2) means a restore from backup, or a migration over SnapMirror or AWS DataSync. Decide the generation before you build the standby.

Total monthly by throughput

The 4.8 TB crossover above assumes the 128 MBps minimum. Raise throughput and the crossover moves up with it. Here are the combinations laid out.

Assumptions: Single-AZ gen 1, all-tiering, SSD at the 1,024 GiB minimum, Tokyo / Osaka rates. The backup-copy column is 30 daily generations at a 2% change rate. Capacity pool request charges are not included.

Logical data	128 MBps	256 MBps	512 MBps	1,024 MBps	2,048 MBps	Backup copies
1 TB	$293	$409	$641	$1,105	$2,033	$80
5 TB	$389	$505	$736	$1,200	$2,128	$400
10 TB	$508	$624	$855	$1,319	$2,247	$800
20 TB	$746	$862	$1,093	$1,557	$2,485	$1,600
50 TB	$1,460	$1,576	$1,807	$2,271	$3,199	$4,000

Bold is cheaper than holding backup copies. Restated as the highest throughput that still comes in under the backup-copy figure:

Logical data	Backup copies / month	Highest throughput under that
1–2 TB	$80–$160	None. Even 128 MBps standing costs more
5 TB	$400	128 MBps
10 TB	$800	256 MBps
20 TB	$1,600	1,024 MBps
50 TB	$4,000	2,048 MBps (the gen 1 ceiling in Tokyo and Osaka)

At 50 TB you can provision the largest throughput gen 1 offers in-Region and still come in cheaper than holding backup copies. At 1–2 TB backup copies are cheaper at every throughput, and there the difference is a requirements conversation.

What the "zero while idle" of backup copies buys

With no destination file system in normal operation, there is no throughput capacity charge and no SSD capacity charge. That is a clear advantage on the monthly figure. The work it defers, though, reappears at the moment of failover, as urgent work.

And the unit of a backup is the volume, so a restore always produces a new volume. There is no path that overwrites an existing volume in place, on the CopyBackup route or the AWS Backup route. That is what makes steps 4 to 6 below unavoidable rather than optional: a new volume means a new junction path if the original still exists, and export policies, SMB shares, quotas, and the snapshot policy do not travel with it. The volume size default is a separate trap — it comes up as 1 TiB rather than the source's size, covered further up.

In an incident that same constraint cuts the other way and becomes an advantage: you can preserve a compromised volume exactly as it stands and restore beside it, so the original is still there to investigate.

Here is what a cold start to restored service actually needed, in the range I measured.

#	Step	Measured / state
1	Create the file system in the destination Region	20–22 min (measured, SINGLE_AZ_1, 128 MBps)
2	Create the SVM	a few minutes
3	Restore the volume from backup	13 m 21 s (CopyBackup path) / 16 m 16 s (AWS Backup path), both at 9 MB
4	Recreate export policies and SMB shares	Only the volume is restored. Share configuration does not come with it
5	AD-join the SVM if you use SMB	It is a new SVM, so it joins again
6	Repoint clients	The new file system has a different DNS name and different IPs. Either move a CNAME or remount on the client

Steps 1 and 3 finish if you wait. Steps 4 to 6 are a person deciding and typing. And they are needed mid-incident, not on a quiet afternoon. What you saved monthly is traded against doing that work under pressure.

In a SnapMirror shape, 1 to 3 do not exist, and the destination SVM in 5 is already joined. What is left is 6 and the break-and-promote, so the number of steps is not comparable to begin with.

Steps 4 to 6 can be automated ahead of time. Declare the restore in CloudFormation, script vserver cifs create and the share creation, put a CNAME in front of DNS. But "can be" and "confirmed to work during an incident" are different claims. Run it through once while nothing is wrong.

The price difference is the requirement difference

Here is what sits inside the $80 and the $293 at 1 TB.

	Backup copies	Standing (SnapMirror shape)
RPO	60 min (the automatic backup minimum)	5 min
RTO	file system creation 20–22 min + restore 13–16 min (measured)	promote the volume
Failback	no path	yes
Destination file system in normal operation	not needed	needed

If the requirement is a minute-level RPO, backup copies are not a candidate. And at recovery time the backup-copy side creates a destination file system too, so the same floor starts applying from then on. The accurate reading is a design whose cost structure differs between normal operation and recovery.

Not included above

• Capacity pool request charges: not in the tables above. The rates are known, but I have not measured the conversion from SnapMirror transferred bytes to request counts, so I cannot produce a number. With all-tiering every write goes to the capacity pool, so write requests ($0.0047 / 1,000) may not be negligible.
• Inter-Region data transfer: treated differently depending on the path. Split out into the next section
• Source-side backup storage (unchanged — you only added somewhere to put a copy)
• KMS request charges if you use a CMK
• SnapMirror inter-Region transfer (SnapMirror is not measured in this post)

Inter-Region data transfer is treated differently per path

AWS Backup copies have a transfer line item. Tokyo to Osaka is $0.09 / GB (Price List API, AWSBackup, APN1-APN3-CrossRegion-WarmBytes-FSx, retrieved 2026-08-29). The AWS Backup pricing page gives the same transfer rate for Resource Group 3, which includes Amazon FSx, on a standard vault and on a logically air-gapped vault alike.

For native CopyBackup, the reasonable thing is to estimate as though it applies. I started to write "probably does not apply", checked again, and withdrew it. Here is why.

The argument I withdrew: backups sit in AWS-managed S3 and never traverse the customer VPC, so they are not subject to inter-Region transfer charges the way EC2 is. That does not hold. EBS snapshots are equally in an AWS-managed area and equally do not traverse a VPC, and a cross-Region snapshot copy does incur AWS Data Transfer charges. The AWS Storage Blog walks through tracking that charge in Cost Explorer, and the usage type that appears there is USW2-USE1-AWS-Out-Byte, the service is "EC2 - Other", and the usage type group is Data Transfer - Region to Region (Out) (Effectively track AWS data transfer costs for cross-region Amazon EBS Snapshot Copy).

That also exposes a hole in how I first checked it. I based it on "there is no transfer item in the FSx for ONTAP price list", but inter-Region transfer is listed under AWSDataTransfer, not under the originating service. EBS is exactly that case: there is no "snapshot transfer" item in the EBS price list, and the charge happens anyway.

And AWSDataTransfer has a generic, service-agnostic inter-Region SKU.

Direction	Usage type	Rate
Tokyo → Osaka (out)	APN1-APN3-AWS-Out-Bytes	$0.09 / GB
Osaka → Tokyo (in)	APN1-APN3-AWS-In-Bytes	$0.00 / GB

(Price List API, AWSDataTransfer, effective 2026-06-01, retrieved 2026-08-29)

The Amazon FSx SKU on the AWS Backup side is also $0.09 / GB. The same transfer rate appearing in both places makes it natural to read them as the same underlying charge.

To summarise, this is as far as it can be taken right now.

Question	State
AWS Backup cross-Region copies incur transfer	Listed in the price list ($0.09 / GB, Tokyo → Osaka)
Native CopyBackup incurs transfer	Estimate as though it does. A generic $0.09 / GB SKU exists, and the same shape (EBS snapshot copy) is charged in practice. But I have not confirmed it on a bill — unverified
"It is not in the FSx for ONTAP price list, so it is free"	This inference is wrong. Transfer is listed under AWSDataTransfer

In an estimate, put in the first full copy's capacity × $0.09 / GB. After that it is incremental, so changed volume × $0.09 / GB. A 10 TB first full is $900 — not a monthly figure, but a one-off of real size. The shortest way to settle it is to copy one small volume and read the UsageType in Cost Explorer. I have not done that.

On which account is billed for transfer, two AWS statements disagree. FSx for ONTAP is not a resource type AWS Backup fully manages, so that discrepancy lands directly on this case.

Source	Statement
AWS Backup Developer Guide	For resource types that are not fully managed, transfer appears on the destination account
AWS Backup pricing page	Transfer is charged to the account sending the data (the copy source)

Which one is correct I have not been able to confirm. If cost attribution has to go into the design of a cross-account setup, copy once first and check which account it lands on in the actual bill.

The trade-off of all-tiering

Keeping a standby cheap with all-tiering means reads after a failover start from the capacity pool. All does not pull read blocks back onto SSD, so performance immediately after a cutover is not the same as production sized for SSD. It is a choice between the monthly cost while idle and the performance immediately after cutover.

• Prioritise cost while idle → all
• Need production-equivalent performance from the moment of cutover → provision SSD as in production (the "all SSD" column above)

When you build your own estimate, replace the change rate and the generation count with measurements from your environment. The 2% is an assumption, not something I measured. Rates are revised, too. The figures above were retrieved on 2026-08-29 and are effective 2026-07-01, so check the current values on the FSx for ONTAP pricing page and the AWS Backup pricing page before you decide.

---

As a ransomware layer

An isolated copy is a useful layer, but it lacks two properties people expect of it.

Expectation	Reality
Put it in an isolated account and it cannot be deleted	Copies can be deleted. The isolation holds only if the destination account's IAM or vault policy prevents deletion
A backup copy satisfies an immutability requirement	It does not. Preventing deletion during a retention period is the domain of WORM features (Object Lock, SnapLock, Tamperproof Snapshot, Vault Lock)

WORM features are irreversible. Once enabled, nothing is deletable until retention expires, and the blast radius is routinely wider than the resource you named. Get the retention value and the blast radius approved separately before enabling one. I made a file system undeletable for six months this way.

On the other hand, a restore always producing a new volume is an advantage during an incident. You can preserve the compromised volume for investigation and restore into a separate volume to resume operations, without overwriting the original.

---

Common errors and how to isolate them

Decide which layer stopped before you start debugging. Get the layer wrong and you spend the incident suspecting something that works.

Layer	Look at	What to check
1. Source	The backup	Lifecycle is AVAILABLE; volume type is RW; style is FlexVol
2. Permissions	IAM / KMS	fsx:CopyBackup present; source-Region backup reachable; destination key permissions for a CMK
3. Copy	describe-backups at the destination	COPYING, AVAILABLE, or FAILED; concurrency limits
4. Restore	The destination volume	Lifecycle; enough SSD (it pauses when short)
5. Access	The client	Export policy, security group, SVM NFS / SMB endpoint

Messages I actually saw:

Message	Layer	What to do
Backup <id> is being copied, can't be deleted	3	Wait for the copy. There is a short delay even after it completes
Backup failed. Please delete the backup and try again.	1	Names no cause. Suspect FlexGroup and take a FlexVol control
Volume with type DP is not backupable.	1	That is a SnapMirror destination. Back up at the source instead
Rejection from exceeding copies in flight	3	5 per volume per destination Region per KMS key, 1,000 per account. Wait and retry
Unknown options: --ontap-configuration (delete-file-system)	—	A CLI version difference. Read the response. This cost me 8 minutes of polling

Whether a failed copy leaves a partial backup at the destination is unverified — I did not induce a failure deliberately. If you automate this, detect FAILED and delete it (the backup created by my FlexGroup failure did remain as FAILED, and it deleted cleanly).

---

Where this sits alongside an existing backup product or SaaS

If you already run a data protection product or backup SaaS, this update is not a migration question. It is a question of which layer you give to what. There are three paths, and combining them is normal.

Path	Managed by	Another Region	Another account	Fits
A. FSx for ONTAP backups	FSx for ONTAP API / console	yes (new)	no	Volume-level evacuation with the fewest moving parts
B. AWS Backup	Backup plans	yes	yes (needs Organizations)	Policy control, one view across services
C. Existing data protection product / SaaS	That product's policy	Depends on the product	Depends on the product	File- or application-level restore, catalog search, fitting existing workflows

A concrete way to split them

File-level restores from the existing product; whole-volume evacuation from FSx for ONTAP backup copies. One split that often works, and the reason is restore granularity. A restore from an FSx for ONTAP backup produces one new volume, which is a lot of machinery to return a single file a user deleted. Conversely, pushing whole volumes to another Region through an existing product tends to grow the transfer volume and the catalog. Where your product already handles cross-Region evacuation efficiently, the opposite split is equally reasonable.

The decisive question for AWS Backup is whether you need another account. Evacuating to an isolated account is out of reach for the FSx for ONTAP API alone; it needs AWS Backup and AWS Organizations. If you only need another Region, the FSx for ONTAP API is fewer moving parts.

What to ask, regardless of product

Ask along these axes rather than by product name:

Axis	What to establish
Unit of protection	Whole volume, file / directory, or application-consistent
Restore granularity	Can it return one file, or only a whole volume
Cross-Region / cross-account path	The product's own feature, via AWS Backup, or your own copy
What the restore target requires	Does a file system need to exist first
Where retention policy lives	The product or AWS. Is it managed in two places
Monitoring and alerting	Where failures surface, and whether that reaches your existing observability
Where the cost lands	Product licensing, AWS usage, or both

"Managed in two places" is where the accidents are. If FSx for ONTAP automatic backups and the product's policy each hold generations independently, changing retention on one side leaves the other holding an unintended number. The ceiling is 4,091 backups per volume, so plan backwards from it.

Storage is also billed twice. Holding the same data in both the product's repository and FSx for ONTAP backups charges for both sets of generations. If you combine them, pick a primary and make the generation counts differ:

Shape	Primary	Secondary
File-level restore matters most	Existing product, long retention, many generations	FSx for ONTAP backups short and few (recent whole-volume evacuation)
Cross-Region evacuation matters most	FSx for ONTAP backup copies, many generations	Existing product limited to in-Region file restores

Neither is correct in the abstract. It comes down to which granularity 90% of your restore requests arrive in. Counting your past restore tickets is the most reliable way to find out.

About monitoring

My verification polled describe-backups. I have not verified a path for detecting copy completion through CloudWatch metrics or EventBridge events. If you plan to wire this into an existing observability stack, that is a gap you will need to close yourself.

---

Choosing between this and SnapMirror

Neither is better. The AWS documentation states RPO and RTO figures for both, and they protect different things.

For context: cross-Region disaster recovery for FSx for ONTAP has been buildable with SnapMirror for years — a destination file system, cluster peering, asynchronous replication. Plenty of production environments run exactly that, and backup copies do not displace it. What got added is the option of not holding the destination while nothing is wrong.

Dimension	Backup copies	SnapMirror
Suits	Offline copies for compliance or isolation	Availability in a second Region
RPO guidance	60 minutes	as low as 5 minutes
RTO guidance	minutes to hours (size dependent)	single-digit minutes
Needed while idle	No destination file system	A running destination file system
Shape of recovery	Restore as a new volume. The original does not come back	Break the relationship and promote the destination
Path back to production	None. Continue on the recovery side, or copy back in the other direction	Delete the relationship and snapmirror resync from the DR side
Trade-off	Destination file system creation lands on RTO (20 min measured); RPO is as coarse as the backup interval. The unit of backup and restore is the volume, and with AWS Backup / FSx backups a restore always lands in a newly created volume — there is no restore-in-place path, so junction paths, share configuration and where clients point all have to be rebuilt	You pay for destination capacity and throughput continuously; needs cluster peering and does not work through NAT

In operation, the asymmetry in "path back to production" is what bites. SnapMirror can be re-established in reverse to fail back. Backup copies only restore, and what you get is a new volume. If a documented failback procedure is a requirement, backup copies do not substitute for it.

One caveat on snapmirror resync: user-created snapshots are not replicated by a resync. The preserve parameter is available on XDP relationships.

Running both

This is a natural combination: SnapMirror for availability, backup copies for isolated retention. One catch — a SnapMirror destination is a DP volume and cannot be backed up, so "back up the replica and evacuate that" does not work. Take backups at the source and copy those.

---

Regional DR within one country

Copying to Osaka keeps data inside Japan while placing it in a second Region.

Consideration	Detail
Where the data sits	Both Tokyo and Osaka are in-country
Idle cost	Backup storage only ($0.050/GB-month in Osaka, rate effective 2026-07-01)
Needed at recovery	A file system and SVM in Osaka. Creation time lands on RTO (20 min measured)
Generation availability	SINGLE_AZ_1 was creatable in Osaka (measured 2026-08-28). This differs by Region
Trade-off	Coarser RPO and RTO than SnapMirror. A minute-level RPO requirement means keeping the destination running

How you satisfy a data residency requirement is a design question, not a legal or regulatory determination. Interpreting regulatory requirements belongs to your compliance function and the relevant authority. This post does not substitute for that.

---

A staged rollout

Do not start on a production volume. The order I would suggest:

1. Run the whole path on a small test volume (~1 GiB) — copy, destination file system, restore, content check, teardown. This is where the holes in your procedure show up
2. Time it including teardown. Destination file system creation lands on RTO, so this is the number you most want
3. Measure once at production data volume. My 9.4 MiB figures are dominated by fixed overhead and are not evidence for your environment
4. Check whether the second copy is incremental by comparing transfer volume and duration
5. Run periodic copies on a non-production volume and build the failure-detection path. This is where the real work is
6. Go to production, keeping the existing backup path running in parallel
7. Put restore drills into operations. Without them your RTO is an estimate

Do not go to production without step 5. Copies are asynchronous, and when one fails your command has already returned success.

A verification plan template

Useful to have on one page if a team is involved:

Item	What goes in it	Mine
Question being answered	"Does cross-Region evacuation work without a standing destination?"	same
Success criteria	Content matches after restore, and every line of the RTO breakdown is filled	Hash match achieved. RTO breakdown incomplete (AD and remount unmeasured)
Time required	Half a day for the small path, a day at production volume	~1.5 hours including teardown
Cost ceiling	Driven by destination file system runtime. Set it first	Capped at 3 hours / $2; actual $0.55
Stakeholders	Storage operations, the business (accepting the restored data), audit / control, networking (destination VPC, AD reachability)	—
Go criteria	Measured RTO under target / incrementality confirmed / failure detection working	Not met (incrementality and detection unverified)
No-Go criteria	RPO needed in minutes / failback required / FlexGroup in scope	—

By that standard I cannot call my own run a Go. Incrementality and failure detection are unverified, and the RTO breakdown does not include AD. What this post establishes is that the path works.

A recovery runbook skeleton

Naming the decision points keeps the day itself calm:

#	Decision or action	Branch
1	Is recovery needed (Region-level failure, or data loss)?	Data loss alone is an in-Region restore. You do not need the other Region
2	Which generation?	Check CreationTime on the copies. This is also where you see whether copying kept up
3	Create the destination file system	deploy the template, or steps 4–5 by hand
4	SMB in play?	Then AD join is required. Put the reachability check here
5	Restore	Wait for Lifecycle: CREATED. OntapVolumeType reads DP while restoring
6	Business validation	Data match and application startup. Databases need a consistency check
7	Return to the original Region?	Backup copies have no failback path. Either continue on the recovery side, or copy back in the other direction

---

Try it now

The same steps with only the values to substitute:

# Change these five lines for your environment
export SRC_REGION=ap-northeast-1
export DST_REGION=ap-northeast-3
export SRC_VOLUME_ID=fsvol-0123456789abcdef0
export SRC_BACKUP_ID=backup-0123456789abcdef0
export DST_BACKUP_ID=   # fill in after the copy

# 1) create a backup
aws fsx create-backup --region "$SRC_REGION" --volume-id "$SRC_VOLUME_ID" \
  --query 'Backup.BackupId' --output text

# 2) wait for AVAILABLE
aws fsx describe-backups --region "$SRC_REGION" --backup-ids "$SRC_BACKUP_ID" \
  --query 'Backups[0].Lifecycle' --output text

# 3) copy to another Region (--region is the destination, --source-region is the origin)
aws fsx copy-backup --region "$DST_REGION" \
  --source-backup-id "$SRC_BACKUP_ID" --source-region "$SRC_REGION" --copy-tags \
  --query 'Backup.BackupId' --output text

# 4) confirm the copy
aws fsx describe-backups --region "$DST_REGION" --backup-ids "$DST_BACKUP_ID" \
  --query 'Backups[0].{Life:Lifecycle,Src:SourceBackupId,SrcRegion:SourceBackupRegion}' --output table

If step 4 shows SourceBackupId and SourceBackupRegion, the copy is real. That is the whole day-to-day preparation.

---

Wrapping up

What this update removed is what you keep running day to day. Putting data in a second Region no longer requires a file system there.

You pay for that at recovery time instead — file system creation (20 minutes measured) plus an RPO as coarse as your backup interval. If minute-level RPO and a failback procedure are requirements, this does not replace SnapMirror. If isolated retention is the requirement, you now have an option that needs nothing standing by.

Three things I plan to do next:

1. Measure cross-account copies. The AWS Backup cross-Region copy and restore are measured now; cross-account needs AWS Organizations and remains documentation only
2. Measure incrementality at production data volume. At 9.4 MiB it disappears into fixed overhead
3. Establish a failure-detection path. Whether CloudWatch or EventBridge can carry copy state is unverified

The most useful thing I learned was smaller than the feature: I believed DP was a permanent property until I tried writing to the volume, and I believed storage efficiency was not carried over until I ran the same restore through the console. Two conclusions drawn from a single observation on a single interface, both wrong.

Thanks for reading.

---

Resources

• AWS What's New: FSx for NetApp ONTAP now supports copying backups across AWS Regions and accounts
• AWS What's New: AWS Backup adds cross-Region and cross-account backup support
• AWS: Copying backups
• AWS: Copying backups within the same AWS account — the backup-copy vs SnapMirror guidance and the RPO / RTO figures
• AWS: Protecting your data with volume backups — restore target confined to the backup's Region, SSD-first restores, background priority
• AWS: Restoring a backup to a new volume
• AWS: CreateVolumeFromBackup
• AWS CloudFormation: AWS::FSx::Volume — the BackupId property
• AWS Backup: Creating backup copies across AWS Regions
• AWS Backup: Creating backup copies across AWS accounts
• AWS Backup: Encryption for backups in AWS Backup (why AWS managed keys cannot do a cross-account copy)
• AWS Backup: Feature availability (the per-Region exceptions)
• Cross-Region and Cross-Account Backup for Amazon FSx for NetApp ONTAP (NetApp Community: the cross-account walkthrough, four architecture patterns, clean room and restore testing)
• AWS: Quotas (FSx for ONTAP)

---

Every resource used for this test has been deleted. The figures are measurements from one specific environment and configuration, and will differ with data volume and setup.