バックアップ設計

このレッスンでできるようになること。保持期間や監査の要件文から、AWS Backup とサービス個別のスナップショットのどちらで組むかを決め、世代管理と保護の設定まで選べるようになります。

要件の文から入る

ある会社が、EC2 のインスタンスストア以外のボリューム、RDS、EFS、DynamoDB を使っています。監査部門から「すべてのバックアップを7年間保持し、取得状況を一元的に報告できること。運用担当者を増やさずに実現すること」と指示が出ました。何を選びますか。

注目する語は「すべての」「一元的に報告」「運用担当者を増やさずに」です。各サービスの自動バックアップ機能を個別に設定していく案も技術的には成立しますが、サービスごとに設定画面と保持ルールが分かれるため、横断の報告と運用が人手に寄ります。この形が出たら AWS Backup のバックアップポリシーが答えです。複数サービスのバックアップを1つのプランで束ね、保持ルールとレポートをまとめて扱うためのサービスだからです。

AWS Backup とサービス個別バックアップの線引き

どちらでも取得はできます。試験で問われるのは、その先の運用要件です。

判断の軸は次の一文です。対象が1サービスに閉じていて、そのサービス固有の機能が要るなら個別。複数サービスにまたがるか、監査や組織横断の要件が付いたら AWS Backup。

世代管理と保持ポリシー

保持の設計で押さえる論点は3つです。

1つめは保持期間そのものです。バックアッププランのライフサイクルで、一定期間が過ぎたらコールドストレージへ移し、さらに保持期間を過ぎたら削除する、という流れを定義します。長期保持は暖かい階層に置き続けるより冷たい階層へ移した方が安く済むので、7年保持のような要件では移行を組み込むのが定石です。

2つめは複製先です。「リージョン障害に備える」「本番アカウントが侵害されてもバックアップは残す」と書かれていたら、バックアップのコピー先を別リージョンや別アカウントに指定します。同じアカウントの同じリージョンにだけ置いたバックアップは、その障害や事故の巻き添えになります。

3つめは改変防止です。「保持期間中は誰も削除できないこと」「ランサムウェア対策として上書きを防ぐこと」と書かれたら、AWS Backup のボールトロックのように、いったん設定すると保持期間中の削除を止められる仕組みを選びます。S3 に置いた成果物であれば Object Lock が同じ役割を果たします。IAM ポリシーで削除権限を外す案は惜しいのですが、権限を持つ管理者がいる限り理屈の上では消せてしまうため、改変防止の要件語に対しては弱い答えになります。

RDS の自動バックアップとスナップショットの違い

ここも定番です。自動バックアップは設定した保持期間の範囲で、指定した時点への復元ができます。手動スナップショットは明示的に削除するまで残ります。要件文に「任意の時点に戻したい」とあれば自動バックアップの保持期間の話、「特定の時点の状態を長期に保管したい」とあれば手動スナップショットの話です。なお DB インスタンスを削除すると自動バックアップは消えるため、長期保管の要件があるなら手動スナップショットか AWS Backup に寄せます。

要件語から構成への対応表

よくある引っ掛け

1つめは、削除防止を IAM の権限設計だけで答えてしまうものです。「保持期間中は削除を許さない」という監査要件には、権限の付け外しではなく、設定そのものが削除を拒む仕組みを当てます。

2つめは、バックアップを同一リージョン内に置いたまま「リージョン障害に備える」と書かれた問題に答えてしまうものです。コピー先の指定まで見て選択肢を切ります。

まとめ

• 複数サービス横断、監査報告、組織全体への強制は AWS Backup の担当です
• 保持設計はライフサイクル、コピー先、改変防止の3点で組みます
• 長期保持はコールドストレージへの移行を組み込むと安くなります
• 「削除できないこと」はボールトロックや Object Lock で満たします。権限設計だけでは弱いです
• RDS は、時点復元なら自動バックアップ、長期保管なら手動スナップショットです