dshimizu/blog/alpha

とりとめのないITブログ

AWSでのVPC設計に関するメモ書き

AWSVPC設計に関して考えたことや調べたこと、参考資料やリンクを残しておく。

事前

AWSアカウント

VPCではないけれど、本番環境とステージング環境・開発環境を1つのAWSアカウント内で運用するか、AWSアカウントレベルでを分けるか、がある。 要件や組織体制、サービス規模によるところもあると思うのでどっちが良いとは一概には言えないけど、AWSアカウントを分けるとその分IAMアカウントの管理とか請求でやや煩雑になる部分もあるが、下記の記事にあるように各環境が完全に疎になるのは良さそう。

VPC

1つのAWSアカウントで運用する場合、本番環境、ステージング環境、開発環境でVPCを分けたい。 本番環境とステージング・開発環境でAWSアカウントを分ける場合はそのまま作れば良い。

AZ

東京リージョンだと、ap-northeast-1a, 1b, 1c, 1dがある。1bは使えない(人によっては使える?)ので3つのAZが利用可能。 1つのリージョン内の各AZは地理的に分離しているらしいので、AZの障害に備えると最低2つ以上のAZを利用する構成にしたい。

アドレス・サブネット

VPCに割り当てるアドレス帯域

最初にVPCに割り当てるアドレスは決める。 RFC 1918 に指定されているように、プライベート IPv4 アドレス範囲から CIDR ブロック (/16 以下) を指定することが推奨らしい。

会社内でもまだ使われていない /16 のレンジがあると良いと個人的には思う。 下記のサブネットにはVPCで割り当てられているアドレス帯域の中から割り当てることになるので、余裕を持たせておいた方が良い。(たいてい余るが)

サブネットアドレス

VPCの中に作るのがサブネット。VPCは同一リージョン内の全AZにまたがるが、サブネットは特定のAZのみで扱われる。 よくあるWeb/App/DBの3層構造にする場合、3層×2AZで最低6サブネットが必要となる。

ホスト数に問題ないなら一つのサブネットにクラスB、クラスC単位で割り当てるのが楽。

  • ap-northeast-1a に10.0.1.0/24 を割り当てる。
  • ap-northeast-1c に10.0.2.0/24 を割り当てる。

ただ、下記の記事のような形で検討するのも良さそう。

同一の用途のネットワーク(例えばWeb層)でかつMulti AZを使う場合、クラスCを2つに分割して各AZのサブネットに割り当てる、ということもできる。

  • ap-northeast-1a に10.0.1.0/25 を割り当てる。
  • ap-northeast-1c に10.0.1.128/25 を割り当てる。

こうすると、Web層の通信をまとめて制御する場合は10.0.1.0/24を指定すれば済む。

AZを考慮したCIDR割り当てをすれば運用面で多少楽できる部分はあるかもしれない。

ただ、現在はAZが3つ使えるので、例えばクラスCを3つに分割しようとすると煩雑なので、やはり可能ならクラスB、クラスC単位でざっくり割り当てるのが楽そう。

ルートテーブル(ルーティング)

サブネット内部から外部(インターネット)へ通信するためにはインターネットゲートウェイを作成し、ルートテーブルでインターネットゲートウェイへのルーティングを追加する必要がある。 サブネット内部から外部(インターネット)へ通信しても良いサブネットには、インターネットゲートウェイへのルーティングが許可されたルートテーブルを割り当てる。そうでないものはlocalのみに制限されたルートテーブルを割り当てる。

セキュリティグループとネットワークACL

セキュリティグループはインスタンスへのインとアウトの通信を制御する。ネットワーク ACL はサブネットレベルでインとアウトの通信を制御する。

セキュリティグループはほぼ必須で使うことになると思う。 ネットワーク ACLもデフォルトで割り当てられているが、サブネットレベルの細かい制御が必要な場合は設定が必要。使うかどうかは要件による。

まとめ

ドキュメントやblackbeltの資料を読むのは良い。 各環境の分離レベルをどうするか、クラウド(AWSVPC/AZ)を考慮したアドレス設計をどうするかを少し自分の中で整理しながら書いた。

参考