1.はじめに
以前、「AWSアカウント設計」について記事を出しました。
今回は、このアカウントを作った後避けては通れない「VPC設計」について書いていきます。
VPCは設計をせずに作成することも可能ですが、
「どこのVPCにEC2を構築すれば良いのか?」とか「管理が大変!」等の壁にぶつかり、
後々後悔することがあるので、事前に設計することをおすすめします。
今回は、アカウントを複数作成することを考慮した上で
『環境ごとにアカウントを分けたパターン』
『システム・環境ごとにアカウントを分けたパターン』
の2パターンで考えていこうと思います!!
私個人的におすすめな構成ですので、参考になれば幸いです。
#2.VPC設計
##2-1.環境ごとにアカウントを分けたパターン
このパターンのアカウントの分け方は以下の図のようになっています。
そして以下の図のように、VPCが追加されていき、Subnetでさらに分割されていくイメージです。
図.2.1.2.環境ごとにアカウント分割パターン-VPC追加イメージ
Subnetの切り方は3環境全て統一するので、1つのVPCに注目します。
個人的におすすめな構成は以下の図のように、役割を4つ作り、それぞれのAZごとにSubnetを作成する構成です。
各サーバの役割は以下4つのどれかに分けられることや、通信要件を考慮した上での構成にしています。
それぞれの役割を以下の表にまとめます。
表.2.1.1.セグメントの役割一覧
No | 名前 | 役割 | ルーティング(受信) | ルーティング(送信) |
---|---|---|---|---|
1 | Public Segment | インターネットと直接やり取りを行う領域。 ロードバランサーや、NATゲートウェイ、Proxyサーバ、踏み台サーバなどが配置される。 |
Private Segment Managed Segment |
インターネット |
2 | Private Segment | webサーバ等の基本的なサーバが配置される領域。 外部公開するWebサーバは、Public Subnetのロードバランサーを経由する。 |
Managed Segment | Public Segment Protected Segment |
3 | Protected Segment | 重要データをもつサーバのための領域。 DBサーバ等が配置される。 |
Private Segment Managed Segment |
なし |
4 | Managed Segment | 管理系サーバのための領域。 監視サーバやウイルス対策管理サーバ等が配置される。 |
なし | Public Segment Private Segment Protected Segment |
また、IPレンジについては、こちらのサイトが参考になります。
個人的には見やすさ、拡張性のことを考慮した以下の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.システム・環境ごとにアカウントを分けたパターン
このパターンのアカウントの分け方は以下のようになっています。
図.2.2.1.システム・環境ごとにアカウント分割パターン
こちらもVPCが構築されると以下のようになります。
図.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パターン書きました。
あくまで設計なので、個人的な思考が多く含まれています。
それぞれの環境ごとにこのパターンを使える場合もあれば、
そうでない場合もあるかと思いますので、いい感じで変更をかけていただけると幸いです!!