Amazon API GatewayとAWS Lambdaを利用したサーバレスAPI基盤構築 ~利用者認可・リクエストレート制限の実装ポイントを紹介~

 こんにちは、大和総研 CCoEの林です。

 大和総研ではクラウドを通じてお客様に価値を提供すべく、2021年度よりパブリッククラウドの推進組織(CCoE: Cloud Center of Excellence)を設置し、クラウド活用を推進しています。

 私は、主に金融機関向けシステムのアプリケーション開発を担当していますが、現在は、パブリッククラウドを活用した事業会社向けのシステム構築に携わっています。担当プロジェクト内で、オンプレミス環境で構築されていたAPI基盤の一部をAmazon Web Services(以下、AWS)に移行し、Amazon API GatewayとAWS Lambdaを利用して新たなAPI基盤を構築しました。API GatewayとLambda Authorizerを組み合わせて、利用者認可やリクエストレート制限の仕組みを実装しましたので、サーバレスを活用したシステム開発を検討されている方向けに、こちらの実装ポイントを中心に紹介します。

Amazon API Gatewayとは

 AWS上で、APIを簡単に作成・公開・管理できるフルマネージドサービスです。Amazon API Gatewayで利用できる機能の概要を紹介します。

  • REST/WebSocket APIの公開
  • 認証・認可の設定(IAM/Cognito/Lambda Authorizerとの連携)
  • LambdaやEC2などのバックエンドサーバとの接続
  • アクセス制御・レート制限(スロットリング)
  • APIのライフサイクル管理

Lambdaと組み合わせて利用することで、サーバレスなAPI公開が実現できます。

Amazon API Gateway | API の管理 | アマゾン ウェブ サービス

AWS Lambdaとは

 AWS上で、サーバを用意せずにアプリケーションコードを実行できるサーバレスな実行環境です。AWS Lambdaの特徴を簡単に紹介します。

  • サーバ管理が不要
  • イベント駆動型で必要な時だけ実行
  • 実行時間/リクエスト数に対して従量課金
  • リクエスト負荷に応じた自動スケーリング
  • Amazon API Gateway や Amazon S3、Amazon DynamoDB、Amazon EventBridgeなどの他サービスと簡単に連携

一言でまとめると、コードを書くだけで、自動でスケールする処理を実行可能なサービスです。

サーバーレスコンピューティング - AWS Lambda - Amazon Web Services

構築したAPI基盤の概要

 今回構築したAPI基盤のポイントは以下の通りです。

  • APIをインターネット上に公開し、提携先企業から利用可能とすること
  • 社外からのリクエストを受けるため、セキュリティを担保すること
  • API利用時には認可を行うこと
  • API利用者単位で流量制限(レート制限によるアクセスコントロール)が可能なこと
  • オンプレミス環境上のシステムでAPIリクエストを受け取り処理するため、オンプレミス環境へ接続すること


 これらのポイントを踏まえて、以下の構成図に示すようなAPI基盤を構築しました。
 (※一部、説明に不要なサービスを削除しています。)

図 1 API基盤の構成概要図(出所:大和総研作成)

  • インターネットからのアクセスはAmazon CloudFrontで受け付け、Amazon API Gatewayのエンドポイントをオリジンに指定しています。Amazon CloudFrontにはWAFをアタッチしており、リクエスト元の制御を行っています。
  • Amazon API GatewayとAWS Lambdaを連携し、認可にはLambda Authorizerを利用しています。
  • Amazon API GatewayとLambda Authorizerを組み合わせて、リクエストレートの制限も行っています。
  • 認可が済んだリクエストは、Network Load BalancerとApplication Load Balancerを通過した後、Gateway Load BalancerのEndpoint経由で、セキュリティアカウント上に用意されているセキュリティチェック機構に送信されます。
  • セキュリティのチェックが完了したリクエストは、専用線を通じてオンプレミス環境上の各社内システムに送信されます。社内システムにて処理が実行された後、APIのレスポンスが返却されます。
  • 各種AWSサービス上のログはAmazon CloudWatchに保管しています。ログの長期保管用にはAmazon Kinesis Data Firehoseを利用してAmazon S3にバックアップを転送しています。


 以降に、本API基盤を構築した際の主な実装ポイントを3点ご紹介します。

【ポイント①】アクセス元のIPアドレス・リクエストURLチェック

 本構成ではAmazon CloudFrontを利用してインターネット経由で社外からのリクエストを受け付けていますが、利用契約を結んでいる企業からのリクエストのみ許可する必要があります。そこで、Amazon CloudFrontにAWS WAFをアタッチし、WAFの機能を利用してリクエストのチェックを2点行うようにしました。

 1つ目は、AWS WAF上で「IPアドレスセット」を設定し、リクエストの送信元IPアドレスによるフィルターを実装し、許可対象のIPアドレス以外からのリクエストを拒否しています。

図 2 AWS WAFのIPアドレスセット画面(出所:AWSマネジメントコンソール画面)

 2つ目は、AWS WAF上で「正規表現パターンセット」を設定し、リクエストURL内のパスに正規表現パターンセットに設定された内容と一致する場合のみ、リクエストを許可するように設定しています。

