AWS Backupとは？対応サービス・料金・バックアッププラン作成と復元手順を解説

AWS Backupは、EC2・RDS・DynamoDB・EFSといった複数のAWSサービスのバックアップを1つのコンソールから設定・監視できるマネージドサービスです。サービスごとにバラバラだったバックアップ運用を、共通のポリシー（バックアッププラン）で一元管理できる点が特徴です。一方で「amazon workspace バックアップ」で検索してたどり着いた場合は注意が必要で、Amazon WorkSpacesはAWS Backupの対象外です。本記事では対応サービスと料金、バックアッププランの作成から復元までの手順を整理し、WorkSpacesを含む「AWS Backupでは守れないリソース」の扱いまで解説します。

まとめ：AWS Backupの要点と使いどころ

AWS Backupは、対応サービスのバックアップをバックアッププランで自動化し、バックアップボールトに集約する仕組みです。EC2・EBS・RDS・Aurora・DynamoDB・EFS・FSx・S3など主要リソースを幅広くカバーし、クロスリージョン／クロスアカウントのコピーや、コールドストレージへのライフサイクル移行によるコスト最適化に対応します。料金はバックアップ保管量・復元量・リージョン間転送で課金され、コールド移行で保管コストを大きく下げられます。ただしAmazon WorkSpacesは公式のサポート対象一覧に含まれず、WorkSpaces自身の自動スナップショット（12時間ごと）で保護される別系統です。この違いを取り違えると「バックアップしたつもりで守れていない」状態になります。以降で対応サービス・WorkSpacesの正しい扱い・料金・プラン作成・復元・ログ監査を順に見ていきます。

AWS Backupの仕組みと一元管理の考え方

AWS Backupが解く課題は「バックアップ設定の分散」です。EC2はAMIやEBSスナップショット、RDSは自動スナップショット、DynamoDBはオンデマンドバックアップと、サービスごとに管理画面も保持ルールも異なります。AWS Backupはこれらを共通の枠組みに載せ替え、組織全体のバックアップを横断的に統制します。

サービス個別のバックアップとの違い

各サービスが持つ標準のバックアップ機能は、AWS Backupを使わなくても利用できます。ただしそれらは中央管理の対象外です。AWS Backupで管理下に置くと、保持期間の統一、タグでの一括対象化、コンプライアンス監査、リージョン横断のコピーといった運用が1か所で完結します。逆に言えば、AWS Backupで「オプトイン（管理対象に追加）」していないサービスは、コンソールにバックアップが並んでも一元管理されません。

バックアッププラン・バックアップボールト・リソース割り当ての関係

運用の中心は3つの要素です。バックアッププランは「いつ・どのくらいの間隔で・どれだけ保持するか」を定義するスケジュールとライフサイクルの束。バックアップボールトは復旧ポイント（リカバリーポイント）を格納する保管先で、暗号化キーやアクセス権をここで管理します。リソースの割り当ては「どのリソースをこのプランで守るか」の指定で、タグ条件による自動選択もできます。この3つを組み合わせるだけで定期バックアップが回り始めます。

AWS Backupが対応するAWSサービス（2026年時点の一覧）

公式ドキュメントのサポート対象は幅広く、ストレージ・データベース・コンテナまで及びます。主要なものは次のとおりです。

AWS OrganizationsやCloudFormationとの連携で、複数アカウント・スタック単位のバックアップも統制できます。GuardDutyと連携した復旧ポイントのマルウェアスキャンにも対応しており、復元前に感染データを検知できます。DynamoDBの特徴や料金の詳細や、複数リージョン運用を前提にしたDynamoDB Global Tablesの構成を押さえておくと、バックアップ設計の判断がしやすくなります。

継続的バックアップ（PITR）とスナップショットの使い分け

