AWS

AWS AMIとは：作成・コピー・共有・登録解除のCLI手順と東京のスナップショット料金

AWS AMIとは：作成・コピー・共有・登録解除のCLI手順と東京のスナップショット料金

AMI（Amazon Machine Image）は、EC2インスタンスを起動するためのOSとソフトウェア、接続するボリュームの定義をまとめたイメージです。この記事では、AMIの中身と、最新のAmazon Linux 2023のAMI IDをSSMパラメータで引く方法、自作AMIの作成・リージョン間コピー・アカウント共有をAWS CLIで行う手順を整理しました。AMIそのものに料金はかかりませんが、裏にあるEBSスナップショットは東京リージョンで1GBあたり月0.05ドル課金されます。使われていないAMIと孤立したスナップショットを洗い出すコマンド、誤削除を防ぐ保護設定、社内で使えるAMIを絞るAllowed AMIsまで扱います。

まとめ：AWS AMIを使う場面とスナップショット課金を放置しない運用の要点

AWSが公開しているAMIは、IDを直接書かずにSSMパブリックパラメータから引くのが基本です。Amazon Linux 2023のAMIは1本ごとにリリースから90日で非推奨になるため、IDを固定するとすぐ古くなります。

自作AMIは、同じ構成のサーバーを何台も起動する場合や、起動時間を短くしたい場合に作ります。作成時にはルートボリュームと追加ボリュームのスナップショットが作られ、AMIを登録解除してスナップショットを消すまで課金が続きます。

運用で最初にやるべきことは、半年以上起動されていないAMIを一覧にし、--delete-associated-snapshots を付けて登録解除することです。本番で使うAMIには登録解除保護を付け、バックアップの役割はAWS Backupへ任せます。

AMIの中身と起動までの流れを押さえるAWS AMIの基礎知識

AMIを理解する近道は、「何が入っていて、どこに保存され、誰が使えるのか」を分けて見ることです。

AMIに含まれるスナップショット・起動許可・ブロックデバイスマッピング

Amazon EC2のAmazonマシンイメージの説明では、AMIはインスタンスの起動に必要なソフトウェアを提供するイメージで、起動時にアタッチするブロックデバイスを指定するブロックデバイスマッピングを持ちます。EBS-backed AMIの場合、ソフトウェアの実体はEBSスナップショットに保存されています。

要素 中身 課金
EBSスナップショット ルートと追加ボリュームの内容 保存量に応じて課金
ブロックデバイスマッピング デバイス名・サイズ・種類 なし
起動許可 使えるアカウントの一覧 なし
メタデータ 名前・アーキテクチャ・ブートモード なし

新しいインスタンスを起動すると、EC2はスナップショットから新しいEBSボリュームを作ってルートボリュームにします。インスタンスストアのボリュームはマッピングに定義が残るだけで、元のインスタンスにあったデータは引き継がれません。ボリュームの種類と料金はAmazon EBSのボリュームタイプと東京の料金で整理しています。

AMI IDはリージョンごとに別物でコピーしないと使えない仕組み

AMIはリージョン単位のリソースです。同じAmazon Linux 2023でも、東京と大阪ではAMI IDが違います。自作AMIを別のリージョンで使うには、そのリージョンへコピーして新しいIDを受け取る必要があります。

AMIの入手元は、AWSが提供するAMI、パブリックAMI、他のアカウントから共有されたAMI、AWS Marketplaceで購入したAMIの4種類です。パブリックAMIは誰でも公開できるため、提供元を確かめずに使うと、不要なソフトウェアや認証情報が残ったイメージを本番に持ち込むおそれがあります。AMIから起動するEC2の全体像はAmazon EC2の仕組みと料金モデルを参照してください。

AWS公式AMIの最新IDをSSMパラメータで取得して起動する手順

AWSのAMIはパッチを当てるたびに新しいIDで公開されます。IDを設定ファイルに直書きすると、古いAMIを使い続ける原因になります。

Amazon Linux 2023の最新AMI IDを取得するSSMコマンド

Amazon EC2でのAL2023の手順では、/aws/service/ami-amazon-linux-latest/ 配下のパラメータを使います。標準版は al2023-ami-kernel-default-x86_64、最小構成版は al2023-ami-minimal-kernel-default-x86_64、Graviton向けは末尾が arm64 です。

# 1) 東京リージョンの最新AL2023（x86_64・標準版）のAMI IDを確認する
aws ssm get-parameter \
  --region ap-northeast-1 \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query "Parameter.Value" --output text

