Amazon Machine Image（AMI）とゴールデンイメージ管理

AMIはEC2を起動するためのテンプレート

**Amazon Machine Image（AMI）**は、EC2インスタンスを起動するときに指定するイメージです。AMIを選ぶと、OSや起動に必要なソフトウェアを含むベースの構成を使ってインスタンスを作成できます。同じAMIから複数のインスタンスを起動すれば、共通の土台をそろえやすくなります。

AMIには、インスタンスを起動するための情報と、ルートデバイスを含むブロックデバイスマッピングが定義されています。EBSをルートデバイスに使うAMIでは、ルートボリュームや追加ボリュームの元になるEBSスナップショットが関連付けられます。AMIはスナップショットそのものではなく、どのイメージとボリューム構成からインスタンスを起動するかをまとめる単位です。インスタンスストアをルートデバイスに使うAMIもあるため、暗号化やスナップショットを扱うときはEBSベースのAMIかどうかを確認します。

AMIから起動した後のインスタンスは、元のAMIとは別のリソースです。インスタンス上で後から行った変更が、元のAMIに自動反映されるわけではありません。変更した構成を別のインスタンスでも使うには、新しいAMIを作成するか、イメージ作成パイプラインを更新して再作成します。

ゴールデンイメージで共通の土台をそろえる

組織内の複数の環境やチームで使う標準AMIは、ゴールデンイメージと呼ばれることがあります。呼び方に厳密なAWSサービス上の定義があるわけではありません。ここでは、複数のインスタンスに共通して必要な設定をあらかじめ組み込んだ管理対象のAMIを指します。

イメージには、起動する場所やアプリケーションの役割が変わっても共通して使う要素を入れます。たとえば、組織で標準化したOS、承認済みのセキュリティパッチ、監視やログ収集のエージェント、複数のアプリケーションで必要な言語ランタイムなどです。OSやソフトウェアのサポート状況を追い、脆弱性修正を含む新しいイメージを継続的に作る運用も必要です。

一方、環境ごとに値が異なる情報はAMIに固定しません。アプリケーションのリリース版、テスト環境と本番環境で異なる接続先、APIトークンやデータベース認証情報などをイメージに焼き込むと、古い値の残存や秘密情報の漏えいにつながります。これらはインスタンス起動後のデプロイ工程で設定し、秘密情報はSecrets Managerなどから実行時に取得する方式を検討します。

この分離によって、共通のOS・エージェントを更新するときにアプリケーションの環境設定までイメージへ混ぜずに済みます。反対に、環境固有の値を変えるたびにゴールデンイメージを作り直す必要もありません。

暗号化されていないAMIから暗号化AMIを作る

AMIの登録済み内容をその場で暗号化状態へ切り替えることはできません。EBSベースのAMIの場合、暗号化の対象はAMIに結び付いたEBSスナップショットです。したがって、暗号化済みのAMIを新たに用意するには、元のAMIを維持したまま、暗号化されたスナップショットを参照する別のAMIを作成します。

現在は、AMIのコピー操作時に暗号化を指定する方法が利用できます。コピー元が暗号化されていなくても、コピー先のAMIを作る際に暗号化を有効にし、使用するAWS KMSキーを指定できます。コピー操作によって新しいAMIとその背後の暗号化済みスナップショットが作られます。これが、暗号化状態を引き継ぐだけの通常コピーとは異なる点です。

同じ結果は、元AMIからインスタンスを起動し、ボリュームのスナップショットを取得して暗号化コピーを作り、そのスナップショットから新しいAMIを登録する手順でも得られます。複数のEBSボリュームをAMIに含める構成では、必要なボリュームを漏れなく扱います。目的が再利用できる暗号化AMIの作成であれば、AMIコピー時に暗号化を指定する方法が手順をまとめやすい選択肢です。

また、暗号化されていないAMIからインスタンスを起動する際に、起動するEBSボリュームだけを暗号化することもできます。この場合、起動元AMI自体の暗号化状態は変わりません。暗号化AMIを複数回利用したいのか、今回起動するボリュームだけを保護したいのかを区別します。

暗号化に使うKMSキーについては、実行者とコピー先アカウントに必要な利用権限があるか確認します。別リージョンへコピーする場合は、コピー先リージョンで使えるキーを指定します。KMSキーへのアクセスが許可されていないと、スナップショットのコピーや共有先での利用が失敗することがあります。