AWS Backupには2つの取得方式があります。スナップショット方式は指定スケジュールで断面を取る一般的な方法です。継続的バックアップ方式は変更を継続的に記録し、指定した任意時点に復元するポイントインタイムリカバリ（PITR）を可能にします。継続的バックアップに対応するのはRDS・Aurora・S3・SAP HANAなど一部で、対応可否がそのまま「秒単位の巻き戻しが必要な基幹DBをどう守るか」の設計判断に直結します。全リソースがPITR対応ではない点を前提に、要件の厳しいものから割り当てます。

対象外のサービスと自前バックアップが必要なケース

サポート一覧に載らないリソースは、AWS Backupだけでは守れません。代表例がAmazon WorkSpacesで、ほかにもLambda関数コードや一部のマネージドサービスの設定情報などは別手段が要ります。「AWS環境だからAWS Backupを有効化すれば全部安心」という前提は成り立ちません。対象外リソースは、そのサービス固有のバックアップ機能や、データのS3/FSxへのエクスポートで個別に守る必要があります。次章でWorkSpacesを具体例に、対象外リソースの守り方を示します。

Amazon WorkSpacesのバックアップとAWS Backupの違い

「amazon workspace バックアップ」で情報を探している場合、最初に押さえるべき結論は、Amazon WorkSpacesはAWS Backupでバックアップできないという事実です。AWS BackupでWorkSpacesを対象に追加しようとしても選択肢に現れません。WorkSpacesは独自のスナップショット機構でデータを保護しており、AWS Backupとは別系統で考える必要があります。

WorkSpacesがAWS Backupの対象外である理由

AWS Backupの公式サポート対象一覧にAmazon WorkSpacesは含まれていません（2026年時点）。仮想デスクトップであるWorkSpacesは、内部的なスナップショットの取得・復元・再構築という専用フローで守る設計になっているためです。したがって、WorkSpacesの保護を「AWS Backupのバックアッププランに任せる」構成は組めません。ここを誤解したまま運用すると、AWS Backup側の管理画面にはWorkSpacesの復旧ポイントが一切現れず、守れていないことに気づけません。

WorkSpacesの自動スナップショット（12時間ごと・ルート／ユーザーボリューム）

WorkSpacesは復元用の自動スナップショットを12時間ごとに取得します。WorkSpaceが正常なときはルートボリューム（OSやアプリ）とユーザーボリューム（利用者のデータ）の両方のスナップショットがほぼ同時に作成され、不具合がある状態ではユーザーボリュームのみが取得されます。最初のスナップショットはWorkSpace作成後おおむね30分以内（地域によっては数時間）に作られます。取得タイミングはコンソールのWorkSpace詳細画面「Snapshots」で確認できます。この間隔は固定で、より短い間隔での取得はできません。

復元と再構築の違いと、失われるデータ

WorkSpacesの巻き戻しには「復元（restore）」と「再構築（rebuild）」の2つがあり、戻る範囲が違います。復元はルートボリュームとユーザーボリュームの両方をスナップショット時点までロールバックします。再構築はユーザーボリュームのデータのみをロールバックし、ルートボリュームは最新のバンドルイメージから作り直します。どちらも「直近12時間より新しい変更は失われうる」点は共通です。誤削除したユーザーファイルだけ戻したいなら再構築、OS側の破損を含めて時点回復したいなら復元、と使い分けます。

スナップショットだけに頼らないユーザーデータ保護

12時間間隔の自動スナップショットは、要件によっては粒度が粗すぎます。数時間前の状態が必要な業務では、この間隔が原因でデータを失う場面があります。実務では、失いたくないファイルをWorkSpaces内のローカルに置きっぱなしにせず、S3やFSx、社内ファイルサーバなどWorkSpacesの外へ日次以上の頻度で退避させる設計が有効です。手動バックアップはWorkSpaces標準では用意されていないため、より短い間隔・任意時点の保護が要るなら、ファイル共有やサードパーティのバックアップツールを併用します。

AWS Backupの料金体系とコスト最適化の勘所

AWS Backupの利用料は、機能利用料ではなくバックアップの「保管量」と「操作量」で決まります。課金要素を把握しておくと、保持ポリシーの設計でそのままコストが変わります。

