AWS Backup入門｜EC2・RDS・EFSを一元管理するバックアップポリシーと料金ガイド

オンプレ時代は、サーバーごとにバックアップスクリプトを書き、テープやNASに取得スケジュールを個別に設定するのが当たり前でした。10台、20台とサーバーが増えると、「どのサーバーのバックアップが昨夜失敗したか」を朝イチで確認するのが日課になっていたインフラエンジニアは少なくないはずです。

AWSに移行すると今度は、EC2のEBSスナップショット・RDSの自動バックアップ・EFSのバックアップ・DynamoDBのバックアップがすべて別々の管理画面に分散します。マネジメントコンソールをあちこち開かないと全体像がつかめない、という問題は意外と見落とされがちです。

この問題を解決するのが AWS Backup です。この記事では、AWS Backupの仕組みからコンソール操作・料金体系・実務Tipsまで、オンプレ経験者がすぐに現場で使えるレベルで解説します。

なぜAWS Backupなのか？（オンプレとの違い・背景）

オンプレ環境では、バックアップ管理ソフト（Veeam、Symantec Backup Exec等）が全サーバーを一元管理していました。AWSに移行すると、各サービスが独自のバックアップ機能を持つため、最初は「それぞれ自動でやってくれる」と便利に感じます。しかし現場では次のような問題が起きます。

・EC2（EBSスナップショット）→ EC2コンソールのスナップショット画面
・RDS → RDSコンソールの自動バックアップ・スナップショット画面
・EFS → EFSコンソールのバックアップ設定
・DynamoDB → DynamoDBコンソールのバックアップ画面

リソースが増えると、保持期間設定のバラつき・設定漏れ・監査対応の手間が積み重なります。コンプライアンス監査で「全データベースのバックアップ保持を90日以上証明してください」と言われたとき、各画面を個別に調べる作業は非常に非効率です。

AWS Backupが解決するもの：

・バックアップスケジュールと保持期間を一元ポリシーで管理
・タグベースでリソースを自動的にバックアップ対象に追加
・クロスアカウント・クロスリージョンバックアップ
・コンプライアンスレポートの自動生成

2026年7月時点の対応リソース：Amazon EC2、Amazon EBS、Amazon RDS（Aurora含む）、Amazon EFS、Amazon DynamoDB、Amazon S3、Amazon FSx（Windows File Server / Lustre / ONTAP）、AWS Storage Gateway、Amazon DocumentDB、Amazon Neptune、Amazon Redshift、Amazon Timestream

バックアップ・スナップショット・レプリケーションの違いについては、こちらの記事でも詳しく整理しています。

AWS Backupの3つの主要コンポーネント

AWS Backupを使いこなすには、以下の3つの概念を押さえておく必要があります。

1. バックアップボールト（Backup Vault）

バックアップデータの「保管庫」です。AWS Managed Key（aws/backup）または自分で作成したKMSキーで暗号化されます。

特筆すべきはボールトロック機能です。コンプライアンス要件（SOC2、PCI DSS等）やランサムウェア対策として、「指定期間中はバックアップを誰も削除できない」WORM（Write Once Read Many）設定が可能です。管理者権限を持つIAMユーザーでも削除できなくなるため、バックアップの改ざん防止に有効です。

本番環境では Default ボールトをそのまま使わず、prod-backup-vault のように環境別にボールトを分けるのが現場での定石です。

2. バックアップ計画（Backup Plan）

「いつ・どのくらいの頻度で・何日間保持するか」を定義するルールのセットです。1つのプランに複数のルールを持たせられます。

例：

・毎日午前2時にバックアップ → 7日間ウォームストレージで保持
・毎週日曜日 → 4週間保持
・毎月1日 → 1年間保持（取得後30日でコールドストレージに自動移行）

オンプレのフルバックアップ＋差分バックアップとは異なり、AWS Backupではサービスごとにスナップショット形式で取得されます。

3. バックアップ割り当て（Resource Assignment）

バックアップ計画に対して「何をバックアップするか」を指定します。リソースARN直接指定でも、タグベースの割り当てでも可能です。

タグベースが特に強力で、Backup: daily-7d タグを付けたリソースが自動的にプランに組み込まれます。TerraformやCloudFormationでリソースを作成するときにタグを必須化しておくと、バックアップ対象の設定漏れがなくなります。

基本的な使い方（コンソール操作）

1. バックアップボールトを作成する

AWS Management Console →「Backup」→「バックアップボールト」→「ボールトを作成」

主な設定項目：

・ボールト名：例: prod-backup-vault
・暗号化キー：AWS Managed Key（aws/backup）または KMSカスタムキー
・ボールトロック：任意（WORM要件がある場合は有効化）

2. バックアップ計画を作成する

「バックアップ計画」→「バックアップ計画を作成」→「新しい計画を作成」

バックアップルールの主な設定項目：

・ルール名：例: daily-backup
・バックアップボールト：先ほど作成したボールト
・バックアップ頻度：毎日
・バックアップ時間帯：00:00～02:00 UTC（日本時間 09:00～11:00）
・保持期間：7日間
・コールドストレージへの移行：長期保存が不要な場合は「なし」

