AWS Backupで統合バックアップ — 世代とクロスリージョン

バックアップは「取れている」ことより「戻せる」ことが本質です。AWS Backupで複数サービスの世代管理・クロスリージョン・改ざん防止・復旧テストをどう設計するか、現場の判断軸で整理します。

「バックアップは毎晩取れています」——監査や障害対応の場面で、この一言だけでは通用しません。問われるのは、狙った世代に、狙った時間内で、確実に戻せるかどうかです。AWS Backupは、EBS・RDS・EFS・DynamoDBなど複数サービスのバックアップをプラン単位で一元管理し、世代・保持・クロスリージョン・改ざん防止・復旧テストまでを一つの枠組みで扱えるサービスです。本記事では、SIer/情シスの実務者が設計時に踏むべき判断軸と、現場でつまずきやすい落とし穴を整理します。

01なぜ「サービス個別」から「AWS Backup一元管理」へ寄せるのか

EBSスナップショット、RDS自動バックアップ、DynamoDBのPITR——各サービスにはそれぞれ固有のバックアップ機構があります。小規模なら個別運用でも回りますが、アカウント数・リソース数が増えると、保持ポリシーの粒度がサービスごとにバラバラになり、「どのリソースが本当に保護されているか」を棚卸しできなくなります。ここが監査で最も刺さるポイントです。

AWS Backupは、これらをバックアッププランという共通の器で束ね、タグベースでリソースを自動選択し、保持ルールとコピールールを一元的に適用します。結果として「保護対象の網羅性」を1画面で示せるようになります。マルチアカウント環境での統制についてはマルチアカウント統制、DR全体のRPO/RTO設計はマルチリージョンDRのRPO/RTO設計もあわせてご覧ください。

現場のコツ：移行初期は既存のサービス個別バックアップをいきなり止めないでください。AWS Backup側でリソースが正しく捕捉され、復旧テストが通ることを確認してから、旧設定を段階的に外すのが安全です。二重取得の期間コストは、取りこぼしリスクより安いと割り切ります。

02バックアッププランの基本構造 — ルールと選択の分離

AWS Backupの設計は、大きく2つの要素に分かれます。

バックアップルール：いつ取るか(スケジュール)、どれだけ残すか(保持期間)、どこへコピーするか(コピー先リージョン/アカウント)、ライフサイクル(コールドストレージ移行)を定義します。1プランに複数ルールを持たせられます。
リソース割り当て(選択)：どのリソースを対象にするか。ARN直接指定に加え、タグ条件で動的に選択できます。「Backup=daily のタグが付いたリソースは自動で日次プランへ」といった運用が定石です。

この「ルール」と「選択」の分離が肝です。新規リソースにタグを付けるだけでバックアップ対象に組み込まれるため、リソース追加のたびにプランを触る必要がなくなります。逆に言えば、タグ運用が崩れると保護漏れが静かに発生するので、タグの付与自体をSCPやAWS Configで強制する設計が望ましいです。

図：タグで選択されたリソースがプランで束ねられ、プライマリVaultからコピー先Vaultへ複製され、Vault Lockで保護される。

03世代と保持 — ライフサイクルとコールドストレージの落とし穴

保持設計では「何日残すか」だけでなく「いつ安価なコールドストレージへ移すか」を決めます。AWS Backupのライフサイクルは、ウォームストレージからコールドストレージへ自動移行し、コストを抑えられます。ただし、ここには実務でよく踏む制約があります。

コールドストレージへ移行したバックアップは、最低90日間はコールドに置く必要があります。したがって保持期間は「コールド移行日数＋90日」以上でなければ設定が通りません。
コールドへの移行日数は、一度コールドへ移った後は変更できません。
コールドストレージ階層に対応するのはEBS・EFS・DynamoDBなど一部リソースに限られます(対応状況は公式のFeature availabilityで最新を確認)。RDSスナップショットなどは同じようにコールド最適化されるわけではない点に注意します。

