AWS Backupとは？対応サービス・東京の料金とバックアッププラン作成・復元手順【2026年10月】

AWS Backupは、EC2・EBS・RDS・Aurora・DynamoDB・EFS・S3などのバックアップを、1つのバックアッププランで自動取得し、バックアップボールトにまとめて保管するマネージドサービスです。Amazon WorkSpacesのバックアップ方法を探している場合は注意が必要で、WorkSpacesはAWS Backupの対象に入っていません。WorkSpacesは12時間ごとの自動スナップショットで保護され、戻し方も別です。本記事では2026年10月28日時点の公式ドキュメントと料金データをもとに、対応サービスごとの機能差、東京リージョンの単価、CLIでのプラン作成と復元の手順、WorkSpacesの扱いを順に説明します。

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

• バックアッププラン（頻度・保持期間）、バックアップボールト（保管先）、リソースの割り当て（タグ指定）の3つを作れば、定期バックアップが始まります。スケジュールの最短は1時間ごとです。
• 対応サービスは20種類以上ありますが、継続的バックアップ（PITR）・コールドストレージ・復元テストに対応するリソースはそれぞれ異なります。
• 東京リージョンの保管単価は、EBSスナップショットが0.05ドル/GB-月、EFSとS3のウォームが0.06ドル/GB-月、DynamoDBのウォームが0.114ドル/GB-月です。コールドに移すと最低90日分の料金がかかります。
• Amazon WorkSpacesは対象外です。WorkSpaces Personalは12時間ごとの自動スナップショットで「復元」か「再構築」を選んで戻し、Poolsはホームフォルダーを利用者のS3バケットに保存します。
• 本番のアカウント管理者がバックアップを消せる構成のままでは、ランサムウェア対策になりません。猶予期間終了後のコンプライアンスモードのVault Lock、または論理エアギャップボールトへのコピーを組み合わせます。

AWS Backupの仕組み：プラン・ボールト・リソース割り当て

AWS Backupが解決するのは、バックアップ設定がサービスごとに分かれてしまう問題です。EC2はAMIやEBSスナップショット、RDSは自動バックアップ、DynamoDBはオンデマンドバックアップと、標準機能のままでは管理画面も保持ルールも別々になります。AWS Backupはこれらを共通のルールで取得し、取得結果（復旧ポイント）を1か所で一覧・監査できるようにします。

バックアッププラン・ボールト・割り当ての役割

バックアッププランは「いつ取るか・何日残すか・どこへコピーするか」を書いたルールの集まりです。公式のプラン設定の説明では、頻度は1時間ごと・12時間ごと・日次・週次・月次から選ぶか、cron式で指定します。スナップショットの保持は1日から100年まで（または無期限）、継続的バックアップの保持は1日から35日までです。

バックアップボールトは復旧ポイントの保管先で、暗号化に使うKMSキーとアクセスポリシーをボールト単位で持ちます。リソースの割り当ては、どのリソースをそのプランで守るかの指定です。ARNを1件ずつ並べる方法と、「backup=daily」のようなタグで選ぶ方法があり、タグで選べば後から作ったEC2やRDSも自動で対象に入ります。

サービス標準のバックアップ（DLM・RDS自動バックアップ）との違い

Amazon Data Lifecycle Manager（DLM）はEBSスナップショットとEBS-backed AMIの世代管理に特化した機能で、RDSやDynamoDBは扱いません。RDSの自動バックアップもRDSの中だけで完結します。AWS Backupは複数サービスを同じプランで扱い、クロスアカウント管理・監査レポート・Vault Lockまで含めて管理できる点が違います。

注意したいのは、AWS Backupが自分以外で取ったバックアップを管理しない点です。公式の概要ページには、AWS Backupの外で取ったバックアップは統制の対象外と書かれています。さらに、RDSの継続的バックアップのように標準機能と同じ基盤を使うサービスと、DynamoDBのように別のバックアップ層として動くサービスがあります。DLMやDynamoDBのオンデマンドバックアップを残したままAWS Backupを足すと、同じデータを二重に保管して料金も二重になるため、移行時はどちらか一方に寄せます。

AWS Backupの対応サービスと機能の違い（2026年10月時点）

