aws-cdk

WebFunctions L2 ConstructsのPRマージされた模様。 近々使えるようになりそう aws-cdk#39210

Lambda Web Functions の L2 マージされた！ aws-cdk#39210

grantInvokeFromVpcEndpointsOnly()作ったのはこちら！ 当時は「引数に複数個のEndpoint渡すケースなんて誰がやるんじゃい」って思ってましたが、2年後に自分がやりました。 aws-cdk#32719

🔗 Repositorio oficial y ejemplos: aws/aws-cdk 📌 Guarda este post para modernizar tus despliegues en AWS.

Ship a Lambda Web Function with CDK So, AWS Lambda Web Functions just came out, and I'm super excited about them. What are they? Well, you can now ship Express, Hono, or React Router with no Lambda-specific adapters or wrappers. Let me show you how I got this demo set up with CDK. λ: cxrj1w1j65n0k7ss.p7v.lambda-web.us-east-2.on.aws (this may not live forever but the code should) > ⚠️ DISCLAIMER: The code we are about to see is written with L1 CDK constructs. The L2 constructs are being tracked via this PR. First, let's look at the server code I have in Express. I've omitted the bulk of its logic for brevity. Here, you can see that it's an Express.js server binding to a port. import express from "express"; const [hostname, rawPort] = ( process.env.AWS_LAMBDA_HTTP_ENDPOINT ?? `127.0.0.1:${process.env.PORT ?? "3000"}` ).split(":"); const port = Number(rawPort); export const app = express(); export const server = app.listen(port, hostname, () => { console.log(`Spinning Lambda is listening on http://${hostname}:${port}`); }); I can run the code locally with pnpm dev. !Image description Now, let's look at the CDK stack used to deploy this function. export class SpinningLambdaStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // code bucket stuff omitted const webFunction = new CfnWebFunction(this, "WebFunction", { functionName: `${this.stackName}-web`, // many props omitted for brevity }); const revision = new CfnWebFunctionRevision(this, "WebFunctionRevision", { functionName: webFunction.ref, // many props omitted for brevity }); const endpoint = new CfnWebFunctionEndpoint(this, "WebFunctionEndpoint", { functionName: webFunction.ref, // many props omitted for brevity }); } } Now for deployment. I'm using the new AWS experience, so I have a project dedicated to this demo. I grab some credentials for my account with aws login. I need to do a one-time setup to bootstrap CDK with npx cdk bootstrap. Once that's done, I can run pnpm deploy to ship it. Then it's live 🚀! !Image description Share this on X/Twitter, and it should render as an embed: https://cxrj1w1j65n0k7ss.p7v.lambda-web.us-east-2.on.aws/embed Full repo: sboult/lwf-three-js --- As always, happy coding 😉! Follow AWS for more articles like this. {% organization aws %} Follow me for all things tech! {% user hacksore %}

CDKにSQLインジェクションリスク github.com/aws/aws-cdk/security/advisories/GHSA-2…

