AWS Backup

は、、、、、、、など複数の AWS リソースのバックアップを、一元的に管理・自動化するためのフルです。サービスごとに個別のやバックアップ設定を作る代わりに、バックアップ計画、バックアップ Vault、ライフサイクル、保持期間、コピー、監査をまとめて管理できます。

SAA では、AWS Backup は「複数サービスのバックアップを中央管理したい」「タグで対象を自動選択したい」「クロスやにバックアップを保管したい」「削除や改ざんからバックアップを守りたい」という文脈で出ます。単一 EBS のスナップショット作成だけでなく、組織的なバックアップ戦略を設計するサービスとして理解します。

Point

Backup は「予備」「控え」「バックアップ」という意味です。
AWS Backup は、各サービスのバックアップ操作をまとめて扱うサービスです。
試験では「一元管理」「自動化」「複数リソース」「コンプライアンス」がキーワードになります。
和訳
- Backup: 予備、控え、支援
- Weblio英和辞書「backup」

概要

は、バックアップ対象、取得頻度、保持期間、保存先、コピー先をポリシーとして定義し、複数の AWS リソースに適用するサービスです。バックアップ対象は明示的に選ぶことも、タグを使って自動的に選ぶこともできます。

バックアップの単位は、復旧ポイントとして Backup Vault に保存されます。復旧時は、復旧ポイントから元のサービスに戻します。たとえばならからボリュームを復元し、ならバックアップから DB を復元します。

AWS Backup は、サービスごとのバックアップ機能をすべて置き換えるものではありません。RDS の自動バックアップ、EBS スナップショット、など、各サービス固有のバックアップ機能との関係はサービスごとに異なります。SAA では、単体リソースの簡単なバックアップよりも、複数サービスを一元管理し、ルールを統一し、監査やを満たす場面で AWS Backup を選びます。

観点	AWS Backup でできること
一元管理	複数サービスのバックアップ設定と履歴をまとめて管理します。
自動化	スケジュール、保持期間、ライフサイクルを計画で定義します。
対象選択	タグやリソース指定でバックアップ対象を選びます。
	クロスコピー、コピーを設計できます。
保護	Vault Lock で型の保持を強制できます。
監査	、、、と連携します。

主要技術

①バックアップ計画とバックアップルール

バックアップ計画は、バックアップ戦略を定義する単位です。計画の中にバックアップルールを作り、取得頻度、バックアップウィンドウ、保存先 Vault、保持期間、ライフサイクル、コピー先などを指定します。

設定	役割	SAA での判断
Backup plan	バックアップ戦略全体	アプリや要件ごとに作ります。
Backup rule	取得頻度や保持期間	日次、週次、月次などの要件を表します。
Backup window	バックアップ実行時間帯	業務負荷が低い時間に寄せます。
Lifecycle	warm から cold への移行や削除	長期保管コストを下げます。
Copy rule	別や別アカウントへのコピー	やに使います。

対象リソースは、ARN で直接指定する方法と、タグで選ぶ方法があります。タグを使うと、Backup=Daily や Environment=Prod のようなルールに基づいて、対象リソースを自動的に計画へ含められます。SAA では、リソースが増えてもバックアップ設定を漏れなく適用したい場合にタグベース選択が有効です。

対象リソースをどの粒度で指定するかも判断軸です。インスタンスを対象に選ぶと、インスタンスの構成情報と、そのインスタンスにアタッチされたすべてのボリュームを 1 つの復旧ポイントとしてまとめて保護でき、復元時はインスタンスごと戻せます。個々の EBS ボリュームを対象に選ぶと、保護されるのはそのボリュームのデータだけで、インスタンスの構成は含まれません。

対象リソースの指定	保護される範囲	SAA での判断
EC2 インスタンス	インスタンス構成と全アタッチ EBS ボリューム	インスタンスまるごと復旧したい場合に選びます。
EBS ボリューム	そのボリュームのデータのみ	特定ディスクだけを保護したい場合に選びます。
/ / など	各サービスの復旧ポイント	同じ計画に混在させて一元管理できます。

