VPC にプライベートサブネットを作るのはエンジニアの思考停止か？

Posted on 2015-06-22

タイトルは若干釣りです ;-)
一般的な Web サービスにおいて、VPC にプライベートサブネットは必要ですか？という話です。

VPC の設計でよくあるのが、パブリックサブネットとプライベートサブネットを持つ 2 層レイヤの VPC です。公式ドキュメントにも例があります。

パブリックサブネットがいわゆる DMZ セグメントで Web / App サーバが配置されます。プライベートサブネットはインターネットから隔離されたセグメントで DB サーバが配置されます。

このプライベートサブネットは AWS の良さを殺してしまうだけで意味がないと思っています（AWS を前提に書いていますが、オンプレミスにも同じことが当てはまると思います）。

Web / App サーバの設定ファイルには DB への接続情報が書かれているので、パブリックサブネットに侵入された時点で権限を分けていたとしても DB にアクセスされていると考えるべき
- 仮に暗号化したパスワードを設定ファイルに書いたとしても、復号化する鍵を Web / App サーバから見えるところに置く必要があるので堂々めぐり
- そう考えるとサブネットを分ける意味がない
プライベートサブネット用に立てる NAT インスタンスが SPOF であり、冗長化するためにそれなりの労力が必要
- NAT インスタンスの保守にコストを割くなら、プライベートサブネットを廃止してパブリックサブネットに侵入されない工夫をすべき
Auto Scaling で Web / App サーバがスケーラブルになっても、NAT インスタンスがボトルネックになって全体としてスケールしない
- サービスを止めることなく NAT インスタンスを入れ替えることはできないので、結果的に AWS のスケーラブルな特性を殺してしまう

これらの理由からプライベートサブネットは不要だと思っています。

技術的じゃないところに理由があるとすれば、「セキュリティ監査でよく聞かれる」というのが思いつきますが実際はどうなんでしょうか。

思いのほか AWS 界隈からいろいろな意見をいただいたので追記します。概要をかいつまんで列挙します。

「誤ってセキュリティグループを開けてしまったときの予防策」
- ヒューマンエラーは必ず起きるので安全側に倒すという意味で一定の効果はありそうですね。 Trusted Advisor にセキュリティグループのチェック項目があるので定期的にチェックするようにしています。
「DX や VPN でセグメント調整するときに必要」
- こちら側の閉塞網をプライベートサブネットにつなぐということかな？ DX や VPN をつないだことがないので参考になりました。
「パブリックサブネットは ELB や Nginx だけを置いてリバースプロキシすれば DB の情報はプライベートサブネットだけに持つことができる」
- これは盲点でした。この方法ならばプライベートサブネット内で完結することができますね。また、プライベートサブネットだけで動くサーバ（たとえばバッチサーバ）もあるので、「パブリックサブネットに侵入された時点でアウト」とは言えませんでした。
「NAT は HTTP Proxy 使えばある程度スケールするし監視できる」
- CDP の High Availability NAT パターンで紹介されている方法のようです。

このエントリーを書いたときはマイノリティーな考え方だと思っていたのですが、同じように考えている人が意外と多かったです。これまでの常識にとらわれることなくノウハウをアップデートしていきたいものです。

はったりエンジニアの備忘録