プロポーザル

AWS CDKの採用事例で語られる利用方法と現場のギャップに悩んだことはありませんか？ 私はあります。

CDKによって得られるはずのベネフィットがなぜ自分のチームで得られないのか？ CDKはなぜCloudFormationの完全上位互換ではないのか？ CDKConferenceで2年お話しし、CDKに50回以上Contributesした私が、CDKを選定しなかった理由とは何か？そこから見えるCDKのPros/Consとは？というお話をさせていただきたいと思います。

AWS CDKは、プログラミング言語で表現することのできる、AWSが誇る画期的なIaCツールです。
プログラミング言語で書けるが故に自由度の高い拡張性や汎用性を実現できるものの、それらをうまく表現するには様々なコード設計の選択が伴ってくるのもまた事実です。
特にCDKには特有の「コンストラクト」という概念などを通して、非常に高い再利用性を表現できる仕組みがあります。

しかし、「この再利用性を具体的にどう表現するのか？」といったセオリーはまだあまり世には広まっておらず、各個人・組織での秘伝のタレとなっているような状況もあるようにも思えます。

そんなCDKにおける再利用性に関して、できるだけ具体的に・かつ属人性を排除して扱えるように、一つずつポイントにフォーカスして、CDKユーザーの皆様が「再利用性」を担保できるIaCコードを実現可能にするためのアプローチをお話したいと思います。

AWS CDK のコード分割手法にはコンストラクトを利用した手法があり、現在ではコンストラクトを利用した手法が一般的になりつつあります。更に言うと、このコンストラクトの分割戦略にも様々な手法があり、私はその中でも AWS CDK の L1 やL2 といったレイヤーを意識した分割戦略をよく利用します。この分割戦略を私は「レイヤーリスペクトパターン」と呼んでおり、レイヤーリスペクトパターンを採用することによるメリットとデメリット、及びその実践方法を紹介します。

想定聴講者： AWS CDK アプリケーション開発の経験が1年以上ある方、コンストラクト分割戦略に関心のある方

AWS CDKの重要な利点の一つは、コンストラクトプログラミングモデルによる高い再利用性です。自作のCDKコンストラクトをライブラリ化することにより、開発者間での再利用をさらに促進することができます。最近特に注目を集めている開発組織効率化の観点からも、強力な手段となるでしょう。このセッションを聞けば、コンストラクトライブラリ開発に際して必要な最新の情報が整理され今すぐライブラリ開発を始められるようになります。また、自身でも複数のコンストラクトを開発・公開する筆者の視点から、よりライブラリの価値を高めるために意識したいことや、開発・メンテナンスに関するTipsを紹介します。

弊社のSREチームでは、EC2上で動いている20年物のモノリシックなアプリケーションから、コンテナ基盤への移行およびCICDパイプラインの整備を数年がかりで進めています。

プロジェクトの開始当初、チームメンバーの多くがCDKとTypeScriptの経験が浅く、インフラリソースの管理も不十分な状態でした。
しかし、CDKの導入によってインフラ構成の可視化が進み、構築作業の抜け漏れも減少しつつあります。

本セッションでは、以下の内容を中心にご紹介します。
・コンテナ構築のフローをCDKによって標準化・自動化した取り組み
・100台近いコンテナを少ないコードで管理する為の工夫
・複数人でのCDK開発を実現する為の取り組み

組織でのCDKの導入や推進に際し、本セッションが事例として参考になれば幸いです。

AWS CDKには「CDK Pipelines」という、AWS CodePipelineでAWS CDKのデプロイ環境をシンプルに作成するためのL3 Constructが提供されています。

しかし、このCDK Pipelinesについて、
・ aws_codepipelineと何が違うの？
・ self-mutateの仕組みや使い方が全然わからない...
・ そもそもCDK Pipelinesってなに？

といった意見も多く、正直使いにくい...と感じている方も多くいらっしゃるのではないでしょうか？

そこでこのセッションでは、私が実際に新規プロダクトでCDK Pipelinesを採用した経験を元にこれらについて説明しながら、実際にCDK Pipelinesをプロダクトに導入する際のユースケースやノウハウについて紹介したいと思います。

「AWS CDKに興味を持ったけれど、なかなかコードを書き始められない」と悩んでいませんか？CDKは簡単に始めることができますが、メンテナンスしやすく、壊れにくいコードを書くためには覚えておきたいプラクティスがあります。しかし、すべてのエンジニアがインフラ構築やプログラミングに精通しているわけではなく、CDKのスタート地点は人それぞれです。このセッションでは、AWS IaCのエキスパートとして多くのお客様を支援した経験と個人的な思いを織り交ぜて、CDKのコードを書くために最初におさえておきたいベストプラクティスをやさしく解説します。

2023年6月にEC2 Instance Connect Endpointがリリースされました。これはVPC内のEC2インスタンスに対するSSHまたはRDP接続が、容易に実現できるサービスです。
CDK公式でのL2コンストラクトは存在していませんでしたが、2024年5月にコミュニティ主導のCDKコンストラクトライブラリであるopen-constructsにてL2が使用可能になり、非常に簡単にEIC Endpointを作成することができるようになりました。

このセッションでは実際にプライベートサブネット上のEC2インスタンスへのSSH接続を行う例に加え、RDSへのDB接続もEIC Endpointを介して行えることをCDK実装例も併せて紹介します。
VPC内リソースへのあらゆる通信を、踏み台無しで実現できる可能性を秘めた素敵なサービスですので、多くの開発者に刺さる内容のはずです！

JAWSDAYS2024、ご参加いただきありがとうございました。
JAWSDAYSのティザーサイトは、フロントエンドはNext.js+S3+CloudFrontでホスティング、バックエンドにはAWS CDK（TypeScript）を用いたLambdaやDynamoDB等で構築しており、全てサーバーレス系のサービスで構築しています。フロントエンド・バックエンド共にTypeScriptを採用し、Monorepo構成とすることで、リポジトリ横断で型の恩恵を受けつつ、CI/CDパイプライン（GitHub Actions）のスリム化、パイプラインでの自動テスト等、持てる知識を全て投入しました。
上記の他にもbiomeやNxといったライブラリを採用してみてどうだったか？サポーター瞬殺撃のタイミングでリソースはどうなっていたのか？ パフォーマンスを改善するためにどんな工夫を加えたか？ などをお話します。