Seeing and restoring a RAM-shared logically air-gapped vault from another account and Region — measured

The earlier post copied an Amazon FSx for NetApp ONTAP (hereafter FSx for ONTAP) backup from Tokyo to Osaka and restored it, all inside one account. In September 2026, AWS Backup added logically air-gapped vault support for FSx for ONTAP, and trying that is what prompted this post. It picks up where the earlier one stopped: an AWS Backup logically air-gapped (LAG) vault owned by another account, shared over AWS RAM so the recipient can see it, and restored into the recipient's own file system. The earlier post was a same-account cross-Region copy. This one is about visibility and restore across the account boundary.

Up front:

• A LAG vault owned by one account becomes visible to another account over AWS RAM (V1). The recipient's --by-shared lists exactly one vault, its ARN account is the owner, and VaultType is LOGICALLY_AIR_GAPPED_BACKUP_VAULT. It is visible in both Tokyo (ap-northeast-1) and Osaka (ap-northeast-3).
• The share is one-directional. The owner's own --by-shared is empty (V2) — shared-with-me is not shared-by-me.
• The recipient must name the owner's account. A list-recovery-points call without --backup-vault-account-id is AccessDeniedException; with it, it succeeds and returns one recovery point (V4).
• The portal visualizes, the CLI restores. With the shared-vault ARN in its IAM policy the portal shows the air-gap chip and the owner account (V3, V5), but the restore dialog's confirm button stays disabled — the portal does not start the restore.
• Revoking the share drops the vault within 1–2 seconds in both Regions (V6); later calls return AccessDeniedException. An already-restored volume is untouched.
• The shared recovery point restored into the recipient's existing file system, job COMPLETED in 1362 s (~22.7 min), the restored volume reached CREATED (1 GiB, junction /vol_restored) (V7).

Every figure is n=1, one environment, one run: 2026-10-12 (JST), Tokyo primary + Osaka secondary, SINGLE_AZ_1 128 MBps 1024 GiB, aws-cli 2.36.5. Not a generalization to another environment or scale.

Scope: visibility of a shared LAG vault from a recipient account across two Regions (V1, V2, V4), the portal's read path (V3, V5), revocation (V6), and a restore from the shared recovery point into the recipient's existing file system (V7).

Out of scope: multi-party approval (MPA — design only, not run, because it needs two AWS Organizations and a 3–20 person approval team that a single-org two-account lab cannot provide); the organization-sharing path (E13 — this environment used the invitation path with organization sharing off); a cross-Region restore into a recipient file system in that Region (E6 — this run kept to visibility and the same-path restore).

Shape of the setup

The point is that the vault lives in the owner account and the recipient only sees and restores it. The owner holds the air-gapped copy; the recipient never owns the vault, only the volume it restores.

On vendor neutrality: this post evaluates the shared-LAG-vault path on technical grounds only. SnapMirror and the backup-copy / shared-vault paths each suit a different context, and neither is framed as better than the other. The recommended option's own constraints are stated alongside the others.

Who it's for

• You want a tamper-resistant retention layer in a separate account from production
• You want backup copies to land outside your own account
• You are isolating the owning and the restoring account against ransomware or credential compromise
• You want to know which operations the portal handles and which the CLI handles

What changed from the backup-copies post — where it is seen from

The earlier post was about where a backup can live: both source and destination inside one account. This post is about an owner's LAG vault being shared to another account, and the recipient seeing it and restoring it — across the account boundary.

Blur the account boundary and the runbook comes out wrong: the recipient cannot list recovery points without naming the owner account, and the owner can revoke visibility at any time while the recipient's restored volume stays put.

Test environment

Do not use these n=1 durations as an RTO basis for your environment. They are measured against a 1 GiB volume with one recovery point, where fixed overhead dominates.

What I measured (V1–V7)

One shared vault, seen from the recipient (V1, V2)

Running --by-shared in the recipient account returned exactly one LAG vault shared by the owner. Its ARN account is the owner, and VaultType is LOGICALLY_AIR_GAPPED_BACKUP_VAULT. 18 s.

Two quirks of the list: the by-shared row has no VaultState and shows NumberOfRecoveryPoints 0. The count populates on the vault detail, not on the list.

The recipient's detail view shows the vault type (logically air-gapped), the compliance-mode lock, a one-week retention, and one recovery point.

The same shared vault and recovery point were visible to the recipient in Osaka, the second Region. The share holds in both Regions.

The direction checks out too (V2): the owner's own --by-shared is empty in both Regions. Shared-with-me and shared-by-me are different lists, and this vault appears for the recipient, not the owner.

The owner side shows a shared status (V5)

Seen from the owner, the same vault carries a "shared" status and the RAM-share row to the recipient account.

The copy jobs — from the standard vault into the Tokyo and Osaka LAG vaults — both completed. Which Region's list a cross-Region copy job lands in is in a later section.

A call without the account ID is denied (V4)

