Amazon Web Services(AWS)がAmazon API Gatewayをリリースした。APIの公開，メンテナンス，監視，安全確保を目的に‘あらゆる規模’のAPIに対応する，完全に管理されたサービスだ。AWS管理Webポータルを使うことで，アプリケーションのデータやビジネスロジック，Amazon EC2上で動作するアプリケーションなどのバックエンドサービスが提供する機能，AWS Lambda上で動作するコード，AWS以外にホストされて利用可能なすべての公開サービス，といったものにアクセスするための，‘フロントドア’の役割をするAPIの開発が可能になる。
AWSの公式ブログによると，AWSユーザの大半は，モバイルやWeb，エンタープライズ，あるいはIoT(Internet of Things, モノのインターネット)アプリケーションのバックエンドWebサービスをAWS上にホストしている。これらのサービスはユーザインターフェースを持たず，通常はRESTスタイルのインターフェースを使用して，プログラム的にアクセスする。APIバックエンドをうまくホストするためには，セキュリティの提供，トラフィック管理，監視機能の実装など，不可欠な基本的サービスを提供する，インフラストラクチャのサポートが不可欠だ。
Amazon API Gatewayはまさに，このインフラストラクチャを提供するためのものだ。‘何十万’という規模のAPI同時呼び出しを受け入れて処理し，トラフィック管理や認証，アクセス管理，モニタリング，APIバージョン管理といったタスクを実行する。API Gatewayのこの驚異的なポテンシャルについては，Python用のboto AWS SDKやAWS CLIを開発したMitch Garnaat氏を始めとして，何人かの業界著名人がコメントを寄せている。
そのフォース(Force)には本当に驚かされました。何千という数のRESTフレームワークが突然恐怖の声を上げ，そして沈黙したかのように思えます。 #AWSSummit
AWSチーフエバンジェリストのJeff Barr氏は，APIをエンドユーザや顧客に提供する場合，１つ以上のプログラミング言語を対象としたソフトウェア開発キット(SDK)の開発やメンテナンス，配布といった作業がしばしば必要になると，AWS公式ブログで指摘している。そのためにAWS API Gatewayは，SDKを自動生成する機能も備えている。現在はJavaScript, iOS, Androidが対象だが，将来的には他の言語もサポートする計画だ。公式ブログではさらに，例えばSwaggerなどで記述された既存のAPI定義を，API Gatewayにインポートすることも可能だとされている。ただしこのツールは，現時点では提供されていない。
Barr氏は，API GatewayとAWS Lambdaという，いずれもイベントに応答したコードの実行や，下位の計算リソースの自動管理を行うサービスを組み合わせることで，複雑なバックエンドアプリケーションのプロビジョニングやコンフィギュレーションを必要としない，APIの開発が可能になる，とも述べている。
AWS Lambdaを[API Gatewayeと組み合わせて]使用することによって，完全にサーバレスな，スケーラビリティの高いAPIの実装が可能になります。
さらにBarr氏は，API Gatewayが‘レガシシステムをラップし，拡張し，効果的に近代化する'APIの実装を可能にする点も指摘する。複数のRPCスタイルのサービスコール結果をひとつの応答に集約して，データのフィルタや処理を行うことができるのだ。さらに，JSON-Schemaを使った変換を指定することにより，既存サービスの出力するXML形式のデータをJSONに変換することも可能である。開発したAPIは，AWS Management Console内でテストすることができる。HTTPステータスコードやレスポンス(ボディとヘッダ)，要求ログすべてにアクセス可能だ。下のスクリーンショットは，API Gateway UIのエンドポイント定義とテストセクションを示している。
複数の環境 – API Gatewayでは‘ステージ’と呼んでいる – を生成して，‘dev, beta, prod’といったタグのスコープ内で，選択的にデプロイすることも可能だ。また，必須ではないが，バージョン毎，オペレーション毎に別々の実装を使用することもできる。APIの新バージョンを作成する場合には，既存のAPIをクローンして特定のステージにデプロイし，旧バージョンの非推奨化を合わせて作業することも可能だ。
AWSの公式ブログでは，APIをデプロイした後の要求の受け入れや処理，モニタ，応答はAPI Gatewayで行う，と説明されている。キャッシュはステージ単位で設定することができる。キャッシュした応答の寿命時間や，要求パラメータのキャッシュキーへのマッピングなど，完全なコントロールが可能だ。APIへの要求はAmazon CloudWatchにログされ，詳細な測定情報が，ステージ単位，メソッド単位でAmazon CloudWatchにレポートされる。APIの生成や設定といった管理作業は，監査を目的としてCloudTrailにログされる。所定のレートを超えるリクエストを絞り込むことも可能だ。個々のメソッドへのアクセス許可には，AWS Identity and Access Management (IAM), Amazon Cognito, あるいはOAuth認証が利用できる。
Barr氏はAWS公式ブログで，API Gatewayの設計目標として，以下のような効果の提供をあげている。
- スケーラブルかつ効果的 – システムリソースを活用しつつ，どのようなRPS(Request per Seconds)値も処理可能であること。
- セルフサービスかつ高い有用性 – 特別な知識やスキルを必要とせずに，APIの定義や改訂，デプロイ，監視が可能であること。SDKが容易に生成できることも含まれる。
- 信頼性 – エラー応答がカスタマイズ可能であることなど，完全にコントロールされたエラー処理を備えた，信頼性の高いサービスの構築。
- 安全性 – 最新のAWS認証機構とIAMポリシのメリットを活用した，APIおよびAWSリソースの管理が可能であること。
- パフォーマンス – AWSネットワークによるバックエンドへのデータ転送を備え，(CloudFrontを通じて)低レイテンシを実現した，世界規模のアクセスに対応するサービスの構築。
- 費用対効果 – 固定費を必要としない賦課方式で，経済的なサービス構築が可能であること。
Amazon API Gatewayは現在，米国東部(バージニア北部)，米国西部(オレゴン)，欧州(アイルランド)の各リージョンで利用可能だ。詳しい情報はAWSのドキュメントポータルで見ることができる。