AWS認定資格 WEB問題集&徹底解説DevOpsエンジニア プロフェッショナル(DOP)

Amazon EC2 Image Builder の概要と試験出題ポイントは?

AWSサービスの一つであるAmazon EC2 Image Builderはどんな内容なのでしょうか?また、AWS認定資格のDevOpsエンジニア-プロフェッショナル(DOP)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか?
ここでは、そんなあなたの疑問に回答していきたいと思います

Amazon EC2 Image Builder 徹底解説 | AWS認定試験の頻出ポイントまとめ

1. サービス概要

Amazon EC2 Image Builderは、Amazon マシンイメージ(AMI)とコンテナイメージの作成・強化・テスト・配布を自動化するフルマネージドサービスです。 ベースイメージにソフトウェアの導入や設定、パッチ適用を加え、テストに合格したイメージだけを指定のリージョンやアカウントへ配布する一連の流れを「イメージパイプライン」として定義し、定期実行できます。

組織で承認済みの標準イメージ(ゴールデンイメージ)を、手作業のスクリプトや自前のビルドサーバーなしで最新かつ安全な状態に保てる点が中心的な価値です。Image Builder 自体の利用料はかかりません。 DOP-C02 ではアーティファクトのビルド自動化とデプロイ戦略、SOA-C03 では AMI・コンテナイメージの作成と管理、SCS-C03 では強化済みイメージによるコンピューティングのセキュリティ統制の文脈で問われます。

2. 主な特徴と機能

2.1 コンポーネント

イメージに加える処理の単位です。YAML / JSON の宣言的な文書で記述し、インスタンス上のアプリケーション AWS TOE(Task Orchestrator and Executor)が実行します。 カスタマイズを行うビルドコンポーネントと、出来上がったイメージを検証するテストコンポーネントがあり、AWS が管理する既製コンポーネント(ソフトウェア導入、OS 更新、再起動テストなど)も利用できます。

2.2 イメージレシピとコンテナレシピ

レシピは「ベースイメージ+適用するコンポーネント」の組み合わせを定義する文書で、セマンティックバージョンで管理されます。AMI 用はイメージレシピ、Docker イメージ用はコンテナレシピです。ベースイメージには既存 AMI、AWS Marketplace の製品、Docker Hub や Amazon ECR のイメージを選べます。

2.3 インフラストラクチャ設定

ビルド・テスト用インスタンスのインスタンスタイプ、IAM インスタンスプロファイル、VPC / サブネット / セキュリティグループ、ログの出力先 S3、通知用の SNS トピック、失敗時にインスタンスを残して調査するかどうかなどを定義します。

2.4 ディストリビューション設定

完成した AMI をどのリージョンへコピーし、どのアカウント・組織・OU に共有するかを定義します。暗号化用の KMS キーの指定、起動テンプレートの自動更新、最新の AMI ID を Systems Manager Parameter Store に書き込む設定、ライセンスの関連付けなども可能です。コンテナイメージは配布先の ECR リポジトリを指定します。

2.5 イメージパイプラインとスケジュール

レシピ・インフラ設定・ディストリビューション設定を組み合わせて自動化したものがパイプラインです。cron 式によるスケジュール実行、手動実行、EventBridge からの起動に対応し、「ベースイメージやコンポーネントに更新があったときだけビルドする」条件も指定できます。失敗が続くスケジュールパイプラインを自動で無効化する設定もあります。

2.6 セキュリティ強化と脆弱性スキャン

DISA STIG に沿った強化コンポーネントを AWS が提供しており、CIS の強化コンポーネントも AWS Marketplace 経由で利用できます。Amazon Inspector を有効にしていれば、ビルド中のイメージの脆弱性(CVE)を検出して結果を記録できます。

2.7 ワークフローとライフサイクルポリシー

ワークフローでビルド・テスト・配布の各段階の手順をカスタマイズでき、Lambda 関数や Step Functions を呼び出す独自の検証も組み込めます。 ライフサイクルポリシーは、古くなったイメージを経過日数や世代数、タグに基づいて非推奨化・無効化・削除し、関連する AMI やスナップショットの整理を自動化します。

3. アーキテクチャおよび技術要素

  1. スケジュール、手動、EventBridge などでパイプラインが起動する。
  2. インフラストラクチャ設定に従ってビルド用 EC2 インスタンスが起動し、Systems Manager を通じてビルドコンポーネントが実行される(ビルドフェーズ → 検証フェーズ)。
  3. 検証に成功するとインスタンスを停止して AMI を作成する(コンテナの場合はイメージを作成)。
  4. 作成したイメージからテスト用インスタンスを起動し、テストコンポーネントと脆弱性スキャンを実行する。
  5. すべてのテストに合格した場合だけ、ディストリビューション設定に従ってリージョン・アカウントへ配布し、起動テンプレートや Parameter Store を更新する。
  6. 結果は SNS や EventBridge で通知され、ビルド・テスト用インスタンスは後片付けされる。

ビルド用インスタンスは Systems Manager や S3 と通信できる必要があります。プライベートサブネットで動かす場合は NAT ゲートウェイか VPC エンドポイントを用意します。

