Lambda Web Functionsは既定で認証なしの公開URL 情シスが先に決める設定

AWSが2026年10月12日に提供を始めた「AWS Lambda Web Functions」は、ポートで待ち受けるふつうのWebアプリを、書き換えずにLambdaで動かせる仕組みです。発表の中身は、AWSのLambda Web Functions提供開始、東京も対象にまとめています。

この記事では、AWSの公式ドキュメントを読んで分かった、情シスが先に決めておくことを書きます。要点は3つです。

• 1つのコマンドで作ると、既定では認証なしで、だれでも開けるURLができます。
• 環境の数と、1秒あたりのリクエスト数の上限は、既定では設定されません。
• URLへのアクセスの記録(CloudTrail)は、既定では残りません。

どれも「便利に始められる」ための既定値です。会社で使うなら、開発者が最初の1本を出す前に、決めておくことがあります。

何が増えたのか Lambdaは3つの形に

AWSは今回、Lambdaを3つの形に整理しました。

Event Functionsへの呼び名の変更について、AWSは「名前だけの変更で、既存の関数のコードの変更や再デプロイは要らない」と書いています。

Web Functionsでは、ExpressやNext.jsなどのNode.jsのフレームワークを、Lambda用の変換の部品(アダプター)なしで動かせます。Webの処理は、データベースやほかのAPIの返事を待つ時間が長くなりがちです。待っているあいだのCPUには課金しない、というのが料金の考え方です。

1つのコマンドで何が作られるか

AWSのブログは、aws lambda-web deploy という1つのコマンドで、事前の準備なしにURLまでできると紹介しています。ドキュメントによると、最初の実行で次のものが作られます。

• コードを置くS3バケット(バージョニングを有効にしたもの。既にあれば使い、無ければ作る)
• CloudWatch Logsに書き込む権限を持つIAMの実行ロール(同じく、無ければ作る)
• Web Functionと、最初のリビジョン(コードと設定の、変更できない写し)
• dev という名前のエンドポイント。1つのリージョンで動くHomeRegionの型で、新しいリビジョンへ自動で切り替わる設定

そして、このコマンドが作るエンドポイントの認証は、既定でApplicationManagedです。Lambdaは認証をせず、URLを知っている人はだれでも呼び出せます。ドキュメントは「既定では、スターターのエンドポイントは認証なしでリクエストを受け付ける。IAMの認可を求めるには --auth-type IamAuth を付ける」と書いています。

既定のリソースを作らせる場合、実行する人には、iam:CreateRole・iam:PutRolePolicy・s3:CreateBucket・s3:PutBucketPolicy などの権限が要ります。

編集部の補足です。開発者の手元の権限が広い会社では、情シスが知らないうちに、ロール・バケット・公開URLが1回のコマンドでそろいます。検証のつもりの dev が、そのまま外から開ける状態で残ることも考えられます。

公開の範囲 認証の型は2つ

エンドポイントごとに、認証の型を選びます。あとから変えることもできます。

ネットワークについて、ドキュメントに書かれている注意は次のとおりです。

• エンドポイントのドメインは、インターネットから届きます。PrivateLinkのインターフェイスエンドポイントは使えません。
• IamAuthは、呼び出せる相手を絞るものです。ネットワークの上でエンドポイントを非公開にするものではありません。
• 独自ドメインとAWS WAFは、エンドポイントに直接は付けられません。必要なら、前にCloudFrontを置きます。
• ApplicationManagedのままCloudFrontを前に置いても、エンドポイントのドメインへ直接来たリクエストは、CloudFrontとWAFを通りません。
• CloudFrontからだけ受けるには、IamAuthにして、CloudFrontのOAC(オリジンアクセスコントロール)で署名させます。あわせて、自社のディストリビューションだけを許すリソースベースのポリシーを付けます。

組織で、認証なしのエンドポイントを止める

AWS Organizationsでアカウントをまとめている会社向けに、ドキュメントはSCP(サービスコントロールポリシー)の例を載せています。リクエストの中の認証の型を表す条件キー lambda:Request/WebFunctionAuthType が ApplicationManaged のとき、作成と更新を拒否する内容です。

このSCPを入れると、aws lambda-web deploy は --auth-type IamAuth を付けない限り、アクセス拒否で失敗します。公開サイトを出すアカウントだけを対象から外す、という使い分けができます(使い分けの部分は編集部の補足です)。

費用 上限は既定では付かない

課金は、リクエスト数、実際に使ったCPU時間、環境があるあいだのメモリ、データ転送の4つです。メモリは、リクエストが来ていない待ち時間も、環境が残っているあいだはかかります。

2026年10月13日に料金ページで確かめた単価(Arm)は、次のとおりです。

東京は、CPUとメモリがバージニア北部より約16%高い計算です(編集部の計算)。

