aws CDKの振り返りや活用機会を考えてみる

昨年７月に参加したJAWS-UG主催のawsCDKハンズオンを皮切りに、CDKの勉強をしています。

昨日はクラスメソッド社主催のaws CDK事情大公開という勉強会に参加してきました。

https://classmethod.connpass.com/event/337711/

ハンズオンに参加した時はどうだったか

このハンズオンでは、CDKの概要と、typescriptを用いてCDKを利用する方法を学習しました。

CDKについて簡潔にまとめるとawsのインフラをtypescriptを用いてコード管理が行えるaws公式のツールといったところです。

なおこれはIaCにカテゴライズされるツールで、Infrastructure as Code（インフラストラクチャーアズコード）と言ってクラウドインフラをコード管理できるツールに該当します。

cloudformationもyamlファイルで構成を定義してawsインフラを構築できるためコード管理自体は可能になりますが、違いとしては、yamlで設定パラメーターが大量に記述されていることになるので、可読性が低く複雑な構成のインフラとなると大量の行数におよびわかりづらい点が利用していた際課題としてありました。（※これについてはterraformも記述量削減とはならないと調べた際の情報にありました）

この点CDKは「設定パラメーターの羅列」ではないので、非常に可読性が高く、構築するインフラがわかりやすいことと、typescriptを用いているので、アプリケーションチックに管理でき、ユーザーフレンドリーです。

このハンズオンの時は、基本的なコマンドやtypescriptの書き方と使い方に関しての学習で、これまで見てきた現場での実運用面に当てはめて考えた時にいくつかの疑問が湧いた状態でいました。

手動でのマネコン設定等による弊害があるのは多く見てきましたが、その問題が解決したとして、別の問題を孕むのではないかという疑問がありました。

aws CDK事情大公開に参加してみて

上記ハンズオンで生じていた疑問が勉強会中のセッションで見事に解決しました。

この勉強会では、CDKを導入している現場での運用例の解説が中心であったので、まさに目的としていた情報を知ることができました。

ハンズオン参加以降に抱いていた疑問を挙げていくと下記のようなものがありました。

誤操作によるインフラの破壊や環境を壊したり削除を防止できるか
CDKの操作や変更が正しいかを検証したり、誤りがないかテストできるか
CDKを用いてベストプラクティスな設計を推奨する仕組みがあるか
セキュリティスキャンを実行できるか
複雑なstepfunctionsに対応できるか
CDKでの設定とその他の手法（マネコンなど）での設定変更の際の整合性や優先度合い

これらの疑問の解が見つかりました。

CDKのtypescriptで定義するclass appstackのパラメーターtermination protaction:trueで防止できる。
cdk-mentor,eslintなどで検証・テストできる
CDK Aspectsを利用する
セキュリティースキャンとしてcdk-nagが存在する
distributed map機能を利用すれば並列ワークロード数が増加する
CDKでの設定で上書きされる（参考：https://dev.classmethod.jp/articles/configure-deletion-protection-for-cloudformation-stack-with-aws-cdk/）

総評

CDKに関してはまだまだ新しい技術ということもあり、２０２５年１月の段階では商業技術書などでの情報は少ない様子のため、非常に貴重な場となりました。

現場の状況や運用体制によっても導入できるかどうかは左右されることがあるとは思いますが、個人的にはcloudformationやマネコン等いくらか触ってきた感じからすると素敵な技術で推していきたいと思っています。