# 2) IDを書かずに、パラメータ名のまま起動する（resolve:ssm: で起動時に解決される）
aws ec2 run-instances \
  --region ap-northeast-1 \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --instance-type t3.micro \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0

CloudFormationでは、パラメータの型を AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> にすると、スタックの作成と更新のたびに最新のIDが入ります。インスタンスタイプはx86_64とarm64で選べるものが違うため、インスタンスタイプの選び方と命名規則でアーキテクチャを合わせてください。

2026年8月17日にAL2023の既定カーネルが6.18へ変わった影響

同じページには、2026年8月17日以降、al2023-ami-kernel-default から起動した新しいインスタンスはカーネル6.1ではなく6.18で起動すると書かれています。すでに動いているインスタンスは、起動したときのカーネルのままです。

影響が出るのは、カーネルモジュールを自前でビルドするセキュリティ製品や監視エージェントを入れているサーバーです。Auto Scalingで新しく起動した台だけが6.18になり、エージェントが起動しない事故が起こりえます。検証が終わるまでは al2023-ami-kernel-6.1-x86_64 のような版指定のパラメータを使い、検証後に既定へ戻すのが安全な順番です。

自作AMIを作成・コピー・共有するAWS CLIの具体的な設定手順

アプリケーションやミドルウェアを入れたインスタンスからAMIを作ると、同じ構成のサーバーを数分で起動できます。ここでは作成・コピー・共有の3操作をCLIで示します。

create-imageで再起動ありとno-rebootを使い分ける判断基準

EBS-backed AMIの作成の説明では、EC2は既定でインスタンスを停止して再起動し、整合した状態でスナップショットを取ります。create-imageに --no-reboot を付けると再起動しませんが、その場合はファイルシステムの整合性が保証されません。

# AMIとスナップショットに同じタグを付けて作成し、available になるまで待つ
AMI_ID=$(aws ec2 create-image \
  --region ap-northeast-1 \
  --instance-id i-0123456789abcdef0 \
  --name "web-prod-$(date +%Y%m%d-%H%M)" \
  --description "web server image" \
  --tag-specifications \
    'ResourceType=image,Tags=[{Key=Role,Value=web},{Key=Owner,Value=infra}]' \
    'ResourceType=snapshot,Tags=[{Key=Role,Value=web},{Key=Owner,Value=infra}]' \
  --query ImageId --output text)

aws ec2 wait image-available --region ap-northeast-1 --image-ids "$AMI_ID"
echo "$AMI_ID"

本番のデータベースが動いているサーバーで --no-reboot を使うのは避けるべきです。書き込み途中のデータがスナップショットに入り、起動しても壊れたファイルが残ることがあります。再起動できないサーバーでは、アプリケーションを止めるか、データをEBSから切り離してからスナップショットを取る手順が必要です。作成には数分、大きなボリュームでは最大24時間かかることがあります。

copy-imageで東京から大阪へ暗号化付きでコピーする手順

AMIのコピーは、コピー先のリージョンで実行します。起動許可はコピーされず、ユーザーが付けたタグも --copy-image-tags を指定しない限り引き継がれません。

# コピー先（大阪 ap-northeast-3）で実行し、スナップショットをKMSキーで暗号化する
aws ec2 copy-image \
  --region ap-northeast-3 \
  --source-region ap-northeast-1 \
  --source-image-id ami-0123456789abcdef0 \
  --name web-prod-dr \
  --copy-image-tags \
  --encrypted \
  --kms-key-id alias/dr-ami-key

完了時刻を指定しないコピーは無料ですが、コピー先にもスナップショットができるため、保存料金は2リージョン分になります。完了時間を15分から48時間の範囲で指定する時間ベースのコピーは有料で、東京では完了時間に応じて1GBあたり0.005〜0.020ドルです。災害対策でコピーする場合、復旧の目標時間に余裕があるなら時間指定は要りません。

AMIの特定アカウントへの共有とパブリック公開を防ぐ設定の確認手順

特定のAWSアカウントとのAMIの共有では、起動許可の launchPermission にアカウントIDを追加します。共有された側は起動だけができ、AMIの削除や変更はできません。

# 開発アカウント（111122223333）にだけ起動を許可する
aws ec2 modify-image-attribute \
  --region ap-northeast-1 \
  --image-id ami-0123456789abcdef0 \
  --launch-permission "Add=[{UserId=111122223333}]"

# アカウントでAMIのパブリック公開がブロックされているかを確認する
aws ec2 get-image-block-public-access-state --region ap-northeast-1

