AWS CDKほぼ未経験で勉強会に参加してみた話 〜横浜銀行アジャイル開発チームの学び方〜

📝 はじめに

おひさしぶりです。ふじです。
私が所属している横浜銀行のアジャイル開発チームでは、プロダクト開発だけでなく
メンバー同士で知識を共有する勉強会が定期的に開催されています。

先日、チームメンバーの watariさん が「AWS CDK 勉強会 〜基本と設計思想のベストプラクティス〜」というテーマで、メンバー向けの勉強会を実施してくれました。

私はというと、

• AWS CDK：ほぼ触ったことなし
• IaC：CloudFormation をなんとなく知っている程度

という状態での参加でした。

この記事では、CDK初学者の立場から、特に印象に残ったポイントとして、

• Stack / Construct という考え方
• L1〜L3 Construct の役割分担
• アプリ開発者向けの CDK ロードマップ

を中心に振り返っていきます。

---

🏗 IaCの延長線としてのAWS CDK

勉強会の前半では、IaC（Infrastructure as Code）の背景について触れられました。

Terraform や CloudFormation といった IaC ツールは広く使われていますが、

• 独自構文が多く学習コストが高い
• IDE補完が弱く、書いていてつらい
• 設定が増えるほど可読性が下がる

といった課題もあります。

そこで登場するのが AWS CDK です。

CDK は、

• TypeScript / Python などの 一般的なプログラミング言語で
• AWSインフラをコードとして定義でき
• 最終的には CloudFormation テンプレートを生成する

という位置づけのフレームワークです。

「インフラを“アプリケーションコードと同じ感覚”で書ける」
この説明が、CDK未経験の私にとって非常に分かりやすいものでした。

---

🧱 Stack と Construct ― CDKを理解するための基本単位

今回の勉強会で、特に印象に残ったのがStack と Construct という考え方です。

Stack とは

Stack は、

• １つのデプロイの単位
• CloudFormation の Stack と同じ
• この Stack をクラウドインフラ上に展開してインフラ構築を行う

という存在です。

「このシステムで必要なインフラ一式」をまとめたもの、と考えると理解しやすいです。

---

Construct とは

Construct は、

• Stack 内で定義される単位
• Construct を定義する ＝ Stack の定義を追加していくこと

を表します。

つまり、

• Stack = 箱
• Construct = 中に入れる部品

という関係です。

Construct を定義することが、Stack の中身を追加することにつながるという説明がとても理解が深まりました。

---

🔍 L1〜L3 Construct の役割分担

Construct にはそれぞれの役割があり、これを理解できたことが今回一番の学びでした。

L1 Construct

• CloudFormation と 1対1で対応
• Cfn〜 で始まるクラス
• かなり細かい設定が可能

ただし、
CloudFormationを直接書いている感覚に近いため、「どうしても必要なときだけ使う」という位置づけです。

---

L2 Construct

• L1をより使いやすく抽象化したクラス
• １つのAWSサービスごとに提供されることが多い
• 多くのケースで 基本はこれを使う

「まずは L2 を使えばいい」という明確な指針が示されたことで、CDKへの心理的ハードルが一気に下がりました。

---

L3 Construct

• 複数のリソースをまとめた構成パターン
• 例：ECS Service（LB、Cluster、Task などを一括定義）

「複雑な構成を“まとめて使う”ための仕組み」であり、初学者の段階では無理に最初から使う必要がないと理解できました。

---

🛣 アプリ開発者向け CDK ロードマップが現実的だった

勉強会の後半で紹介されたCDKロードマップ もとても印象に残っています。

ステップ1：小さく始める

• パラメータストア
• Secrets Manager
• 設定値の管理

単体でも存在できるリソースから触ることで、CDK の書き方やデプロイの流れに慣れる、という考え方です。

---

ステップ2：AWSマネージドなPaaS

• S3
• DynamoDB
• CI/CDパイプラインを用いたCDKの実行

AWS が可用性を担保してくれるサービスを中心に、少しずつ範囲を広げていくステップです。

---

ステップ3：ネットワーク・複雑な構成

• VPC
• ECS / EC2
• RDS
• サービス間連携（SQS / SNS）

このステップでは、ネットワーク設計やリソース間の依存関係など、考慮すべき設計要素が一気に増えてきます。

「ロードマップとして示してもらえたことで、今の自分がどこにいるのかが分かりやすく、今後、自分がどのように習得していくべきかも学ぶことができました。

---

🌱 横浜銀行アジャイル開発チームの勉強会文化

今回の勉強会を通して感じたのは、横浜銀行のアジャイル開発チームでは、

• 設計思想に重点を置くこと
• 初学者が置いていかれない構成

が大切にされているということです。

質問にも適宜回答いただき、チーム全体の理解度がかなり上がったことを実感しました。

---

✍️ まとめ

CDK 未経験の状態で参加した今回の勉強会でしたが、

• Stack / Construct という基本概念
• L1〜L3 の使い分け
• 現実的な CDK ロードマップ

を学べたことで、「CDK は難しいもの」から「段階的に学べばチームで使えるもの」という認識に変わりました。

今後はロードマップの最初のステップから少しずつ CDK に触れることで、チームの一員として理解を深めていきたいと思います。