AWS BackupでEC2・RDS・EFSのバックアップを一元管理する方法|バックアッププランと復元テストの運用設計

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS BackupでEC2・RDS・EFSのバックアップを一元管理する方法|バックアッププランと復元テストの運用設計
「EC2スナップショット、RDSの自動バックアップ、EFSのバックアップ……サービスごとにバラバラに設定していて、どのリソースが何日分保持しているか把握しきれない」という状況、AWSを本番環境で運用しているエンジニアにはよく見られます。

バックアップが分散管理になると、監査対応や障害復旧の場面で「どのバックアップが有効なのか」をまず確認するところから始まり、RTO(Recovery Time Objective:目標復旧時間)の達成が難しくなります。

この記事では、AWS Backupを使ったバックアップの一元管理(aws backup 一元管理)の方法を解説します。バックアッププランの設計からEC2・RDS・EFSへの適用手順、復元テストの運用フロー、コスト最適化まで、本番環境で実践できる設計パターンを順を追って説明します。

この記事のポイント

・AWS Backupでバックアッププランを1箇所で管理できる
・EC2・RDS・EFSをタグで一括割り当て可能
・バックアップボールトでリカバリポイントを統合管理
・復元テストを定期実施してRPO/RTOを検証することが重要


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

AWS Backupとは何か — 複数サービスを横断する集中バックアップ管理

AWS Backupは、複数のAWSサービスのバックアップを単一の管理コンソールから一元制御できるフルマネージドサービスです。2019年の一般提供開始以降、対応サービスは継続的に拡大しており、現在は以下が主要な対象となっています。

EC2(EBSボリューム):インスタンス全体のクラッシュ整合スナップショット
RDS / Aurora:データベースインスタンスのバックアップとクラスタースナップショット
EFS(Elastic File System):NFSファイルシステムの増分バックアップ
DynamoDB:テーブルのオンデマンドバックアップ
S3:バケット内オブジェクトの連続バックアップ(2021年対応)
FSx:Windows File Server / Lustre / ONTAP / OpenZFS

AWS Backupを導入する最大のメリットは、バックアップポリシーの統一です。各サービス個別に設定していた保持期間・スケジュール・暗号化ポリシーを、「バックアッププラン」という単一の設計で横断的に管理できます。

コンプライアンス観点でも有効で、AWS Backup Auditマネージャーと組み合わせることで、バックアップの設定状況や復元テストの実施状況をレポートとして出力できます。ISO27001やSOC2の監査対応で、バックアップ証跡の提出が必要な場合に特に役立ちます。

また、AWS Organizationsと連携したクロスアカウントバックアップにも対応しており、マルチアカウント構成の本番環境でも一貫したバックアップポリシーを適用できます。

バックアッププランの設計(ルール・ボールト・IAMロール)

AWS Backupを使ったバックアップは、以下の3つの構成要素で成り立っています。

バックアップボールト(Vault):リカバリポイント(バックアップデータ)の保存先
バックアッププランとルール:いつ・どんな設定で・何日保持するかの定義
IAMロール:バックアップ操作に必要なアクセス権限

1. バックアップボールト(Vault)の作成

バックアップボールトは、リカバリポイントを保存するコンテナです。KMSキーで暗号化され、アクセスポリシーでアクセスを制限できます。本番環境では、用途別に以下の2種類を作成するのが実務でよく採られる設計です。

本番ボールト(例:production-backup-vault):本番環境のリカバリポイント
テストボールト(例:restore-test-vault):復元テスト用の一時的なリカバリポイント

# バックアップボールトの作成(東京リージョン) aws backup create-backup-vault \ --backup-vault-name production-backup-vault \ --encryption-key-arn arn:aws:kms:ap-northeast-1:123XXXXXXX78:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ --region ap-northeast-1 # 実行結果 { "BackupVaultName": "production-backup-vault", "BackupVaultArn": "arn:aws:backup:ap-northeast-1:123XXXXXXX78:backup-vault:production-backup-vault", "CreationDate": "2024-01-15T09:00:00.000Z" }

2. バックアップルールの設計

バックアッププランには、1つ以上の「バックアップルール」を定義します。ルールで指定できる主な項目は以下のとおりです。

スケジュール:cron式またはレート式(例:毎日JST午前2時 = UTC17時)
開始ウィンドウ:バックアップ開始の猶予時間(デフォルト60分)
完了ウィンドウ:バックアップ完了の期限(デフォルト180分)
保持期間:リカバリポイントを削除するまでの日数
ライフサイクル:ウォームストレージからコールドストレージへ移行するタイミング

実務では「日次(7日保持)+ 週次(35日保持)+ 月次(1年保持)」の3層ルールが一般的です。