暗号化したスナップショットを持つAMIを共有するときは、共有先にKMSキーの利用権限も渡す必要があります。AMIのパブリックアクセスのブロックは、新しいアカウントでは既定で有効です。ただし2023年7月15日以降に一度でもパブリックAMIを持ったアカウントでは無効のままなので、上のコマンドで状態を確かめてください。設定はリージョンごとに必要です。

AMIの料金は東京で1GBあたり月0.05ドルかかるスナップショットの実額

AMIの請求は、AMIという項目では出てきません。請求書ではEBSスナップショットの保存料金として計上されます。

AMI本体は無料でもEBSスナップショットが課金される仕組みと増分保存

Amazon EBSの料金ページの説明では、ボリュームの初回のスナップショットはデータの完全なコピーを保存し、2回目以降は変更された部分だけを保存します。課金はボリュームのサイズではなく、実際に保存されたデータ量で決まります。

課金項目（東京） 単価
スナップショットの保存（標準） 0.05ドル／GB月
アーカイブ層での保存 0.0125ドル／GB月
アーカイブからの取り出し 0.03ドル／GB
90日未満でアーカイブを削除 残り期間分を0.0125ドル／GB月
時間ベースのコピー 0.005〜0.020ドル／GB

使用中のデータが8GBのルートボリュームなら、最初のAMIは月0.4ドル前後です。毎日AMIを作って90世代残すと、変更分が積み上がって数十GBに膨らみます。スナップショットのアーカイブは保存単価が4分の1ですが、最低90日の保存と取り出し料金があるため、年に数回しか使わない監査用のAMIに限って使います。

Price List APIで東京のスナップショット単価を確かめるPythonコード

料金ページの地域別の表はブラウザ側で描画されるため、単価をプログラムで読むにはPrice List APIを使います。EC2のオファーファイルは東京リージョン単体でも数百MBあるので、メモリに余裕のある環境で実行してください。

# 東京リージョンのEBSスナップショット関連の単価をAWS Price List API（AmazonEC2）から取得する
import json, urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
def get(path):
    with urllib.request.urlopen(BASE + path, timeout=900) as r:
        return json.load(r)

