AWS CDKはとても便利で、その便利さは色々なところで語られています。今回は敢えてAWS CDKを実際のプロジェクトで使ってみて辛かった点を書いてみます。
L2コンストラクトでは指定できない設定値がある
L2コンストラクトはL1コンストラクトを使う場合よりもコードの実装量が少なくて済む便利なものです。その反面、（このような便利なものにありがちのデメリットかと思いますが）指定できない設定値があります。開発の途中で自分が指定したくなった設定値が指定できないことに気がついた場合にはその時点からL1コンストラクトで書き直すことになり、辛いです。
とはいえこの辛さは緩和できる方法があります。AWS CDKにはL2コンストラクトから直接アクセスできない設定値を上書きする方法があります。具体的な方法は、こちらの記事が分かりやすいです。
ただし、L2コンストラクトが自動生成するLambda関数の設定など、設定値の上書きが難しいものもあります。そこまで指定しようと思う場合にはL1コンストラクトで書き直すかCDKコード外での解決（手動で設定するとか）を考えることになります。
L3コンストラクトでは大幅な手戻りが発生する可能性がある
L3コンストラクトはL2コンストラクトを複数集めてパターン化したようなものです。L2コンストラクトを使うよりもさらにコードの実装量が少なくて済む便利なものです。その反面、指定できる設定値はL2コンストラクトよりもさらに少ないです。また、アーキテクチャーの修正のような設定値の変更以上の修正をしたくなった場合には、L2コンストラクトで書き直すことになり大幅な手戻りが発生し、辛いです。
L3コンストラクトの導入は慎重に、基本はL2コンストラクトを使っていくのがよさそうです。
特定のコマンドのときだけ前処理/後処理をすることができない
例えば、cdk deployの時だけ特定のファイルをとあるディレクトリから別のディレクトリにコピーするといったようなことができません。
特定のコマンドではなくすべてのコマンドのときに前処理/後処理が実行されてもよい場合にはcdk.jsonに下記のように記載すれば前処理としてpre.sh、後処理としてpost.shを実行できます。
"app": "sh pre.sh && npx ts-node --prefer-ts-exts bin/app.ts && sh post.sh"
コードがCloudFormation的な書き方になってしまう
私がこれまでCloudFormationを使ってきたせいか、コードがCloudFormation的な書き方になってしまいます。私はTypeScriptでAWS CDKを書いているので、もっとTypeScript的な書き方をしてかっこいいコードを書きたいと思うものの、なかなかその書き方に慣れません。また、ググって出てくるAWS CDKのコードもCloudFormation的な書き方のものが多く、参考にできるコードが少ないです。
最後に
とはいえAWS CDKの書き心地は最高なので、これからもガシガシ使っていきたいです。