プロポーザル

GO株式会社ではこれから訪れる自動運転社会で求められる鮮度の高い地図データを実現するために、タクシーやトラックにつけられたドライブレコーダーから取得できる情報をもとに、AI技術などを用いて地図と実際の道路情報の差分を自動で抽出し、地図のメンテナンスに活用するプロジェクトを行っています。

本プロジェクトでは研究開発の開始からAWS CDKを採用し、現在では本番環境で50以上、QA環境では100を優に超えるスタックをCDKで管理運用しています。
GitHub ActionsとCDKを組み合わせたCICD環境、検証パターンごとにQA環境を自動生成する仕組みなど4年間の開発運用で得たノウハウや工夫、苦労話を余すところなくご紹介いたします！

App Staging Synthesizerは既存のBootstrapモデルの置き換えを目指し開発が進められているモジュールです。
例えば既存のBootstrapモデルでは、同じAWSアカウントとリージョンにデプロイされるCDKアプリケーションのアセットは共有のS3バケットやECRにアップロードされます。
このモデルはシンプルな一方で、異なるCDKアプリケーション間でのリソース分離は困難になっています。
App Staging Synthesizerはこのような既存のBootstrapが抱える様々な問題点を解決するための仕組みです。

まだまだ開発途中のalpha版であり制限もありますが、いつか安定版になる日に備えて、既存のBootstrapとの違いを中心に利用方法などをご紹介出来ればと思います。

AWS CDKを利用したサービスの運用を行っていく中で、安全にデプロイを行うため、cdk diffコマンドを利用し加えた変更との差分を確認することは非常に重要です。
特にCIパイプラインで実行するようにしているケースも多いのではないでしょうか。

ここ数ヶ月の間cdk diffコマンドには様々な変更が入り、機能の拡張やバグ修正が行われています。
本セッションではそんな進化を続けているdiffコマンドについて以下を中心にご紹介します
・ 主要なオプションと使い方
・ 内部ではどのようなフローで動作しているか
・ 利用する上での注意点
基本的な使い方から内部での動作まで、diffコマンドの挙動をしっかり理解するために必要な情報に触れられればと思います。

CDKを利用するにあたって、複数環境・アカウントをまとめて管理したり、開発規模やスピードに合わせて1つのアカウントの中に複数面が必要になることを考慮するなど、さまざまなシチュエーションに対応できるようにCDKを定義をしたいなと日々考えています。

いままで色々と試行錯誤して来たパターンなどを紹介しつつ、みなさまと当日「こうするとより良いのでは！」というやり方を見つけられたらと思います。

CDK開発中に下記の悩みはありませんか？

• 開発環境用のAWSリソースの課金が気になる
• 開発中のAWSリソースの作って壊しての流れが手間
• 手軽にさわれるAWSリソースの開発環境が欲しい

Localstackを用いると、Docker上に仮想のAWSリソースをエミュレートできます。
このセッションでは、下記についてお話します。

話す内容

• Localstackとは？
• cdklocalとは？
• Localstackを使ってみる
• cdklocalを用いて、CDKのスタックをLocalstackにデプロイしてみよう
• Tips
  • Localstackのリソースブラウザを活用しよう
  • Localstackの無料版と有料版の違いは？

対象者

• Localstackを知りたい・始めたい人
• CDKの開発環境に悩んでいる人

AWS CDKを用いた開発において、セキュリティを考えることは非常に重要です

今回AWS CDKを使用したインフラ構築におけるセキュリティ強化のための
最適なCI/CDパイプラインの設計について考察します

具体的には、CodeQLによる静的解析（SAST）とCheckovによるIaCセキュリティチェックを組み合わせ、
セキュアなデプロイメントを実現します

IAMロールとポリシーの適切な設定、AWS KMSやSecrets Managerを使った機密情報の保護についても触れ、
GitHub Actionsを用いて、コードの変更が行われるたびに自動的にセキュリティチェックを実行し、
潜在的な脆弱性を早期に検出・修正するフローを解説します

AWS CDKのベストプラクティスに基づいた具体的な実装例を通じて、
セキュリティ意識の高い環境の構築方法を学びましょう

私のAWS入門はCDKを用いたサーバーレス開発でした。当時書き慣れていたTypeScriptでAWSリソースを構築できる手軽さ・楽しさはとても魅力的でした。初心者にとって「すぐに動いて楽しい」という感動はとても大きいものです。

さて、今この話をするとCDKでどのように構成していたのか？と問われます。
そこで痛感したのは、"私はCDKについて何も分かっていない"ということです。

エンジニアとして開発の経験・知識を身につけた今、CDKについて学び直し、再入門してみます。そしてその題材として、一年前に書いたCDKのコードを見直したいと思います。

【話すこと】
AWS CDKにまつわる基本的な概念のおさらい
初心者目線でAWS CDKのベストプラクティスを知る
システム開発の経験を通して得た保守しやすいコードの書き方を踏まえてリファクタリングを考える
IaCにおける“個人開発から実務案件へ”

「CDKコントリビュートって上級者がやるものでしょ。」
そんなふうに考えていた時期が私にもありました…

本セッションではコントリビュート初心者の私が実際に約2ヶ月間取り組んだ経験を元に、コントリビュート未経験者・初心者にとって役立つ内容をご紹介します。

・どのようにコントリビュートに取り組んだか
・実際に取り組んでみてどうだったか、得られたこと
・コントリビュートにおいてハマったこと、Tips
・コントリビュートあるある
ほか

本セッションを通して一人でも多くの方がコントリビュートに興味を持っていただき、AWS CDKの発展につながれば幸いです。

2023年にアップデートされたBLEA(Baseline Environment on AWS)のv3.0.0では、これまでのAWS CDKの開発の常識とは異なる新しいベストプラクティスが数多く採用されました。
今回、社内案件の開発で基盤をAWS CDKで構築した際、このベストプラクティスをできる限り取り込んだことで、今まで以上に開発を効率的に進めることができましたので、導入したベストプラクティスとその他一緒に行った工夫点をご紹介したいと思います。

AWS Amplify は Webフロントエンドとモバイルアプリ向けのフレームワーク、ツール群ですが、2024/5/6にGAになった Amplify Gen2 は AWS CDK をベースに新たに作成されたツールです。
Amplifyアプリのバックエンド構築機能を提供する @aws-amplify/backend のアーキテクチャを通してAmplify Gen2がどのようにAWS CDKを利用しているのかについてお話ししたいと思います。そして、どのようなAWS CDKのベストプラクティスが採用されているのかについてもお話しします。

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