図 3 AWS WAFの正規表現パターンセット画面(出所:AWSマネジメントコンソール画面)

【ポイント②】API利用者の認可機能

 本構成では、Amazon API GatewayにLambda Authorizerを利用してAPI利用に対する認可を実行しています。Amazon API Gatewayの設定メニューに「オーソライザー」の項目があり、事前に構築したLambda関数を設定しています。

図 4 オーソライザーの設定画面(出所:AWSマネジメントコンソール画面)
 今回は、既存のAPIインターフェースを変更せずに認可を実現する必要がありました。そのため、従来のオンプレミス環境のAPI基盤を利用していたAPIのリクエストパラメータ名・値を引き続き利用できるよう、Lambda関数を実装しています。

 認可に利用するため、各社向けに払い出したクライアントID・クライアントシークレット値は、AWS Systems Manager上のParameter Storeの機能を利用して保管しています。Lambda関数は、APIのリクエストパラメータに指定されたクライアントID・クライアントシークレット値を取得し、Parameter Store上の値と一致しているかをチェックしています。

図 5 Lambda AuthorizerによるID/シークレットチェック(出所:大和総研作成)

【ポイント③】利用者単位のリクエストレート制限

 API利用を制限しない場合、大量のリクエスト送信により、予期せぬ費用が発生したり、スケーリング上限に達してシステムが正常に稼働できなくなったりする可能性があります。これらを防ぐために、APIの利用者単位でのリクエストレート制限を実装しています。

 今回は、Amazon API Gatewayの機能である「使用量プラン」と「APIキー」を利用してリクエストレート制限を実現しています。

 まず、使用量プランのメニューからプランの作成を行います。使用量プランの設定では「スロットリング」と「クォータ」の2つの設定ができます。スロットリングには、さらに「レート」と「バースト」の2つの設定があり、レートは、1秒あたりに許可される平均リクエスト数、バーストは瞬間的(数百ミリ秒~1秒)に許可される最大リクエスト数の設定です。クォータは、期間(1ヵ月、1週間、1日)あたりに利用者が実行できるリクエストの総数が設定できます。今回はレートの制限のみを利用しています。

図 6 使用量プラン一覧画面(出所:AWSマネジメントコンソール画面)
図 7 使用量プラン設定画面(出所:AWSマネジメントコンソール画面)

 次に、利用者単位(今回は利用会社単位)のAPIキーを発行します。発行後、APIキーの詳細画面から使用量プランとの紐付けを行います。

図 8 APIキー一覧画面(出所:AWSマネジメントコンソール画面)
図 9 APIキー詳細画面(出所:AWSマネジメントコンソール画面)
図 10 使用量プランの追加画面(出所:AWSマネジメントコンソール画面)

 次に、使用量プランによる制限を適用したいAPIのメソッドに対して、Amazon API Gatewayのメソッドリクエストの編集画面から、「APIキー必須化」の設定を行います。

図 11 メソッドリクエストの編集画面(出所:AWSマネジメントコンソール画面)

 最後に、再び適用したい使用量プランの詳細画面に遷移し、「ステージを追加」のメニューから、使用量プランを紐付けるAmazon API GatewayのAPI・ステージを選択して設定完了です。(※今回は最後にステージの追加を行いましたが、事前に設定しても問題ありません。)

図 12 使用料プランとステージの関連付け画面(出所:AWSマネジメントコンソール画面)

 以上の設定により、APIリクエストのヘッダに「x-api-key」というパラメータ名で、利用者ごとに払い出されたAPIキーを設定してリクエストを送信することで、作成した使用量プランに基づくリクエスト制限が実行されます。

 ただし、今回は「既存APIのインターフェースを変更しない」という制約があり、リクエストへ新たな項目「x-api-key」を設定できませんでした。そこで、こちらを解消するためにも、Lambda Authorizerを活用しています。

 各社向けに払い出しているクライアントIDと、新規発行したAPIキー情報の紐付けは、別途Lambda Authorizerが利用する設定ファイル上に保持しています。そのため、Lambda AuthorizerはAPIリクエストを受けた際に、クライアントIDの値からAPIキーを検索して取得します。取得したAPIキーを、Lambda Authorizer内でポリシーステートメントに設定して返却することで、APIリクエストのリクエストレート制御を実現しています。ここが今回工夫したポイントです。

おわりに

 本記事では、Amazon API GatewayとAWS Lambdaを利用して実現したAPI基盤の構成事例と、構築時のポイントを紹介しました。今回のような構成を取ることでサーバ・OSの管理を行わずに済み、インフラ運用コストを軽減できるメリットがあります。また、自動スケーリングによりキャパシティプランニングの検討が不要になるといったメリットも存在します。運用負荷軽減・コスト最適化を視野に入れた、サーバレスでAPIを提供したいと考えている方々の一助になれば幸いです。

 大和総研では、金融機関や事業会社のお客様へクラウドを導入・運用してきた実績を活かし、お客様のクラウドインフラの構築・移行などをサポートします。ご要望・ご不明点などがありましたら、ITソリューションサービスサイトよりお問い合わせください。

 ※Amazon Web Services、Amazon API Gateway、AWS Lambda、Amazon CloudFront、AWS WAF、Amazon S3等は、米国および/またはその他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。