Tamanyan.me | たまにゃんのエンジニアブログ

Amazon Virtual Private Cloud (Amazon VPC) は最も基本的なAWSのサービスだが、自由度も高いのでどのように設計をすればよいのか、いつも頭を悩ませる。AWS Single VPC Designを読み込んでベストプラクティスを守るようにする。

ベストプラクティス

ネットワーク設計を考える時に、まず一般的なネットワーク設計原則を確認する。例えば、プライベートネットワークにオーバーラップしないようにサブネットを実装するのが良い。また将来への拡大に備えて、IPアドレススペースを余分に確保しておく事も良い考えだ。VPCは、次のような設計のベストプラクティスに従う必要がある。

  • VPCネットワークレンジ(CIDRブロック)が他のプライベートネットワーク範囲とオーバーラップしないようにする
  • 一度に全てのネットワークアドレスを確保してはいけない、将来に使うことも想定して使えるスペースを残しておく
  • 特定のリージョンのすべてのAvailability Zonesに渡って、ネットワークを分ける
  • それぞれのルーティング要件(public subnets vs private subnets)に応じて、サブネットをAvailability Zones毎に作成する
  • 将来予想されるホストマシンの増加に対して備えるために、 VPCのCIDRとサブネットを適切なサイズで用意する

AWS上のアプリケーション

VPCの設計を考える時、ユーザー、バックエンドシステム、ルーティングの観点からAWSをどのように活用するかを考えて、同様に現在と将来に必要なネットワークサイズを推定する必要がある。ベストプラクティスを守ってさえいれば、ある構成から別の構成に簡単に変える事も可能。例えば、Internet-Accessible VPCにプライベートサブネットを追加することで以下のようなPublic and Privately Routed VPCを作り出す事ができる。しかし、一度作成したVPCとサブネットはリサイズする事はできないという事を覚えておく必要がある。

自分のユースケースに対して適切な構成を選択するには、以下のような条件をもとにデザインパターンを考える。

  • User Access: 誰がネットワークのAWSリソースにアクセスするのか?(内部ユーザー、外部ユーザー?)
  • Systems Access: 他システム(内部、外部、共有)と連携する必要があるか?
  • Routing: それぞれ違った方法でルーティングをするホストが必要か?

これらの条件をもとに以下のデザインパターンを採用する。

Internet-Accessible VPC

パブリックサブネットのみで構成されたVPC。VPC内のAWSリソースは自社が持つ内部システム及び内部ネットワークとの直接的の接続をできないようにする。

Internet-Accessible VPC

Usecase

テスト、R&D、デモ、本番とその他の環境で使われるが、内部ネットワークからは完全に隔離されたネットワークとする。ネットワーク内のAWSリソースが内部へのプライベート通信を持たないようにするケースで適切である。

User Access

VPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)はインターネット越しに利用する。

Systems Access

VPC内のAWSリソースはインターネット上の他のパブリックなシステムへのアクセスが許可される。

Routing

AWSリソースはすべて同じルーティング要件を共有し、インターネットゲートウェイとAWSが提供するインターネット接続を利用する。

Public and Privately Routed VPC

パブリックサブネットとプライベートサブネットで構成されたVPC。NATも使用する事も考える。

Public and Privately Routed VPC

Usecase

このパターンは内部(ブライベート)と外部(パブリット)リソースの両方と通信する必要があるネットワーク構成を作るときに使用される。パブリックとブライベートルーティングの両方に対応する必要があるシステムで最適。例えば、データベース・バックエンドシステムで構築された多層構造Webアプリケーションで有効。

User Access

状況によるが、VPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)はインターネット越しでも内部からでもアクセスできるようにする。

Systems Access

VPC内のAWSリソースは内部・外部システムへのアクセスできるようにし、プライベートネットワーク、インターネット接続を利用できるようにする。

Routing

パブリックサブネットかプライベートサブネットのどちらにAWSリソースを配置するかをグループ分けして、それぞれが適切にルーティングされるようにする。

On-Premises and Internet-Accessible VPC

パブリックサブネットとプライベートサブネットと内部システム(VPN接続)で構成されたVPC。

On-Premises and Internet-Accessible VPC

Usecase

このパターンはオンプレミス(ブライベート)と外部(パブリット)リソースの両方と通信する必要があるネットワーク構成を作るときに使用される。インターネット越しに内部の顧客システム等にアクセスするWebアプリケーションで等有効。

User Access

状況によるが、VPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)はインターネット越しでも内部からでもアクセスできるようにする

Systems Access

VPC内のAWSリソースは内部・外部システムへのアクセスできるようにし、プライベートネットワーク、インターネット接続を利用できるようにする。

Routing

パブリックサブネットかプライベートサブネットのどちらにAWSリソースを配置するかをグループ分けして、それぞれが適切にルーティングされるようにする

Internal-Only VPC

プライベートサブネットと内部システム(VPN接続)で構成されたVPC

Public and Privately Routed VPC

Usecase

バックオフィスシステムのような内部ユーザーからのアクセスのみを想定したケースで有効。

User Access

VPC内にあるAWSリソースにアクセスする際には、全ユーザー(内部・外部)は内部からのみアクセスできるようにする

Systems Access

VPC内のAWSリソースは顧客の内部システムにアクセスできるようにする。

Routing

AWSリソースはすべて同じルーティング要件を共有し、VPNかAWS Direct Connectを利用して顧客の内部システムと通信できるようにする。

VPCのサイジング

VPCのサイズは16アドレス(/28 ネットマスク)から65,536(/16 ネットマスク)まで取る事が可能。VPCのサイズはどの程度リソースが必要になるかに応じて、適切なサイズを決める。

Micro

  • Netmask: /24
  • Subnet Size: /27
  • Hosts/Subnet*: 27
  • Subnets/VPC: 8
  • Total IPs*: 2164

Small

  • Netmask: /21
  • Subnet Size: /24
  • Hosts/Subnet*: 251
  • Subnets/VPC: 8
  • Total IPs*: 2008

Medium

  • Netmask: /19
  • Subnet Size: /22
  • Hosts/Subnet*: 1019
  • Subnets/VPC: 8
  • Total IPs*: 8152

Large

  • Netmask: /18
  • Subnet Size: /21
  • Hosts/Subnet*: 2043
  • Subnets/VPC: 8
  • Total IPs*: 16344

Extra Large

  • Netmask: /16
  • Subnet Size: /20
  • Hosts/Subnet*: 4091
  • Subnets/VPC: 16
  • Total IPs*: 65456

* AWSで事前に予約されたIPアドレスは除外している

例えば以下のWebサイトで192.168.0.0をSmallのVPCサイズで分割してみる。 このように8つのサブネットができたので、後はこれを各Availability Zonesやパブリックサブネット、プライベートサブネットとして振り分けていく。

VPC Size

参考資料


たまにゃん🇹🇭エンジニア
バンコクで働くエンジニア。ex-日本経済新聞社。マーケティングテクノロジーの分野で仕事してます(CRM、データエンジニアリング)。AtCoder緑。Kaggle Expert。データサイエンス・ソフトウェアエンジニアリング・バンコクの事のついて情報発信する。