2024.08.27

CDK導入、そこまで頑張らなくていいです~CDKが「不要」になるケース~

Agaroot IT Partners(AITP)のtomoです。

今回はCDKを利用してきた経験をもとに、CDKを使わなくともマネジメントコンソール画面などからの操作で十分事足りるケースを紹介します。
後半部分に補足としてCDKのメリットについても触れますので、CDKを利用するかどうか検討する際の参考にしていただければと思います。

尚、前述の通り(まだまだCDKをマスターしたとは言えない私の)経験則を紹介する記事になりますので、異論や読者の皆様の感覚と違う点もあるかと思いますが、その点はご容赦ください🙏

この記事はこのような方におすすめ

CDK導入を検討している方
CDK(あるいは総じてIaC)のメリットを知りたい方

結論

マネジメントコンソール画面などでサクッと終わるリソースの変更や一部サービスにCDK導入は不要
それ以外(大抵のケース)はCDK(IaC)の導入を是非おすすめします

CDKが「不要」になるケース

私がAWSの各サービスやCDKを利用してきた中で「これには流石にCDKを利用しなくていいな」と思ったケースは、大きく分けて2つに分類できます。

既存リソースの微細な変更
一部サービスの利用

それでは順に説明していきます。

既存リソースの微細な変更

(言わずもがなですが、)例えばEC2インスタンスの終了保護の変更など、CDKなどIaCによって構築されていない既存リソースの微細な変更にわざわざCDKを利用する必要はないでしょう。

特に下記のような条件が重なる場合、その既存リソースの変更にCDKを利用する必要はないと考えた方がいいかと思います。

マネジメントコンソール画面などから簡単に設定が終わる
操作を誤るリスクが低かったり、たとえ誤っても影響が少ない
CDKで構築されている(する予定の)リソースとの関連はない(例えば、既存のDynamoDBテーブルからのデータ取得権限をCDKで構築されたLambda関数に付与する、といったことはしない)

一部サービスの利用

私が出会したケースでは、SPAやSSRを利用したアプリなどのデプロイに役立つAmplifyホスティングやアプリへのアクセス解析ができるCloudWatch RUMの構築が該当します。これらのサービスについてはわざわざCDKを導入する必要はないでしょう。

理由は2つあります。

マネジメントコンソール画面での操作が十分に分かりやすい
どちらのサービスもマネジメントコンソール画面のUI/UXが十分に分かりやすく、おそらくAWSはおろかIT初心者でも問題なく構築できます。私の前職でもAWS初心者の方が「Amplifyでの構築、簡単に終わりましたよ」と言って、CodeCommitと連携したパイプライン付きのアプリをサクッと構築していました。
L1コンストラクトしかない(CDKでの構築に手間がかかる)
どちらのサービスもCDKで構築するとなると、L1コンストラクトというCloudFormationにより近い、あまり抽象化されていない実装方法で構築するしかありません(L1コンストラクトの詳細についてはこちらをご参照ください)。

上記によるものか、他サービスの場合大抵調べるとCDKでの構築事例を載せたブログなどが沢山見つかるのですが、上記2サービスについてはあまり見かけません。

余談ですが、Amplifyに関してはGen 2になってから「CDKによって構築するサービス」というよりむしろ「CDKを組み込んで広範にわたるエコシステムを構築するサービス」となりました。CDKの導入を検討している方は、Amplify Gen2も検討されてみてはいかがでしょうか。

他ケースには是非CDKやその他IaCのご利用を

上記で紹介したケース以外では是非CDKなどのご利用をおすすめします。私もCDKを利用して、リソースの迅速かつ確実な構築が出来るメリットを日頃から感じています。

リソースの迅速な構築

定番のリソースを1から構築する場合には、ものによってはテストコードなどこだわらなければマネジメントコンソール画面での操作にかかる所要時間の半分以下でCDKによって構築できます。少なくとも
CDKでの所要時間 ≦ マネジメントコンソール画面での所要時間 となることが多い気がします。

良く「慣れればCLIで操作した方がマネジメントコンソール画面で操作するよりもサクッと終わる」と言われますが、CDKにも似たような感覚があるかもしれません。特にAPI GatewayやECSなどの構築は私にはマネジメントコンソール画面のUI/UXが分かりにくく、むしろCDKの方が分かりやすく感じます。

またCDKであれば手順書の作成も殆どの場合で不要ですし、少しの差異しかない環境を複数用意する場合にはコードを再利用することができます。

リソースの確実な構築

CDKならばコードなのでGitのPRなどを用いてコードレビューを他メンバーに依頼することも可能ですし、手動での操作は行うとしてコマンドを数回叩く程度なのでデプロイ時のミスもほぼほぼなくなります。またテストコードやコード解析などを導入すれば更なる品質担保につながるでしょう。

まとめ

いかがだったでしょうか。今回は敢えてCDKが「不要」なケースについて取り上げてみましたが、もちろん、既存リソースの微細な保守管理などCDKによるメリットがあまり得られないケースでは無理にCDKを導入する必要はないと思います。

また、メリットの考察を通してCDKが広範なケースにおいて有効的であるとも再確認できたのではないでしょうか。

何はともあれ、本記事がAWSやCDKを導入、利用する際の参考になれば幸いです👋

All Blog