リソース別の機能可用性表には、EC2・S3・EBS・RDS（DBインスタンスとMulti-AZ DBクラスター）・Aurora・Aurora DSQL・EFS・FSx 4種・Storage Gateway（ボリュームゲートウェイ）・DocumentDB・Neptune・Redshift Serverless・Timestream・Windows VSS・仮想マシン（VMware等）・CloudFormation・DynamoDB・EC2上のSAP HANA・EKSが載っています。主なリソースの機能差は次のとおりです。

DynamoDBは「AWS Backupの高度な機能」をオプトインするかどうかで別物になります。オプトインしないと、コールド移行もリージョン間・アカウント間のコピーも使えません。DynamoDBのバックアップをAWS Backupに移すなら、最初にアカウントの設定画面で高度な機能を有効にしてからプランを作ります。

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

継続的バックアップはS3・RDS・Aurora・EC2上のSAP HANAに対応し、過去35日以内の任意の時刻へ1秒単位で戻せます。誤ったUPDATE文を流した直前に戻したいデータベースはPITR、月末時点を1年残したいといった長期保管はスナップショット、と役割を分けます。PITRは保持が最長35日なので、90日の最低保管期間があるコールドへは移せません。

RDSで初めてPITRを有効にする場合、設定変更は次のメンテナンスウィンドウで適用され、それまではAWS Backupがスナップショットで穴を埋めます（2026年2月26日のドキュメント更新）。プランを作った当日からPITRで戻せるとは限らない点を、切り替え計画に入れておきます。

対象外のサービスと別の手段が要るケース

機能可用性表に無いサービスは、AWS Backupでは守れません。代表例が後述のAmazon WorkSpacesで、ElastiCache・OpenSearch Service・Lambdaも表に載っていません。これらは各サービスの標準機能（スナップショットや設定のコード化）で守ります。EC2の中で動くMySQLのように、インスタンス丸ごとのバックアップでは整合性が取れないデータは、アプリケーション側のダンプやWindows VSSを併用します。PostgreSQLの例はPostgreSQLのバックアップ設計｜pg_dumpとPITRの使い分け・復旧検証の手順で扱っています。

Amazon WorkSpacesのバックアップ方式と自動スナップショットの範囲

AWS Backupの対応リソースの一覧にも機能可用性表にも、WorkSpacesは載っていません。WorkSpacesのデータは、WorkSpaces自身が取る自動スナップショットで守られます。仮想デスクトップとしての構成や料金はAmazon WorkSpacesとは｜AWSの仮想デスクトップ(DaaS)の仕組み・料金で解説しているので、ここではバックアップと復旧に絞ります。

WorkSpaces Personalの自動スナップショット（12時間ごと）

WorkSpacesの管理ガイドによると、自動スナップショットは12時間ごとに予定されています。WorkSpaceが正常ならルートボリューム（WindowsのC:、Linuxの/）とユーザーボリューム（D:、/home）の両方、異常な状態ならユーザーボリュームだけが取得されます。作成直後の初回スナップショットは通常30分以内ですが、リージョンによっては数時間かかり、その前に異常になると復元できません。

管理ガイドの復元・再構築の手順は、この自動スナップショットを使う前提で書かれています。どの時点のスナップショットがあるかは、CLIの describe-workspace-snapshots で確認できます。

aws workspaces describe-workspace-snapshots --workspace-id ws-0123456789

復元と再構築で戻る範囲の違い

障害時の操作は「復元（Restore）」と「再構築（Rebuild）」の2つです。どちらも現在のユーザーボリュームの中身は上書きされるので、実行前に退避が必要なファイルが無いかを利用者に確認します。

復元は、スナップショット以降に入れたアプリや変更した設定が消えます。再構築は、作成後に入れたアプリがすべて消えるうえ、ネットワークインターフェースも作り直されるため、プライベートIPアドレスとホスト名が変わります。Active Directoryに参加しているWorkSpaceは新しいコンピューターオブジェクトになるので、IPやホスト名で許可しているファイアウォールやライセンスサーバーがあれば、再構築の後に設定を直す必要があります。OSが壊れただけなら復元、ルートのスナップショットが無いときは再構築、と順に試すのが基本です。

