AMIとスナップショットはどう違うのか？EC2とEBSの関係を整理

Q: Q. AMI を削除すれば裏のスナップショットも消えますか？

A. 従来は消えませんでした。deregister しても紐づく EBS スナップショットは残り、課金され続けます。aws ec2 deregister-image --delete-associated-snapshots を使うか、DLM の AMI ポリシーで世代管理すれば、AMI とスナップショットをまとめて整理できます。

Q: Q. AMI 作成時に EC2 を停止する必要は？

A. 整合性の観点では停止が推奨です。--no-reboot で稼働中に作成もできますが、書き込み途中の状態が混ざるリスクがあります。本番では定期メンテナンス時間に停止して AMI を作成し、再起動する運用が安全です。

先に要点

AMI は EC2 を起動するためのイメージで、OS・起動権限・ブロックデバイスマッピングと、1つ以上の EBS スナップショットをまとめた「起動用の定義セット」です。
スナップショットは EBS ボリュームのある時点コピー(増分保存)で、ディスクの中身を戻す・別ボリュームを作るためのものです。スナップショット単体では EC2 は起動できません。
失敗の典型は2つ。「スナップショットだけ取って起動できず慌てる」と「使わない AMI を放置して裏のスナップショット料金が積み上がる」。どちらも仕組みを知れば防げます。
世代管理は手作業ではなく Amazon Data Lifecycle Manager で「日次取得・N世代保持・古い世代は自動削除」をルール化するのが定番です。

AWS を触り始めると、AMI とスナップショットがどちらも「保存」に見えて混ざりやすいです。実際、どちらも EC2 や EBS を戻す話で出てくるので、初心者ほど区別が曖昧になりやすいところです。

ですがこの2つは同じものではありません。似ているのは「復元に関わる」という点だけで、役割はかなり違います。そしてこの違いを曖昧にしたまま運用すると、いざという時に「スナップショットはあるのに EC2 が起動できない」「気づいたらスナップショット料金だけ毎月膨らんでいた」という事故につながります。

この記事では、2026年6月時点で Amazon EC2 User Guide、Amazon EBS User Guide、AWS Prescriptive Guidance の公開情報を確認しながら、AMI とスナップショットの違いを、実際のコマンド・料金・失敗例を交えて整理します。

まず一言でいうと

最初にざっくり分けるなら、こう考えると分かりやすいです。

AMI

EC2 を起動するための元データ。OS・初期設定・ボリューム構成・起動権限まで含む。「同じサーバーをもう1台立てる」ための型紙。

スナップショット

EBS ボリュームのある時点コピー。増分保存。「ディスクの中身を保存・復元する」「別ボリュームを作る」ための部品。

つまり、サーバーを同じ構成でもう1台立てたい、同じ OS や初期設定を元にして起動したい、ならば AMI が中心です。一方で、ディスクの中身をある時点へ戻したい、既存ボリュームから新しいボリュームを作りたい、ならばスナップショットが中心です。

スナップショットとは何か

Amazon EBS のドキュメントでは、スナップショットは EBS ボリュームの point-in-time copy、つまりある時点のコピーとして説明されています。さらに EBS スナップショットは増分バックアップで、最初の1回はフル、以後は前回からの変更ブロックだけを保存する仕組みです。

ここで大事なのは、スナップショットが見ている対象は「ボリューム」だという点です。具体的にできることは次のとおりです。

ある EBS ボリュームをまるごと保存する
そのスナップショットから新しい EBS ボリュームを作る
別アベイラビリティゾーンや別用途向けに同じ内容のディスクを複製する

たとえば、稼働中インスタンスのデータボリュームを CLI で取得するとこうなります。

$ aws ec2 create-snapshot --volume-id vol-0abc123 --description "app-data 2026-06-13"
{
    "SnapshotId": "snap-0def456",
    "VolumeId": "vol-0abc123",
    "State": "pending",
    "VolumeSize": 100,
    "StartTime": "2026-06-13T02:11:09.000Z"
}

State が pending から completed に変われば取得完了です。重要なのは、このスナップショットはあくまで「100GB のディスクの中身」であって、これ単体では EC2 として起動できないという点です。ここを誤解していると、後述する起動できない事故につながります。

AMIとは何か

