こんにちは、クレスコの北垣です。 

AWS関連ビジネスのコンサルタントやシステムアーキテクト、プロジェクトマネージャーとして業種を問わず幅広く活動しております。今回は、AWS re:Invent 2024で得た知見を基に、生成AI時代のサーバレスAPI構成について解説します。 

目次

  1. 本記事執筆のきっかけ 
  2. ストリーミングレスポンスAPI公開アーキテクチャの主要パターン 
  3. 各アーキテクチャの比較 
  4. 今後の展望 

1. 本記事執筆のきっかけ

AWS re:Invent 2024に初めて現地参加し、生成AIやサーバレスに関連するセッション、AWSソリューションアーキテクトの方との生成AIサービスの統合に関するディスカッションを通じて、ストリーミングレスポンスを実現するサーバレスAPI構成の整理を行ったことがきっかけです。   

 

AWSの生成AIサービス（Amazon Bedrock など）を利用する際、クライアントから直接アクセスすることも可能ですが、より柔軟な統合を目指す場合、ECS (Fargate)やLambdaが有力な選択肢になります。ECSであればALBを利用して公開することが一般的かと思いますが、Lambdaの場合は公開パターンがいくつかあります。 

 

生成AIのユースケースだと特にストリーミングレスポンスを実現することがユーザビリティを向上させるためにも必須の要件になるかと思いますので、今回は「ストリーミングレスポンスを返却するLambda」を公開するという点にフォーカスした主要アーキテクチャについて整理します。 

 

※ 注意　- 本記事の内容は2025年1月7日時点の情報で記載しております。 

２. ストリーミングレスポンスAPI公開アーキテクチャの主要パターン

ストリーミングレスポンスとは、データを一度に送信するのではなく、生成されたデータを順次クライアントに送信する方式です。これにより、ユーザーは処理の進捗をリアルタイムで確認でき、特に生成AIの応答を待つ際のユーザー体験を大幅に向上させることができます。 

 

では、ストリーミングレスポンスを実現するAWSサーバレスAPI構成について、どんなものが考えられるでしょうか？ 主要な構成を以下に示します。（前述の通り、アプリケーションはLambda利用前提です） 

① ～ ④ のそれぞれのパターンについて、解説していきます。 

 

① API Gateway (WebSocket タイプ) 

API GatewayではHTTP、REST、WebSocketの３つのAPIタイプがありますが、ストリーミングレスポンスに対応しているのは WebSocket タイプ のみ です。 

 

特徴： 

  • WebSocketはクライアントとサーバ間で双方向のリアルタイム通信が可能 
  • セキュリティ面では、API Key、IAMポリシー、カスタム認証、およびWAF（Web Application Firewall）との統合が可能 

 

注意点： 

  • 接続のアイドルタイムアウトが30秒のため、長時間の処理には適さない 
  • WebSocketに対応したLambda関数やクライアントの実装が必要 
  • リクエストサイズ32KB、レスポンスサイズ128KBまでの制限があり軽量なデータ通信が推奨される 

 

双方向でのリアルタイム通信が必要なチャットアプリや通知サービスに生成AIを統合するユースケースであれば、本構成が選択肢に入りますが、タイムアウト制限や軽量なデータ通信の注意点を考慮する必要があります。 

 

参考：WebSocket API の設定と実行に関する API Gateway クォータ 

 

② Lambda Function URLs 

Lambda Function URLsは、Lambda関数に直接HTTPエンドポイントを提供するシンプルな構成で、ストリーミングレスポンスにも対応しています。 

 

特徴： 

  • 追加のサービスを必要とせず、シンプルな構成でHTTPリクエストを処理可能 
  • ストリーミングレスポンスをサポートし、データを段階的にクライアントへ送信可能 
  • セットアップが簡単で、コスト効率が高い 
  • リクエストサイズ6MB、レスポンスサイズ20MBまで可能 

 

注意点： 

  • IAM認証 および リソースベースのポリシーを使用したアクセス制限をサポートしているが、クライアントからの直接アクセスにはIP制限やカスタム認証ロジックをLambda内に実装する必要がある 
  • Lambda単体のコストしか掛からないメリットはあるが、DDoS攻撃などを受け意図せず高コストになる可能性もあり、他のアーキテクチャよりもセキュリティリスクが高い 

 

IAM認証やリソースベースポリシーをかけられないユースケースの場合、他のアーキテクチャよりもセキュリティリスクが高いため、小規模かつ短いサイクルで試す場合に利用する形 が望ましいと考えます。 

 

