CloudFormationのドリフト認識変更セットを使ってみた（続編）

はじめに

前回、CloudFormationのドリフト認識変更セットを使ってみたという記事を書いた際にセキュリティグループを題材にしていましたが、セキュリティグループ内のルールについては複数の構成方法があります。

1. セキュリティグループ本体の定義の中にルールを書く方法
   （AWS::EC2::SecurityGroup内の$.SecurityGroupIngressに記述）
2. セキュリティグループルールを個別にリソースとして定義する方法
   （AWS::EC2::SecurityGroupIngressでルールを記述し、適用先のセキュリティグループを$.GroupIdで指定）

前回の記事では1の方法を試しましたので、今回は2の方法で作成したリソースに対してドリフト認識変更セットがどのように作用するのか調べていきます。

目次はこちら。

• テスト用のリソースを準備する
• 構成変更
• 構成変更からのロールバック
• 意地悪な構成変更
• 意地悪な構成変更からのロールバック
• まとめ

テスト用リソースを準備する

前回はセキュリティグループの中にルールを記載していましたが、今回はAWS::EC2::SecurityGroupIngressを使用して、ルールを個別に定義してみます。
下記のテンプレートをもとに、CloudFormationでスタックを作成します。

作成したセキュリティグループですが、前回と見た目は同じ構成になっています。

こちらが今回作成したセキュリティグループ。

比較用に、前回作成したセキュリティグループを再掲します。
IDはもちろん変化するのですが、それ以外は同じ構成になっていることが見て取れます。

前回と同様、作成したセキュリティグループをコンソールから変更していきます。
変更パターンも前回と合わせてみました。

やはり比較用として、前回のいじった構成も同様に載せておきます。

構成変更

さて、変更セットを作成してみましょう。
更新用のテンプレートは下記のようにしました。
AWS::EC2::SecurityGroupIngressがひとつ増えた構成です。

上記のテンプレートをもとに作成したドリフト認識変更セットのdiffビューはこのような感じになっています。
論理IDSecurityGroupIngress2の追加となっており、もとのSecurityGroupに対する変更が発生していない(※)ことから、今回手動で加えた変更は認識してくれませんでした。
（※：実際は変わるんですけどね...）

通常の変更セットのdiffビューも示しておきます。
ドリフト認識変更セットと変わりないです。

とりあえず変更セットを実行します。
更新後のセキュリティグループは、予想通り、下記のようになりました。
手動で変更した内容は維持されていますね。

構成変更からのロールバック

このままではおもしろくないのでもうちょっと続けてみます。
先ほど変更した結果に対して、「変更前のテンプレートを使用してドリフト認識変更セットを作成した場合」にどうなるかを見てみました。
結果としてはやはり、論理IDSecurityGroupそのものに対する変更は行われていないことから、単に先ほどと逆の変更セットが作成されました。

結果は省略しますが、変更セットを実行したところ、普通に「CloudFormation的には構成変更、利用者の視点ではロールバック」が行われました。...なんか消化不良な気がしますね...。

意地悪な構成変更

消化不良を解消すべく、下記のような流れを考えてみました。ちょっと意地悪な構成変更です。
2までは同じで、3のときにCloudFormationはどういう挙動を示すのか？というところを見てみます。

1. 当初のテンプレートで初期リソースを構成
2. CloudFormationの外部で構成を変更
3. テンプレート経由で下記の変更を加える
   ・論理IDSecurityGroupに$.SecurityGroupIngressを追加する
   ・リソース単位での追加・削除はなし

3で与えるテンプレートは下記の内容とします。
もともと論理IDSecurityGroupIngressとして作成されたルールがライブリソースの検出時にSecurityGroupのプロパティとして検出され、そこに、論理IDSecurityGroupに追加した$.SecurityGroupIngressのルールが、グループ本体に取り込まれた元SecurityGroupIngressとの差分として検知されることを期待しての内容です。

変更セットはこうなりました。
まず、サマリーはこちら。

続いて、論理IDSecurityGroupのdiffがこちら。
正直、これは予想していませんでした。別リソースとして構成している80/tcpのアクセス許可が論理IDSecurityGroupに差分として組み込まれるところまでは予想していましたが、「提案されているリソースの状態(diffの右側)」ではそのルールが443/tcpのアクセス許可に置き換えられると思っていたところ、80/tcpのルールが維持されて差分なしと認識されているのはおどろきです。

変更セットを実行した結果、セキュリティグループはこうなりました。
...ちょっとまって、diffビューでなくなるといっていたルールが残ってる？？

意地悪な構成変更からのロールバック

直前の結果になんとなく釈然としない気持ちをおさえつつ、当初のテンプレートで再びロールバックをかけてみることにしました。

ドリフト認識変更セットのサマリーはこちら。
直前の変更セット適用以降、CloudFormationの外での変更を行っていないにもかかわらず、ドリフトステータスが「ドリフト済み」となっています。いや、あなたがやったんですよ？？

続いてdiffはこちら。
えーと、diffの右側にも手動ルールが残っていますが...。

diffの画面に現れた「ドリフトを表示」を押したときの画面がこちら。
手動で追加した1433/tcpと3389/tcpのルールは一応検知されています。
にしても、削除ではなく追加として認識されているのが謎ですね。

そして、変更セットを流した後のセキュリティグループがこちら。
あのー、ルールが一つも減っていないんですが...。

元の状態が維持されていないことから、これ以上、更新に伴う変化を観測しても無意味なものとなるため、今回の検証はここで打ち切ることとしました。

まとめにくいけどまとめ

前回を含め、2回にわたってCloudFormationのドリフト認識変更セットを試してみましたが、いくつか気づいたことをまとめます。

1. ドリフト認識変更セットは定義の変化に加え、ライブのリソース状態も含めて変更をあぶりだしてくれる
   こちらは期待した通りの挙動でした。変更をリセットする、という意味では非常に有用ですね。
2. 定義の方法が複数存在するリソースでは、思った通りの差分とならないことがある
   これは想定通りの部分と予想外の部分が混在していましたね。
   あるリソースの定義方法が単一であれば気にする必要はありませんが、今回取り上げたセキュリティグループのように、定義方法が複数あるリソースをドリフト認識変更セットで管理する場合は要注意です。

とはいえ、今までは定義間の差分しか見てくれなかったところにライブ状態を加えて比較してくれるのは夢が広がりますね。
みなさんも、ぜひいろんな使い方を試してみてください！
それではまた！