AWS経験者がGoogle Cloudのネットワークを触る前に知っておくとよさそうなこと
TL;DR
- サブネットは AZ 単位ではなく Region 単位で作成
- ルートテーブルはサブネット単位で作成できず VPC 単位
- VPC 内のパブリックサブネット・プライベートサブネットといった概念がない（が、相当する要件のものは作れる）
- NAT の利用には Cloud NAT を使うが Cloud Router も別途必要
- Google CloudのVPCを基礎から始める がとても分かりやすくまとめられており勉強になりました
サブネットは AZ 単位ではなく Region 単位で作成
AWS だと AZ（Availability Zone）ごとにサブネットを作成する必要がある。Google Cloud だと Region 単位で作成する。AZ を跨ぐ形でサブネットが作成されるイメージ。Region にサブネットを1つ作成することで実質複数 AZ を跨いで冗長構成が組める。
サブネットはリージョン リソースであり、IP アドレス範囲が関連付けられています。
雑なイメージだと下記。
雑なイメージ
ルートテーブルはサブネット単位で作成できず VPC 単位
AWS だとサブネット単位でルートテーブルの作成が可能。Google Cloud だとサブネット単位のルートテーブルの作成は不可で、 VPC 内に1つのルートテーブルが存在し、VPC 内の全てのサブネットのルーティングも担うという構成になる。
ルートを個別に適用することもできますが、VPC ネットワークのルーティング テーブルが VPC ネットワーク レベルで定義されています。
雑なイメージだと下記。
雑なイメージ
VPC 内のパブリックサブネット・プライベートサブネットといった概念がない
要件として VPC 内に AWS でいうところのパブリックサブネット・プライベートサブネットに相当するものを構築することはできるが、それらを明確に位置付ける概念として定義されているものはなさそう。
AWS だと下記のように明確な区分けと定義が存在する。
サブネットタイプ
サブネットのタイプは、サブネットのルーティングの設定方法により決まります。例:
パブリックサブネット – サブネットには、インターネットゲートウェイへの直接ルートがあります。パブリックサブネット内のリソースは、パブリックインターネットにアクセスできます。
プライベートサブネット – サブネットには、インターネットゲートウェイへの直接ルートがありません。プライベートサブネット内のリソースには、パブリックインターネットへのアクセス用に NAT デバイスが必要です。
Google Cloud のドキュメントにおいて AWS のように言及した内容は見当たらない。
また、前述したように「ルートテーブルはサブネット単位で作成できず VPC で1つ」という仕様から、同 VPC において「172.16.0.0/24 のサブネットは 0.0.0.0 の宛先をデフォルトインターネットゲートウェイ経由でインターネットへ」、「172.16.1.0/24 のサブネットは 0.0.0.0 の宛先を NAT 経由でインターネットへ」といった設定を VPC に設置された単一のルートテーブル上で設定することは不可。ただ、ここで誤解するとマズそうなのが「同 VPC 内でインターネットゲートウェイと NAT へのトラフィックを分けられないというわけではない」ということ。ルートテーブル上で直接 NAT へのルーティング設定ができないということであり、NAT 側の設定からは特定のサブネットからのトラフィックをルーティングする設定は行える。
そもそも Google Cloud の NAT（Cloud NAT）では、デフォルトだと全サブネットの IP レンジに対して機能する。その上で IP レンジを指定するといった設定も可能（※併せてルートテーブル上でネクストホップがインターネットゲートウェイとなるようなルーティング設定も必要）。
NAT のサブネット範囲を指定する
デフォルトでは、特定の VPC ネットワークのリージョン内で、すべてのサブネットのすべてのプライマリ IP 範囲とセカンダリ IP 範囲に対して NAT が機能します。NAT を使用できるプライマリおよびセカンダリ サブネット範囲を制限できます。
Google Cloud - Public NAT でネットワーク アドレス変換を設定、管理する
Public NATゲートウェイは、ネクストホップがデフォルトのインターネット ゲートウェイであるルートのみを使用できます。
Google Cloud - Cloud NAT プロダクトの相互作用
なので、172.16.1.0/24 の サブネット に関して NAT 経由でインターネットへ通信したいといった場合は Cloud NAT の設定で IP レンジを指定すると良いということになる。
上記の例の場合、ルートテーブル上の設定だと、172.16.0.0/24 と 172.16.1.0/24 のネクストホップが共にインターネットゲートウェイを指しそうな印象だが、172.16.1.0/24 の方は Cloud Router（※後述）という NAT のルーティングを司るマネージドサービス側の設定でルーティングがコントロールされ、NAT を経由するようになっている？ということになる（詳しい挙動はワカラナイ）。
なので上記を諸々踏まえ、概念としてはパブリックサブネット・プライベートサブネットといったものはないが、要件上満たすものは作れるという見解。
雑なイメージだと下記。
雑なイメージ
（おまけ）Cloud NAT の利用に伴い Cloud Router が必要
NAT を利用する場合は Cloud NAT というマネージドサービスを使う。
Cloud NAT を利用するにあたり、Cloud Router というものが必要になる。Cloud Router は動的ルーティングを提供するマネージドサービスのようだが、Cloud NAT 利用時のコントロールプレーンとしても機能すると記載してあることから NAT におけるルーティング情報等を包括的に管理しているもの捉えてよさそう。基本的に外部ネットワークにルートを Advertise する細かい設定などが不要であれば特に設定する内容はなく、ただ作成して設置しておくだけで良いという印象。
Cloud Router は、Border Gateway Protocol（BGP）を使用して IP プレフィックスをアドバタイズする、完全分散型のマネージド Google Cloud サービスです。ピアから受信する BGP アドバタイズに基づいて動的ルートをプログラムします。物理デバイスまたはアプライアンスの代わりに、各 Cloud Router が BGP スピーカーおよびレスポンダーとして機能するソフトウェア タスクで構成されます。Cloud Router は、Cloud NAT のコントロール プレーンとしても機能します。Cloud Router は、次の Google Cloud プロダクトに BGP サービスを提供します。
Google Cloud - Cloud Router の概要
感想
ネットワークに限らず AWS を経験してから Google Cloud を経験する際に、思想やアーキテクチャが異なることは珍しくないため事前に知っておくと構築時の理解が速くなりそうなポイントを少し掻い摘んでまとめてみた。どちらが優れているかという話ではなく、それぞれメリデメやトレードオフの部分があると思うので好みや運用に合っているかなどを加味した上で判断していきたい。
Discussion