▪️目的
AWSでシステムを運用する場合、障害や誤操作、データの削除などに備えて、バックアップを取得することが重要です。
例えば、次のようなケースが考えられます。
- EC2インスタンスのデータを誤って削除してしまった
- RDSのデータベースに障害が発生した
- 重要なデータを誤操作によって上書きしてしまった
- 災害や大規模障害に備えて、別のリージョンにもバックアップを保管したい
こうした事態に備え、AWSではさまざまなバックアップの仕組みを利用できます。
その中でも、複数のAWSサービスのバックアップをまとめて管理できるのが、AWS Backup です。
AWS Backupを利用すると、バックアップのスケジュールや保存期間などを設定し、対応するAWSリソースのバックアップを一元的に管理できます。
この記事では、AWS Backupの基本的な仕組みから、バックアッププラン、バックアップボールト、復元、リージョンをまたいだコピーまで、初心者向けに解説します。
目次
- AWS Backupとは
- AWS Backupの基本的な仕組み
- バックアッププラン
- Backup Vault(バックアップボールト)
- Recovery Point(復旧ポイント)
- バックアップと復元の流れ
- クロスリージョン・クロスアカウントバックアップ
- AWS Backupと各サービス固有のバックアップの違い
- AWS Backupを利用するメリット
- 利用する際の注意点
- まとめ
▪️AWS Backupとは
AWS Backupは、AWS上の対応リソースのバックアップを一元的に管理するためのサービスです。
通常、AWSの各サービスには、それぞれ独自のバックアップ機能があります。
例えば、EC2のEBSボリュームではスナップショット、RDSではデータベースの自動バックアップやスナップショットなどを利用できます。
AWS Backupを利用すると、対応する複数のサービスについて、バックアップのスケジュールや保存期間などをまとめて管理しやすくなります。
♦︎AWS Backupで管理できるリソースの例
| AWSサービス | バックアップ対象の例 |
|---|---|
| Amazon EC2 | EC2インスタンスに関連する対応リソースやEBSボリューム |
| Amazon EBS | EBSボリューム |
| Amazon RDS | データベース |
| Amazon DynamoDB | テーブル |
| Amazon EFS | ファイルシステム |
| Amazon S3 | バケット内のオブジェクトなど、対応するバックアップ対象 |
対応するサービスや機能はリソースの種類、リージョン、バックアップ方式などによって異なります。
AWS Backupは、すべてのAWSリソースを無条件にバックアップできるわけではありません。実際に利用する際は、対象リソースがサポートされているか確認しましょう。
▪️AWS Backupの基本的な仕組み
AWS Backupの基本的な流れは、次のとおりです。
バックアップ対象のAWSリソース
↓
AWS Backup
↓
バックアッププラン
↓
スケジュールに沿ってバックアップ
↓
バックアップボールトに保存
↓
必要に応じてリソースを復元
例えば、EBSボリュームを毎日バックアップし、一定期間保存するように設定できます。
バックアップが作成されると、復元に利用するデータが復旧ポイントとして管理されます。
障害や誤操作などが発生した場合は、利用可能な復旧ポイントを選択し、対応するリソースを復元できます。
ここで重要なのは、バックアップを取得することと、バックアップから正常に復元できることは別だという点です。
バックアップが作成されていても、復元に必要な設定や権限が不足していたり、復元後のアプリケーションが正常に動作しなかったりする可能性があります。そのため、復元手順の整備や定期的な復元テストも重要です。
▪️バックアッププラン
バックアッププランは、どのような条件でバックアップを取得するかを定義する設定です。
バックアッププランでは、主に次のような項目を設定します。
- バックアップを取得するスケジュール
- バックアップを保存するボールト
- バックアップの保存期間
- バックアップを別のリージョンなどへコピーするルール
♦︎バックアッププランのイメージ
バックアッププラン
│
├─ 取得頻度:毎日
│
├─ 保存先:Backup Vault
│
├─ 保存期間:30日間
│
└─ コピー先:別リージョン
上記は仕組みを説明するための例です。実際のスケジュールや保存期間は、システムの要件に応じて設計します。
♦︎バックアップの頻度
バックアップの頻度は、どの程度のデータ損失を許容できるかなどを考慮して決定します。
例えば、1日に1回バックアップを取得する構成では、障害が発生した時点によっては、直近のバックアップ以降に発生したデータ変更が失われる可能性があります。
より細かい時点への復元が必要な場合は、対象サービスが対応していれば、継続的バックアップやポイントインタイムリカバリ(PITR)などを検討します。
♦︎保存期間
保存期間は、バックアップをどれくらいの期間保持するかを定めるものです。
例えば、日次バックアップを30日間保持する構成などが考えられます。
バックアップの保存期間を長くすると、過去の状態へ戻せる選択肢が増える一方、保存コストが増える可能性があります。
そのため、業務上必要な復旧期間や社内ルール、法令・規制などを考慮して設計することが重要です。
▪️Backup Vault(バックアップボールト)
Backup Vault(バックアップボールト)は、AWS Backupで作成したバックアップを管理するための保管先です。
バックアッププランで保存先のボールトを指定することで、取得したバックアップを管理できます。
♦︎バックアップボールトのイメージ
EBS・RDSなどの対象リソース
↓
AWS Backup
↓
Backup Vault
↓
復旧ポイントを管理
バックアップボールトでは、バックアップの管理やアクセス制御、暗号化などを扱います。
♦︎暗号化
バックアップには、データの機密性を保つための暗号化も重要です。
AWS Backupでは、対象リソースやバックアップ方式に応じて、AWS Key Management Service(AWS KMS)のキーなどを利用してバックアップを暗号化します。
暗号化方式や利用できるキーには条件があるため、対象リソースの仕様を確認しましょう。
また、バックアップを別のアカウントへコピーする場合などは、コピー先の暗号化キーやアクセス権限の設定も重要になります。
♦︎ボールトのアクセス制御
バックアップは、元のリソースとは別に保護すべき重要なデータです。
例えば、攻撃者や誤操作によって本番データだけでなくバックアップまで削除されると、復旧が難しくなる可能性があります。
そのため、バックアップボールトへのアクセス権限を適切に制御し、バックアップの削除や変更ができるユーザーを必要最小限にすることが重要です。
なお、AWS Backupには、論理的にエアギャップされたボールトなど、バックアップの保護を強化するための機能もあります。利用条件や対応リソースを確認したうえで検討しましょう。
▪️Recovery Point(復旧ポイント)
Recovery Point(復旧ポイント)は、バックアップからリソースを復元する際に利用するバックアップデータを表します。
バックアッププランに従ってバックアップが作成されると、そのデータが復旧ポイントとして管理されます。
♦︎復旧ポイントのイメージ
バックアップ対象
↓
AWS Backup
↓
┌────────────┐
│ 復旧ポイントA │ ← 1日前のバックアップ
├────────────┤
│ 復旧ポイントB │ ← 2日前のバックアップ
├────────────┤
│ 復旧ポイントC │ ← 3日前のバックアップ
└────────────┘
↓
必要な時点のデータを選択して復元
例えば、今日のデータに問題が発生した場合、要件に応じて昨日や数日前の復旧ポイントから復元することを検討できます。
ただし、復元できる時点や復元方法は、対象サービスやバックアップ方式によって異なります。
♦︎復旧ポイントと保存期間
復旧ポイントには、バックアッププランで設定した保存期間などが関係します。
保存期間が終了したバックアップは、ライフサイクル設定などに従って削除される場合があります。
そのため、必要な復旧ポイントが保持されるように保存期間を設計しましょう。
▪️バックアップと復元の流れ
AWS Backupを利用する場合、バックアップの取得だけでなく、復元の手順も理解しておくことが重要です。
♦︎バックアップの流れ
- バックアップ対象のリソースを決める
- バックアッププランを作成する
- バックアップの頻度や保存期間を設定する
- 対象リソースをバックアップ対象に指定する
- バックアップジョブの実行状況を確認する
バックアッププランに従ってバックアップを取得するほか、対応するリソースではオンデマンドでバックアップを開始できる場合もあります。
♦︎復元の流れ
- 復元したい復旧ポイントを選択する
- 対象リソースに対応した復元設定を行う
- 復元ジョブを実行する
- 復元処理の完了を確認する
- 復元したリソースやアプリケーションが正常に動作するか確認する
復元では、元のリソースをそのまま上書きするとは限らず、新しいリソースを作成する方式もあります。
例えば、EBSボリュームのバックアップから復元する場合、復元したボリュームをEC2インスタンスへ接続するなど、追加の作業が必要になることがあります。
また、データベースの復元では、接続先の切り替えやアプリケーション側の確認が必要になる場合があります。
バックアップジョブが成功したことだけで、システム全体を復旧できると判断しないことが大切です。
▪️クロスリージョン・クロスアカウントバックアップ
AWS Backupでは、要件に応じてバックアップを別のリージョンやAWSアカウントへコピーできます。
これらは、災害や重大な誤操作などに備えて、バックアップの保護を強化する方法です。
♦︎クロスリージョンバックアップ
クロスリージョンバックアップは、バックアップを別のAWSリージョンへコピーする方法です。
例えば、東京リージョンで稼働するシステムのバックアップを、大阪リージョンにも保管する構成が考えられます。
東京リージョン
本番リソース
↓
バックアップ
↓
バックアップコピー
↓
大阪リージョン
バックアップを保管
本番環境のリージョンで障害が発生した場合に備えて、別のリージョンにバックアップを保管できます。
ただし、バックアップが別リージョンにあるだけで、システム全体が自動的に切り替わるわけではありません。復元先のリソースやネットワーク、アプリケーションなどを復旧する手順も必要です。
♦︎クロスアカウントバックアップ
クロスアカウントバックアップは、バックアップを別のAWSアカウントへコピーする方法です。
例えば、本番環境とは別のバックアップ専用アカウントにバックアップを保管する構成が考えられます。
本番アカウント
本番リソース
↓
AWS Backup
↓
バックアップコピー
↓
バックアップ専用アカウント
バックアップを保管
本番アカウントで誤操作や不正アクセスが発生した場合でも、別アカウントに保管されたバックアップを復旧に利用できる可能性があります。
ただし、クロスアカウントコピーには、AWS Organizationsの構成やボールトポリシー、IAM権限、暗号化キーなどの条件があります。すべてのリソースやリージョンで同じように利用できるわけではありません。
▪️AWS Backupと各サービス固有のバックアップの違い
AWS Backupと、各AWSサービスが提供するバックアップ機能は、どちらか一方だけを使うという関係ではありません。
対象サービスや要件に応じて、AWS Backupとサービス固有の機能を使い分けたり、組み合わせたりします。
♦︎AWS Backup
AWS Backupは、対応する複数のサービスのバックアップを一元的に管理することに向いています。
バックアッププランを利用して、取得スケジュールや保存期間などをまとめて管理できます。
♦︎サービス固有のバックアップ機能
一方、各サービスにも固有のバックアップ機能があります。
例えば、Amazon RDSでは、自動バックアップやスナップショット、対応するデータベースのポイントインタイムリカバリなどを利用できます。
Amazon EBSでは、スナップショットを利用してボリュームのデータを保護できます。
♦︎比較
| 項目 | AWS Backup | サービス固有の機能 |
|---|---|---|
| 主な目的 | 複数サービスのバックアップを一元管理 | 各サービスに適したバックアップや復元 |
| 管理方法 | バックアッププランなどで共通的に管理 | サービスごとの設定や機能を利用 |
| 対象 | AWS Backupが対応するリソース | 各サービスが提供する機能の対象 |
| 注意点 | 対象リソースや機能の対応状況を確認する | サービスごとに仕様や制約を理解する |
どちらが優れているというより、バックアップの目的や運用方法に合わせて選択することが重要です。
▪️AWS Backupを利用するメリット
AWS Backupを利用する主なメリットは、次のとおりです。
① バックアップを一元管理できる
複数のAWSサービスのバックアップを、共通の仕組みで管理しやすくなります。
サービスごとに個別の設定を管理する負担を減らせる場合があります。
② バックアップを自動化できる
バックアッププランを設定することで、スケジュールに従ったバックアップを実行できます。
手作業によるバックアップの取得漏れを防ぎやすくなります。
③ 保存期間を管理できる
バックアップの保存期間やライフサイクルを設定することで、必要な期間バックアップを保持しやすくなります。
④ 別リージョン・別アカウントへのコピーに対応できる
対応するリソースでは、バックアップを別のリージョンやAWSアカウントへコピーできます。
本番環境とは異なる場所にバックアップを保管することで、復旧手段を増やせます。
⑤ 復元テストを支援できる
AWS Backupには、対応するリソースの復元テストを計画・実行し、復元処理の結果や所要時間などを確認する機能があります。
バックアップを取得するだけでなく、実際に復元できることを検証する運用にも役立ちます。
▪️利用する際の注意点
AWS Backupを利用する際は、次の点にも注意しましょう。
① バックアップ対象の対応状況を確認する
AWS BackupがすべてのAWSリソースや機能に対応しているわけではありません。
対象サービス、リージョン、バックアップ方式、復元方式などを事前に確認しましょう。
② バックアップの取得状況を監視する
バックアッププランを設定しても、権限や設定、対象リソースの状態などによってジョブが失敗する場合があります。
バックアップジョブの実行状況を確認し、失敗した場合に検知できる仕組みを整えましょう。
③ 復元テストを実施する
バックアップが存在することと、必要なデータやシステムを復元できることは同じではありません。
定期的に復元テストを行い、復元手順やアプリケーションの動作を確認しましょう。
④ 暗号化キーやアクセス権限を管理する
暗号化されたバックアップを復元する際には、必要なキーへのアクセス権限などが関係します。
バックアップの保存先やコピー先を含めて、IAM権限やKMSキーの管理を適切に設計することが重要です。
⑤ 利用料金を確認する
AWS Backupの料金は、対象リソースやバックアップの保存量、コピー、復元、利用する機能などによって異なります。
バックアップの保存期間を長くしたり、複数のリージョンやアカウントにコピーしたりすると、追加の料金が発生する可能性があります。
導入前に、バックアップ対象や取得頻度、保存期間、コピー先を整理し、料金を確認しましょう。
▪️まとめ
AWS Backupは、AWS上の対応リソースのバックアップを一元的に管理するサービスです。
今回のポイントを整理します。
- バックアッププラン:バックアップの頻度や保存期間などを定義する
- Backup Vault:バックアップを管理する保管先
- Recovery Point:復元に利用するバックアップデータ
- バックアップと復元:バックアップの取得だけでなく、復元手順の検証も重要
- クロスリージョンバックアップ:別リージョンへバックアップをコピーする
- クロスアカウントバックアップ:別アカウントへバックアップをコピーする
システムを安定して運用するためには、障害や誤操作が発生したときに備え、データを保護する仕組みを整えておくことが重要です。
AWS Backupを活用し、バックアップの取得・保管・復元までを考慮した運用設計を行いましょう。
次の記事では、「AWS Organizations」について解説します。
*「AWS Organizations」の記事はこちら
→「https://lovelabengineer.com/2026/10/11/【aws入門】aws-organizationsとは?複数アカウントを一元管理す/」

No responses yet