AWS導入前に知っておきたかった「VPC設計」

# 1.はじめに

以前、「[AWSアカウント設計](https://qiita.com/takuya_tsurumi/items/cbeeeaa1e3a87c679f81)」について記事を出しました。
今回は、このアカウントを作った後避けては通れない「VPC設計」について書いていきます。

VPCは設計をせずに作成することも可能ですが、
「どこのVPCにEC2を構築すれば良いのか？」とか「管理が大変！」等の壁にぶつかり、
後々後悔することがあるので、事前に設計することをおすすめします。

今回は、アカウントを複数作成することを考慮した上で

『環境ごとにアカウントを分けたパターン』
『システム・環境ごとにアカウントを分けたパターン』

の2パターンで考えていこうと思います！！
私個人的におすすめな構成ですので、参考になれば幸いです。

#2.VPC設計
##2-1.環境ごとにアカウントを分けたパターン
このパターンのアカウントの分け方は以下の図のようになっています。

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3332393534342f64333237316536612d336336312d363735652d396330622d3033363862613364323964322e706e67.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329544/d3216a6a-fc1c-3692-6959-45bacbf3f791.jpeg)
図.2.1.1.環境ごとにアカウント分割パターン


そして以下の図のように、VPCが追加されていき、Subnetでさらに分割されていくイメージです。

![unnamed-2.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329544/0b742429-cd89-8cc5-a473-42023f82dda4.jpeg)
図.2.1.2.環境ごとにアカウント分割パターン-VPC追加イメージ

Subnetの切り方は3環境全て統一するので、1つのVPCに注目します。
個人的におすすめな構成は以下の図のように、役割を4つ作り、それぞれのAZごとにSubnetを作成する構成です。
各サーバの役割は以下4つのどれかに分けられることや、通信要件を考慮した上での構成にしています。


![unnamed-3.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329544/cfaa340c-b84e-47a0-dc71-6e4c5bf8137a.jpeg)
図.2.1.3.VPC役割分担とSubnet構成

それぞれの役割を以下の表にまとめます。

表.2.1.1.セグメントの役割一覧

|No|名前|役割|ルーティング(受信)|ルーティング(送信)|
|---|----|----|---------------|---------------|
|1|Public Segment|インターネットと直接やり取りを行う領域。<br>ロードバランサーや、NATゲートウェイ、Proxyサーバ、踏み台サーバなどが配置される。|Private Segment<br>Managed Segment|インターネット|
|2|Private Segment|webサーバ等の基本的なサーバが配置される領域。<br>外部公開するWebサーバは、Public Subnetのロードバランサーを経由する。|Managed Segment|Public Segment<br>Protected Segment|
|3|Protected Segment|重要データをもつサーバのための領域。<br>DBサーバ等が配置される。|Private Segment<br>Managed Segment|なし|
|4|Managed Segment|管理系サーバのための領域。<br>監視サーバやウイルス対策管理サーバ等が配置される。|なし|Public Segment<br>Private Segment<br>Protected Segment|

また、IPレンジについては、[こちら](https://qiita.com/nisshiee/items/df4261132ec686964605)のサイトが参考になります。
個人的には見やすさ、拡張性のことを考慮した以下のIPレンジが好みです。
Subnetは各AZごとに1つではなく、複数作成(1aのSubnetが3つ等)できるようにすると後悔することがないでしょう。

表.2.1.2.IPレンジ表

|No|環境|VPC-IPレンジ|Subnet-IPレンジ|
|---|---|---|---|
|1|本番環境|10.100.0.0/16|10.100.0.0/24~10.100.255.0/24|
|2|検証環境|10.101.0.0/16|10.101.0.0/24~10.101.255.0/24|
|3|開発環境|10.102.0.0/16|10.102.0.0/24~10.102.255.0/24|

##2-2.システム・環境ごとにアカウントを分けたパターン

このパターンのアカウントの分け方は以下のようになっています。

![68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3332393534342f64656132373435652d613434622d353862332d623435392d6362333861306261323331362e706e67.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329544/638651ff-c564-854b-f559-35babcf9adab.jpeg)

図.2.2.1.システム・環境ごとにアカウント分割パターン

こちらもVPCが構築されると以下のようになります。

![unnamed.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/329544/0c2cf577-ec2b-0433-3607-b369491a2f70.jpeg)


図.2.2.2.システム・環境ごとにアカウント分割パターン-VPC追加イメージ

こちらの構成でも「2.1.環境ごとにアカウント分割パターン」同様、
各役割を意識して必要な数ずつSubnetを作成します。

そして一番考慮しなければならないのが、IPレンジだと思います。
サーバの数等で切り方は変わりますが、表.2.1.2.にまとめたIPレンジ表が
もう一段階細かくなるイメージです。

以下一例としてまとめます。サブネットマスクは任意で変更してください。

表.2.2.2.IPレンジ表

|No|環境|環境別IPレンジ|VPC-IPレンジ|Subnet-IPレンジ|
|---|---|---|---|---|
|1|本番環境|10.100.0.0/16|10.100.0.0/24~10.100.255.0/24|10.100.0.0/28~10.100.255.240/28|
|2|検証環境|10.101.0.0/16|10.101.0.0/24~10.101.255.0/24|10.101.0.0/28~10.102.255.240/28|
|3|開発環境|10.102.0.0/16|10.102.0.0/24~10.102.255.0/24|10.102.0.0/28~10.102.255.240/28|


#3.まとめ
VPCの設計についてアカウント分類を考慮した上で、2パターン書きました。
あくまで設計なので、個人的な思考が多く含まれています。

それぞれの環境ごとにこのパターンを使える場合もあれば、
そうでない場合もあるかと思いますので、いい感じで変更をかけていただけると幸いです！！