Amazon EC2 Image Builder入門｜AMI自動ビルドとゴールデンイメージ管理でオンプレ運用の「手作業」を排除する実践ガイド

AMI管理、まだ手で変更していませんか？

「EC2インスタンスにSSHでミドルウェアをインストールして、スナップショットを取って、AMIを作って、リリース先のリージョンにコピーして…」

オンプレミスでゴールデンイメージを手作業で整備してきたエンジニアなら、クラウドに移行してからも似た運用を続けているケースは少なくありません。手動運用は最初こそ素早く回せますが、AMIの数が増えるにつれて「どのAMIが最新か」「誰が何を入れたか」「テストは通っているか」という疑問が重なっていきます。

この記事では、そのAMI作成から配布・テストまでをパイプライン化してくれる Amazon EC2 Image Builder について、オンプレ経験者にもわかりやすく解説します。カバーする内容は以下のとおりです。

・なぜEC2 Image Builderが必要なのか（手動運用の限界）
・基本構成（コンポーネント・レシピ・パイプライン）
・パイプライン作成の実践手順
・料金体系とコスト試算
・マルチリージョン配布・テスト自動化などの実務Tips
・よくあるトラブルと対処法

なぜEC2 Image Builderなのか？（手動AMI運用の限界）

オンプレ環境でのゴールデンイメージ管理は、多くの現場でこんな流れを踏んでいます。

・ベースOSのVMをクローン
・ミドルウェアや設定を手動で適用
・確認したらスナップショット取得
・テンプレートとしてライブラリに登録

クラウドでも「ベースAMIからEC2を起動→SSHで変更→AMIをCreate→古いものをDeregister」という手順は変わりません。問題はここからです。

・再現性がない: 誰がどのコマンドを打ったか履歴が残りにくい
・テストが属人化する: 動作確認を自分の目で見ているだけで自動化されていない
・マルチリージョン展開が面倒: AMIコピーを手動でリージョン数だけ繰り返す
・古いAMIが残り続ける: クリーンアップのルールがなければEBSスナップショット課金が積み重なる

EC2 Image Builderはこれらを 「定義→ビルド→テスト→配布」という1本のパイプライン に収めます。パイプラインはスケジュール実行や手動トリガーに対応し、実行ログはAmazon CloudWatch Logsに流れるため、監査証跡としてもそのまま使えます。

EC2 Image Builderの基本構成

EC2 Image Builderは5つの概念で成り立っています。順番に把握しておくと設計がスムーズになります。

1. コンポーネント（Component）

AMIに適用する「作業ステップ」の単位です。YAML形式で記述し、buildフェーズ（インストール・設定）とtestフェーズ（動作確認コマンドの実行）に分けて定義できます。AWSが公式に提供するマネージドコンポーネント（Amazon Linux向けの強化設定、Docker CE インストール等）も多数用意されており、自前の作業と組み合わせて使えます。

# コンポーネントYAMLの基本構造（例: Nginxのインストールと起動確認）
name: InstallNginx
description: Install and start Nginx
schemaVersion: 1.0

phases:
  - name: build
    steps:
      - name: InstallNginx
        action: ExecuteBash
        inputs:
          commands:
            - amazon-linux-extras install nginx1 -y
            - systemctl enable nginx
            - systemctl start nginx
  - name: test
    steps:
      - name: CheckNginx
        action: ExecuteBash
        inputs:
          commands:
            - systemctl is-active nginx

2. レシピ（Recipe）

ベースAMIと複数のコンポーネントを組み合わせる「設計図」です。レシピには AMIレシピ（EC2インスタンスを経由してAMIを作成）と コンテナレシピ（DockerイメージをECRに格納）の2種類があります。本記事ではAMIレシピを扱います。

3. パイプライン（Pipeline）

レシピ・インフラ設定・ディストリビューション設定を束ねて「いつ・どこで・どう配布するか」を管理します。定期実行（cronスタイル）と手動トリガーを選べます。

4. インフラストラクチャ設定（Infrastructure Configuration）

