JAWS-UG 神戸 #6 Junki Ishigaki June 6, 2025 #jawsug_kobe #jawsug 

石垣潤樹 / Junki Ishigaki - 所属 → 株式会社シーズ - やっていること → インフラエンジニア - やっていること → AWSとかさわってます - 好きなAWSサービス → S3 - 最近 → Amplify Gen2楽しい, DuckDBいいね - 好き → ラーメン, 担々麺 2 社内で使ってるアイコン x.com/tokyo_jjjx 自己紹介 

目次 - Lambda Web Adapterおさらい - 今回試しにやってみたこと - 感想など 3 

Lambda Web Adapterおさらい - Lambda Web Adapterとは - ざっくりいうと、Lambdaに対する入出力とWebAppフレームワークのインタ ーフェースの媒介 - もっとざっくりいうと、Lambdaに入力されたものをごにょごにょうまい具合 に変換してWebApp側に渡すツール - そもそもの発端は、開発者が使い慣れたWebAppフレームワークをLambda上 で動かせるようにという経緯。 4 https://github.com/awslabs/aws-lambda-web-adapter?tab=readme-ov-file#aws-lambda-web-adapter 

Lambda Web Adapterおさらい 5 https://github.com/awslabs/aws-lambda-web-adapter/blob/main/docs/images/lambda-adapter-overview.png 

今回試しにやってみたこと 6 # プロジェクトのファイル構成 simpleapi/ │ ├── app/ # アプリケーションディレクトリ │ ├── src/ # ソースコードディレクトリ │ │ ├── main.rs # メインのRustコード（APIエンドポイント定義） │ │ └── data.rs # データ管理モジュール（モデルとデータ操作関数） │ ├── Cargo.toml # Rustの依存関係設定 │ ├── Dockerfile # マルチステージビルド用Dockerfile（ローカル/Lambda両対応） │ └── README.md # アプリケーションのREADME │ ├── cdk/ # CDKプロジェクトディレクトリ │ ├── bin/ # CDKアプリケーションのエントリポイント │ │ └── app.ts # CDKアプリケーション定義 │ ├── lib/ # CDKスタック定義 │ │ └── simple-api-stack.ts # APIスタック定義（Lambda + API Gateway） │ ├── package.json # Node.js依存関係 │ └── tsconfig.json # TypeScript設定 └── docker-compose.yml # ローカル開発用Docker Compose設定 WebApp CDKでAWSにdeploy 

今回試しにやってみたこと 7 # プロジェクトのファイル構成 simpleapi/ │ ├── app/ # アプリケーションディレクトリ │ ├── src/ # ソースコードディレクトリ │ │ ├── main.rs # メインのRustコード（APIエンドポイント定義） │ │ └── data.rs # データ管理モジュール（モデルとデータ操作関数） │ ├── Cargo.toml # Rustの依存関係設定 │ ├── Dockerfile # マルチステージビルド用Dockerfile（ローカル/Lambda両対応） │ └── README.md # アプリケーションのREADME │ ├── cdk/ # CDKプロジェクトディレクトリ │ ├── bin/ # CDKアプリケーションのエントリポイント │ │ └── app.ts # CDKアプリケーション定義 │ ├── lib/ # CDKスタック定義 │ │ └── simple-api-stack.ts # APIスタック定義（Lambda + API Gateway） │ ├── package.json # Node.js依存関係 │ └── tsconfig.json # TypeScript設定 └── docker-compose.yml # ローカル開発用Docker Compose設定 WebApp CDKでAWSにdeploy Dockerfile [1行追加] COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.9.1 /lambda-adapter /opt/extensions/lambda-adapter 

こんな感じ 8 GET /items GET /users 

ここから感想パート 9 - ルーティングどこでやるか問題 - デメリットぽいところ - メリットぽいところ - いつもの開発 - 役割分担がしやすい - 可搬性 

ルーティングどこでやるか問題 10 - Lambda-> 単機能で小さく素早く返すべきという話が一方であります API Gatewayでルーティングさせるパターン 

ルーティングどこでやるか問題 11 - 今回の構成は、API Gatewayからany requestを1つのLambdaに流してます。 今回のパターン(いわゆるLambdalith) ここのLambdaが大きくな っていきます 

デメリットぽいところ 12 - コールドスタート問題 - Lambdaの起動までに時間かかるという問題 - Lambdaのパッケージ自体が大きくなるほど影響が大きくなる - 同時実行数 - Lambdaの同時実行数はAWSアカウント毎(かつリージョン毎)ではあるものの、 Lambdaが大きくなって処理時間が伸びると同時性が高まって上限を気にしな いといけないケースも出てくる。 - オブザーバビリティ - Lambdaのエラーレイトを見るだけでは、どのAPIのエラーかわからないなど ※そもそも小分けのパターンでも計装はしたほうがいいとは思います などなど 

