AWS でバックアップを取得するための設定事項
はじめに・想定読者
AWSクラウド上でインフラを運用する際、データのバックアップ戦略はビジネス継続性に直結する重要事項です。本記事ではバックアップ担当者を対象に、AWSでバックアップを設計・設定する際に検討すべきポイントを解説します。
初めに事前に考えておくべき事項を記載します。制約条件や要件定義のようなものです。次に、バックアップ設定において決めるべき事項を記載します。こちらは詳細要件定義や設計のようなものです。
この記事を読み、AWS上で堅牢かつ効率的なバックアップ戦略を立案・実装するためのガイドとしてご活用ください。
事前に考えておくべき事項
対象サービス・リソース
まず、どのAWSサービスやリソースをバックアップの対象とすべきかを明確にします。ビジネスクリティカルなデータやシステムは漏れなくバックアップ対象に含める必要があります。代表的なものは以下の通りです。
データベース (Amazon RDS, Aurora, DynamoDBなど): データベースは定期スナップショットやポイントインタイムリカバリ (PITR) により頻繁にバックアップします。RDSは自動バックアップ機能があり、指定期間のスナップショットとトランザクションログを保持してポイントインタイムで復元可能です。DynamoDBもPITRを有効化すると最大35日前までのデータを復元できます。
オブジェクトストレージ (Amazon S3): S3にはスナップショット機能はありませんが、バージョニングとクロスリージョンレプリケーションを有効化することで削除・上書きに備えた「バックアップ」に類似する耐障害性を確保できます。必要に応じて定期的に別バケットや別リージョンへコピーしアーカイブすることも検討します。
Amazon EC2 (EBSボリューム): EC2インスタンスのデータはEBSスナップショットとして取得します。必要に応じてインスタンスの構成（AMI）もバックアップします。
ファイルストレージ (Amazon EFS): EFSはAWS Backupと連携して定期バックアップが可能です。またEFS自体の増分バックアップ機能も提供されています。
その他サービス: Amazon FSx系サービス（FSx for Lustre/NetAppなど）やAmazon Redshift、Amazon Elasticache、Amazon Neptuneなどもそれぞれスナップショット機能があります。環境によってはこれらも重要データを保持しているためバックアップ対象に含めます。
インフラ構成情報: システム設定やコード自体もバックアップが重要です。たとえばAWSの設定をコード化したCloudFormationテンプレートやTerraformファイル、IAMポリシーのエクスポート、Lambda関数コードなどはソース管理やエクスポートでバックアップし、障害時にインフラ構成自体を迅速に復旧できるようにします。
なお、AWSにはAWS Backupというマネージドサービスがあり、複数サービスにまたがるバックアップを一元的にスケジューリング・管理できます。AWS BackupはEC2/EBS、RDS、DynamoDB、EFS、S3など幅広いサービスをサポートしており、ポリシーベースで自動バックアップやライフサイクル管理、クロスリージョン・クロスアカウントへのコピーも可能です。一方で、各サービス個別のバックアップ機能（例: EBSスナップショット、RDS自動バックアップ、DynamoDB PITR、S3バージョニングなど）を組み合わせて独自に運用することもできます。環境規模や要件に応じて、AWS Backupの集中管理を利用するか、サービス固有機能・スクリプトでバックアップ運用するかを選択します（詳細は後述の「バックアップ取得方法の選択」セクションで比較検討します）。
RPOとRTOの定義と設計への適用
RPO (Recovery Point Objective) と RTO (Recovery Time Objective) はバックアップ・DR計画を語る上で欠かせない指標です。RPOは災害発生時に許容されるデータ損失量（時間）を意味し、最後の正常なバックアップからどのくらい遡った時点までのデータ復元が必要かを表します。例えばRPOが1時間であれば、「障害直前までの1時間以内のデータ損失は許容する」という意味になります。一方、RTOはサービス停止から復旧までの許容ダウンタイム、すなわち「障害発生から何時間以内にサービスを復旧させる必要があるか」を示す目標時間です。RTOが1時間なら、障害発生後1時間以内に業務を再開できなければならないことを意味します。
RPOとRTOの値はできる限り小さいほど望ましいですが、目標を厳しくするほど実現コストやシステムの複雑さは増大します。RPOを満たすにはバックアップ頻度を上げる必要があり、例えば「許容損失が2時間のデータ」であれば最低2時間おきにバックアップを取得する必要があります。またRTOを満たすには高速な復元手段（冗長構成の活用や自動化されたフェイルオーバー）が求められます。RPOとRTOは相互に関連しており、頻繁なバックアップ（低RPO）を行っても復元に長時間かかっては意味がありませんし、逆に高速に復旧（低RTO）できてもバックアップ間隔が長すぎれば最新データを失うことになります。したがってシステムの重要度に応じてRPO/RTOのバランスをとり、適切な技術や手法（バックアップ頻度、冗長化、レプリケーション、クラスタリングなど）を選定することが重要です。
バックアップ設計においては、決めたRPO/RTOを実現できるよう具体策に落とし込む必要があります。例えば「RPO=15分・RTO=1時間」と定義したなら、15分おきのバックアップ取得と、障害発生から1時間以内にリストア完了するための手順・リソースを用意しなければなりません。RPOが極めて短い（ゼロに近い）システムでは継続的なデータ同期やリアルタイムレプリケーションが必要になり、通常のバックアップ運用だけでは賄えない場合もありますので、バックアップ/リストア以外の方法も検討が必要になります。
https://www.skygroup.jp/tech-blog/article/724/ より引用
一方、大半の一般的な業務システムであれば、定期バックアップ＋迅速なリストア手順の組み合わせで数時間以内のRTO/RPOを達成できます。バックアップはDR戦略全体の中で最もシンプルかつ低コストな手段ですが、一般に復旧時間（RTO）やデータ損失時間（RPO）は他の高度な手法より大きくなる点に留意しましょう。
担当者の役割とバックアップ運用プロセス
バックアップの計画・運用には明確な担当者の役割分担と定期的なプロセスが欠かせません。システム規模にもよりますが、一般に以下のような役割・責務を考慮します。
バックアップ戦略の策定: システムオーナーやアーキテクトが中心となり、ビジネス側と協力してRPO/RTOなど要求定義を行い、どのデータをどの頻度・方法でバックアップするか戦略を立案します。対象リソースの洗い出しやクリティカル度の分析（BIA: Business Impact Analysis）もこの段階で実施します。
バックアップ設定・実施: インフラ担当者（または自動化されたジョブ）が、決定した方針に従いAWS Backupのバックアッププランを作成したり、サービス個別のスナップショット取得設定を行います。タグやスクリプトを用いてバックアップ漏れがないよう環境全体に適用します。例えばAWS Organizationsを利用してポリシーベースで全アカウントにバックアップを適用することもできます。
バックアップの監視: 定期バックアップが正しく実行・保存されているかをモニタリングします。AWS Backupはジョブの成否をCloudWatchイベントやSNS通知で検知できますし、CloudTrailでバックアップAPI操作履歴を追跡することも可能です。担当者は失敗ジョブに対処し、必要に応じて再実行やAWSサポートへの問い合わせを行います。バックアップの未実行や失敗が放置されないよう、運用監視体制に組み込みます。
バックアップデータの検証と定期リストアテスト: バックアップは取るだけでなく、いざという時に復元できて初めて意味があります。担当者は定期的にバックアップデータからのリストア試験を行い、データの完全性を検証します。例えば3ヶ月に一度はテスト用環境にバックアップから復元し、想定通りシステムが稼働するか確認します。これにより、万一バックアップが壊れていた・手順に不備があったという事態を事前に発見できます。実際、長年バックアップは取っていたがいざ復旧しようとしたらバックアップが空で何も復元できなかったという笑えない事故も報告されています[※1]。こうした事態を避けるため、「バックアップから復元する」訓練を定期的に実施することが重要です。
復旧手順の整備と周知: バックアップからのリストア手順を文書化し、関係者に共有します。手順書には復旧に必要なAWS権限やコマンド、順序、注意点を具体的に記し、緊急時に担当者以外でも対応できるようにします。事業継続計画(BCP)や災害復旧計画(DR計画)の中にバックアップからの復旧シナリオを組み込み、定期的に演習 (Simulation) を実施しておくことが望ましいです。AWS Backupの操作に慣れておくためにも、従業員がバックアップ復元手順を実際に練習しておくことが推奨されます。
バックアップデータの管理: 保存期間が過ぎた古いバックアップの削除やアーカイブ先への移行を定期的に行います（後述の「保持期間」参照）。必要に応じて法令遵守のために特定バックアップの保持延長や証跡取得（監査用レポートの保管）も担当者が実施します。AWS Backupのライフサイクル管理やAudit Managerを活用するとバックアップ保持状況の監査証跡を自動取得できます。
アクセス制御の管理: バックアップ先へのアクセス権を適切に制御・定期見直しします。原則としてバックアップデータへ読み取り・復元が必要な最小限の権限のみを付与し、削除や変更操作は厳格に制限します。例えば通常のオペレーターにはバックアップの起動権限は与えても削除権限は与えない、といったポリシー設定を行います。この後述べるように、バックアップ用Vaultへのリソースベースポリシーで削除操作を拒否する設定も可能です[※2]。
以上のように、バックアップ運用は「計画→取得→監視→検証→復旧準備」のライフサイクルを継続的に回す取り組みです。一連のプロセスが組織の中で定着するよう、経営者やチームリーダーはバックアップ運用を全社的なBCPの一部として位置付け、定期的な訓練と改善を推進することが重要となります。
想定すべき障害・インシデントシナリオ
バックアップ戦略を検討する際には、どのような障害やインシデントに備えるのか具体的に想定しておく必要があります。ここでは考慮すべき4つのシナリオと、それぞれに対応するバックアップ要件について説明します。
1. 正常なユーザによる本番データストアへの誤操作
シナリオ: アプリケーションのオペレーターや開発者など正当な権限を持つユーザが、誤って本番データを削除・上書きしてしまうケースです。例えばDB上で誤ったクエリを実行してデータを消してしまった、S3バケットの中身をミスで削除してしまった、などヒューマンエラーによるデータ損失が該当します。
バックアップ要件: このシナリオではシステム自体は稼働していますがデータが失われている状態のため、迅速に直前の状態にデータを戻すことが最重要です。したがってRPOを極力短く設定し、頻繁なバックアップや継続的なバックアップを行っていることが理想です。たとえば、RDSであれば自動バックアップとトランザクションログにより数分〜数時間前までポイントインタイム復元できますし、DynamoDBならPITRで直近数分前の状態まで戻せます。S3の場合はバージョン管理が有効であれば、削除されたオブジェクトの旧バージョンを復元するだけで元に戻せます。EBSボリュームの場合、最新スナップショットから新規ボリュームを作成してEC2にアタッチすることで、ファイル単位での救出も可能です。
設計上のポイント: 誤操作は局所的なデータ損失であるため、バックアップの保存先は同一リージョン内でも構いません（リージョン全体の障害ではないので）。重要なのはバックアップ取得間隔であり、トランザクション性の高いデータほど短間隔で取得します。例えば、「毎日深夜1回のバックアップ」ではその日の日中に起きた誤削除には対応できないため、業務時間中は数時間おきに追加スナップショットを取るなど工夫します。またバックアップからの部分復元手順も用意します。誤って削除された一部データだけを戻すには、一旦全体を別環境にリストアし、必要な部分（例えば特定テーブルやファイル）だけを抽出して本番に戻す、といった作業が必要です。緊急時にスムーズに対応できるよう、具体的な手順を決めてスクリプト化・ドキュメント化しておきます。
備考: AWSでは多くのサービスでこうした誤操作に備えた自動バックアップ機能を提供しています。例えばRDSでは自動スナップショットにより最新状態からの復元が容易にでき、定期バックアップ戦略の一部として活用できます。いずれにせよ、人為ミスによるデータ損失は最も発生確率が高いインシデントであるため、それを前提とした高頻度バックアップと迅速復旧手順の整備がバックアップ戦略の基本となります。
2. 攻撃者による権限の乗っ取り（セキュリティ侵害）
シナリオ: 悪意ある第三者がクラウド環境の認証情報を盗み出したり、脆弱性を突いて権限を奪取したりして、AWSアカウント内のリソースを不正操作するケースです。攻撃者はデータの漏えいや破壊を目的としており、本番データのみならずバックアップデータも削除・暗号化しようと試みる可能性があります（ランサムウェア攻撃など）。
バックアップ要件: このシナリオへの対策の鍵は、バックアップを攻撃の被害から隔離し、改ざんや削除を防ぐことです。具体的には以下のような方針をとります。
バックアップデータを別環境に隔離: 万一メインのAWSアカウントやリージョンが乗っ取られてもバックアップが消されないよう、別のAWSアカウントや別リージョンにバックアップコピーを保持します。例えば、計算処理を行わない専用のバックアップ用アカウントを用意し、そこに定期的にバックアップを複製します。このアカウントは外部から侵入されにくく、本番環境が侵害されてもバックアップだけは安全に保管されます。
バックアップの削除禁止（イミュータビリティ）: バックアップが攻撃者に削除・改ざんされないよう、AWS BackupのVault Lock機能を利用してWrite-Once-Read-Many状態で保存します。Vault Lockを有効にすると、一度保存されたバックアップはポリシーで定めた保持期間が経過するまでルートユーザであっても削除や期間短縮ができなくなります。これにより攻撃者が管理者権限を得てもバックアップを消去できず、安全に保たれます。「バックアップVaultのロック」はランサムウェア対策として非常に有効な手段です。
アクセス権の厳格化: 攻撃者に悪用される経路を減らすため、バックアップ関連のIAM権限を最小権限の原則で設定します。例えば通常の運用担当者にバックアップ削除権限は与えず、万一その担当者の認証情報が漏洩してもバックアップを消されないようにします。AWS BackupのバックアップVaultにはリソースベースポリシーを設定でき、特定の操作（例: DeleteRecoveryPoint）を全面禁止したり、許可された役割にのみ限定したりできます。後述するJSONポリシーの例では、全ユーザに対してバックアップ削除をDenyし、一部の管理IAMロールや別AWSアカウントだけ例外で許可する設定を示しています。
複数世代のバックアップ保持: 攻撃の痕跡が発覚するまで時間がかかる場合もあるため、世代を遡ってデータを復旧できるよう適切に長期間のバックアップを保持します。攻撃発生直後のバックアップは既にデータが暗号化/破壊されている可能性があるため、問題のない時点まで戻れるよう数日前～数週間前のバックアップも参照できる状態が望ましいです。
侵入検知との連携: これはバックアップ戦略自体というよりセキュリティ全般の話ですが、万一の侵入に早期に気づければ被害を最小限にできます。AWS BackupのイベントをCloudWatchやSNSでアラートし、異常なバックアップ削除操作が行われたら即時通知・対処する仕組みを設けることも有効です。
設計上のポイント: AWS Backupはクロスアカウント・クロスリージョンへの自動バックアップコピー機能を提供しており、このシナリオで非常に有用です。組織内に別途「バックアップ用アカウント」を作成し、そこにバックアップVaultを用意して、元のアカウントから定期的にバックアップコピーを送ります。AWS BackupのVault間コピーでは、コピー先Vault側にbackup:CopyIntoBackupVaultを許可するリソースポリシーが必要なので事前設定しておきます（後述のコード例参照）。またコピー先では別のKMSキーで再暗号化するため、元のデータキーが漏洩してもコピー後のデータは読めない利点があります。Vault Lockについては一度有効化すると保持期間内の削除やポリシー変更ができなくなるため慎重に扱う必要がありますが、セキュリティ要件が高いシステムでは導入を検討すべきでしょう。
攻撃者による脅威が高まる現代では、バックアップも 「盗まれたり壊されたりしないこと」 まで考慮した設計が求められます。
3. AWSの責任によるサーバ停止（リージョン障害など）
シナリオ: AWS側の大規模障害により、こちらの操作にかかわらずインスタンスやデータベースが長時間利用不可能になるケースです。例えば特定リージョン全体のサービス停止、AZ複数同時障害、AWSサービスのバグによる管理コンソール・API操作不能などが該当します。2021年のAWS東京リージョン障害のように、インフラ側の問題でシステムがダウンする可能性もゼロではありません。
バックアップ要件: このシナリオではプライマリリージョンがしばらく使えないことを前提に、セカンダリリージョンでシステムを復旧させる必要があります。したがってバックアップデータを別リージョンにも保持しておくことが重要になります。リージョン障害への対策としては、以下のような方針が考えられます。
クロスリージョンバックアップ: 定期バックアップを障害発生時に代替とするには、普段から別リージョンへバックアップコピーを取得しておく必要があります。AWS Backupを使えばバックアッププランで自動的に他リージョンへのコピーを組み込めますし、手動でもスナップショットをコピー可能です。例えば東京(ap-northeast-1)のバックアップを大坂(ap-northeast-3)やシンガポール(ap-southeast-1)にコピーしておけば、東京リージョンがダウンしても他リージョンでデータを取得できます。
復旧環境の用意: データだけでなく、復旧先リージョンで迅速にシステムを立ち上げる手順を整備します。あらかじめ他リージョンにパイロットライト環境（小規模の待機系）を動かしておく方法もありますし、バックアップから必要なリソース（EC2やRDSなど）を自動デプロイするスクリプトを用意しておく方法もあります。いずれにせよ、リージョン障害時にはRTO内に代替リージョンで稼働できることを目標に、訓練や自動化を行います。
DNSや設定の切り替え: フェイルオーバー時にはRoute 53のDNS切替やアプリケーションの接続先変更なども発生します。これらも含めた復旧手順を包括的に検討します。バックアップ戦略という枠を越えますが、リージョン障害対策はDR計画全体の話になるため、バックアップはその一部（データの移行）の役割を担う形です。
バックアップ＆リストアを用いたDR戦略ではプライマリリージョンが災害に遭った場合、別リージョンにデータをリストアして新たに環境を立ち上げることになります。この場合、RPOは「最後に別リージョンへコピーされた時点のデータ」まで遡りますので、リージョン間コピーの頻度を上げるほどRPOが短縮されます。またRTOはバックアップを戻してシステムを再構築する時間となるため、環境規模によっては数時間以上かかる場合もあります。RTOを短縮するには、できるだけインフラ構成をコード化して自動展開し、人手の作業を減らすことが有効です。
設計上のポイント: クロスリージョンのバックアップは同一アカウント内で行う場合も別アカウントで行う場合もあります。単一アカウントであれば設定は比較的シンプルですが、障害発生時に他リージョンで誤って全削除といった人的ミスも起こり得るため注意が必要です（極限的には別アカウント＋別リージョンが安全ですが複雑になります）。KMSキーについてはマルチリージョンKMSキーを使うと、複数リージョン間で同じキーIDの鍵を複製でき、復号に利用できます。別リージョンにバックアップをコピーする際、このマルチリージョンキーを導入すれば暗号化設定の管理が容易になります。
4. AWSの責任によるデータ消失
シナリオ: AWSの管理上の不備やハードウェア障害によって、こちらの責任ではないにもかかわらずデータそのものが失われてしまうケースです。AWSは通常各サービスで高い耐久性を確保していますが（例: S3は年99.999999999%の耐久性を謳う）、理論上ゼロではありません。また、過去には特定AZのストレージ故障やソフトウェア不具合で一部のEBSボリュームやRDSインスタンスが永続的に失われた事例もわずかながら報告されています。
バックアップ要件: このシナリオはリージョン全体の物理的消失に近い状況であり、やはり遠隔地へのバックアップが核心的な対策となります。言い換えると、AWSに置いているデータしか存在しないのであれば、AWS側での消失に対してこちらから打てる手はありません。したがってデータのコピーをAWS外にも保持するか、少なくとも別リージョン・別アカウントには常に存在する状態にしておく必要があります。
クロスリージョン/クロスアカウント: リージョン障害と同様、まずは他リージョンや別アカウントへのバックアップコピーが基本です。仮に片方のリージョンでAWSがデータを消失させても、もう一方に独立したコピーがあれば復旧可能です。
オフライン・オフクラウドバックアップ: 考え得る最悪の事態（クラウド事業者そのもののサービス継続不能など）に備えるなら、AWS外部にバックアップをエクスポートすることも検討します。例えば定期的に重要データのスナップショットをオンプレミスにダウンロードしテープ保管する、他のクラウドにコピーする、といった方法です。これは運用コストや手間が大きいため一般的ではありませんが、金融機関など極めて厳密なデータ保全が必要な業界では採用の余地があるかと考えられます。
設計上のポイント: AWS上の複数リージョンにまたがってバックアップを保持していれば、AWS全体で同時にデータ消失が起こらない限り大丈夫です（確率的には非常に低いです）。とはいえ契約上AWSはクラウドの中のインフラ部分までしか責任を負わないため、最終的なデータ保護の責任は利用者側にあることを忘れてはいけません。バックアップはまさにその責任範囲に含まれる対策なので、「AWSが壊さないだろう」と過信せず、自ら二重三重の備えを講じる姿勢が重要です。
バックアップ設定において決めるべき事項
バックアップ取得方法の選択: AWS Backup vs 各サービス個別機能
バックアップ方式としては、大きく「AWS Backupを活用する方法」と「サービスごとに個別にバックアップする方法（DIY方式）」があります。それぞれメリット・デメリットがあるため、環境に適した方法を選択します。
AWS Backupを使う場合: AWS Backupは複数サービスのバックアップを一元管理できるマネージドサービスです。ポリシー（バックアッププラン）を一度設定すれば、対象となるEC2/EBS、RDS、DynamoDB、EFS、S3などのバックアップを自動でスケジューリング・保存してくれます。また前述の通りクロスリージョン・クロスアカウントへのコピーやライフサイクル管理（一定期間後に自動でバックアップをGlacierなど低コストストレージへ移行・満了削除）も組み込めます。組織全体で統一したバックアップポリシーを適用しやすく、タグベースで保護対象を自動検出するなどスケールする環境に適した仕組みが備わっています。加えて、AWS Backup専用のバックアップVaultによってアクセス制御や暗号化キーを個別設定できるため、特にマルチアカウント環境ではセキュアな集中保管先として機能します。
AWS Backupは追加コスト（管理サービス利用料）は基本かかりません。課金は作成されたスナップショットやジョブ数に応じて通常の各サービスの料金が適用されるだけです（例: EBSスナップショット容量、Glacier保管料金など）。そのため可能であればAWS Backupを積極的に使うことが推奨されます。実際、AWS Well-Architected Frameworkでも大規模環境でのバックアップにはAWS BackupやAWS Organizationsを用いた集中管理を推奨しています。AWS Backupを用いることでバックアップ運用の自動化が進み、手作業ミスの削減やポリシー逸脱の検知（AWS Backup Audit Managerによる監査機能）などメリットが多く得られます。
サービス個別機能を使う場合: 規模が小さい環境や特殊な要件がある場合には、各サービスのネイティブなバックアップ機能を組み合わせて運用する方法もあります。例えば「EC2のEBSボリュームはスクリプトでスナップショットを取得」「RDSは自動バックアップに任せる」「DynamoDBはPITRを有効化しつつ定期的にオンデマンドバックアップ取得」「S3はバージョニングと別バケットへのレプリケーションで対処」といった具合です。これらをAWS LambdaやCloudWatch Eventsでスケジューリングし、独自に通知・監視することもできます。メリットとしては必要最低限のバックアップのみでシンプルに構成でき、サービス固有の機能（例えばRDSのPITRやOracle等の場合のバックアップオプション細かな設定）を活かしやすい点があります。また一部サービスではAWS Backup未対応のものもあり（例: ElastiCache）、そうしたものは個別対応が必要です。
個別運用のデメリットは、サービス横断での統一管理が難しくなる点です。ヒューマンエラーでバックアップ設定漏れが発生したり、各所にログが分散するため管理負荷や監査負荷が高まりやすいでしょう。またクロスアカウント・クロスリージョンへのコピーを自前でスクリプト実装するのは手間がかかります。したがって特段の理由がない限りAWS Backupを使った方が効果的です。ただし例えばDynamoDB PITRのようにAWS Backupではカバーできない継続的バックアップ（ポイントインタイム復元）はサービス固有機能の利用が必要ですし、S3のバージョニングもAWS Backupの定期バックアップとは性質が異なるため両方活用する余地があります。現実的には「AWS Backupで全体俯瞰しつつ、一部サービスは追加でネイティブ機能を組み合わせる」というハイブリッド運用も考えられます。
バックアップの保存場所: リージョン内・リージョン間・別アカウント・AWS外
バックアップデータをどこに保存するかも重要な検討ポイントです。単一の場所にしかバックアップがないと、その場所が使えなくなった場合に復旧不能となるため、複数の保管場所を組み合わせて冗長性を確保します。一般的な選択肢と特徴は次の通りです。
同一リージョン内: バックアップを元のリソースと同じリージョンに保管するパターンです。メリットは低レイテンシーで高速にバックアップ・リストアできる点と、データ転送コストがかからない点です。例えば東京リージョン内でEC2のEBSスナップショットを取得すれば、同じリージョン内の別AZで復旧するのが迅速です。またRDS自動バックアップは同一リージョンのストレージに保存されます。ただしリージョン全体の障害には弱いという欠点があります。したがって通常は「まず同リージョンに1世代以上バックアップを保持しつつ、別リージョンにもコピーを取る」構成がとられます。
別リージョン（クロスリージョン）: プライマリとは異なるAWSリージョンにバックアップデータを保存する方法です。地域災害や広域停電、リージョン障害への備えとして有効であり、オフサイトバックアップの一種です。AWS Backupではバックアッププランに追加コピー先リージョンを指定するだけで自動的にクロスリージョンコピーを行ってくれます。手動でもEBSスナップショットのコピー、RDSスナップショットのコピー機能などが利用できます。デメリットは復旧に時間がかかることと、リージョン間のデータ転送コストが発生する点です。前者についてはあらかじめ他リージョンにスタンバイ環境を置くことで緩和できます（パイロットライト構成等）。後者についてはバックアップデータ量次第ですが、頻繁に大容量転送するとコスト増となるためバックアップ頻度とのトレードオフを検討します。別リージョンへのバックアップは「リモートコピー」「DRコピー」とも呼ばれ、災害復旧用として位置付けます。なお、規制によっては特定地域外へのデータ移動を制限している場合もあるため（データ主権）、クロスリージョンバックアップ実施時は法務確認も必要です。
別アカウント（クロスアカウント）: バックアップを異なるAWSアカウントに保管する方法です。これは主にセキュリティ強化（誤操作や攻撃からの隔離）を目的とします。別アカウントにバックアップを置けば、本番アカウントが侵害されてもバックアップアカウントまでは影響が及びにくくなります。AWS Backupのクロスアカウント機能を使えば組織内の別アカウントへ自動コピー可能です。自社内で複数のAWSアカウントを運用している場合、中央バックアップアカウントを設けてそこに集約保管するのがベストプラクティスです。
クロスアカウントバックアップは人的ミスや内部脅威への対策にもなり、たとえば開発チームごとにアカウントを分けていてもバックアップだけは中央で一括管理する、といった運用を可能にします。デメリットはアカウント間の設定がやや複雑になる点ですが、AWS OrganizationsとAWS Backupの組み合わせでほぼ解決できます。
例えば上図は、ワークロード用AWSアカウントで取得したバックアップを、同一リージョン内の中央バックアップアカウントのVaultにコピーし、さらに別リージョンの中央Vaultにも複製するパターンを示しています。図中の①は同一アカウント内・同リージョン内でのバックアップ（ローカルコピー）、②はそれを同リージョンの別アカウントVaultへコピー、③は別リージョンの中央Vaultへコピーする流れです。こうしたマルチアカウント・マルチリージョンのアーキテクチャにより、単一障害点を排除したバックアップ保管が可能となります。
AWS外部: AWSクラウドの外（オンプレミス環境や他クラウド、物理媒体など）にバックアップデータを保存する方法です。実現手段としては、バックアップ取得後にデータをオンプレミスに逆転送したり、S3からテープ装置に書き出したりする必要があります。
あるいはRDSのスナップショットをS3にエクスポートし、それをダウンロードして社内保管するといった方法も考えられます（ただしRDS snapshotのS3エクスポートはParquet形式であり、そのまま復元には使えない点に注意）。AWS外部へのバックアップは、クラウド依存を減らし究極のリスクシナリオに備えるものですが、コストと運用負荷が大きく一般には実施されません。
バックアップの頻度と保持期間
「どのくらいの頻度でバックアップを取得し、どれだけ長く保持するか」はバックアップ戦略の基本方針です。適切な頻度と保持期間はデータの変化率やビジネス要件によって決まります。
バックアップ頻度の決め方
頻度はRPO目標を直接反映します。一般にデータ更新が頻繁なものほど短い間隔でバックアップし、変化の少ないデータは低頻度で十分です。
以下は典型的なガイドラインです:
トランザクション系データベース（例: RDS上のOLTPデータベースやDynamoDBテーブル）: 連続的ないし1時間おき程度の頻度でバックアップします。RDS/Auroraはポイントインタイムリカバリが可能なので常時ログを取った上で、スナップショットも頻繁に取得します。DynamoDBもPITRを有効化しつつ、重要テーブルなら追加で日次エクスポートも検討します。
ファイルサーバ/オブジェクトストレージ（例: EFS, S3バケット）: データ更新があっても個別ファイル単位であることが多いため、バージョン管理や週次程度のバックアップで対応します。特にS3はバージョニングとLifecycle（後述）で世代管理し、新規ファイルや更新ファイルのみ別途アーカイブする方法が有効です。
仮想サーバ/システムイメージ（例: EC2のEBSボリューム）: OSやアプリケーションコードは頻繁には変わらないため日次バックアップが一般的です。毎日深夜にスナップショットを取り、万一のインスタンス障害に備えます。もし日中にも設定変更が走るケースではその直後にスナップショットを追加取得するとよいでしょう。
ログ・監査記録・アーカイブ: 日次やリアルタイムで他へ転送済みであれば、バックアップは週次〜月次程度でも問題ありません。長期保管が必要な場合はAmazon S3 Glacier等のアーカイブストレージに直接保存することも考えます。
重要なのは、ビジネス側と合意したRPOを満たすだけの頻度になっているかです。例えばRPOが「最大1時間のデータ損失許容」であれば、最低でも1時間に1回はバックアップを取得していなければなりません。頻度が不足していると、いざという時に目標を満たせず経営的損失に繋がります。一方で頻度を上げすぎるとシステムやネットワークに過負荷となる場合もあります。データ量・変化量に見合った頻度を選定し、AWSの各種サービス（イベント駆動のバックアップ、増分バックアップなど）を活用して負荷と頻度を両立させます。例えばEBSスナップショットは初回以降増分取得なので毎時間取っても増量部分のみで済みますし、RDSもトランザクションログを活用することで実質的に継続バックアップが可能です。
バックアップ保持期間の決め方
保持期間（Retention）はバックアップをどれだけ過去まで遡って保持するかを定めます。基本的には以下の観点で決まります。
復旧要件: ある時点のバックアップから復元したいとき、どこまで古い世代が必要になるかです。多くの場合直近数世代があれば十分ですが、シナリオ②（セキュリティ侵害）のように攻撃に気付くまで時間がかかった場合には何週間も前の状態に戻す必要が生じます。自社のリスク検知体制上、最悪どれくらい気付かない可能性があるかを考慮して保持期間を決めます。
法令・コンプライアンス要件: 業種によってはデータを○年間保存する法律・規制があります。例えば金融取引記録は7年間保存が義務付けられることがあります。この場合、少なくとも7年分のバックアップ（またはアーカイブ）を保持しなければなりません。メールや監査ログなども長期保管対象となりがちです。
ビジネスニーズ: 過去データの参照ニーズによっても決まります。例えば分析のため1年前のDBスナップショットを取り出すことがある、という場合は1年間は残しておくべきでしょう。また、年単位での大きな変更（年次決算など）前の状態を残しておきたいという要求もあり得ます。
AWS Backupではバックアッププラン内でライフサイクルポリシーを設定でき、例えば「バックアップ開始から30日間は標準ストレージに保持、その後90日間は低コスト保管、その後削除」というルールを自動化できます。この機能を活用すれば、保持期間経過後の手動削除忘れを防ぎつつコスト最適化も図れます。たとえば日次バックアップは30日保持、週次バックアップは6ヶ月保持、月次バックアップは7年保持といった多層的な運用も可能です。AWS BackupのVaultごとに保持期間を分けることもできます。
世代管理のベストプラクティス: 全バックアップを無制限に残すのは現実的ではないため、世代交代ルールを決めます。一般的には「世代数ベース」または「期間ベース」での削除です。期間ベースは上記の通り要件から決め、世代数ベースは例えば最新7世代の日次バックアップを保持などとします。AWS Backupでは期間指定ですが、例えば毎日実行で30日保持にすれば常に30世代が維持されます。S3のバージョニングについてはLifecycleルールで「何日後に旧バージョンを削除」等が設定できます。
コストに関する注意点と見積もりのポイント
クラウドバックアップは従量課金であり、設計によってコストが大きく変動します。バックアップ戦略を考える際にはコスト意識も重要です。以下、主なコスト要因と最適化ポイントを挙げます。
ストレージ容量コスト: 取得したバックアップ（スナップショットやデータコピー）は基本的に保存容量に比例した料金が発生します。サービスごとに単価は異なりますが、例としてEBSスナップショットは約0.05 USD/GB/月、Glacier Deep Archiveは0.002 USD/GB/月程度です（リージョンにより異なります。AWS公式ドキュメントを参照ください）。
増分バックアップの場合、増加分のみ容量加算されます。保持期間を長くするほど容量コストは累積しますので、必要以上に古い世代を残さないことが肝要です。AWS Backupのレポート機能やCost Explorerを使って、各サービスのバックアップ容量を定期的に分析しましょう。特に使われていないリソースのバックアップが惰性的に残っていないか、可視化・棚卸しすることが大切です。
データ転送料・リクエスト費用: バックアップ取得やコピーに伴うデータ転送やAPIコールにも微小なコストがあります。同一リージョン内のバックアップは基本的にデータ転送無料ですが、リージョン間コピーを行うとコピー元リージョンからのデータ送信（AWS間転送）料金が発生します。例えば100GBのスナップショットを毎日別リージョンにコピーすると月3000GBの転送となり、数百ドル規模のコストになる可能性があります。クロスアカウントで同じリージョン内にコピーする場合は転送コストはかかりません。APIリクエスト費用は1件あたり0.05 USD以下のものが多く、一度に大量のリソースをバックアップする場合でも大きな負担にはなりにくいですが、極端に高頻度（例えば数分おきにスナップショット実行など）だと無視できない額になることもあります。
スナップショットの重複・無駄を省く: 開発中のリソースなど、本番稼働後には不要になるバックアップが残り続けていないか注意します。特にAutoScalingで消える一時サーバのバックアップや、一時的にテストしたDBスナップショットが放置されているケースがありえます。AWS ConfigやBackup Audit Managerを使えば、バックアップポリシー適用漏れだけでなく不要バックアップの検出もある程度可能です。定期的にVaultやスナップショット一覧を確認し、意味のないデータが占有していないかチェックしましょう。
KMS暗号化のコスト: 後述するようにバックアップデータは暗号化すべきですが、KMSのカスタマーマスターキー(CMK)を使用する場合、APIリクエスト料金が発生します。ただKMSリクエストは1ヶ月あたり数千～数万回は無料枠があるため、通常のバックアップ頻度であれば追加コストはごく小さいです。ただし何千ものリソースを一斉にバックアップするような環境ではKMS費用も意識してください。
AWS Backup付随サービスの費用: AWS Backup Audit Managerを使うと、バックアップポリシー準拠状況をレポートできますが、評価ごとに料金がかかります。大規模組織で毎日のようにAudit Managerを回すとそれなりの額になりえます。ただしコンプライアンス違反での罰則や事後対処コストに比べれば安い投資と言えます。必要性に応じて有料機能も活用しましょう。
以上を総合すると、コスト見積もりのポイントは「バックアップ対象容量 × 保持期間 × ストレージ単価 + 転送・リクエスト費用」で概算できます。具体的には例えば: 「100GBのEBSボリュームを日次スナップショット（増分平均10GB増）で30日保持、かつ別リージョンにもコピーして60日保持」 といったシナリオで各項目を計算します。AWS Pricing CalculatorやCost Explorerを用いてシミュレーションし、月額コストの見積もりを事前に出すと良いでしょう。経営層には「このバックアップ戦略により、仮に障害が起きた場合の最大損失を○ドル防げる。コストは月○ドル」という形で説明できるとなお良いです。コストとリスクのバランスを取りながら、必要十分なバックアップに予算が割り当てられるよう調整します。
暗号化とセキュリティ: KMSの活用
バックアップに含まれるデータは本番と同等かそれ以上に機密性が高いため、暗号化による保護が不可欠です。AWSではバックアップデータを暗号化する方法として主にAWS Key Management Service (KMS)が利用されます。基本方針は 「転送中と保管中の両方を暗号化」 することです。転送中の暗号化はAWSの各サービスがAPI通信でTLSプロトコルを使用することで実現されており（AWS Backupもエンドポイントとの通信はTLSで保護されています）、ユーザ側で特別な対応は不要です。一方、保存データの暗号化はリソースや用途に応じて設定が必要です。以下、具体的なポイントを整理します。
バックアップデータの暗号化: AWS Backup経由で取得されるバックアップ（スナップショット等）は、原則ソースデータの暗号化状況を引き継ぎます。例えば暗号化されたEBSボリュームのスナップショットは自動的に暗号化されます。RDSの自動バックアップも、元DBが暗号化されていればスナップショットも暗号化されます。DynamoDB PITRは内部的にKMSが使われています。可能な限りすべてのリソースは暗号化を有効にしておき、バックアップも暗号化状態で保存されるようにします。AWSサービスの多くはデフォルトでAWS管理キーによる暗号化を提供していますが、必要に応じて 顧客管理キー（CMK） に切り替えることでアクセス制御を強化できます。
異なるキーによる再暗号化: AWS Backupではバックアップコピー時に別のKMSキーで再暗号化する機能があります。例えば、ソースアカウントではキーAで暗号化されたバックアップを、別アカウントにコピーする際にそのアカウントのキーBで暗号化し直すことが可能です。これにより、仮にキーA（ソース側）が漏洩してもコピー先のデータはキーBなしには復号できず安全です。また万一ソース側アカウントが攻撃されても、コピー先キーの管理権限が渡らない限りバックアップの中身は読まれません。このように鍵を分離することでバックアップデータに対する多重の認可がかかり、より安全性が高まります。
KMSキーのアクセス制御: KMSキー自体に対するアクセス許可も厳密に管理します。バックアップデータを暗号化するキーのKMSポリシーを編集し、復号を許可するプリンシパル（IAMユーザ/ロールやAWSサービス）を必要最小限に絞ります。例えば「バックアップ復元バッチ用のIAMロール」にのみ復号権限を与え、他の一般権限ではたとえバックアップにアクセスできても復号はできない、といった設定が可能です。アクセス制御ポリシーと暗号鍵による二段構えのセキュリティを構築することで、万一アクセス制御が突破されてもデータ自体は読めない状態を作れます。また、キーの削除保留期間を長めに設定しておけば、誤ってCMKを消してしまいバックアップが復元不能になる事故も防げます。
マルチリージョンKMSキーの活用: バックアップを複数リージョンにまたぐ場合、マルチリージョンキーを検討します。マルチリージョンKMSキーはあるリージョンで作成すると別リージョンにレプリケートでき、同じエイリアス/キーIDで扱える対になる鍵を提供します。これを使うと、例えば東京リージョンで暗号化したデータを大坂リージョンの同じキーIDで復号することができます。クロスリージョン復元時に鍵管理が簡単になる利点があります。マルチリージョンキーを使わない場合でも、別リージョン用にキーを用意しておきコピー時に指定すれば問題ありませんが、複数鍵を追跡する手間が増えます。なおマルチリージョンキーは複製しても各リージョンのKMSで独立管理されているため、一方が削除されても他方は残ります（耐障害性も向上）。
暗号化の監査と検証: バックアップが確実に暗号化されていることを定期的に確認します。AWS Backup Audit Managerには「バックアップが適切に暗号化されているか」をチェックする制御項目があります。これを有効にすれば、暗号化されていないリカバリポイントが無いか検出できます。また、Security HubやConfigのルールでも「EBSスナップショットが未暗号化ならアラート」等のチェックが可能です。こうした仕組みを使い、暗号化漏れをゼロにするよう運用します。
総じて、バックアップの暗号化はデフォルトで常に有効にし、かつ鍵管理に細心の注意を払うことが重要です。鍵を安全に保管できなければ暗号化していても意味がありません。KMSのキー削除はマルチユーザ承認とし、CloudTrailで誰が鍵にアクセスしたかを監視するなど、鍵そのもののガバナンスにも気を配りましょう。適切に暗号化と鍵管理ができていれば、バックアップデータが漏洩・盗難しても実質的な被害を防ぐことができます。
雑な結論
たくさん考慮すべき点がありすぎてよくわからんという状況になっている方もいらっしゃるかと思いますので、筆者の独断と偏見でおすすめのバックアップ設定を載せておきます。
置かれている状況の仮定
- AWS Organizations内に複数のAWSアカウントあり
- 複数のAWSアカウントを管理しているCCoEやSRE/インフラエンジニアの想定
- 主に東京リージョンでリソースを構築している
おすすめのバックアップ設定
まずはこの3点が設定されていれば、十分な頻度のバックアップが取得されて、かつ、攻撃者からも守られている状態になります。
- AWS Backupで包括的なバックアップ設定をする
- PITRが設定できるものは活用する
- RDS/AuroraはPITR（継続的バックアップ）を35日間で設定する
- その他、差分/増分バックアップが設定できるものは活用する
- PITRや差分/増分バックアップが設定できる場合は、費用は頻度によらないため、高頻度で設定する。
- フルバックアップを取得するものは、費用が頻度に比例してしまうため、頻度を低くする。
- PITRが設定できるものは活用する
- バックアップ（Vault）にはロックを実施する。
- 可能であればコンプライアンスモードでロックする。少なくともオブジェクトモードでロックする。
- まずは、別リージョンや別アカウントにコピーしない
- Vaultから、別のリージョンや別アカウントのVaultにコピーするという仕様のため、必要になったら実施したら良い。
その後、別リージョンや別アカウントにコピーするべきか、暗号化の種類や強度を変更すべきか、保存している期間や世代数が十分か、権限は適切に設定されているか、など細かく検討しても遅くないかなと思います。
参考
※1: https://zenn.dev/kiiwami/articles/cc0fb26bcf867d18
※2: https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault-access-policy.html
Discussion