4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

備忘録まとめ記事:頭の中のモヤモヤを整理し、AWS CDKでTypeScriptが主流な理由を考察してみた

Last updated at Posted at 2025-01-05

はじめに

この年末年始は、AWS CDK (Cloud Development Kit) についてキャッチアップする予定でしたが、つい他のことを優先してしまいました(笑)。

普段は、CloudFormation や Terraform といった Infrastructure as Code (IaC) ツールを使うのが好きです。

しかし、少し前にAWS CDKを触った際、うまくいかなかった部分がありました。その原因がようやく分かったので、備忘録として整理することにしました。

技術的な検証記事ではありませんが、温かく見守っていただけると幸いです。

記事を書こうと思ったきっかけ

最近、あまり勉強してこなかったAWS CDKについて、詳しい方に質問する機会がありました。

その中で、以前検証した際に感じていた違和感の正体について、自分なりに理解することができました。

私の理解が完璧かどうかはさておき、納得することができたので、この内容を備忘録としてまとめておこうと思います。

まず、AWS CDKについて

AWS Cloud Development Kit (AWS CDK) は、コードでクラウドインフラストラクチャを定義し、AWS CloudFormation を通じてリソースをプロビジョニングするオープンソースの開発フレームワークです。

AppStacks.png
引用画像:https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/home.html

AWS CDKについては、過去の記事で概要の理解やPythonを使った簡単なVPC周りの作成を試した内容を2回ほどまとめています。

そちらの記事を読んでいただけると幸いです。

また、私が受講しているITスクールの方が書かれた、とても参考になる記事がありますので、ぜひ一度目を通してみることをおすすめします。

実際に私が感じていたことをまとめてみた

正直なところ、この疑問は公式サイトやインターネット上にたくさんの文献があり、単純に自分が調査を怠っていただけだと思います(笑)。

img_awsgeek-aws-cdk_01.6c7f97729a059cb6953d84bd19852e1bb7f89f6d.png
引用画像:https://aws.amazon.com/jp/builders-flash/202309/awsgeek-aws-cdk/

そこまで調べなかったことはさておき、ここでは自分が感じた疑問を整理してみます(笑)。

私が感じていた疑問:その1

VPCやサブネットについてはおそらく明示的に指定して作成していましたが、それ以外のルートテーブルについては特に意識せずに設定していました。

その結果、複数のルートテーブルが意図せず作成されるという事象が発生しました。

以下の画像の通り、VPCやサブネットについては想定通りに作成されているものの、ルートテーブルが意図せず大量に作成されていました。

スクリーンショット 2024-12-28 19.42.27.png

教えていただいたところ、AWS SDKにはデフォルト値が設定されており、明示的に指定しない場合はそのデフォルト値が自動的に採用されることが分かりました。

なるほど、こういう仕組みだったのか!」と納得することができました。

私が感じていた疑問:その2

普段、インフラのコードを書く際には、Lambda関数でPythonをランタイムとして選択することが多いです。

そのため、私はTypeScriptなど他の言語をあまり学んでおらず、今回もPythonを使って過去の記事で技術検証を行っていました。

しかし、AWS CDKについては、TypeScriptを使用している人が多いという印象を持っていました。

これまでその理由を深く追求することはありませんでしたが、せっかくの機会なので、「なぜAWS CDKではTypeScriptが選ばれることが多いのか」という観点で、少し調べてみることにしました。

AWS CDKでTypeScriptが選ばれる理由

ここからはインターネット上の文献を参考にしながら、自分なりにまとめて整理しました。

今回参考にしたサイトのリンクも掲載していますので、詳しく知りたい方はぜひ確認してみてください。


  • CDKのネイティブ言語
    TypeScriptはAWS CDKが最初にサポートした言語であり、公式のサポートが最も強力です。他の言語よりも早く新機能や更新が反映されます。

  • 型安全性
    TypeScriptは静的型付けをサポートしており、型チェックを通じてエラーを早期に検出できます。これにより、より信頼性の高いインフラコードを記述できます。

  • 開発体験の向上
    TypeScriptは優れたIDEサポート(例えばVS Code)を提供しており、自動補完やエラーの検出が効率的に行えます。これにより、開発体験が向上します。

  • コミュニティとドキュメントの充実
    TypeScriptはCDKコミュニティで広く採用されており、サンプルコードや学習リソースが豊富に存在します。

これらの理由により、AWS CDKを使う際にTypeScriptが広く選ばれていることに納得できました。

それでも、AWS CDKは難しいと感じてしまう

やはり、私自身が普段の仕事でプログラミングやコードを書く機会が少ないため、AWS CDK特有の概念や考え方をまだ具体的にイメージすることができていません。

また、「コンストラクト」や「抽象化」といった考え方も、明確に理解できていない状態です...。

一方で、CloudFormationのJSONやYAMLについては、AWSリソースをベースに詳細な設定を組み立てる仕組みのため、頭の中でイメージを言語化しやすく、それを実際にコードとして書き起こすことができます。

今後どこかで時間を確保し、しっかりと取り組みたいと思っていますが、一旦ここで学習をストップしようと思います。

まとめ

私自身、AWS CDKについては以前から興味がありましたが、実際に触れてみた感想としては「やっぱり難しい...」というのが正直なところです。

その理由としては、やはりCloudFormationやTerraformを使った構築に慣れてしまっていることが大きいと感じています。

普段慣れた方法と比較すると、新しい概念や抽象化の考え方が大きなハードルとして感じられました。

とはいえ、今回、以前から興味を持っていたAWS CDKについて質問させていただく機会があり、とても楽しい時間を過ごすことができました。

たくさん質問をしてしまいましたが、丁寧に教えていただき、本当にありがとうございました!!

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?