HTTPリクエストをLambdaやコンテナへ通す入口は、API Gateway・ALB・Lambda Function URLの3択に集約されます。機能が多い順に高く、軽い順に守りが薄い。この記事では、SIer/エンタープライズの現場で迷わないよう、機能差とコスト、そして選定を誤ると効く落とし穴を判断軸として整理します。
013手段は「守りの厚さ」で並ぶ
HTTPリクエストをLambda関数やコンテナへ通す入口は、実務上ほぼ3択に収束します。Amazon API Gateway、Application Load Balancer（ALB）、そしてLambda Function URLです。この3つは横並びの競合ではなく、機能（＝守りの厚さ）が多い順に単価が高く、軽い順に自前で守る範囲が広がるという一直線上に並んでいます。ここを取り違えると、「軽さで選んだのに結局WAFもスロットリングも自作する羽目になった」あるいは「フルスペックのゲートウェイを立てたが使うのは素通しだけ」という、どちらもよくある失敗に落ちます。
本記事では、まず各手段が「何を肩代わりしてくれるか」を一次情報ベースで押さえ、次にコスト、最後に判断軸と決定表へ落とし込みます。Lambdaの本体側の作り込みはLambda 本番運用の実践、VPC内リソースへの接続はLambda の VPC ネットワーキングで別途扱っていますので、本記事は「入口の選定」に集中します。
02API Gateway：REST と HTTP は別物として扱う
API Gatewayは3手段の中で最も高機能な入口です。ただし注意すべきは、API Gatewayの中にREST APIとHTTP APIという性格の異なる2製品が同居している点です。名前が紛らわしいですが、HTTP APIは「REST APIの新版」ではなく、機能を絞って低価格・低レイテンシに振った別ラインです。AWSの公式ドキュメントも「REST APIはより多くの機能を、HTTP APIは最小限の機能を低価格で」と明言しています。
実務でよく効く差分だけを挙げると次のとおりです（詳細と最新は公式の比較表で必ず確認してください）。
- REST APIのみ：API キー／使用量プラン、
per-clientのスロットリング、リクエストバリデーション（JSONスキーマ検証）、AWS WAF連携、プライベートエンドポイント、エッジ最適化、レスポンスキャッシュ、リクエストボディ変換、X-Rayトレース。 - HTTP APIのみ：JWTオーソライザー（Cognito等のIdPと直結）、自動デプロイ、AWS Cloud Mapへのプライベート統合。
- 両方：Lambda統合、IAM認証、Lambdaオーソライザー、カスタムドメイン、CORS、CloudWatchメトリクス/アクセスログ、NLB/ALBへのプライベート統合。
03ALB：既存VPCとL7ルーティングに馴染ませる入口
ALBは元来コンテナ／EC2向けのL7ロードバランサーですが、Lambdaをターゲットグループに登録して直接呼び出せます。Elastic Load BalancingがLambdaを同期呼び出しし、パスやヘッダーのリスナールールでルーティングします。関数側はstatusCode・headers・bodyを含むレスポンスドキュメントを返し、ELBがそれをHTTPレスポンスに変換します。
ALBが光るのは、すでにALB前提のVPC構成があり、その裏側にLambdaもコンテナも混在させたいケースです。「/api/* はECSタスクへ、/webhook はLambdaへ」といった同一ホスト内のパスベース振り分けが1つのALBで完結します。WAFはALBに直接アタッチでき、既存のセキュリティグループ／サブネット設計にそのまま乗ります。ECS/EKSとの入口を揃えたい場合は、ECS と EKS の選定やFargate と EC2 起動タイプの議論とセットで検討すると一貫します。
一方で、ALBはAPI管理機能を持ちません。APIキー、使用量プラン、リクエストバリデーション、スキーマ管理、レスポンスキャッシュ、こうしたものは一切なく、認証もWAFやOIDC連携（Cognito/OIDCのリスナー認証）で組む前提です。「APIらしい入口」を期待するとギャップが出ます。またALBは常時起動でありLCU課金が走るため、トラフィックが薄いと固定費が相対的に重くなります。
04Lambda Function URL：最軽量、ただし守りは自前
Lambda Function URLは、関数に直接HTTPS URLを1本生やす最軽量の手段です。ゲートウェイもロードバランサーも挟まず、追加料金はゼロ（Lambdaの実行料金のみ）。認証はAuthTypeで二択です。
AWS_IAM：IAMプリンシパルの署名付きリクエストのみ許可。呼び出し側にlambda:InvokeFunctionUrlとlambda:InvokeFunction権限が必要です（2025年10月以降、新規Function URLは両方が必須になりました）。NONE：認証なしの公開。リソースベースポリシーで公開を許可した瞬間、URLを知る誰でも叩けます。
ここが最大の落とし穴です。Function URLにはWAFも、per-clientのスロットリング（レート制限）も、APIキーも、リクエスト検証もありません。NONEで公開Webhookを受ける、といった使い方はDDoSやabuseに対して丸腰になります。theburningmonk（Yan Cui）氏の解説でも、Function URLはこうした保護機構を持たないため、公開エンドポイントとして使うなら前段にCloudFrontを置く等の補強が要る、と整理されています。
NONE公開は「社内ツールの検証用」「CloudFront + WAFを前段に必ず置く」のいずれかに限定する運用ルールを敷くのが安全です。IAM Access AnalyzerでFunction URLの外部公開を継続監視できるので、SCPと合わせて「AuthType=NONEの作成を組織で禁止」しておくとガバナンス事故を防げます。ガバナンス設計はマルチアカウント統制も参照してください。053手段の機能マップ
「どこまで肩代わりしてくれるか」を1枚に整理すると、選定の議論が一気に速くなります。REST APIを右端、Function URLを左端に置き、守りの厚さで並べたものが下図です。
06コスト構造の違いを直感で押さえる
3手段は課金モデルがそもそも異なります。単価の丸暗記より、「リクエスト従量か、時間従量か、ゼロか」を掴むのが実務では効きます（金額はリージョン・時期で変わるため、必ず公式の料金ページで最新を確認してください）。
- Lambda Function URL：入口の追加料金はゼロ。Lambda実行料金だけで動きます。最も安く、トラフィックが薄いほど有利。
- API Gateway HTTP API：リクエスト従量。公式の例では100万リクエストあたり約$1.00と、REST APIより大幅に安い水準です。使わない時間帯の固定費はありません。
- API Gateway REST API：リクエスト従量。100万リクエストあたり約$3.50が基準で、HTTP APIの数倍。ただしAPIキー・WAF・検証・キャッシュ等の機能込みの値段と捉えます。
- ALB：時間課金（稼働時間）＋LCU従量。リクエストが少なくても常時起動の固定費が走るのが他2手段と決定的に違う点です。トラフィックが厚くなるほど1リクエストあたりの単価は下がり、逆に薄いと割高になります。
07判断軸と決定表
選定は次の順で問うと、たいてい一意に決まります。上から順に「Yes」で止まったところが答えです。
- APIキー配布 / ゲートウェイでのリクエスト検証 / レスポンスキャッシュ / WAFのどれかが要る？ → Yesなら API Gateway REST API。
- JWT（Cognito/外部IdP）でエンドポイントを保護したい、かつ上記の重装備は不要？ → Yesなら API Gateway HTTP API。
- 既にALB前提のVPCがあり、コンテナとLambdaを同じ入口・同じパス体系で捌きたい？ → Yesなら ALB（WAFはALBに直付け）。
- 認証はIAM署名で足り、公開するとしてもCloudFront+WAFを前段に置ける、単発の軽い関数？ → Yesなら Lambda Function URL。
要件対応を一覧にすると次のとおりです。◎=標準機能、△=前段や自作で補う、×=非対応。
08選定を誤りやすい典型パターン
最後に、現場でひっくり返りやすいアンチパターンを挙げておきます。
- 「安いから」でHTTP APIを選んだがWAF要件が後出し：HTTP APIにWAFは付きません。後からWAFが必須になると、前段にCloudFrontを挟むかREST APIへ作り直すことになります。セキュリティ要件は最初に確定させます。
- Function URLの
NONEで公開Webhookを受けてしまう：レート制限もWAFもないため、URLが漏れた瞬間にabuseへ丸腰です。公開するならCloudFront+WAFを前段に必須とします。 - Lambda1本のためにALBを新設：常時起動の固定費が乗るため、薄いトラフィックではほぼ割高です。ALBは"既にある"時の相乗り先と考えます。
- REST APIを素通し用途で使う：機能を一切使わないなら、その分の単価が無駄です。素通しならHTTP APIかFunction URLで十分です。
- プライベートAPIをHTTP APIで組もうとする：プライベートエンドポイントはREST APIのみ。VPC内クローズドなAPIが要件なら、REST API（プライベート）かALB（内部）を選びます。
認証設計まで踏み込む場合は、IdPをFargate上に自前で持つKeycloak on Fargate リファレンスアーキテクチャや、認可の粒度を詰めるIAM 最小権限の現実も合わせて設計すると、入口と認証が一気通貫になります。
—まとめ
3手段は「守りの厚さ」で一直線に並びます。WAF・APIキー・検証・キャッシュのどれかが要ればREST API、JWT主体で軽くしたいならHTTP API、既存ALBにコンテナと相乗りするならALB、単発で最軽量ならFunction URL。この順に判断軸を当てれば、たいてい一意に決まります。誤りやすいのは、後出しのセキュリティ要件（特にWAF）と、Function URLのNONE公開、そしてLambda1本のためのALB新設です。機能・コスト・守りの3点を最初に揃えて確定させることが、作り直しを避ける最短ルートです。数値・料金・上限はバージョンやリージョンで変わるため、必ずAWS公式の最新情報でご確認ください。