AWSで新規にシステムを構築する際のアドレス体系案
AWSのネットワーク設計をサボらないでちゃんとやる
という記事があって、自分もちょうどこのあたりを検討しているので自分の検討している体系も書いてみる。
この体系は「現時点でオンプレミスの環境があってそことVPN接続する」「今回たまたまAWSを使っているものの今後ほかのクラウド環境も使うかもしれない」「少し共通の機構を持つ小さいシステムが10〜20個ぐらい格納されるかもしれない」という前提で作ってある。
おそらく方向性としては「システム別に独立した体系にする」などの方針でシステム別に小分けになって相互に疎結合の通信のみにするというのもありえるが、今回はオンプレミスからの緩やかな移行なども鑑みて「大きな体系内に小さなシステムを内包する」方向性にしている。
ビット体系：AAAAAAAA BBBBBCCD DDEEFFGG GGGGGGGG
| CIDR | bit | 個数 | 概要 | 説明 | |
|---|---|---|---|---|---|
| A | /8 | 8 | - | クラスA | クラスAのプライベートアドレス体系（＝10）。 |
| B | /13 | 5 | 32 | 事業 | Aとセットで当該事業に割り当てられた値。 |
| C | /15 | 2 | 4 | 拠点 | AWSの各リージョンや別クラウド。DRも独立拠点。 |
| D | /18 | 3 | 8 | 環境 | 共通、本番、ステージング、開発、DRなどの環境。VPCはこの単位。 |
| E | /20 | 2 | 4 | カテゴリ | Private、Publicなどのカテゴリ。当面はこの2で残り2つは予備。 |
| F | /22 | 2 | 4 | AZ | アベイラビリティゾーン。ここまででサブネットを形成。4AZまで対応しているが事業によっては2AZにして他のセグメントを拡張してもよい。 |
| G | /32 | 10 | 1024 | ホスト | ホストやELB等の資源。 |
- AWSのVPCの制限としてCIDRは/16〜/24なのでA〜Dで1VPCの基底CIDRとする。
- 環境は「共通」とそれ以外は性質が異なり、「共通」以外の各環境は「共通」とVPC peeringで接続する。
- 「共通」以外の各環境は相互に直接通信できない。
- VPNとの接続はPrivateカテゴリのみ許可する（各環境のPrivateカテゴリにVPNが張られる）。
- 外部ELB/踏み台/NATはPublicカテゴリに入れる。
- DBサブネットグループやElasticCacheサブネットグループはA〜Fまでで決まるサブネットを設定する。あまりサブネットを小分けにしすぎない。
- 何らかの事情で自動で勝手に消費されない固定IPアドレス帯が欲しい場合はEのカテゴリを1つ固定IP用として利用する。
- 非AWSの場合、D以降は異なる体系になる可能性が高い。
事業によってはホスト部分（G）は1桁減らして512にしてそれ以外のところを拡張してもよいかもしれない。
この体系を検討するうえで参考にしたのは以下。
図が2あってとても参考になるのだけれど微妙に間違いがあるので注意。
https://www.itcloudarchitect.com/index.php?view=posts&id=169
