AWS Lambda Function URLsとAmazon API Gatewayの違い

summary

AWS Lambdaを使ってREST APIを実装する場合、以前はAmazon API GatewayがAPIを構築するサービスとしてほぼ一択の選択肢でしたが、AWS Lambda Function URLsがリリースされてからはこちらもケース次第で選ばれるようになりました。本記事ではそれぞれのサービスの違いと適切なユースケースを解説した上で、選定におけるポイントを述べています。

AWS Lambda Function URLsとAmazon API Gatewayの機能比較

AWS Lambda Function URLsは、2022年にAWSがリリースした機能で、LambdaファンクションにHTTPリクエスト用の受け口を追加する機能です。従来はAmazon API Gatewayを使ってHTTPリクエストを受け取っていましたが、AWS Lambda Function URLsを使うことでより簡単にAPIを公開できるようになりました。

まずは以下に、AWS Lambda Function URLsとAmazon API Gatewayの主要な機能を比較した表をまとめました。端的に言うとAWS Lambda Function URLsは低レイテンシーかつ低コスト、簡単な設定のみでAPIを公開できる代わりにAmazon API Gatewayと比較すると制約が多く、柔軟な設定が出来ないデメリットがあるということになります。

まずは自分の公開したいAPIの仕様がAWS Lambda Function URLsで満たせるならAWS Lambda Function URLsを採用して、難しければAmazon API Gatewayを使うアプローチが良いでしょう。

機能/特性	AWS Lambda Function URLs	Amazon API Gateway
コスト	API Gatewayの追加コストなし、低コスト	使用量に応じた追加コスト（リクエスト数やトラフィックに依存）
設定の簡単さ	簡単（Lambda関数にURLを割り当てるだけ）	詳細な設定可能（高度な機能をサポート）
認証方法	AWS_IAM認証のみ対応	AWS_IAM、Cognito、カスタムLambdaオーソライザーなど対応
レスポンス制限	最大15分間の実行時間	最大29秒の実行時間、10MBのレスポンスサイズ制限
レスポンスストリーミング	対応	非対応
レイテンシ	追加のレイテンシは発生しない	追加のレイテンシーオーバーヘッドあり
メトリクス	エンドポイント単位のメトリクスはなし	詳細なメトリクス（リクエスト数、レイテンシー、エラー率など）
エンドポイントごとの設定	単一のLambda関数で全エンドポイントを管理	エンドポイントごとに異なる設定（メソッド、認証など）可能
統合可能なサービス	Lambda関数のみ	Lambda、S3、DynamoDB、Step Functionsなど多くのAWSサービス
WebSocketサポート	非対応	WebSocket APIをサポート
セキュリティ機能	WAFとの直接統合はなし（CloudFront経由で対応可能）	WAFとの直接統合、CORS設定、スロットリングなど
スロットリング（レート制限）	非対応	API Gateway側でスロットリングとレート制限設定可能
カスタムドメインサポート	非対応	カスタムドメイン名の設定が可能
認証ごとのカスタマイズ	対応不可（すべてのエンドポイントに同じ認証方式が適用）	エンドポイントごとに異なる認証方式を設定可能

LambdalithなアプローチとAWS Lambda Function URLsの相性

最近ではAPIをサーバレスで構築する際のトレンドとして、Lambdalithというアプローチが人気です。これはエンドポイントごとに個別のLambdaファンクションを持つ代わりに、単一のLambdaファンクションでAPI全体を処理するアプローチです。LambdalithではないアプローチではAmazon API Gatewayを使ってリクエストのパスごとに用意されたLambdaファンクションにリクエストをルーティングします。Lambdalithの場合だとすべてのリクエストを単一のLambdaファンクションで受け取って、Lambda内に実装されたルーティングの仕組みを使うことで処理を捌きます。つまり、自ずとAWS Lambda Functions URLsを使用するほうがアーキテクチャ的にもフィットし、コストもレイテンシもAmazon API Gatewayに比べて優れたAPIを提供することが可能になります。

このアプローチの一番のメリットは従来のウェブアプリケーションフレームワーク（を使った構成そのままでAWS Lambdaを動かせることにあるでしょう。通常、AWS Lambdaを動かす場合には以下のようなハンドラでイベントを受け取って処理を記述する必要がありました。少し、そこが従来のウェブアプリケーション開発者からすればとっつきにくい部分だったかもしれません。なぜならWebアプリケーションフレームワークによってリクエストのハンドリング方法は異なるため、イベントのエントリポイントが決まっているLambdaファンクションとの相性は決して良いものとは言えません。

export const handler = async (event, context) => {
  // ここに処理を記述
}

しかし、AWS Lambda Web AdapterというAWSが出しているOSSを使うことで、従来のウェブアプリケーションフレームワーク（Express.js, Next.js, Flask, SpringBoot, ASP.NET and Laravel, anything speaks HTTP 1.1/1.0）を構成そのままでAWS Lambda上で動かすことが出来ます。

