CloudFormationテンプレートリバース作戦(未解決)

CloudFormationテンプレートで作成したスタックに対して手動でガチャガチャ動かしてしまってー、履歴とかも取ってなくてー、タグとかも整理されているんだかいないんだかでー。 というガバナンスガバガバ状態だけど、心を入れ替えてヤル気はあるんで既存リソースを活用して初めからIaCやり直したいっす!!って場合にはどんな対応があるか調べてみた。

対策1:CloudFormationのimport機能

https://aws.amazon.com/jp/blogs/news/new-import-existing-resources-into-a-cloudformation-stack

ガバナンスが効いている状態であれば、インポート機能を活用してテンプレートファイルを一致させつつみたいな感じ出来るが、最早そんなレベルではない場合はどうするか。

対策2:Former2

既存AWSリソースからCFnテンプレートを作成するサービスとしてはCloudFormerとFormer2があります。

2019のre:inventではAWSもこちらの利用を勧めていたりします。

https://dev.classmethod.jp/articles/cloud-formation-dop408/

Former2の使い方

以下が分かりやすいのでご参考に。

https://dev.classmethod.jp/articles/former2/

ReadOnlyなアクセスキーとシークレットキーをぶち込む必要があります。

Former2でスタック復元できるのか?

結論としては、「厳しい」と思いました。厳しいポイントは以下。

厳しかったポイント1:リソース依存関係問題

依存関係のありそうなリソースを連続して選択してテンプレート化すると、ref!などで依存関係を見てくれるのですが、選択方法にコツが入ります。

依存関係先がテンプレート内に記載あれば、そこを指定するが、なければ既存リソースの物理IDを拾いにいく形になっています。

具体的には - ①vpc - ②subnet の順番でリソース選択すれば、subnet側で!refを使って①の論理IDを拾いにいって汎用的なテンプレートが構築されるが、

  • ①subnet
  • vpc の順番でリソース選択すると、①subnetは既存vpcの物理ID情報をテンプレートに埋め込むといった形になります。

汎用的なテンプレートへのリバースにはリソース選択順番が肝といったわけです。

厳しかったポイント2:復元リソースを探し切れない

Former2の検索窓でタグ情報などを使って、リソースを一括して選ぶことが出来るのですが、Routetabelのrouteなどタグ情報などが全くつけれないリソースとかもあってそういうのは別途選択する必要がありそう。

まとめ

Former2でスタック復元は厳しいですね。

参考程度にはできるかもだけど。。。

CFnドリフト検出できるリソースはドリフト検出で確認+ドリフト出来ないリソースはaws cliで状況確認みたいな超絶泥臭い対応しかないのかな

あとは使ったことないけどawsspecとかって使えるのか?