夏が終わり、ようやく秋ですね。フィクションの夏なら好きです。西です。

AWS ワークロードの実行基盤には様々な選択肢があります。昨今は Amazon ECS や AWS Lambda (Lambda) 等のコンテナ・サーバレスサービスを採用することが主流ですね。一方、移行リスクに対して費やす工数・費用・メリットのバランスから、現在も初期構築時の Amazon EC2 (EC2) で稼働しているシステムは多く存在するのではないでしょうか。

EC2 で稼働するワークロードの場合、Amazon Machine Image (AMI) の作成・管理は運用上とても重要です。 AMI 作成環境の整備や旧 AMI の自動削除、AMI スキャンやクロスアカウント展開など、考慮するポイントは多岐にわたります。本記事ではそれらポイントをマネージドサービスでケアできる EC2 Image Builder の構成と、利用における一例をお伝えします。

EC2 Image Builder とは

EC2 Image Builder (Image Builder) は AMI の作成・管理・展開を自動化するためのサービスです。 AMI だけでなく、コンテナ環境で利用する Docker イメージを対象として取り扱うこともできます。本記事では主要なユースケースである AMI を扱うケースにフォーカスします。

docs.aws.amazon.com

概要を整理すると、Image Builder では AMI や Docker イメージ作成に関わる要素を組み合わせてパイプライン化することが可能です。具体的には以下の要素を取り扱います。

AMI や Docker イメージなど、成果物を作成する際に実行する処理
作成した成果物の保存場所 (AWS アカウント・ECR リポジトリ)
成果物の作成環境 (VPC や IAM 等の設定)

なお、Image Builder による AMI 作成は、AMI 作成用の EC2 に対し、SSM セッションマネージャー経由で処理を実行します。そのため、その実行環境を用意して Image Builder の設定を実施する必要があります。

構成要素について

Image Builder パイプラインを作成するには以下のリソースを準備する必要があります。

リソース	役割
コンポーネント	AMI 作成時に実行するコマンドを定義します。パラメータを定義して実行時に渡すこともできます。ビルド用とテスト用が存在します。
レシピ	実行するコンポーネントを紐付けておくリソースです。コンポーネントのパラメータに渡す値もレシピで指定します。
インフラストラクチャ設定	AMI を作成する際の EC2 に関わる以下のような設定を定義します。・VPC ・サブネット・セキュリティグループ・インスタンスプロファイル・(任意) 完了後の通知用 Amazon SNS (SNS) トピック
ディストリビューション設定	作成される AMI の名前や他アカウントとの共有設定を定義します。

これら全ての要素を紐づけたものがパイプラインです。ユーザはパイプラインを実行することで、各構成要素の設定に基づいて AMI を作成することができます。

絵にすると以下のような構成・処理の流れで AMI が作成されます。

その他構成要素

以上の要素以外にもパイプラインをカスタマイズすることが可能です。

インフラストラクチャ設定で SNS トピックを関連付けると、パイプライン実行完了時に SNS トピックによる通知が可能です。しかし、Image Builder の Event は Amazon Q Developer (旧 AWS Chatbot) の取り扱い対象外の Event (UnsupportedEvents) です。通知させる場合は SNS トピックから Lambda をトリガーさせる等、他の手段で通知させる必要があります。

AMI のライフサイクル設定

Image Builder ではライフサイクルポリシーが存在します。このポリシーはレシピに紐づく形で、作成した AMI の自動削除や無効化の設定が可能です。例えば「レシピ A で作成した AMI は直近 3 つまで保存し、古いものから順に削除する」のような管理が可能です。

実際に利用する上での一例

最後に運用方針の観点から実際の利用について考えてみます。

レシピとコンポーネントの運用

AMI 作成に最も関連が強いのがレシピとコンポーネントです。コンポーネントには AMI 作成時に実行するコマンドを定義します。一方、実際にパイプラインに紐づけるのはレシピです。どのように作成・運用するのが良いでしょうか。

個人的な見解ですが、実際の AMI 作成にはバージョン指定やワークロード特有のパラメータを利用すると思います。そのため、以下の運用になるケースが多いと考えています。

AMI で実行する処理は不変なので、コンポーネントは一つ作る
指定するバージョン情報等、パラメータが変わるだけレシピを作る

絵にするとこうです。

絵では一つですが、実際はコンポーネントが一つとは限りません。パラメータ毎の組み合わせ爆発を考えると、以上の例はリソース数を抑えられる運用と思います。

ちなみに、この場合は一つのレシピで一つの AMI しか作らない運用です。そのため、ライフサイクルポリシーを採用するかどうかの判断が難しくなります。無理に採用する必要はないですが、

dnf update 等で定期的にパッケージ最新化の影響チェックをしている等 → 採用する
設定やバージョン変更時のみ AMI を作成している → 管理のシンプル化のために採用しない

などが採用基準として良いのではないでしょうか。あくまで一例ですが。

ビルド時の特定ファイル配置

EC2 インスタンスへログインする際の方法として、昨今は SSM セッションマネージャーが推奨されています。しかし、システム要件などから公開鍵認証方式を採用しているケースも多いのではないでしょうか。その場合、AMI 作成時に公開鍵を配置するケースもあると思います。

そういった場合、Image Builder は特定ファイルをビルドコンポーネントの実行完了後に自動削除するため、注意が必要です。自動削除の対象は CloudInit 関連ファイルや、SSH 関連ファイル、インスタンス起動時のファイルなどです。削除対象ファイル群の情報は以下のドキュメントに記載があります。

docs.aws.amazon.com

何も設定を施さない場合は、ファイルの配置処理を実行しても、その後にファイルは自動削除されます。削除対象のファイルを事前に配置する場合は、配置するファイルの種別に応じた名前の空ファイルを作成することで削除を回避可能です。利用するケースに合わせて作成を忘れないようにしましょう。