エンジニアチームの往蔵・和山です。
今回は、2024年7月6日(土)に開催された「AWS CDK Conference Japan 2024」に参加しましたので、そのレポートをお届けします！

AWS CDK Conference Japanとは

AWS CDK Conference Japanとは、CDK(Cloud Development Kit)の最新動向やベストプラクティスを共有する、AWS公式の年次カンファレンスです。 主催はJAWS-UG CDK支部で、今年で3回目となるようです。

今回は参加したメンバーより印象に残っているセッションのレポートをお届けします！

印象に残っているセッション（往蔵）

私が特に印象に残っているセッションはAWS CDK コンストラクトの分割戦略：レベル指向プラクティスの実践です。

AWS CDKのコードを分割する際、コンストラクトと呼ばれるCDKの単位を利用することで、効率的に分割できます。コンストラクトには、公式から提供されているものもあれば、自分で定義するものもあります。

公式のコンストラクトは、抽象度に応じてL1, L2, L3のレベルに分かれています。自分でコンストラクトを作成する際に注意しなければならないのは、特定のサービスのためだけのものにしてしまうと再利用性が低くなってしまうことです。再利用性と抽象化の恩恵を最大限に享受するためには、特定サービス専用のコンストラクトを作成するのではなく、公式が提供するL1, L2, L3のレベル指向のプラクティスを参考にすることが重要だと紹介されていました。

このセッションでは、再利用可能性を重視したコンストラクトの作成方法について詳しく説明されており、非常に参考になりました。私の携わっているプロジェクトでも、CDKのコードの再利用性について議論することがあるので、このセッションの内容をぜひ参考にしたいと思いました！

印象に残っているセッション（和山）

私の印象に残っているセッションは初心者が押さえておきたいAWS CDKのベストプラクティス2024です。

このセッションでは、CDKを使い始めたエンジニア向けに、CDKの基礎知識をカバーするためのプラクティスが紹介されていました。ソフトウェア開発の基本10選、AWS CDKの基本10選の合計20選紹介されています。今回は特に気になったプラクティスを2つ紹介いたします。

Gitリポジトリとチームの境界をあわせる

このプラクティスは、1Gitリポジトリに1CDK Appを原則とするプラクティスです。

リポジトリの中に複数のCDK Appが同居するとデプロイするときの負荷が高まることや、スタック間参照で依存関係が生じることで開発・運用上で面倒を引き起こすことが多くなります。 （スタックの分け方については同セクションの別プラクティスでも紹介されています）

私たちのチームは、リポジトリによって1CDK Appだったり、複数のAppを定義したりしています。現状の運用が曖昧な状況であると気づきました。 このセクションを通じて、改めてチーム内で戦略を立て直していきたいと思いました。

パラメータはAppレベルから注入する

このプラクティスは、StackやConstructから外部パラメータを参照しないようにするプラクティスです。具体的には、外部設定をトップレベルにし、App、Stack、Constructの順にプロパティを渡す形になります。

外部パラメータの具体例は環境変数が挙げられると思います。環境変数を直接StackやConstructに記述すると次のデメリットが生じます。

• テストが難しくなる

• コード上に環境変数が散在し、どこで何が定義されているのか分かりにくくなる

私たちのチームは、ちょうど外部パラメータの取り扱い方法に関して検討していたところでした。このプラクティスを参考にし、さっそくチームで実践していきたいと思います。

全体の感想

今回のカンファレンスは、初心者向けにベストプラクティスや各登壇者の経験談、中級者以上にはコントリビュートやConstructの作成方法などについての話題が中心だった印象を持ちました。 とても学びのある良いセッションで構成されており、個人やチームに還元できることが多いと感じました。

今後もCDKに関する知識やプラクティスは継続的に収集・実践し、チームに還元していきたいなと思います！

最後に、noteの更新情報やスペクティの最新情報は公式Xにて発信しています。ぜひフォローをお願いします！

次回もお楽しみに！