CDK Conference 2025参加レポート
はじめに
7/12(土)開催のCDK Conferenceに参加してきました。イベントから1週間以上経ってしまいましたが、今さらブログ書きました。
今回は初めてJAWSイベントの運営ボランティアとして参加したので、イベント当日の様子だけでなく、最後に準備も振り返ってみようと思います。
CDK Conference当日
会場準備のため、入場開始より1時間ほど早く会場入りしました。場所は、アマゾンオフィスのある目黒セントラルスクエアの21階。17階のStartup Loft Tokyoはイベントで何度か行ったことがありましたが、21階は初めて。大きな部屋が2つ、小さな部屋がたくさんありました。
準備中のメインルーム
ゆめみさん提供の水。こんなにたくさんの参加者がくるのか...
当日のタイムテーブル(リンク)
あっという間に12時半のオープニング開始時間となりました。
当日写真を全然取っていなかったので、Xに上がったものも載せていこうと思います。
大部屋が満員に(X)
CDKはイベント前日に6歳になったらしい。
セッションの内容から脱線しているものも多いです。かなり自分用のメモ（セッションレポートのつもりはあんまりない）
キーノート(1)AWS CDKはなぜ生まれたのか
- 抽象化：複雑な実装をカプセル化し、再利用可能なコンポーネントとして提供すること。コンピュータサイエンスの歴史でも、抽象化が行われてきた。
- 例）オブジェクト指向、関数型(Immutable Data)
- 抽象化は、開発者が複雑な仕様やリスクを意識せずに、安全で再利用可能な方法でシステムを構築するためのガードレールになる。インフラでも監視やログ、セキュリティを抽象化されたモジュールや設定として再利用可能にすることで、well-architectedな設計に。
- Amplify：フロントエンドアプリの開発・公開が簡単
- Serverless Application Model(SAM)：バックエンドのサーバレスコンポーネント(API Gateway,
lambda,DynamoDB)をYAMLで宣言的に定義して、簡単に連携できるオープンソースフレームワーク。 - CDKは命令型でAWSリソースを定義。高レベルのオブジェクト抽象化
- 複雑なリソース群を一つのコンポーネントとして扱える。new ec2.Vpc(this,'MyVPC')だけで、ベストプラクティスに基づいたネットワーク環境を自動で定義。
- プログラミングの考え方とワークフローで、アーキテクチャをプロビジョニングできる。
つまり、従来は手動で構築していたクラウドの構成を、コードで定義して管理できるようになり、ソフトウェア開発と同様にバージョン管理や自動デプロイのプロセスに組み込める。- プロビジョニング：必要なインフラを構築・設定して、使える状態にすること。
- CDKがリリースされた当時、「ゲームチェンジャー」と称された。これは、それまでのインフラ構築の考え方とは本質的に異なるアプローチだった。
- CDK誕生のきっかけは、Amazon Echo Dotのような、サーバレスアーキテクチャを活用した大規模な検索サービスを構築しようとしたこと。このプロジェクトには、以下のような要求があった。
- グローバルなプロビジョニング：世界中の複数拠点にインフラを迅速に展開する必要がある。
- モジュールの独立開発：開発チームがそれぞれ独立してモジュールを開発できる体制が望ましい。
- 当時、この課題に対する主な選択肢はCloudFormationだったが、開発チームは、単なる設定言語であるJSONやYAML以上のものを求めていた。
- アプリケーション概念をモデル化できない：CloudFormationは宣言型のテンプレート言語であり、個々のリソースとパラメータを定義できても、「データ取り込み用のパイプライン」や「Strage Layer」といったアプリ全体の概念やロジックをモデル化することはできなかった。
- 抽象化の欠如：開発者は個々のリソースを一つひとつ宣言する必要があり、CloudFormationの宣言的な枠組みに縛られていた。より高いレベルでの「抽象化」が強く求められていた。
- 解決策が、Javaを使ってインフラをオブジェクトとして抽象化するというアイデア(これが後のコンストラクトの概念になる)。AmazonのOLPの1つである「Invest and Simplify」の考え方で考案。
- この新しいアプローチで、開発プロセスが改善。
- 学習コストの低減：アプリケーションのロジックとインフラ定義を同じプログラミング言語で扱える
- インフラを機能ごとにコンポーネントに分割できるため、コンポーネント間の接続定義や単体テストが容易に。作成したコンポーネントはJavaモジュールとして編成し、「コンストラクト」として他チームとも共有できる。
- 複数環境への展開：一度定義したインフラ構成を、開発環境や本番環境など、複数の環境へ簡単にデプロイできるように。
- JSII(JavaScript Interop Interface)をOSSとして開発。TSで書いたコードを複数の言語で扱える。単一のコードベースから多言語ライブラリを開発することが可能。
- 補足：JSIIの解説資料
- JSII：TypeScriptで書いたライブラリを、PythonやJavaなど他の言語でも使えるようにする。
- TSから各言語に変換されるのは、コンストラクトの構造定義のみ。内部処理は変換されない。CDKコード実行時には、各言語のランタイムが親プロセスとして、jsii-runtimeという名前のNode.jsプロセスが子プロセスとして起動する。jsii-runtimeを介して、元のTypeScriptで書かれた内部処理を実行。
キーノート(2)AI-Agent時代のソフトウェア開発を支えるAWS Cloud Development Kit(CDK)
- LLMは確率的に次のトークンを推論
- 使われる技術やデザインはランダム
- CDKでも、L1使われるか、L2使われるかわからない。
- 期待する振る舞いを言語化する必要がある。
- 人間だけが知っていることを減らして、AIにも理解できる形式的なコードとして表現し、コンテキストの差を埋めつつ自律的に情報を取得させる = Everything as Code
- インフラの構成だけでなく、アプリケーションのロジック、デプロイ手順、セキュリティポリシー、テストといった、システムに関するあらゆる情報や文脈（コンテキスト）を、コードで表現しようという考え方
- 変更を追跡可能に。再現性・一貫性も生まれる。
- Everything as Codeの中心的な役割を果たすのが、IaC。
- CDKはデプロイ前にフィードバック提供するのがよい。
- Linterや組み込みバリデーションなど。
- 面倒で間違えやすい実装を肩代わりしてくれる。
- grantメソッド：IAMポリシーの設定
- myBucket.grantRead(myLambda);
↑ myLambdaにmyBucketからの読み取り権限を与える
- myBucket.grantRead(myLambda);
- connectionsオブジェクト：セキュリティグループのルールを設定
- myDatabase.connections.allowFrom(myLambda, ec2.Port.tcp(5432));
↑ myDatabaseのセキュリティグループにインバウンドルールを追加し、myLambda からの TCPポート5432番への通信を許可
- myDatabase.connections.allowFrom(myLambda, ec2.Port.tcp(5432));
- grantメソッド：IAMポリシーの設定
- 補足: Everything as Code（DevOps Guidance）
- 〇〇 as Codeがたくさん。
- Networking as Code
- Database as Code
- Configuration as Code
- Documentation as Code
- Image as Code
-
アンチパターンのページはちゃんと見てみた。
- 機密情報はハードコードしない
- インフラは手動変更しない
- システムに合わせて、ドキュメントを最新に保つ
- 構成ドリフト（理想状態との差異）は、手動変更や外部サービスの自動変更などで発生する可能性がある。ドリフトの防止策（Immutable Infrastructureを選ぶなど）を打った上で、下記などでドリフト検知できるように。
- AWS Config
- Terraform Drift Detection
- CloudFormation Drift Detection
- IaCはコードだから、アプリのコードと同じくきちんとコンポーネント化して（モノリシックを避けて）、バージョン管理する。
- 〇〇 as Codeがたくさん。
AWS CDK 入門ガイド - これだけは知っておきたいヒント集
- App,Stack,Constructの階層構造
- 抽象化レベルに応じた3つのConstruct
- L1:CloudFormationの仕様と1対1で対応する、自動生成された最も基本的なコンストラクト。クラス名はCfnで始まる。プロパティが完全に網羅され、最大限のコントロールが可能だが、記述は冗長になりやすい。
- L2: AWSのベストプラクティスに基づき、デフォルト値とヘルパーメソッドを提供する。内部でL1コンストラクトをラップし、権限設定などの定型的な処理を簡単に記述できる。
- L3: 複数のL1/L2コンストラクトを組み合わせて、一般的なアーキテクチャパターンをカプセル化したもの。パターンとも呼ばれる。
- cdk bootstrap: CDKアプリのデプロイに必要となる共通リソース（S3バケット、ECRリポジトリ、IAMロールなど）をプロビジョニング。デプロイ先のアカウントとリージョンに一度だけ実行する初期セットアップ。CDKToolkitという名前のCloudFormationスタックが作成される。
- CDKにおけるテスト: 必須ではないが、推奨。CDKプロジェクトの初期化時には、デフォルトでスナップショットテストの仕組みが用意されていて、npm run testで実行。他にも何種類かテストを記述できる。
- スナップショットテスト: 内部的にcdk synthを実行して得られるテンプレートを、以前保存されたスナップショット(ローカル)と比較。デプロイ済みの環境と比較するcdk diffとは異なり、意図しないコード変更でテンプレートの出力が変化していないかを検知。
- 紹介されていた参考ドキュメント
cdk initで生成されるあのファイル達は何なのか
- cdk.json
- CDKアプリケーションの実行設定を管理する。CDKコマンドを実行する際の挙動を制御。
- このファイルがないと、CDKコマンド実行時にアプリのエントリーポイントなどの設定値を、コマンドライン引数で毎回指定する必要がある。めんどい。
- ↓プロパティの例としてapp
- cdk synthやcdk deployを実行した際に、どのファイルを実行するかを指定するエントリーポイント
- ts-nodeオプション
- 下記ステップを一度に実行
- npm run buildを手動で実行しなくても、TSファイルをJSファイルに変換(Node.jsが直接実行できる形式)
- Node.jsランタイムで実行
- tscコマンドのように変換結果をディスクには書き出さず、メモリ上に一時保存してそのままnodeで実行 = .js の中間ファイルが不要
- ただプロジェクト内にjsファイルが存在している( npm run build 実行したなど)場合、ts-nodeはデフォルトでjsファイルを優先して読み込む。結果として、tsファイルを更新してもts-nodeはその変更を無視して、古いjsファイルを使い続ける。そのため、--prefer-ts-exts オプションが必要(PR)
- 下記ステップを一度に実行
- package.json
- Node.jsプロジェクトの定義（マニフェスト）ファイル
- これがないと例えば、
- 手動で全ての依存パッケージを一つずつインストールする必要がある。メンバー間や環境間でバージョンの一貫性を保てない。
- npm run ○○ のようなコマンドエイリアスが使えなくなる(scriptsセクションで定義)。プロジェクト固有のコマンドを、標準的で覚えやすい名前（test, buildなど）に統一できる。
- package-lock.json
- npm installでインストールされたパッケージの正確なバージョン情報(package.jsonに記載されない、サブ依存関係も含む)などを記録したファイル 。誰がどの環境でインストールしても、全く同じ依存関係が保証される 。
- jest.config.js
- jest(CDKがデフォルトで使用するテストフレームワーク)の挙動を管理する設定ファイル。
- 設定ファイルがないと、コマンドで毎回長いオプションを指定するのはめんどいし、入力ミスもしやすい。
- 通常、テストはnpm run testで実行される。package.jsonに、"test": "jest" と書かれているため、内部的にjestコマンドを実行。
- tsconfig.json
- TypeScriptコンパイラ(tsc)の設定ファイル。
- 出力するJSのバージョンや、コンパイル後の出力フォルダなどを設定
TypeScript エコシステムで築く AWS CDK の品質基盤
- 最終成果物が同じでも、CDKコードの品質は大事。コードの保守性などの観点で。
- ソフトウェア品質は国際規格がある。JIS X 25010には、ソフトウェア品質の特性として「保守性」「機能適合性」など8個に分類されていて、それらをさらに細分化した副特性もある。
URL - ESLint(静的解析ツール): JS/TSコードを解析して、構文エラーやコーディング規約の違反を検出。個人の知識やレビューに依存せず、ベストプラクティスに沿ったコードを書ける。CDK専用のプラグインがある。
- 例えば「Construct の public プロパティに Construct 型を指定しない」というルールに違反したとき、以下のような表示になる。
Playground。WebContainer環境で、ブラウザ内で動作する開発サーバーが立ち上がるまで時間がかかる - 補足: WebContainer環境とは
- Webブラウザが直接実行できるのは主にJavaScriptだが、Node.jsのランタイムはC++で書かれている。この言語間の壁を埋めるのがWebAssembly（Wasm）。
WebContainerでは、あらかじめC++で書かれたNode.jsランタイムを、専用のコンパイラ(Emscripten)を使ってブラウザが実行可能なWasm形式に変換しておく。ブラウザは、その変換済みのWasmファイルをダウンロードして実行する。Node.js環境はブラウザ内で完結して動作するため、ローカルにNode.jsをインストールする必要なし。
- Webブラウザが直接実行できるのは主にJavaScriptだが、Node.jsのランタイムはC++で書かれている。この言語間の壁を埋めるのがWebAssembly（Wasm）。
無理しない、着実にやりきるCDK移行術
-
cdk migrate
- 既存のCloudFormationスタック(デプロイ済み)・テンプレート(ローカル)、非IaC管理のデプロイ済みAWSリソースをCDKコードに変換
- 新しく作成されたCDKアプリには、L1コンストラクトのみが含まれる。
-
cdk importとの違いが紛らわしい
- 記述済みのCDKコードと既存リソースを紐づけ、管理下に置くコマンド。cdk deploy時に既存リソースの削除・再作成を防ぐ。新しいコードを生成するのではなく、CloudFormationスタックの状態(リソースの論理IDと物理IDのマッピング情報)を更新する。
- 特に、まだ一度もデプロイされていないスタックに対してcdk importを実行すると、CDK CLIは以下の手順を踏む。(AI出力で、情報ソース見つけられず)
- インポート対象のリソースを除外したテンプレートを内部的にsynthする。
- そのテンプレートを元に、インポートの受け皿となるCloudFormationスタックをAWS上に新規作成
- 作成されたスタックに対してインポートを行い、既存リソースの物理IDとのマッピング情報を更新する
- 自動生成されたL1からL2への書き換えは必要だが、大変なので無理しない。
- Constructのツリー構造が変わるため、CloudFormationテンプレート内のリソースの論理IDが変わる。(CDKがツリー構造における各Constructのパスを基に、一意な論理IDを算出する。スタック内でのIDの一意性を保証するため、末尾に8文字のハッシュ値を自動で付与)
Renovateを活用した手離れの良いCDKプロジェクトの作り方
- CDKライブラリ更新は週1で、バージョンアップが大変。
- Renovateというツールは、更新PRを自動作成してくれるらしい。すごい便利。
- そのPRをトリガーとしてCIが実行され、テストなどがすべて成功した場合にのみPRをオートマージする運用が一般的。
- NODEJS_LATESTという定数について
- AWSの新しいサービスや機能は、全世界のリージョンに一度に展開されるのではなく、段階的にリリースされる。このため、あるリージョンでは最新のlambdaランタイムが利用できても、別のリージョンではまだ利用できないという状況が発生し得る。NODEJS_LATESTは、全世界のリージョンで広く利用可能になったと判断された、最新の安定版LTS（長期サポート）バージョンを指す。
- JestよりVitest(両方テストフレームワーク)の方が高速みたい。CDK Conference関係ない & 投票数少ないけどこんな投稿あった。Jestの上位互換がVitestだけど移行は進んでいない、ってことだと思ってる。
初心者向けワークショップ
自分にとっては今回のメイン。
サポートという立ち回りではありますが、参加者の方々からの質問に全然答えられなかったらどうしよう...と少し心配気味でスタート。自分含めた学生4人と運営の方2人+AWSの方2人という、大人数で臨みました。
TypeScript の基礎から始める AWS CDK 開発入門に書いてある通りにVSCodeServerを立ち上げて、開発環境をセットアップ。参加者は各自のAWSアカウントで実施していたため、事前に試したときには見たことない502エラーの人が。全く原因不明。スタックを削除して作り直したら、エラーは解消されたとのことで、よかった。
進行の方が作成した翻訳のデモアプリをまず立ち上げる。
初めてデモアプリ触ったとき、どんな言語を入力してもきちんと翻訳されることに感動しました。
Amazon Translate・Amazon Comprehendというサービスが使われているようですが、初めて聞いた。
翻訳アプリを触ったあとは、自分でCDKコードを書いていくパート。API GatewayとLambdaを使って、"Hello World"のAPIを作成しました。参加されている方々の様子を見ていると、かなり順調に進んでいそう。本当に初心者なのか(?)というくらい、プロ感の溢れている方がちらほら。よく考えたら、あくまで初心者なのはCDKであって、AWS自体は使いこなしていてもおかしくない。
最後に発展課題。
参加者から質問されると、逆にこちらが勉強になる。
DynamoDBテーブルを含む新しいスタックを作成し、cdk deployを行っても、承認を求める確認が出なかったとのこと。cdk deployが承認を求めるのは、IAM関連、セキュリティーグループの変更など、セキュリティに影響を及ぼす可能性のある変更だけらしい。
忘れずにcdk destroyを実行して、ワークショップは終了。
なぜサポート役の学生が4人もいるかと言うと、企画当初は、学生主導でワークショップ進行できたらいいねという話をしていたためです。ただワークショップの内容を考える、当日の進行を主導するレベルからは遠く、結果的に運営の方にお願いすることとなりました。「学生だけでワークショップやりたい」と運営陣の前で豪語していたのは若干恥ずかしいですが、当日はサポート役として少し貢献できたのでよかったです。ワークショップの準備をして下さった新澤さん、ありがとうございました！
【あのMCPって、どんな処理してるの？】 AWS CDKでの開発で便利なAWS MCP Servers特集
初心者向けワークショップと被ったこともあり、セカンドトラックはあんまり聞けてなかった。初めからちゃんと聞けたのはこのセッションくらい。
-
AWS MCP Serversは、数十種類存在する(!)。セッションで紹介されたMCPサーバーは3つ。
-
3つのMCPサーバは共通して、FastMCP(フレームワーク)を使用。
server.pyなどで、mcp=FastMCP(...)のようにサーバーインスタンスを作成。個々の機能を、mcp.toolというデコレータでサーバーインスタンスにツールとして登録。-
mcp=FastMCP(...): コードの中心部分。引数として、下記のようなものがある。- name: サーバーの名前(デフォルトはFastMCP)
- instructions: サーバーが持つツール、AIアシスタントの振る舞いに関する指示するためのシステムプロンプト。
- dependencies: サーバーが動作するのに必要なPythonライブラリ。3つ目のCDK MCP Serverで使われていた。
- などなど。
-
-
AWS Documentation MCP Server: AWS公式ドキュメントに接続
- いろんなツールがあるが、get_available_services(中国リージョンで利用可能なサービス一覧を取得)が気になる。
- 中国の法律や規制に準拠するため、中国国内のリージョン（北京、寧夏）は、他のリージョンとは物理的にもアカウント体系としても分離されているらしい。
- 中国リージョンを使うには、中国国内の事業者ライセンスなどを使って「AWS（中国）アカウント」の作成が必要
- 中国リージョンのデータセンターは、物理的に中国本土内に存在。データセンター間のネットワークも、AWSのグローバルネットワークバックボーンから分離されている。
-
server_aws_cn.py(中国向け)のinstructionsに、
Always use `get_available_services` firstって書いてあった。このツールはやはり大事っぽい。
Claude Desktopで試したら、get_availble_services試してみた
-
AWS Pricing MCP Server: コストの見積もりや分析
- FastMCPのinstructionsと、mcp.toolのdescriptionが3つの中で一番長い。料金に関するツールだから、間違った情報を与えないように厳格なルールを敷いている？
-
AWS CDK MCP Server: CDK開発をサポート
- この3つの中では唯一、
mcp.resourceでリソースも登録していた。
- この3つの中では唯一、
AWS CDK単体テスト実装を効率化するライブラリをリリースしました
スライドは見つけられませんでしたが、ブログはこちら。
- アサーションテスト: コンストラクトから期待通りの設定でCFnテンプレートが生成されることを確認
- アサーションテストを行う標準モジュールとしては、aws-cdk-lib/assertionsモジュールが存在。ただリソースのプロパティに対する型情報が乏しく、テストコード書くのが大変 & テストが落ちた時に「テストコードの記述ミス」か「実装コードのバグ」なのかわからない。aws-cdk-utulライブラリは、テスト対象のリソースに関するスキーマや型情報を提供してくれる。
- （全く関係ないけど）TL;DRは「忙しい人向けの要約」みたいなスラングって知らなかった。「長すぎるから読んでない（Too Long; Didn't Read）」なんて他の人に使ったらだいぶ皮肉っぽいから、自分の記事とかに使う用なのかな。
CDK引数設計道場100本ノック
- L1,L2ともにコンストラクトの引数型定義が行われているが、L2はより抽象度の高い独自の型定義によって使いやすくなっている。
- L1: CFnの仕様に対応した、文字列や数値などのプリミティブ型が中心。
- L2: IBucketのようなインターフェース型や、リソースオブジェクトもプロパティとして直接受け入れる。これによって、リソース間の関連性を認識し、ARNの解決やIAMの設定などを自動化できる。
- 例：CloudFrontディストリビューションのオリジン（コンテンツの取得元）にS3バケットを指定
- L1: 以下を手動で行う必要がある。
- CloudFrontディストリビューションがバケットにアクセスするためのOrigin Access Identityを自分で作成
- 後続のバケットポリシー、ディストリビューション設定の両方から参照されるため、最初に定義。
- S3バケットポリシーを更新し、OAIをPrincipal(バケットへのアクセス主体)として指定し、バケット内のオブジェクトへの読み取りを許可するステートメントを追加。
- S3バケットのドメイン名やARNを文字列として渡し、OAIを関連づけて、CloudFrontディストリビューションを作成。
- ARN(Amazon Resource Name): AWS上に存在する全てのリソースに一意に割り当てられる識別名。
- 例(S3バケットのARN)：arn:aws:s3:::my-example-bucket
S3バケット名はグローバルで一意だから、ARNにはリージョンやアカウントIDが含まれない。
- 例(S3バケットのARN)：arn:aws:s3:::my-example-bucket
- ARN(Amazon Resource Name): AWS上に存在する全てのリソースに一意に割り当てられる識別名。
- CloudFrontディストリビューションがバケットにアクセスするためのOrigin Access Identityを自分で作成
- L2: Bucketオブジェクトを渡すだけ。
const bucket = new s3.Bucket(this, 'MyBucket'); new cloudfront.Distribution(this, 'MyDistribution', { defaultBehavior: { // Bucketオブジェクトを直接渡す origin: new origins.S3Origin(bucket), }, });-
new origins.S3Origin(bucket)の部分は、S3Originコンストラクトが以下の処理をすべて自動で行う- 渡されたbucketオブジェクトから、CloudFrontオリジン設定に必要なドメイン名などのプロパティを参照して設定。
- OAIを作成
- bucketオブジェクトが持つgrantRead()メソッドを、作成したOAIを引数に指定して呼び出す。OAIからのs3:GetObjectアクションを許可するバケットポリシーが自動で設定。
-
- L1: 以下を手動で行う必要がある。
- 引数設計の具体例がたくさん示されました。ノックはあんまり取れなかった...。
Git Syncを超える！OSSで実現するCDK Pull型デプロイ
-
Git sync: 2023年11月に公開されたCloudFormationの機能。GitリポジトリからCFnテンプレートをPull型で同期・デプロイしてくれる。
- ただしGitリポジトリとCFnスタックを常に一致させているわけではない。CFnテンプレートなどに変更加えてpushしないと、スタックが更新されなそう（Git syncの挙動）
- PipeCD: 継続的デリバリー(CD)のプラットフォーム。Pull型。
- デプロイに関する全ての権限をAWS内に閉じたいときは有効。Git syncだと、assetsのpublshを行うのはGitHub Actions。
- 補足: GitHub Actions(のRunner)がAWSにアクセスする仕組み
- 「RunnerがOIDC(OpenID Connect)を利用して一時的な認証情報でAWSのIAMロールを引き受け、AWSにアクセス。」
- GitHub Actions Runner: GitHub Actionsワークフローを実行するソフトウェア。GitHub提供の仮想マシン上で動作する「GitHub-hosted runner」と、ユーザが用意した環境で動作する「Self-hosted runner」の2種類
- OIDCによる一時的な認証情報の流れ
- ワークフローが動き出すと、GitHubのOIDCプロバイダーがJWT(Json Web Token)を自動で発行してRunnerが受け取る。JWTには、リポジトリ名、ブランチ名などが含まれる。
- configure-aws-credentialsアクションは、JWTを使ってAWSのSTS(Security Token Service)にアクセスし、IAMロールの引き受けをリクエスト。
- AWS STSは、JWTが信頼できるものか、IAMロールの信頼ポリシーと照合して検証。検証が成功すると、STSは一時的な認証情報(デフォルトの有効期間は1時間)を生成し、Runnerに返される。
- configure-aws-credentialsアクションは、受け取った認証情報をRunnerの環境変数に設定。
- ワークフローの後続のステップは、この環境変数を使用して、IAMロールに許可された範囲でAWSリソースを操作。
- これによって、有効期間の長いアクセスキーをGitHub Secretsに保存する必要がなく、セキュリティが向上。
AWS CDKの仕組み
- CDKは、CDK CLIとCDK Appの2つの主要な構成要素。
- CDK CLIはCDKコマンドを提供するコマンドラインツール。CDK AppはTypeScript等でリソースを定義したアプリケーションコードそのもの。
- このセッションのメイントピック。cdk deployの挙動
- cdk deployを叩くと、CDK CLIがコマンド受け取る。
- configを読み込んで、context(いろんな設定値)を取得
- synthが走り、子プロセスとしてCDK Appを実行。アプリケーションライフサイクルがあり、4フェーズから成る。
- Constructフェーズ:
- CDKコードを読んでいき、Constructツリーを構築。
- Lambdaコードのバンドル(TS→JS)。ファイルアセットのバンドルは走るが、イメージアセットはここではビルドされない(CDK CLIで走る)
- Prepareフェーズ:
- ツリーのルートからAspect(そのノード以下の全てのノードに同じ操作を適用)の有無をチェックして、あれば実行。
- CDK v1では、Constructフェーズでprepareメソッドを実行していた。
- Validateフェーズ：
- 各ノードに適用されたバリデーションロジックを実行し、エラーがないかチェック。
- Synthesizeフェーズ：
- ツリーからCFnテンプレートを生成。L1 Constructからtemplate.jsonを作成している。論理IDの計算なども行う。
- クラウドアセンブリ(CFnテンプレート = xxx.template.json、アセットファイル等)をcdk.outディレクトリに出力
- Constructフェーズ:
- (ここ以降は、cdk deploy時のみ実行。)イメージアセットのビルド(CDK Appで、ファイルアセットのバンドルは行われた)
- アセット(ファイルアセット・イメージアセットの両方)アップロード
- CFnテンプレートに基づきAWSリソースを操作する、CloudFormationデプロイ
その他
懇親会は学生4人で固まってしまっていましたが、他の参加者の方々が何人か席に来てくださって、いろんなお話できました。皆さん共通しているのは、多方面でたくさん活動していること。ストイックな方ばかりで、たくさん刺激を頂けました。
運営ボランティアをやってみて
ボランティアをやることになったきっかけは、この投稿でした。 CDKについては「名前は聞いたことあるな」程度でしたが、カンファレンスの運営に携わってみたいという思いがあったため、ダメ元で応募してみることに。
2週間後くらいに運営の方から連絡が来て、ボランティアとしてお手伝いできることになったのはとても嬉しかったです
CDKも分からないし、CDK Conference一度も参加したことないし、最初はこんな感じでした(笑)。
5月中旬くらいから週1でミーティングがあり、CDK Conferenceまでの準備の様子を見ることができました。運営の準備もCDKも全然分からない状態でしたが、CDK支部の方々が受け入れてくださり、初心者に対してオープンなコミュニティだなというのが第一印象でした。(夜遅くまでフォローアップもしてくれました)
初心者ワークショップ担当としても、ボランティアとしても、あまり貢献できなかったのは心残りですが、CDK Conferenceという大きなイベント運営に関わることができて、とても楽しかったです。
- CDK Conferenceテーマ、企画内容を考える
- スポンサー募集
- 懇親会の準備
- CfPの募集、選定
- 集客
などなど、
イベント準備ではこんなにやることがあるのか、と驚きました。イベントに参加する際には、イベントを支える運営の方々に対して感謝の気持ちを忘れないようにします。
運営の皆さん、ありがとうございましたm(__)m
おわりに
内容が分からなくてAIと壁打ちした箇所が多く、誤って解釈している部分があるかもしれないです。かなり文字数が多くなってしまいましたが、まだ資料やアーカイブ動画を全く見れていないセッションも多いので、改めて見直したいです。
当日はセッション内容をあまり理解できなかったものの、ブログを書く過程でだいぶ理解が進んだ気がします。資料や動画を残してくれててよかった。
JAWSのイベント運営、CDKという技術、両方に初めて深く触れるイベントでしたが、とても楽しかったです！
Discussion