気軽に作ろう！ 自作AWS CDKコンストラクタ Tuesday, March 25, 2025 Haruka Sakihara LayerX SRE & Cloud Native Night! 

自己紹介 Haruka Sakihara <主な取得資格> • ネットワークスペシャリスト試験(IPA) • AWS Certified 全15資格 • Google Cloud Certification 5資格 <所属> • アクセンチュア株式会社 テクノロジー コンサル ティング本部 (2021年新卒入社) • クラウドの部署にいます <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <その他表彰> • 2023 Japan AWS Jr.Champion • 2024 Japan AWS All Certifications Engineer 

CDKのコンストラクタは便利！すごい！ CDKの便利なところは、既存のプログラミング言語でインフラ構成を記述できることだけではあり ません。L2/L3 Constructorの高度な抽象化による記述の簡素化も魅力の一つです。 VPC Availability Zone 1 Availability Zone 2 Public subnet Private subnet Public subnet Private subnet Internet gateway NAT gateway Route table Route table Route table Route table Elastic IP CDK Code (L2 Constructor) Deployed Resources 

CDKのコンストラクタは便利！すごい！ CDKの便利なところは、既存のプログラミング言語でインフラ構成を記述できることだけではあり ません。L2/L3 Constructorの高度な抽象化による記述の簡素化も魅力の一つです。 VPC Availability Zone 1 Availability Zone 2 Public subnet Private subnet Public subnet Private subnet Internet gateway NAT gateway Route table Route table Route table Route table Elastic IP CDK Code (L2 Constructor) Deployed Resources たったこれだけで以下を表現できる！ • パブリックサブネット2個 →IGWも必要 →サブネットのデフォルトGWはここに向ける • プライベートサブネット2個 • NAT1個 →プライベートサブネットのデフォルトGWはここに向ける →NATにアタッチするElasticIPも確保 

自作コンストラクタ作ってみないの？ 私 L2みたいなきれいに抽象化されたインターフェース設計 ぱっとできないしハードル高いかな・・・ 

大丈夫！ 気軽に作ろう！ 今すぐ作ろう！ 

今回作る題材 以下のアーキテクチャをCDKを使って構築するというケーススタディを考えてみましょう。 VPC Availability Zone 1 Availability Zone 2 Public subnet Private subnet Public subnet Private subnet Internet gateway Application Load Balancer Amazon Aurora instance ECS Service Topic Amazon SNS Endpoints LB Security group App Security group DB Security group 

自作コンストラクタを作る前 スタックの中にすべてのリソースを愚直に書くことになります。L2やL3を駆使したとしても、ス タック分割をせずに自サービス関連リソースをすべて書くとかなりの量になります。 1. VPCを作る 2. SNSトピックを作る 3. ECSサービス用のセキュリティグループを作る 4. ALB用のセキュリティグループを作る 5. ECSクラスタを作る 6. ECSタスク定義を作る 7. ECSタスク定義にアプリコンテナを足す 8. ECSサービスを作る 9. タスクロールにSNS Publish権限を付与する 10. ALBを作る 11. ALBリスナーを作り、ターゲットとしてECSサービスを指定 12. ECSサービス用sg/ALB用sg間の通信許可設定を施す 13. データベース用セキュリティグループを作る 14. データベースを作る 15. データベース用sgにECSサービスからの通信を許可する 

自作コンストラクタを作った後 細々としたリソースを自作コンストラクタの中にまとめてあげることによって、スタック全体の見通 しがとてもよくなります。 2. SNSトピックを作る 1. VPCを必要他リソースと共に作る 3. サービスをホストするECSを作る 4. サービスが依存するDBを作る 

自作コンストラクタを作った後 細々としたリソースを自作コンストラクタの中にまとめてあげることによって、スタック全体の見通 しがとてもよくなります。 2. SNSトピックを作る 1. VPCを必要他リソースと共に作る 3. サービスをホストするECSを作る 4. サービスが依存するDBを作る 15ステップ→4ステップに削減！ 自作コンストラクタ 自作コンストラクタ 自作コンストラクタ 

WebUI表示の違い 自作コンストラクタを導入してリソースをグルーピングすることによって、CloudFormationの WebUI上でもそのグループ構造を保ったまま表示されるため視認性が良いです。 自作コンストラクタ導入前 自作コンストラクタ導入後 タブOpen 全リソースがフラットに表示 リソースが自作コンストラク タの単位で階層化されて表示 

自作コンストラクタの構造 自作コンストラクタの実態は、Constructクラスを継承した自作クラスです。自作クラスの constructorメソッド内に、以前と同様に作成したいリソース定義を書いていくだけでOKです。 自作コンストラクタMyNetworkの正体は？ 