WorkSpaces PoolsのホームフォルダーとS3保管

非永続型のWorkSpaces Poolsは、サインインのたびに新しいデスクトップへ接続するため、Personalのような復元・再構築はありません。ホームフォルダーを有効にすると、そのデータは利用者のアカウント内のS3バケットへ自動で保存されます。S3はAWS Backupの対象なので、そのバケットでS3バージョニングを有効にし、S3用のバックアップ・復元権限を設定してAWS Backupのプランに割り当てれば、ホームフォルダーをバックアップできます。なおWorkSpaces Poolsは2026年7月31日に新規顧客の受付を停止しており、既存顧客も2027年12月31日で使えなくなります。

12時間より細かく守りたいユーザーデータの置き場

自動スナップショットは12時間ごとに予定されますが、取得完了や正常性を保証する間隔ではありません。失われる作業の範囲は最後に利用可能なスナップショットの時刻で決まり、約12時間を超える場合もあります。業務ファイルを12時間より短い間隔で戻せるようにしたいなら、ファイルをWorkSpaceの中に置かず、FSx for Windows File ServerやS3など、AWS Backupの対象になる共有ストレージに保存させる運用に寄せます。FSxとS3はAWS Backupで1時間ごとのスケジュールを組めるため、WorkSpaceが壊れても再構築後に共有ストレージから戻すだけで済みます。

AWS Backupの料金：東京リージョンの単価と見積もり

AWS Backupには最低料金や初期費用はなく、保管量（GB-月）、復元量（GB）、リージョン間コピーの転送量（GB）で課金されます。東京リージョン（ap-northeast-1）の主な単価は次のとおりです。EFS・DynamoDB・S3はAWS Price List APIの2026年10月14日公開データ、EBSとRDSはAWS Backupの料金ページが参照する各サービスのスナップショット単価から取りました。

EBSのコールドはEBSスナップショットアーカイブ層への移行で、復元時に0.03ドル/GBの取り出し料金がかかります。RDSのスナップショット料金とDBインスタンスの無料分の関係はAWS RDSの料金を東京リージョンの実額で計算する：延長サポート課金と単価の下げ方で詳しく計算しています。単価は改定されるため、契約前には料金ページで最新値を確かめてください。

コールドストレージに移せる条件（最低90日）

コールドに移せるのは、EBS・EFS・DynamoDB（高度な機能あり）・Timestream・EC2上のSAP HANA・VMwareなどのバックアップです。機能可用性表ではAurora DSQLとCloudFormationもコールド移行の対応対象で、CloudFormation内のリソースには各リソース固有の制約が適用されます。ライフサイクルAPIの仕様では、削除までの日数をコールド移行の日数より90日以上長くする必要があり、早く消しても90日分の料金（早期削除料金）がかかります。公式は、移行を少なくとも8日目以降にするよう推奨しています。フルバックアップを早く移すと、AWS Backupがウォームに別のフルバックアップを取り直すためです。

判断の目安は保持期間です。保持が90日に届かないプランでは、コールドを使っても安くなりません。EBSのコールドは月次以下の頻度のプランにしか使えないため、日次バックアップを35日残す構成ならウォームのまま運用します。

リージョン間コピーの転送料と見積もりの手順

東京から大阪リージョンへコピーする場合、転送料はEBS・S3・Auroraが0.09ドル/GB、EFS・DynamoDBが0.11ドル/GBです。これに加えて、大阪側のボールトで保管料金が別にかかります。たとえばEFSの復旧ポイントが東京で合計1,000GB-月あれば、保管料は1,000×0.06＝60ドルで、毎月500GB分を大阪へコピーすると転送料が500×0.11＝55ドル、大阪側の保管料が別途加わります。増分バックアップでは2回目以降に増えるのは変更分だけなので、定常時の保管容量は「フル容量＋日次の変更量×保持日数」を概算の出発点にし、月中の保管期間でGB-月に換算して単価を掛けます。DynamoDBなどのフルバックアップにはこの増分計算を使わず、保持する各バックアップの課金容量を合算します。

CLIでバックアッププランを作成する手順

