はじめに
日々の業務の中で、インフラの手作業に時間を取られてしまうことがあります。
近年では、「インフラもコードで管理する（IaC: Infrastructure as Code）」 という考え方が浸透してきており、
私の所属組織でも、AWS Cloud Development Kit（CDK） を導入し、運用の効率化と“トイル（Toil）”の削減に取り組み始めました！
本記事では、自分の学習メモも兼ねて、AWS CDKについて学んだことをまとめてみました。
インフラストラクチャ・アズ・コード（IaC）とは
インフラの設定をコードで書いて管理する方法です。
手作業とIaCの比較
手作業：
- AWSのコンソール画面にログイン
- 手動で設定（例：EC2インスタンスを作成、S3バケットを作成）
- 設定内容をドキュメントに記録
- 次回も同じことを繰り返す
IaC：
1.必要なインフラをコードで記述
2.コードを実行
3.自動的にインフラが構築される
4.変更があれば、コードを更新して再実行
AWS CDKとは
AWS Cloud Development Kit（CDK）は、使い慣れたプログラミング言語でクラウドリソースを定義できるオープンソースのフレームワークです。コードからCloudFormationテンプレートを生成し、AWSリソースをプロビジョニングします。
AWS CDKのメリット
-
開発者体験の改善
- TypeScript、Python、Java、.NET、Goなど多言語サポート
- 使い慣れた言語とIDEの活用（コード補完、型チェック、ユニットテスト）
- リソース間やスタック間の依存関係の自動解決
-
アプリ全体をコードで定義
- Lambda関数コードやコンテナイメージなどのアセットを一緒にデプロイ
- CI/CDパイプラインの自動構築
- 複数のAWSアカウントやリージョンへのデプロイ
-
抽象化と再利用
- ベストプラクティスに基づいた複雑な設定の抽象化
- 必要に応じて低レベルな設定も可能
- モジュール化によるチーム内での共有
AWS CDKのコンセプト
AWS CDKのコア概念は以下の3つ
- Constructs: 柔軟に構造を表現するためのコアフレームワーク
- AWS CDK Lib: AWSのリソースを定義するための標準的なコンストラクトライブラリ
- AWS CDK Toolkit (CLI): CDKアプリケーションを操作するためのコマンドラインツール
アプリケーション構造
AWS CDKアプリケーションの階層構造について
- App: アプリケーション全体をまとめるルートとなる概念。
- Stack: CloudFormationスタックに対応し、デプロイの最小単位。
- Construct: AWS CDK において最も重要な概念。一つ以上の AWS リソースを表現します。
Constructの抽象化レベル
Constructには3つの抽象化レベルがあります
- L1 Construct: CloudFormationテンプレートをそのままコード化したもの
- L2 Construct: ベストプラクティスと安全なデフォルト値を含む抽象化されたコンストラクト
- L3 Construct（パターン）: よくある構成をまとめた高レベルな抽象化
例えば、S3バケットをL2コンストラクトで定義すると、適切なデフォルト値が設定され、バケットへのアクセス許可も簡単なメソッドで記述できます。
CDKでのベストプラクティス
適切な抽象化レベルの選択
- 基本的にはL2コンストラクトを使用
- 複雑な設定が必要な場合はL1コンストラクトに降格
- 共通パターンはL3コンストラクトまたは独自コンストラクトとして抽象化
機能不足の対処法
- L2コンストラクトがない場合はL1コンストラクトを使用
- L2コンストラクトの機能が足りない場合は
Construct.node.defaultChildでL1コンストラクトを取得 - CloudFormationに対応していない機能はカスタムリソースで対応
コンストラクトの再利用
独自のコンストラクトライブラリを作成して組織内で共有することで、ベストプラクティスやセキュリティガードレールを標準化できます。
まとめ
AWS CDKは、使い慣れたプログラミング言語でAWSリソースを定義できるフレームワークです。CloudFormationの宣言的なアプローチを維持しながら、プログラミング言語を活用することで、より柔軟で再利用可能なインフラコードを作成できます。