先に要点
- AWSのバックアップは サービスごとに方法が違います。EC2はEBSスナップショット/AMI、RDSは自動バックアップとスナップショット、S3はバージョニング、というように使い分けます。
- 稼働中DBをそのままスナップショットすると「クラッシュ整合」止まり。AWS公式は、EC2自前DBならData Lifecycle Manager+Systems Managerでフリーズ→スナップショット→解除のアプリケーション整合方式を推奨。スナップショットとDBネイティブの両方を取るのが堅実です(RDSは自動で整合性を担保)。
- これらを 横断して一元管理できるのが AWS Backup。バックアッププランで「対象・頻度・保持期間・コピー先」をまとめて自動化できます。
- 大事なのは取ることより 戻せること。復元テスト・世代管理・暗号化・別リージョンへのコピーをセットで設計します。
- やりがちな失敗は、スナップショットの取りっぱなしでコスト増、復元を一度も試していない、同一リージョンにしか置いていないの3つです。
AWSでバックアップって、結局どこで何を取ればいいの？ ── AWSはサービスごとにバックアップの仕組みが分かれているため、全体像がつかみにくいテーマです。
この記事では、AWSのバックアップ方法を、サービス別の取り方 → AWS Backupでの一元管理 → ベストプラクティス → やりがちな失敗の順で、実務目線で整理します。マネジメントコンソールの画面手順は変わりやすいので、本記事では 「何を・どの仕組みで・どう守るか」を主役にします。
AWSバックアップの考え方(まず決めること)
個別の手順に入る前に、設計の軸を押さえます。バックアップで最初に決めるのは RPOとRTOです。
- RPO(目標復旧時点) ── どこまでのデータ消失を許せるか。「最大1時間前まで戻ればOK」なら、バックアップは1時間ごとに必要。
- RTO(目標復旧時間) ── 何時間以内に復旧したいか。短いほど、すぐ起動できる形(AMIや多重化)が要る。
この2つが決まると、「どの頻度で・どこまで・どんな形で」残すかが決まります。そのうえで、バックアップは必ず自動化する(手動運用は取り忘れる)、復元を定期的に試す(戻せない事故を防ぐ)の2点を前提にします。詳しくはバックアップはあるのに戻せないを防ぐも参考になります。
サービス別のバックアップ方法
AWSの主要サービスごとに、標準的なバックアップ手段を整理します。
DynamoDB
PITR(継続バックアップ)で過去35日の任意時点へ。加えてオンデマンドバックアップで任意のスナップショット。
EFS / FSx
ファイルストレージはAWS Backupと連携してバックアップ。世代管理もまとめられる。
設定・構成そのもの
インフラ構成はIaC(CloudFormation / Terraform)でコード管理。これも広い意味での「復元可能性」。
ポイントは、データ(中身)とマシン(起動できる形)を分けて考えることです。EBSスナップショットはディスクの中身、AMIは「そこから即起動できるテンプレート」。両者の違いはAMIとスナップショットはどう違うのかで詳しく整理しています。
重要: 稼働中DBのスナップショットは「そのまま」では不十分
ここがAWSのバックアップでいちばん誤解されやすい点です。稼働中のデータベースが乗ったEBSボリュームをそのままスナップショットしても、取れるのは「クラッシュ整合(crash-consistent)」な状態です。これは「電源プラグをいきなり抜いて、後で入れ直した」のと同じ状態に相当します。多くのDBはトランザクションログから復旧できますが、メモリ上の未書き込みデータや処理中のI/Oは保証されず、復元時にデータ破損のリスクが残ります。
AWS公式が推奨するのは アプリケーション整合(application-consistent)なスナップショットです。やり方は、EC2で自分でDBを運用しているか、マネージドのRDSかで変わります。
EC2で自分でDBを運用している場合(公式の推奨方式)
AWS公式は、Amazon Data Lifecycle Manager(DLM)とAWS Systems Manager(SSM)を組み合わせ、スナップショットの前後にスクリプトを実行する方式を推奨しています。公式ドキュメントはこう説明しています ── 「スナップショット作成を開始する前に、プリスクリプトのコマンドを実行してI/Oをフリーズ・フラッシュし、開始後にポストスクリプトでI/Oを解凍する」。
- プリスクリプト ── スナップショット直前にDBの書き込みを一瞬止めてディスクへ吐き出す(MySQLなら
FLUSH TABLES WITH READ LOCKなど)。ロックはスナップショット開始までのごく短時間でよく、完了まで待つ必要はありません。 - ポストスクリプト ── スナップショット開始後にロックを解除する。
DLMは MySQL / PostgreSQL / SAP HANA / Windows(VSS) 向けのSSMドキュメントを用意しており、これに沿えば整合性のあるスナップショットを自動化できます。簡易には「DBを一時停止してからスナップショット」「メンテ時間に取得」でも整合性は確保できますが、止めたくない本番では上のフリーズ方式が定石です。
スナップショットとは別に「DBネイティブのバックアップ」も併用する(=両方やる)
ボリュームを丸ごと取るスナップショットに加えて、DB自身のバックアップ(mysqldump / pg_dump などの論理バックアップや、RDSのスナップショット)も取るのが堅い構成です。両者で守れる範囲が違うからです。
「スナップショットとDBバックアップ、両方やれ」と聞いたことがあるなら、それは正しい指摘です。速い全体復旧(スナップショット/AMI)と、テーブル単位・別環境への移行もできる論理バックアップ(DBネイティブ)は役割が違い、本番では両方を持つのが堅実です。
マネージドのRDS / Auroraの場合
RDSやAuroraなら、この心配はほぼ不要です。自動バックアップ(日次スナップショット+トランザクションログ)とPITRはAWSが整合性を保って管理してくれます。任意の時点へ復元でき(最新の復元可能時点は現在の約5分前まで)、保持期間は最大35日、デフォルトで有効です。長期保管したい節目では手動スナップショットを取ります(自分で消すまで残るのでコストと世代に注意)。つまり、整合性のためのフリーズ操作を自分で組む必要があるのは「EC2で自前DBを動かしている場合」で、RDSなら標準機能に任せられます。
AWS Backup でまとめて管理する
サービスごとに個別設定すると、設定漏れや世代管理のばらつきが起きます。これを解決するのが AWS Backupです。EC2/EBS、RDS、DynamoDB、EFSなどを 1つのバックアッププランで横断的に自動化できます。
AWS Backupの主な機能は次の通りです。
- バックアッププラン ── 「毎日2時に取得、35日保持、月次は1年保持」のようなルールを定義。
- タグでの対象選択 ──
Backup=trueのようなタグを付けたリソースを自動的に対象化。新規リソースの入れ忘れを防げる。 - クロスリージョン/クロスアカウントコピー ── 災害対策として別リージョン、別アカウントへ自動コピー。
- ボールトロック ── バックアップ(ボールト)を一定期間 削除不可にして、ランサムウェアや誤操作・内部不正からも守る。
バックアップのベストプラクティス
サービスを問わず共通で押さえたい勘どころです。
とくに 「復元テスト」は軽視されがちですが最重要です。バックアップは取れていても、いざ戻すと「権限が足りない」「手順が分からない」「想定より何時間もかかる」が当たり前に起きます。戻せて初めてバックアップです。AWSのアカウント初期設定の勘所はAWSアカウントで最初にやるべきこともあわせてどうぞ。
やりがちな失敗
① スナップショットの取りっぱなし ── ライフサイクルを設定せず溜め続け、ストレージ課金が膨らむ。② 復元未テスト ── 取得だけ確認して満足し、本番障害で初めて戻せないと気づく。③ 同一リージョンのみ ── リージョン障害やアカウント侵害で、本番もバックアップも同時に失う。
いずれも「取ること」だけに注目すると起きます。ライフサイクルで消す・別リージョンへ逃がす・定期的に戻すの3点を最初から設計に入れておくと、まとめて防げます。
AWSバックアップに関するよくある質問
Q. AWSのバックアップはどれを使えばいいですか？
A. 対象が1〜2サービスで小規模ならRDSの自動バックアップやEBSスナップショットなど標準機能で十分です。複数サービスにまたがる、世代や保持を統一したい、クロスリージョンや監査が必要、という段階になったら AWS Backupで一元管理するのが定石です。まず標準機能で始め、必要に応じてAWS Backupへ寄せると無駄がありません。
Q. スナップショットとAMIはどう使い分けますか？
A. EBSスナップショットは「ディスクの中身の保存」、AMIは「そこからEC2を即起動できるテンプレート」です。データだけ守りたいならスナップショット、OS・設定ごと丸ごと別インスタンスとして起動し直したいならAMI、と考えると整理できます。詳しくは関連記事で解説しています。
Q. RDSのバックアップは自動ですか？
A. RDSとAuroraは 自動バックアップが標準で、日次のバックアップとトランザクションログから、保持期間内の任意の時点へ戻す ポイントインタイムリカバリ(PITR) ができます。加えて、長期保管したい節目では 手動スナップショットを取ります。手動スナップショットは自分で消すまで残るので、世代管理とコストに注意します。
Q. 稼働中のデータベースをそのままスナップショットして大丈夫ですか？
A. 自分でEC2上にDBを立てている場合は注意が必要です。稼働中のままEBSスナップショットを取ると「クラッシュ整合」(電源を急に切ったのと同等)の状態になり、復元時にデータ破損のリスクが残ります。AWS公式は、Data Lifecycle Manager と Systems Manager を使い、スナップショット前にI/Oをフリーズ・フラッシュ(MySQLなら FLUSH TABLES WITH READ LOCK 等)して開始後に解除する「アプリケーション整合スナップショット」を推奨しています。DBを一時停止してから取る方法でも整合性は確保できます。RDS/Auroraの自動バックアップはAWS側が整合性を管理するため、この心配は不要です。
Q. スナップショットとDBのバックアップは両方やるべきですか？
A. 本番では両方持つのが堅実です。ボリュームスナップショットやAMIは「サーバーを丸ごと素早く復旧する」のに向き、mysqldump/pg_dumpなどの論理バックアップやRDSスナップショットは「テーブル単位の復元や別環境への移行」に向きます。守れる範囲が違うため、AWSでも両者を併用する構成が一般的です。「スナップショットとDB、両方取れ」という助言は、この役割の違いを踏まえた妥当なものです。
Q. バックアップは別リージョンに置くべきですか？
A. 重要なデータは置くべきです。同一リージョンにしか置かないと、リージョン規模の障害やアカウント侵害で本番とバックアップを同時に失います。AWS Backupのクロスリージョンコピーや、S3のレプリケーションで、別リージョン(必要なら別アカウント)へ複製しておくと、災害対策(DR)として有効です。
Q. バックアップのコストを抑えるには？
A. ライフサイクルで古い世代を自動削除し、長期保管はColdストレージなど低コスト階層へ移すのが基本です。スナップショットは増分保存ですが、取りっぱなしで世代が増えると積み上がります。保持期間をRPO/RTOから逆算して決め、不要な手動スナップショットを残さないことが効きます。
Q. ランサムウェアや誤削除からバックアップ自体を守るには？
A. AWS Backupの ボールトロックで、一定期間バックアップを削除不可にできます。あわせて、バックアップの削除権限を最小限の管理者だけに絞り、別アカウントへコピーして分離します。バックアップ自体が消されたら元も子もないため、「守る対象」としてバックアップを保護する発想が重要です。