Amazon API Gateway を独自ドメインで利用する

Arai

2015.07.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

Amazon API Gatewayを使用して作成したREST APIは、AWSが発行するFQDNで公開する以外にも、Route 53などのDNSを介して独自ドメインで公開することができます。では早速ですが、独自ドメインからアクセスできるREST APIを試しに作ってみましょう。

Amazon API Gateway で作成したAPIを独自ドメインで公開するためには、HTTPSを使用する必要があります。そのため、SSLサーバ証明書が必要です。

APIを作る

AWS Lambda Function の準備

今日の運勢を文字列で返してくれる、おみくじ関数を作りました。

Amazon API Gateway の準備

Amazon API Gatewayの設定方法を詳細に解説…したいところですが、弊社ブログにはすでに多くの API Gateway 解説記事が投稿されていますので、詳しくはこちらをご参照ください。

今回は、ルート直下に omikuji リソースを作成し、 omikuji の GET メソッドで先ほどのおみくじ関数を呼び出す、という構成にしています。
また、API名は Omikuji API としました。

途中で、Amazon API Gateway に AWS Lambda Function を実行する権限を与えて良いか尋ねられますので、はいと答えて与えておいてください。
また、必要に応じて API Key を発行し、リソースへのアクセスを制限することが出来ます。今回はお試しなので設定しませんが、本格的にやってみようと思っている方は以下の記事を参考に API Key を発行してください。

Amazon API GatewayでAPIキー認証を設定する

APIをデプロイする

Omikuji APIをデプロイします。先ほど紹介した解説記事に詳しい手順が書いてありますので併せてご参照ください。今回は環境名 v1 にデプロイすることにします。

これにて、Omikuji APIが公開されました。
ですが、今回の本題はここからです。このOmikuji APIを独自ドメインを介して公開してみましょう！

独自ドメインの設定を行う

マネジメントコンソールの APIs > Custom Domain Names から、独自ドメインの割り当て設定を行います。

基本的には ELB に証明書を適用するときのやり方と同じです。が、IAM に登録済の証明書が使えない（選択させてくれない）、一度登録した証明書を再利用させてくれない、など、ちょいちょい機能が足りてない部分があると感じました。このあたりは、今後の発展に期待します！

情報を正しく入力すると次に進めます。正しくない証明書を入力すると、赤い文字で怒られますｗ

DNS（Route 53）の設定を行う

証明書の登録が成功すると次のような画面に進みます。

さっき入力したドメインからこのドメインに向いたCNAMEレコードを貼ってくれ！ と言われます。
ここで表示されるのは Amazon CloudFront CDN と同じドメインのレコード (xxxxx.cloudfront.net) です。

では、言われたとおりに設定しましょう。今回は Amazon Route 53 を使用して設定するため、CNAMEレコードではなくエイリアスにしています。
Amazon Route 53 のエイリアス機能については、とてもここでは紹介しきれないため、弊社ブログのエントリーをぜひ参照ください。

Amazon Route 53のALIASレコード利用のススメ

DNSの設定が反映されるまでには少し時間がかかるので、気長にコーヒーでも飲みながら待ちましょう。

これで独自ドメインとAmazon API Gatewayで作成したAPIのつなぎこみは完了しました。
が、実際に公開されるまでには、あと１ステップ残っています！

APIをマッピングする

先ほど登録した独自ドメインに対して、どのAPIが対応するのかを設定します。
今回は、はじめてなのでOmikuji APIひとつしかありませんが、独自ドメインに複数のAPIを対応させることも可能です。

先ほど、 xxxxx.cloudfront.net へCNAMEを設定してくれと言われた画面に戻ります。画面消しちゃったという方は、 APIs > Custom Domein Names から左ペインのドメイン名を選択すれば再度表示することができます。

この画面のCreate API Mappingから、この独自ドメインがどのAPIに対応するのか、またどのステージに対応するのか、およびAPIの Base Path を設定できます。

API には、独自ドメインと対応するAPIを設定します。今回は Omikuji API ですね。この項目は必須です。
Stage には、ドメインに紐付けるステージ(環境)を設定できます。先ほど v1 というステージにおみくじAPIをデプロイしたので、今回は v1 を指定していますが、入力しなくても大丈夫です。
Base Path にパスを指定すると、そのパスを独自ドメインに追加したものがおみくじAPIのルートになります。(本来は入力必須ではありませんが、後述の理由から必ず入力してください）

実際に見てみるとわかりやすいと思います。

-	おみくじリソースにアクセスする方法
Stageに`v1`指定、Base Path指定なし	https://独自ドメイン/omikuji (*1)
Stageに`v1`指定、Base Pathに`api`指定	https://独自ドメイン/api/omikuji
Stage指定なし、Base Pathに`api`指定	https://独自ドメイン/api/v1/omikuji
Stage指定なし、Base Path指定なし	https://独自ドメイン/v1/omikuji (*1)

*1 2015/07/11現在、Amazon API Gatewayの不具合のため、この設定では動きません。

今回の設定は Stageにv1指定、Base Pathにapi指定なので、 https://独自ドメイン/api/omikuji でアクセスできます。
では実際にアクセスしてみましょう！

独自ドメインからAWS API Gatewayで作成したAPIにアクセスすることができました！
APIを何回か叩いた結果おみくじとして機能していたので、特別な設定をしない限り勝手にキャッシュされることはないようです。

まとめ

API Gatewayは、HTTPS経由のアクセスにしか対応していない。
API Gatewayに独自ドメインからアクセスする際、xxxxx.cloudfront.net に対してCNAME/ALIASを貼る。
- SSL証明書が必須です。（2015/07/11 現在）
API Mappings で Base Path を省略するとリソースにアクセスできなくなる不具合がある。参考
- どこ叩いても 403 Forbidden が返ってきてしまう。とてもハマった。
API 処理結果のキャッシュが可能。
API をステージ(環境)にデプロイするという考え方。
- ステージと Custom Domain Name の API Mappings をうまく使えば、APIのバージョン管理などがとても楽になりそう。
- /api/v1/omikuji -> /api/v2/omikuji