API GatewayのREST APIにVPCリンクを設定する

API GatewayとVPCリンク

ここではREST APIのVPCリンクを設定する場合について説明します。

API GatewayのREST APIではリクエストをVPCリンクを経由してNLBに転送できます。 これによってNLBを通じてVPC内のEC2やECSといったリソースにリクエストの処理を任せることができるようになります。

今回使用する構成としては以下のような感じになります。

リクエストはAPI Gateway -> NLB -> EC2といった感じで流れていきます。

VPCリンクの詳しい仕組みについては以下の記事が参考になるかと思います。

• 知れば納得！HTTP　API と REST API の VPC リンクは違うんやで。 | DevelopersIO

手順

今回の作業手順は以下のとおりです。 VPCリンク以外は構築済みとして、それ以降の作業を説明します。

• VPCリンクの作成
• メソッドとの紐付け

VPCリンクの作成

API Gateway用のVPCリンクはAPI Gatewayのページから作成します。

ターゲットNLBは既に作成済みの「sample-nlb」を選択しています。 「作成」ボタンを押すと作成中となり、少し時間（数分程度）をおいて作成が完了します。

メソッドとの紐付け

今回はテスト用にtestメソッドを用意しました。 これをVPCリンクに紐づけて、NLBの背後にあるEC2インスタンスで処理をします。

メソッドを選択して以下のように設定します。

VPCリンクは先程作成したものを設定しています。 今回はプロキシ統合を利用しています。 エンドポイントURLが見切れていますが、ここは以下のような値が入っています。

エンドポイントURL

http://[NLBのDNS名]/for_test

NLBのDNS名は以下のような形式です。

NLBのDNS名

{NLB名}-{16文字の文字列}.elb.{リージョン名}.amazonaws.com

NLBのDNS名についてはマネージメントコンソールのLoadBalancerのページのここから取得できます。

ここでは以下のようなマッピングが行われます。

• API Gateway GET /test => EC2 GET /for_test

EC2側では/for_testでレスポンスを返すようなアプリケーションが起動しています。 なので、API Gatewayの/test GETメソッドの実態はEC2内の/for_test GETメソッドとなります。

greedyパス変数を使用した紐付け

先程はAPI GatewayのメソッドとEC2のメソッドを１対１で対応させていましたが、透過的にAPI Gatewayメソッドのマッピングを行う方法もあります。

greedyパス変数です(Catch-allパス変数という呼び方もあるようです)。

これを利用する場合は、リソースの作成時に以下のように設定を行います。

greedyパス変数を利用することでそれより深いパスにあるメソッドを一括して、特定の処理に設定することが可能です。

メソッドの設定としては以下のような感じです。

今回は/{proxy+}としているので、ルート以下のすべてのパスがこのANYメソッドに紐付けられます。

例:

• API Gateway GET /test => EC2 GET /test
• API Gateway POST /test => EC2 POST /test
• API Gateway GET /test/foo => EC2 GET /test/foo

API GatewayにおけるANYメソッドはGET, POST...etcなどのHTTPのメソッドを問わず、このAPI Gatewayのメソッドのルールで処理されることになります。

要約すると以下のような挙動になります。

• /（ルート)以下のパスはすべてEC2で処理される
• HTTPのメソッドの種類を問わずEC2で処理される

つまりはAPI Gatewayに対して送ったリクエストはすべてEC2に転送されることになります。

ここでの注意点はエンドポイントURLに{proxy}変数を入れる必要があるということです。 これを入れないとすべてのリクエストがEC2側のルートにマッピングされてしまい、どのメソッドを呼び出してもルートからレスポンスが返るようになってしまいます。

エンドポイントURL

http://[NLBのDNS名]/{proxy}

終わりに

VPCリンクを使用してVPC内のリソースにAPI Gatewayを紐付ける方法を整理しました。 greedyパス変数によってAPIサーバーをそのままAPI Gatewayに紐付けられるので便利だと思いました。 API Gateway側の認可機能やスロットリング制御などをそのまま使用し、今までのAPIサーバーはそのまま使い続けるなどの局面で便利なんじゃないでしょうか。