クラウドがよく分かる！お役立ちコラム

AWSバックアップは十分ですか？復旧できないリスクと確認ポイント

この記事は約13分で読めます。

• #aws backup restore risk

バックアップの「取得している」と「復旧できる」は別物

バックアップ運用について、多くの現場で「バックアップを取得しているかどうか」に意識が向きがちです。しかし本当に問われるべきは、「実際に復旧できるか」「事業を止めずに継続できるか」という点です。

バックアップの目的は「取ること」ではなく「戻せること」

バックアップを取得する目的は、障害・誤操作・攻撃が起きたとき、データやシステムを元の状態に戻すことです。取得自体が目的化してしまうと、保持期間や暗号化キーの管理、復旧手順の整備といった「戻すための準備」がおろそかになってしまいます。バックアップは「取って終わり」ではありません。「戻せることを確認して初めて完成する」運用だと捉えることが重要です。

自動化されているからこそ見落としが起きやすい

AWS Backupはバックアッププランを設定すれば、対象リソースのバックアップを自動的に取得し続けてくれます。この自動化は運用負荷を大きく下げる一方で、「動いているから大丈夫」という思い込みを生みやすいのです。新しく追加したリソースがバックアップ対象に含まれているか、保持期間が事業要件に合っているかは、自動化されているからこそ定期的に人の目で確認する必要があります。

AWSBackupから復旧できない典型パターン

実際にどのような場合に「バックアップは取得していたのに復旧できない」という事態が起きるのでしょうか。よくある典型パターンを見ていきます。

バックアップの対象漏れ

最も多いトラブルが、バックアップ対象の範囲に漏れがあるケースです。EC2/EBSはバックアップしていても、RDSやAurora、EFS、DynamoDBといった他のデータストアが対象から漏れているなどが考えられます。また、IAMロールやネットワーク構成、アプリケーションの設定情報までは戻せないこともあるのです。

システムは複数のAWSサービスを組み合わせて構築されていることが多いでしょう。そのため、どのリソースが「守る対象」に含まれているかを可視化しなければなりません。いざという時に想定外の抜け漏れに気づくことになります。

なお、AWS Backupの「保護されたリソース」画面に表示されるのは「バックアップの設定対象として登録済みのリソース」です。

この画面だけでは対象漏れの有無までは分かりません。自社で管理しているリソース台帳と突き合わせて確認する必要があります。

保持期間切れ・世代不足

バックアップの保持期間（保持設定）が短すぎるパターンにも注意です。必要な世代数を確保できていないと、復旧したいタイミングで必要な復旧ポイントがすでに削除されかねません。特に、障害の発生に気づくまでに時間がかかるケースには注意すべきです。トラブル前の健全なバックアップが、すでに保持期間を過ぎて消えている可能性があります。

同一リージョン・同一アカウントにしか置いていない

バックアップを取得先と同じリージョン・同じアカウントにしか保管していないか確認しましょう。リージョン単位の障害や、アカウントの認証情報が侵害された場合に、バックアップが利用できないリスクがあります。バックアップは本番環境とは独立した場所に、意図的に分離して保管することが重要です。

KMS暗号化キーの喪失・権限不備で復号できない

AWS BackupではAWS Key Management Service（KMS）を使ってバックアップを暗号化するのが一般的です。しかし、暗号化に使ったKMSキーを誤って削除するケースが見受けられます。また、復元を実行するIAMロールにキーへのアクセス権限が不足する場合もあるのです。

これらの状態に陥ると、バックアップ自体は残っていても復号できず、復元に失敗します。バックアップの保護と同じくらい、暗号化キーのライフサイクル管理も重要な運用項目です。

復旧手順が未整備・一度も検証されていない

バックアップから実際にリソースを復元する手順を誰も試したことがない、というケースも少なくありません。この場合、以下の事態に陥るリスクがあります。

• ● 復元操作そのものが初めてで操作が分からない
• ● IAMロールの権限が足りずエラーになる
• ● 復元後にネットワーク設定が必要だと気づいていない
• ● アプリケーション側の再設定方法が明確でない

どれも実際に手を動かして検証していなければ見えてきません。RPO（どの時点まで戻せるか）とRTO（どれだけ早く戻せるか）についても、目標値だけを決めて実際に測定したことがない組織が多いのです。

自社のバックアップを見直す確認ポイント

ここまで見てきた典型パターンを踏まえ、自社のバックアップ運用を見直す際に確認しておきたいポイントを整理します。

• ● 対象範囲：守るべきリソースがすべてバックアッププランに含まれているか
• ● RPO：障害発生時、どの時点のデータまで戻せればよいか
• ● RTO：どれだけの時間で復旧を完了させる必要があるか
• ● 保管の分離：リージョン障害への備えとして別リージョンへコピーしているか、
• ● 改ざんへの対応：削除・改ざんへの備えとしてVault Lockや別アカウントでの保管を検討しているか
• ● 復旧テストの有無：実際に復元操作を行い、手順と所要時間を検証したことがあるか
• ● KMSキー管理：暗号化キーの削除防止・アクセス権限が適切に設定されているか
• ● 保持設定：保持期間・世代数が事業要件

これらは一度確認して終わりではありません。システム構成の変更や新しいリソースの追加のたびに見直すべき項目です。

参考：バックアップ運用にかかる費用感の考え方

AWS Backupの料金は、主に保存容量に応じたストレージ料金と、復元時にかかる料金で構成されます。ただし実際の金額は、リージョン、保護するリソースの種類、保持期間、無料枠の適用有無によって変化するものです。そのため、条件を指定せずに一律の目安金額を示すことはできません。