AWSの料金ページには、試算の例が4つあります。1つ目は、サーバー側で画面を作るWebアプリです。月1,500万リクエスト、1件150ミリ秒のうちCPUを使うのが40ミリ秒、メモリは約500MB、環境が1つだけ動き続けるという前提で、バージニア北部では月25.78ドルです。同じ式に東京の単価を入れると、約29.27ドルになります(編集部の試算。無料枠とデータ転送は入れていません)。

気を付けたいのは、台数と流量の上限です。

maxEnvironments と rateLimit は、既定では設定されません。設定しない場合に効くのは、アカウントの上限(リージョンごと)だけです。

• 1つのエンドポイントで、1秒あたり10,000リクエスト
• アカウントの全エンドポイントの合計で、1秒あたり100,000リクエスト
• vCPUは2,000まで。1つの環境が2 vCPUを使うので、計算上は1,000環境まで(編集部の計算)

編集部の補足です。認証なしの公開URLで、上限が既定のままだと、アクセスが急に増えたときに、アカウントの上限まで環境が増える余地があります。攻撃や、巡回するボットによるアクセスでも同じです。公開する前に rateLimit と maxEnvironments の値を決め、費用の通知も設定しておくと、請求で初めて気づくことを防げます。rateLimit を超えたリクエストには、HTTP 429が返ります。

動かせるもの・動かせないもの

開発の担当や委託先に、先に伝えておきたい条件です。

複数リージョンの型(MultiRegion)について、ドキュメントは「Lambdaは、ヘルスチェックにもとづくフェイルオーバーをしない」と書いています。災害対策の切り替えの仕組みとして見るのは避けてください。

もう1つ、運用で気づきにくい点があります。Lambdaは、リビジョンを作るときに、サーバーが待ち受けを始めたかどうかを確かめません。画面でActiveと出ていても、リクエストが失敗することがあります。公開の前に、実際にURLを開いて確かめる手順を入れておきます。

ログと監査 残るもの・残らないもの

アプリのログは、動いたリージョンごとの .local という名前のロググループに書かれてから、ホームリージョンのロググループに集められます。保持期間は、両方に設定します。ホームリージョンだけ直しても、各リージョンの .local のログは残り続けます。

影響する会社・しない会社

• 影響する: AWSで、開発者にLambdaの広い権限を渡している会社。新しい操作のアクション名は lambda: で始まります。lambda:* のようにまとめて許可しているポリシーには、新しい操作も含まれます(編集部の補足)。
• 影響する: Node.jsのWebアプリやAPIを、開発会社やフリーランスにAWSの上で作ってもらっている会社。委託先のアカウントや権限で、公開URLが作られることがあります。
• 影響する: すでにLambdaでWebやAPIを動かしている会社。移すかどうかを比べる対象になります。
• 影響しない(いまは): Node.js以外の言語で作っているアプリ。提供開始のときのランタイムは、Node.js 24だけです。
• 影響しない: 既存のLambda関数。呼び名がEvent Functionsに変わるだけで、コードの変更や再デプロイは要りません。
• 影響しない: AWSを使っていない会社。

情シスが今日やること

1. もう作られていないかを確かめる。CloudTrailのイベント履歴で、イベント名 CreateWebFunction と CreateWebFunctionEndpoint を探します(過去90日)。Lambdaのコンソールの「Web Functions」でも一覧できます。提供中の5つのリージョン(東京・バージニア北部・オハイオ・オレゴン・アイルランド)をそれぞれ見ます。
2. 認証なしの公開を、どのアカウントで許すかを決める。AWS Organizationsを使っているなら、ドキュメントのSCPの例を入れ、公開サイトを出すアカウントだけを対象から外します。
3. Lambdaの権限を持つロールを洗い出す。lambda:* を許可しているポリシーと、iam:CreateRole・iam:PassRole・s3:CreateBucket を併せ持つロールを一覧にします。
4. 公開するときの型を決めておく。CloudFrontを前に置き、IamAuthとOACで直接のアクセスを止める。rateLimit と maxEnvironments に値を入れる。費用の通知を設定する。この3点を、公開の前の確認項目にします。
5. ログの扱いを決める。URLへのアクセスの記録(データイベント)を取るかどうかと、ロググループの保持期間です。
6. 開発の担当と委託先に、上の「動かせるもの・動かせないもの」の条件を伝える。WebSocketを使うアプリや、Node.js以外のアプリは、そのままでは対象になりません。

書かれていないこと

確かめた資料に、次の点は書かれていません。

• Node.js以外の言語や、x86への対応の時期
• 提供するリージョンが増える時期。提供中のリージョンは、AWSの「AWS Capabilities by Region」のページで確かめられます
• 円での料金。単価はドルです
• 稼働率の保証(SLA)の対象かどうか