コンピューティング・ 2026-05-11

EC2 Image Builder とは？AMI ビルドを自動化するパイプライン構築

EC2 Image Builder は AMI の作成・テスト・配布を自動化するマネージドサービス。Component（YAML）→ Recipe → Pipeline の 3 段構造で、定期実行・脆弱性スキャン・マルチリージョン配布までを 1 本のワークフローに統合できる。

#AWS #EC2 #AMI #Image-Builder #コンピューティング

AMI を「手で焼く」運用を卒業し、定期実行・脆弱性スキャン・配布まで全部マネージドに任せる仕組み。

1. 概要（端的に）

EC2 Image Builder は AMI の作成・テスト・配布パイプラインをフルマネージドで提供するサービス。ベース AMI に対して「何をインストールし、何をテストし、どこに配布するか」を YAML で宣言しておけば、Image Builder が EC2 を一時起動して構築 → テスト → AMI 化 → 後始末まで自動で実行する。サービス自体は無料（裏で動く EC2・EBS のみ課金）。

2. 何ができるか

AMI 自動ビルド：ベース AMI に対してパッチ適用・ソフト導入を自動実行
定期スケジュール：「毎週月曜 03:00」「最新パッチがリリースされたら」等で再ビルド
脆弱性スキャン：Amazon Inspector と連携して CVE をブロック判定
テスト自動化：ビルド後の AMI で起動 → テスト用 EC2 で品質確認
マルチリージョン配布：1 回のビルドで複数リージョンへ自動コピー
マルチアカウント共有：Organizations 配下の AWS アカウントへ共有
コンテナイメージ対応：ECR への Docker イメージビルドも可能
タグ・暗号化制御：KMS による暗号化や任意タグの一括付与

3. 特徴

観点	特徴
料金	サービス利用料は無料（ビルド中の EC2・EBS のみ課金）
ビルド環境	一時的に立ち上がる EC2 で実行（終了後に自動削除）
言語	Component は YAML で記述
対応 OS	Amazon Linux 2/2023・Ubuntu・RHEL・Windows Server 各種
テスト	AWS-TOE（Task Orchestrator and Executor）でビルド・検証を統合
配布先	AMI / コンテナイメージ（ECR）
連携	EventBridge / SNS / Systems Manager / IAM / Inspector

Packer との位置付け

EC2 Image Builder vs Packer

評価項目	EC2 Image Builder 推奨	HashiCorp Packer
提供形態	AWS マネージドサービス	OSS（自前で実行環境を用意）
料金	無料（EC2/EBS 実費のみ）	OSS は無料／実行環境は自前負担
対応クラウド	AWS 中心	マルチクラウド
テスト統合	組み込み（AWS-TOE）	別途仕組みが必要
配布の自動化	リージョン/アカウントへ自動配布	自前で実装
スケジュール実行	ビルトイン	CI/CD と組み合わせ
学習コスト	AWS だけで完結し低め	CI/CD・複数 Provider 知識が必要

AWS 単一クラウド前提なら Image Builder、マルチクラウドなら Packer。

AWS 単一クラウド前提なら Image Builder が運用負荷を最小化できる。マルチクラウドで AMI / VM イメージを統一管理したい場合は Packer に分がある。

4. 仕組み

Image Builder は次の 4 つの構成要素を組み合わせて「Pipeline」を作る。

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

ビルド／テストで実行するスクリプトを YAML で定義した最小単位。「nginx を入れる」「ウイルス対策ソフトを入れる」「OS パッチを当てる」など機能ごとに分割しておくと再利用しやすい。

name: InstallNginx
schemaVersion: 1.0
phases:
  - name: build
    steps:
      - name: InstallPackage
        action: ExecuteBash
        inputs:
          commands:
            - sudo dnf install -y nginx
            - sudo systemctl enable nginx

AWS マネージドコンポーネント（最新パッチ適用・CIS ベンチマーク適用等）も用意されており、組み合わせるだけでセキュリティ要件を満たしやすい。

4-2. Image Recipe（レシピ）

「ベース AMI + 適用する Component 群 + ブロックデバイスマッピング」を束ねた AMI の設計図。レシピはバージョン管理され、変更のたびに新バージョンを発行する。

