Direct answer
Immutable and air-gapped backups address different failure paths. Immutability resists modification during a defined retention window; an air gap reduces continuous reachability. High-impact environments commonly need both: fast immutable recovery for normal incidents and a slower independently controlled copy for control-plane compromise.
How to frame the decision
Architecture decisions should be evaluated against shared failure domains. Geographic distance alone does not create independence when identities, management tools or deletion privileges are shared.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
What should an AWS logical-air-gap acceptance test prove?
The most valuable acceptance test is not vault creation; it is a cross-account restore into a clean account using a resource type and encryption path that the service currently supports.
- Map every protected resource to the current AWS Backup feature-availability table.
- Share only the required recovery path and verify that the recovery account cannot mutate the source recovery point.
- Record the identity, keys, network, service quotas and elapsed time required to make the restored workload usable.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Threat model | Identify whether the primary concern is stolen credentials, software vulnerability, malicious insider or provider control-plane failure. | A threat-to-control matrix showing which copy survives each scenario. |
| Recovery speed | Use an online immutable tier for rapid restore and reserve offline media for catastrophic cases. | Measured retrieval and restore times for both tiers. |
| Retention authority | Separate the person who creates backup policies from the role that can alter protected retention. | Role exports and a failed retention-shortening test. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Draw the actual trust and data flows before changing controls.
- Translate the requirement into a pass/fail test for immutable vs air-gapped backup for ransomware recovery.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- Marketing uses air gap to describe storage that is continuously authenticated and reachable.
- Immutable retention expires before the expected ransomware dwell time.
- Offline media exists but keys, catalogs or compatible drives are unavailable.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Record the design decision, owner, exception and next test date.
- A tested requirement exists for: Threat model.
- A tested requirement exists for: Recovery speed.
- A tested requirement exists for: Retention authority.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Which sources support the current claims?
Official sources establish current product behavior or the public incident facts. They do not convert the anonymized practitioner observations into vendor guarantees.
- AWS Backup: Logically air-gapped vaultOfficial documentation · Current behavior, sharing model, resource limitations and comparison with standard vaults.
- AWS Backup: Vault LockOfficial documentation · Current governance and compliance mode behavior.
- AWS Backup: Multi-party approvalOfficial documentation · Current protected-operation approval model for logically air-gapped vault recovery.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
Is AWS Backup Logically air-gapped vault the same as Vault Lock?
No. AWS documents logically air-gapped vaults as always using Vault Lock in compliance mode while also supporting a separate-account restore path through sharing; a standard vault can optionally use Vault Lock without that same recovery model.
Can another AWS account restore from a logically air-gapped vault?
Yes, when the vault is shared and the resource supports the required path. Treat this as a testable capability because resource type, encryption and Region constraints can change the answer.
What is the most important proof-of-concept test?
Restore a representative workload from an account that does not own the source vault. Continue until the application and business data are validated, then retain the logs and close the disposable recovery account if it has no continuing purpose.