Next.jsをLambda Web Functionsで動かして、同時アクセスとキャッシュと費用を測った はじめに 2026 年 10 月 12 日に、AWS Lambda に Web Functions という新しい種類が加わりました。HTTP サーバーをそのまま Lambda で動かせて、1 つの実行環境が複数のリクエストを同時に処理します。課金も、CPU を実際に使った時間ベースです。 「Next.js のサーバーをそのまま載せられるなら、コンテナで動かす代わりになるのでは？」と思い、検証しました。 この記事では、同じ Next.js アプリを次の 3 つで比べた結果をまとめます。 Lambda Web Functions（新しい方） Lambda Event Functions（従来の Lambda）＋ Lambda Web Adapter ALB ＋ ECS（Fargate）（費用だけ机上で比較） 先に分かったことを書いておきます。 GitHub Actions から aws lambda-web deploy 1 コマンドでデプロイできます。コンテナイメージを作る必要もありません。 50 同時アクセスのコールドスタートで、Web Functions は 6 環境、Event Functions は 50 環境を立ち上げました。 ただし短い負荷試験では、1 環境が同時に処理したのは 最大 2 件でした。I/O 待ちのあるリクエストでは Web Functions も 36 環境まで増えます。数分間の持続負荷では、1 環境 20 件まで上がりました。 Next.js の use cache は環境ごとのメモリにあり、共有されません。revalidateTag も受けた 1 環境にしか効きません。 費用は「CPU 時間＋環境が生きている間のメモリ＋リクエスト数」。I/O 待ちが長い SSR ほど有利です。 既存の記事との関係 リリースから 10 日ほどで、すでに良い検証記事がいくつも出ています。この記事と重なる部分は、次の記事が先に詳しく調べています。 キャッシュが環境ごとに分かれること、EndpointMaxEnvThrottle の 429: Next.js の Vercel 依存機能は、Lambda Web Functions で動くのか？（Qiita） 1 環境の同時処理数が控えめに始まり、負荷が続くと上がること: Lambda Web Functions にアプリを載せ替えて料金と速さを比べてみた（Qiita）、Some notes on Lambda Web Functions（Aidan Steele） この記事では、フロントエンドエンジニアが Next.js を本番で動かすかを判断する目線で、GitHub Actions でのデプロイ、Event Functions との同条件の比較、費用の 3 方式比較を加えています。 検証した環境 項目 内容 計測日 2026-10-19、2026-10-22 リージョン 東京（ap-northeast-1） Next.js 16.4.2（output: "standalone"、cacheComponents: true） Web Functions Node.js 24、Arm64、2 vCPU・2 GB（固定） Event Functions Node.js 24、Arm64、2048 MB、Lambda Web Adapter（レイヤー）、Function URL（レスポンスストリーミング） AWS CLI 2.37.13 以上（aws lambda-web コマンドが必要） 計測元 手元の Mac。応答時間はネットワークの往復を含みます Web Functions と Event Functions には同じビルド成果物を載せています。違いはプラットフォームだけです。 ! 計測の回数について この記事の計測は、個人の検証環境で、各条件 1〜3 回ずつ行ったものです。統計的にしっかり比べたものではないので、数字は「この条件ではこうなった」という参考値として読んでください。 計測用に、Next.js アプリに次のエンドポイントを用意しました。 パス 中身 /api/env どの実行環境が応答したか（環境ごとに起動時に作る ID）と、その環境で何件目かを返す /api/slow?ms=500 指定ミリ秒待ってから返す。DB や外部 API を待つ SSR の代わり。CPU はほぼ使わない /cache use cache の結果（生成した時刻と、生成した環境の ID）を表示する POST /api/revalidate revalidateTag("demo") を実行する 環境の ID は globalThis に置いています。Next.js はルートごとに別のモジュールインスタンスを持つことがあるためです。 lib/runtime-info.ts const g = globalThis as typeof globalThis & { __runtimeState?: RuntimeState }; function state(): RuntimeState { g.runtimeState ??= { envId: randomUUID().slice(0, 8), startedAt: Date.now(), requestCount: 0, }; return g.runtimeState; } 1. Next.js を Web Functions に載せる 1-1. ビルド Next.js の standalone 出力を使います。Web Functions は、待ち受けるアドレスを環境変数 AWS_LAMBDA_HTTP_ENDPOINT（host:port）で渡してきます。Next.js の standalone サーバーは HOSTNAME と PORT を読むので、変換する小さなエントリを挟みます。 index.mjs const endpoint = process.env.AWS_LAMBDA_HTTP_ENDPOINT; if (endpoint) { const i = endpoint.lastIndexOf(":"); process.env.HOSTNAME = endpoint.slice(0, i); process.env.PORT = endpoint.slice(i + 1); } await import("./server.js"); standalone の server.js は public と .next/static を配信しないので、ビルド後にコピーします。 npm run build cp -R .next/standalone dist/web-function cp -R public dist/web-function/public mkdir -p dist/web-function/.next cp -R .next/static dist/web-function/.next/static cp lambda/web-function-entry.mjs dist/web-function/index.mjs Event Functions で動かす場合は、同じディレクトリに Lambda Web Adapter 用の起動スクリプト（PORT=8080 で node server.js）を足して zip にします。 1-2. 事前に用意するもの Web Functions 本体とは別に、めったに変わらない土台を先に作っておきます。今回は CDK で作りました。 リソース 用途 S3 バケット aws lambda-web deploy がビルド成果物を置く 実行ロール Web Functions が動くときの権限（ログ出力など） GitHub の OIDC プロバイダー GitHub Actions がアクセスキーなしで AWS にログインする デプロイ用ロール GitHub Actions が使う権限。特定のリポジトリ・ブランチからだけ使えるよう信頼ポリシーで制限する Web Functions 本体（関数・リビジョン・エンドポイント）は CDK ではなく GitHub Actions で作りました。理由は 2 つです。 2026 年 10 月時点で、aws-cdk-lib には L1（CfnWebFunction など）しかなく、L2 はレビュー中です（aws-cdk#39210）。 コードを変えるたびに CDK でリビジョンを作ると、GitHub Actions 側で切り替えたトラフィックの重みと CloudFormation の状態がずれます。 1-3. GitHub Actions のワークフロー .github/workflows/deploy-web-function.yml name: deploy-web-function on: workflow_dispatch: inputs: create: description: "初回（Web Function がまだ無い）なら true" type: boolean default: false permissions: id-token: write # OIDC で AWS のロールを引き受けるため contents: read env: AWS_REGION: ap-northeast-1 FUNCTION_NAME: my-nextjs jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 24 cache: npm - run: npm ci - run: bash scripts/package.sh # 1-1 のビルドとコピー - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ vars.AWS_DEPLOY_ROLE_ARN }} aws-region: ${{ env.AWS_REGION }} lambda-web コマンドは新しい AWS CLI にしかないので入れ替える - name: Update AWS CLI run: | curl -sSL "awscli.amazonaws.com" -o awscliv2.zip unzip -q awscliv2.zip sudo ./aws/install --update - name: Deploy run: | args=( --name "$FUNCTION_NAME" --code dist/web-function --entry-point index.mjs --bucket-name "${{ vars.CODE_BUCKET_NAME }}" --execution-role-arn "${{ vars.EXECUTION_ROLE_ARN }}" --revision-description "${GITHUB_SHA::7}" --max-environments 50 --rate-limit 100 ) if [ "${{ inputs.create }}" = "true" ]; then args+=(--create) fi aws lambda-web deploy "${args[@]}" aws lambda-web deploy は 1 コマンドで、関数の作成（初回のみ）、コードのアップロード、リビジョンの作成、エンドポイントの公開までを行います。コンテナイメージのビルドやレジストリへの push は要りません。 ロール ARN やバケット名は、秘密情報ではないので Repository variables に入れました。ロールは OIDC の条件で守られているので、ARN が見えても他のリポジトリからは使えません。 1-4. つまずいたところ OIDC でログインできない（Not authorized to perform sts:AssumeRoleWithWebIdentity） 2026 年 7 月 15 日以降に作られたリポジトリでは、GitHub の OIDC トークンの sub に、所有者とリポジトリの数値 ID が入るようになっています（repo:<owner>@<ownerId>/<repo>@<repoId>:ref:refs/heads/main の形）。信頼ポリシーを旧書式（repo:<owner>/<repo>:ref:...）だけで書いていたため、拒否されていました。新旧両方を許可して解決しました。 The rateLimit 50 is invalid エンドポイントの --rate-limit（1 秒あたりのリクエスト数の上限）に指定できるのは、0、100 刻み（1000 まで）、1000 刻み（10000 まで）だけでした。0 はエンドポイントを止める値です。 2. 起動の速さ 条件 Web Functions Event Functions コールド 1 リクエスト 1386 ms 1608 ms ウォーム 1 リクエスト 97 ms 138 ms コールド 50 同時 6 環境、p50 982 ms 50 環境、p50 1484 ms ウォーム 50 同時 15 環境、p50 57 ms 49 環境、p50 47 ms コールド 1 リクエストの値は各 1 回の計測で、手元からの往復も含みます。Web Functions と Event Functions の差（約 200 ms）は、回数を増やすと入れ替わる程度のものかもしれません。そのため、どちらが速いかはこの表からは言い切りません。 それよりも、同時アクセスでの環境の増え方が大きく違います。 Event Functions は 1 つの環境が 1 リクエストしか処理しないので、50 同時なら 50 環境がすべてコールドスタートします。 Web Functions は 6 環境で 50 件をさばきました。1 環境が複数のリクエストを処理するためです。 ウォームの 50 同時で、Web Functions は環境が 9 つ増えました。ただし、新しい環境の応答も 80 ms 前後で、リクエストは初期化を待っていません。Web Functions は、既存の環境が上限に近づくと先回りして環境を用意します（公式ドキュメントの headroom の説明どおり）。 なお、新しい AWS アカウントは Lambda の同時実行数の上限が低いことがあります。Event Functions で 50 同時を測るなら、事前に上限を確認しておくと安心です。 3. 同時アクセスで何環境になるか 3-1. 429 の正体は環境数の上限だった 最初は --max-environments 10 でデプロイしていました。50 同時で送ると、約 6 割が 429 で返ってきました。 --rate-limit が原因だと思って 100 から 1000 に上げましたが、変わりません。応答ヘッダー lambda-web-error-type を集計したところ、すべて Platform.EndpointMaxEnvThrottle でした。 const res = await fetch(url); const errorType = res.headers.get("lambda-web-error-type"); // 例: Platform.EndpointMaxEnvThrottle 環境数の上限（10）に達して、それ以上増やせずに拒否されていました。新しい関数は 1 環境で処理する件数を控えめな値から始めるので、10 環境では 50 同時を受けきれなかったわけです。429 の理由はこのヘッダーで区別できます。 lambda-web-error-type 原因 Platform.EndpointMaxEnvThrottle --max-environments に達した Platform.AccountActiveVCPUArm64Throttle アカウントの Arm64 vCPU のクォータに達した（takumi3488 さんの記事で観測） --max-environments は暴走を防ぐ安全装置として便利ですが、関数を作った直後は小さくしすぎないほうがよいです。 3-2. I/O 待ちがあると、Web Functions も環境が増えた /api/slow?ms=500（500 ms 待つだけ）に 50 同時で送りました。 Web Functions Event Functions 応答した環境 36 50 p50 719 ms 674 ms 「Web Functions なら少ない環境で済む」と予想していましたが、36 環境まで増えました。新しく増えた環境の応答も 720 ms 前後で、初期化を待っていたわけではありません。 CloudWatch のメトリクス EnvironmentConcurrentRequests（1 環境が同時に処理した最大件数、1 分ごと）を見ると、計測中は どの 1 分も最大 2 件でした。 aws cloudwatch get-metric-statistics \ --namespace AWS/Lambda/Web \ --metric-name EnvironmentConcurrentRequests \ --dimensions Name=FunctionName,Value=my-nextjs \ --start-time 2026-10-19T12:10:00Z --end-time 2026-10-19T12:55:00Z \ --period 60 --statistics Maximum Average 50 件が同時に 500 ms 滞在し、1 環境が 2 件までしか受けないなら、最低でも 50 ÷ 2 ＝ 25 環境が必要です。実際は 36 環境で、それより 11 多くなりました。Web Functions は既存の環境が上限に近づくと先回りして環境を足す（headroom）と公式に書かれているので、この 11 はその余裕分だと考えています。ただし、余裕をいくつ持つかは公式に書かれていないので、11 という数までは説明できません。 公式ドキュメントの「1 環境あたり 64 件（最大 128 件）」は、リビジョンの設定 maxConcurrencyPerEnvironment の上限です。実際に何件まで詰めるかは Lambda がリソースの使われ方を見て決める「動的な上限」で、新しい関数は控えめな値から始まります。公式にも「最初の負荷試験は、後の試験より多くの環境を使うことがある」と書かれています（Scaling behavior）。 /api/env（数十 ms で終わる）のコールド 50 同時が 6 環境で済んだのは、1 件がすぐ終わるので、2 件ずつ順番に流せたからだと考えています。環境の数を決めるのは同時アクセス数そのものではなく、同時に滞在している件数（アクセスの多さ × 1 件の処理時間）です。API や DB を待つ SSR ほど環境は増えます。 3-3. 3 日後も、短時間のバーストでは 2 件のまま 3 日後に同じ「500 ms 待ち × 50 同時」を 15 秒おきに 3 回送りました。3 回とも 36 環境、1 環境の最大は 2 件のままでした。数秒のバーストを数回送るだけでは、上がりませんでした。 3-4. 持続負荷をかけると、1 環境の同時処理数が上がる 続けて、500 ms 待ち × 40 同時を 約 7 分間かけ続けました。 時刻（UTC） 応答した環境 1 環境の最大（CloudWatch） p50 開始（1 回目） 20（全部コールド） － 2317 ms 約 1 分後 29 7 545 ms 約 2 分後 6 20 540 ms 3〜7 分後 2 20 541〜574 ms 約 2 分で 1 環境の同時処理数が 2 → 7 → 20 件に上がり、40 件を 2 環境でさばくようになりました。詰め込んでも応答時間は変わっていません（このエンドポイントは CPU をほぼ使わないため）。 asahide さんの記事でも、20 同時を送り続けると 100 秒後に 1 環境が 20 件を処理したと報告されており、傾向は一致します。 ! 分かっていないこと この持続負荷の計測は 1 回だけです。 「負荷が続いたから上がった」のか、「関数を作ってから 3 日たったから上がった」のかは区別できていません。何をきっかけに上げるかは、公式ドキュメントにも書かれていません。 40 件しか送っていないので、20 件が上限なのか、もっと上がるのかは分かりません。 Aidan Steele さんは、maxEnvironments を小さく絞った状態でバーストを繰り返すと、1 環境の件数が上がったと書いています。今回は 50 と大きめにしていたので、環境数に余裕があると、詰めるより環境を増やす方を選んだのかもしれません（推測です）。 3-5. 環境はアイドル約 5〜6 分で回収される 7 分の計測の前、最後のアクセスから約 6 分空いていましたが、1 回目は 20 環境すべてがコールドスタートでした。公式には何分で回収するかは書かれていませんが、BeeX の記事（中央値 346 秒）や Aidan Steele さんの観測（約 5 分）とも合います。 3 章のまとめ 短い負荷試験の環境数だけを見て「環境が増えて高くつく」と判断しないほうがよいです。数分間の持続負荷では、1 環境の同時処理数が上がりました。 逆に、短時間のスパイクが中心のトラフィックでは、環境が多めに出ます。メモリは環境ごとに課金されるので（5 章）、その分は費用に効きます。 1 環境で複数のリクエストを処理するので、重い同期処理（大きな JSON の加工、重いレンダリング）は、同じ環境の他のリクエストも止めます（クラスメソッドの記事が詳しいです）。 4. Next.js のキャッシュは環境ごと 4-1. 書き込めるのは /tmp だけ /var/task/.next/cache には書けませんでした。Next.js のキャッシュはディスクに残らず、メモリだけになります。Event Functions も同じです。 4-2. use cache は環境の数だけ生成される /cache は次のようなコンポーネントです。 app/cache/page.tsx async function getCachedSnapshot() { "use cache"; cacheLife({ stale: 30, revalidate: 60, expire: 3600 }); cacheTag("demo"); return { generatedAt: new Date().toISOString(), generatedOn: currentEnvId() }; } これに 50 同時で送り、レスポンスの「生成した環境」と「生成時刻」を集計しました。 Web Functions Event Functions 応答した環境 20 49 キャッシュの中身の種類 20 種類 49 種類 キャッシュを再利用した件数 30 件 1 件 キャッシュは環境ごとのメモリにあり、環境の数だけ生成が走りました。 Event Functions は 1 環境 1 リクエストなので、同時アクセスではキャッシュがほぼ効きません（50 件中 1 件）。 Web Functions は 1 環境で複数のリクエストを処理するので、同じ環境に来たリクエストでは再利用されます（50 件中 30 件）。 4-3. revalidateTag は受けた環境にしか効かない POST /api/revalidate を 1 回送ってから、また 50 同時で送りました。無効化が効いたのは、POST を受けた 1 環境だけでした。ほかの 20 環境は、古いキャッシュを返しました。 このときの古いキャッシュは、生成から約 25 秒で、cacheLife の stale（30 秒）の範囲内でした。言えるのは「無効化がほかの環境に届かなかった」ことまでで、古いキャッシュを何秒返し続けるかは測っていません。 4-4. 環境が回収されると、キャッシュも消える 約 14 分空けてからアクセスすると、新しい環境 1 つでキャッシュを作り直していました。前の環境は回収され、キャッシュも一緒に消えていました。 4-5. どうするか ここまでの結果は、Web Functions の欠点というより、Next.js を複数のプロセスで動かすと必ず起きることです。既定のキャッシュはプロセスのメモリにあるので、ECS の複数タスクでも同じことが起きます（Next.js のセルフホストのドキュメント）。 共有するには、キャッシュハンドラーを差し替えて、Redis（ElastiCache など）に置くのが一般的です（cacheHandlers）。今回はそこまでは試していません。 ! 4 章の計測は各 1 回です。ISR（ページ単位の revalidate）は、複数の環境では試していません。 5. 費用の比較 5-1. 課金の仕組み 課金されるもの Web Functions CPU を実際に使った時間（1 ms 単位）＋ 環境が動いている間に使ったメモリ（リクエストの合間も含む） ＋ リクエスト数 Event Functions 実行時間（待ち時間を含む）× 割り当てメモリ ＋ リクエスト数 ALB + ECS（Fargate） タスクと ALB が起動している時間 Web Functions のメモリについて、公式の料金ページは「the memory consumed by each execution environment for as long as it runs」、試算例では「including time between requests」と書いています（AWS Lambda の料金）。待ち時間の CPU はほぼ課金されないので、I/O 待ちの長い SSR ほど有利です。最低料金や最小台数の設定はなく、アクセスがなければ 0 環境まで縮みます。 東京リージョンの単価（AWS Price List API、2026-10 時点）は次のとおりです。 サービス 項目 単価（USD） Web Functions（Arm） vCPU $0.0000322421 / vCPU 秒 メモリ $0.0000042688 / GB 秒 リクエスト $0.30 / 100 万件 Event Functions（Arm） 実行時間 × メモリ $0.0000133334 / GB 秒 リクエスト $0.20 / 100 万件 Fargate（Linux x86） vCPU / メモリ $0.05056 / vCPU 時間、$0.00553 / GB 時間 ALB 時間 / LCU $0.0243 / 時間、$0.008 / LCU 時間 5-2. 月額の試算 前提 1 リクエストの CPU 時間 30 ms。実行時間は 150 ms（I/O 待ちが短い SSR）と 500 ms（API 待ちが長い SSR）の 2 通り Web Functions: 1 か月ずっと 1 環境が起動している（月 10 万件でも平均 26 秒に 1 件来るので、ほぼ回収されない想定）。使用メモリは 0.14 GB（実行中の Node.js プロセスの RSS で 137 MB） Event Functions: メモリ 1 GB ALB + ECS（Fargate、x86、常時起動）は 2 パターン。どちらも ALB 1 台（LCU 平均 0.5） 最小構成: 0.25 vCPU / 0.5 GB × 1 タスク 冗長構成: 0.5 vCPU / 1 GB × 2 タスク（2 つの AZ に 1 つずつ置く想定） 含めないもの: データ転送、ECR、CloudWatch Logs、NAT Gateway、無料枠 ! 試算の前提について 1 リクエストの CPU 時間 30 ms は仮の値で、測っていません。アプリによって大きく変わります。 Web Functions の使用メモリ（137 MB）は、軽い負荷で 1 回測った値です。同時アクセスが多いときや、キャッシュが増えたときは、もっと増える可能性があります。 計測で使った Event Functions は 2 GB ですが、試算は 1 GB にしています。2 GB にすると、100 万件で 150 ms なら約 $4.2、500 ms なら約 $13.5 です。 実際の請求額での確認はしていません。 月のリクエスト数 Web Functions Event Functions（150 ms） Event Functions（500 ms） ALB + ECS（最小構成） ALB + ECS（冗長構成） 10 万 約 $1.7 約 $0.2 約 $0.7 約 $31 約 $65 100 万 約 $2.8 約 $2 約 $7 約 $31 約 $65 1,000 万 約 $14 約 $22 約 $69 約 $31 ※ 約 $65 ※ 実行時間（150 ms / 500 ms）で列を分けているのは Event Functions だけです。Event Functions は待ち時間を含む実行時間に課金されるので、API や DB を待つ時間が長いほど高くなります。Web Functions は CPU を使った時間（どちらも 30 ms）に課金されるので、待ち時間が延びても金額はほぼ変わりません。ALB + ECS は起動している時間で決まるので、どちらも同じです。 ※ ECS は、1,000 万件/月（平均で毎秒約 4 件）を 0.25 vCPU のタスク 1 つでさばけるかは確かめていません。足りなければタスクを増やすぶん高くなります。 内訳 Web Functions: メモリ（使用量 GB × 2,592,000 秒 × $0.0000042688。0.14 GB で $1.55）＋ CPU（0.03 秒 × $0.0000322421 / 件）＋ $0.30 / 100 万件 Event Functions: 実行時間 × 1 GB × $0.0000133334 / 件 ＋ $0.20 / 100 万件 ALB + ECS: ALB $17.50 ＋ LCU 約 $2.9 ＝ 約 $20.4 に、タスクの費用を足す 最小構成: （0.25 × $0.05056 ＋ 0.5 × $0.00553）× 720 時間 ＝ $11.09 冗長構成: （0.5 × $0.05056 ＋ 1 × $0.00553）× 720 時間 × 2 タスク ＝ $44.37 読み取れること アクセスが少ないうちは Event Functions が一番安いです。Web Functions には「1 環境ぶんのメモリ」（この試算で月 $1.55）という下限があります。 待ち時間が長いほど Event Functions は高くなり、Web Functions が有利になります。この試算では、実行時間 150 ms なら月約 170 万件、500 ms なら月約 28 万件で逆転します。 ALB + ECS は、最小構成でも ALB とタスクで月 $30 前後の固定費がかかります。その代わり、アクセスが増えても費用が読みやすいです。 Web Functions は、3 章のように短時間のバーストで環境が増えると、そのぶんメモリの課金も増えます。 6. 使わない間はエンドポイントを止める 検証用の環境は、使わない間は止めておくと安心です。予算アラートは通知するだけで、課金は止めません。 止め方 再開 Web Functions エンドポイントの rateLimit を 0（全リクエストを拒否） rateLimit を元の値に戻す Event Functions 予約同時実行数を 0 予約同時実行数の設定を外す Web Functions を止める aws lambda-web update-web-function-endpoint \ --function-name my-nextjs --endpoint-name <エンドポイント名> \ --throttle-config '{"rateLimit": 0}' Event Functions を止める / 再開する aws lambda put-function-concurrency --function-name my-nextjs-event --reserved-concurrent-executions 0 aws lambda delete-function-concurrency --function-name my-nextjs-event まとめ Web Functions Event Functions ALB + ECS デプロイ GitHub Actions から 1 コマンド。CDK の L2 はまだない CDK で完結。Next.js には Lambda Web Adapter などが必要 イメージのビルドとレジストリ、デプロイの仕組みが要る。構成要素は多い 同時アクセス 1 環境で複数処理。ただし最初は 1 環境 2 件程度から。持続負荷で 1 環境あたりの件数が上がる 1 環境 1 リクエスト。同時アクセスは全部コールド 常時起動。スケールに時間がかかる Next.js のキャッシュ 環境ごとのメモリ。同じ環境内では再利用される 同時アクセスではほぼ効かない タスクごと。複数タスクなら共有されない 費用 CPU 時間＋環境ぶんのメモリ。待ち時間に強い 少ないアクセスなら最安 固定費が大きいが読みやすい 注意 リリース直後。Node.js 24 / Arm64 のみ Lambda の各種制約 常時起動の運用 社内ツールや検証環境など、アクセスが少ないもの: Event Functions か Web Functions API や DB を待つ SSR で、アクセスが中程度: Web Functions が有力 常時アクセスが多い、安定運用が最優先: ALB + ECS どれを選んでも: 複数の環境・タスクで動かすなら、Next.js のキャッシュを共有する仕組みが要ります Web Functions はリリースされたばかりで、スケーリングの挙動や CLI は今後変わるかもしれません。この記事の数字は 2026 年 10 月 19 日・22 日時点のものです。 参考 Scaling behavior for Lambda Web Functions（AWS 公式） Lambda Web Function endpoints（AWS 公式） Troubleshooting Lambda Web Functions（AWS 公式） AWS Lambda の料金 Next.js の Vercel 依存機能は、Lambda Web Functions で動くのか？（Qiita） Lambda Web Functions にアプリを載せ替えて料金と速さを比べてみた（Qiita） Lambda Web Functions で Elysia を動かして測ってみた（Qiita） Some notes on Lambda Web Functions（Aidan Steele） Lambda Web Functions と Lambda Web Adapter で Next.js の配信性能を比べてみた（DevelopersIO） Lambda Web Functions の Node.js で CPU バウンドな処理をすると、ほかのリクエストは待たされるか？（DevelopersIO） Lambda Web Functions × Next.js × Cognito を検証した（BeeX）