数値・料金・上限はバージョンや対象リソースで変わるため、実装前に必ず公式で最新を確認してください。世代設計の考え方は、日次で短期・週次で中期・月次で長期といった多階層のルールを1プランに束ねるのが定石です。日次30世代は短期の即時復旧用、月次を長期保持のコンプラ用、と役割を分けます。

現場のコツ：「保持期間=Always(無期限)」を安易に選ばないでください。特にVault Lockのコンプライアンスモードと組み合わせると、無期限のバックアップは削除できず永久課金になります。保持は必ず具体的な日数で設計し、コンプラ要件の年数(例：7年=約2,557日)に合わせます。

04クロスリージョン/クロスアカウントコピー — DRとランサム対策の要

同一アカウント・同一リージョンにしかバックアップがない状態は、リージョン障害でもアカウント侵害でも一発で全滅します。AWS Backupは、バックアップルールのコピー設定で、別リージョン・別アカウントのVaultへ自動複製できます。これがDRとランサムウェア対策の基盤になります。

設計上、押さえておくべき挙動を整理します。

継続的バックアップ(PITR)のコピーはスナップショット化する：クロスリージョンまたはクロスアカウントへコピーすると、コピー先ではポイントインタイムリストアが使えなくなり、периодのスナップショットとして扱われます。「DR先でも秒単位で巻き戻せる」という前提は置かないでください。
コールド階層のクロスコピーは非対応：コールドストレージのバックアップは、そのままクロスリージョン/クロスアカウントへコピーできません。
RDS系の同時クロスコピー：RDS・Aurora・DocumentDB・Neptuneは、単一のコピーアクションでクロスリージョンとクロスアカウントのスナップショットコピーを同時に実行できます(2025年10月にGA)。ただしRDS Multi-AZ「クラスター」はコピー操作自体が非対応という別の制約が残るため、対象がMulti-AZクラスターかどうかは事前に確認します。

クロスアカウントコピーはAWS Organizations環境が前提で、コピー先アカウントのVaultアクセスポリシーとKMSキーの権限設計が肝になります。IAMの最小権限の考え方はIAM最小権限の現実解、KMS設計はKMS暗号化設計もあわせて確認してください。

05Vault Lock — 改ざん・誤削除からの最後の砦

ランサムウェアの被害を決定づけるのは「バックアップまで暗号化・削除されるか」です。ここを守るのがAWS Backup Vault Lockです。Vault LockはVaultにWORM(write-once, read-many)を適用し、保持期間が満了するまでバックアップの削除・変更を拒否します。モードは2つあります。

ガバナンスモード：十分なIAM権限を持つ利用者であればロックの解除・管理が可能。組織内の指定担当者だけが変更できる、という統制目的に使います。
コンプライアンスモード：猶予期間(グレースタイム、最低3日=72時間)を過ぎると、Vaultとロックはいかなる利用者(ルートユーザーを含む)およびAWSでも変更・削除できなくなります。SEC 17a-4等の規制対応を想定した最も強い保護です。

コンプライアンスモードは強力ゆえに取り返しがつきません。グレースタイム中はDeleteBackupVaultLockConfigurationでロックを外せますが、グレースタイム満了後は不可逆です。設定はput-backup-vault-lock-configurationで行い、--changeable-for-daysを指定するとコンプライアンスモード、省略するとガバナンスモードになります。

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name my_vault_to_lock \
  --changeable-for-days 3 \
  --min-retention-days 7 \
  --max-retention-days 30

現場のコツ：コンプライアンスモードを本番へ入れる前に、必ず検証用Vaultでグレースタイムを長め(例：数日)に取ってドライランしてください。無期限保持のバックアップが混ざったままロックすると永久課金になり、アカウントを閉じてもAWSは90日後にVault内容を削除する挙動になります。最小/最大保持期間の設定でガードするのが定石です。

図：ガバナンスモードはIAM権限で解除可能。コンプライアンスモードはグレースタイム満了後、ルートユーザーやAWSでも変更・削除できなくなる。

06復旧テスト — 「戻せる」を自動で証明する

