RDSには自動バックアップがある。EBSにはスナップショットがある。ではLambdaは？SQSは？Route 53は？——コンソールを探し回った経験のある人へ。答えは「無い」ではなく「そこじゃない」です。バックアップの全体地図と、スナップショットが本番負荷ほぼゼロで済む仕組みを解説します。
AWSのバックアップで初学者がつまずくのは、個々の機能の使い方ではありません。「何が・どこで・どう守られているのか」の地図を持っていないことです。本記事では、まずデータと構成の2分類という地図の描き方を示し、AMI・スナップショット・バックアップ・レプリカという紛らわしい言葉を交通整理します。その上で「バックアップを取ると本番が重くなるのでは？」という素朴で正しい疑問にスナップショットの内部の仕組みから答え、サービス別の早見表と、現場で実際に事故になる落とし穴を整理します。AWS Backupの運用設計(プラン・世代・Vault Lock・復旧テスト)はAWS Backupで統合バックアップを、スナップショットを分析に活用する話はRDSスナップショットのS3エクスポートをあわせてどうぞ。
01地図の描き方 — 「データ」と「構成」を分けると全部解ける
AWSのリソースが持っているものは、2種類に分けられます。
- データ：そのリソースの中にしか存在しない状態。RDSの中身、S3のオブジェクト、EBSのブロック、DynamoDBのアイテム。失うと二度と作り直せません。これがバックアップの対象です。
- 構成：リソースの「作り方の記述」。Lambdaのコード、IAMポリシー、API Gatewayの定義、セキュリティグループのルール。これらの正しい置き場はAWSの中ではなくGitです。バックアップに相当するのはリポジトリとIaC(CloudFormation/Terraform)、そしてデプロイ成果物(S3のzip、ECRのイメージ)です。
冒頭の問いに答えます。AWS Backupの対応リソース一覧にLambdaはありません。EC2・EBS・S3・RDS・Aurora・DynamoDB・EFS・FSxなど、対応しているのは軒並み「データを抱えるサービス」です。Lambdaが無いのは欠陥ではなく、この分類の帰結です。関数のコードはGitに、ビルド成果物はS3やECRに、関数定義(メモリ・環境変数・トリガー)はIaCにある——つまりLambdaのバックアップはデプロイパイプラインそのものです。
紛らわしいのがLambdaの「バージョン」機能です。発行したバージョンは不変で、世代管理のように見えます。しかし関数を削除すればバージョンも道連れで消えます。誤削除から守ってくれないものはバックアップとは呼べません。同じ理屈で、「コンソールで直接変更した設定」はどこにも記録されない最悪の状態です。手作業の変更をやめてコード管理に寄せる話はIaCのState管理とCI/CD入門で扱っています。
02用語の交通整理 — AMI・スナップショット・バックアップ・レプリカ
地図の次は言葉です。「スナップショットは取ってます」「AMIはありますか？」「……同じものでは？」——この手の会話が起きるのは、性質の違う4種類の名前が、同じ「守る」の文脈で飛び交うからです。
- スナップショットは「仕組み」の名前：EBSボリューム1本の断面です。戻せる単位もボリューム1本。スナップショットからボリュームを作ってアタッチするところまでやって、初めて復元です。
- AMIは「包み」の名前：実体は起動情報(ブロックデバイスマッピング等)＋スナップショット群です。AMIを作ると、ルートと追加ボリュームのスナップショットが裏で作られます。マシンをまるごと起動し直せるのはAMIだけ。なお実行中インスタンスからのAMI作成は、整合性確保のためデフォルトで再起動を伴います(No rebootを選ぶとファイルシステム整合性は保証されません)。
- バックアップは「目的」の名前：世代・保持・戻す手順まで含めた運用を指す言葉です。RDSの「自動バックアップ」は日次スナップショット＋5分ごとに退避されるトランザクションログのセットで、だから保持期間内の任意の秒へ戻せます(PITR)。「手動スナップショット」は点にしか戻れません。同じ「スナップショット」という言葉でも、運用上の役割はここまで違います。ちなみにPITRの復元先は新しいインスタンスで、既存の上書きではありません。
- レプリカ/Multi-AZは「可用性」の名前：「今」を複製する仕組みで、「過去」を持ちません。
DROP TABLEも忠実に複製されます。「Multi-AZだからバックアップ不要」が誤りである理由はこれです。
そしてAWS Backupは、これらをすべて「復旧ポイント」という統一語彙で呼び直します。EC2の復旧ポイントの実体はAMI、EBSはスナップショット、RDS/Auroraはスナップショットや継続バックアップ——中身はサービス別のまま、器だけ揃える発想です。実務上の注意として、AWS Backupが管理するAMIはEC2コンソールから登録解除できません。消すときはVault側で復旧ポイントを削除します。対応表にまとめます。
| 言葉 | 実体 | 戻せる単位 | 消える・残る条件 |
|---|---|---|---|
| EBSスナップショット | ボリューム1本の断面(増分) | ボリューム | 明示削除まで残る。AMIに使われている間は削除不可 |
| AMI | 起動情報＋スナップショット群 | マシンまるごと(起動) | 登録解除で消える。解除してもスナップショットは残り課金継続(同時削除オプションあり) |
| RDS自動バックアップ | 日次スナップショット＋5分毎のログ | 任意の秒(新インスタンスへ) | 保持期間(最大35日)で失効。インスタンス削除で消える(Retain指定を除く) |
| RDS手動スナップショット | ストレージの断面 | その時点(新インスタンスへ) | 明示削除まで残る |
| AWS Backupの復旧ポイント | リソース別(EC2=AMI、EBS=スナップショット等) | リソース別 | Vaultの保持ルールに従う。EC2側からは登録解除不可 |
| レプリカ(Multi-AZ・リードレプリカ) | 「今」の複製 | 戻せない(過去を持たない) | —(可用性の仕組みでありバックアップではない) |
| S3バージョニング | 同一キーの旧版の積み重ね | オブジェクト単位 | ライフサイクル設定次第で旧版は掃除される |
| 起動テンプレート/ゴールデンイメージ | 構成の記述/「揃えたAMI」の運用上の呼び名 | — | データは含まない(01の「構成」レーン) |
03なぜスナップショットは本番負荷ほぼゼロなのか — 増分・参照・非同期
もうひとつの素朴な疑問に答えます。「200GBのボリュームをバックアップするなら、200GB読み出すはず。本番が重くなるのでは？」——ファイルコピーの感覚では正しい心配ですが、スナップショットは読んで写す方式ではありません。EBSを例に、公式ドキュメントに書かれている仕組みを追います。
- 断面の確定は一瞬：スナップショット作成を指示した瞬間に「その時点の版」が確定します。以後の書き込みは断面とは独立に進むため、業務I/Oを止めて読み写す工程がそもそも存在しません。
- 退避は裏で非同期：確定した断面のブロックは、バックグラウンドでS3側のスナップショット領域へ吸い上げられます。ステータスが
pendingの間も本番の読み書きは通常どおりです。 - 2回目以降は変更ブロックだけ：初回のみ書き込み済みブロックの全量(200GiBのボリュームでもデータが50GiBなら50GiB)、以後は前回から変わったブロックだけを退避し、変わっていないブロックは前回スナップショットへの参照で済ませます。公式の例では、50GiBの初回スナップショットの後に30GiB分を変更・追加した場合、2つ目のスナップショットが新規に保存するのは30GiBだけです。
この「ストレージ層で断面を切る」設計は、DBサービスでも同じです。ただしサービスごとに輪郭が違い、そこに正直な注記が要ります。
- RDS：ストレージボリュームのスナップショットです。シングルAZ構成では取得開始時に数秒〜数分の短いI/O一時停止が発生し得ます(サイズとインスタンスクラスに依存)。Multi-AZ構成ならMariaDB/MySQL/Oracle/PostgreSQLはスタンバイ側から取得されるため本番は無停止。SQL ServerだけはMulti-AZでも短時間の停止があります。夜間に「バックアップウィンドウ」を設ける慣行は、この一時停止を業務時間外へ寄せるためのものです。
- Aurora：そもそも夜間スナップショット方式ではなく、分散ストレージからS3への継続的な増分バックアップが常に流れています。公式に「バックアップ書き込み中の性能影響もサービス中断もない」と明記されており、自動バックアップは無効化できません。
- DynamoDB：バックアップはテーブルのプロビジョンドスループットを一切消費しません。リクエスト時刻のマーカーを記録し、裏側で非同期に組み立てる方式です(そのため項目間の因果一貫性は保証されず、ズレは通常1秒未満とされています)。
逆に、負荷ゼロにならない反例を知っておくと理解が固まります。ElastiCache(ノード型のRedis OSS/Valkey)のバックアップはストレージ層ではなくエンジンのBGSAVE(fork)で作られるため、メモリに余裕がないノードでは性能影響が出ます。公式も「レプリカからバックアップを取る」「reserved-memoryを確保する」ことを推奨しています。つまり負荷ゼロはスナップショットの魔法ではなく、ストレージ層で断面を切れる設計の恩恵です。切れないサービスでは、負荷はエンジンに現れます。
04サービス別「バックアップはどこ？」早見表
ここまでの地図を、現場でよく使うサービスに当てはめます。「消える条件」の列が初学者にとっての本丸です。
| リソース | データの守り方 | 取得時の本番影響 | 初学者が踏む注意 |
|---|---|---|---|
| EC2 (EBS) | スナップショット / AMI(＋AWS Backup/DLMで自動化) | ほぼなし(非同期・増分) | AWSは自動では取ってくれないと公式明記。自動化を仕込むまで保護ゼロ |
| RDS | 自動バックアップ(PITR)＋手動スナップショット | シングルAZは数秒〜数分のI/O停止、Multi-AZはほぼなし | インスタンス削除で自動バックアップも消える(Retain指定か最終スナップショットが必要。手動スナップショットは残る) |
| Aurora | 継続バックアップ(無効化不可)＋スナップショット | なし(公式明記) | 保持期間は最大35日。それ以上はスナップショットで |
| DynamoDB | PITR(35日)＋オンデマンドバックアップ | なし(スループット消費ゼロ) | 復元は新テーブルへのみ。TTL・Auto Scaling・アラーム等は復元されず手動で再設定 |
| S3 | バージョニング＋ライフサイクル、レプリケーション、AWS Backup for S3 | なし | 「S3だから安全」は障害耐性の話。誤削除にはバージョニングを有効化して初めて対抗できる |
| EFS / FSx | AWS Backup(EFSは自動バックアップ推奨) | ほぼなし | NFSマウント先で消したファイルはバックアップからしか戻らない |
| ElastiCache | Redis/Valkeyはスナップショット。ノード型Memcachedは無し | ノード型はfork負荷あり→レプリカから取得 | キャッシュは「元データから再構築できる」ことが前提の置き場。再構築不能なデータを置いたら設計ミス |
| SQS / SNS / Kinesis | バックアップ機構なし(流れるデータ) | — | 守るのは「メッセージ」でなく「再処理できること」。DLQ・冪等設計・再投入手順で担保 |
| CloudWatch Logs | 保持期間設定＋S3エクスポート/サブスクリプション | なし | 保持期間デフォルト「失効しない」はコスト事故、短すぎは証跡喪失。明示設定する |
| Secrets Manager / Parameter Store | 削除の猶予期間(7〜30日)/パラメータ履歴(最大100世代) | なし | これらは「バックアップ風」の救済機能。定義本体はIaC側で管理する |
| Lambda / API Gateway / IAM / Route 53 | 構成なのでGit＋IaC＋成果物ストア | — | AWS Config履歴は「証跡」でありリストア手段ではない。コンソール手作業はどこにも残らない |
表の下3行が、冒頭の「Lambdaのバックアップはどこ？」の一般形です。データを抱えるサービスはAWS側の仕組み(＋AWS Backupの一元管理)で守り、流れるデータは再処理設計で守り、構成はGitで守る。この3分岐だけ覚えれば、初見のサービスでも「どこを探すべきか」を外しません。
05素人がつまずく落とし穴5選
知識としては上の表で足りますが、実際の事故は決まったパターンで起きます。5つだけ挙げます。
- ①RDSを消したら自動バックアップも消えた：自動バックアップはインスタンスに紐づき、削除時に「自動バックアップを保持」を選ばなければ一緒に消えます。削除前の最終スナップショット取得を運用ルール化してください(手動・最終スナップショットは削除後も残ります)。
- ②バックアップはあるのに戻せない：DynamoDBの復元は新テーブルのみで、TTLやAuto Scaling設定は戻りません。EBSスナップショットだけあってもAMIがなければ同じ構成のEC2はすぐに起きません。「戻す手順」まで含めて初めてバックアップです。
- ③リージョンの中に閉じている：スナップショットはリージョナルリソースです(EBSはリージョン内の全AZに複製されますが、リージョンの外へは出ません)。東京リージョン障害のシナリオでは東京のバックアップも巻き込まれます。DR要件があるならクロスリージョンコピーを明示的に仕込みます。
- ④S3バージョニングの削除マーカー：バージョニング有効時の削除は「削除マーカーを積む」だけで、旧版はその下に残っています。「消えた！」の多くはマーカーを外せば戻ります。逆に、ライフサイクルで旧バージョンを掃除する設定を入れていると「バージョニングしているから安全」が期限付きになります。仕組みの詳細はS3はファイルシステムではないもどうぞ。
- ⑤取れているが、戻したことがない：最頻出にして最重症。リストアの所要時間(=実測RTO)を知らないバックアップは、監査でも障害でも役に立ちません。定期的な復旧テストの自動化はAWS Backupの機能で仕込めます(運用設計編参照)。
—まとめ
全体地図を4行に圧縮します。
- データはAWSの仕組みで守る：スナップショット/PITRをAWS Backupで束ねる。負荷ほぼゼロの正体は「断面確定は一瞬・退避は非同期・増分は変更ブロックだけ」(＋Multi-AZはスタンバイから)。例外はElastiCacheのようにエンジンで断面を切るサービス
- 流れるデータは再処理で守る：SQS/Kinesisにバックアップは無い。DLQ・冪等・再投入の設計が代わりを務める
- 構成はGitで守る：Lambdaのバックアップはデプロイパイプラインそのもの。コンソール手作業だけがどこにも残らない
- 言葉は「実体」で見る：AMI＝起動情報＋スナップショット群(解除しても中身は残る)、自動バックアップ＝スナップショット＋ログ(だから任意の秒へ)、レプリカ＝過去を持たない複製
そして、シングルAZ RDSのI/O一時停止・DynamoDB復元の制約・リージョン閉鎖性のような「輪郭の細部」が、実際の設計品質を分けます。守るべきデータの列挙から復旧テストまで、バックアップ/DR全体の設計はお問い合わせから。実績は導入事例をご覧ください。
—参考(一次情報)
- Amazon EBS snapshots (自動では取られない旨・S3保存・リージョン内複製)
- How Amazon EBS snapshots work (フル/増分・ブロック参照モデル)
- Create an Amazon EBS-backed AMI (AMI＝起動情報＋スナップショット・再起動と整合性)
- Deregister an Amazon EC2 AMI (解除してもスナップショットは残る・課金継続)
- Introduction to backups - Amazon RDS (自動バックアップと削除時の挙動)
- Creating a DB snapshot - Amazon RDS (シングルAZのI/O一時停止・Multi-AZはスタンバイから取得)
- Restoring a DB instance to a specified time - Amazon RDS (5分毎のログ退避・新インスタンスへの復元)
- Overview of backing up and restoring an Aurora DB cluster (継続増分・性能影響なし)
- Backing up and restoring DynamoDB tables (スループット消費ゼロ・復元制約)
- ElastiCache Snapshot and restore (BGSAVEの性能影響とレプリカ取得の推奨)
- What is AWS Backup? (対応リソース一覧)