Backup Architecture

1. ネイティブ自動化されたバックアップとAWS Backupを要件で使い分ける

サービス固有の自動化されたバックアップだけで要件を満たせる場合は、それ自体が候補です。複数リソースや複数アカウントへ統一したバックアップポリシーを適用したい場合はAWS Backupを評価します。

AWS Backupを採用しても、基盤となる サービスのバックアップ機構と完全に独立した仕組みが必ず作られるわけではありません。リソースタイプとバックアップタイプに応じた実装関係を確認します。

2. バックアップ計画を保護階層へ落とし込む

AWS Backupではバックアップ計画 / ルールとリソース割り当てを使ってスケジュール、ボールト、ライフサイクル、コピーをポリシー化できます。重要なのは、中央管理することと全リソースへ同一ルールを適用することを混同しないことです。

中央ガバナンス
        ↓
重要度 / 保持 / 障害範囲
        ↓
保護階層
        ↓
バックアップルール / リソース割り当て

重要データベース、一般ワークロード、再作成可能データなどで要件が異なるなら、中央管理を維持しながら計画 / ルールを分離します。

3. RDSでは定期バックアップと継続的バックアップの扱いが異なる

Amazon RDSをAWS Backupで保護する場合、定期バックアップと継続的バックアップを同じものとして扱いません。

継続的バックアップでは、AWS BackupがRDS / Auroraの自動化されたバックアップ管理を引き継ぎます。独立した2つのトランザクションログバックアップシステムが並行して作られるわけではありません。

4. 機能サポートはリソースタイプごとに確認する

AWS Backup対応リソースでも、定期 / 継続的、PITR、コピー、コールドストレージなどの対応範囲は同一ではありません。

必要な復旧機能
↓
リソースタイプ
↓
AWS Backup 機能対応
↓
ネイティブサービス機能
↓
候補を決定

例として、現在 AWS BackupではRDS マルチAZ DBクラスターの継続的バックアップ / PITRをサポートしません。PITRが必要ならRDS ネイティブ自動化されたバックアップを評価します。

5. Organizations バックアップポリシーはマルチアカウントへポリシーを展開する

AWS Organizationsのバックアップポリシーを使うと、組織 / OU / アカウントへバックアップポリシーを中央展開できます。

AWS Organizations
       ↓
バックアップポリシー
       ↓
OU / アカウント
       ↓
AWS Backup 計画
       ↓
対象リソース

Organizations バックアップポリシーではリソースタイプやタグを利用して対象を選択します。個別 リソース ARNを直接指定したい場合は、ローカルバックアップ計画のリソース割り当てを利用します。

6. コピーは必要な障害範囲へポリシーとして組み込む

クロスリージョン / クロスアカウントコピーが必要なら、バックアップルールのコピーアクションへ組み込みます。

プライマリ復旧ポイント
├─ クロスリージョンコピー
│      ↓
│  復旧リージョンボールト
└─ クロスアカウントコピー
       ↓
   バックアップアカウントボールト

コピー先では送信元とは別のライフサイクル / 保持期間を設定できます。ただしコピー機能の対応範囲はリソースタイプごとに確認します。

7. コピーとコールドストレージの順序を間違えない

コールド / アーカイブ階層へ移行済みの復旧ポイントは、後からクロスリージョン / クロスアカウントコピーできません。

バックアップ
↓
必要なコピーを実施
↓
送信元 / 宛先ごとにライフサイクル
↓
対応リソースならコールドストレージ

「まずコールドへ移してから別アカウントへコピーする」という順序を前提にしません。コピー要件とライフサイクルを一続きのポリシーとして設計します。

8. 定期と継続的では保持期間の設計が異なる

長期保持期間と短期PITRを同じバックアップタイプだけで満たそうとせず、継続的バックアップと定期復旧ポイントを組み合わせて評価します。

9. コールドストレージは長期保持期間のコスト最適化候補

対応リソースでは、定期復旧ポイントをウォームストレージからコールドストレージへライフサイクル切り替えできます。

定期バックアップ
↓
ウォームストレージ
↓
コールドストレージ
↓
有効期限

コールドストレージへ切り替えしたバックアップは少なくとも90日間コールド階層で保持する必要があります。短期間だけ保持するバックアップには適しません。

判断には保持期間、復元頻度、復元時間要件、機能サポート、コストを使います。

10. 保持期間変更時は定期と継続的を分離する

バックアップ計画の変更が既存復旧ポイントへ与える影響は、バックアップタイプによって同じではありません。

将来復旧ポイントだけを見るのではなく、既存復旧ポイントのライフサイクルもコスト / コンプライアンスの観点から確認します。

11. 増分バックアップとストレージコストもリソースタイプ依存

対応リソースでは定期バックアップが増分に保存され、変更データ中心でストレージを消費する場合があります。

コスト見積り
=
リソースサイズ
+
変更率
+
バックアップタイプ
+
保持
+
コピー数
+
ストレージ階層

「AWS Backupならすべて増分」と一般化せず、リソースごとの機能サポートを確認します。

12. コスト最小化より復旧要件を先に満たす

バックアップコストだけを最小化すると、RPO、保持期間、障害範囲、復元要件を満たせない場合があります。

13. 復元にはリソース固有のメタデータとIAMロールが必要

復旧ポイント ARNだけで、すべてのリソースを同じ設定で復元できるわけではありません。

復旧ポイント
↓
GetRecoveryPoint復元メタデータ
↓
復元 メタデータ
+
復元 IAMロール
↓
復元ジョブを開始
↓
復旧対象

復元 メタデータはリソースタイプによって異なり、対象識別子、サブネット、セキュリティグループ、インスタンスタイプなどが必要になる場合があります。

14. 復元は多くの場合新しいリソースとして作成する

AWS Backupの復元は、多くのリソースタイプで既存リソースを直接巻き戻すのではなく、新しいリソースとして復元します。

復旧ポイント
↓
新しいリソース
↓
設定確認
↓
アプリケーション接続 / ルーティング切替

一部リソースには異なる復元動作がありますが、「復元 = 必ずインプレースロールバック」と一般化しません。

15. コールドストレージはRTOへ影響し得る

コールドストレージはストレージコストを抑える候補ですが、復元時間とのトレードオフがあります。

コールドストレージからの復元はウォームストレージより通常さらに時間が必要で、AWS Backupは復元時間 SLAを提供していません。現在のAWSではコールドストレージからの復元はウォームストレージより通常約4時間長くかかるとされています。

最低ストレージコスト
≠
常に最適な復旧アーキテクチャ

保持
+
復元時間要件
+
RTO
        ↓
ストレージ階層を選択

16. 判断例

17. 判断フロー

バックアップ要件
↓
保護対象リソース / アカウント / OU
↓
ネイティブバックアップで十分か
または
中央 管理が必要か
↓
ネイティブ自動化されたバックアップ / AWS Backup
↓
定期 / 継続的
↓
機能対応確認
↓
コピー要件
↓
コピーを先に実施
↓
保持 / ライフサイクル / ストレージ階層
↓
復元対象
↓
復元 メタデータ + IAMロール
↓
アプリケーション接続を含む復旧経路
↓
RPO / 保持 / RTOを満たすか評価

18. 障害モード