AMI は Amazon Machine Image の略で、EC2 を起動するときの元になるイメージです。Amazon EC2 User Guide や AWS Prescriptive Guidance では、AMI には次のような情報が含まれると整理されています。

1つ以上の EBS スナップショット(ルートボリュームと、付随するデータボリューム分)
起動権限(どのアカウントがこのイメージから起動できるか)
ブロックデバイスマッピング(起動時にどのボリュームをどう接続するかの定義)

ブロックデバイスマッピングがあるからこそ、AMI は「この内容でインスタンスを起動するための定義セット」になります。単なる保存されたディスクではない、という点がスナップショットとの決定的な違いです。

AMI を作るときも、裏では EBS スナップショットが自動で作られます。

$ aws ec2 create-image --instance-id i-0aaa111 --name "web-app-2026-06-13" --no-reboot
{
    "ImageId": "ami-0ggg999"
}

$ aws ec2 describe-images --image-ids ami-0ggg999 \
    --query 'Images[].BlockDeviceMappings[].Ebs.SnapshotId'
[
    "snap-0hhh888",
    "snap-0iii777"
]

この出力のとおり、1つの AMI が複数のスナップショットを参照しています。この「AMI とスナップショットは別物だが内部でつながっている」関係こそが、後でコスト事故の原因になります。

EC2インスタンスからAMIを作る手順

読み込み中...

失敗例1: スナップショットだけ取って起動できず慌てる

これは初心者に最も多い事故です。

現象

本番 EC2 が壊れた。バックアップとして EBS スナップショットは毎日取っていたのに、そこから「サーバーを起動」しようとしてもメニューに起動の選択肢が出てこない。復旧に時間がかかり慌てる。

原因

スナップショットはボリュームの中身でしかなく、起動権限やブロックデバイスマッピングを持たない。EC2 を起動するには AMI のような起動用定義が必要。スナップショット=バックアップ=そのまま起動できる、という思い込みが原因。

確認手順は次のとおりです。まず手元にあるのがスナップショットだけなのか、AMI もあるのかを切り分けます。

$ aws ec2 describe-images --owners self --query 'Images[].[ImageId,Name]' --output table
# 行が出てこなければ、起動できる AMI を1つも持っていない

回避策は2つあります。ひとつは、スナップショットしか無い状態でも復旧できるよう、ルートボリュームのスナップショットから AMI を作る手順を知っておくことです。

$ aws ec2 register-image --name "recovered-2026-06-13" \
    --root-device-name /dev/xvda \
    --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"SnapshotId":"snap-0def456"}}]' \
    --architecture x86_64 --virtualization-type hvm --ena-support
{
    "ImageId": "ami-0jjj555"
}

ただしこの方法は、ルートボリューム(OS が入ったディスク)のスナップショットでないと EC2 として起動できません。データボリュームだけのスナップショットからは起動用 AMI は作れず、新しいボリュームとしてアタッチするしかありません。

もうひとつの根本対策は、はじめから「サーバー全体の復旧用には AMI」「データだけの復元用にはスナップショット」と取得対象を分けて運用しておくことです。これが次の使い分けの章につながります。

何を復元したいかで使い分ける

実務では、違いを理屈で覚えるより「何を戻したいか」で考えると整理しやすいです。

やりたいこと	向いているもの	理由
同じ構成の EC2 をもう1台作る	AMI	起動に必要な定義をまとめて持てる
サーバーが壊れたとき素早く再起動する	AMI	そのまま起動できる型紙だから
ある時点のディスク内容を残す	スナップショット	EBS ボリュームの時点コピーだから
誤削除後に中身だけ調査する	スナップショット	別ボリュームとして切り出しやすい
OS や初期設定込みで再利用する	AMI	起動テンプレートとして使いやすい

本番運用では、サーバー全体を素早く戻したいケースとデータだけを戻したいケースの両方が起きるため、「日次 AMI + データボリュームの EBS スナップショット」を併用するのが定番です。

失敗例2: 古いAMIを放置してコストが膨らむ

もうひとつ多いのが、コストの事故です。

現象

請求書を見たら EBS スナップショット料金が想定より高い。EC2 はそれほど多くないのに、スナップショットだけが何百個も積み上がっていた。

原因

AMI を作るたびに裏でスナップショットが増える。そして AMI を登録解除(deregister)しても、参照していた EBS スナップショットは自動では消えず残り続ける。この「孤児スナップショット」が課金され続ける。