似た機能として Amazon Data Lifecycle Manager があります。こちらは EBS と EBS-backed のライフサイクル自動化に特化した機能で、EBS 以外のサービスを含めた横断的なバックアップ統制やの保管には向きません。複数サービスをまとめて扱う要件ではを選びます。

⚠️ 頻出: 「多数の EC2、EBS、RDS、EFS に同じバックアップルールを適用したい」「タグで対象を自動管理したい」は AWS Backup のバックアップ計画を選びます。

②バックアップ Vault、復旧ポイント、暗号化

Backup Vault は、が作成した復旧ポイントを保管する論理です。Vault にはアクセス制御、暗号化、Vault Lock、通知などを設定できます。復旧ポイントは、特定時点に戻すためのバックアップデータです。

用語	役割	注意点
Backup vault	復旧ポイントの保管先	アクセス制御と暗号化の境界になります。
Recovery point	復元に使うバックアップ	保持期間や削除条件の対象です。
key	バックアップ暗号化	復元やコピー時の権限不足に注意します。
Vault access policy	Vault へのアクセス制御	誰が削除・復元できるかを制御します。
Vault notification	ジョブ状態通知	などで成功・失敗を検知します。

一部のリソースでは、AWS Backup がバックアップを独立した AWS Backup 管理のリソースとして扱います。この場合、Vault の KMS キーでバックアップを暗号化し、arn:aws:backup で始まる ARN を使ってバックアップ自体に対するアクセス制御を設計できます。

バックアップ Vault はソースリソースから分離された保管場所です。たとえばやを削除しても、保持期間内の復旧ポイントが Vault に残っていれば復元に使えます。ただし、復元先の設定、権限、KMS 復号権限、ネットワークやは別途確認します。

⚠️ 頻出: 「バックアップを本番リソースとは別の権限境界で守りたい」「削除権限を制限したい」「KMS でバックアップを暗号化したい」は Backup Vault と IAM/KMS を確認します。

③クロスリージョンコピーとクロスアカウントコピー

は、復旧ポイントを別や別アカウントの Vault にコピーできます。これは、リージョン障害対策、ランサムウェア対策、アカウント侵害対策、規制要件に役立ちます。

コピー方式	主な用途	判断ポイント
クロスリージョンコピー	リージョン障害や地理的分離	要件やデータ保管距離の要件で使います。
コピー	本番アカウントから保管用アカウントへ退避	アカウント侵害や誤削除への耐性を高めます。
コピー	既存復旧ポイントを手動でコピー	一時的な移行や特別な保管要件に使います。
スケジュールコピー	バックアップ計画の一部として自動コピー	継続的な DR 設計に向きます。

クロスリージョンコピーでは、初回コピーは通常フルコピーになり、対応リソースでは以降のコピーが増分になることがあります。コピー先 Vault のキーで再暗号化されるため、コピーや復元に必要な KMS 権限を忘れないようにします。

クロスアカウントコピーでは、と組み合わせて、バックアップ専用アカウントへ集約する設計がよく使われます。本番アカウントで誤ってリソースやバックアップを削除しても、別アカウントにコピーが残っていれば復旧できる可能性が高まります。

⚠️ 頻出: 「本番アカウントの管理者が誤って削除しても守りたい」「リージョン障害に備えたい」「バックアップを別アカウントに隔離したい」はクロスアカウントコピー、クロスリージョンコピー、Vault Lock を組み合わせます。

④Vault Lock と WORM 保護

Vault Lock は、バックアップ Vault に保持ルールを強制し、復旧ポイントの削除や保持期間短縮を防ぐ機能です。、つまり一度書いたら変更・削除できない保護モデルを実現するために使います。

モード	主な用途	注意点
Governance mode	管理者の誤操作対策	適切な権限があればロック設定を変更できる場合があります。
Compliance mode	規制・監査要件の強い保持	猶予期間後は顧客や AWS でもロックを削除できない設計です。