4. セキュリティと認証・認可

  • インスタンスプロファイル: ビルド・テスト用インスタンスには EC2InstanceProfileForImageBuilder と AmazonSSMManagedInstanceCore を含むロールを付ける(コンテナビルドでは ECR 用のポリシーも追加)。権限不足や SSM への経路がないことはビルド失敗の典型原因。
  • サービスの権限: Image Builder はサービスリンクロール、または管理ポリシー EC2ImageBuilderExecutionPolicy を付けた実行ロールで操作する。
  • 暗号化 AMI の共有: 他アカウントへ暗号化 AMI を配布するには、配布先アカウントが使えるように KMS キーのキーポリシーで許可する。
  • 強化と検査: STIG / CIS コンポーネントで OS を強化し、Inspector で既知の脆弱性を検出する。ビルド後には SSH 鍵などを消す後処理が自動で行われる。
  • 統制: コンポーネントやレシピは AWS RAM で共有でき、Organizations と組み合わせて承認済み AMI だけを使わせる運用ができる。
  • 監査と接続: API 呼び出しは CloudTrail に記録され、AWS PrivateLink(インターフェイス VPC エンドポイント)でプライベートに API を呼び出せる。

5. 料金形態

EC2 Image Builder の利用自体は無料です。イメージの作成・保存・配布の過程で使う他サービスの料金が発生します。

  • EC2: ビルド・テスト用インスタンスの実行時間。
  • ストレージ: AMI の EBS スナップショット、ECR に保存したコンテナイメージ、S3 に出力したログ。
  • データ転送: 他リージョンへの AMI コピーやコンテナイメージの転送。
  • 検査: Amazon Inspector によるスキャン。

6. よくあるアーキテクチャ・設計パターン

  • ゴールデン AMI パイプライン: 毎月(または依存更新時)に最新パッチを適用した AMI を作り、テスト合格後に起動テンプレートを更新し、Auto Scaling グループのインスタンスの更新で入れ替える。
  • イミュータブルデプロイ: 稼働中のサーバーにパッチを当てず、新しい AMI からインスタンスを作り直す。ブルー / グリーンやローリング更新と組み合わせる。
  • マルチアカウント配布: 共有サービスアカウントで AMI を作り、Organizations / OU 単位で共有して各ワークロードアカウントで利用する。
  • IaC からの最新 AMI 参照: 配布時に Parameter Store へ書き込んだ AMI ID を CloudFormation や起動テンプレートから参照する。
  • コンテナのベースイメージ管理: コンテナレシピで強化したベースイメージを作り、ECR へ配布する。
  • セキュリティ基準の組み込み: STIG / CIS 強化と Inspector スキャンをパイプラインに組み込み、基準を満たすイメージだけを配布する。

7. 設定・デプロイ手順(ハンズオン例)

  1. EC2InstanceProfileForImageBuilder と AmazonSSMManagedInstanceCore を付けた IAM ロールとインスタンスプロファイルを作成する。
  2. 必要ならビルドコンポーネント(例: Web サーバーの導入)を YAML で作成し、イメージレシピを作成して、ベースイメージ(例: Amazon Linux 2023)、AWS 管理の更新コンポーネント、自作コンポーネント、再起動テストなどのテストコンポーネントを追加する。
  3. インフラストラクチャ設定でインスタンスタイプ、サブネット、ログ出力先、SNS トピックを指定する。
  4. ディストリビューション設定で配布先リージョン、共有先アカウント、起動テンプレートの更新を指定する。
  5. パイプラインを作成してスケジュールを設定し、手動で 1 回実行して AMI の作成と配布を確認する。
  6. ライフサイクルポリシーを作成し、古い AMI とスナップショットが自動整理されるようにする。

8. 試験で問われやすいポイント

8.1 サービス選択

  • Q: パッチ適用済みの AMI を定期的に作成・テストし、複数リージョンへ配布する作業を最小の運用負荷で自動化したい場合は?
    A: EC2 Image Builder のイメージパイプラインを使う。手作業のスナップショットや自作スクリプトより運用負荷が小さい。
  • Q: コンテナのベースイメージも同じ仕組みで管理できる?
    A: できる。コンテナレシピでビルドし、ECR へ配布する。
  • Q: Image Builder の利用料は?
    A: 無料。EC2、EBS スナップショット、ECR、S3、Inspector などの料金のみ発生する。

8.2 配布と共有

  • Q: 作成した AMI を組織内の全アカウントで使えるようにするには?
    A: ディストリビューション設定で Organizations や OU への共有を指定する。
  • Q: 暗号化された AMI を他アカウントへ配布したら起動できない。原因は?
    A: KMS キーのキーポリシーで配布先アカウントにキーの利用を許可していない。
  • Q: 新しい AMI ができたら Auto Scaling グループで使われるようにしたい場合は?
    A: ディストリビューション設定で起動テンプレートを自動更新し、インスタンスの更新で入れ替える。最新 AMI ID を Parameter Store に書き込んで参照する方法もある。

8.3 セキュリティ

  • Q: 規制要件に沿った強化済み AMI を作りたい場合は?
    A: STIG 強化コンポーネントや CIS 強化コンポーネントをレシピに含める。
  • Q: ビルドしたイメージの既知の脆弱性を検出したい場合は?
    A: Amazon Inspector を有効にし、Image Builder のスキャン設定で CVE の検出結果を取得する。

8.4 運用とトラブルシューティング

  • Q: ビルドがタイムアウトや接続エラーで失敗する。よくある原因は?
    A: インスタンスプロファイルに SSM の権限がない、またはプライベートサブネットから SSM / S3 へ到達する経路(NAT・VPC エンドポイント)がない。
  • Q: 失敗原因を調べるためビルド用インスタンスを残したい場合は?
    A: インフラストラクチャ設定で失敗時に終了しない設定にし、S3 のログも確認する。
  • Q: 古い AMI とスナップショットが増え続けてコストがかさむ場合は?
    A: ライフサイクルポリシーで自動的に非推奨化・削除する。
  • Q: ベースイメージが更新されたときだけビルドしたい場合は?
    A: パイプラインのスケジュールに、依存関係の更新があるときだけ実行する条件を指定する。