---
title: "API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ"
url: "https://www.issoh.co.jp/tech/details/18499/"
published: 2026-10-18
updated: 2026-10-18
categories: ["AWS"]
publisher: "株式会社一創"
---

# API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ

Amazon API GatewayとALB（Application Load Balancer）は、どちらもLambdaやECSの前に置いてHTTPリクエストを受けられます。違いは課金の形と上限値に表れ、API Gatewayはリクエスト数に比例し、統合タイムアウトは29秒か30秒です。ALBは時間とLCU（処理量の単位）で課金され、Lambdaの完了まで待つ代わりに本文は1MBまでしか渡せません。本記事では、タイムアウト・ペイロード・東京リージョンの料金・認証とWAFの違いを比較したうえで、ALBにLambdaを登録するCLI手順と、API GatewayからVPCリンクV2で内部ALBへつなぐ構成をコード付きでまとめました。APIゲートウェイという仕組みそのものは[APIゲートウェイとは？役割・機能とリバースプロキシ／サービスメッシュとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13210/)で扱っています。仕様と単価は2026年10月時点の公式情報で確認した値です。

## まとめ：API管理が要るならAPI Gateway、量と長い処理ならALB

外部に公開するAPIで、利用者ごとのスロットリングやAPIキー、リクエスト検証が要るならAPI Gatewayを選びます。月に数百万リクエスト程度までなら、API Gatewayの方が安く済むことが多い価格帯です。ALBの固定費は東京で月約18ドルあり、リクエストが少ないうちは割高になります。

ALBが勝つのは、トラフィックが多い、29秒を超える処理がある、ECSやEC2に既にALBがある、のいずれかに当てはまる場面です。ただしLambdaに渡せる本文は1MBで、APIキーやスロットリングの機能はありません。両方の長所が欲しいときは、API Gatewayを入口にしてVPCリンクV2で内部ALBへ流す構成が、2025年11月からNLBなしで組めるようになりました。

## API GatewayとALBの役割の違い｜APIを管理する機能と負荷分散の守備範囲