課金される4つの要素（保管・復元・リージョン間転送）

課金は大きく、ウォームストレージ保管料・コールドストレージ保管料・復元（リストア）量・リージョン間コピーの転送量に分かれます。保管料はサービスごとに単価が異なります。以下はus-east-1の目安で、リージョンやサービスで変動するため最新は公式の料金ページで確認してください。

意外な出費になりやすいのがリージョン間コピーと、削除済みDBのスナップショットです。Auroraは自動バックアップ有効かつ保持期間が長い間は追加課金されませんが、元DBを削除するとボールト内のスナップショットが課金対象に変わります。ブルー／グリーンデプロイでの一時的なDB削除でも起きるため、DR用コピーと保持設計は費用影響を試算してから決めます。

コールドストレージへのライフサイクル移行でコストを下げる

長期保持のバックアップは、ウォームからコールドストレージへ自動移行させると保管料を大幅に削減できます。コールド移行はバックアッププランのライフサイクル設定で「取得からXX日後にコールドへ、YY日後に削除」と指定します。コールドには最低保存期間（90日）の条件があり、頻繁に読み出す短期バックアップには不向きです。「直近1〜2週間はウォームで即復元、それ以降の月次・年次はコールドで安く長期保管」という二層設計が、復元速度と保管コストの現実的な落としどころです。

バックアッププランの作成手順

実際のセットアップは、プランを作り、対象リソースを割り当てるだけで動き始めます。コンソール・CLI・CloudFormationのいずれでも構成できます。

コンソールでのプラン作成とスケジュール設定

AWS Backupコンソールで「バックアッププランを作成」を選び、テンプレートから始めるか新規に作ります。ルールごとに、取得スケジュール（cronまたはrate式）、バックアップウィンドウ、保持期間、コールド移行の有無、保管先ボールトを指定します。スケジュールは日次・週次・月次のほか、最短1時間間隔まで設定できます。基幹系は日次＋長期保持、検証環境は週次といったように、重要度で間隔と保持を変えるのが基本です。

タグによるリソースの自動割り当て

プランに対象を割り当てる際、リソースIDを個別指定するほかに、タグ条件（例：Backup=true）で自動選択できます。タグ方式にしておくと、後から作成したリソースにタグを付けるだけで自動的にバックアップ対象へ加わり、付け忘れによる保護漏れを減らせます。EC2インスタンスを守る場合は、付随するEBSボリュームも含めてAMIとして取得される点を前提に、ボリューム構成をタグ運用に合わせて整理しておきます。EC2とLightsailの違いを理解しておくと、どのコンピュートリソースをAWS Backup管理下に置くべきかの判断がしやすくなります。

クロスリージョン・クロスアカウントコピーの設定

災害対策では、取得した復旧ポイントを別リージョンや別アカウントへコピーします。バックアッププランのコピー先設定で対象リージョン／アカウントとボールトを指定すると、取得のたびに自動でコピーが作られます。ランサムウェアや誤操作に備え、本番アカウントとは別の「バックアップ専用アカウント」へコピーしておくと、本番アカウントが侵害されても復旧手段を残せます。

バックアップからの復元（リストア）手順

復元は、保管された復旧ポイントを選んで戻す操作です。サービスによって「元に上書きするのか、新しいリソースとして作るのか」が異なります。

復旧ポイントを指定した復元の流れ

コンソールのボールトから対象の復旧ポイントを選び、「復元」を実行します。復元時にはリソースタイプに応じた設定（復元先のVPC・サブネット・インスタンスタイプ・暗号化キーなど）を指定します。継続的バックアップ対応リソースなら、断面ではなく任意の時点を指定した復元（PITR）も選べます。復元は基本的に新しいリソースを生成する形になるため、既存リソースへの上書きにはなりません。

サービス別に異なる復元後の扱い