# バックアッププランの作成(日次・週次・月次の3層ルール) aws backup create-backup-plan \ --backup-plan '{ "BackupPlanName": "3TierBackupPlan", "Rules": [ { "RuleName": "DailyBackup", "TargetBackupVaultName": "production-backup-vault", "ScheduleExpression": "cron(0 17 * * ? *)", "StartWindowMinutes": 60, "CompletionWindowMinutes": 180, "Lifecycle": { "DeleteAfterDays": 7 } }, { "RuleName": "WeeklyBackup", "TargetBackupVaultName": "production-backup-vault", "ScheduleExpression": "cron(0 17 ? * SUN *)", "StartWindowMinutes": 60, "CompletionWindowMinutes": 360, "Lifecycle": { "DeleteAfterDays": 35 } }, { "RuleName": "MonthlyBackup", "TargetBackupVaultName": "production-backup-vault", "ScheduleExpression": "cron(0 17 1 * ? *)", "StartWindowMinutes": 60, "CompletionWindowMinutes": 480, "Lifecycle": { "MoveToColdStorageAfterDays": 30, "DeleteAfterDays": 365 } } ] }'

3. IAMロールの設定

AWS Backupがリソースにアクセスしてバックアップを取るには、IAMロールが必要です。マネジメントコンソールで初回設定時に「デフォルトロールを作成」を選ぶと、以下の2つのポリシーがアタッチされたロール(AWSBackupDefaultServiceRole)が自動作成されます。

AWSBackupServiceRolePolicyForBackup:バックアップ実行権限(EC2スナップショット作成、RDSバックアップ実行等)
AWSBackupServiceRolePolicyForRestores:復元実行権限(EC2インスタンス作成、RDSインスタンス作成等)

CLIで作成する場合は以下のコマンドを使います。

# AWSBackupDefaultServiceRole の作成 aws iam create-role \ --role-name AWSBackupDefaultServiceRole \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": "backup.amazonaws.com"}, "Action": "sts:AssumeRole" } ] }' # バックアップ用ポリシーをアタッチ aws iam attach-role-policy \ --role-name AWSBackupDefaultServiceRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup # 復元用ポリシーをアタッチ aws iam attach-role-policy \ --role-name AWSBackupDefaultServiceRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores

AWSでLinuxサーバーを構築する実践的な手順については、Amazon Linuxの入門教材・学習ロードマップもあわせてご覧ください。

EC2・RDS・EFSのバックアップ設定を一元化する手順

1. タグベースのリソース割り当て設計

AWS Backupでは、バックアッププランへのリソース割り当てに「タグ」を使う方法が最も運用しやすいです。AWSリソースに共通タグを付与することで、新たなリソースが追加されても自動的にバックアップ対象に含まれるためです。

推奨タグ設計の例:

キー: Backup / 値: true:バックアップ対象とするリソース全般
キー: BackupPlan / 値: 3TierBackupPlan:適用するプランを明示
キー: Environment / 値: production:本番環境の識別

EC2・RDS・EFSにこれらのタグを付与しておけば、バックアッププランのリソース選択で「Backup=true」の条件だけで対象を網羅できます。Infrastructure as Code(Terraform等)でリソース作成時にタグをデフォルト付与する設計にしておくと、抜け漏れを防げます。

2. バックアッププランへのリソース割り当て

タグ条件でリソースを割り当てる設定をCLIで行う手順です。

# バックアッププランのIDを取得 PLAN_ID=$(aws backup list-backup-plans \ --query 'BackupPlansList[?BackupPlanName==`3TierBackupPlan`].BackupPlanId' \ --output text) # タグベースでリソースを割り当て(EC2・RDS・EFS 全て一括) aws backup create-backup-selection \ --backup-plan-id ${PLAN_ID} \ --backup-selection '{ "SelectionName": "BackupTaggedResources", "IamRoleArn": "arn:aws:iam::123XXXXXXX78:role/AWSBackupDefaultServiceRole", "ListOfTags": [ { "ConditionType": "STRINGEQUALS", "ConditionKey": "Backup", "ConditionValue": "true" } ] }' # 実行結果 { "SelectionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "BackupPlanId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy", "CreationDate": "2024-01-15T09:30:00.000Z" }

3. オンデマンドバックアップで動作確認

設定後は、即座に動作確認用のオンデマンドバックアップを実行することを推奨します。スケジュール実行を待たずに問題を早期発見できるためです。

# EC2インスタンスのオンデマンドバックアップ実行 aws backup start-backup-job \ --backup-vault-name production-backup-vault \ --resource-arn arn:aws:ec2:ap-northeast-1:123XXXXXXX78:instance/i-0abc1234def567890 \ --iam-role-arn arn:aws:iam::123XXXXXXX78:role/AWSBackupDefaultServiceRole \ --region ap-northeast-1 # バックアップジョブの状態確認 aws backup list-backup-jobs \ --by-backup-vault-name production-backup-vault \ --by-state RUNNING \ --query 'BackupJobs[*].{JobId:BackupJobId,Status:State,Resource:ResourceArn}' # ボールト内のリカバリポイント一覧確認 aws backup list-recovery-points-by-backup-vault \ --backup-vault-name production-backup-vault \ --query 'RecoveryPoints[*].{ARN:RecoveryPointArn,Status:Status,Created:CreationDate,Size:BackupSizeInBytes}' \ --output table

