パブリックなAPI Gatewayから仮想オンプレミスとして別ネットワークのALBをHTTPSバックエンドとして指定する

いわさ

2021.11.15

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

いわさです。

API Gatewayを使って別のネットワーク（別AWSアカウント、Azure、オンプレミス）をバックエンドに指定する方法を検証していました。
かつ、プライベート経路を通すがバックエンドに対して全経路のSSL通信が必要、といったシーンを想定しています。

API Gatewayは通常はLambdaと組み合わせて利用するシーンが多いと思いますがプライベートなリソースをバックエンドに指定出来るのでしょうか。

なお、プライベートネットワーク相当の環境は、先日作成したテンプレートを使いたいと思います。

VPCリンクを使う

API Gatewayの統合タイプには"VPCリンク"というものがあり、こちらを使うことでプライベートリソースをバックエンドに指定することが出来ます。
以下の記事がとても参考になりました。

今回はREST APIを想定しているので、VPCリンクのターゲットはNLBになります。

そして、VPCと外部のプライベートネットワークをプライベート接続することで、API Gatewayからプライベートリソースまで通信出来るようになります。
AWSのVPC間であればVPCピアリング、AWS外（Azureなどのパブリッククラウドやオンプレミス）であればDirect Connectや、あるいはサイト間VPNを使います。

ここまでの構成で、API GatewayからバックエンドまでをHTTP通信は可能です。

エンドポイントURLへHTTPSを指定した場合はどうなるでしょうか。

エラーになってしまいました。

Execution failed due to configuration error: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Javaアプリケーションでは自己署名証明書を信頼せずにSSL接続を行うと上記エラーが発生するようです。
信頼、あるいは無視する設定が必要なのですが、API Gatewayでは用意されていませんので別の方法を考える必要があります。

API Gateway、お前、Javaだったのか...

ACMで証明書を作成しALBを設置

今回はACM+ALBな環境をプライベートネットワーク側に配置して接続するようにしてみます。
ただし、オンプレミスなどを想定しているので、NLBのターゲットグループはALBではなくてIPアドレスを指定します。

iwasa.takahito@hoge ~ % nslookup internal-alb1-1540553884.ap-northeast-1.elb.amazonaws.com
Server:        192.168.0.1
Address:    192.168.0.1#53

Non-authoritative answer:
Name:    internal-alb1-1540553884.ap-northeast-1.elb.amazonaws.com
Address: 10.103.10.172
Name:    internal-alb1-1540553884.ap-northeast-1.elb.amazonaws.com
Address: 10.103.11.189

ALBを使う場合はIPをどう固定化するのか考えるべきだと思いますが、今回は前述のとおりオンプレミスの静的なロードバランサーを想定しているのでここでは考えません。

Mon Nov 15 00:16:07 UTC 2021 : Sending request to https://nlb1-1f700f2691864826.elb.ap-northeast-1.amazonaws.com/
Mon Nov 15 00:16:07 UTC 2021 : Execution failed due to configuration error: Host name 'nlb1-1f700f2691864826.elb.ap-northeast-1.amazonaws.com' does not match the certificate subject provided by the peer (CN=20211114.tak1wa.com)

それでもまだエラーが発生していますが、しかしちょっとエラー内容が変わりました。
名前解決してやればいけそうな気がしますね！もうちょっと

Route 53 プライベートホストゾーン

API Gatewayから同FQDNでNLBへの名前解決を行ってやればいけそうです。
オンプレミス側での内部DNSはWebサーバーを指しており、引いてくることは出来ないため独自にNLBが属するVPC内で内部DNSが欲しいところです。
これには、Route 53のプライベートホストゾーンが適していそうです。