AWS Lambda Function URLsとAmazon API Gatewayの違い

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を使うアプローチが良いでしょう。

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を採用することで実装に困るということはあまり無いでしょう。