Snapshots, replication, and high availability each address different recovery requirements. They can still remain inside the same AWS account as the workload they protect. If an operator deletes the wrong volume, a pipeline tears down the wrong environment, or credentials are compromised, some of those recovery options may be exposed to the same incident as the primary data.
On August 27, 2026, AWS announced that AWS Backup supports copying Amazon FSx for NetApp ONTAP backups across AWS Regions and AWS accounts. You can copy an FSx for ONTAP (FSxN) volume backup to another Region, another account, or both. Copies can be created by a backup plan or an on-demand copy job, and backup policies in AWS Organizations can apply plans across an organization.
This adds a managed way to keep FSxN recovery points outside the source AWS account.
In this post:
- What actually changed, and what you could already do before this
- Where cross-account copies fit alongside Snapshot copies, SnapMirror, and FSx backups
- Four architecture patterns
- A step-by-step walkthrough: local backup, cross-Region and cross-account copy, then restore in the destination account
- Limits and design considerations before you go to production
- How this feature relates to ransomware response, compliance, and governance
The console screenshots below are from a lab that used a production-style source account and a separately administered destination account in another Region. Redact account IDs and ARNs as needed for your own publishing standards. Confirm current console labels and Regional availability in the AWS documentation before you use the same design in production.
What actually changed
FSx for ONTAP has supported volume backups for a long time, and it already supported copying those backups. What it did not support was crossing an account boundary through a managed service.
Capability | Before | Now |
|---|
In-Region backup copy, same account | Yes (FSx CopyBackup) | Yes |
Cross-Region backup copy, same account | Yes (FSx CopyBackup) | Yes |
Cross-Region backup copy via AWS Backup | No | Yes, on demand or policy based |
Cross-account backup copy | No | Yes, through AWS Backup and AWS Organizations |
Organization-wide cross-account copy rules | Unavailable because FSxN cross-account copy was unsupported | Yes, through AWS Backup policies in Organizations |
The native FSx CopyBackup API still exists and is still useful. It operates within a single AWS account, either in-Region or cross-Region, and only within the same AWS partition. See the Copying backups documentation for its behavior.
The new capability uses AWS Backup. This adds support for AWS Organizations, destination backup vaults, resource-based vault policies, and cross-account copy permissions.
The launch announcement states that the feature is available in commercial AWS Regions where both services are available. The current AWS Backup feature matrix lists exceptions: FSx for ONTAP cross-Region copy is not supported in Middle East (Bahrain) or Middle East (UAE), and cross-Region and cross-account copy are not supported in Asia Pacific (New Zealand), China (Beijing), or China (Ningxia). Check that matrix before choosing source and destination Regions.
Where this fits in an FSxN protection strategy
Cross-account backups do not replace SnapMirror. Each layer addresses a different failure mode and recovery objective.
Layer 1: ONTAP Snapshot copies. Space-efficient, point-in-time copies on the volume support fast recovery from problems such as an overwritten file or a batch job that damaged a dataset. Because the copies reside on the source file system, they do not protect against loss of that file system.
Layer 2: Multi-AZ high availability. A Multi-AZ file system has HA nodes distributed across two Availability Zones. It protects availability during node and Availability Zone failures, but it is not a backup.
Layer 3: SnapMirror replication. SnapMirror provides incremental block replication to another FSxN file system, including one in another Region. It is designed for disaster recovery objectives that require a frequently updated destination volume and a shorter recovery time than a backup restore.
Layer 4: AWS Backup cross-Region and cross-account copies. Recovery points can be copied to a vault in a separately administered account and Region. This can reduce exposure to a compromise or operational error in the source account. Recovery takes longer than activating a replicated volume because the backup must first be restored to an FSxN volume.
Figure 1. Snapshot copies, Multi-AZ, SnapMirror, and cross-account backups cover different failures.
A common design is to use SnapMirror for disaster recovery RPO and RTO requirements, and cross-account backup copies for an additional recovery path. ONTAP SnapLock can provide WORM retention for files on a SnapLock volume. AWS Backup Vault Lock can enforce WORM controls and retention for recovery points in a backup vault. These controls protect different objects and should be evaluated separately.
Four useful architecture patterns
1. The fan-in vault account
Figure 2. A fan-in design centralizes recovery points from multiple production accounts into a separately administered vault account and Region.
A common starting point is a dedicated account for backup copies. Production accounts copy FSxN recovery points into a vault in that account, and interactive access is limited to a controlled recovery role. Vault Lock can enforce retention. AWS also recommends an SCP that denies organizations:LeaveOrganization because an account that leaves the organization retains its backups.
2. Fan-out to multiple isolated accounts
In this pattern, one production account copies recovery points to several destination accounts. It may be useful when copies require separate administration or retention policies.
3. Cross-Region and cross-account in one hop
Because a destination vault ARN contains both an account and a Region, one copy rule can target a vault in another account and Region. AWS describes this as copying to another Region, another account, or both. This can address account-isolation and Regional recovery requirements with one configured destination.
4. The clean room
Incident response may need to examine or recover data without using the production environment. A recovery point can be restored to an FSxN file system in the account and Region where that recovery point is stored. If analysis will occur in a different account, first copy the recovery point there. After the restore completes, FlexClone can create space-efficient, writable copies so that analysts can work on separate datasets without making full physical copies.
The same approach can support recovery validation. A scheduled test can restore a volume, mount it, run application-specific integrity checks, record the result, and then remove the test resources. AWS Backup lists FSx for ONTAP as supporting restore testing. For FSxN, the restore-testing selection must include storageVirtualMachineId in RestoreMetadataOverrides; AWS Backup cannot infer that required value. AWS Backup deletes the restored test volume after the validation window. FlexClone can be used after a separate on-demand restore has completed, but not while a volume restore is in progress.
Getting started: backup, cross-Region cross-account copy, and restore
AWS Backup copies a recovery point, not a live volume. The sequence is always:
- Create a backup in the source account and Region.
- Copy that recovery point to a vault in another account, another Region, or both.
- Restore in the account and Region where the copied recovery point lives, onto an existing FSxN file system.
Step 1: Enable cross-account backup (management account, one time)
Cross-account backup is an organization-level opt-in, so this can only be done with AWS Organizations management account credentials.
- Open the AWS Backup console and go to Settings.
- Under Cross-account backup, choose Enable (or Turn on).
Both the source and destination accounts must belong to the same organization in AWS Organizations. Note that after you disable this setting, in-flight cross-account jobs may continue for up to about 15 minutes due to eventual consistency.
Organization Backup policies, cross-account monitoring, and related toggles are useful at scale, but they are not required for a first on-demand copy. Cross-account backup is the required org setting.
Figure: AWS Backup Settings > Cross-account management. Turn on Cross-account backup. Leave Backup policies and the other toggles off for a first on-demand copy.
Step 2: Create the destination vault and its key (destination account, destination Region)
In the isolated account, in the destination Region, create a backup vault. Two hard requirements:
- It cannot be the default vault. The default vault is encrypted with a key that cannot be shared across accounts.
- Use customer managed KMS keys. Amazon FSx is not independently encrypted by AWS Backup. The AWS Backup encryption documentation states that cross-account copies of resources that are not fully managed by AWS Backup do not support AWS managed keys because their key policies cannot be shared. Use customer managed keys for the source FSxN file system and destination vault. AWS Backup encrypts the copy with the destination vault’s key.
Create a symmetric customer managed key (for example alias/fsxn-lab-dest), then create a Backup vault encrypted with that key. A logically air-gapped vault is a different product path with mandatory Vault Lock and additional isolation features. It is not required for a first cross-account copy.
When the KMS wizard asks for key administrators and key users, select the identity you are already signed in as. You do not need a custom IAM role for this first setup.
Figure: Customer managed KMS key used to encrypt the destination vault.
Figure: Creating a non-default Backup vault encrypted with the destination customer managed key. After creation, copy the vault ARN from the vault summary page; the ARN embeds both the account ID and the destination Region.
Step 3: Add the vault access policy (destination account)
The destination vault needs a resource-based policy allowing backup:CopyIntoBackupVault. Without it, every copy attempt is denied. Any cross-account action other than backup:CopyIntoBackupVault is rejected outright.
Grant it to the whole organization:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "backup:CopyIntoBackupVault",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": ["o-a1b2c3d4e5"]
}
}
}
]
}
Or scope it tightly to specific source accounts:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowProductionCopyIntoVault",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:root"
},
"Action": "backup:CopyIntoBackupVault",
"Resource": "*"
}
]
}
Figure: Vault access policy granting the source account backup:CopyIntoBackupVault.
Step 4: Prepare the source file system, source CMK policy, and a destination restore target
In the source account and Region, create (or identify) an FSx for ONTAP file system encrypted with a customer managed key, plus a volume you will protect. Tag the volume, not only the file system, if you will select resources by tag later (for example Backup = fsxn-demo).
Because FSx is not fully managed by AWS Backup, volume backups inherit encryption from that file system CMK. For cross-account copy, the destination account must be allowed on that source key. If you skip this step, the copy job fails with an AccessDeniedException on the source backup’s KMS key. The destination vault CMK alone is not enough.
In the source account, open KMS > Customer managed keys > the key used by the FSxN file system > Key policy > Edit. Add a statement that grants the destination account root principal cryptographic access. Replace DESTINATION_ACCOUNT_ID with the isolated account ID:
{
"Sid": "AllowDestAccountCrossAccountCopy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::DESTINATION_ACCOUNT_ID:root"
},
"Action": [
"kms:DescribeKey",
"kms:Decrypt",
"kms:Encrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant"
],
"Resource": "*"
}
Keep your existing statements that allow the source account administrators and the fsx.amazonaws.com service principal. Save the policy. You can do this on an existing file system without recreating FSxN or taking a new backup; then retry the copy on the same recovery point.
Because restore creates a new volume on an existing file system in the same Region as the recovery point, also create an FSxN file system and SVM in the destination account and Region before you need them for recovery validation.
Figure: Volume on the source FSx for ONTAP file system in the production account (source Region).
Figure: Volume tagged for backup selection (Backup = fsxn-demo).
Figure: Destination FSx for ONTAP file system in the destination account and Region, ready to receive a restored volume.
Step 5: Create a local backup in the source account (prerequisite)
Create a non-default source vault encrypted with the source file system’s customer managed key. Then create an on-demand backup of the volume. This step is still same-account and same-Region. That is expected: you need a completed recovery point before AWS Backup can copy it.
If the console prompts you to create AWSBackupDefaultServiceRole, allow it. The AWS managed policy AWSBackupServiceRolePolicyForBackup includes backup:CopyFromBackupVault and backup:CopyIntoBackupVault. Those identity permissions must also align with the destination vault resource policy from Step 3.
Figure: Source vault encrypted with a customer managed key (not the default vault).
Figure: On-demand backup of the FSx volume into the source vault. Wait for the backup job to complete before starting the copy.
Step 6: Copy across Region and account (the new capability)
In the source account, open the completed recovery point and choose Copy:
- Toggle Copy to another account’s vault.
- Paste the destination vault ARN from Step 2. The destination Region is taken from the ARN, so one copy job can change both account and Region.
- Confirm the destination differs from the source Region shown in the console, then submit the job.
- Watch progress under Jobs > Copy jobs.
This is the capability that was missing for FSx for ONTAP before the August 2026 launch: managed cross-account copy through AWS Backup, including cross-Region in the same hop when the vault ARN points to another Region.
Figure: On-demand copy to another account’s vault. The vault ARN includes the destination account and Region.
Figure: Completed copy job in the source account.
In the destination account and Region, open the isolated vault and confirm the copied recovery point is present.
Figure: Recovery point visible in the destination account vault after the cross-Region, cross-account copy.
Step 7: Automate with a backup plan copy rule (optional for first test, recommended for production)
For ongoing protection, create a backup plan in the source account with tag-based selection on the volume (Backup = fsxn-demo) and a copy rule that targets the destination vault ARN. The plan still creates a local recovery point first, then starts the copy. Organization backup policies can apply the same pattern across accounts later; they are not required for an account-level plan.
Figure: Backup plan with a local source vault and a copy rule targeting the destination vault. Resource assignment uses the volume tag (Backup = fsxn-demo).
Step 8: Restore in the destination account and Region
AWS Backup does not restore a resource directly from one account into another. Copy the recovery point into the recovery account and Region, then restore it there. An FSx for ONTAP backup is restored as a new volume on an existing FSxN file system in the same Region as the backup.
In the destination account:
- Open the copied recovery point and choose Restore.
- Select the destination file system and SVM from Step 4.
- Provide a new volume name (for example
restored_demo). ONTAP volume names use underscores, not hyphens. - Complete the restore job, then confirm the volume is available on the destination file system.
If the destination account has never used Amazon FSx, use the service there first so that its required service-linked role exists before the recovery exercise. Do not start FlexClone until the restore job has finished.
Figure: Restore targeting the destination file system and SVM in the destination Region.
Figure: Restored volume available on the destination FSx for ONTAP file system.
A backup copy is a recovery point, not a complete recovery environment. You can keep an FSxN file system warm in the recovery Region or provision one as part of a tested recovery runbook. Either way, validate restore before you depend on the design in production.
Things to know before you go to production
Limits that affect production design:
- FlexGroup backup copies are not supported. Amazon FSx does not support copying FlexGroup volume backups through native
CopyBackup or AWS Backup. FlexGroup volumes can be backed up in place, except that SnapLock FlexGroup volumes cannot be backed up. Use SnapMirror when a FlexGroup volume requires cross-Region replication. - FSxN backups do not transition to cold storage. The AWS Backup feature matrix does not list lifecycle-to-cold-storage support for FSx for ONTAP. Separately, AWS Backup does not support cross-account copies into cold tiers for any resource. Plan FSxN retention around warm backup storage.
- Partition boundaries apply. Native FSx cross-Region copies work within the commercial, China, or GovCloud partition, but not between those partitions. AWS Backup cross-account copy for FSx for ONTAP is not supported in the China Regions. Consult the feature matrix for additional Regional exceptions.
- The first copy is full. The AWS Backup cross-account documentation states that the first cross-account copy is full and that subsequent copies are generally incremental when the service supports incremental backups. FSx for ONTAP supports incremental backup. Validate the resulting transfer and storage behavior for your volume and destination before estimating production cost.
- Source backups must be available before they can be copied, and you cannot delete a source backup while a copy of it is in flight. There is a short delay after the destination copy becomes available before the source can be deleted, which matters if your automation retries deletes aggressively.
- More than one quota may apply. The Amazon FSx backup-copy documentation lists limits of five copy requests in progress for one volume to one destination Region and KMS key, and 1,000 in-progress copy requests per account. AWS Backup also has copy-job quotas. Its documented quota of 100 concurrent in-Region or cross-Region copy jobs applies to fully managed resource types, and Amazon FSx is not fully managed by AWS Backup. AWS does not document a single combined quota model for FSxN copies through AWS Backup, so confirm applicable quotas with AWS before scheduling a large deployment.
- Keep the vault account in the organization. If a destination account leaves the organization, it keeps the backups. Attach an SCP denying
organizations:LeaveOrganization to your vault account. - Vault Lock does not override AWS account closure. If an account containing a locked vault is closed, AWS retains the backups during the 90-day post-closure period. AWS deletes them if the account is not reopened during that period.
- Constrain destinations deliberately. Once cross-account backup is enabled, member accounts can configure destination vaults. AWS documents SCP examples using
backup:CopyFromBackupVault and backup:CopyIntoBackupVault, scoped by vault tag, account ID, or organizational path, to limit approved destinations. - Cost the data movement. For a cross-Region copy, the sending account pays the data-transfer charge and the receiving account pays for destination backup storage. Restores and AWS Backup Audit Manager evaluations can add charges. The first cross-account copy is full. AWS states that later copies to the same destination account and vault are generally incremental when the service supports incremental backups, and FSxN backups are incremental. Measure copy behavior and cost with your own volumes before producing a production estimate.
Security, compliance, and governance considerations
Ransomware and recovery isolation
Attackers may target recovery mechanisms before encrypting production data. They can try to delete snapshots, break replication relationships, or remove backups by using credentials obtained from the affected environment.
A destination vault policy can limit the source account to backup:CopyIntoBackupVault. Under that design, permissions from the source account alone do not grant access to read or delete existing recovery points in the destination account. This isolation depends on correct IAM, KMS, vault policy, Organizations, and destination-account controls.
AWS Backup Vault Lock in compliance mode can prevent retention from being shortened after its grace period expires, including by the destination account’s root user. ONTAP SnapLock separately enforces WORM retention for files stored on SnapLock volumes. These controls can be combined, but they protect different copies and require separate configuration.
Compliance and immutability
Some organizations use the 3-2-1-1-0 guideline: three copies, two types of storage, one off-site copy, one offline or immutable copy, and verified recoverability. Cross-account copies can contribute to the isolated-copy requirement, while Vault Lock can add immutability. Whether a design satisfies a regulation or internal control depends on the complete architecture and operating procedures.
Using a managed backup plan can simplify audit evidence compared with maintaining custom copy automation. Reviewers can inspect the plan, Organizations policy, vault and KMS policies, job history, and compliance reports.
Placing the destination vault in a separately administered account can also support separation of duties. IAM and Organizations controls can prevent workload administrators from managing the destination copies. Organizations should map this design to their specific regulatory and internal-control requirements.
Central policy and evidence
Large AWS environments also need a consistent way to apply policy and collect evidence across accounts.
Backup policies in AWS Organizations can apply backup plans, including copy rules, across accounts and organizational units. FSxN tags used for backup selection must be applied at the volume level, not only at the file-system level.
AWS Backup Audit Manager includes controls that evaluate whether resources are covered by a backup plan, meet minimum retention, and have scheduled cross-Region or cross-account copies. It can generate reports in an S3 bucket. These controls evaluate configuration and backup activity; they do not replace application-level restore validation. Audit Manager and cross-account management are not available in every AWS Region, so check the AWS Backup feature matrix for each Region in the design.
Figure 3. Central policy application and compliance reporting across accounts.
Takeaways
- AWS Backup now copies FSx for NetApp ONTAP backups across Regions and accounts, on demand or through backup plans. Review the AWS Backup feature matrix for Regional exceptions.
- Cross-account copies add account isolation. A copy in a separately administered account provides a recovery path that does not depend on access to the source account.
- Use the features for their intended recovery objectives. SnapMirror supports disaster recovery RPO and RTO requirements. Cross-account backups add an isolated recovery path. SnapLock and Vault Lock provide different WORM controls.
- Start with a fan-in vault account. One isolated account, customer managed KMS keys on both the source file system and the destination vault, a
CopyIntoBackupVault vault policy, the destination account on the source FSx CMK policy, and one copy rule per backup plan. - Use a narrowly scoped destination vault policy. Grant the source account only
backup:CopyIntoBackupVault. Correctly configured source-account permissions do not grant read, delete, or retention-management access to destination recovery points. - Apply and evaluate policy centrally. Organizations backup policies can apply plans across accounts. Backup Audit Manager can evaluate coverage and copy rules and generate reports.
- Test the restore. Recovery requires a local backup first, then a copy in the destination account and Region, plus an FSxN file system on which to create the restored volume. AWS Backup restore testing can schedule restore jobs, but its FSxN selection requires a
storageVirtualMachineId override and application-level validation is still required.
Start with a non-production volume and test backup, copy, and restore before using this design in production.
Resources:
