VPCとクラウドネットワーク

VPCとクラウドネットワークとは

VPC(Virtual Private Cloud)は、クラウド事業者の設備の中に切り出す自分専用の仮想ネットワーク、つまり「自分だけのIPアドレス空間」です。[[AWS]] では VPC、Google Cloud でも VPC、Azure では Virtual Network と呼ばれ、名前は違ってもどのクラウドにも必ずあります。

物理的には他の利用者と同じ機器を共有していますが、論理的には分離されていて、通信は自分の VPC の中で完結します。物理配線を変えずにネットワークを論理的に区切る、という発想は [[VLAN]] とまったく同じで、VPC はそれをクラウド規模で行うものです。

[[クラウドコンピューティング]] は「サーバーを借りる」話として語られがちですが、実際にはアドレス範囲を決め、区画を切り、どこへ通信を通すかを自分で書くネットワーク設計も引き受けます。

CIDRとサブネット分割

VPC を作るとき最初に決めるのが CIDRブロック、この VPC 全体が使うプライベートIPの範囲です。そこから用途ごとにサブネット(区画)を切り出します。

VPC  10.0.0.0/16 (約6.5万アドレス)
├─ 10.0.1.0/24    AZ-a  パブリック
├─ 10.0.2.0/24    AZ-c  パブリック
├─ 10.0.11.0/24   AZ-a  プライベート
└─ 10.0.12.0/24   AZ-c  プライベート

/16 や /24 の読み方も、10.0.0.0/8 などプライベートIPの予約範囲から選ぶことも [[IPアドレスとサブネット]] のままで、オンプレのネットワーク知識がそのまま再登場します。

サブネットを切るときの注意が3つあります。

1つのサブネットは1つのアベイラビリティゾーン(AZ)に属する — 単一データセンターの障害に備えるなら、同じ役割のサブネットを2つ以上のAZに作る
各サブネットで数個のアドレスがクラウド側に予約される — /24 で実際に使えるのは251個程度。/28 のような小さすぎる区画は後から足りなくなる
VPC の CIDR は後から自由に変えられない — 最初の一手が最も戻しにくい

将来オンプレや別の VPC と接続する可能性を考えると、192.168.0.0/24 のような家庭用ルーターとかぶりやすい範囲は避けたほうが安全です。アドレス範囲が重複したネットワーク同士は、そのままではつなげません。

パブリックサブネットとプライベートサブネット

初学者が最も誤解しやすいのがここです。パブリック/プライベートという専用の種類のサブネットが用意されているわけではありません。違いはルートテーブルのたった1行です。

パブリックサブネット — ルートテーブルに「宛先 0.0.0.0/0 はインターネットゲートウェイへ」という行がある
プライベートサブネット — その行が無い

ルートテーブルは [[ルーティング]] のルーティングテーブルそのもので、デフォルトルートの向き先が違うだけです。

置く場所	代表的な配置
パブリックサブネット	[[ロードバランサ]]、[[踏み台サーバー]]、NATゲートウェイ
プライベートサブネット	アプリケーションサーバー、データベース

この構造が分かると、[[踏み台サーバー]] の「内部サーバーはインターネットから直接触れない場所に置く」が具体的な設定として見えてきます。プライベートサブネットのサーバーにはグローバルIPを振らず、外から名指しで届く経路そのものを作らないからです。

インターネットゲートウェイとNATゲートウェイ

インターネットゲートウェイ — VPC とインターネットをつなぐ出入口。VPC に1つ取り付ける
NATゲートウェイ — プライベートサブネットからの外向き通信だけを通す装置

プライベートに置いたサーバーでも、OS のパッケージ更新や外部APIの呼び出しでインターネットに出る必要はあります。しかし外から入られては困ります。この「出ていけるが、入ってこられない」を実現するのが NATゲートウェイで、原理は [[NATとポートフォワーディング]] の変換表そのものです。表は内側から始めた通信にしか作られないため、外から突然届いたパケットは戻り先が分からず捨てられます。

NATゲートウェイ自体はパブリックサブネットに置き、プライベートサブネットのルートテーブルに「0.0.0.0/0 は NATゲートウェイへ」と書きます。時間課金に加えて転送量でも課金される、学習用に作って消し忘れると高くつく代表格です。

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