EC2は復旧ポイントからインスタンスをまるごと再作成し、インスタンスタイプやセキュリティグループなどの構成も復元メタデータから引き継ぎます。RDSは新しいDBインスタンスとして復元され、接続先エンドポイントが変わるためアプリ側の向き先変更が必要です。接続プールを挟んで切り替えを吸収したい場合はRDS Proxyの接続プールの利用も検討します。DynamoDBは新しいテーブルとして復元され、テーブル名の指定が必要です。復元後はエンドポイントや名前が変わる前提で、切り替え手順まで含めて復旧計画を用意しておきます。

バックアップの監査ログとランサムウェア対策

バックアップは「取れていること」と「壊されないこと」の両方が要件です。AWS Backupには、運用状況を可視化する監査機能と、復旧ポイントを保護する仕組みがあります。

AWS Backup Audit ManagerとCloudTrailによるログ確認

バックアップジョブの成否や、社内ポリシー（例：全対象が日次で取得され90日保持されているか）への準拠状況は、AWS Backup Audit Managerでレポート化できます。API呼び出しレベルの操作ログはCloudTrailに記録され、「誰がいつ復旧ポイントを削除したか」まで追跡できます。ジョブ失敗はEventBridge経由でSNS通知に流し、取得漏れを放置しない運用にします。

Backup Vault Lockによる削除・改ざん防止

Backup Vault Lockは、ボールト内の復旧ポイントを保持期間中は削除・変更できないWORM状態にする機能です。コンプライアンスモードで有効化すると、ルート権限を持つ管理者でも期間内の削除ができなくなり、ランサムウェアや内部不正による「バックアップごと消される」事態を防げます。本番の重要データは、クロスアカウントコピー先のボールトにVault Lockを併用しておくと、多層で復旧手段を守れます。

よくある質問

AWS BackupでAmazon WorkSpacesはバックアップできますか？

できません。Amazon WorkSpacesはAWS Backupの公式サポート対象一覧に含まれず、バックアッププランの対象に追加できません。WorkSpacesは独自の自動スナップショット（12時間ごと、正常時はルートとユーザーの両ボリューム）で保護され、巻き戻しは「復元」または「再構築」で行います。より短い間隔や任意時点の保護が必要な場合は、ユーザーデータをS3やファイルサーバへ退避する、あるいはサードパーティツールを併用します。

AWS Backupの料金はどのくらいかかりますか？

バックアップの保管量（ウォーム／コールド）、復元量、リージョン間コピーの転送量で課金され、機能自体の固定料金はありません。us-east-1ではウォーム保管がEBS/EFSで約$0.05/GB月、コールドはEBSで約$0.0125/GB月が目安です。単価はサービス・リージョンで変わるため、正確な見積もりはAWSの料金計算ツールと公式料金ページで確認してください。

AWS Backupのリストアはどうやって行いますか？

バックアップボールトから対象の復旧ポイントを選び、「復元」を実行します。復元先の設定（VPC・インスタンスタイプ・暗号化キーなど）を指定すると、多くの場合は新しいリソースとして復元されます。既存リソースへの上書きではないため、復元後のエンドポイントや名前の切り替え手順も復旧計画に含めておきます。

バックアップの間隔はどのくらい細かく設定できますか？

バックアッププランのスケジュールはcronまたはrate式で指定でき、最短1時間間隔から日次・週次・月次まで設定可能です。RDS・Aurora・S3などの継続的バックアップ対応サービスでは、スケジュール断面に加えて任意時点へ戻すポイントインタイムリカバリも利用できます。

AWS Backupのログや操作履歴はどこで確認できますか？

バックアップジョブの成否や準拠状況はAWS Backup Audit Managerのレポートで、API操作の履歴はCloudTrailで確認します。ジョブの失敗をEventBridgeで検知してSNSやメールに通知する構成にしておくと、取得漏れを早期に把握できます。誰が復旧ポイントを削除したかもCloudTrailで追跡できます。

関連記事

• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説
• RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説
• AWS Lightsailとは？EC2との違い・料金・始め方を2026年最新情報で解説
• Amazon DynamoDB Global Tablesの基本とその重要性