肝心のストリーミングレスポンスですが、以下の３パターンで利用可能です。 

  • Node.js マネージドランタイム 
  • カスタムランタイム 
  • Lambda Web Adapter 

 

参考：Lambda 関数のレスポンスストリーミング 

 

③ ALB ＋ Lambda 

こちらは Lambda Function URLs ではなく、通常のLambdaを利用しALBで公開するパターンです。 

 

特徴： 

  • ストリーミングレスポンスをサポートし、データを段階的にクライアントへ送信可能 
  • WAFやCognitoを統合することで、認証やアクセス制御を強化 

 

注意点： 

  • リクエストサイズ1MB、レスポンスサイズ1MBの制限あり 
  • ALB維持コストが掛かる（月額 約25$ 程度） 

 

レスポンスサイズ制限（1MB）があるため、軽量なレスポンスである制約はあるものの、セキュアな構成で本番運用に適した構成です。 

 

④ Cloudfront + Lambda Function URLs 

② の Lambda Function URLs構成にCloudfrontを前段に配置することで、セキュリティとコスト効率を両立させた構成です。Cloudfrontはストリーミングレスポンスに対応しています。 

 

特徴： 

  • CloudFrontが前段でDDoS攻撃や悪意のあるアクセスを遮断 
  • ストリーミングレスポンスをサポートし、データを段階的にクライアントへ送信可能 
  • WAFやCognito（Lambda@Edgeを使用）を統合することで、認証やアクセス制御を強化 
  • Lambda Function URLsのリソースポリシーを使用してCloudFrontからのアクセスのみを許可可能 
  • 高いセキュリティとコスト効率を両立 
  • リクエストサイズ1MB、レスポンスサイズ20MBまで可能 

 

注意点： 

  • 設定が少し複雑 
  • PUT/POSTリクエストを行う場合にはリクエスト本文のサイズ制限あり 
  • Lambda@Edgeの動作制限を考慮した実装必要 

 

設定方法については、以下リンク先で紹介されていますが、少し複雑なため、ポイントを絞って分かりやすく解説します。 

 

参考：AWS Lambda 関数 URL オリジンへのアクセスを制限する 

(1) Origin Access Control (OAC)の設定 

Lambda Function URLsへのアクセスをCloudFront経由のみに制限する設定です。 

リンク先に記載の通り設定していけば良いのですが、Cloudfrontの設定後にLambda関数の 

アクセス権限を更新する流れとなる点を理解して進めてください。 

(2) x-amz-content-sha256 ヘッダーにペイロードハッシュ値を設定 

ストリーミングレスポンスを実現する際、クライアントからのリクエストは基本POSTメソッドに なるかと思います。リンク先の以下の記述の通り、PUT または POST メソッドの場合は、本対応が必要になってきます。 

注記

Lambda関数URLでPUTメソッドまたはPOSTメソッドを使用する場合、ユーザーはCloudFrontにリクエストを送信するときに x-amz-content-sha256 ヘッダーにペイロードハッシュ値を含める必要があります。Lambdaは、署名されていないペイロードをサポートしていません。

クライアント側で対応可能であれば特に問題ありませんが、サーバ側で対応する場合はLambda@Edge を利用します。ただし、Lambda@Edgeにはリクエスト本文のサイズ制限があるため、注意が必要です。 

 

[ Lambda@Edge リクエスト本文のサイズ制限 ] 

リクエスト本文が大きい場合、CloudFront は、本文を以下のように切り詰めてから Lambda@Edge に公開します。 

 

  • ビューワーリクエストでは、本文が 40 KB で切り捨てられます。 
  • オリジンリクエストでは、本文が 1MB で切り捨てられます。 

オリジンリクエストの方が１MBまで処理可能なため、ビューワーリクエストで処理する必要性が無ければ、オリジンリクエストを選択しましょう。 

参考：[本文を含める] オプションを使用する場合のリクエスト本文に対する制限 

 

若干の設定の複雑さはありますが、コスト効率に優れておりセキュアなアーキテクチャです。 

本番運用ではこのアーキテクチャを推奨します。 

3. 各アーキテクチャの比較

これまで説明した内容をまとめたものがこちらです。 

ストリーミングレスポンスを実現する構成を検討する際に、ユースケースに応じたアーキテクチャ選定の参考になれば幸いです。

4. 今後の展望

現在、開発プロジェクトにおいて利用する生成AIを統合したストリーミングレスポンスAPIを開発しており、コスト、セキュリティ、パフォーマンスの観点から Cloudfront ＋ Lambda Function URLs の構成を採用しました。実際にやってみるとハマった点などもありますので、その内容について次の記事にて詳細にお伝えしていこうと思います。