EFSのバックアップ対象となるファイルシステムは、EC2インスタンスにNFSマウントして使用しているケースが多いです。EFSのマウント設定全般についてはLinuxのmountコマンドとfstabの設定方法も参考にしてください。

復元テストの設計と実施(定期検証フロー)

「バックアップは取れているが、復元できるかどうかは試したことがない」という状態は、バックアップがないのと本質的に変わりません。復元テストは、バックアップ運用の中で最も重要な工程です。設定の完了直後に1度実施し、その後は定期的に繰り返すことで、いざという場面で慌てず対応できる体制を整えます。

1. EC2インスタンスの復元テスト手順

EC2の復元テストは、本番インスタンスとは別のサブネットに新しいインスタンスとして起動します。本番環境への影響がないため、定期的に実施できます。

# 最新リカバリポイントのARNを取得 RECOVERY_POINT_ARN=$(aws backup list-recovery-points-by-backup-vault \ --backup-vault-name production-backup-vault \ --by-resource-type EC2 \ --query 'RecoveryPoints | sort_by(@, &CreationDate) | [-1].RecoveryPointArn' \ --output text) # EC2インスタンスとして復元(テスト用サブネットに起動) aws backup start-restore-job \ --recovery-point-arn ${RECOVERY_POINT_ARN} \ --metadata '{ "InstanceType": "t3.medium", "SubnetId": "subnet-0test1234xxxxx", "SecurityGroupIds": "sg-0test1234xxxxx", "Iops": "0", "Encrypted": "false" }' \ --iam-role-arn arn:aws:iam::123XXXXXXX78:role/AWSBackupDefaultServiceRole \ --resource-type EC2 # 復元ジョブの完了を確認 aws backup list-restore-jobs \ --by-status COMPLETED \ --query 'RestoreJobs[*].{JobId:RestoreJobId,Status:Status,Created:CreatedResourceArn}'

2. RDS・EFSの復元テスト手順

RDSは、本番DBとは別の新しいDBインスタンスとして復元します。復元完了後に接続してデータの整合性を確認し、テスト後にインスタンスを削除するフローが基本です。

# RDSインスタンスとして復元(復元先はテスト用の別DBインスタンス) aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:ap-northeast-1:123XXXXXXX78:recovery-point:rds:prod-db-xxxxxxxx \ --metadata '{ "DBInstanceIdentifier": "restore-test-db-20240115", "DBInstanceClass": "db.t3.medium", "Engine": "mysql", "MultiAZ": "false", "StorageEncrypted": "false" }' \ --iam-role-arn arn:aws:iam::123XXXXXXX78:role/AWSBackupDefaultServiceRole \ --resource-type RDS

EFSの復元は、新しいEFSファイルシステムを作成し、そこにリカバリポイントの内容を書き込む形式で実行されます。復元完了後、EC2インスタンスに一時的にマウントしてファイルの存在と内容を確認します。確認が終わったらテスト用EFSは削除してコストが発生し続けないようにしてください。

3. 定期復元テストの運用フロー

本番環境では、月1回の定期復元テストを標準的な運用フローとして組み込むことを推奨します。以下のチェックリストを参考にしてください。

・最新リカバリポイントのARNを取得して記録する
・テスト用環境(別サブネット・別VPC等)への復元ジョブを実行する
・復元後の動作確認(EC2: SSH接続、RDS: クエリ実行、EFS: ファイル一覧確認)
・復元にかかった時間をRTO目標値と比較して評価する
・テスト用リソースを削除してコストが発生し続けないことを確認する
・テスト結果をドキュメントに記録する(AWS Backup Auditレポートで代替可能)

運用コスト・保持期間ポリシーの最適化

AWS Backupのコストは「保存したリカバリポイントのサイズ × 保持期間」で決まります。コストを抑えながら必要な保護水準を維持するには、ライフサイクル設定と保持期間の設計がポイントです。

1. ウォーム/コールドストレージのコスト比較

AWS Backup(東京リージョン ap-northeast-1)のストレージ料金は以下のとおりです(2024年時点・概算)。

対象サービス ウォームストレージ(GB/月) コールドストレージ(GB/月)
EC2(EBSスナップショット) $0.05 $0.01
EFS $0.05 $0.01
RDS $0.095 コールド非対応

コールドストレージへの移行条件は、ウォームストレージに最低90日間保持されていることです(一部サービスは制限あり)。移行後の最低保持期間は90日で、コールドストレージへ移行すると即座の復元はできなくなりますが、コストは5分の1になります。

