ロードバランサー通過後の通信がHTTPである理由

「外からはHTTPSなのに、ロードバランサーを通過した後はHTTPで通信している」ケースは、実際のWebシステムでよく見られますが、要件定義をする際などはその理由について、ことさら説明されることもないため、改めて整理してみました。

1. ロードバランサーでのSSL終端（SSL Termination）

• 多くのロードバランサーは HTTPS（SSL/TLS）通信の暗号化・復号処理を肩代わりします。
• ロードバランサーがクライアントとの間でHTTPSを確立 → 内部の通信は復号化済みのHTTPで流す。

主な理由：

• サーバー側に負荷の大きい暗号化処理を任せず、効率よく処理できる。
• サーバーの設定を簡単にできる（証明書の更新や管理もLBに集約できる）。

2. 内部ネットワークは「信頼できる」前提

• ロードバランサーとアプリケーションサーバー間の通信は、通常 同じデータセンターや同じVPC内のプライベートネットワークを通ります。
• この区間はインターネットに晒されないため、「盗聴や改ざんのリスクは低い」と考え、HTTPで済ませるケースが多い。

3. パフォーマンスの観点

• HTTPSは毎回暗号化・復号処理が必要で、CPUに負荷がかかります。
• 内部通信までHTTPSにすると、その分オーバーヘッドが増える。
• 大規模システムでは、内部をHTTPにしておくことで レイテンシ削減やサーバーリソース節約が可能。

4. 例外：内部もHTTPSにするケース

とはいえ、必ずしもHTTPで良いわけではなく、以下のようなケースでは 内部もHTTPS（End-to-End Encryption） が選ばれます。

• 金融・医療などセキュリティ要件が非常に厳しいシステム
• 複数のデータセンターをまたいで通信する場合（物理的にネットワークが分かれるため盗聴リスクあり）
• ゼロトラストアーキテクチャを導入している場合

🔑 まとめ

• 外部 → LB：HTTPS（安全性のため必須）
• LB → 内部サーバー：HTTPが多い（効率化・管理簡略化）
• ただし高セキュリティ要件では内部もHTTPSにする