EBS スナップショットの標準ティアは 1GB あたり月 0.05 USD(東京リージョン目安)です。仮にルート 30GB の AMI を毎日作り、増分込みで実効 10GB ずつ積み上がると、半年で約 1.8TB 相当となり、月 90 USD 前後がスナップショットだけで発生する計算になります。増分保存なので実際はもっと少ないことも多いですが、「AMI を deregister したから消えたはず」という思い込みのまま放置すると、確実に積み上がります。

確認手順はこうです。まず、どの AMI からも参照されていない孤児スナップショットを洗い出します。

# 自分が所有する全スナップショット ID
$ aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].SnapshotId' --output text

# AMI が参照しているスナップショット ID
$ aws ec2 describe-images --owners self \
    --query 'Images[].BlockDeviceMappings[].Ebs.SnapshotId' --output text

前者にあって後者に無いものが孤児候補です。なお、AMI を deregister するときに --delete-associated-snapshots を付けると、その AMI 専用のスナップショットは同時に削除できます(複数 AMI が共有しているスナップショットは削除されません)。

$ aws ec2 deregister-image --image-id ami-0ggg999 --delete-associated-snapshots

回避策は、削除を手作業に頼らず世代管理ルールに任せることです。次の章で具体的に決めます。

世代管理ルールの具体運用

「古くなったら消す」を人間が覚えていられないのが事故の根本原因です。Amazon Data Lifecycle Manager(DLM)で、取得と削除をポリシー化します。DLM には大きく2つの保持方式があります。

方式	指定するもの	挙動	向くケース
カウントベース	保持する世代数(最大1000)	新しいものを作ると最も古いものから自動削除	常に直近 N 世代だけ持ちたい本番サーバー
エイジベース	保持期間(最大10年)	作成から指定期間を過ぎたものを自動削除	「30日保持」など期間で決めたい監査・規約対応

具体的なルール例としては、次のような組み合わせが扱いやすいです。

本番 Web サーバーの AMI: 日次取得・カウントベースで7世代保持。AMI ポリシーには deprecate ルールも設定し、古い世代は削除前にまず「非推奨(deprecated)」にして新規ユーザーから選べなくする。
データボリュームのスナップショット: 日次・直近14世代 + 週次・8世代の2段構え。長期保管が必要な分だけアーカイブティア(1GB あたり月 0.0125 USD 前後、最低保管90日)へ寄せる。
すべてのリソースに Backup=daily のようなタグを付け、DLM はそのタグを対象にして動かす。

DLM の AMI ポリシーは、保持数を超えた古い AMI を deregister するだけでなく、紐づく EBS スナップショットも合わせて削除してくれます。これにより、失敗例2の孤児スナップショット問題が構造的に起きなくなります。さらに、count ベースなら「常に7個」、age ベースなら「30日で消える」と上限が決まるため、放置によるコスト増の上限が読めるようになります。

よくある誤解

AMIがあれば全部バックアップになる

AMI は便利ですが、万能なバックアップと考えると危険です。AMI は「起動しやすさ」に強い一方で、特定ファイルだけを戻すような細かい粒度の復旧や、データベースの論理バックアップの代わりにはなりません。AWS Prescriptive Guidance でも、EC2 のバックアップでは「インスタンス全体を AMI で取るか」「個別ボリュームをスナップショットで取るか」を分けて考える前提になっています。

スナップショットがあればそのままEC2を起動できる

これが失敗例1の正体です。スナップショット単体は、基本的にボリュームを作るための元でしかありません。そこから EC2 を起動するには、ルートボリュームのスナップショットから AMI を登録する手順が必要です。データボリュームだけのスナップショットからは起動できない、という点も合わせて覚えておくと安全です。

料金や保存の感覚も違う

スナップショットは増分保存なので、同じボリュームに対して何度取っても、毎回フルコピーを丸ごと持つわけではありません。2回目以降は前回からの変更ブロック分だけが追加されます。料金は保存している実データ量に対して、標準ティアで 1GB あたり月 0.05 USD 前後が目安です。

一方 AMI 自体には保存料金がかからず、課金されるのは AMI が参照している EBS スナップショットの容量です。つまり「AMI を10個作った」=「その分のスナップショット容量に課金される」と考えるのが正確です。ユーザーの感覚としては、ボリュームの履歴管理に近いのがスナップショット、再利用できるサーバーの元に近いのが AMI です。

