カスタマーサクセス部の棚本です。
掲題の通りですが、CloudFormationでParameter Storeのパブリックパラメータを利用して作成したEC2を、テンプレートを変更することなく元のAMI IDを保持したまま変更セットを実行する必要があったため、実施方法をご紹介いたします。
経緯
AWSから提供されるWindowsやAmazon LinuxなどのAMI IDは、最新バージョンがParameter Storeのパブリックパラメータとして公開されております。
CloudFormationでEC2を作成する際に、EC2のImageIdを指定するパラメータとして上記のパブリックパラメータを利用することで、スタック作成時に公開されている最新のAMI IDからEC2を作成することが可能です。
AWSTemplateFormatVersion: "2010-09-09" Description: "Create Test Server" Parameters: ImageId : Type : AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> Default: /aws/service/ami-windows-latest/Windows_Server-2022-Japanese-Full-Base
こちらのテンプレートの仕組みとして、変更セット実行時に最新のAMI IDが更新されていた場合、既存のEC2が置換されてしまいます。
こちらの事象の詳細については弊社ブログにて詳しく記載されております。
既存の対応策と課題
上記の対策といたしまして、ネストスタックを利用する方法が弊社ブログにて紹介されております。
こちらの方法を利用すれば、スタック更新時にも作成時に利用したAMI IDを利用可能となります。
しかし、既に本番環境などでスタックを作成してしまっていてネストスタックで作成することが出来ない、でもコンソールから変更してドリフト(実際のAWSリソースとテンプレートに記載されている内容に乖離がある状態)が発生するのは嫌だ・・・
といったこともあるかと思います。
そこで今回は、テンプレートの記載を変えることなく、作成時に使用したAMI IDを指定して変更セットを実行する方法をご紹介いたします。
対応策
やり方は
- EC2で利用されているAMI IDをParameter Storeに格納する。
- 変更セットを実行する際に上記のパラメータをEC2のImageIdとして利用する。
これだけです。
手順
対象のEC2で利用されているAMI IDを確認します。 サービス「EC2」>「インスタンス」から対象のEC2を選択し、「詳細」タブから「AMI ID」の値をコピーします。
サービス「Systems Manager」>「パラメータストア」からマイパラメータの作成を行います。
パラメータを作成します。
- 名前:任意の名前
- 説明:任意の説明
- 利用枠:標準
- タイプ:文字列
- データ型:text
- 値:コピーしたAMI ID
CloudFormationから対象のEC2の変更セットを作成する際に、AMIを指定しているパラメータの値をパラメータストアに格納した名前にして実行します。
変更セットのプレビュー時に「置換」が「true」ではないことを必ず確認してください。
補足①
EC2の設定には変更すると置換されるプロパティとそうでないプロパティが存在しております。
例えばインスタンスタイプを変更する場合、既存のEC2は削除はされず、再起動しつつ変更が行われます。
AMI IDを変更する場合は既存のEC2が削除され、新しいEC2が立ち上がる、といった感じです。
各プロパティが変更された際の動作は以下のドキュメントで確認できます。
(各プロパティの「Update requires」の値が該当します。)
docs.aws.amazon.com
補足②
EC2のAMI IDをParameter Storeのパブリックパラメータから指定する場合、CloudFormationのパラメータタイプは「AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>」を使用します。
このパラメータタイプはパラメータストアに格納されているパラメータ名を入力する必要があるため、直接AMI IDを指定するとエラーになってしまいます。
ですので、AMI IDをParameter Storeに格納して利用する必要があります。
まとめ
今回はCloudFormationでParameter Storeのパブリックパラメータを利用して作成したEC2を、テンプレートを変更することなく元のAMI IDを保持したまま変更セットを実行する方法をご紹介いたしました。
このような事象を発生させないためには、将来的な運用を見据え、CloudFormation(IaC)を利用していくルール作りが大切なのだと思います。
例えば、インスタンスの更新に変更セットを利用することが見込まれるので、パブリックパラメータを使わずにAMI IDをパラメータに直接埋め込む。
或いは一番初めの構築にのみCloudFormationを利用して、更新はGUIで行う、などが挙げられます。
システムやチームの方針によって最適な利用方法は変わると思いますので、これらを見極めて皆が幸せになれるIaCの使い方を広めていければと思います。
棚本 清也(執筆記事の一覧)
2024年7月入社
自動化・最適化が出来るエンジニアを目指してます。