Vault Lock は、ランサムウェア対策や規制遵守で重要です。攻撃者や誤操作によってバックアップが削除されると、復旧不能になる可能性があります。Vault Lock を使うと、定義した保持期間が終わるまで復旧ポイントを削除できないようにできます。

Point

WORM = Write Once, Read Many の略です。
直訳すると「一度書いて、何度も読む」です。
バックアップでは、保存した復旧ポイントを保持期間中に変更・削除できないようにする考え方です。
和訳
- Write: 書く
- Read: 読む
- Weblio英和辞書「write」

Compliance mode は非常に強力です。設定後の猶予期間を過ぎると、Vault に復旧ポイントが残っている限りロック設定を削除できないため、保持期間を誤ると意図しない長期保管コストが発生します。SAA では、削除防止とコスト・運用リスクの両方を考えます。

⚠️ 頻出: 「管理者を含めてバックアップ削除を防ぎたい」「WORM 要件」「ランサムウェア対策」「保持期間を強制」は Vault Lock を選びます。

⑤復元、PITR、復旧設計

バックアップは取得するだけでは不十分で、復元できることが重要です。では、復旧ポイントを選び、対象サービスに応じた設定で復元ジョブを実行します。やなど一部のサービスでは、を使って特定時点へ戻す設計もあります。

復旧観点	内容	SAA での判断
	どの時点までのデータ損失を許容するか	バックアップ頻度や PITR の有無に影響します。
	どれくらいの時間で復旧するか	復元手順、コピー先、事前準備に影響します。
PITR	特定時点への復旧	DB 系や DynamoDB などで重要です。
Restore testing	復元テスト	バックアップが実際に使えるか確認します。
クロス復旧	別リージョンのコピーから復旧	リージョン障害対策です。

RPO が短い場合、日次バックアップだけでは足りないことがあります。サービスが PITR に対応しているなら PITR を有効化し、対応していない場合はバックアップ頻度やアプリケーション側のを検討します。RTO が短い場合は、バックアップから復元するだけでなく、復元先ネットワーク、切り替え、アプリ起動手順まで含めて設計します。

保持期間が異なる複数の要件も、1 つのバックアップ計画の中で両立できます。対応サービスでは継続的バックアップを有効にすると直近の任意時点へ戻せる PITR が使え、これとは別のルールで定期を長期保持できます。継続的バックアップの保持期間には上限があるため、「直近の数日から数週間は任意時点へ戻したい」と「数か月から数年は保管したい」が同時に出る問題では、PITR 用のルールと長期保持用のルールを分けて考えます。

⚠️ 頻出: 「誤削除前の特定時点に戻したい」は PITR、「別リージョンで復旧したい」はクロスリージョンコピー、「復旧できることを継続的に確認したい」は復元テストや監査を考えます。

リージョン規模の災害に備える戦略は、RPO と RTO の厳しさとコストの兼ね合いで次の 4 つから選びます。下へ行くほど RPO と RTO は短くなり、待機側で常に動かす資源とコストは増えます。

DR 戦略	DR リージョンで常に用意するもの	RPO / RTO の目安	判断ポイント
バックアップと復元	バックアップのコピーだけ	時間単位	最も安価です。障害時にインフラをで作り直し、バックアップから復元します。
パイロットライト	データの複製先 (DB のレプリカなど) と・テンプレート	RPO は分単位以下、RTO は数十分程度	アプリケーションサーバーは止めておき、障害時に起動してします。
ウォームスタンバイ	縮小した規模で動き続ける本番と同じ構成	分単位	切り替え直後から縮小した容量で要求を処理でき、その後します。
マルチサイト (アクティブ/アクティブ)	本番と同じ規模で稼働し、普段から要求を処理する環境	ほぼゼロ	最も高価です。複数リージョンが同時に利用者へ応答します。

パイロットライトとウォームスタンバイの違いは、追加の操作なしにすぐ要求を処理できるかどうかです。パイロットライトはサーバーの起動とスケールアウトを先に行う必要があり、ウォームスタンバイはスケールアップだけで済みます。どちらも障害時に DR リージョンで台数を増やすため、そのリージョンのの vCPU などのサービスを本番規模まで事前に引き上げておきます。クォータはリージョンごとに管理されるため、本番リージョンで引き上げ済みでも DR リージョンには反映されません。や EC2 上のサーバーをブロック単位で継続的に複製するは、パイロットライトの考え方をマネージドで実現するサービスです。

