CloudFormation の注意点Tips

最近CloudFormationを触り始めました、AWSのリソースをテンプレートから作成できるのは便利なのですが、その反面注意する必要がある点もあったので、備忘録も兼ねて紹介したいと思います。

対象読者

• CloudFormation初心者

前提

本記事では以下の構成のCodePiplineでリソースを作成することを前提として話していきます。
私がその構成でしかCloudFormationを扱ったことがないので、
他の構成やでは当てはまらない点もあるかもしれませんが、その点についてはご了承お願い致します。

CodePipeline

• 1. Source ステージ
  • CodeCommit上のリポジトリのmasterブランチ
• 1. Build ステージ
  • 必要なyamlファイルを生成し、artifactsで指定して後続のステージで参照できるようにしています
• 1. MakeChangeset ステージ
  • CloudFormationのアクション「変更セットの作成または置換」で各stackのchangesetを作成します
• 1. Deploy ステージ
  • CloudFormationのアクション「変更セットの実行」で各stackの作成または更新を行います

stackで作成されたリソースはコンソール上から変更、削除しない

コンソール上からStackでリソースの設定を変更すると。CodePipelineを実行した時に、テンプレート通りのパラメータに設定されず、コンソール上で設定したパラメータが残ってしまう場合があります。

私は特にLambdaに対してやっていましたが、
APIGatewayをトリガー設定を間違ったパラメータで変更してしまい、CodePipelineを再実行しても設定が戻らず、
必ずエラーになるAPIを作成してしまったことがあります。

設定を元の状態に戻せるのであれば問題ないかもしれませんが、基本的にstackで作成されたリソースをコンソール上から変更するのはやめましょう。

stackで作成されたリソースはコンソール上から削除しない

コンソール上からリソースを削除するとChangeset作成の段階で失敗します。
Changeset作成時はどうやら変更前のリソースは存在するものという前提で動いているようです。

もし削除してしまった場合、一番確実な対象法はstackを削除して再度作り直すことです。

私も次のCodePipelineの実行でLambdaが再作成されるだろうと思い、下手にパラメータを変更したLambdaを削除してしまいました。。
泣く泣くstackを削除して再度作り直しましたが、まだlambdaだけのstackで良かったです。
（実際どうなるのかはわかりませんが、これがDynamoDBだったりRDSだったらと思うとゾッとします）

DynamoDBの1テーブルに対して複数のGSI変更はできない

これはDynamoDBの仕様でもあるのですが、一つのテーブルに対してGSIの変更は一つずつしか変更できません。

• 新規テーブルを作成する場合
  • 複数のGSIの作成は可能です。
• 既存テーブルに対して複数のGSIの作成または変更した場合
  • エラーとなり更新に失敗します。

もし既存テーブルに対して複数のGSIの変更を行いたい場合は面倒ですが、一つのGSIを変更するたびにデプロイする必要があります。

VPC内のLambdaを含むstackを削除する場合、VPC内のLambda削除に40分の遅延が発生する

これはよくStackOverflowでもissueが上がってたりしますが、VPC内のlambdaを含むstack削除するとそのLambdaの削除に40分程時間がかかります。
これはLambdaに紐付いているENIが削除されるまで待機しているのが原因のようです。

対応としては(本来やって大丈夫かはともかく)コンソール上でENIのリストからLambdaに紐付いているENIを削除することで、遅延を減らすことができます。
Serverless Frameworkではstack削除時に並行してENIを削除するためのプラグインも公開されています。

まとめ

CloudFormationは便利な半面扱いづらい箇所も多く、使えば使うほど、悩まされる部分も増えている気がします。
今後も何かしら気づいた点があれば、記事を更新して（ついでにもっと読みやすくして）いきたいと思います