自作コンストラクタの構造 自作コンストラクタの実態は、Constructクラスを継承した自作クラスです。自作クラスの constructorメソッド内に、以前と同様に作成したいリソース定義を書いていくだけでOKです。 今まで同様にリソースを定義する！ Constructクラスを継承した自作クラス =自作コンストラクタ 

自作コンストラクタへのリファクタ後に出るエラー 自作コンストラクタに切り出して、作成するリソースが定義されているスコープが分割されたことに よって、リソース作成時に必要になるinput情報の参照エラーが一時的に出るようになります。 自作コンストラクタMyDatabase 自作コンストラクタMyService vpcの定義が別コンストラクタ(MyNetwork)に 切り出されたため参照エラー vpc参照エラー(同上) vpc参照エラー(同上) vpc参照エラー(同上) vpc参照エラー(同上) vpc参照エラー(同上) SNSトピックの定義が自コンスト ラクタ外にあるため参照エラー ECS用セキュリティグループの定義が 別コンストラクタ(MyService)に切り 出されたため参照エラー 

自作コンストラクタの引数やプロパティを定義する このような場合、変数参照エラーを解消するように自作コンストラクタの引数やプロパティを定義す ることになります。 スタック作成時 ①MyNetworkコンストラクタの プロパティにvpcを定義 ②vpcプロパティに、コンス トラクタ内で作成したvpcオ ブジェクトをセットして外部 からの参照を可能にする ③MyServiceコンストラクタ 作成に必要な引数(vpc)を定義 ④引数で渡されたvpcの情報 を参照しリソース作成 vpcとSNSトピックの 情報を渡すI/Fになる 

自作コンストラクタ作ってみないの？ 私 L2みたいなきれいに抽象化されたインターフェース設計 ぱっとできないしハードル高いかな・・・ きりのいいリソースでまず切り出して、 後からそれを成立させるような引数にしておけば 自然といい感じになる！！！！ 

まとめ • 自作コンストラクタを作ると、CDKのコードもCloudFormationのコンソール表示もわかりやす くなります！ • AWS純正のL2コンストラクタが非常によくできているので「あのレベルのきれいな抽象化・設計 をする自信なんてない……」という気持ちになりますが、もうちょっと気軽に自作コンストラクタ は手を出してOKです！ • アプリ出身だと「入出力I/Fはきっちり設計で決めてから実装しないと……」という気持ちになり がちかもしれませんが、まずはリソース区切って後から辻褄合わせるで全然なんとかなります！ 

まとめその1 • 自作コンストラクタを作ると、CDKのコードもCloudFormationのコンソール表示もわかりやす くなります！ • AWS純正のL2コンストラクタが非常によくできているので「あのレベルのきれいな抽象化・設計 をする自信なんてない……」という気持ちになりますが、もうちょっと気軽に自作コンストラクタ は手を出してOKです！ • アプリ出身だと「入出力I/Fはきっちり設計で決めてから実装しないと……」という気持ちになり がちかもしれませんが、まずはリソース区切って後から辻褄合わせるで全然なんとかなります！ 

より良いコンストラクタ設計をするために…… 

ちょっとレベルアップ 

課題その① MyServiceを作るために、依存リソースとしてMyNetworkが必要という構図です。 2. SNSトピックを作る 1. VPCを必要他リソースと共に作る 3. サービスをホストするECSを作る 4. サービスが依存するDBを作る 依存 

vpcの引数の渡し方がダサい問題 MyServiceコンストラクタが要求する引数はIVpcインターフェース型です。普通にやると自作コン ストラクタであるMyNetworkはIVpcインターフェース型を満たさないので、回りくどい引数の引き 回しが必要になります。 IVpcインターフェースにそのまま渡 せず、vpc.vpcという渡し方になる ↓ ダサい！！！！ vpcオブジェクトは MyNetwork型なので (再掲) MyNetworkが持つプロパティ (再掲) MyServiceコンストラクタの引数 

自作コンストラクタのIVpcインターフェース対応 MyNetworkがIVpcインターフェース型を満たすように実装してあげることで、AWS製のL2 VPCコ ンストラクタ同等の使い心地を担保することができます。 implements ec2.Ivpcの宣言 ec2.Ivpcインター フェースが持つプロパ ティの宣言 プロパティへ の値セット ec2.Ivpcインターフェース が持つメソッドの実装 MyNetworkがIvpcインター フェースを満たしたため、直 接引数として渡せる！！ 

(参考)レベル思考プラクティスによるL2化の推奨 @WinterYukky氏によるセッション「AWS CDK コンストラクトの分割戦略」では、「特定サービス のためだけに作られた再利用性のない『L4』ではなく、他リソースからも直感的に参照・利用でき るL2コンストラクタへの分割も視野に入れること」と述べられています。 出典: https://speakerdeck.com/winteryukky/aws-cdk-construct-partition-strategy-implementing-level-oriented-practice 