⑥監査、通知、コスト最適化

は、バックアップジョブ、復元ジョブ、コピージョブの状態を一元的に確認できます。、、、、AWS Backup と連携し、バックアップ失敗の通知、監査証跡、確認を行います。

連携	主な用途	判断ポイント
CloudWatch	と	バックアップ失敗やジョブ状態を監視します。
EventBridge	バックアップイベントに応じた自動処理	失敗時に通知や修復処理を起動できます。
CloudTrail	操作の監査	誰が計画や Vault を変更したか追跡します。
SNS	ジョブ通知	成功・失敗を運用者へ通知します。
Backup Audit Manager	コンプライアンス確認	バックアップポリシーへの準拠を評価します。

コストは、バックアップストレージ、復元、復元テスト、クロス転送、Audit Manager などに影響されます。保持期間が長いほどコストは増えます。対応リソースでは増分バックアップや cold storage へのライフサイクル移行により、長期保管コストを抑えられます。cold storage へ移せるのは、、高度な機能を有効にしたなどで、移したバックアップは最低 90 日 cold storage に置く必要があるため、保持期間は移行までの日数より 90 日以上長くします。

AWS Backup は、AWS Backup の外で作成されたバックアップをすべて統制するわけではありません。サービス個別のバックアップ設定や手動が混在すると、重複コストや管理漏れが発生します。SAA では、中央管理したいなら AWS Backup に寄せ、個別機能が必要ならサービス固有機能と関係を確認します。

⚠️ 頻出: 「バックアップが取れていることを監査したい」「失敗時に通知したい」「保持期間でコストを最適化したい」は Audit Manager、EventBridge/SNS、ライフサイクルを組み合わせます。

試験対策

SAA では、はバックアップと復旧の設計問題で出ます。問題文に「複数 AWS サービスのバックアップを一元管理」「タグベースで対象を選択」「保持期間を自動化」「別や別アカウントへコピー」「バックアップ削除を防止」「を満たす」とあれば AWS Backup を候補にします。

問題文のキーワード	優先して考える機能	理由
複数サービスのバックアップ一元管理	AWS Backup	、、などをまとめて管理できます。
タグで対象を自動選択	Backup plan + resource selection	リソース追加時のバックアップ漏れを減らせます。
リージョン障害対策	クロスリージョンコピー	別リージョンに復旧ポイントを保管できます。
アカウント侵害・誤削除対策	コピー	バックアップ専用アカウントへ隔離できます。
管理者でも削除できない保持	Vault Lock	型の保護を強制できます。
特定時点に戻したい		対応サービスでは細かい時点へ復旧できます。
バックアップ準拠状況の確認	Backup	監査やレポートに使えます。

よくある誤答は、すべてを EBS や RDS 自動バックアップだけで済ませる選択肢です。単一リソースの簡単な保護ならそれで足りる場合もありますが、複数サービスにまたがる統制、タグベース適用、クロスアカウントコピー、Vault Lock、監査が必要なら AWS Backup が適切です。

AWS Backup との違いも重要です。バックアップは過去時点に戻すための保護です。可用性を高めるマルチ、RDS 、 Global Database、 Replication などは、バックアップとは目的が異なります。とバックアップは併用するものです。

/ も判断軸です。日次バックアップで許容できるならバックアップ計画で足りますが、数分単位で戻したいなら PITR や継続的バックアップを検討します。短い RTO が求められる場合、バックアップからの復元だけでは遅い可能性があり、ウォームスタンバイやレプリケーション構成も検討します。

最後に、コストとロック設定に注意します。長期保持や Vault Lock の Compliance mode は強力ですが、誤った保持期間を設定すると簡単に削除できず、保管コストが続きます。試験では、コンプライアンス要件とを両方満たす選択肢を選びます。

概要