CDKのスタックにタグをつけるときは除外リソースの設定(excludeResourceTypes)に注意する

まえおき

久々のブログ投稿!最近はエンジニア関係ない業務が多く、ネタがあんまりない…。

久しぶりにCDKでリクエストがあって対応したけど、確認せず大丈夫だろうーと思ったら、大丈夫ではなかったので書いてみる。

 

やりたかったこと

  • 全体のスタックにAというタグをつける

  • ただし、特定のAWSリソースについてはAタグではなくBタグをつけたい

 

やったこと

  • 一番上のスタックについて、Bタグをつけるリソース以外にAタグを設定する
    Tags.of(MyStack).add('A', 'AA', exclude_resource_types=['AWS::Xxx::Zzz'])
  • Bタグをつけるリソースに直接Bタグをつける
    Tags.of(MyResource).add('B','BB')

 

デプロイ結果

  • BタグのみをつけるリソースにAタグもBタグもついてしまう

 

理由と回避策

 タグのPriority調整もしてみたが、結局解決できずサポートに問い合わせへ…。理由としてはスタックにタグを付与するとデプロイ時にCloudformationがすべてのリソースにタグを付与してしまうらしい(exclude_resource_typesが適用されない)。また、githubのレポジトリでも議論が行われていること(https://github.com/aws/aws-cdk/issues/16742)。

 スタック以下のレベルでタグを設定したり、逆にinclude_resource_typesを設定する、Bタグをつけるリソースだけスタックを分離ことで回避できるらしい。前の2つはCDKで生成するリソースが多くあるので、別途分離もスタック構成のアーキテクチャを考慮しないといけないので、難しい…。

 結局対応としては、これからCDK変更がほぼないこと、Bタグの適用は期間限定で必要なことから、コンソールから手でAタグを削除することになった。

 

まとめ

 CDKでタグを扱うときはスタックレベルの動作に気を付ける必要があることがわかった。githubのイシューが10月に作られているのにディスカッションが活発でないけど、みんなこんなことにはまらないのかと疑問もある。まあ、スタックレベル指定のタグだと大体は全リソースに適用するものであり、リソースを除くという要件はあんまりないかもしれない。

 また、反省としては新しいもののデプロイはちゃんと確認をしようということ。当たり前なことだけど守られてなかったと反省中。全体コード自体は今まで何回もデプロイして単体テストもやってたので、まさかタグのところでバグるとは思わなかった…(言い訳だけど)。

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

PythonのDict型をDynamoDB形式のJsonに変換する

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった