クラウドネットワーク

01

クラウドの中に自分のネットワークを作る：仮想ネットワークとIPアドレス範囲

クラウドのデータセンターでは、たくさんの利用者のサーバーが一緒に動いています。それでも、自分のサーバー同士だけが通信でき、ほかの利用者とは切り離されていなければなりません。そこでクラウドは、利用者ごとに論理的に分けられたネットワークを用意します。これを仮想ネットワークと呼びます。物理的なケーブルやスイッチは共有していますが、アドレスもルートもルールも、利用者ごとに別々です。

仮想ネットワークを作るとき、最初に決めるのは、使うIPアドレスの範囲（アドレス範囲）です。ふつうは、インターネットでは使わないと決められているプライベートアドレスの範囲から選びます。プライベートアドレスは、どの会社や家庭で重ねて使ってもかまわないアドレスなので、そのままではインターネットに出られません（どうやって出るのかは3章で見ます）。

CIDR：スラッシュの後ろの数字を読む

IPv4アドレスは32ビットです。10.0.0.0/16は「先頭の16ビット（10.0）は固定し、残りの16ビットをこのネットワークが使う」という意味です。だからアドレスは2^16 = 65,536個になります。/の後ろの数字が大きいほど固定する部分が長くなり、範囲は小さくなります。この書き方をCIDRと呼び、それで表した範囲をCIDRブロックといいます。下の図で、サブネットの大きさを変えてみてください。

仮想ネットワークの範囲は、さらにサブネットに分けます。サブネットは、同じ役割のサーバーをまとめておく区画です。インターネットに見せるWeb層、隠しておくDB層のように役割ごとに分け、サブネットごとに別のルート（2章）やファイアウォール（4章）を設定できます。

サブネットのアドレスは全部は使えない

どのサブネットにも、クラウドがあらかじめ予約しておくアドレスがあります。サブネットの最初のアドレス（ネットワークアドレス）、サブネットの外へ出る出入り口であるゲートウェイ、DNSなどです。いくつ予約するかは、クラウドプロバイダーによって違います。だから/24のサブネットでも、サーバーに割り当てられるアドレスは256個より少し少なくなります。

最初から広めに、重ならないように

アドレス範囲は、作ったあとで変えるのが大変です。サーバーやサービスが増えることを考えて広めに取り、社内ネットワークやほかの仮想ネットワークと重ならないように分けておきます。ここがつまずきやすいところです。社内ネットワークが192.168.0.0/16を使っているのに、クラウドでも同じ範囲を使うと、あとで両方をつなごうとしたとき、どちら側の192.168.1.10なのか区別できず、接続そのものができません（7章）。

範囲を分けてサブネットを作りました。では、サブネットのサーバーが送ったパケットは、どこへ行けばよいのかをどうやって知るのでしょうか。

02

サブネットとルーティング：パブリックとプライベートを分けるもの

サーバーがパケットを送ると、サブネットに関連付けられたルートテーブルが行き先を決めます。ルートテーブルは「この範囲へ向かうパケットは、あの出入り口へ送る」という行の一覧です。仮想ネットワークには「ネットワーク内のアドレスはネットワーク内で届ける」というデフォルトのルートが最初からあるので、サブネット同士は特に設定しなくても通信できます。

宛先              ネクストホップ（送り先）
10.0.0.0/16       ネットワーク内（ローカル）
172.16.0.0/12     VPN接続 → 社内ネットワーク
0.0.0.0/0         インターネットゲートウェイ

ルートテーブルは、パケットの宛先アドレスに一致する行を探し、その行のネクストホップへ送ります。たとえば、Webサーバーが同じネットワークにあるDBサーバー（10.0.2.15）にパケットを送るとしましょう。10.0.2.15は10.0.0.0/16の中のアドレスなので、1行目に一致します。ところが0.0.0.0/0は「すべてのアドレス」なので、最後の行にも一致します。

このように複数の行が一致するときは、いちばん具体的な行、つまり/の後ろの数字が大きい行が勝ちます。これを最長プレフィックス一致といいます。/16は/0より具体的なので、このパケットはネットワークの中で届けられます。一方、インターネット上のWebサイト（203.0.113.10）は最初の2行には一致せず、0.0.0.0/0だけに一致するので、インターネットゲートウェイへ向かいます。そのため0.0.0.0/0は、ほかのどの行にも一致しないアドレスが最後に行き着く先として、デフォルトルートと呼ばれます。下の図で、宛先とサブネットの種類を変えてみてください。

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

インターネットへ向かうルート（0.0.0.0/0 → インターネット）があるサブネットをパブリックサブネット、ないサブネットをプライベートサブネットと呼びます。ここがつまずきやすいところです。決めるのはサブネットに付けた名前ではなく、ルートです。また、パブリックサブネットでも、サーバーがインターネットと直接やり取りするには、サーバーにパブリックIPが必要です。プライベートIPしか持たないサーバーは、パブリックサブネットにあってもインターネットからは見つけられません。

よくあるWebサービスは、次のように分けます。

DBやアプリサーバーをプライベートサブネットに隠しました。でも、セキュリティ更新は受け取らなければならないし、クラウドのストレージサービスにも届く必要があります。インターネットへのルートがないのに、どうやって外に出るのでしょうか。

03

プライベートサブネットから外に出る：NATとプライベートエンドポイント

NAT（ネットワークアドレス変換）は、プライベートなサーバーの代わりに外とやり取りします。サーバーがインターネットにパケットを送ると、NATはパケットの送信元アドレスを自分のパブリックIPに変えて送り出します。応答が戻ってくると、誰が送ったリクエストだったかを覚えていて、正しいサーバーに応答を渡します。

ポイントは方向です。NATが扱うのは、内側から始まった接続だけです。外から始まった接続は、どのサーバー宛てなのかNATにはわからないので、捨てられます。だから「サーバーは更新を受け取れるようにしたいが、インターネットからは接続されないようにしたい」という問題なら、答えはNATです。インターネットからのリクエストを受け付ける必要があるなら、ロードバランサー（5章）か、サーバーのパブリックIPが必要です。

NATはふつう、クラウドが管理してくれるサービスとして使います。自分のサーバーをNATインスタンスにすることもできますが、そのサーバーが止まるとプライベートサブネット全体が外に出られなくなるので、高可用性も保守も自分で面倒を見ることになります。マネージドNATがどこに置かれるか（1つのゾーンか、リージョン全体か）は、プロバイダーによって違います。

インターネットを通らずにクラウドのサービスへ：プライベートエンドポイント

ストレージ、キュー、鍵管理のようなクラウドのマネージドサービスは、ふつうインターネットに公開されたアドレスを持っています。プライベートなサーバーがそのまま呼び出すと、トラフィックはNATを通ってインターネットに出てから戻ってきます。プライベートエンドポイントを使えば、この道のりがネットワークの中で完結します。方式は2つあります。

これでパケットは行き先がわかるようになりました。でも、道があるからといって、誰でも通してよいわけではありません。どのパケットを入れて、どれを止めるかを決める門番が必要です。