AWS Certified CloudOps Engineer - Associate (SOA-C03) #6 Domain 2-2 信頼性 — バックアップ・復元と災害復旧 (DR)
#5 で「サービスが動き続ける」可用性を押さえたなら、この記事は「データを失わずに復元する」バックアップと災害復旧を扱います。信頼性ドメインでは可用性とデータ保護は一対です。運用で最も重い事故はインスタンスが落ちることよりも データが消えること なので、試験もバックアップ戦略と復旧目標を比重をもって問います。
バックアップの基本単位 #
| リソース | バックアップ手段 | 特徴 |
|---|---|---|
| EBS ボリューム | スナップショット (Snapshot) | 増分保存、S3 に保管、リージョン内 |
| EC2 インスタンス | AMI | ボリュームスナップショット + メタデータ。インスタンス再作成 |
| RDS | 自動バックアップ・手動スナップショット | ポイントインタイムリカバリ (PITR) 対応 |
| EFS・DynamoDB・その他 | サービスごとのバックアップまたは AWS Backup | 中央管理が可能 |
EBS スナップショットの性質 #
EBS スナップショットは 増分 (incremental) です。最初のスナップショットだけが全体で、以降は変わったブロックだけを保存します。そのため頻繁に取得してもコストが線形には増えません。スナップショットは S3 に保存され (ユーザーに直接は見えません)、別のリージョン・アカウントへコピー して地理的分散や分離を構成できます。
RDS バックアップ: 自動バックアップ vs スナップショット #
| 区分 | 自動バックアップ | 手動スナップショット |
|---|---|---|
| 保持 | 最大 35 日、保持期間が過ぎると削除 | 自分で削除するまで永続 |
| ポイントインタイムリカバリ (PITR) | 可能 | 不可 (取得した時点のみ) |
| インスタンス削除時 | 一緒に削除 | 残る |
運用の定番は「インスタンスを削除してもバックアップを残したい」です。自動バックアップはインスタンスと一緒に消えるので、永続保持が必要なら 手動スナップショット を別途取得しておく必要があります。
AWS Backup: バックアップの中央管理 #
サービスごとにバックアップを別々に設定すると、漏れと不一致が生じます。AWS Backup は複数サービスのバックアップを 一つのポリシーで中央管理 します。
| 構成 | 役割 |
|---|---|
| Backup Plan | バックアップの頻度・保持・時間枠を定義したポリシー |
| Backup Vault | バックアップが保存される場所。アクセスポリシー・暗号化 |
| Resource Assignment | タグや ID でバックアップ対象を指定 |
主な効用は次のとおりです。
- タグベースの一括適用 — 特定のタグが付いたすべてのリソースを一つのポリシーでバックアップ
- クロスリージョン・クロスアカウントコピー — バックアップの他リージョン複製をポリシーに含める
- Backup Vault Lock — バックアップを 修正・削除不可 (WORM) にロックして、ランサムウェアや誤削除に備える。コンプライアンス要件に対応
- 中央レポート — どのリソースがポリシーから外れているかを一目で
「数十のアカウント・複数サービスのバックアップを標準ポリシーで強制し、規定遵守を証明せよ」という要求の答えが AWS Backup (+ Organizations 連携 + Vault Lock) です。
RPO と RTO: 復旧目標 #
DR 戦略を選ぶ基準が 2 つの指標です。
| 指標 | 定義 | 一行で |
|---|---|---|
| RPO (Recovery Point Objective) | 許容できる データ損失の時間 | 「どれだけ過去に戻ってよいか」 |
| RTO (Recovery Time Objective) | 許容できる 復旧所要時間 | 「どれだけ速く復元すべきか」 |
RPO が短いほどバックアップを頻繁に (またはリアルタイム複製) 取得する必要があり、RTO が短いほど待機環境を事前に立ち上げておく必要があります。両方を短くするとコストが大きくなるので、要求に合った最小コストの戦略 を選ぶのが試験の枠組みです。
DR 戦略 4 つ #
RPO・RTO とコストのトレードオフに応じて、4 つの戦略に分かれます。SAA で見た枠組みを運用の視点で改めて整理します。
| 戦略 | 平時コスト | RTO | 構成 |
|---|---|---|---|
| Backup & Restore | 最も低い | 最も長い (時間) | バックアップのみ他リージョンに。障害時に最初から復元 |
| Pilot Light | 低い | 長い | 中核 (DB 複製) だけ起動しておき残りは停止。障害時に起動 |
| Warm Standby | 中間 | 短い (分) | 縮小版の全環境を常時起動。障害時に拡張 |
| Multi-Site (Hot) | 最も高い | 最も短い (ほぼ 0) | 両側をフル容量で同時運用 |
選択の基準は単純です。
- コスト最小 が優先で復旧が遅くてもよいなら → Backup & Restore
- 速い復旧 が優先でコストを許容するなら → Warm Standby または Multi-Site
- その間の妥協が Pilot Light
「RTO 数分、コストは最小化」のように 2 つの条件が一緒に来たら、その両方を同時に満たす地点 (通常 Pilot Light か Warm Standby) を選ぶのが正解です。
試験での出題パターン #
- インスタンスを削除してもバックアップを維持 → 手動スナップショット (自動バックアップは一緒に削除)
- 複数サービスのバックアップを標準ポリシーで強制 → AWS Backup + タグベースのポリシー
- バックアップを削除・改ざん不可に → Backup Vault Lock (WORM)
- リージョン障害に備えてバックアップを保管 → スナップショット・バックアップを 他リージョンコピー
- コスト最小・復旧が遅くてもよい → Backup & Restore
- RTO 数分が必要 → Warm Standby
- RPO・RTO がほぼ 0 → Multi-Site
よくある落とし穴 #
1) 自動バックアップが永続保持されると思う #
自動バックアップは保持期間 (最大 35 日) が過ぎるか、インスタンスを削除すると消えます。永続保持は手動スナップショットです。
2) スナップショットが全体コピーだと誤解 #
EBS スナップショットは 増分 です。頻繁に取得しても変更ブロックだけが追加されます。
3) DR 戦略をコストだけで選ぶ #
最も安い Backup & Restore が常に答えとは限りません。RTO・RPO 要求 を先に読み、それに合った最小コストの戦略を選ぶべきです。
4) マルチリージョンをデフォルトと仮定 #
ほとんどの可用性要求は Multi-AZ で十分です。マルチリージョン DR は リージョン障害・規制 のような明示的な要求があるときです。
まとめ #
この記事で押さえたこと:
- バックアップ単位は EBS スナップショット (増分)・AMI・RDS バックアップ。スナップショットは他リージョン・アカウントへコピー可能
- RDS 自動バックアップはインスタンスと一緒に削除、永続保持は 手動スナップショット
- AWS Backup で複数サービスをタグベースのポリシーで中央管理。Vault Lock で WORM
- RPO(データ損失許容) と RTO(復旧時間許容) が DR 戦略選択の基準
- DR の 4 戦略: Backup & Restore · Pilot Light · Warm Standby · Multi-Site。コストと RTO のトレードオフ
- 要求を先に読み、それに合った最小コストの戦略 を選ぶのが核心
次: Domain 3-1 CloudFormation と IaC #
データ保護まで信頼性ドメインを終えました。次は 3 番目のドメインである デプロイ・プロビジョニング・自動化 です。
#7 Domain 3-1 デプロイ: CloudFormation の深掘りと IaC では、CloudFormation のスタックとテンプレート構造、変更セット (Change Set) とドリフト検出、複数アカウント・リージョンへデプロイする StackSets、そして CDK・Terraform のような他の IaC ツールとの関係まで運用の視点で整理します。