課題その② MyServiceにMyDatabaseへのアクセスを許可するために、MyDatabaseはMyServiceのsgを知らな いといけない=依存しているという構図です。 2. SNSトピックを作る 1. VPCを必要他リソースと共に作る 3. サービスをホストするECSを作る 4. サービスが依存するDBを作る 依存 

MyDatabaseにサービスのsgを渡す手法がダサい問題 MyServiceからMyDatabaseへのコネクションを疎通させるためにサービス用sgからのTCP3306番 をデータベースsgが受け付けるように実装する必要があり、そのためにMyDatabaseコンストラクタ の引数にサービス用sgを直接指定してしまっています。 (再掲) MyServiceが持つプロパティ (再掲) MyDatabaseコンストラクタの引数 vpcとセキュリティグループだと粒度が合って いなくてダサい！ ↓ セキュリティグループをもう少し抽象化したい 

IConnectableインターフェースの活用 IConnectableインターフェースは、ネットワークを通してコネクションを張るリソース実体を抽象 化したものです。今回は、MyServiceコンストラクタをIConnectableインターフェースを満たすよ うに実装を修正します。 implements ec2.IConnectableの宣言 セキュリティグループではなくて ec2.Connectionsをプロパティとして外部に公開 ECSサービスのセキュリティグループを ec2.Connectionsでラップしてセット 

IConnectableインターフェースの活用 すると、MyDatabaseコンストラクタが依存するのは、MyServiceのセキュリティグループという SpecificなリソースではなくMyServiceそのものであると表現することができ、抽象化の粒度をきれ いに揃えることができました。 データベースへの接続元をセキュリティグループでは なくec2.Iconnectableインターフェースで表現 ec2.Iconnectableインターフェースで 表現された接続元にアクセス許可 

課題その③ MyServiceがSNS Publishをするために、MyServiceはSNSに依存しているという構図です。 2. SNSトピックを作る 1. VPCを必要他リソースと共に作る 3. サービスをホストするECSを作る 4. サービスが依存するDBを作る 依存 

MyServiceの引数設計がきれいじゃない問題 MyServiceが行っているSNS Publish処理をIAM Roleで許可するために、MyServiceコンストラクタ がSNSトピックに依存する形になっています。しかし、今後SNSトピックを利用した処理が廃止さ れたときにコンストラクタのI/Fまで変わってしまうためあまりきれいな設計ではありません。 Service作成のためにSNSトピックを渡している ↓ SNSトピックを使わなくなったときに I/F変動余地ありでダサい (再掲) MyServiceコンストラクタの引数 

IGrantableインターフェースの活用 IGrantableインターフェースは、IAMでアクセス許可を付与できる実体を抽象化したものです。 MyServiceコンストラクタがIGrantableインターフェースを満たすように実装を修正することで、 SNSトピックへのPublish許可定義を、serviceオブジェクト生成時の内部処理ではなくserviceオブ ジェクトそのものに対する処理に書き換えることができ依存関係がきれいになりました。 implements iam.Grantableの宣言 ECSサービスが持つIAMロールを grantPrincipalとして外部に公開 grantPrincipalプロパティ のセット SNS Publish許可を内 部でやるのをやめる SNSトピック引数の廃止 権限付与のためにserviceが SNSトピックに依存しない IGrantableインターフェースを満たす MyServiceコンストラクタに、ここで Publish権限付与 

まとめその2 • 自作コンストラクタを作ると、CDKのコードもCloudFormationのコンソール表示もわかりやす くなります！ • AWS純正のL2コンストラクタが非常によくできているので「あのレベルのきれいな抽象化・設計 をする自信なんてない……」という気持ちになりますが、もうちょっと気軽に自作コンストラクタ は手を出してOKです！ • アプリ出身だと「入出力I/Fはきっちり設計で決めてから実装しないと……」という気持ちになり がちかもしれませんが、まずはリソース区切って後から辻褄合わせるで全然なんとかなります！ • I/Fがきれいじゃないなと思ったら、既存のコンストラクタのような使い心地を担保するために、 IVpcインターフェースのような既存インターフェースを実装してL2化するのはいいアプローチ です(ただし対応工数と要相談) • 自作コンストラクタ同士をまたいだ参照が必要になるのは、大体コネクション許可定義と権限付 与のためです。これを抽象化するために、自作コンストラクタがIConnectableインターフェー ス/IGrantableインターフェースを満たすようにリファクタできるといい感じのI/Fになります 

最後に宣伝 書籍 『AWSクラウド設計完全ガイド』 日経BPから発売中！ 第3章「実行アーキテクチャの設計」を執筆しました。 よろしければお手に取っていただければと思います m(__)m 

Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい [email protected] Haruka Sakihara(崎原 晴香)