When the recipient lists recovery points without --backup-vault-account-id, it is AccessDeniedException. With the owner's account ID it succeeds and returns one recovery point. The ARN shape is arn:aws:backup:<region>:<owner>:recovery-point:<id>. Being shared is not the same as being readable in the recipient's plain context — the owner account has to be named. 18 s.

The portal visualizes; it does not start the restore (V3, V5)

Tested with the shared-vault ARN added to the deployed portal's role. With it added, listSharedBackupVaults succeeds without an error and the screen shows the air-gap chip and the owner account.

This is the design line. The restore dialog opens, but its confirm button stays disabled, and the portal does not initiate the restore. The restore is the job of the CLI script (08); the portal handles visualization and selection. The arn-present spec passed both of its tests. 41 s.

Revoking the share drops it in 1–2 seconds (V6)

Revoking the share dropped the vault from the recipient's --by-shared list in about 1–2 seconds in both Regions. Later list-recovery-points calls return AccessDeniedException. A volume already restored before the revoke is unaffected — visibility and the data materialized on the recipient side are different things. 2 s.

Restore from the shared vault into the recipient's existing file system (V7)

The shared vault's recovery point restored into the recipient's existing file system. The job reached COMPLETED in 1362 s (~22.7 min). The restored volume vol_restored reached CREATED — 1 GiB, junction /vol_restored. The restore role was accepted and the Project tag was applied.

So the full path holds: a LAG vault owned by another account, seen by the recipient, and restored on the recipient side.

Constraints and out-of-scope

Stated as scope, not as defects.

• MPA is design-only. The template ships an MpaApprovalTeamArn parameter (default empty), the docs mark it unverified, and it is tracked as a follow-up issue. It is not run here because MPA needs two AWS Organizations and a 3–20 person approval team, which a single-org two-account lab cannot satisfy.
• The organization-sharing path (E13) is not recorded, because this environment used the invitation path with organization sharing off.
• A cross-Region restore into a recipient file system in that Region (E6) was not run — this run kept to visibility and the same-path restore.

Where a cross-Region copy job appears

One manual observation, separate from the scripted V-items (observed once). The cross-Region copy job (Tokyo source → Osaka LAG vault) appeared in the source Region's list-copy-jobs, carrying the destination vault ARN in ap-northeast-3. It did not appear in the destination Region's list. If you watch only the destination side for progress, you will not find it — that is the operational catch. Both copies' recovery points share the same delete date (source-backup creation time + 7 days), cross-Region included.

Choosing between this and SnapMirror

The shared-vault path and SnapMirror carry different things. This is not a ranking.

Stated symmetrically, including the recommended option's constraints: the shared-vault path takes 22.7 min to restore (n=1, 1 GiB) and its restore does not complete from the portal; SnapMirror needs cluster peering and a destination file system standing at all times. Running both is coherent — SnapMirror for availability, the shared LAG vault for a tamper-resistant retention layer in a separate account.

What's next

Each of these needs a real environment or a different org/account shape than this run had, so they are tracked as follow-up issues rather than folded in here. The plan is to cover them in later posts in this series.

• Measure the cross-Region restore (E6) into a recipient file system in that Region. This run kept to visibility and the same-path restore. Tracked in issue #479.
• Measure the organization-sharing path (E13). This run used the invitation path only. Tracked in issue #479.
• Run MPA on a two-org, approval-team setup. It is design-only here. Tracked in issue #471.

The most useful thing I learned was smaller than the feature: being shared and having the data materialized on the recipient side are different states. Revoking the share removes visibility — an owner-side action — but a restored volume belongs to the recipient and stays.

Thanks for reading.

Earlier post: AWS Backup now copies FSx for ONTAP backups across Regions and accounts — measured Tokyo to Osaka

Japanese version (はてなブログ): RAM で共有した論理エアギャップボールトを、別アカウント・別リージョンから見て復元する

Repository

The lab that produced these screenshots — the CloudFormation templates, the scripts, and the verification record — is here: infrastructure/shared-backup-vault-lab.

Resources

• What's New: AWS Backup adds logically air-gapped vault support for Amazon FSx for NetApp ONTAP — the release this post verifies
• AWS Backup: Logically air-gapped vault
• AWS Backup: Creating backup copies across AWS accounts
• AWS RAM: Sharing your resources
• AWS Backup: ListBackupVaults / --by-shared
• AWS Backup: Multi-party approval (MPA)
• AWS: Restoring an FSx for ONTAP backup to a new volume
• AWS Storage Blog: Inside the AWS Storage Assessment — how intelligent analysis replaces guesswork — related for planning: its workload classification and data-protection cost modeling inform the standing-file-system vs. backup-only cost trade-off discussed above

The file systems, SVMs, volumes, standard vault, and restored volume used for this test have been deleted and billing is stopped. The logically air-gapped vaults, under a compliance-mode lock, cannot be deleted until their recovery points' retention (source-backup creation time + 7 days) expires, and are deleted after that. The figures are measurements from one specific environment and configuration (n=1), and will differ with data volume and setup.