コンソールでも同じことができますが、本番と検証で同じ設定を再現するにはCLIかIaCで持つ方が確実です。以下は backup=daily タグの付いた対象リソースを、毎日午前3時（日本時間）から60分以内にバックアップ開始し、35日保持して大阪リージョンにもコピーする例です。EBSだけを対象にする場合は、このタグを対象のEBSボリュームだけに付けます。コマンドと入力JSONは、AWS CLI 1.46.2（botocore 1.43.62）のローカル引数検証を通ることを確認しています。AWS上でのバックアップ・復元成功やIAM・KMS権限の検証は含みません。アカウントIDとARNは自分の環境に置き換えてください。以下はBashなどのシェルで実行し、事前に export AWS_DEFAULT_REGION=ap-northeast-1 を設定します。BackupPlanIdとRestoreJobIdは、山括弧ごと実際の応答値に置き換えてください。

バックアップボールトとプランの作成

先に東京に保管先の prod-vault を作り、コピー先として大阪に dr-vault を作っておきます。スケジュールのcron式は既定でUTCとして解釈されるため、ScheduleExpressionTimezone に Asia/Tokyo を指定して日本時間で書きます。

aws backup create-backup-vault --backup-vault-name prod-vault --region ap-northeast-1
aws backup create-backup-vault --backup-vault-name dr-vault --region ap-northeast-3

cat > plan.json <<'EOF'
{
  "BackupPlanName": "prod-daily",
  "Rules": [
    {
      "RuleName": "daily-0300-jst",
      "TargetBackupVaultName": "prod-vault",
      "ScheduleExpression": "cron(0 3 * * ? *)",
      "ScheduleExpressionTimezone": "Asia/Tokyo",
      "StartWindowMinutes": 60,
      "CompletionWindowMinutes": 480,
      "Lifecycle": { "DeleteAfterDays": 35 },
      "CopyActions": [
        {
          "DestinationBackupVaultArn": "arn:aws:backup:ap-northeast-3:111122223333:backup-vault:dr-vault",
          "Lifecycle": { "DeleteAfterDays": 35 }
        }
      ]
    }
  ]
}
EOF
aws backup create-backup-plan --backup-plan file://plan.json

StartWindowMinutes は「この時間内に開始できなければ失敗にする」幅、CompletionWindowMinutes は完了までの上限です。Aurora以外のデータベースはメンテナンスウィンドウの1時間前からウィンドウ中までバックアップを開始できないので、RDSのメンテナンスウィンドウと重ならない時刻を選びます。

バックアップ対象リソースのタグ指定

create-backup-plan の応答に含まれる BackupPlanId を使い、タグ「backup=daily」が付いたリソースを対象にします。IAMロールは、コンソールで初めてバックアップを設定したときに作られる AWSBackupDefaultServiceRole を使う例です。

cat > selection.json <<'EOF'
{
  "SelectionName": "tag-backup-daily",
  "IamRoleArn": "arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole",
  "ListOfTags": [
    { "ConditionType": "STRINGEQUALS", "ConditionKey": "backup", "ConditionValue": "daily" }
  ]
}
EOF
aws backup create-backup-selection --backup-plan-id <BackupPlanId> --backup-selection file://selection.json

オンデマンドバックアップの取得とジョブ確認

プランの初回を待たずに動作を確かめるなら、start-backup-job で1回だけ取得します。失敗したジョブは list-backup-jobs で状態を絞って一覧できます。

aws backup start-backup-job --backup-vault-name prod-vault \
  --resource-arn arn:aws:ec2:ap-northeast-1:111122223333:volume/vol-0123456789abcdef0 \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole \
  --lifecycle DeleteAfterDays=7

aws backup list-backup-jobs --by-state FAILED --by-created-after 2026-10-01T00:00:00Z

EC2インスタンス単位でバックアップすると、AWS BackupはAMIを作ります。AMIとスナップショットの関係や不要になったAMIの削除手順はAWS AMIとは？スナップショットとの違い・種類・料金と作成から削除までの手順【2026年10月】を参照してください。

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

