【AWS・EC2】プライベートサブネット内で構築したAPIをブラウザorコンソールから呼び出せない。

Question

以下の構成で、awsの環境構築をしています(aws初心者なので表現がおかしいかもですがご容赦ください)。

 ①１つのVPC内に、プライベートサブネットとパブリックサブネットを置く。

②パブリックサブネット内について
 ・ルートテーブルとインターネットゲートウェイ、ルートテーブルとパブリックサブネットを紐付けて、パブリックサブネットがインターネットと通信できるようにした。
 ・セキュリティグループのインバウンドは、SSH、HTTPS、HTTPを全て0.0.0.0/0で設定。
 ・パブリックサブネットはフロントエンド用（Next.js）とするため、パブリックサブネット内でEC2をインスタンス起動して、ターミナルからEC2にアクセスして、Nginxを使用して、webサーバーを構築。
 ・自作のソースコードを持ってきて、npm startし、ブラウザからhttp:// IPアドレスで、接続＆ブラウザ表示を確認済。

③プライベートサブネット内について
 ・プライベートサブネットはバックエンド用(nestJSでAPI、DBはPostgreSQL)とするため、EC2とRDSを構築。
 ・セキュリティグループのインバウンドは、
SSH、HTTPS、HTTPをそれぞれ、フロントエンド側のセキュリティグループとバックエンド側のセキュリティグループを許可＆
PostgreSQLをバックエンド側のセキュリティグループのみ許可
 ・こちらも、パブリックサブネット内のEC2からプライベートサブネット内のEC2にアクセスして、自作のソースコードを持ってきて、npm startが無事でき＆DBにテーブルなどが作成できたことをコンソール上で確認。

と、ここまではできました。
が、フロントエンド・バックエンド共にnpm startで起動させているのですが、ブラウザ上でAPIが呼び出せませんでした。
ただ、ブラウザ上でAPIエラーも発生していなかったので、パブリックサブネット上のEC2からAPIを以下のコマンドで叩いてみたのですが、こちらも以下のエラーが返ってきました。

叩いたコマンド：
 curl -I "http://【プライベート IPv4 アドレス】/api/post/userId/null
エラー：
curl: (7) Failed to connect to 【プライベート IPv4 アドレス】 port 80 after 1 ms: Connection refused

上記エラーを検索したところ、awsの以下のサイトに本エラーに関する記述があり、
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-linux-resolve-ssh-connection-errors/
確認したのですが、「ホストはインスタンスに到達したが、SSH ポートでリッスンしているサービスがなかった。」という原因があるのではという記載からバックエンドのnestJSの方がAPIを叩ける状態になっていないのでは？と思いました。

ここで伺いたいのですが、
A)パブリックサブネット内のEC２からプライベートサブネット内のnestJSのソースコードが動いているか確認する手段があれば教えていただきたいです。(現状、コンソール上でnpm startが成功したというステータスしかわからないため)
B）APIコールできない他の理由があるようであれば、こちらもご教授お願いしたいです。

よろしくお願いします。

Comments

[退会済みユーザー]

NATGatewayは？

[lawsoncoffee]

NATGatewayは、私の理解だと、プライベートサブネットからインターネットに接続するためのものと認識してます。今回は、パブリックサブネットからプライベートサブネットにアクセスすることなので、NATGatewayとは逆方向を実現したいです。

[yu_1985]

それはプライベートサブネットからインターネットへのアクセスに必要なものなので、今回は関係がありません。

[退会済みユーザー]

仰る通りで私の認識が不味かったです。
https://blog.serverworks.co.jp/2021/02/22/121747

Answer 1

まず、プライベートサブネット内にブラウザからアクセスできないのは、インターネットに繋がっていないので当然です。
それをしたいならプロキシかなにかを挟む必要があります。
一般的にはAWS上ではELB（大抵はALB）を使用します。

curlでパブリックサブネットのEC2からAPIのプライベートIPにリクエスト送って失敗しているのは、npm startで使っているポートが80番ではないからではないでしょうか。
デフォルトでは3000とかだったかと思いますし、オプションで変えてるならその番号です。

そもそも、アプリのフロントとバックエンドをどういう構成にしようとしているのでしょうか。
クライアントから直接APIにアクセスさせたいなら、構成としてALBがほぼ必須になります。

Comments

[lawsoncoffee]

ご回答ありがとうございます。

>curlでパブリックサブネットのEC2からAPIのプライベートIPにリクエスト送って失敗しているのは、npm startで使っているポートが80番ではないからではないでしょうか。

ポート番号として8000を使用していたので、一時的にセキュリティグループのインバウンドにカスタムTCP/8000を加えて再度試したところ、200が返ってきました。nestJSのソースコードは動いていたようです。

>アプリのフロントとバックエンドをどういう構成にしようとしているのでしょうか。

フロントエンドとバックエンドを分け、フロントエンドからAPIで叩いてデータを取得したかったので、
バックエンド側(API＋DB)は、フロントエンドのwebサーバーからだけ通信できれば良いと考えていました。
そのため、バックエンド側(API＋DB)をプライベートサブネット内に配置し、プライベートサブネットのセキュリティーグループのインバウンドにて、HTTP(S)にフロントエンド側のセキュリティグループを指定すれば、ブラウザ上であってもアプリのフロントからは、APIを叩けるのではと考えていました(そして、このアプリのフロント以外からは叩けなければセキュリティレベルが高いかなと)。
が、この目論見がそもそも間違っていたようですね。ALBについて調べてみようと思います

[yu_1985]

フロントエンドという言葉の意味を勘違いしていないでしょうか。
そこにあるのはクライアント側で動くプログラムで、フロントのサーバーとは単にクライアントで動くプログラムを置いているだけなのでは。
バックエンドのAPIはクライアントからアクセスできなくてはならず、ネットワーク的な制限をかけてしまうとクライアントからアクセスできなくなり思うように動作はしないはずです。
そこではない方法でセキュリティを担保する必要があります。

[lawsoncoffee]

ありがとうございます。理解できました。
バックエンドのAPIはクライアントからアクセスしつつ、セキュリティ観点はまた、別で考えてみます