2. 保持期間ポリシーの設計原則

実務でよく採用される保持期間ポリシーは以下のとおりです。

バックアップ種別 スケジュール ウォーム保持 コールド移行後保持
日次バックアップ 毎日 02:00 JST 7日間 コールド移行なし
週次バックアップ 毎週日曜日 02:00 JST 35日間 コールド移行なし
月次バックアップ 毎月1日 02:00 JST 30日間 コールド移行後330日間

月次バックアップのみコールドストレージへ移行することで、RTO要件を満たしながら年間のストレージコストを大幅に削減できます。ウォームとコールドのコスト差は5倍($0.05 vs $0.01)あるため、1TBのEFSを12ヶ月保持するケースでは、コールド移行により月間コストが$50から$10に下がります。

3. コスト異常検知の設定

AWS Cost Anomaly Detectionと組み合わせることで、バックアップコストの急増を自動検知できます。バックアップ対象が予期せず増えた場合(大量データのEFSが誤ってタグ付けされた等)のアラートとして有効です。Cost Explorerの「サービスごとのモニター」でAWS Backupを対象に追加するだけで設定できます。

よくあるエラーとトラブルシュート

AWS Backupを設定・運用する中で遭遇しやすいエラーと対処法をまとめます。

1. 「ResourceNotFoundException: vault not found」

バックアップジョブ実行時にバックアップボールトが見つからない場合に発生します。

原因:指定したボールト名がリージョンに存在しない、またはリージョンの指定ミス
対処aws backup list-backup-vaults --region ap-northeast-1 でボールト名を確認する

# ボールト一覧を確認(リージョンを明示する) # run with ec2-user or an IAM principal that has AWSBackupOperatorAccess $ aws backup list-backup-vaults --region ap-northeast-1 \ --query 'BackupVaultList[*].{Name:BackupVaultName,ARN:BackupVaultArn}' # 出力例 [ { "Name": "Default", "ARN": "arn:aws:backup:ap-northeast-1:123XXXXXXX78:backup-vault:Default" }, { "Name": "production-backup-vault", "ARN": "arn:aws:backup:ap-northeast-1:123XXXXXXX78:backup-vault:production-backup-vault" } ]

2. 「InvalidParameterValueException: metadata フォーマットエラー」(復元時)

EC2やRDSの復元時にメタデータJSON形式が間違っている場合に発生します。

原因--metadata に指定するキーはリソース種別によって異なる
対処:AWS CLIの aws backup get-supported-resource-types と公式ドキュメントでキー名を確認する

【注意】EC2復元時の必須キーは InstanceTypeSubnetIdSecurityGroupIds の3つです。RDSの場合は DBInstanceIdentifierDBInstanceClassEngine が必須となります。誤ったキー名を指定しても上書きエラーが起きず、ジョブが FAILED になるだけなので原因特定が遅れやすいです。

3. バックアップジョブが EXPIRED / ABORTED になる

バックアップジョブが開始ウィンドウ内に開始されなかった場合(EXPIRED)や、完了ウィンドウを超えた場合(ABORTED)に発生します。

EXPIRED の対処:StartWindowMinutes を大きくする(大規模スナップショットほど時間がかかる)
ABORTED の対処:CompletionWindowMinutes を大きくする(EFSのデータ量が増えた場合等)

【注意】RDSのバックアップはメンテナンスウィンドウと重複すると失敗することがあります。バックアッププランのスケジュールをRDSのメンテナンスウィンドウと重ならない時間帯に設定してください。

本記事のまとめ

AWS BackupによるEC2・RDS・EFSの一元管理を構成するポイントをまとめます。

やること コマンド・設定
バックアップボールト作成 aws backup create-backup-vault
バックアッププラン作成 aws backup create-backup-plan
リソース割り当て(タグベース) aws backup create-backup-selection
オンデマンドバックアップ実行 aws backup start-backup-job
リカバリポイント一覧確認 aws backup list-recovery-points-by-backup-vault
復元ジョブ実行(EC2/RDS) aws backup start-restore-job
コスト最適化 ライフサイクルでコールドストレージ移行設定

AWS Backupは設定自体はシンプルですが、「バックアッププランの設計」「復元テストの定期実施」「コストポリシーの最適化」の3点を最初から設計しておくことで、本番障害時に慌てずに対応できる基盤が整います。

AWSのインフラ設計をLinuxエンジニアとして体系的に学びたい方は、
AWSをLinuxエンジニアが学ぶためのロードマップもご覧ください。

AWSのバックアップ設計を「実務の型」として身につけませんか?

AWS Backupの設定方法は調べれば分かります。でも「なぜその保持期間を選ぶのか」「復元テストをいつ・どう実施するのか」を説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。