ビルド時に一時的に起動するEC2インスタンスのスペックや、IAMロール・VPCサブネットを指定します。ビルドが終わるとこのインスタンスは自動で削除されます。

5. ディストリビューション設定（Distribution Configuration）

ビルドしたAMIをどのリージョンに、どのAWSアカウントに配布するかを定義します。ここがマルチリージョン展開を自動化するキーになります。

パイプラインの作成手順

AWSマネジメントコンソールの「EC2 Image Builder」から作成します。「Create image pipeline」ウィザードを使うのが最初は把握しやすいです。ここでは概念と主な選択肢を中心に解説します。

1. コンポーネントを作成する

「Components」→「Create component」でYAMLを貼り付けます。phasesをbuildとtestに分けて書くことがポイントです。testフェーズの終了コードが0以外ならビルド全体が失敗扱いになり、壊れたAMIの配布を自動的に止めてくれます。

注意点として、コンポーネントYAMLはバージョン管理されます。既存コンポーネントを更新したい場合は新バージョンを作成し、レシピ側でバージョン指定を変更するという手順になります（インプレース更新はできません）。

2. イメージレシピを作成する

「Image recipes」→「Create image recipe」へ進みます。主な設定項目は次のとおりです。

・Base image: Amazon Linux 2023 / Amazon Linux 2 / Windows Server 等のベースAMIを選択。「Always build off the latest version」にチェックを入れると、ベースAMIがAWSから更新されるたびに自動で最新版を使います
・Components: 追加したいコンポーネントを順番に並べる。AWSマネージドのものと自作のものを混在させてOK
・Working directory: コンポーネントのコマンドが実行されるディレクトリ（デフォルトは /tmp/imagebuilder）
・Systems Manager agent: インストール有無（後述のSSM連携に使うため、基本的に有効のままにしておく）

3. パイプラインを設定・実行する

「Image pipelines」→「Create image pipeline」のウィザードを進めます。ウィザード内でレシピ・インフラ設定・ディストリビューション設定を紐付けます。

スケジュールは「Weekly」「Daily」「Custom cron」などから選択できます。OSベンダーのパッチ公開サイクルに合わせて毎週火曜の夜間にビルドを走らせる、といった設定が現場では多く使われます。

ウィザード完了後、「Run pipeline」ボタンで手動実行できます。初回実行でビルドインスタンスが立ち上がり、コンポーネントが順に適用され、testフェーズが全通過するとAMIが作成・登録されます。ログはCloudWatch Logsの /aws/imagebuilder/ ロググループに流れます。

# AWS CLI でパイプラインを手動実行する（東京リージョンの例）
aws imagebuilder start-image-pipeline-execution \
  --image-pipeline-arn arn:aws:imagebuilder:ap-northeast-1:123456789012:image-pipeline/my-pipeline \
  --region ap-northeast-1

# パイプライン実行状況の確認
aws imagebuilder list-image-pipeline-images \
  --image-pipeline-arn arn:aws:imagebuilder:ap-northeast-1:123456789012:image-pipeline/my-pipeline \
  --region ap-northeast-1

料金の仕組み（コスト感覚）

EC2 Image Builder自体のサービス利用料は無料です。費用が発生するのは以下のリソースです（2026年9月時点）。

典型的なビルドは20～40分程度で完了します。t3.mediumで1回あたりのEC2費用は$0.03程度です。週次で自動実行しても月$0.1程度に収まります。コストの大半はAMIのスナップショット保管なので、古いバージョンを自動で削除するポリシーを設けることが重要です（後述）。

実務Tips

1. testコンポーネントで「壊れたAMI」を本番に流さない

buildフェーズだけで終わるコンポーネントを使っている場合、「インストールは通ったが起動しない」「ポートが空いていない」といった問題がビルド後まで見えないことがあります。testフェーズに確認コマンドを入れることで、AMI登録前に壊れたイメージを自動で弾けます。

・サービスの起動状態確認（`systemctl is-active `）
・ポートのリッスン確認（`ss -tlnp | grep `）
・バージョンチェック（`nginx -v` 等）
・設定ファイルの構文チェック（`nginx -t` / `httpd -t`）