# AWS CLI でバックアップ計画の一覧を確認する
aws backup list-backup-plans   --region ap-northeast-1

# バックアップジョブの実行状況を確認する
aws backup list-backup-jobs   --by-state RUNNING   --region ap-northeast-1

# バックアップボールトの一覧を確認する
aws backup list-backup-vaults   --region ap-northeast-1

3. リソースを割り当てる

計画の詳細ページ →「リソース割り当てを追加」

タグベース割り当ての設定例：

・割り当て名：prod-tagged-resources
・IAMロール：AWSBackupDefaultServiceRole（初回コンソール利用時に自動作成）
・リソースの選択：タグ → キー Environment / 値 production

これで Environment: production タグを持つEC2・RDS・EFS等が自動的にバックアップ対象になります。新しいリソースにタグを付けるだけで、手動設定なしにバックアップが開始されます。

料金の仕組み（コスト感覚）

AWS Backupの料金は、バックアップの「保存形式」によって大きく異なります（2026年7月時点・東京リージョン ap-northeast-1）。

コスト試算例（500GBのRDS・毎日バックアップ・7日保持）：

日次バックアップで平均保持量は約 500GB × 3.5 = 1,750GB となります。
1,750GB × $0.05 = 月額 約$87.5（2026年7月時点のレート換算で約13,000円程度）

コールドストレージ活用例（取得後30日でコールドに移行）：

・ウォームストレージ（直近30日分）: 500GB × 30日分 相当 × $0.05
・コールドストレージ（31日目以降）: 残りの保持分 × $0.01

月次バックアップを1年間コールドストレージで保持する場合は、ウォームに比べてストレージコストを最大80%削減できます。

応用・実務Tips

【重要】クロスリージョンバックアップでDR構成を強化する

バックアップルールに「クロスリージョンコピー」を追加すると、東京リージョン（ap-northeast-1）のバックアップを大阪リージョン（ap-northeast-3）に自動コピーできます。

AWSのDR設計において、バックアップのクロスリージョンコピーはPilot Light・Backup and Restore構成の基本です。RPO（目標復旧時点）を短くしたい場合は、コピー頻度を上げるか、クロスリージョンレプリケーションを組み合わせることを検討してください。

タグ戦略との組み合わせ

BackupPlan: daily-7d、BackupPlan: weekly-28d、BackupPlan: monthly-365d のようなタグ体系を設計しておくと、リソース追加時にタグを貼るだけで自動的に適切なプランに組み込まれます。Terraformの default_tags でデフォルトタグを設定しておくと、新規リソースへのバックアップタグ付け漏れを防げます。

AWS Organizationsとの連携でマルチアカウント管理

AWS Organizationsのバックアップポリシーを使うと、管理アカウントから全メンバーアカウントにバックアップ計画を展開できます。「全本番アカウントのRDSは最低7日保持」という組織ポリシーを一元管理でき、ガバナンス統制として機能します。

EFSバックアップはコールドストレージ移行を積極的に使う

Amazon EFSはファイルシステム全体を最初にフルバックアップし、以降は増分で取得します。ただし、タイムスタンプ更新などメタデータ変更も差分扱いになるため、データ変更が少なくてもバックアップサイズが予想より大きくなることがあります。Amazon EFSの料金体系と合わせて確認し、取得後30日でコールドに移行するルール設定を検討してください。

よくあるトラブルと対処法

「AWSBackupDefaultServiceRoleが存在しない」エラー

AWS Backupを初めて使うアカウントでは、サービスロールが未作成の場合があります。コンソールから「AWS Backup」→「設定」→「バックアップ設定の更新」を実行すると、サービスリンクロールとデフォルトIAMロールが自動作成されます。

# IAMロールの存在確認
aws iam get-role   --role-name AWSBackupDefaultServiceRole

# ロールが存在しない場合はコンソールから自動作成する
# AWS Backup → 設定 → バックアップ設定の更新 を実行

「RDSのバックアップジョブが失敗する」

RDSのメンテナンスウィンドウとAWS Backupのバックアップ時間帯が重なるとジョブが失敗することがあります。バックアップ時間帯をRDSの自動バックアップウィンドウ・メンテナンスウィンドウとずらして設定してください。

また、RDSの自動バックアップ保持期間が「0日」（無効化）に設定されている場合、AWS BackupはRDSをバックアップできません。RDS側で保持期間を1日以上に設定する必要があります。

「バックアップはあるのにリストアに時間がかかる」

ウォームストレージのバックアップは即時リストア可能ですが、コールドストレージに移行したバックアップは取り出し処理に数時間かかることがあります。RTO（目標復旧時間）が短いシステムでは、直近のバックアップをウォームストレージに保持する期間を十分に確保してください。

本記事のまとめ

AWS Backupは、バラバラだったAWSサービスのバックアップを一元管理するマネージドサービスです。

オンプレ時代の「バックアップ管理台帳」に相当する管理基盤をクラウドでも確立できるのが、AWS Backupの強みです。まずはデフォルトボールトと日次バックアップ計画から始めて、タグ戦略と組み合わせた自動化を段階的に進めてみてください。

Linuxサーバーのバックアップ設計については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。