Amazon API Gatewayは「HTTP API」と「REST API」のどちらを選択すれば良いのか？ #reinvent

Amazon API Gatewayの新機能「HTTP API」

re:Invent 2019期間中、Amazon API Gatewayの新機能「HTTP API」が発表されました。現在プレビューとして、US East (Ohio), US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo), EU (Frankfurt), EU (Ireland)で提供されています。

HTTP APIはREST APIの上位互換というわけではなくAPI Gatewayのコアな機能に特化して低コストで利用したい場合に適した機能という位置付けになっています。つまりREST APIと比較するとできないことがいくつかあります。

本記事では以下のドキュメントをベースに、新しく提供されるHTTP APIがどういう場合に適しているかより掘り下げてみたいと思います。

• Choosing Between HTTP APIs and REST APIs - Amazon API Gateway

本記事はプレビュー版として公開されているドキュメントを参考にした考察です。本リリース時には仕様などが変わる可能性がありますのでご容赦ください。

HTTP APIの特徴

まずHTTP APIの特徴について簡単にまとめます。

低レイテンシ・コスト最適化

REST APIに比べると機能が限られますが、コアな機能のみの提供に絞ることで低レイテンシかつ低コスト（コスト最適化）を実現しています。

HTTP APIが提供する機能がユースケースに合致するかが、HTTP APIを選択する上での特に重要なポイントになります。

AWS LambdaプロキシまたはHTTPプロキシのみ

呼び出し先にはAWS LambdaプロキシまたはHTTPプロキシのいずれかが設定できます。API Gateway + Lambdaの構成を作りたい場合は問題ありませんが、例えば他のAWSサービスとダイレクトに連携するなどといったことはできないので注意が必要です。

OpenID ConnectとOAuth 2.0をサポート

下記で解説させていただいた通り、OpenID ConnectおよびOAuth 2.0の規格に準拠する形でのJWTでの認証のみをサポートします。

認証基盤にCognito User Poolsを利用する場合、User PoolsをOIDC Providerとして連携することができます。

自動デプロイですぐに利用開始が可能

REST APIで煩雑だったStageの用意が自身で用意しなくても、API作成時に自動で作成されるようになります。例えばREST APIでは Prod といったStageを用意していたかと思います。

https://{api_id}.execute-api.{region}.amazonaws.com/Prod/

これがHTTP APIの場合はDefault RouteとDefault Stageが用意されることにより、デフォルトで以下のようになります。

https://{api_id}.execute-api.{region}.amazonaws.com/

また自動デプロイがデフォルトで有効になっているため、APIを更新すると即座にStage（公開中の環境）が更新されるようになります。立ち上げが迅速に行えるメリットがあります。

HTTP APIとREST APIの比較

認証

Authorizers	HTTP API	REST API
AWS Lambda		○
IAM		○
Amazon Cognito User Pools	○(※)	○
Native OpenID Connect / OAuth 2.0	○

※ Native OpenID Connect / OAuth 2.0として連携可能

HTTP APIの特徴としてJWT Authorizerが挙げられますが、逆に言うとJWT Authorizerのみしか利用できません。REST APIでは、APIの実行権限をIAMで与えることができましたが、そのようなユースケースで利用したい場合はHTTP APIは適していません。

前述の通り、Amazon Cognito User Poolsの連携についてはOIDC Providerとしての連携のみが可能です。

連携

Integration	HTTP API	REST API
HTTP proxy	○	○
Lambda proxy	○	○
HTTP		○
AWS services		○
Private integration		○
Mock		○

前述の通りどちらもLambdaプロキシ、HTTPプロキシが利用できます。従来のAPI Gatewayの特徴的な機能であるAWSサービスと直接繋げる場合はREST APIを選択します。また、VPC内でインターナルに利用したい場合もREST APIを選択します。

API管理

API Management	HTTP API	REST API
Usage plans		○
API keys		○

Usage plansおよびAPI keysは、構築したAPIを外部システム向けに公開する場合などに便利な機能ですが、コアな機能ではないためHTTP APIでは提供されていません。しかしスロットリングの機能は標準で提供されるため、単純にスロットリングをさせたい場合はHTTP APIでも実現可能です。

デプロイ

Deployment	HTTP API	REST API
Cache		○
Request transformation		○
Request / response validation		○
Test invocation		○
CORS configuration	○
Automatic deployments	○
Default stage	○
Default route	○

明確に機能差が出るところです。

REST APIは多機能で、キャッシュ、リクエスト変換、バリデーション、テスト実行などが提供されます。一方HTTP APIはそれらの機能が提供されませんが、REST APIで欲しかったような機能が提供されています。ポイントはやはり迅速に設定できるところです。CORSの一括設定や自動デプロイ、デフォルトでStageとRouteが作られるなど、REST APIで実現する際に準備に時間がかかるようなところが迅速に用意できるようになっています。

セキュリティ

Security	HTTP API	REST API
Client certificates		○
AWS WAF		○
Resource policies		○

AWS WAF連携などのセキュリティの機能はREST APIのみで提供されます。この辺りはHTTP APIでも利用できるようなアップデートに期待したいところですね。

APIの種類

API Type	HTTP API	REST API
Regional	○	○
Edge-optimized		○
Private		○

REST APIでは上記の種類のAPIが作成可能ですが、HTTP APIでは「低レイテンシ・コスト最適化」を主たる目的としているのでRegionalなエンドポイントを作成することができます。Edge-optimizedは端的に言うとCloudFront Distribution経由で配信されるエンドポイントですが、こちらはREST APIのみでサポートされます。また、インターナルAPIを作りたい場合もREST APIを選択します。

つまりHTTP APIはリージョンが特定的なAPIを作りたい場合に最適というわけです。

まとめ

HTTP APIはJWT Authorizerが便利な点やCORS設定が簡単な点に目が行きがちですが、主たる目的が「低レイテンシ・コスト最適化」であることを意識して選択する必要があります。

機能を絞っているためできないことが多いので、機能の比較を見てみるとREST APIで当たり前のようにできていることができない場合もあります。本記事を参考に、HTTP APIとREST APIのどちらを選択するか考えていただければ幸いです。