AWS CDKのS3レプリケーションで「Priority must be specified」と言われたら AWS CDKでS3のクロスリージョンレプリケーションを設定したところ、cdk synth もユニットテストも通ったのに、デプロイでバケットの作成が失敗しました。 Resource handler returned message: "Priority must be specified for this version of Cross Region Replication configuration schema. Please refer to S3 Developer Guide for more information. (Service: S3, Status Code: 400, ...)" (HandlerErrorCode: InvalidRequest) レプリケーションのルールは1つしか書いておらず、優先度を気にする場面ではないです。 最初に結論ですが、S3がPriorityを要求したのは、CDKが出力するレプリケーション設定が「V2」と呼ばれる形式になっており、V2ではルールごとにPriorityが必須だからです。 この記事では、S3レプリケーションのルールとPriorityの役割、V1とV2の違いを整理したうえで、CDKのどの挙動がこのエラーにつながったのかを説明します。 確認した環境は次のとおりです。 aws-cdk-lib 2.268.0（TypeScript） s3.Bucket の replicationRules で、別リージョンの既存バケットへ複製する構成 S3 レプリケーションの仕組み S3 レプリケーションは、バケットに書き込まれたオブジェクトを、別のバケットへ非同期に複製する機能です。 複製先が別リージョンならCross-Region Replication（CRR）、同じリージョンならSame-Region Replication（SRR）と呼ばれます。 バックアップを別リージョンに置くDR構成などでよく使われます。 レプリケーションを動かすには、複製元のバケットにレプリケーション設定を付けます。 レプリケーション設定は、S3が複製に使うIAMロールと、1つ以上のルールから成ります。 ルールには、どのオブジェクトを（フィルター）、どこへ（複製先）、どう複製するか（ストレージクラス、暗号化など）を書きます。 また、複製元と複製先の両方でバージョニングが有効になっている必要があります。 CloudFormationのテンプレートでは、AWS::S3::Bucket の ReplicationConfiguration プロパティに書きます。 "ReplicationConfiguration": { "Role": "arn:aws:iam::111122223333:role/replication-role", "Rules": [ { "...": "1 つ目のルール" }, { "...": "2 つ目のルール" } ] } SSE-KMSで暗号化したオブジェクトは、既定では複製されません。 ルールの SourceSelectionCriteria で明示的にオプトインし、複製先リージョンのKMSキーを EncryptionConfiguration に指定する必要があります1。 ルールのPriorityが決めること レプリケーション設定には複数のルールを書けます。 たとえば、tax/ で始まるオブジェクトと document/ で始まるオブジェクトを別々の条件で複製したい場合は、フィルターの異なる2つのルールを並べます。 複数のルールが同じオブジェクトに当てはまり、しかも複製先のバケットが同じだと、どちらのルールで複製するかを決める必要があります。 Priority は、このようにルールが衝突したときにどのルールを優先するかを決める整数です。 値が大きいほど優先度が高くなります。 S3はすべてのルールに従って複製しようとしますが、同じ複製先を持つルールが衝突したときは、Priorityが最も高いルールに従います。 次の図は、プレフィックスが star のルール 1（Priority 1）と、starship のルール 2（Priority 2）を、同じ複製先に向けて並べた例です2。 star-a.txt はルール 1 にだけ当てはまるので、ルール 1 に従って複製されます。 starship-x.txt は star と starship のどちらのプレフィックスにも当てはまるので、2つのルールが衝突します。 このときS3はPriorityの大きいルール 2 に従い、ルール 2 のストレージクラスで複製します。 moon.txt はどちらのルールにも当てはまらないので、複製されません。 裏を返すと、ルールが1つしかない設定や、ルール同士が別々のオブジェクトにしか当てはまらない設定では、Priorityの値は結果に影響しません。 S3 ユーザーガイドの設定例でも、ルールが1つの例について「Priorityの値は関係ない」と説明しています。 それでもPriorityを書かなければならない場合があるのは、次に見る設定の形式によるものです。 レプリケーション設定の V1 と V2 レプリケーション設定には、V1 と V2 の2つの形式があります。 現在の最新はV2で、S3は後方互換のためにV1も受け付けています。 S3は、ルールの書き方から形式を判別します。 ルールに Filter がある設定、または S3 Replication Time Control（S3 RTC）を指定したルールがある設定がV2です。 V1では Filter を使わず、Prefix をルールの直下に置きます。 CloudFormationのテンプレートで書くと、次のような違いになります。 V1 のルール（Prefix をルールの直下に置く） { "Status": "Enabled", "Prefix": "key-prefix", "Destination": { "Bucket": "arn:aws:s3:::destination-bucket" } } V2 のルール（Filter を使い、Priority と DeleteMarkerReplication も書く） { "Status": "Enabled", "Filter": { "Prefix": "" }, "Priority": 1, "DeleteMarkerReplication": { "Status": "Disabled" }, "Destination": { "Bucket": "arn:aws:s3:::destination-bucket" } } 2 つの形式の違いは次のとおりです。 項目 V1 V2 判別方法 Filter を使わない Filter がある、またはS3 RTCを指定している 対象の絞り込み キーのプレフィックスのみ（ルール直下の Prefix） プレフィックス、タグ、その組み合わせ（Filter） Priority 書けない 必須 DeleteMarkerReplication 書けない 必須 削除マーカーの複製 ユーザーの削除操作で付いた削除マーカーだけを複製する ルールごとに有効か無効かを選べる（タグベースのルールを除く） S3のドキュメントには、Filter を指定するなら Priority と DeleteMarkerReplication も含める必要があると書かれています。 逆に、V1の設定にPriorityを書くと「Priority cannot be used for this version of Cross Region Replication configuration schema」というエラーになります3。 冒頭のエラーメッセージの正体はこいつというわけです！ V2と判定された設定にPriorityが無かったことを意味しています。 CloudFormationの AWS::S3::Bucket ReplicationRule では、Priority も Filter も Required: No です。 Priorityが必須かどうかは、同じルールの中に Filter があるかどうかで決まるため、プロパティ単体の必須指定としては表せません。 そのため、テンプレートの形だけを見る検証では、この誤りを見つけにくくなっています。 修正前のコード 失敗したのは、次のようなコードです。 複製元バケットをKMSで暗号化し、別リージョンにある既存のバケットへ、SSE-KMSのオブジェクトも含めて複製します。 source-bucket.ts（修正前） import * as kms from 'aws-cdk-lib/aws-kms'; import * as s3 from 'aws-cdk-lib/aws-s3'; // 複製先（別リージョン）のバケットと KMS キー const destinationBucket = s3.Bucket.fromBucketAttributes(this, 'DestinationBucket', { bucketName: 'example-destination-bucket', region: 'ap-northeast-3', }); const destinationKey = kms.Key.fromKeyArn( this, 'DestinationKey', 'arn:aws:kms:ap-northeast-3:111122223333:key/mrk-EXAMPLE', ); // 複製元の KMS キー const sourceKey = new kms.Key(this, 'SourceKey'); new s3.Bucket(this, 'SourceBucket', { encryption: s3.BucketEncryption.KMS, encryptionKey: sourceKey, versioned: true, replicationRules: [ { destination: destinationBucket, kmsKey: destinationKey, sseKmsEncryptedObjects: true, }, ], }); ルールは1つで、filter も priority も指定していません。 このコードから合成されるテンプレートのルールは、次のようになります。 合成されたテンプレート（抜粋） "ReplicationConfiguration": { "Role": { "Fn::GetAtt": ["SourceBucketReplicationRoleXXXXXXXX", "Arn"] }, "Rules": [ { "DeleteMarkerReplication": { "Status": "Disabled" }, "Destination": { "Bucket": "arn:aws:s3:::example-destination-bucket", "EncryptionConfiguration": { "ReplicaKmsKeyID": "arn:aws:kms:ap-northeast-3:111122223333:key/mrk-EXAMPLE" } }, "Filter": { "Prefix": "" }, "SourceSelectionCriteria": { "SseKmsEncryptedObjects": { "Status": "Enabled" } }, "Status": "Enabled" } ] } コードで指定していない Filter と DeleteMarkerReplication が出力される一方で、Priority は出力されていません。 Filter があるのでS3はこの設定をV2と判定し、Priorityが無いことを理由にバケットの作成を拒否しました。 CDK のどの挙動がエラーにつながったのか CDKの s3.Bucket の実装（bucket.ts）を見ると、原因は次の3点に分けられます。 以下の引用は、記事執筆時点のmainブランチから必要な部分だけを抜き出し、一部を省略したものです（コード中の日本語コメントは私が書いてます）。 1. Filter を必ず付けるので、設定は常に V2 になる CDKは、filter を指定しなくても空のプレフィックスで Filter を作ります。 aws-s3/lib/bucket.ts（抜粋） const prefix = rule.filter?.prefix ?? ''; const filter = isAndFilter ? { and: { prefix, tagFilters: rule.filter?.tags } } : { prefix }; Filter があるので、CDKで作ったレプリケーション設定は必ずV2として扱われます。 2. priority は省略すると出力されない priority は、指定された値がそのまま渡されるだけです。 aws-s3/lib/bucket.ts（抜粋） return { id: rule.id, priority: rule.priority, // 未指定なら undefined のまま // ... filter, deleteMarkerReplication: { status: rule.deleteMarkerReplication ? 'Enabled' : 'Disabled' }, }; 同じV2の必須項目でも、DeleteMarkerReplication は未指定なら Disabled で補われます。 一方の priority は補われないので、省略するとテンプレートから消えます。 priority のJSDocには @default 0 とありますが、実装に0を補う処理はありません。 3. priority の漏れを検査するのは、ルールが 2 つ以上のときだけ 合成時の検査は、次の1か所です。 aws-s3/lib/bucket.ts（抜粋） if (props.replicationRules.length > 1 && props.replicationRules.some(rule => rule.priority === undefined)) { throw new ValidationError(/* ... */ "'priority' must be specified for all replication rules when there are multiple rules", this); } 条件に length > 1 があるので、ルールが1つなら priority を省略しても合成は成功します。 これらにより、CDKは常にV2で出力するのに、V2で必須のPriorityはルールが1つだと補いも検査もしません。 CloudFormationのスキーマでもPriorityは任意なので、誤りに気づくのはデプロイ時のS3APIになります。 筆者の環境でも、cdk synth とユニットテストは成功し、CloudFormationがバケットを作成する段階で失敗しました。 修正後のコード 修正は、ルールに priority を明示するだけです。 ルールが1つなので、値は何でも構いません。 source-bucket.ts（修正後） new s3.Bucket(this, 'SourceBucket', { encryption: s3.BucketEncryption.KMS, encryptionKey: sourceKey, versioned: true, replicationRules: [ { destination: destinationBucket, kmsKey: destinationKey, sseKmsEncryptedObjects: true, - // CDK は Filter 付き（V2）のルールを出力し、V2 では Priority が必須になる。 - // priority を省略すると Priority が出力されないため明示する - priority: 1, }, ], }); 合成されるルールには "Priority": 1 が加わり、デプロイも成功するようになりました。 合成されたテンプレート（抜粋） "Filter": { "Prefix": "" }, - "Priority": 1, "SourceSelectionCriteria": { 同じ指定漏れを繰り返さないように、ユニットテストでもPriorityの出力を確かめておくと安心です。 スナップショットテストだけだと、Priorityが「無い」ことは差分として現れないため、見落としやすくなります。 source-bucket.test.ts import { Match, Template } from 'aws-cdk-lib/assertions'; test('レプリケーションルールに Priority が出力される', () => { const template = Template.fromStack(stack); template.hasResourceProperties('AWS::S3::Bucket', { ReplicationConfiguration: Match.objectLike({ Rules: [ Match.objectLike({ // Filter 付き（V2）のルールは Priority が無いと S3 に拒否される Filter: Match.anyValue(), Priority: 1, }), ], }), }); }); おわりに S3レプリケーションのPriorityは、本来は複数のルールが衝突したときの優先順位を決める値です。 しかし、レプリケーション設定がV2形式であれば、ルールが1つでも書かなければなりません。 CDKの replicationRules は設定を常にV2で出力するので、ルールの数にかかわらず priority を明示しておくのが確実だと思います。 今回のように、あるプロパティが必須かどうかが別のプロパティの有無で決まる制約は、デプロイ先のサービスのAPIが初めて検査します。 こうした制約が絡むプロパティは、テストで出力そのものを確かめておくと、デプロイ前に気づける可能性が高まって良いかと思います！ 参考にしてください！ 参考 Replication configuration file elements（Amazon S3 ユーザーガイド） AWS::S3::Bucket ReplicationRule（AWS CloudFormation テンプレートリファレンス） ReplicationRule（Amazon S3 API リファレンス） aws-cdk-lib/aws-s3/lib/bucket.ts（aws/aws-cdk） feat(s3): replicating objects（aws/aws-cdk #30966） Is there a way to enable ReplicationConfiguration for AWS S3 Replication management using s3.putbucketreplication API?（Stack Overflow） 脚注 複製元のKMSキーでの復号と、複製先のKMSキーでの暗号化の権限も、レプリケーション用のIAMロールに必要です。CDKの replicationRules を使うと、これらの権限を持つロールが自動で作られます。 ↩︎ S3 ユーザーガイドの「プレフィックスが重なる2つのルール」の例をもとにしています。違いがわかるように、ルールごとに複製後のストレージクラスを変えています。 ↩︎ Stack Overflowで、V1の設定にPriorityを付けてこのエラーになった事例が報告されています。 ↩︎

