![[アップデート]EC2 Image BuilderがSSMパラメータストアとの統合をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9a77dea1d7bd5c93a0746301f6ee63e2/e9c4b3d42f7df740ded6031194d290e5/ec2-image-builder)
[アップデート]EC2 Image BuilderがSSMパラメータストアとの統合をサポートしました
2025.05.01お疲れさまです。とーちです。
Amazon EC2 Image Builderで AWS Systems Manager パラメータストアが使用できるようになったというアップデートがありました。
最近だと、AWS Elastic Beanstalkもパラメータストアをサポートしていたりと、ややマイナー寄りなAWSサービスでもパラメータストアの統合が進んできていていいですね。
EC2 Image BuilderではどのようにSSM パラメータストアが統合されたのかを確認していきましょう。
EC2 Image Builderの基本おさらい
まずEC2 Image Builderを簡単におさらいします。EC2 Image Builderは一言でいうと、ユーザー独自のAMIやコンテナイメージを作成するためのCI/CDパイプラインを提供するサービスです。EC2 Image Builderは以下の図のように様々な要素が組み合わさって一つのパイプラインを作ります。
画像はAWS入門ブログリレー2024〜EC2 Image Builder 編〜 | DevelopersIOより引用
またEC2 Image Builderの概要を理解するのに以下の図がとても分かりやすいと思ったので載せておきます。
画像はAmazon EC2 Image Builder入門より引用
各要素を簡単に説明すると以下の通りです。（EC2 Image BuilderではAMIまたはコンテナイメージを作成できますが、ここでは分かりやすくするためにAMI作成をする想定で説明します）
- イメージレシピ：作るイメージの設計図です。ベースイメージと、そこに追加するコンポーネントで構成されます。
- ベースイメージ：スタート地点となるOSイメージです。AmazonのAMIや自分で以前作ったイメージから選べます。
- コンポーネント：イメージに機能を追加するための部品です。大きく2種類あります。
- ビルドコンポーネント：ソフトウェアのインストールや設定変更など、イメージを作る時に実行する作業です。例えば「Apacheをインストールする」「セキュリティ設定を強化する」などの指示をYAMLファイルに書きます。これらはスナップショットを取る前に実行されます。
- テストコンポーネント：作ったイメージが正しく動くか確認するためのテストです。例えば「Webサーバーが応答するか」「必要なポートが開いているか」などをチェックします。これらはスナップショット後に実行されます。
- ディストリビューション設定：作ったイメージをどこで使えるようにするかの設定です。例えば「東京リージョンと大阪リージョンで使えるようにする」「開発チームのAWSアカウントと共有する」などを指定します。
- インフラストラクチャ設定：イメージを作る時に一時的に使うEC2の設定です。例えば「どのインスタンスタイプを使うか」「どのネットワーク内で動かすか」「ログ出力先S3バケット」などを指定します。インスタンスタイプは、容量不足で失敗しないよう複数指定しておくと安心です。
- ビルドスケジュール：イメージの作成をいつ実行するかの設定です。「毎週月曜の深夜に自動実行」などのスケジュールを設定できます。もちろん、ボタン一つで手動実行することも可能です。定期的に最新のセキュリティパッチを適用したイメージを作りたい場合に便利です。
今回のアップデート内容
EC2 Image Builderについておさらいができたところで、今回のアップデートを説明します。今回のアップデートではイメージレシピ、コンポーネント、ディストリビューション設定のそれぞれでSSM パラメータストアが統合されたというものになります。
イメージレシピ
パラメータストアを参照し、パラメータストア内に記載されたAMI IDを入力として利用できるようになりました。例えば、ユーザーが作った最新のAMI IDをパラメータストアに記載しておくことで、常に最新のAMIをベースイメージに指定することが出来たりします。
コンポーネント
SSM パラメータを簡単に参照できるようになりました。コンポーネント内の処理でパラメータストアに格納された値を使えます。コンポーネント内でDBに接続したりなどのユースケースで役立ちます。
ディストリビューション
出力されたAMI ID等をSSM パラメータに書き込めるようになりました。Image Builderで作成した最新のAMI IDを特定のパラメータストアに自動で記載するには、これまでだとカスタムスクリプトなどで頑張る必要がありましたが、これが設定一つでできるようになりました。
それではそれぞれ試してみましょう。
コンポーネントにパラメータストアを指定する
まずはAWS Systems Managerのパラメータストアでパラメータを作成しておきます。なおAMIはAmazonLinux2023の2025/4現時点での最新のものを使用しました。
以下のように作成しました。
- コンポーネントテスト用
- 名前：
/ec2imagebuilder/dbpassword - タイプ：文字列
- データ型：text
- 値：
ec2imagebuilder-ParameterStore-update-test-20250501
- 名前：
- イメージレシピテスト用
- 名前：
/ec2imagebuilder/baseid - タイプ：文字列
- データ型：aws:ec2:image
- 値：AMI IDを入力
- 名前：
それではコンポーネントを作成していきます。
今回は簡単なビルドコンポーネントを作ってパラメータストアとの連携を試してみます。
コンポーネントの基本設定は以下のようにしました。
肝心のSSM パラメータストアと連携するビルドコンポーネントドキュメント（ビルド処理を記載するコード）ですが、以下のように記載しました。
name: HelloWorldBuildDocument
description: This is hello world build document.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: HelloWorldStep
action: ExecuteBash
inputs:
commands:
- echo "MyDB Password is {{ aws:ssm:/ec2imagebuilder/dbpassword }}."
コンポーネントドキュメントではドキュメント内で定義した定数を参照するのに {{ 定数名 }} といった書き方をしますが、SSM パラメータストアの値を参照する場合は以下のように記載します。
{{ aws:ssm:/my/param }}
/my/param の部分にパラメータストアのパラメータ名を記載します。
パラメータストアを参照するためには当然IAM権限が必要です。具体的なIAMポリシーについては後ほど解説します。
また、上記の詳細についてはAWS公式ドキュメントもご参照ください。
イメージレシピにパラメータストアを指定する
続いてイメージレシピを作成していきます。
イメージレシピでは上記の通り、ベースイメージとして使用するAMI IDをパラメータストアから取ってくることができるようになっています。
ベースイメージを設定する項目で以下のようにパラメータストアのパラメータ名を指定します。ARN形式での指定もできるようです。パラメータ名を指定すると自動でAMI名等が表示されました。便利ですね。
コンポーネントの項目で先程作成したビルドコンポーネントを追加します。
その他の設定はデフォルトのまま、イメージレシピを作成しました。
ディストリビューション設定でパラメータストアを指定する
続いてディストリビューション設定を作成します。
今回はAMIを作成するので、イメージタイプはAMIを指定します。
リージョン設定の項目で、AMI IDを出力する先のパラメータストアの名前とパラメータストアのデータ型（text or AWS EC2 Image）を指定します。既存のパラメータ名を指定して更新することもできるようです。今回はパラメータを新規作成してみます。
イメージパイプラインの作成
それでは、これまで作った要素を使用してイメージパイプラインを作成していきます、といきたいところですが、その前にIAMロールを作成しておきましょう。
EC2 Image BuilderでAMIを作成する際に必要となるIAMロールは大きく２つあります。
- Image Builder自体の実行ロール（デフォルトだとAWSServiceRoleForImageBuilder）：こちらはImage Builderがパイプラインを実行するために必要なロールでEC2の起動等に使われたりします。
- Image Builderが起動するEC2インスタンスに付与するIAMロール（デフォルトだとEC2InstanceProfileForImageBuilder）：ビルドコンポーネント等はEC2上で実行されるので、コンポーネントからSSM パラメータストアを参照する際はこちらのIAMロールに権限を追加する必要があります。
パイプラインを作成する前に上記２つのIAMロールを作っておきます。
Image Builder自体の実行ロールの作成
Image Builder自体の実行ロールはサービスリンクロール（AWSServiceRoleForImageBuilder）も使えますがこのロールには、SSM パラメータストアを参照できる権限はついておらず、かつサービスリンクロールには権限を追加することが出来ません。 そのため、独自のIAMロール（サービスロール）を作る必要があります。
EC2 Image Builderの公式ドキュメントには、サービスロールを作成する手順のリンクの記載がありますが、この手順には基本的な作り方しか書いてなかったので、実際のサービスリンクロールのポリシーを参考にしてIAMポリシー等を追加しました。少々作り方に悩んだ部分もあったので以下、手順も記載しておきます。
まずは以下の内容をRole-Trust-Policy.json として開発端末にファイルとして用意しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "imagebuilder.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
以下のコマンドでIAMロールを作成します。
aws iam create-role --role-name custom-AWSServiceRoleForImageBuilder --assume-role-policy-document file://Role-Trust-Policy.json
IAMポリシーを付与するのですが、サービスリンクロール（AWSServiceRoleForImageBuilder）についている管理ポリシー「AWSServiceRoleForImageBuilder」は付与することが出来ません。
こちらの公式ドキュメント等を参考にIAMポリシーを作ってもいいのですが、今回は、管理ポリシー「AWSServiceRoleForImageBuilder」の内容を丸々コピーして、インラインポリシーとして作成したIAMロールに追加しました。
このIAMロールは上記の通り、Image Builderがパイプラインを実行する際に使用するロールなので、イメージレシピでのSSM パラメータストアの読み込みと作成したAMI IDをSSM パラメータストアに書き込むための権限も必要です。そのため以下のIAMポリシーもインラインポリシーで追加しました。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:ap-northeast-1:＜account-id＞:parameter/ec2imagebuilder/baseid"
},
{
"Effect": "Allow",
"Action": "ssm:PutParameter",
"Resource": "arn:aws:ssm:ap-northeast-1:＜account-id＞:parameter/ec2imagebuilder/*"
}
]
}
Image Builderが起動するEC2インスタンスに付与するIAMロールの作成
Image Builderが起動するEC2インスタンスに付与するIAMロールの基本的な作成方法は公式ドキュメントだと以下のあたりに記載があります。
信頼ポリシーは"Service": "ec2.amazonaws.com" からの使用を許可する形にします。
また、以下の３つのAWS管理ポリシーを付与します。
- AmazonSSMManagedInstanceCore
- EC2InstanceProfileForImageBuilder
- EC2InstanceProfileForImageBuilderECRContainerBuilds（おそらく今回のようにAMIのみを作成するのであれば不要）
続いて以下のSSM パラメータストア関連の権限も付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm:ap-northeast-1:＜account-id＞:parameter/ec2imagebuilder/dbpassword"
}
]
}
これで、IAMロールの準備はOKです。
パイプラインの作成
それではパイプラインを作成していきます。
ビルドスケジュールは今回は検証目的なので手動にしました。
イメージレシピは上記で作成したレシピを指定します。
続いてワークフロー設定についてですが、ここでImage Builder自体の実行ロールを指定します。少なくともマネジメントコンソール上では、カスタムワークフローを指定しないとIAMロールの変更が出来ないようなので、カスタムワークフローを選択します。
また、今回はビルドコンポーネントを動かしたいのでビルドワークフローのbuild-image/x.x.x を選択します。これはAWSが元々用意しているワークフローで、コンポーネントで記載した処理の実行を含むワークフローになっています。
なおワークフローとはEC2 Image Builder のイメージ作成プロセスにおける、実行される「ステップの順序」を定義するものです。ステップの中にはEC2の起動やコンポーネントの実行といったものが含まれます。
画面下部のサービスアクセスの箇所では上記で作成したサービスロールを指定しましょう。
インフラストラクチャ設定で「新しいインフラストラクチャ設定を作成する」を選択し、IAMロールに上記で作成したロール名を指定します。詳細については割愛しますが、「VPC、サブネット、およびセキュリティグループ」の設定も実在のVPC ID等に変更しています。その他の設定はデフォルトです。
ディストリビューション設定も「新しいディストリビューション設定を作成する」を選んで新規作成します。
リージョン設定の箇所に作成されたAMI IDを出力するパラメータストアの名前を指定できます。新規作成も更新もできるようです。今回はパラメータストアが存在しない状態でImage Builderを動かしてみました。
SSM パラメータストアからの取得、格納を確認する
パイプラインが作成できたらさっそくパイプラインを起動してみます。
パイプラインが起動すると画面下部に以下のように起動するたびにイメージのバージョンが作成されます。ログストリームの箇所をクリックするとCloudWatchLogsで実行ログが見れます。
Stdout で検索するとコンポーネントの中で実行されたコマンドの標準出力が確認できます。ちゃんとSSM パラメータストアの値を取得した結果がechoされていますね。
イメージの作成が完了したので、パラメータストアにAMI IDが出力されているかを確認してみます。こちらもちゃんとAMI IDが格納されていました。
EC2の画面からも確認してみましたが、ちゃんと存在していますね。
分かりづらいのですが、ビルドのためにImage Builderによって一時的に作成されたインスタンスのAMIもSSM パラメータストアから取得したAMI IDになっていました。
まとめ
ということで、EC2 Image BuilderでSSM パラメータストアが使用できるようになったというアップデートの紹介でした。
SSM パラメータストアが利用できるようになったことで、ベースイメージを更新したときでもパイプラインの設定変更をしなくても良くなったり、コンポーネント内で機微な情報を扱いやすくなったりと色々メリットがありますね。IAMロールの設定が少し面倒ですが、EC2 Image Builderをすでに使っている方にとっては良いアップデートではないかと思います。
以上、とーちでした。