メリットぽいところ 13 - 開発者が使い慣れたWebAppフレームワークをLambda上で動かせる # プロジェクトのファイル構成 simpleapi/ │ ├── app/ # アプリケーションディレクトリ │ ├── src/ # ソースコードディレクトリ │ │ ├── main.rs # メインのRustコード（APIエンドポイント定義） │ │ └── data.rs # データ管理モジュール（モデルとデータ操作関数） │ ├── Cargo.toml # Rustの依存関係設定 │ ├── Dockerfile # マルチステージビルド用Dockerfile（ローカル/Lambda両対応） │ └── README.md # アプリケーションのREADME │ ├── cdk/ # CDKプロジェクトディレクトリ │ ├── bin/ # CDKアプリケーションのエントリポイント │ │ └── app.ts # CDKアプリケーション定義 │ ├── lib/ # CDKスタック定義 │ │ └── simple-api-stack.ts # APIスタック定義（Lambda + API Gateway） │ ├── package.json # Node.js依存関係 │ └── tsconfig.json # TypeScript設定 └── docker-compose.yml # ローカル開発用Docker Compose設定 ここの部分はいつも通りでで きる WebApp 開発チームごとに ・Next.js ・Flask ・Laravel ・ASP .Net ・Axum など 

メリットぽいところ 14 - 役割分担がしやすい # プロジェクトのファイル構成 simpleapi/ │ ├── app/ # アプリケーションディレクトリ │ ├── src/ # ソースコードディレクトリ │ │ ├── main.rs # メインのRustコード（APIエンドポイント定義） │ │ └── data.rs # データ管理モジュール（モデルとデータ操作関数） │ ├── Cargo.toml # Rustの依存関係設定 │ ├── Dockerfile # マルチステージビルド用Dockerfile（ローカル/Lambda両対応） │ └── README.md # アプリケーションのREADME │ ├── cdk/ # CDKプロジェクトディレクトリ │ ├── bin/ # CDKアプリケーションのエントリポイント │ │ └── app.ts # CDKアプリケーション定義 │ ├── lib/ # CDKスタック定義 │ │ └── simple-api-stack.ts # APIスタック定義（Lambda + API Gateway） │ ├── package.json # Node.js依存関係 │ └── tsconfig.json # TypeScript設定 └── docker-compose.yml # ローカル開発用Docker Compose設定 開発者はビジネ スロジックに注 力 こっちは事前に Platformチーム から共有する など WebApp 環境 

メリットぽいところ 15 - 可搬性 # プロジェクトのファイル構成 simpleapi/ │ ├── app/ # アプリケーションディレクトリ │ ├── src/ # ソースコードディレクトリ │ │ ├── main.rs # メインのRustコード（APIエンドポイント定義） │ │ └── data.rs # データ管理モジュール（モデルとデータ操作関数） │ ├── Cargo.toml # Rustの依存関係設定 │ ├── Dockerfile # マルチステージビルド用Dockerfile（ローカル/Lambda両対応） │ └── README.md # アプリケーションのREADME │ ├── cdk/ # CDKプロジェクトディレクトリ │ ├── bin/ # CDKアプリケーションのエントリポイント │ │ └── app.ts # CDKアプリケーション定義 │ ├── lib/ # CDKスタック定義 │ │ └── simple-api-stack.ts # APIスタック定義 │ ├── package.json # Node.js依存関係 │ └── tsconfig.json # TypeScript設定 └── docker-compose.yml # ローカル開発用Docker Compose設定 Platformチームから事前に別の 環境用のテンプレートが提供 されてたりすると嬉しかったり WebApp WebApp部分はそのままに 環境だけ切り替える 環境 

メリットぽいところ 16 - 可搬性 - 例えば、パフォーマンスが気になってECSに載せ替えるなど(WebAppはその まま) 環境 WebApp こっちはそのまま 

- WebAppはそのままでいろいろ環境を切り替えて使いたい(切り替えられる可能性 を残しておきたい)ような時に、LWAがあると切り替えられる環境のオプションに Lambdaを持っておける。 まとめ 17 WebApp 環境 Next.js Flask ASP .Net Laravel Other… API Gateway Lambda+ LWA Axum ALB+ ECS CloudFront+ Lambda(関数URL)+ LWA Other… 

- Lambda Web Adapter - Lambda Web Adapter でウェブアプリを (ほぼ) そのままサーバーレス化する(2025 年改訂版) - https://aws.amazon.com/jp/builders-flash/202301/lambda-web-adapter/ - AWS Lambda Web Adapterを活用する新しいサーバーレスの実装パターン - https://speakerdeck.com/tmokmss/aws-lambda-web-adapterwohuo-yong-suruxin- siisabaresunoshi-zhuang-patan - WebアプリをLambdaで動かすまでに考えること - https://speakerdeck.com/_kensh/how-to-implement-monolithic-lambda-web-application - awslabs/aws-lambda-web-adapter - https://github.com/awslabs/aws-lambda-web-adapter - Platform Engineering - Platform Engineeringでクラウドの「楽しくない」を解消しよう - https://speakerdeck.com/jacopen/platform-engineeringde-kuraudono-le-sikunai-wojie- xiao-siyou - https://www.youtube.com/watch?v=mOnElI_KM6o 参考資料など 18 

ありがとうございました re:play2023→