先に結論
AMI は、EC2 を起動するときの元になるテンプレートです。
正式には Amazon Machine Image の略で、AWS公式でもインスタンス起動に必要な情報を含むイメージとして説明されています。
初心者向けには、次の切り分けを最初に押さえるとかなり分かりやすいです。
| 項目 | ざっくりした役割 |
|---|---|
| AMI | 起動元の型 |
| EC2インスタンス | 実際に起動して動くサーバー |
| EBS | そのインスタンスに付くディスク |
つまり、AMIは 動いているサーバーそのもの ではなく、そのサーバーをどういう状態で起動するかを決める元データ です。
この記事では、2026年4月23日時点で AWS公式の
AMI types and characteristics in Amazon EC2、Create an Amazon EBS-backed AMI、Create an Amazon EC2 launch template、Create a launch template for an Auto Scaling groupを確認しながら整理しています。
AMIとは何か
AMIは、EC2起動時の土台になるイメージです。
どのOSを使うか、どのアーキテクチャか、どのルートボリューム構成か、といった起動元の情報を持っています。
たとえば、Amazon Linux、Ubuntu、Windows Server、Marketplace製品、社内で作ったカスタムイメージなどがAMIとして使われます。
EC2を作るときに どのAMIから起動するか を選ぶのは、どの型からサーバーを作るか を選んでいるのと近いです。
なぜAMIが大事なのか
初心者だと、EC2画面で目立つのはインスタンスタイプやネットワーク設定なので、AMIは 最初に1回選ぶだけの項目 に見えやすいです。
でも実際には、AMIの選び方でかなり変わります。
- どのOSで起動するか
- Arm系かx86系か
- 最初から何が入っているか
- 起動後の初期設定をどれだけ省けるか
- チーム内で同じ環境を再現しやすいか
このため、AMIは単なる開始ボタンではなく、再現性と運用効率に関わる部品です。
AMIとEC2インスタンスの違い
ここはかなり混ざりやすいです。
AMI
AMIは、起動元のテンプレートです。
まだ動いているサーバーではありません。
EC2インスタンス
EC2インスタンスは、AMIから実際に起動したサーバー本体です。
ログインしたり、アプリを動かしたり、ファイルを書き込んだりするのはこっちです。
初心者向けには、AMIは金型、インスタンスはそこから作られた実物 と考えるとかなり分かりやすいです。
AMIとEBSの関係
AWS公式では、AMIのルートボリュームタイプとして Amazon EBS-backed AMI と Amazon S3-backed AMI が説明されています。
いま一般的に見るのは、ほぼ EBS-backed AMI と考えて大丈夫です。
EBS-backed AMI では、起動時にルートボリューム用のEBSが作られます。
つまり、AMIそのものがディスクではなく、AMIの情報をもとにEBSボリュームが作られてインスタンスが起動する、という流れです。
この点で、
- AMI = 起動元
- EBS = 起動後に付くディスク
- インスタンス = 実際に動くサーバー
と分けると整理しやすくなります。
どんなAMIを選ぶのか
AWS公式でも、AMIは次のような観点で選ぶ前提になっています。
初心者が特に見るべきなのは、次の3つです。
1. OS
Amazon Linux、Ubuntu、Windows Server など、何で始めるかを決めます。
チームの知識や既存運用に合わせる方が安全です。
2. CPUアーキテクチャ
AMIとインスタンスタイプは互換性が必要です。
AWS公式でも、選ぶAMIは使うインスタンスタイプと互換である必要があると説明されています。
たとえば、Arm系AMIなのにx86前提で考えると起動設計がずれます。
3. 公開範囲
AWS公式では、AMIには public / explicit / implicit の launch permissions があると案内されています。
つまり、誰がそのAMIを使えるかも管理対象です。
カスタムAMIとは何か
AMIはAWSが用意したものを使うだけではありません。
自分でEC2を整えて、それをもとにカスタムAMIを作ることもできます。
AWS公式の Create an Amazon EBS-backed AMI でも、既存インスタンスをカスタマイズして新しいAMIを作り、そこから新しいインスタンスを起動する流れが説明されています。
たとえば、次のような場面で便利です。
- 必要なミドルウェアを最初から入れておく
- 社内共通の初期設定をそろえる
- 同じ構成の検証機を何台も立てる
- Auto Scalingで同じ初期状態を増やす
つまり、カスタムAMIは 起動後に毎回手で整える を減らすための部品です。
Launch Templateとの関係
ここも実務ではよくつながります。
Launch Template は、EC2起動に必要な設定一式をまとめる仕組みです。
AWS公式でも、Launch Templateには AMI ID、インスタンスタイプ、キーペア、セキュリティグループなどを含めると説明されています。
このため、AMIは 起動元イメージ、Launch Templateは AMIを含んだ起動設定セット と見ると分かりやすいです。
特に、Auto Scalingや複数台構成では、AMI単体より AMI + Launch Template の組み合わせで考える場面が増えます。
よくある誤解
1. AMIは起動中インスタンスそのもの
違います。
AMIは起動元で、実際に動いているのはインスタンスです。
2. AMIを選べば環境差分は絶対に消える
AMIはかなり役立ちますが、起動後にユーザーデータ、環境変数、外部設定、IAMロール、ネットワーク設定が違えば、完全に同じにはなりません。
再現性を上げる部品のひとつとして見る方が正確です。
3. AMIとEBSは同じもの
近いところで関わりますが、同じではありません。
EBS-backed AMI では、AMIをもとにルートEBSボリュームが作られる、という関係です。
どう理解するとよいか
初心者向けには、AMIを EC2の起動テンプレート として覚えるのがいちばん自然です。
さらに一歩進めるなら、OSイメージ で終わらせず、再現性を持ってインスタンスを増やすための起点 と考えると実務で役立ちます。
この見方をすると、
- まずAMIを選ぶ
- そこからEC2を起動する
- ルートディスクはEBSで持つ
- 複数台や自動起動はLaunch Templateとつなぐ
という流れが見えやすくなります。
この順で読むとつながりやすい
この順に見ると、本体 ディスク 起動元 起動設定 がきれいにつながります。
まとめ
AMI は、EC2を起動するときの元になるテンプレートです。
インスタンス本体ではなく、起動元の型として見ると理解しやすくなります。
特に大事なのは、AMIを OSイメージ だけで終わらせず、同じ状態のEC2を再現する起点 として見ることです。
EBSやLaunch Templateとの関係まで押さえると、AWSの起動まわりがかなり読みやすくなります。
参考リンク
- AWS Docs: AMI types and characteristics in Amazon EC2
- AWS Docs: Create an Amazon EBS-backed AMI
- AWS Docs: Create an Amazon EC2 launch template
- AWS Docs: Create a launch template for an Auto Scaling group