このアプローチのより、Amazon EC2のような仮想マシンやAWS Fargateなどのコンテナで動くアプリケーションをそのままAWS Lambdaに移行することが可能になります。既存のアプリケーションを大幅な書き換えなしにAWS Lambdaに移行できるため、既に知っているWebフレームワークや既存のツール、ORM、ミドルウェアのエコシステムを活用することができます。また、テストも簡単になり、従来のテスト方法を適用できるため、非常に便利です。

AWS Lambda Functions URLsとAWS Lambda Web AdapterがこのLambdalithなアプローチを実現するための効率的な手法になります。AWS Lambda Web Adapterの解説についてはDockerを使わない、Remix / Next.js 14 など最新ウェブフレームワークのAWS完全サーバーレス構成と環境構築方法の記事に詳しく書いてますので興味があれば読んでみてください

AWS Lambda Function URLsの機能について

メリット

Lambdalithなアプローチと自然に連携できます。
Amazon API Gatewayの追加のレイテンシーが発生しません。
Amazon API Gatewayの追加コストが発生しません。
レスポンスストリーミングに対応しています。これは大きなペイロードをHTTPレスポンスで返す場合に便利です。
設定項目が少なく簡単。
APIの実行時間は最大で15分です。

デメリット

Lambdalithなアプローチに限定されてしまいます。
エンドポイントごとのメトリクスがありません。ただし、カスタムメトリクスをEMF（埋め込みメトリクス形式）で実装することで対応可能です。
WAFとの直接統合がありません。ただし、CloudFrontを介してこれを実現でき、CloudFront OACを使用してユーザーがCloudFrontのURLを通じてのみAPIにアクセスできるようにすることが可能です
認証方式はAWS_IAM認証のみです。
エンドポイントごとに異なる認証方式を設定することはできません。

適しているユースケース

Amazon API Gatewayのみが提供している機能が不要な場合には、低コストで低レイテンシーなAPIの提供が可能になります。その他に大きなペイロードをレスポンスストリーミングで返す場合やAmazon API Gatewayのリミットである29秒以上の実行時間が必要な場合もAWS Lambda Function URLsを選ぶことになるでしょう。

その他のポイントとしては認証方式になるでしょう。AWS Lambda Function URLsはAWS_IAMの認証方式しかサポートしていません。つまり、一般ユーザ向けに認証認可をつけたAPIを提供する場合にはCogniteオーソライザーやカスタムLambdaオーソライザーが必要になります。Amazon CloudFront + Lambda@Edgeで似たようなことを実装することは可能ですが、それであればAmazon API Gatewayを選んだほうが良いでしょう。

つまり、完全にパブリックなAPIかマイクロサービス内の内部的なAPIがAWS Lambda Function URLsには向いています。

Amazon API Gatewayの機能について

メリット

柔軟性が高いです。Lambdalithなアプローチでも、個別に関数をアタッチしていくアプローチでも両方対応できます。
ほとんどのAWSサービスと直接統合されています。ケースによってはAWS Lambdaを実装すること無くアーキテクチャを組むことが出来ます。
サードパーティAPIとの統合に便利なHTTP APIへのプロキシが可能です。
多くの機能を提供しています。以下はその一部です。
- Cognitoオーソライザー
- ユーザープラン（SAASアプリケーションの階層型価格設定に便利）
- リクエストモデルを使ったリクエストのバリデーション
- エンドポイントごとの詳細なメトリクス
- 静的データを返すモックエンドポイント
- リクエストとレスポンスの変換（サードパーティAPIとの統合に便利）
- WebSocketサポート

デメリット

追加のレイテンシーオーバーヘッドが発生します。
Amazon API Gatewayの追加コストが発生します。
レスポンスストリーミングの機能がありません。
29秒でタイムアウトします。これを引き上げることは可能ですが、AWSサポートの判断次第でどこまであげれるかは不明です。
10MBのレスポンス制限があります。

適しているユースケース

29秒の実行時間の10MBのレスポンス制限が問題となるケースがありますが、Amazon API Gatewayを使うことで発生する追加コストや追加レインシーが許容できる場合はほとんどのAPIのユースケースに適しています。

まとめ

AWS Lambda Function URLsはコストが安く簡易に使えます。また、Lambdalithなアプローチとの相性も非常に良いです。反面、認証の機能は充実していないため、そこが許容できる場合には有効なオプションとなるでしょう。Amazon API GatewayはAWS Lambda Function URLsの弱点でもある認証認可の機能も充実しており、多彩なオプションを提供しています。適用できるユースケースも広く、Amazon API Gatewayを採用することで実装に困るということはあまり無いでしょう。