前置き
予告編と記事を1つ挟んで、改めて作っていこうと思います。 APIGateWayとLambdaを使って決済システムのAPIを作るお話しです。
全体構成
今回お話しするのはピンクの枠となっている部分です。
注意点
- 必ずしもAWSのベストプラクティスに準じているわけではありません
- プログラムの内容は非公開であり、当該環境内で今回出てくる物は説明するサービスしか構成図に載せてません
- 決済と記載していることからセキュリティの認証系を取るための参考構成としてください
- 構成図はピンクの枠を変更することから毎回の記事には載せますが、検証環境のアカウントが用意できなかったため設定時の画像はあっても細切れとなります
- 左のVPCに関しては、細かい所が出せないため、細かい説明はしません。
今回のお話で利用するサービス
構築にあたっての条件
- APIの本体(Lambda Function)はPrivateNetworkに置くこと
- 決済を実行するときにAPIは一度環境外(グローバル)に情報を投げること
- グローバルに出る際には固定IPであること（投げる先がIPアドレスが指定となっているため)
- 決済後の処理情報は、必要な情報のみを別のAWSアカウント・別VPCに存在するRDSに保存すること
実際にやったこと
- VPCにプライベートサブネットとパブリックサブネットを作成する
- パブリックネットワークにNAT Gatewayを配置する(AZ単位でそれぞれ1つずつ)
- API Gatewayを作成する
- Certification Managerを用いてDNS認証の証明書を作成する。
- API Gatewayでカスタムドメインを有効化して証明書を紐付け、AWSから発行されたドメインを無効化する
- AWS WAFをリージョンで作成する
- 参考は過去記事をどうぞ
- AWS WAFをAPI Gatewayに紐付ける
ハマったことと所感
この時ハマったことが2箇所ほどありました。
ステージを作ってあげないとそもそもAWS独自のURLが発行されないこと、AWS WAFを紐付けられないことを当時は知らず 半日くらい時間を溶かしました。 また、独自URLが発行されないが故に、「API Gatewayって何に使うのよ？」となっていました。
こちらも理解するのに少し時間がかかりましたが、実行していた当初、設計上ではVPC外だったので「バージニアに作る」という感覚で居たのですが、証明書が一向に出てこないとなった末に、API Gatewayのリージョンに作成してみたら動きました。
後から調べて分かったのですが、AWS公式にも「エッジ最適化ではus-east-1」で作ってね
と書いてありました。
備考
前記事より、記事記載形式を変更することにしました。 そのため見やすい、見にくいがありましたらコメントいただければと思います。