idx = get("/offers/v1.0/aws/AmazonEC2/current/region_index.json")
offer = get(idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("version", offer["version"])

for sku, p in offer["products"].items():
    usage = p["attributes"].get("usagetype", "")
    if not usage.startswith("APN1-EBS:Snapshot"):
        continue
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            print(usage, dim["pricePerUnit"]["USD"], dim["unit"])

# 出力例（2026-10-01取得・version 20260925174521）
# APN1-EBS:SnapshotArchiveRetrieval 0.0300000000 GB
# APN1-EBS:SnapshotUsage.outposts 0.0270000000 GB-Mo
# APN1-EBS:SnapshotArchiveStorage 0.0125000000 GB-Mo
# APN1-EBS:SnapshotUsage 0.0500000000 GB-Mo
# APN1-EBS:SnapshotArchiveEarlyDelete 0.0125000000 GB-Mo

SnapshotUsage が通常のスナップショット、SnapshotArchiveStorage がアーカイブ層の単価です。Cost Explorerでも同じ使用タイプ名で絞り込めるので、AMIの棚卸しの前後で請求額がどれだけ減ったかを追えます。

使われていないAMIの参照元を確認し登録解除するまでの運用手順

AMIの無駄は、作ったまま誰も起動していないAMIと、AMIを消したあとに残ったスナップショットから生まれます。一覧を作ってから消す順番を守ります。

LastLaunchedTimeで180日以上起動されていないAMIを一覧にするコマンド

AMIが最後に使用された日時の確認によると、EC2はAMIから最後にインスタンスを起動した日時を LastLaunchedTime として記録しています。記録は2017年4月以降が対象で、反映には24時間の遅れがあり、値を見られるのはAMIの所有者だけです。

# 自分のAMIのうち、最終起動が180日より前、または一度も起動していないものを一覧にする
CUTOFF=$(date -u -d '180 days ago' +%Y-%m-%dT%H:%M:%SZ)

aws ec2 describe-images --owners self --region ap-northeast-1 \
  --query "Images[].[ImageId,CreationDate,LastLaunchedTime || 'never',Name]" \
  --output text |
  awk -F'\t' -v cutoff="$CUTOFF" '$3 == "never" || $3 < cutoff'

macOSの date では -d が使えないため、date -u -v-180d +%Y-%m-%dT%H:%M:%SZ に置き換えてください。一覧に出たAMIでも、起動テンプレートやAuto Scalingグループから参照されていることがあります。削除前の確認対象は、起動テンプレートの ImageId と、削除候補のAMI IDが一致しているかどうかです。CLIの認証設定はAWS CLI v2の設定とSSO認証で解説しています。

AMI登録解除時に関連スナップショットも削除する指定と残存分の確認手順

deregister-imageは、既定ではAMIだけを消し、スナップショットを残します。--delete-associated-snapshots を付けると同時に削除されますが、別のAMIからも参照されているスナップショットは消えません。

# AMIを登録解除し、関連スナップショットも削除する（結果は DeleteSnapshotResults で返る）
aws ec2 deregister-image --region ap-northeast-1 \
  --image-id ami-0123456789abcdef0 \
  --delete-associated-snapshots

# 過去に登録解除だけしたAMIのスナップショット（孤立スナップショット）を探す
aws ec2 describe-images --owners self --include-disabled --region ap-northeast-1 \
  --query "Images[].BlockDeviceMappings[].Ebs.SnapshotId" --output text |
  tr '\t' '\n' | sort -u > ami_snaps.txt
aws ec2 describe-snapshots --owner-ids self --region ap-northeast-1 \
  --filters "Name=description,Values=Created by CreateImage*" \
  --query "Snapshots[].[SnapshotId,VolumeSize,StartTime]" --output text |
  sort > image_snaps.txt
join -v1 image_snaps.txt ami_snaps.txt

結果の ReturnCode が skipped なら、他のAMIが同じスナップショットを使っています。AMIの登録解除の説明では、create-imageで作られたスナップショットの説明欄は「Created by CreateImage(インスタンスID) for AMI ID」という形式です。2本目のコマンドはこの形式を手がかりに、どのAMIからも参照されていないものだけを表示します。

非推奨・無効化・登録解除保護・ごみ箱の4段階で誤削除を防ぐ設計

AMIを止める操作は、強さの違う4種類があります。いきなり登録解除せず、段階を踏むと事故が減ります。

操作 新規の起動 課金
非推奨化 IDを指定すれば可能 継続
無効化（disable-image） 不可・共有も解除 継続
登録解除 不可 スナップショットを残すと継続
ごみ箱から復元 保持期間内なら戻せる 保持中も課金

AMIの非推奨化を enable-image-deprecation で行うと一覧に表示されなくなるだけで、起動テンプレートからは引き続き起動できます。AMIの無効化を行うと起動許可がすべて外れ、関連スナップショットは削除できなくなります。

本番の起動テンプレートが使うAMIには、登録解除保護を aws ec2 enable-image-deregistration-protection --image-id ami-... --with-cooldown で付けます。保護を外しても24時間は登録解除できないため、権限を奪われた場合でも、その間の削除を防ぐことが可能です。さらにごみ箱の保持ルールを作っておけば、登録解除したEBS-backed AMIを保持期間内に戻せます。ごみ箱の利用料は無料ですが、中にあるスナップショットには通常と同じ保存料金がかかります。

自作AMIを焼くか起動時に構成するかの判断と許可するAMIの絞り込み

AMIは便利ですが、作るほど管理対象が増えます。作るべき場面と、作らずに済ませる場面を分けて考えます。

ゴールデンイメージを作るべき条件とユーザーデータで足りる場面

自作AMI（ゴールデンイメージ）を作るべきなのは、Auto Scalingで台数が増減し、起動からサービス開始までを数分以内に収めたい場合です。パッケージの導入に10分かかる構成を毎回ユーザーデータで組むと、負荷が急に増えたときに台数の追加が間に合いません。

逆に、1〜2台を長く動かすだけのサーバーなら、AWSのAMIに起動時のスクリプトで設定を入れる方が管理は楽です。自作AMIはOSのパッチが出るたびに作り直す必要があり、手作業で作ると更新が止まります。作るなら、EC2 Image Builderのパイプラインで定期的に作り直すか、Packerによるマシンイメージの自動構築でコード化してください。Image Builder自体は無料で、構築に使うインスタンスとスナップショットの料金だけがかかります。作ったAMIの脆弱性はAmazon Inspectorの対応スキャンで確認できます。

Allowed AMIsの監査モードで社内に許可するAMI提供元を限定する手順

許可されたAMI（Allowed AMIs）は、アカウントの利用者が見つけて起動できるAMIを、提供元や名前、作成からの日数で絞る機能です。対象は公開AMIと共有AMIで、自分のアカウントで作ったAMIは常に使えます。

  1. ImageProviders に amazon と、社内でAMIを配るアカウントIDを並べた条件を作る
  2. 状態を audit-mode にして、describe-images の ImageAllowed で影響を確かめる
  3. 許可外のAMIで動くインスタンスを describe-instance-image-metadata で探し、起動テンプレートを直す
  4. 問題がなければ enabled に切り替える。設定はリージョンごとに行う

ECSやEKSを使っている場合は、これらがAWSのAMIに依存するため、amazon を必ず許可に含めます。作成日数の条件を数日に絞ると、AMIの更新が遅れた日に起動が失敗するので、厳しくしすぎないことが要点です。

AMIをバックアップ代わりにしない：AWS Backupへ任せる判断

サーバーの日次バックアップとしてAMIを作り続ける運用は、世代の削除を誰かが忘れた時点でスナップショットが積み上がります。保持期間の管理と復元の記録が必要なら、AWS Backupのバックアッププランと復元手順に任せてください。AWS Backupが作ったAMIはEC2側から登録解除できず、復旧ポイントとしてまとめて管理されます。

役割分担は、「起動の雛形はAMI、データの復元はAWS Backup」と決めてしまってよいでしょう。日次のAMI作成スクリプトが何年も動き続け、スナップショットの請求が膨らんだ環境の棚卸しから設計し直したい場合は、AWS・Google Cloud・Azureのインフラ構築でご相談ください。

よくある質問

AWSのAMIについて、作成と運用の場面でよく出る質問に答えます。

AMIとスナップショットの違いは何ですか？

スナップショットは1つのEBSボリュームの内容を保存したものです。AMIは、1つ以上のスナップショットに、ブロックデバイスマッピングや起動許可、アーキテクチャなどの情報を加えた「起動できるイメージ」です。スナップショットだけではインスタンスを起動できず、register-image でAMIとして登録して初めて起動に使えます。AMIを消してもスナップショットは既定では残る点が、両者の関係で最も間違えやすいところです。

AMIの作成中にインスタンスは止まりますか？

既定では止まります。EC2はインスタンスを再起動し、ボリュームへの書き込みがない状態でスナップショットを取ります。--no-reboot を付ければ止まりませんが、ファイルシステムの整合性は保証されません。XFSのように書き込みを一時停止できるファイルシステムなら再起動なしでも安全に取れるとされています。データベースを動かすサーバーでは再起動ありで取るか、アプリケーションを止めてから作成してください。

AMIを削除してもスナップショットの料金がかかるのはなぜですか？

登録解除は既定でAMIだけを消し、スナップショットを残すためです。残ったスナップショットには東京で1GBあたり月0.05ドルの保存料金がかかり続けます。登録解除するときは --delete-associated-snapshots を付けるか、コンソールで「関連付けられたスナップショットを削除」にチェックを入れてください。過去に消し忘れた分は、説明欄の「Created by CreateImage」を手がかりに探せます。

AMIを別のリージョンやアカウントで使うにはどうすればよいですか？

別のリージョンでは copy-image でコピーし、新しいAMI IDを使います。別のアカウントへの共有で必要なのは、modify-image-attribute による共有先アカウントへの起動許可の追加です。共有先がさらに別のリージョンで使いたい場合は、共有されたAMIを共有先のアカウントでコピーします。暗号化したAMIは、KMSキーの利用権限も共有先に渡さないと起動できません。

AWS公式のAMIが非推奨になると、動いているインスタンスは止まりますか？

止まりません。非推奨になったAMIから起動済みのインスタンスは、停止・起動・再起動を通常どおり行えます。非推奨のAMIは一覧に表示されなくなりますが、AMI IDを直接指定すれば、新しいインスタンスの起動も可能です。ただしAL2023のAMIは90日で非推奨になるため、古いIDを固定した起動テンプレートはパッチが当たっていないOSで起動し続けます。SSMパラメータで最新のIDを引く構成に切り替えてください。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2024.07.11　テックブログ PEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）
  2. 2026.09.28　テックブログ タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計
  3. 2026.09.27　コラム 法定調書合計表とは？令和8年分の書き方と提出義務、給与・支払データからの集計自動化
  4. 2026.03.24　テックブログ EARS記法とは？5つの基本型と複合型の書き方・日本語例文・Kiroでの使い方
  5. 2026.09.30　テックブログ OpenAI Dotsとは？常時稼働エージェントの権限設計と自社システム接続【2026年9月】

RELATED POSTS 関連記事

一覧へ戻る

目次