自社の構成での実際の費用感を把握したい場合は、まず以下を明確にしましょう。

• ● 保護するリソースの種類
• ● リソースの容量
• ● 管理する元あるいは先のリージョン
• ● 保持期間

これが明確になれば、AWS Pricing Calculatorで試算できます。また実際にバックアップを取得し始めると、AWSの請求ダッシュボードで既存の利用実績の確認が可能です。

【出典】AWS | AWS Backup の料金

AWS BackupだけではBCP対策にならない理由

「AWS Backupを導入しているから、事業継続計画（BCP）は万全」と考えるのは早計です。AWS Backupが担っているのは、あくまでBCPを構成する要素のひとつに過ぎません。

BCPはデータ復旧だけでなく体制・手順・代替環境まで含む

BCPとは、災害や障害が発生した際にも事業を継続、または早期に再開するための包括的な計画です。データを復旧できることはその重要な前提条件ですが、それだけでは足りません。インフラをコードで再構築できる仕組み（IaC）、対応する担当者の体制と連絡手段、代替環境での業務継続手順、関係者への周知方法まで含めて初めてBCPと呼べます。

AWS Backupが担うのは「データを戻す」部分だけ

AWS Backupが解決してくれるのは、データやリソースの復元という部分です。復元したデータをもとにシステム全体をどう再構築するか、業務をどう継続するかは別途検討する必要があります。IaCによる構成管理や、運用手順の整備を心がけましょう。

「バックアップを取っているからBCPは大丈夫」ではありません。「バックアップは、BCPを支える要素の一つ」という位置づけで捉え直すことが重要です。

【出典】AWS | バックアップ・リストアによる BCP 対策のためのクラウド構成と料金試算例

ランサムウェア対策としての復旧側の備え

近年増加しているランサムウェア攻撃への対策として、IAMによるアクセス制御やエンドポイント保護が用いられます。しかし、万が一侵害された場合に「復旧できる状態を保つ」こともあわせて重要な備えです。AWS Backupには、この復旧側の備えを支える機能がいくつか用意されています。

Vault Lockでバックアップを改ざん・削除から守る

AWS Backup Vault Lockは、バックアップボールトに書き込み後は変更・削除できないWORM（Write Once Read Many）保護をかける機能です。保持期間中は組織の管理者はもちろん、AWSのルートユーザーであっても削除できない「Compliance mode」と、IAM権限を持つ管理者であれば削除・変更が可能な「Governance mode」の2種類があります。ランサムウェアに侵害されてバックアップごと削除・改ざんされるという最悪のシナリオを防ぐうえで有効な機能です。

【出典】AWS | AWS Backup Vault Lock

論理的にエアギャップされたボールトで隔離する

2024年8月には、AWS Backupに「論理的にエアギャップされたボールト（logically air-gapped vault）」が追加されました。バックアップをAWS Backupのサービス専用アカウント内に保管し、本番環境のアカウントから論理的に分離する仕組みです。暗号化にはデフォルトでAWSが所有する暗号化キーが使われますが、ボールト作成時に顧客管理のKMSキーを選択することもできます。

別リージョンにも保管したい場合は、別途クロスリージョンコピーを設定する必要があります。アカウントが侵害された場合でも、バックアップ自体は隔離された状態を保てる点が特徴です。東京リージョンでもすでに利用可能で、2026年7月にも対象リージョンの拡大が発表されるなど、AWSがランサムウェア対策として力を入れている領域の一つです。

【出典】AWS | Introducing AWS Backup logically air-gapped vault、AWS | Logically air-gapped vault

復元テスト機能で「戻せること」を実際に検証する

AWS Backupの復元テスト（restore testing）機能での検証がおすすめです。指定したスケジュールで自動的に復元処理を実行し、実際に復元できるかどうかを検証できます。EC2やEBS、RDS、Aurora、DynamoDB、EFSなど幅広いリソースへの対応が魅力です。

復元にかかった時間は、リソース単位の復旧所要時間がRTOの目標に対してどの程度かを把握する材料といえます。ただし、これはあくまでリソースの復元時間に限ったものです。アプリケーションが正常に動作し業務を再開できるまでの時間を測るものではありません。業務全体のRTOを検証するには、復元後の動作確認や接続先の切り替えまで含めた訓練が別途必要です。

【出典】AWS | Automatic restore testing and validation is now available in AWS Backup、AWS | Restore testing validation

S3バックアップへの「アクセスポイント」で復旧前にデータを確認する

2026年8月には、AWS Backup for Amazon S3に「アクセスポイント」機能が追加されました。これまでバックアップ済みのS3データを確認するには復元（リストア）を実行する必要がありました。しかし、この機能を使うと復元せずに、読み取り専用でバックアップデータへ直接アクセスできます。GetObjectやHeadObject、ListObjectsV2といった標準的なS3 APIで、スナップショットやポイントインタイムの復旧ポイント、論理的にエアギャップされたボールト内のデータも直接参照可能です。

この機能で想定される用途として、AWSでは以下が挙げられています。

• ● 必要なファイルだけを選んで取り出す「対象を絞った復旧」
• ● バックアップデータが壊れていないかを確かめる「データ検証」
• ● 規制対応のための「コンプライアンス監査」
• ● ランサムウェアなどのセキュリティインシデント発生時の「フォレンジック調査」

アクセスポイントを使用している間は対象の復旧ポイントが削除から保護される点も、ランサムウェア対策の観点で見逃せないポイントです。「まず中身を確認してから、必要な分だけ戻す」という運用がしやすくなりました。復旧側の備えはさらに一歩進んだといえるでしょう。

【出典】AWS | AWS Backup for Amazon S3 now supports direct access to backup data