Finally, Real Event Buses! I haven't been excited about many new AWS features this year, but the notification about the relaunch of EventBridge event buses caught my attention! This update brings long-overdue improvements to EventBridge and will be a real benefit for organizations trying to build an event-driven platform. This update addresses many of the multi-account and multi-team challenges we've seen for years. I've seen an organization develop its own serverless eventing platform to avoid these limitations in EventBridge. These improvements truly are long overdue. The Problem with Classic Buses With classic EventBridge buses, you have to manage your rules and targets in the same account and region as the bus you are listening to. For small applications or utilities that listen to AWS events for that account, this isn't a problem. If you are building a multi-region or multi-account application, things get challenging quickly. If you're building a true event bus, that means either everyone needs access to the central account where the bus was created, or a platform team manages all subscriptions. You could forward events to buses in different accounts, but then you lose central visibility into what is connected to the bus. If your application needs to run in multiple regions, you can send events to buses in different regions, but there is no built-in deduplication. So if you need all events to be present in both regions, you must craft the filtering criteria to avoid creating a loop with the buses. With classic EventBridge buses, you are also limited to AWS's event format. You can include whatever structure you want in your message details, but AWS sets the overall structure, which is pivotal to how classic EventBridge buses work. You also have no options for ordering within a classic bus; if you need your messages to arrive in order, you have to implement something else to sort them further down the line. That said, classic EventBridge buses are not deprecated. You can migrate to the newer buses if you want; AWS has some guidance, but you can also keep running your existing event bus. What's New? These new event buses change some of the concepts used in EventBridge. Instead of rules, the new event buses use a subscriber concept. Subscribers determine the events you want, using filters, and the one target that receives them. Subscribers can optionally include a transform that modifies the event before passing it to the target. Your subscribers end up encapsulating all the details to get specific events to a particular target. You can use AWS RAM (Resource Access Manager) to share the bus with your organization or specific AWS accounts. Once you have shared the bus, the target account needs to accept the invitation in the RAM console. After that, the bus shows up in the target account's bus list, where they can add subscribers or publish events. You can see basic information about the subscribers added to your bus, such as name, ordering type, account ID, and creation and update dates, but you don't see what they integrate with, their tags, or other details. If you have an organization that follows AWS Well-Architected principles and uses different accounts for different applications, this allows you to provide a centrally managed bus that different applications, and presumably teams, can publish and subscribe to. With this central management, you can monitor the rate of events flowing through the bus and, if required, revoke account access, for example, due to a cybersecurity incident involving one application. These new event buses offer the option to choose between unordered and FIFO delivery per subscriber. This, combined with batching configuration, transformations, and filtering, gives you flexibility in how downstream applications receive events. Part of this is event deduplication, which can be either content-based or ID-based. Another area where you have more flexibility now is in the types and formats of your events. Multiple content types are supported; at launch, they are JSON, Avro, Protobuf, and octet streams. You can also adjust what the events delivered to your target look like; you choose whether you want the raw payload, metadata applied by AWS included, or payload adjusted by a JSONata expression. This means you want to use your own format, AWS's metadata, or something like the CNCF-backed CloudEvents specification. Retention of events is built into the new event bus; you can retain events for as little as 1 day or as long as 1 year. When you add a subscriber, you can choose a starting point for the events it receives. Often, that will be the latest event after the subscription is created, but it can also be earlier within your retention window. This allows you to replay events to a new subscriber. Unfortunately, there isn't a replay API to let you arbitrarily replay events to a subscriber. Instead, you would need to create a new subscriber to the same target as your existing subscriber, and specify the time span of events you want replayed. Once events reach the end of the timestamp, they will stop being delivered. Exciting, but Use Caution Keep in mind, this new version of the EventBridge bus is still new and was only deployed in 14 regions at release. It's likely to receive some patches and adjustments in the coming months. Prototype away, but I'd be cautious about using it for critical production systems for the next month or two. I don't expect major issues, but you should weigh the risks. CloudFormation has been updated to include the new resource types for this functionality. However, some of the CloudFormation validation tooling has not been updated. The CDK is not updated for these new event buses. They only support the L1 constructs that mirror the CloudFormation resources, but those aren't even complete and require escape hatches to function. I've submitted a bug report to the CDK project to let them know about the issue. This lack of robust infrastructure-as-code support is my primary reason for advising caution. Unless you are using CloudFormation directly, give it some time. The CDK and Terraform don't have good support yet, and that takes a little time. Use Case I'm excited by this new event bus because of the functionality I have in mind for it. At work, we have a system with some event-driven aspects, but bringing it together into an event bus will give us much greater flexibility. We also have an active-standby architecture, and I want to shift that towards an active-active configuration. One challenge we have is that some of our events must be ordered. It's a long road, but this new option for an event bus gives me some hope. I've created a very basic example of this architecture using the CDK, escape hatches and all, with a multi-region configuration where the buses forward events across regions and Lambda functions subscribe to log the events they receive. !AWS architecture diagram showing a two-region configuration with an identical configuration in each region. Each region has an event bus with events flowing to two subscribers. One subscriber points to the event bus in the other region and the other subscriber points to a Lambda function. My proof of concept uses content-based deduplication and works well; aside from requiring escape hatches, I'm happy with how it turned out. In a more fully developed application, I would expect many subscribers to use a dead-letter queue. In the system I am envisioning, I would still need to implement idempotency. The Powertools for Lambda (Python, TypeScript) might help with that, but that is a PoC for another time. {%embed jbutz/aws-relaunched-eventbridge-poc %} As I said, I'm excited about this relaunch of EventBridge event buses, and I look forward to what this will allow us to build. Still, for now, I'm limiting myself to proofs of concept while IaC support is more fully built out and more regions have the service relaunched.