testコンポーネントの終了コードが1以上になると、EC2 Image BuilderはそのビルドをFAILEDと判定し、AMIを作成しません。SNS通知をパイプライン設定に紐付けておくと、失敗時に即時アラートを飛ばせます。

2. マルチリージョンへのAMI配布を自動化する

ディストリビューション設定の「Target regions」に配布先リージョンを追加するだけで、ビルド完了後に自動でAMIコピーが走ります。たとえば東京リージョン（ap-northeast-1）でビルドして大阪リージョン（ap-northeast-3）にも配布したい場合は、ディストリビューション設定に両リージョンを記述します。

各リージョンに配布先アカウントのIDも指定できるため、マルチアカウント環境での組織全体への配布もここで完結します。このアプローチはAWS Organizationsでアカウントを管理している環境と相性が良いです。

3. Systems Manager・AWS Configと組み合わせる

EC2 Image BuilderはAWS Systems Manager（SSM）エージェントが動作する前提で設計されています。AMIにSSMエージェントを含めておくことで、デプロイ後のEC2インスタンスに対してSession ManagerでSSH不要の接続やSSM Patch Managerによる定期パッチ適用が使えます。

また、AWS Configのカスタムルールと組み合わせると「古いバージョンのAMIから起動しているEC2がある」という構成変更を自動検知できます。Image Builderで新AMIを定期生成しつつ、AWS Configで古いAMIを使ったインスタンスを通知する仕組みにすると、ゴールデンイメージの鮮度管理が自然に回るようになります。

4. 古いAMIの世代管理とクリーンアップ

生成し続けると、AMIのEBSスナップショット費用が蓄積します。ディストリビューション設定の「Deprecation time」を設定することで古いAMIに廃止フラグを立てられますが、実際の削除はLambdaやEventBridgeを組み合わせた別処理が必要です。

よく使われるのは、Image Builderパイプラインが成功したら古い世代のAMIをDeregisterするLambdaを呼ぶパターンです。保持世代数を「最新3世代」に固定しておくと、スナップショット費用を一定以下に抑えられます。

よくあるトラブルと対処法

EC2 Image Builderを最初に触るエンジニアが引っかかりやすい点を整理します。

・ビルドインスタンスがタイムアウトする: デフォルトのビルドタイムアウトは720分（12時間）ですが、大きなパッケージのインストールや大量の設定適用が重なるとタイムアウトする場合がある。インフラストラクチャ設定の「Build timeout minutes」を実態に合わせて調整する
・コンポーネントがFAILEDになる: CloudWatch Logsの /aws/imagebuilder/ ロググループを確認する。コマンドの終了コードが0以外になっていることがほとんど。amazon-linux-extrasコマンドはAmazon Linux 2専用のため、AL2023では使えない点に注意
・IAMロールの権限不足: ビルドインスタンスのインスタンスプロファイルに EC2InstanceProfileForImageBuilder と AmazonSSMManagedInstanceCore の2つのポリシーが最低限必要。S3からコンポーネントYAMLを読む場合はS3への読み取り権限も追加する
・AMIが指定リージョンにコピーされない: ディストリビューション設定に配布先リージョンが含まれているか再確認する。マルチアカウントの場合は配布先アカウントでEC2 Image Builderが利用可能なリージョンかも確認が必要
・Windows AMIのビルドが極端に遅い: WindowsはLinuxより初期化処理（sysprep）に時間がかかる（30分以上）。タイムアウト設定を余裕を持って設定する

本記事のまとめ

Amazon EC2 Image Builderで解決できる課題と手段を整理します。

サービス自体の費用は無料で、ビルドに使うEC2の稼働時間（1回あたり数十円程度）だけかかります。既存の手動AMI運用と比較すると、運用コストの削減と品質の安定化が同時に期待できます。

まず1つのコンポーネントから試してみて、週次スケジュールでゴールデンイメージを自動更新する仕組みを少しずつ育てていくのがお勧めです。