EBS・EC2・RDS・DynamoDBの復元は「新しいリソースを作る」操作で、元のリソースは上書きされません。EBSなら新しいボリューム、RDSなら新しいDBインスタンスができるので、復元後にアプリケーションの接続先を切り替えるか、データだけを元のリソースへ移します。EFSは元のファイルシステムにも戻せますが、その場合もルート直下に aws-backup-restore_日時 というディレクトリが作られ、その中に復元されます。

復旧ポイントの選択とstart-restore-jobによる復元

手順は「復旧ポイントを探す→元の設定（メタデータ）を取り出す→必要な項目を書き換えて復元ジョブを出す」の3段です。get-recovery-point-restore-metadata で取り出した設定を土台にすれば、容量や暗号化などは元のボリュームと同じ設定で作られます。

aws backup list-recovery-points-by-backup-vault --backup-vault-name prod-vault \
  --by-resource-arn arn:aws:ec2:ap-northeast-1:111122223333:volume/vol-0123456789abcdef0

# 元の設定（RestoreMetadata）を取り出し、変えたい項目（ここではAZ）だけ上書きして保存する（jqを使用）
aws backup get-recovery-point-restore-metadata --backup-vault-name prod-vault \
  --recovery-point-arn arn:aws:ec2:ap-northeast-1::snapshot/snap-0123456789abcdef0 \
  --query RestoreMetadata --output json \
  | jq '. + {"availabilityZone":"ap-northeast-1a"}' > meta.json

aws backup start-restore-job \
  --recovery-point-arn arn:aws:ec2:ap-northeast-1::snapshot/snap-0123456789abcdef0 \
  --iam-role-arn arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole \
  --resource-type EBS --metadata file://meta.json

aws backup describe-restore-job --restore-job-id <RestoreJobId>

RDSやAuroraをPITRで戻すときも同じ start-restore-job を使い、RDS DBインスタンスでは新しいDBインスタンス識別子、Auroraでは新しいDBクラスター識別子とエンジンなど、リソースごとの必須メタデータと復元時刻を指定します。Auroraでは復元後にDBインスタンスを作成してクラスターに接続する手順も必要です。EBSスナップショットの復元料金は無料ですが、EFSやDynamoDBは復元したGB数に料金がかかるので、大きなファイルシステムは必要なファイルだけを戻す項目単位の復元も検討します。東京リージョンではEFSの項目単位の復元に、復元したGB数の料金とは別に1ジョブ0.60ドルがかかります。

月次の復元テストによる復旧可否と所要時間の確認

バックアップが取れていても、戻せるかは別の問題です。復元テストは、決めた頻度で復旧ポイントを選んで実際に復元し、検証が終わると復元したリソースを自動で削除する機能です。検証用に残す時間は1〜168時間で指定でき、Audit Managerと組み合わせると復元にかかった時間が目標内かも判定できます。東京リージョンの料金は、復元テストした復旧ポイント1件あたり1.80ドルと、復元したデータ量分の復元料金です。RDSとEFSを月1回ずつテストする場合も、評価料金に加えて復元データ量と復元先リソースの稼働・保管料金を見積もります。件数が少なくても、データ容量や検証用に残す時間によっては月十数ドルを超えることがあります。

監査ログとランサムウェア対策

バックアップ運用で監査から聞かれるのは「決めたとおりに取れているか」と「消されない状態か」の2点です。前者はAudit ManagerとCloudTrail、後者はVault Lockと論理エアギャップボールトで答えます。

Audit ManagerとCloudTrailで見る範囲

AWS Backup Audit Managerは、「全リソースがプランで保護されているか」「保持期間が下限以上か」といったコントロールで準拠状況を評価し、24時間ごとにレポートを作ってS3に出力します。一方、誰がいつ復旧ポイントを削除したか、プランを変更したかといった操作の記録はCloudTrailに残ります。監査対応ではAudit Managerのレポートを証跡として出し、事故調査ではCloudTrailのDeleteRecoveryPointやUpdateBackupPlanのイベントを追う、という使い分けです。

Vault Lockと論理エアギャップボールトによる削除防止

