今回は基本に戻って、改めてAWSを使うときのNetworkってどうするのかというのを書いてみます。
AWSのNetwork(VPC)
VPCは「Amazon Virtual Private Cloud 」の略でCloud上にある仮想的なネットワークを指します。
一番最初にAWSを利用しようとしてVPCに行くと、デフォルトでAWS側が用意しているVPC(default VPC)があります。
ちょっと見てみましたが、これ、なんだかんだよく出来ていますね。
大きめにCIDRを取っているVPCとSubnet、Internetから通信が出来るようにInternetGateway、内部とIGWへのルーティング、内部であればすべての通信を許可するSecurityGroup…
最低限ですが必要なものはそろっているので、あまり詳しくない方はそのまま使ってもいいと思います。
ただ、実はこれはAWSが定めるAWS Well-Architected(ベストプラクティス)ではありません。
また、実際にサービスを載せて動かしてみると「ここをもっとこうすると」というのが見えてきます。
見えてきたところでVPCは後から修正できないものが多いのが難点。ということで、最初っからこんな感じで作っておけば後々困ることは少ないんじゃないかなぁというVPCを考えました。
NW構成図
全体の構成図はこんな感じにしました。
ポイントは以下の通りです。
・複数AZ(アベイラビリティゾーン)構成 ※構成図では2AZにしています
・InternetGateway構築
・各AZのPublic用SubnetにNATGateway構築
・サブネットは3つに分割、Pibliic用(Internetから直接アクセスできるところ)、Private用(内部でアクセス可能、Internetから直接は通信できないがInternetへの通信はNATGatewayを経由して出来る)、DB用(内部通信のみ)
・各サブネットに合わせたルーティングテーブル作成、特にDBサブネットはPrivate用サブネットとDBサブネットのみルーティング出来るようにする
・セキュリティグループは共通のものとDB用のもので作成、Publicにおくリソースには個別に作成していく方針
この構成の場合、EC2やECS(コンテナ系)、LambdaなどはPrivate用のサブネットに配置することを前提としています。どうしてもInternetからEC2などが直接通信を受ける(ALB/NLBを前段に構えられない)場合にのみPublicに置きますが、出来る限りPrivateに置くようにします。
PublicはALB/NLB以外はほぼ置かないです。
VPCのCIDR
Networkの概要は出来たので、実際にどのようにIPアドレスを切っていくかを考えます。
VPCは最初にCIDR(サブネットマスク・プレフィックスと言われる/xx)を設定すると後から変えられません。
AWSでサービスを作成した後に困るのはIPアドレスが足りなくなること。その問題を起こさない為にはここでCIDRを大きめに切ることをお勧めします。
正直、大きすぎて困ることはほぼないです。自社のNWとAWSをDirectConnectなどの専用線でつなぐとなる時やAWSのVPC同士をつなぐときはここのCIDRが問題になることもありえますが…。
今回はこんな感じにします。
VPC CIDR
10.200.0.0/18
※IPアドレスだと16,384個分
このCIDRであれば、10.200.0.0から10.200.62.255まで使用可能です。
そしてサブネットを以下の通り切ります。
2AZ構成なので、それぞれの役割のサブネットをAZ毎に1つ作ります。
Public用サブネット：
AZ-a 10.200.0.0/21
AZ-b 10.200.8.0/21
Private用サブネット：
AZ-a 10.200.16.0/21
AZ-b 10.200.24.0/21
DB用サブネット：
AZ-a 10.200.32.0/21
AZ-b 10.200.40.0/21
余剰：(サブネットに割り当ててないけど、何かあった時に使えるIPアドレス)
10.197.48.0/20
/21だと2048個のIPアドレスが使用できます。
実際にはサブネットに割り当てたCIDRの前4つと後ろ1つはAWSで予約されているIPなので利用できません。静的IPを設定する方はご注意を…。
終わり
作成するNW概要としては以上です。
簡単で意識せずに出来るようになっていたりしますが、実際に使い始めてみてから、あれが足りない、これをこうすればよかったとなりがちなところでもあるので、最初に考慮できるのであれば考慮して設計することをお勧めします。
次回からは個々のリソースの作成をしていこうと思います。
