EC2 Image Builder

解決する課題

社内標準の「ゴールデンAMI」を手作業で作ると、毎回EC2を起動して、パッケージを入れ、設定し、スナップショットを取り…という手順書運用になりがちです。これは再現性が低く、属人化し、OSの脆弱性が出るたびに作り直す手間も大きくなります。EC2 Image Builderはこの一連の流れをパイプライン化します。

• イメージの作成手順をコードとして定義し、誰が実行しても同じ結果を得る
• 定期実行で最新のOSパッチを取り込み、イメージを常に新鮮に保つ
• ビルドしたイメージに自動テストを実施し、合格したものだけを配布する

主要概念と用語

• イメージパイプライン: ビルドからテスト・配布までを束ねる自動化の単位。スケジュール実行やトリガー実行ができる
• イメージレシピ: どのベースイメージに、どのコンポーネントを、どの順で適用するかを定義したもの（AMI向け）
• コンテナレシピ: ベースのコンテナイメージとDockerfile、適用するコンポーネントを定義したもの（コンテナ向け）
• コンポーネント: ソフトのインストールや設定、テストを記述した再利用可能な部品。宣言的な YAML または JSON 文書で定義し、AWSTOE が実行する
• ビルドコンポーネントとテストコンポーネント: 前者はイメージを構築する処理、後者はビルド結果を検証する処理
• 配布設定（ディストリビューション設定）: 完成したイメージをどのリージョン・どのアカウントへ展開し、誰と共有するかの定義
• インフラストラクチャ設定: ビルド作業を実行する一時的なEC2インスタンスの種類やサブネット、IAMロールなどの定義

仕様・制限・クォータ

• 出力できるのはAMIとコンテナイメージ（ECRへ）の2種類
• Windows、Linux 系の主要ディストリビューション、macOS に対応する。実際に選べる版とリージョンは対応表で確認する
• ビルドはユーザーのアカウント内で一時的なEC2インスタンスを起動して実行し、完了後に破棄される
• AMI とコンテナイメージは複数リージョンへ配布できる。AMI はさらに別アカウントや AWS Organizations の組織・OU へ共有またはコピーできる
• 既定クォータは 1 リージョンあたり同時ビルド 100、作成済みコンポーネント 1,000、1 レシピあたりのコンポーネント 20。いずれも引き上げ申請が可能
• ベースとなるOSやコンポーネントの組み合わせには制約があるため、対応状況の確認が必要

内部の仕組み

横にスクロール

パイプラインが起動すると、Image Builder はインフラストラクチャ設定で指定された一時的な EC2 インスタンスをユーザーのアカウント内に立ち上げます。AMI ではビルド用インスタンスへコンポーネントを適用してスナップショットを作り、そのイメージから別のテスト用インスタンスを起動して検査します。コンテナでは一時 EC2 上のコンテナ構築工程で検査します。すべての検査に合格した出力だけが配布設定に従って各リージョンへ進み、一時資源は終了します。

• 作業用インスタンスとの通信や設定取得にはSystems Manager（SSM）が使われる
• ベースイメージ・パッチ・自前のコンポーネントを積み重ねるレイヤー的な発想で、変更箇所だけレシピを差し替えやすい

設計パターン / ベストプラクティス

• ゴールデンAMIパイプライン: 社内標準イメージをパイプライン化し、定期実行で常に最新パッチ済みのAMIを供給する
• テストの作り込み: 単にビルドするだけでなく、ポート疎通やエージェント導入確認などのテストコンポーネントを入れ、不良イメージの配布を防ぐ
• コンポーネントの再利用: ミドルウェア導入やCIS系の堅牢化処理などを共通コンポーネント化し、複数レシピで使い回す
• 配布の集中管理: 1つのパイプラインから全リージョン・全アカウントへ配布し、イメージの分散・ばらつきを防ぐ
• 不変インフラとの連携: 完成AMIを起動テンプレートやAuto Scalingに渡し、パッチは「中で当てる」のではなく「新しいイメージに入れ替える」運用にする

運用・監視

• ビルドログとパイプライン実行ログは既定で CloudWatch Logs の /aws/imagebuilder/ 配下へ送られる。インフラストラクチャ設定で S3 にも保存できる
• ビルドの開始・成功・失敗などのイベントはEventBridgeで受け取れ、通知や後続処理のトリガーにできる
• スケジュール実行に加え、ベースイメージの更新を起点に自動実行する設定も可能
• 配布後の不要になった旧AMIやスナップショットはライフサイクルポリシーで自動的に整理し、コストとクォータの肥大化を防ぐ

コスト

• Image Builder自体のパイプライン管理に追加料金はかからないのが基本で、料金は実行時に使う他サービスの利用分に依存する
• 主な費用は、ビルド用に一時起動するEC2インスタンスの稼働時間と、生成されたAMIのEBSスナップショット、コンテナの場合はECRの保管料
• 複数リージョンへ配布すると、その分スナップショットの保管コストが増える
• コスト削減のポイントは、ビルド用インスタンスを軽量タイプにすること、ビルド頻度を適正化すること、旧イメージを自動削除することの3点

セキュリティ

• ビルド用インスタンスには最小権限のIAMロール（インスタンスプロファイル）を付与し、SSM経由での管理権限を持たせる
• 生成するAMIのEBSスナップショットはKMSによる暗号化を有効にし、配布先アカウントとは鍵の共有を適切に設定する
• パイプラインに定期的なパッチ適用を組み込み、脆弱性を含んだイメージが長期間使われ続けるのを防ぐ
• 配布範囲（共有先アカウントやリージョン）を明示し、意図しないアカウントへイメージが共有されないよう管理する
• ビルド時にAmazon Inspectorと連携させ、生成イメージの脆弱性をスキャンする運用も取れる

Well-Architected の観点

• セキュリティ: パッチ適用と脆弱性スキャンを自動化し、暗号化と最小権限を徹底することで、安全なイメージを継続的に供給できる
• 運用上の優秀性: イメージ作成手順をコード化・バージョン管理し、テストを挟むことで、再現性と品質を担保した自動化された運用を実現する
• 信頼性: テスト合格イメージだけを配布する仕組みが、不良イメージによる障害を未然に防ぐ
• コスト最適化: 旧イメージのライフサイクル管理とビルド頻度の最適化でムダな保管費を抑える

試験で問われるポイント

関連サービス・比較

自前でスクリプトを書く構成管理ツールの定番HashiCorp Packerとしばしば比較されます。

ハンズオン / CLI例

# 既存のイメージパイプラインを一覧表示
aws imagebuilder list-image-pipelines \
  --query "imagePipelineList[].{Name:name,Status:status,Arn:arn}"

# 指定したパイプラインを手動で実行（ビルドを開始）
aws imagebuilder start-image-pipeline-execution \
  --image-pipeline-arn arn:aws:imagebuilder:ap-northeast-1:111122223333:image-pipeline/golden-ami

# レシピやコンポーネントなどのリソース一覧を確認
aws imagebuilder list-image-recipes \
  --query "imageRecipeSummaryList[].{Name:name,Platform:platform,Owner:owner}"