試験での整理: 「既存AMIを直接暗号化して内容を変更する」操作と、「暗号化されたスナップショットを使う新しいAMIを作る」操作は別です。AMIコピー時に暗号化を指定すれば、元インスタンスを起動し直すことなく暗号化AMIを作れます。

AMIを別リージョンへコピーする

AMIはリージョン固有のリソースです。あるリージョンで登録したAMIを、そのまま別リージョンのEC2起動に指定することはできません。別リージョンでも同じ構成のインスタンスを起動するには、AMIを対象リージョンへコピーします。

AMIをコピーすると、EBSベースのAMIでは関連するスナップショットもコピー先へ転送されます。そのスナップショットを元にコピー先リージョンのAMIが登録されるため、コピー後は元とは異なるAMI IDになります。AMIが元リージョンから移動して消えるのではなく、リージョンごとに使えるAMIの複製ができます。

たとえば、カナダ中部リージョンで検証済みの注文処理サーバーイメージを作り、フランクフルトリージョンにもコピーしておけば、欧州側のワークロードやリージョン障害に備えた起動に利用できます。複数リージョンへ広げる際は、コピー先で利用するKMSキー、AMIの起動権限、スナップショットの保存コストも合わせて設計します。コピー処理の時間はイメージの大きさやAWS側の状況などに左右されます。

別アカウントに利用させるには、AMIの起動権限を共有する方法があります。リージョンコピーは「別リージョンにAMIのコピーを作る」操作、アカウント共有は「他アカウントにAMIを起動する許可を与える」操作であり、目的が異なります。暗号化AMIを共有する場合はAMIの共有設定に加え、暗号化に使用したKMSキーへのアクセスも確認してください。

EC2 Image Builderで作成と更新を自動化する

EC2 Image Builderは、カスタムサーバーイメージの作成、検証、配布を自動化するフルマネージドサービスです。AMI作成のたびに人がインスタンスへログインして同じソフトウェアを手作業で導入する代わりに、手順を定義して繰り返し実行できます。Image BuilderはAMIのほかコンテナイメージも扱えますが、ここではEC2用AMIのパイプラインに注目します。

AMI作成の設計図になるのがイメージレシピです。レシピではベースイメージを選び、どのソフトウェアや設定を追加するかを定義します。インストールや構成変更の処理はコンポーネントとして組み合わせ、必要なスクリプトを実行する形で再現可能にします。レシピに共通ランタイムや必須エージェントを記述すれば、チームごとの手順差を減らせます。

レシピをイメージパイプラインに設定すると、手動実行やスケジュールに基づくイメージ作成を構成できます。パイプラインではビルド後にテストコンポーネントを実行し、作成したイメージが想定どおりかを確認できます。パッチ更新を含むイメージを定期的に作り、テストに合格した成果物を次の工程へ渡す運用にすると、古いベースイメージを放置するリスクを下げられます。

さらに、配布設定でAMIを展開するリージョンを指定し、他アカウントへの共有も構成できます。暗号化が必要な場合は、AMIの配布先やKMSキーの要件もパイプライン設計に含めます。Image Builderが行うのは、定義されたイメージの作成・テスト・配布です。各アプリケーションをどの環境へデプロイするか、接続情報をどう与えるかは、別のデプロイや構成管理の責任として設計します。

要件ごとの使い分け

要件	判断のポイント
複数のインスタンスでOSや基本ソフトウェアの状態をそろえたい	ゴールデンイメージに共通のOS、パッチ、エージェント、ランタイムを含める
開発・検証・本番で接続先や認証情報が異なる	環境固有の値をAMIに保存せず、起動後の設定やSecrets Managerなどから与える
既存AMIから暗号化済みAMIを作りたい	元AMIを直接変更せず、AMIコピー時に暗号化とKMSキーを指定する
暗号化していないAMIを使い、一度だけ暗号化ボリュームで起動したい	起動時にEBSボリュームの暗号化を指定する。元AMIは暗号化されない
複数リージョンで同じAMIを使いたい	対象リージョンへAMIをコピーし、新しいAMI IDとKMSキーを確認する
イメージ作成を定期化し、テスト後に複数リージョンへ展開したい	Image Builderのレシピ、パイプライン、テスト、配布設定を組み合わせる

公式ドキュメント

• Amazon Machine Images（AMI）の概要
• EBSベースAMIでの暗号化
• AMIのコピー
• EC2 Image Builderの概要
• Amazon EBSの料金