Vault Lockにはガバナンスモードとコンプライアンスモードがあり、コンプライアンスモードは最低3日（72時間）の猶予期間が過ぎると、復旧ポイントが残っている限り利用者もAWSもボールトとロックを変更・削除できません。論理エアギャップボールトはコンプライアンスモードのロックを最初から備えたボールトで、2026年3月にはEKSクラスター、2026年9月にはFSx for ONTAPのコピーにも対応しました（ドキュメント更新履歴）。日次バックアップを通常のボールトに取り、そのコピーを論理エアギャップボールトへ送る構成のTerraform例や保持日数の決め方は、イミュータブルバックアップとは：S3 Object Lock・Vault Lockの実装手順と保持期間の決め方で扱っています。S3側でオブジェクト単位に削除を止める方法はS3オブジェクトロックとは｜2モードの違いとイベントホールドの設定手順をCLIで解説を参照してください。

AWS Backupを使うべき場面と使わなくてよい場面

本記事でAWS Backupを勧めるのは、EC2・RDS・EFSなど複数サービスの保持期間やコピー先を共通管理したい場合と、監査で「全リソースが保護されている」ことを示す必要がある場合です。複数アカウントをAWS Organizationsで管理していれば、管理アカウントからバックアップポリシーを配布でき、アカウントごとの設定漏れを防げます。東京と大阪の両リージョンにまたがる災害対策の構成全体はAWSのBCP対策｜障害の単位で選ぶ構成と東京・大阪リージョンの切り替え設計【2026年10月時点】で整理しています。

逆に、EBSスナップショットだけを数世代残せばよい小さな構成ならDLMで足り、DynamoDBを35日以内の時点に戻せれば十分ならDynamoDB自身のPITRで済みます。フル・差分・増分の違いや世代数の考え方から整理したい場合はシステムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説が前提知識になります。

バックアップの要件定義から、プランのIaC化、復元テストの設計までをまとめて任せたい場合は、AWS・Google Cloud・Azureのインフラ構築支援で相談を受け付けています。

よくある質問

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

できません。WorkSpacesはAWS Backupの対応リソースに含まれていません。WorkSpaces Personalは12時間ごとの自動スナップショットで守られ、障害時は復元（ルートとユーザーの両ボリュームを戻す）か再構築（ユーザーボリュームだけを戻す）を選びます。12時間より細かく戻したいファイルは、FSxやS3などAWS Backupの対象になる共有ストレージに置きます。

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

保管量・復元量・リージョン間転送量に応じた従量課金で、最低料金はありません。東京リージョンではEBSスナップショットが0.05ドル/GB-月、EFSとS3のウォームが0.06ドル/GB-月、DynamoDBのウォームが0.114ドル/GB-月です。コールドに移すと単価は下がりますが、最低90日分の料金がかかります。

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

コンソールのバックアップボールトから復旧ポイントを選んで「復元」を押すか、CLIで get-recovery-point-restore-metadata の結果を使って start-restore-job を実行します。EBSやRDSの復元は新しいリソースを作る操作なので元のリソースは上書きされず、復元後に接続先を切り替えます。

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

スケジュールによるバックアップは最短1時間ごとです。S3・RDS・Aurora・EC2上のSAP HANAは継続的バックアップを有効にすると、過去35日以内の任意の時刻へ1秒単位で戻せます。

AWS BackupとDLM（Data Lifecycle Manager）の違いは何ですか？

DLMはEBSスナップショットとAMIの世代管理に限られ、RDSやDynamoDBは扱いません。AWS Backupは複数サービスを同じプランで管理し、監査レポート・クロスアカウントコピー・Vault Lockまで使えます。EBSだけの小さな構成ならDLMで足ります。

関連記事

• イミュータブルバックアップとは：S3 Object Lock・Vault Lockの実装手順と保持期間の決め方
• Amazon WorkSpacesとは｜AWSの仮想デスクトップ(DaaS)の仕組み・料金
• AWS AMIとは？スナップショットとの違い・種類・料金と作成から削除までの手順【2026年10月】
• AWSのBCP対策｜障害の単位で選ぶ構成と東京・大阪リージョンの切り替え設計【2026年10月時点】
• システムバックアップとは？フル・差分・増分の違いと取得手順・方式の選び方を解説