バックアップ設計の最大の盲点は「取れているが、戻せるか誰も確認していない」状態です。AWS Backupの復旧テスト(restore testing)は、この検証をスケジュール化・自動化します。定期的に実際の復元ジョブを走らせ、復元にかかった時間(RTOの実測)を記録し、テスト後は復元したリソースを自動削除します。

実務での使い方のポイントです。

対応リソース：Aurora、DocumentDB、DynamoDB、EBS、EC2、EFS、FSx(Lustre/ONTAP/OpenZFS/Windows)、Neptune、RDS、S3。AWS Backupが作成した復旧ポイントが対象です。
復元先アカウント：ベストプラクティスは、テスト専用アカウントを指定して本番環境と分離することです。
検証の深掘り：単に復元できたかだけでなく、EventBridgeとLambdaを組み合わせて、接続性チェックやデータ整合性の検証まで自動化できます。検証ステータス(VALIDATING/SUCCESSFUL/FAILED/TIMED_OUT)はAWS Backupコンソールに表示され、独自の検証結果を「送信」する場合のみPutRestoreValidationResult APIをCLI/SDK/Lambda経由で使います。
監査連携：AWS Backup Audit Managerと連携し、「復元が目標時間内に完了したか」をコントロールとして評価できます。RTO達成の証跡を継続的に残せます。

現場のコツ：復元テストで生成されるリソースにはawsbackup-restore-testタグが付与され、それを目印にAWS Backupが自動削除します。このタグを運用スクリプトで誤って剥がすと、テストリソースが消えずに課金が残ります。タグの上書き・削除を制御する設計を最初に入れておいてください。

07コンプライアンス要件への落とし込み — 決定表

ここまでの要素を、実際の要件からどう選ぶか。SIerの現場でよく問われる観点を決定表に整理します。

要件・状況	推奨する構成	理由・注意点
金融/規制業種でWORM必須	Vault Lock コンプライアンスモード＋最小/最大保持期間	ルート含め削除不可。無期限保持を混ぜない。SEC 17a-4等を想定
誤削除防止が主目的	Vault Lock ガバナンスモード	指定担当者のみ変更可。不可逆ではなく運用しやすい
リージョン障害へのDR	クロスリージョンコピー＋別リージョンVault	PITRはコピー先でスナップショット化する点に留意
アカウント侵害/ランサム対策	クロスアカウントコピー(別Org管理下の隔離アカウント)	コピー先の権限を本番と分離。air-gap的に運用
RTOの証跡を監査に出す	復旧テスト＋Audit Manager連携	復元時間を実測・記録。テスト専用アカウント推奨
長期保持でコスト最適化	ライフサイクルでコールド移行(対応リソースのみ)	コールド最低90日、移行日数は後から変更不可

いずれの構成も、対応可否・上限・料金はリソースとリージョンで差があります。実装前に必ず公式ドキュメントで最新の対応状況を確認し、検証環境でドライランしてから本番へ適用してください。

—まとめ

AWS Backupは、複数サービスのバックアップを一元管理し、世代・保持・クロスリージョン/クロスアカウント・改ざん防止・復旧テストまでを一つの枠組みで扱えます。設計の要点を再掲します。

プランは「ルール」と「タグ選択」で組み、リソース追加に強い構造にする
コールド移行は最低90日・移行日数は変更不可・対応リソース限定という制約を前提に世代設計する
クロスコピーではPITRがスナップショット化する挙動を織り込む(RDS系は単一アクションでの同時クロスコピーが可能。ただしRDS Multi-AZクラスターはコピー自体が非対応)
Vault Lockはガバナンス/コンプライアンスの不可逆性を理解し、無期限保持を混ぜない
復旧テストで「戻せる」を自動で証明し、RTOの証跡を監査に残す

「取れている」から「確実に戻せる」へ。ここを設計で埋めるのがEMWの仕事です。要件とコンプラ要件を踏まえた設計はお問い合わせから、実際の進め方は導入事例もご覧ください。

—参考(一次情報)

バックアップとDRの設計に不安が残る場合は、お問い合わせください。要件とコンプラ要件を踏まえた設計をご一緒します。

相談する

← ブログ一覧へ戻る