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

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: backup-copy-cross-region-en-dark@2x.png)

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.

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

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.

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.

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.

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.

If you run ONTAP on-premises

Prerequisites and permissions

Prerequisites

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.

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:

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).

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.

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.

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.

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 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.

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.

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.

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:

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.

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).

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.

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.

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.

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.

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.

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.

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.

Monthly cost of a Single-AZ minimum configuration:

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.

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.

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.

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

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.

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.

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.

(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.

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.

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.

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.

Messages I actually saw:

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.

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:

"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:

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.

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.

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:

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:

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.