4-3. Infrastructure Configuration（実行基盤）

ビルド時に一時起動する EC2 の設定（インスタンスタイプ・サブネット・IAM ロール・SNS 通知先など）。

4-4. Distribution Configuration（配布設定）

完成 AMI を どのリージョン・どのアカウントに配布するか、暗号化キー・起動許可・タグを定義する。

実行フロー

Image Pipeline 実行
   ↓
① ベース AMI から一時 EC2 を起動
   ↓
② Build Component を順に実行（パッチ・パッケージ導入）
   ↓
③ 一時 EC2 から AMI を作成
   ↓
④ 作成 AMI から再度 EC2 を起動（テスト用）
   ↓
⑤ Test Component を実行（ヘルスチェック・脆弱性検査）
   ↓
⑥ Inspector による脆弱性スキャン（オプション）
   ↓
⑦ Distribution Configuration に従い AMI を配布
   ↓
⑧ 一時 EC2 を自動削除

ビルドが失敗した場合、AMI は配布されずに止まる。EventBridge / SNS で通知を受け取って再ビルドを促す設計が定石。

5. ユースケース

ユースケース 1：ゴールデン AMI の継続的更新

セキュリティパッチ・監視エージェント・基盤ライブラリ入りの Golden Image を毎週再生成。Auto Scaling グループの起動テンプレートが参照するため、新規 EC2 は常に最新の Golden AMI から起動される。

ユースケース 2：脆弱性スキャン込みのリリースゲート

Inspector を Test フェーズに組み込み、Critical / High の CVE があれば配布をブロック。検査をパスした AMI のみが本番アカウントに届く。

ユースケース 3：マルチリージョン DR 構成

東京で 1 回ビルドすれば、Distribution Configuration によって大阪・シンガポール・バージニア北部に AMI を自動配布。DR 切替時はターゲットリージョンで起動するだけ。

ユースケース 4：マルチアカウントへのベース AMI 配布

セキュリティチームがビルドした「全社標準 AMI」を Organizations 配下の各事業部アカウントへ自動共有。事業部側は標準 AMI を選ぶだけでガードレールに準拠できる。

ユースケース 5：コンテナイメージのビルド統一

EC2 と同じ Component 群を流用してコンテナイメージを ECR に発行。VM とコンテナの構成差異を最小化する運用パターン。

6. メリット・デメリット

7. ベストプラクティス

AWS マネージドコンポーネントを優先的に採用：自前で書く YAML を最小化する。
Component は機能単位で小さく：nginx 導入と監視エージェント導入は分ける。バージョン管理がしやすい。
テスト Component を必ず 1 つは入れる：「サービスが立ち上がるか」だけでも自動検証する。
Inspector スキャンを Test フェーズに組み込む：脆弱性混入を配布前にブロック。
配布リージョンを最小限に絞る：未使用リージョンへの配布はストレージコストの無駄。
タグ戦略を Distribution Configuration で統一：CostExplorer での AMI 別コスト追跡が容易になる。

8. 関連用語

EC2 — Image Builder が一時起動するビルド対象
AMI — Image Builder が生成する成果物
EC2 Auto Scaling — Golden AMI を参照する起動テンプレートで活用
Inspector — ビルド AMI の脆弱性スキャン連携
Systems Manager — Component で参照する SSM ドキュメントや Parameter Store
EventBridge — ビルド失敗・成功イベントの通知ハブ
CloudFormation — Pipeline 全体を IaC 化する標準手段

9. 関連サイト

AWS 公式

参考記事

🎓 試験での出題傾向

試験	重要度	主な出題パターン
CLF	中	AMI 自動化の概念、マネージドサービスの位置付け
SAA	高	Golden AMI 運用、マルチリージョン DR、Inspector との統合
DVA	中	コンテナイメージビルド、CI/CD との連携
SOA	高	定期スケジュール、パッチ運用、ログ集約、失敗時通知設計

特に SAA では「Golden Image を継続的に更新したい」「マルチリージョンに同一 AMI を配布したい」場面で Image Builder を選ぶ問題が定番。Packer を選ばせる引っかけにも注意。