VPC の中の通信制御は [[ファイアウォール]] の考え方そのままですが、粒度の違う2つが用意されています。

	セキュリティグループ	ネットワークACL
適用先	サーバー1台ごと	サブネット全体
書けるルール	許可のみ	許可と拒否の両方
通信状態の記憶	ステートフル	ステートレス

決定的なのはステートフルかステートレスかの違いで、[[ファイアウォール]] で扱う区別がそのまま当てはまります。セキュリティグループはステートフルなので、「443番の受信を許可」と1行書けばその応答は自動的に戻れます。ネットワークACLはステートレスなので戻りにも許可が要り、応答が返る一時ポート宛に 1024-65535 を許可する行が別途必要になります。

実務ではセキュリティグループを主役に使い、ネットワークACLは「特定のIPをサブネットごと遮断する」といった用途に絞るのが一般的です。

さらに便利なのが、セキュリティグループのルールで送信元にIPアドレスではなく別のセキュリティグループを指定できる、という性質です。「DB用のグループは、アプリ用のグループからの3306番のみ許可」と書いておけば、[[ロードバランサ]] の下でサーバーが増減してもルールを書き直す必要がありません。

初学者向けポイント

プライベートサブネットのサーバーで apt update が固まる — 定番の原因はNATゲートウェイの不在か、ルートテーブルの書き漏れ。セキュリティグループを疑って時間を溶かしがち
ロードバランサからサーバーに届かない — 受信側のセキュリティグループを確認する。行きを許可すれば戻りは自動で通るので、戻り用のルールを足す必要はない
疎通しないときはルートテーブル → セキュリティグループ → ネットワークACL の順に確認すると切り分けが早い
最初から完璧な設計を目指さず、「/16 の VPC + 2つのAZ × パブリック/プライベートの計4サブネット」という定番構成をまねるところから始めるとよい

関連技術とのつながり

[[クラウドコンピューティング]] — 借りたサーバーを置く土台がVPC。ネットワーク設計もセットで必要になる
[[AWS]] — 主要サービス表に並ぶVPCの中身がこの記事の内容
[[IPアドレスとサブネット]] — CIDR表記とプライベートIPの知識がそのままVPC設計に使われる
[[ファイアウォール]] — セキュリティグループとネットワークACLがクラウドでの実体
[[踏み台サーバー]] — パブリックサブネットに置き、プライベートサブネットへの唯一の入口にする
[[VLAN]] — 「通信できる範囲を論理的に区切る」という同じ発想のオンプレ版

Q: パブリックサブネットとプライベートサブネットの違いはどれ?
- [ ] サブネットを作るときに種類として「パブリック」「プライベート」を選ぶ
- [x] ルートテーブルに「0.0.0.0/0 はインターネットゲートウェイへ」という行があるかどうか
- [ ] 割り当てるCIDRブロックの大きさが違う
解説: サブネットに専用の種類があるわけではなく、デフォルトルートの向き先がインターネットゲートウェイかどうかだけが違いです。

Q: NATゲートウェイの役割として本文の説明に合うのはどれ?
- [x] プライベートサブネットからの外向き通信だけを通し、外からの接続は通さない
- [ ] インターネットからプライベートサブネットへ直接接続できるようにする
- [ ] 複数のサーバーへリクエストを均等に振り分ける
解説: 変換表は内側から始めた通信にしか作られないため、外から突然届いたパケットは戻り先が分からず捨てられます。振り分けはロードバランサの役割です。

Q: セキュリティグループとネットワークACLの違いとして正しいのはどれ?
- [ ] どちらもステートレスで、戻りの通信を必ず明示的に許可する必要がある
- [ ] セキュリティグループはサブネット全体、ネットワークACLはサーバー1台ごとに適用される
- [x] セキュリティグループはステートフルで応答が自動的に戻れるが、ネットワークACLはステートレスで戻りの許可が別途必要
解説: 適用先も逆で、セキュリティグループはサーバー1台ごと、ネットワークACLはサブネット全体に効きます。