ゴールデンAMIの自動化 EC2 Image Builderとインスタンスの更新で不変インフラを保つ

DOP-C02を目指す方向けに、パッチ済みの標準AMI(ゴールデンイメージ)を自動で作り、稼働中のAuto Scalingグループへ安全に展開する設計を解説します。試験では「稼働中のサーバーを直接変更しない(不変インフラ)」という前提のもとで、自動化と安全な置き換え方法を選ぶ力が問われます。

覚え方：3つの工程で考える

ゴールデンAMIの運用は「作る(ビルドとテスト)」「配る(バージョン管理と配布)」「置き換える(段階的な展開とロールバック)」の3工程に分けると整理できます。それぞれEC2 Image Builder、起動テンプレートのバージョンとSSMパラメータ、Auto Scalingのインスタンスの更新が対応します。

作る：EC2 Image Builder

Image Builderは、ベースイメージにビルドコンポーネント(パッチ適用、エージェント導入、CISベンチマーク準拠設定など)を適用し、テストコンポーネントで検証してからAMIを作成するパイプラインです。「毎月自動でパッチ済みAMIを作りたい」「テストに合格したイメージだけを使いたい」という要件で選びます。スケジュール実行のほか、ベースAMIの更新時に自動実行する依存関係トリガーもあります。コンテナ向けにはECRへのイメージ配布にも対応しています。

配る：バージョン管理と複数アカウントへの配布

作成したAMIはディストリビューション設定で複数リージョン・複数アカウントへコピーし、共有できます。最新AMI IDはSSMパラメータストアに書き込み、起動テンプレートやCloudFormationからパラメータで参照するのが定石です。こうしておくと、CloudFormationのSSMパラメータ型で常に最新のIDを取り込め、パイプラインの完了をEventBridgeで検知して起動テンプレートの新バージョン作成まで自動化できます。

置き換える：インスタンスの更新(instance refresh)

Auto Scalingグループのインスタンスの更新は、新しい起動テンプレートのバージョンでインスタンスを段階的に置き換える機能です。最小正常率(例:90パーセント)で同時に置き換える台数を制限し、チェックポイントで25パーセントごとに一時停止して確認、CloudWatchアラームによる自動ロールバックで異常時に旧バージョンへ戻せます。スキップマッチングを有効にすると、すでに新テンプレートのインスタンスは置き換えません。「稼働中の数百台を無停止で新AMIへ」という要件に対する最も運用負荷の低い答えです。

チェックリスト

• Image Builderのレシピ・コンポーネント・パイプライン・ディストリビューション設定の役割を説明できる
• 最新AMI IDをSSMパラメータ経由で起動テンプレートに渡す理由を説明できる
• インスタンスの更新の最小正常率・チェックポイント・自動ロールバックを設定できる
• 不変インフラとミュータブル運用の違いを問題文から判別できる
• 複数アカウント・リージョンへのAMI配布方法を挙げられる

まとめ

「作る(Image Builder)・配る(SSMパラメータと起動テンプレート)・置き換える(インスタンスの更新)」の3工程を自動化すると、不変インフラを保ったままパッチ運用ができます。要件文の「不変」「テスト済み」「段階的」「ロールバック」を手がかりに選びましょう。

クイズで理解度を確かめ、最新の出題範囲はAWS認定 公式ページで確認しておきましょう。