API GatewayはAPIの公開と管理のためのサービスで、ALBはHTTPリクエストを複数のターゲットへ振り分けるロードバランサーです。入口として重なる部分はありますが、得意な仕事が違います。ALB単体の仕組みやリスナールールの書き方は[Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説](https://www.issoh.co.jp/column/details/2893/)で解説しています。

### タイムアウト・ペイロード・認証・WAF・料金の主要7項目の比較表

Lambdaを後ろに置く前提で、判断に効く項目を並べました。API GatewayはREST APIとHTTP APIで値が違うため分けています。

| 項目           | REST API        | HTTP API        | ALB            |
| ------------ | --------------- | --------------- | -------------- |
| 統合タイムアウト     | 29秒（申請で延長可）     | 30秒             | Lambdaの完了まで    |
| Lambdaへの本文   | 6MBまで           | 6MBまで           | 1MBまで          |
| 課金の単位        | リクエスト数          | リクエスト数          | 時間とLCU         |
| AWS WAF      | 対応              | 非対応             | 対応             |
| JWTの検証       | オーソライザー         | JWTオーソライザー      | jwt-validation |
| APIキーと使用量プラン | あり              | なし              | なし             |
| WebSocket    | 別のWebSocket API | 別のWebSocket API | EC2・ECSのみ      |

HTTP APIが[AWS WAFの関連付け先](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-associating-aws-resource.html)に含まれていない点は見落とされがちです。WAFが必須の要件でHTTP APIを選ぶと、前にCloudFrontを置いてそちらにWeb ACLを付けることになります。REST APIへのWAFの付け方は[API GatewayにAWS WAFを関連付ける手順](https://www.issoh.co.jp/tech/details/18481/)にまとめました。

### Lambdaの前段で変わるイベント形式とターゲットグループ1つに関数1つの制約

同じLambdaでも、前段がAPI GatewayかALBかで受け取るイベントの形が変わります。ALBのイベントは`requestContext.elb`にターゲットグループのARNが入り、`httpMethod`・`path`・`queryStringParameters`が並ぶ単純な形です。応答には`statusCode`・`headers`・`isBase64Encoded`を必ず含めます。

[ALBのLambdaターゲットの解説](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)には、ターゲットグループ1つに登録できる関数は1つまで、という制約もあります。API Gatewayのように1つのAPIで何十本ものルートを別々の関数へ振る設計をALBでやると、関数の数だけターゲットグループとリスナールールが増えます。[ALBのクォータ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)ではルールが既定100本までなので、ルートの多いAPIは1つの関数の中でルーティングする形に寄せるのが現実的です。

## タイムアウトとペイロード上限の違い｜API Gatewayの29秒とALBの1MB

前段の選択を最も左右するのは、待てる時間と渡せる大きさです。ここでは2つの上限を公式の値で比べます。

### API Gateway：29秒・30秒とALB：Lambda完了・アイドル60秒

[REST APIのクォータ表](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-execution-service-limits-table.html)では統合タイムアウトが50ミリ秒から29秒、[HTTP APIのクォータ表](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-quotas.html)では最大30秒で、HTTP APIは引き上げられません。ALBの場合、ターゲットがLambdaなら関数が応答するかタイムアウトするまで待ちます。Lambdaは最大900秒まで動けるため、1分かかる帳票生成もALB経由ならそのまま返せます。

ターゲットがEC2やECSのときは、[ALBの属性](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html)にあるアイドルタイムアウト（既定60秒・1〜4000秒）が効きます。データが流れない時間がこの値を超えると接続が切れるので、長い処理では値を延ばしておきます。

```
# ALBのアイドルタイムアウトを120秒に延ばす（EC2・ECSターゲット向け）
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/api-alb/50dc6c495c0c9188 \
  --attributes "Key=idle_timeout.timeout_seconds,Value=120"

# Lambdaターゲットでは関数側のタイムアウトが待ち時間の上限になる
aws lambda update-function-configuration \
  --function-name report-export --timeout 120
```

API Gatewayの29秒を引き上げる申請やストリーミングでの回避は[API Gatewayのタイムアウト：29秒の上限を引き上げる手順と504の切り分け](https://www.issoh.co.jp/tech/details/18479/)で扱っています。ALBへ移すのは、引き上げが使えないHTTP APIやedge-optimizedのAPIで長い処理を抱えたときの選択肢です。

### ALBからLambdaへは1MB、API Gateway経由は6MBで頭打ちになる理由

ALBのLambdaターゲットの解説では、Lambdaへ送れるリクエスト本文も、Lambdaが返せる応答のJSONも1MBが上限です。API Gatewayのペイロード上限はRESTとHTTPのどちらも10MBですが、Lambdaと組み合わせると[Lambdaのクォータ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)にある同期呼び出しの6MBで頭打ちになります。

画像やCSVのアップロードを受けるAPIでは、この差がそのまま設計に響きます。ALBで1MBを超えるファイルを扱うなら、S3の署名付きURLを返してクライアントから直接アップロードさせる形が必須です。バイナリの応答はBase64で符号化して`isBase64Encoded`をtrueにするため、実データは1MBの約4分の3まで減ります。

## API GatewayとALBの料金比較｜東京リージョンの単価と損益分岐の試算

課金の形が違うので、単価を並べても高い安いは決まりません。月間リクエスト数を置いて試算すると、どこで逆転するかが見えます。

### リクエスト課金と時間＋LCU課金の東京単価（2026年10月時点）

東京リージョンの単価は、認証不要で引けるPrice List APIのオファーファイルから取得しました。読者向けの料金表は[Elastic Load Balancingの料金](https://aws.amazon.com/jp/elasticloadbalancing/pricing/)と[API Gatewayの料金](https://aws.amazon.com/jp/api-gateway/pricing/)のページにあります。

| サービス     | 課金単位      | 東京の単価           |
| -------- | --------- | --------------- |
| REST API | 100万リクエスト | 4.25ドル（3.33億まで） |
| HTTP API | 100万リクエスト | 1.29ドル（3億まで）    |
| ALB本体    | 1時間       | 0.0243ドル        |
| ALBのLCU  | 1LCU・1時間  | 0.008ドル         |

LCUは4つの次元のうち最も多く使ったもので数えます。Lambdaがターゲットの場合、処理バイトは1時間0.4GBで1LCUです（EC2やコンテナは1GB）。ほかに新規接続が毎秒25、ルール評価が毎秒1,000で1LCUとなり、ルールが10本以下なら評価の次元は計算に入りません。API Gatewayの段階単価や付帯課金の内訳は[API Gatewayの料金を東京リージョンの実額で計算する](https://www.issoh.co.jp/tech/details/18477/)で整理しています。

### 月間リクエスト数別の試算とREST・HTTP APIがALBより高くなる境目

1リクエストの応答を平均10KB、ルール10本以下、ALBは1台を730時間動かす条件で月額を試算しました。Lambdaの実行料金はどちらでも同じなので除き、データ転送料も含めていません。

| 月間リクエスト | REST API | HTTP API | ALB     |
| ------- | -------- | -------- | ------- |
| 100万    | 4.25ドル   | 1.29ドル   | 約17.9ドル |
| 500万    | 21.25ドル  | 6.45ドル   | 約18.7ドル |
| 1,000万  | 42.50ドル  | 12.90ドル  | 約19.7ドル |
| 5,000万  | 212.50ドル | 64.50ドル  | 約27.7ドル |

ALBの固定費は0.0243ドル×730時間で約17.7ドルです。この条件ではLCUが100万リクエストあたり約0.2ドルずつ増えるため、REST APIは月約440万リクエスト、HTTP APIは約1,630万リクエストを超えたあたりでALBより高くなります。応答が大きいAPIほどLCUが早く増え、境目は後ろへずれます。開発環境やステージングのように呼び出しが少ない環境では、固定費の無いAPI Gatewayの方が安い計算です。

## 認証・WAF・スロットリングの違い｜ALBのJWT検証とAPI Gatewayの管理機能

ALBにも認証の機能はありますが、想定している呼び出し元がAPI Gatewayとは違います。ここを取り違えると、移行後にAPIクライアントが動かなくなります。

### ALBのOIDC認証と2025年11月追加のjwt-validationの用途

[ALBのユーザー認証](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html)（`authenticate-oidc`と`authenticate-cognito`）は、未ログインのリクエストをIdPのログイン画面へリダイレクトし、セッションCookieで状態を保ちます。人がブラウザで開く社内システムには向きますが、トークンをヘッダーで送ってくるAPIクライアントには合いません。HTTPSリスナーでしか使えない点も前提です。Cognitoと組み合わせる具体的な設定手順は「[ALBとCognitoで認証を後付けする手順](https://www.issoh.co.jp/tech/details/18501/)」にまとめています。

M2MのAPIクライアント向けには、[2025年11月に発表されたJWT検証](https://aws.amazon.com/jp/about-aws/whats-new/2025/11/application-load-balancer-jwt-verification/)を使います。[JWT検証の解説](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-verify-jwt.html)によると、ALBは署名と`iss`・`exp`を必ず確かめ、追加のクレームを10個まで検証できます。リスナールールのアクションは次の形です。

```
[
  {
    "Type": "jwt-validation",
    "JwtValidationConfig": {
      "JwksEndpoint": "https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_EXAMPLE/.well-known/jwks.json",
      "Issuer": "https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_EXAMPLE",
      "AdditionalClaims": [
        { "Format": "space-separated-values", "Name": "scope", "Values": ["orders/read"] }
      ]
    },
    "Order": 1
  },
  {
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/orders-fn/6d0ecf831eec9f09",
    "Order": 2
  }
]
```

署名アルゴリズムはRS256だけが対象で、JWKSの応答は150KB・鍵10個までという制限があります。IdPの鍵の数がこれを超えると、ALBはリクエストをターゲットへ転送しません。CognitoのアクセストークンはRS256なので、そのまま検証にかけられます。

### 使用量プラン・APIキー・リクエスト検証が要るならAPI Gatewayが残る

ALBに無いのは、利用者単位で流量を管理する機能です。API GatewayのREST APIには、APIキーごとに毎秒のリクエスト数や月の上限を決める使用量プラン、JSONスキーマでのリクエスト検証、応答のキャッシュがあります。取引先ごとに呼び出し回数を契約で分けるようなAPIでは、ALBに移すとこれらをLambda側で作り直すことになります。

認証方式の幅も違います。API GatewayにはCognitoオーソライザー、JWTオーソライザー、Lambdaオーソライザー、IAM認可があり、署名付きのIAM認証でサービス間の呼び出しを守れます。ALBにIAM認可はありません。各方式の設定例は[API Gatewayの認証：Cognito・JWT・Lambdaオーソライザー・IAM認可の使い分け](https://www.issoh.co.jp/tech/details/18493/)で比べています。

## ALBをLambdaの前段に置く設定手順｜ターゲットグループ作成から権限付与まで

ALBにLambdaをつなぐ作業は、ターゲットグループの作成、呼び出し権限の付与、関数の登録、リスナールールの追加の4段階です。コンソールでは権限が自動で付きますが、CLIやIaCでは自分で付けます。

### Lambda登録CLI：ターゲットグループ作成と呼び出し権限の設定

ALBのLambdaターゲットの解説にある手順を、東京リージョンの値で通した例です。ターゲットグループの作成にはcreate-target-group、呼び出し権限の設定にはadd-permissionを使います。ARNとIDは自分の環境の値に置き換えてください。

```
# 1) Lambda用のターゲットグループを作る
aws elbv2 create-target-group --name orders-fn --target-type lambda

# 2) このターゲットグループからの呼び出しだけを許可する
aws lambda add-permission \
  --function-name arn:aws:lambda:ap-northeast-1:123456789012:function:orders:live \
  --statement-id alb-orders \
  --principal elasticloadbalancing.amazonaws.com \
  --action lambda:InvokeFunction \
  --source-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/orders-fn/6d0ecf831eec9f09 \
  --source-account 123456789012

# 3) 関数（エイリアス付きARN）を登録する
aws elbv2 register-targets \
  --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/orders-fn/6d0ecf831eec9f09 \
  --targets Id=arn:aws:lambda:ap-northeast-1:123456789012:function:orders:live

# 4) /orders 配下をこのターゲットグループへ転送する
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/api-alb/50dc6c495c0c9188/0467ef3c8400ae65 \
  --priority 10 \
  --conditions Field=path-pattern,Values="/orders/*" \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/orders-fn/6d0ecf831eec9f09
```

手順2の`--source-arn`と`--source-account`は、公式が「混乱した代理」問題への対策として推奨している条件です。手順3でエイリアス付きのARNを登録しておくと、関数を更新してもエイリアスの向き先を変えるだけで切り替えられます。Lambdaターゲットのヘルスチェックは既定で無効で、有効にすると呼び出しごとにLambdaの料金がかかります。

### ALBとAPI Gatewayの両方から呼べるPythonハンドラーの書き方

前段を移行する期間は、同じ関数をAPI GatewayとALBの両方から呼ぶ場面があります。イベントの形を見分けて、メソッドとパスを取り出す部分だけを分岐させると、本体の処理は共通にできます。

```
import json


def lambda_handler(event, context):
    # ALBからの呼び出しは requestContext に elb キーを持つ
    from_alb = "elb" in event.get("requestContext", {})
    headers = event.get("headers") or {}

    # ALBのヘルスチェックはUser-Agentで見分けて即座に返す
    if from_alb and headers.get("user-agent", "").startswith("ELB-HealthChecker"):
        return build_response(200, {"status": "ok"}, from_alb)

    # REST APIとALBは httpMethod/path、HTTP API（ペイロード2.0）は rawPath を使う
    method = event.get("httpMethod") or event["requestContext"]["http"]["method"]
    path = event.get("path") or event.get("rawPath")

    if method == "GET" and path.startswith("/orders"):
        return build_response(200, {"orders": []}, from_alb)
    return build_response(404, {"message": "not found"}, from_alb)


def build_response(status, payload, from_alb):
    response = {
        "statusCode": status,
        "headers": {"Content-Type": "application/json"},
        "isBase64Encoded": False,
        "body": json.dumps(payload),
    }
    # statusDescription はALB向けの項目なので、ALB経由のときだけ付ける
    if from_alb:
        response["statusDescription"] = f"{status} {'OK' if status == 200 else 'Error'}"
    return response
```

ALBは既定では同じ名前のヘッダーやクエリパラメータが複数あると最後の値だけを渡します。Cookieを複数受け取るアプリでは、ターゲットグループの属性`lambda.multi_value_headers.enabled`をtrueにし、`multiValueHeaders`を読む形に変えます。クエリ文字列はURLエンコードされたまま届くため、関数側でデコードが必要です。

## API GatewayとALBを組み合わせる構成｜VPCリンクV2で内部ALBへ直結する

二者択一にせず、入口のAPI管理はAPI Gateway、後ろのECSへの振り分けは内部ALBに任せる構成もあります。2025年11月の機能追加で、この形がREST APIでも組みやすくなりました。

### REST APIもNLBを挟まずALBへつながるようになった2025年11月の変更

以前のREST APIはVPCリンクの接続先がNLBに限られ、内部ALBへ流すには間にNLBを1台挟む必要がありました。[2025年11月21日のAWS Compute Blog](https://aws.amazon.com/jp/blogs/compute/build-scalable-rest-apis-using-amazon-api-gateway-private-integration-with-application-load-balancer/)で、REST APIがVPCリンクV2を通じてALBへ直接つながるようになったと案内されています。[REST APIのプライベート統合の解説](https://docs.aws.amazon.com/apigateway/latest/developerguide/private-integration.html)では、従来のVPCリンクV1はレガシー扱いで、新規作成は推奨されていません。

```
# 1) VPCリンクV2を作る（REST APIでもapigatewayv2側のコマンドで作成する）
aws apigatewayv2 create-vpc-link --name orders-link \
  --subnet-ids subnet-0a1b2c3d subnet-4e5f6a7b \
  --security-group-ids sg-0123456789abcdef0

# 2) REST APIのメソッドに、内部ALBを指すHTTPプロキシ統合を設定する
aws apigateway put-integration \
  --rest-api-id a1b2c3d4e5 --resource-id a1b2c3 --http-method ANY \
  --type HTTP_PROXY --integration-http-method ANY \
  --connection-type VPC_LINK --connection-id abc123 \
  --integration-target arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/internal-alb/50dc6c495c0c9188 \
  --uri http://internal-alb.example.internal/orders

aws apigateway create-deployment --rest-api-id a1b2c3d4e5 --stage-name prod
```

NLBが不要になった分、NLBの時間料金とNLCUの料金がなくなります。1つのVPCリンクで複数のALBにつなげるので、注文と決済のようにサービスごとにALBを分けている構成でも、リンクは1本で足ります。

### HTTP APIはリスナーARNを指定し、ステージ名がパスに付く点に注意する

HTTP APIは以前からVPCリンクV2でALBにつながります。[HTTP APIのプライベート統合の解説](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-private.html)では、`create-integration`の`--integration-uri`にALBそのものではなくリスナーのARNを渡します。RESTはロードバランサーのARN、HTTPはリスナーのARNと、指定する対象が違う点で迷いやすいところです。

どちらの方式でも、ロードバランサー・VPCリンク・APIは同じアカウントに置く必要があります。また、プライベート統合では呼び出したステージ名がバックエンドへのパスの先頭に付き、`prod`ステージなら`prod/orders`のように届きます。ALBのリスナールールが`/orders/*`だと一致しないため、パラメータマッピングでパスを書き換えるか、ルール側にステージ名を含めてください。

## Lambda・ECSの前段の選び方｜API Gatewayを選ぶ条件とALBを選ぶ条件

ここまでの比較を、採用の判断に落とします。迷ったら、API管理の機能が要るかどうかを先に決めると、残りの条件で自然に絞れます。

### 外部公開API・月数百万リクエスト以下・利用者別の制限ならAPI Gateway

取引先やスマートフォンアプリに公開するAPIは、API Gatewayを選びます。APIキーと使用量プランで相手ごとの上限を決められ、WAFもREST APIなら直接関連付けが可能です。月の呼び出しが数百万回までならALBの固定費より安く、開発・検証・本番とステージを分けても費用が増えにくい点も効きます。

REST APIとHTTP APIのどちらにするかは、使用量プランとWAFが要るかで決めます。どちらも要らず、JWTの検証だけで足りるならHTTP APIの方が単価は約3分の1です。

### 常時高負荷・29秒超の処理・既存のECSはALB、1MB超の本文では見送る

ALBを選ぶのは、月に数千万リクエストを常時受ける社内APIや、1分前後かかる処理をHTTP APIで抱えている場合です。ECSやEC2に既にALBがあり、そこへLambdaの処理を数本足すだけなら、別にAPI Gatewayを立てる理由はありません。ブラウザで使う社内システムなら、ALBのOIDC認証でログイン画面までまとめて任せられます。

次の場面ではALBを前段にしません。Lambdaで1MBを超える本文を直接受け渡すAPI、利用者ごとに流量を分けたいAPI、WebSocketをLambdaで処理したいAPIです。ALBのLambdaターゲットはWebSocketのアップグレード要求を400で拒否するため、この用途ではAPI GatewayのWebSocket APIを使います。前段の構成をECSやLambdaの設計と合わせて見直したい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)のページで支援内容を紹介しています。

## API GatewayとALBの違いについてよくある質問と回答

API GatewayとALBの選定や移行の際によく出る質問に答えます。

### API GatewayとALBはどちらが安いですか？

リクエスト数で変わります。東京リージョンでは、ALBは1台で月約17.7ドルの固定費にLCUの料金が加わり、REST APIは100万リクエストあたり4.25ドル、HTTP APIは1.29ドルです。応答10KBの条件で試算すると、REST APIは月約440万、HTTP APIは約1,630万リクエストを超えるとALBより高くなります。単価は2026年10月時点の値です。

### ALBの後ろにLambdaを置くと29秒の制限はなくなりますか？

なくなります。ALBはターゲットのLambdaが応答するかタイムアウトするまで待つため、待ち時間の上限はLambdaのタイムアウト（最大900秒）です。ただしALBからLambdaへ渡せる本文と応答はそれぞれ1MBまでで、前にCloudFrontを置く場合はCloudFront側のオリジンタイムアウトにも合わせる必要があります。

### API GatewayからALBへ直接つなげますか？

つなげます。HTTP APIは以前からVPCリンクV2で内部ALBに接続でき、REST APIも2025年11月からVPCリンクV2でNLBを挟まずにALBへつなげるようになりました。ALBをインターネットに公開せずに済み、API Gatewayの認証やスロットリングを入口に残せます。API・VPCリンク・ALBは同じAWSアカウントに置きます。

### ALBでAPIキー認証はできますか？

API Gatewayのような管理されたAPIキーと使用量プランの機能はALBにありません。リスナールールでヘッダーの値を条件にして簡易的に弾くことはできますが、キーの発行や回数制限は自前で作ることになります。APIクライアントの認証には、2025年11月に追加されたJWT検証（jwt-validation）を使うのが現実的です。

### HTTP APIとALBはどう使い分けますか？

WAFが要るかと、リクエスト数で決めます。HTTP APIはAWS WAFを直接関連付けられないため、WAFが必須ならALBかREST APIを選びます。WAFが不要で月1,000万リクエスト程度までならHTTP APIの方が安く、固定費もかかりません。トラフィックが常時多い場合や、ECSと同じALBにまとめたい場合はALBが向いています。

## 関連記事

- [APIゲートウェイとは？役割・機能とリバースプロキシ／サービスメッシュとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13210/)：API GatewayとALBの役割の違いの前提になるAPIゲートウェイの考え方。
- [Elastic Load Balancingとは？ELBとALBの違い・4種類の使い分けと料金・設定を解説](https://www.issoh.co.jp/column/details/2893/)：ALBのリスナールールやLCUの仕組みを詳しく確認できる記事。
- [API Gatewayのタイムアウト：29秒の上限を引き上げる手順と504の切り分け・非同期化](https://www.issoh.co.jp/tech/details/18479/)：ALBへ移さずに29秒の制限を回避する方法。
- [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15407/)：前段の後ろで動くLambdaの仕組みと上限。
- [ELBヘルスチェックの設定と失敗原因の調べ方｜ALB・NLBの既定値と理由コード](https://www.issoh.co.jp/tech/details/18067/)：ALBのターゲットが不健全になったときの調べ方。

---

出典: [API GatewayとALBの違い：Lambda・ECSの前段をタイムアウト・料金・認証で選ぶ](<https://www.issoh.co.jp/tech/details/18499/>)（株式会社一創）