EC2 Image Builder

解決する課題

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

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

主要概念と用語

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

仕様・制限・クォータ

• 出力できるのはAMIと**コンテナイメージ（ECRへ）**の2種類
• WindowsとLinux系の主要ディストリビューションに対応
• ビルドはユーザーのアカウント内で一時的なEC2インスタンスを起動して実行し、完了後に破棄される
• 1つのパイプラインから複数リージョン・複数アカウントへ同時配布できる
• パイプラインやコンポーネントなどのリソースには作成数の上限（クォータ）があり、必要に応じて引き上げ申請が可能
• ベースとなるOSやコンポーネントの組み合わせには制約があるため、対応状況の確認が必要

内部の仕組み

パイプラインが起動すると、Image Builderはインフラストラクチャ設定で指定された一時的なEC2インスタンスをユーザーのアカウント内に立ち上げます。そのインスタンス上でレシピに従いコンポーネントを順に実行してイメージを構築し、続けてテストコンポーネントを走らせます。テストに合格すると新しいAMI（またはコンテナイメージ）が作られ、配布設定に基づいて各リージョン・アカウントへ展開されます。最後に作業用インスタンスは自動的に終了します。

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

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

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

運用・監視

• パイプラインの実行状況やビルドログはCloudWatch Logsに出力され、失敗時の調査に使える
• ビルドの開始・成功・失敗などのイベントは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}"