AMIとスナップショットに関するよくある質問

Q. どちらをバックアップに使うべき？

A. 用途次第です。サーバー全体の復旧なら AMI、データボリュームだけなら EBS スナップショット。本番運用では「日次 AMI + EBS スナップショット」の併用が定番で、両方を DLM で世代管理します。

Q. スナップショットだけで EC2 を起動できますか？

A. できません。スナップショットはボリュームの中身でしかなく、起動権限やブロックデバイスマッピングを持たないためです。ルートボリュームのスナップショットから AMI を register してはじめて起動できます。データボリュームのスナップショットからは起動用 AMI は作れません。

Q. AMI を削除すれば裏のスナップショットも消えますか？

A. 従来は消えませんでした。deregister しても紐づく EBS スナップショットは残り、課金され続けます。aws ec2 deregister-image --delete-associated-snapshots を使うか、DLM の AMI ポリシーで世代管理すれば、AMI とスナップショットをまとめて整理できます。

Q. 古い AMI を放置するとどうなりますか？

A. 参照する EBS スナップショットの容量分の料金がかかり続けます。標準ティアで 1GB あたり月 0.05 USD 前後なので、数百個積み上がると無視できない額になります。カウントベースで保持世代数を決め、超過分を自動削除するのが回避策です。

Q. 世代管理は何世代くらいが目安ですか？

A. 本番サーバーの AMI なら日次7世代(1週間分)、データのスナップショットなら日次14世代に加えて週次を数世代、といった二段構えが扱いやすいです。長期保管が必要な分はアーカイブティア(1GB あたり月 0.0125 USD 前後、最低90日)へ寄せます。

Q. AMI 作成時に EC2 を停止する必要は？

A. 整合性の観点では停止が推奨です。--no-reboot で稼働中に作成もできますが、書き込み途中の状態が混ざるリスクがあります。本番では定期メンテナンス時間に停止して AMI を作成し、再起動する運用が安全です。

Q. スナップショットからの復旧時間は？

A. 大容量ボリュームでも、復元したボリュームは作成直後から使い始められます。データは裏でバックグラウンドに取り込まれる(遅延ロード)ため、初回アクセスだけ遅くなることがあります。性能を最初から出したい場合は Fast Snapshot Restore を有効化します。

Q. AMI のリージョン間コピーはできますか？

A. できます。AMI をコピーして別リージョンに置けば、東京から us-east-1 へといった災害対策(DR)構成に使えます。料金はデータ転送料と、コピー先リージョンでのスナップショット保存料が発生します。

まとめ

AMI とスナップショットの違いは「どちらも保存っぽい」ところで混ざりやすいですが、役割はかなり違います。

スナップショットは EBS ボリュームの時点コピーで、それ単体では EC2 を起動できない
AMI は EC2 を起動するための定義セットで、内部にスナップショットを含む
「サーバーを起こす」なら AMI、「ディスクを戻す」ならスナップショット
取りっぱなしは事故の元。DLM で世代数や保持期間を決めて、取得と削除をルール化する

スナップショットだけ取って起動できず慌てる事故も、古い AMI を放置してコストが膨らむ事故も、仕組みと世代管理を押さえれば防げます。バックアップや復旧の流れまで含めて見たい場合はバックアップはあるのに戻せないを防ぐには？復元確認の手順と見落としやすい点を整理や、誤終了時の判断なら AWSでEC2を停止ではなく終了してしまったときはどうする？まず確認すべきこともつながります。

参考リンク

Amazon EBS User Guide: Amazon EBS snapshots
Amazon EBS User Guide: How Amazon EBS snapshots work
Amazon EBS User Guide: Pricing and billing for archiving Amazon EBS snapshots
Amazon EC2 User Guide: Create an Amazon EBS-backed AMI
Amazon EC2 User Guide: Deregister an Amazon EC2 AMI
Amazon Data Lifecycle Manager: DeprecateRule API Reference
AWS Prescriptive Guidance: Amazon EC2 backup and recovery with snapshots and AMIs
Amazon EBS pricing: Amazon EBS pricing

AMIとスナップショットはどう違うのか？EC2の起動用イメージと保存単位を整理