[AWS]VPCの分け方の考え方

AWS設計を行うにあたって考えることの一つに、VPCの設計があります。

VPCの分け方はアカウント管理と関わってきます。

VPCの分け方には以下の観点があります。

・システム毎

・環境毎

・システム、環境それぞれで別

これを一つのアカウントで構成するとしましょう。

システムはA、Bとあり、それぞれで本番、検証の環境があるとします。

まず「システム毎」に分けた場合

AシステムのVPC、BシステムのVPCの2つが出来上がります。

一つのVPCの中には本番環境と検証環境がひとまとめに入っています。

VPCはセキュリティを考える上での一つの単位になるので、システム毎にセキュリティが分かれている、という考え方ができます。

また、一つのVPCに本番と検証が入っていることによって

何のメリットやデメリットがある？？？

というと、とりあえず以下のデメリットが見つかりました。

・検証環境に攻撃を受けた場合、本番環境にも影響が出る

・本番と検証でネットワーク構成に差異が出る。

・VPC内のセキュリティグループが増えるので、管理が煩雑

先にも書きましたが、VPCはセキュリティの単位です。

同一VPC内に本番と検証が同居している場合、検証環境に攻撃を受けたら本番環境にも影響を受ける可能性が高くなります。

それであればあらかじめVPCを分けて、ネットワーク的に分離した方が良いです。

また、本番と検証で同一のIPアドレスを使用できないので、VPCを分けた方が完全に同じ環境を作ることができます。

このような観点から見ても、VPCは本番と検証で分けた方がいいでしょう。

また、分け方の考え方の観点の例としては以下があります。

・アプリケーション単位

・本番/検証などの環境単位

・セキュリティレベル単位

・同一サービス単位（ドメイン）

などがあります。

同一VPCにあれもこれも入れている場合、セキュリティグループをたくさん作ることになるので管理が煩雑になってしまいます。

なので、シンプルな構成でVPCを分ける、ひいてはAWSアカウントを分ける設計をした方が良いかと思います。

うーん、もう少し深掘りして事例なんかも見てみたいですね。

ちなみに弊社はガイドラインによると、

1アカウント1VPCの構成が原則でした。。。。

けどすでにアカウントがいくつも作られていたり、VPCは分かれていたりと

ガイドライン無視の状態で各チームが色々やってしまっています。

まずはこの辺の統制を効かせることと、準拠しているかどうかのチェックが必要だな。

今日もお仕事頑張りましょう！