AWS CDK 脱初心者・中級者に向けた第一歩~AWS CDK Tipsまとめ~
概要
CDK脱初心者に向けた、Tips集を書きました。
例えば、以下のようなキーワードを説明します：
- CDKとCloudformation。その違い。
- L1, L2, L3コンストラクタ。
- 効率的なデプロイ手順
- その他（CDKの最小権限、Amazon Q Developer）
※筆者も脱初心者に向けて勉強中です。
対象読者
以下の人を想定しています。
- CDKの抽象度の違い（L1, L2, L3）などが理解しきれていない
- ハンズオンで簡単なサーバーレスアプリを作ったけど、次に進む方法がわからない
前提的なこと
環境構築とハンズオンを最低一回やる
やや当たり前ですが、一応書いておきます。
以下が参考になります。
公式のハンズオン
基本的な概念を理解しよう
CDKの理解を深めるために、以下に記載した概念を理解しておくとよい。
用語解説（IaC, CDK, CloudFormation）
よくある用語は以下の通りです：
| 用語 | 説明 | CDKとの関係 |
|---|---|---|
| IaC | Infrastructure as Code。インフラの設定をコードで管理しましょうという考え方・仕組み。 | AWSに限らない一般的な用語であり、CDKもIaCの一つ |
| CDK | 自分の好きなプログラミング言語で、AWSのリソースを定義できる仕組み（IaC） | - |
| Cloudformation | yaml形式で、AWSのリソースを定義できる仕組み（IaC） | CDKのコードは一度Cloudformationに変換されてからデプロイされる |
| SAM | サーバーレスアプリケーションのCloudformationを少し簡単に書ける仕組み | 直接的な関係はない。ただし、SAMとCDKを連携させてローカルテストする方法もあるらしい |
| SDK | プログラムからAWSリソースを操作するためのライブラリ | 名前が似ているだけで関係ない。IaCでもない。例えば、Pythonで使えるboto3がある。 |
補足を入れると、Cloudformationで定義するリソースはAWSリソースと一対一に対応している。
- 例えば「VPCを定義するCloudformation」には、VPCとInternet Gatewayと"VPCとInternet Gatewayの紐づけ"という3つのリソースが定義される（他にもSubnet, Route Table, Route Tableの紐づけなどなど）
- AWSのコンソールでの操作感とかなり乖離があり、Cloudformation特有の難しさがある
一方で、CDKにはもう少し便利な仕組みがある（詳細は次節）
用語解説（L1/L2/L3コンストラクタ）
CDKには、L1/L2/L3コンストラクタの3種類がある。
※コンストラクタとは、CDKの中でAWSのリソースを定義するためのメソッドのようなもの
詳しい説明はこちらの記事などが参考になるが、ざっくりと以下のイメージ：
| コンストラクタ | 説明 | 補足 |
|---|---|---|
| L1 | Cloudformationと粒度で、AWSリソースを定義するコンストラクタ |
Cfnxxxという名前。例） CfnVpc：VPCそのもの（サブネット等は別）を定義してくれる |
| L2 | L1より高い抽象度でリソースを定義できるコンストラクタ。イメージは、コンソール上で操作する単位に近い。 | 名前にプレフィックスがない。 例） Vpc：Internet Gatewayやサブネットなど一括で定義してくれる |
| L3 | L2よりさらに高い抽象度で、Lambda+API Gatewayといった典型パターンを定義できるコンストラクタ | 例）ApplicationLoadBalancedEc2Service：ECS+ALBの典型パターンを一気に定義してくれる |
そして、L2を使うのがおすすめである。なぜなら、
- L1は細かすぎて使いにくい（CDKを使うメリットがあまりなく、Cloudformationとほぼ同じである）
- L3は色々（勝手に）設定されるのでわかりにくく、やや柔軟性に欠ける。特に、勉強という意味でも、色々設定されるのは理解しづらい。
- 中間のL2がちょうどいい。コンソール操作と抽象度が近く、理解しやすい。
ちなみに、L2, L3は明確な命名規則がない（たぶん）
L2は"コンソールでよく見るサービス名"、L3は"サービス名の組み合わせ"という感じである。また、L3はaws_ecs_patternsのようなモジュールでまとまっていることもある。
L1/L2/L3コンストラクタの具体イメージ
コード例と簡単な補足です。
※ChatGPTに書いてもらったので、動かないかもしれないです
L1: CfnVpcを使った場合
L1はCloudFormationリソースとほぼ一対一対応しており、設定も細かく指定する必要があります。
import * as cdk from 'aws-cdk-lib';
import { CfnVpc } from 'aws-cdk-lib/aws-ec2';
const app = new cdk.App();
const stack = new cdk.Stack(app, 'L1VpcExample');
new CfnVpc(stack, 'MyVpc', {
cidrBlock: '10.0.0.0/16',
enableDnsSupport: true,
enableDnsHostnames: true,
});
このコードでは、VPCの基本的な設定しか行えないため、サブネットやルートテーブルなどを別途手動で定義する必要があります。
L2: Vpcを使った場合
L2はより高い抽象度を持ち、VPCと関連リソースを簡単に一括で定義できます。
import * as cdk from 'aws-cdk-lib';
import { Vpc } from 'aws-cdk-lib/aws-ec2';
const app = new cdk.App();
const stack = new cdk.Stack(app, 'L2VpcExample');
new Vpc(stack, 'MyVpc', {
maxAzs: 2, // 使用するアベイラビリティゾーンの数
cidr: '10.0.0.0/16',
});
このコードでは、サブネットやルートテーブル、NATゲートウェイなどが自動で設定され、さらに細かい設定もオプションで調整可能です。
L3: ApplicationLoadBalancedFargateServiceを使った場合
L3はさらに高い抽象度を持ち、よく使われる設計パターンを簡単に構築できます。
import * as cdk from 'aws-cdk-lib';
import { ApplicationLoadBalancedFargateService } from 'aws-cdk-lib/aws-ecs-patterns';
const app = new cdk.App();
const stack = new cdk.Stack(app, 'L3Example');
new ApplicationLoadBalancedFargateService(stack, 'MyService', {
taskImageOptions: {
image: ecs.ContainerImage.fromRegistry('amazon/amazon-ecs-sample'),
},
});
具体的な進め方
CDKを勉強するために、実際に触ってみることが重要である。
ただし、初心者あるある(?)の"何から手を付けていいかわからない状態"に陥らないため、以下に進め方の方針を記載する。
テーマ設定のコツ
これもあるあるだが、何かテーマを決めて、それをAWSで作る（=CDKでリソースを定義する）ことから始めるとよい。
ちなみに、テーマは具体的なサービスとかではなく、それっぽいものなら良いと思う。
例えば、Webサイト（具体的な中身は適当）を作る。
- S3バケットを作成し、静的ウェブサイトをホスティングする（シンプルなHTMLを配置する）
- ECS+Fargate（Next.jsのサンプルコードを動かしてみる）
あくまで、CDKを理解することが目的なので中身は何でもよい。
※やや蛇足だが、LambdaやAurora、Dynamo DBなど、どんどん拡張していくのも楽しい。
アーキテクチャ図を描く
決めたテーマに関して、アーキテクチャ図を描く。
※drawioなど、何でもよい。少し本記事の内容からそれるため詳細は割愛。
これから作るものの全体像を把握しつつ、"CDKでどんなリソースを定義しないといけないか？"を理解しながら進めることが目的である。
とりあえず動くコードを書く（すぐデプロイ）
ここから具体的なCDKのコードを書いていくフェーズである。
まずは、先述のL2コンストラクタを使ってリソースを定義して、（細かい設定はしないまま）すぐにデプロイすることをお勧めする。
さらに言うと、
- （作りたいリソースの）サンプルコードをググる
- コピペする
- デプロイする
くらいでよい。
補足：すぐデプロイする理由
簡単に言うと、CDKのデプロイに時間がかかるので、とりあえず動くものを作った方が良いからである。
例えばAWSコンソールで操作する場合は、基本的にはわかりやすいので、初めから色々設定してデプロイすることができる。
たとえ設定ミスがあっても、すぐにエラー表示されるので、比較的簡単に修正してデプロイできる。
ただ、CDKの場合はそうではない（特に初心者の場合は）
最初のコンパイルでエラーになるならまだ良いが、デプロイ後にエラーが発生する場合も多い。特に、デプロイに数分（ロールバックも数分）かかり、トライアンドエラーしているとあっという間に時間が過ぎてしまう（最悪の場合、挫折して終わる…）
そのため、最初に"デプロイが成功する状態"をつくり、少しずつコードを修正するのが、効率的に進められると感じている。
ちなみに、デプロイを成功させる（=成功体験を得る）というのも、大きなメリットである。
また、以下のような流れも良い：
- CDKでデプロイする
- コンソールで設定変更する
- CDKに反映する
- CDKで再デプロイする
- 所望の設定になっているか確認する
慣れていれば、2の手順は不要だが、いきなりCDKのコードをいじるよりも、コンソールの方がわかりやすいのでおすすめである。
ただし、2でリソースをいじる際の注意点がある（後述）
設定を試行錯誤する手順
CDK関連のブログ記事は多いが、結局公式リファレンスを見るのが確実である。
前節を踏まえて、以下のような流れで実装を進めるとよい：
- とりあえずサンプルコードを動かす
- コンソール等を見ながら設定箇所を理解する
- 公式リファレンスでどのパラメータを設定すれば良いか確認する
- コードに反映する
公式リファレンスを使うコツだが、
- 使用するコンストラクタ等が明確な場合、そのページを探してみつける
- コンストラクタ等がわからない場合、定義したい「CDK + AWSのリソース名（英名）」でGoogle検索してみつける。
- ページが見つかったら、変更したい設定箇所を見つける。やや勘と検索力が必要だが、概ね以下の2通りであることを理解しておくとよい
- コンストラクタの引数（Construct Props）で指定する。例）EC2のIAMロールを指定する。
- コンストラクタでリソースを定義した後にメソッド（Methods）を使う。例）EC2にセキュリティグループを指定する
※ちなみに、サンプルコードはブログ記事で探したほうが良いと思う（理由：わかりやすいから）
デプロイ時の注意点
リソースをコンソールで編集する際の注意
CDKでデプロイしたリソースをコンソールで変更する場合の注意点を説明する。
それは、CDK destroy（リソース削除）のときに失敗することがあることである（依存関係をいじってしまうとダメらしい）
このとき、cdk deploy, cdk destroyをやり直しても（削除に失敗した状態のスタックがあるため）失敗する。
この場合は、コンソール上でリソースを削除したうえで、コンソール上でCloudformationのスタック削除（強制削除）という流れで解決できる（はず）。
CDKでデプロイしたリソースのタグ活用
リソースにタグを付与することで、CDKのリソースを区別しやすくできる。
以下のようなコードで、CDKリソースに一括でタグを付与することも可能：
Tags.of(myConstruct).add('key', 'value');
retainOnDeleteオプションを理解する
特定のリソースを削除対象から除外する設定。
データを保存する系のサービス（S3, DBなど）はデフォルトでONになっている場合が多いらしい。
個人開発の場合は、全リソースを削除したい場合もあるので（お金がかかるので）、ここの設定は注意するとよい。
逆に、削除対象から外したい場合も当然活用する。
他にも試してみる！
ここからは補足的な話で、これも試してみると面白いという話です！
CDKを最小権限で利用する
個人開発や勉強でやるなら、広めの権限を使用していてもよい。
が、最小権限でやってみるというのも良い。
詳細は、以下の記事が参考になる：
Amazon Q Developerを使う
最近ブームの生成AIサービスで、使わない手はない。
とりあえず、vscodeの拡張機能を入れてみることを勧める。
無料枠があり、CDKコードを一から生成してもらうことも、既存のコードを修正してもらうことも可能で、結構便利。
ただし、一発で所望のコードが得られない場合も多いので、ある程度CDKを読む力も必要である。
Discussion