AWS経験者から見たGoogle CloudとAWSの相違点(ネットワーク)

記事タイトルとURLをコピーする

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。


みずほリサーチ&テクノロジーズ株式会社の舘山です。本日は Amazon Web Services (AWS) 経験者の視点から、オンプレミスとの接続関連で注意が必要な、Google Cloud と AWS の差異について共有します。

当ブログは G-gen × みずほRT によるコラボ記事です

はじめに

当記事の観点

当記事では主にオンプレミスとクラウド環境のネットワーク接続という観点で、Google Cloud と AWS の相違点を紹介します。AWS 経験者が Google Cloud を扱う際に困った部分をピックアップしたため、取り上げる差異の選定にある程度バイアスがかかっている点はご了承ください。

Google Cloud とオンプレミスとの接続の全体像については、以下のブログ記事を参照してください。

また、両クラウドのネットワークの全般的な比較については、以下のブログ記事を参照してください。

関連記事

blog.g-gen.co.jp

blog.g-gen.co.jp

専用線接続を共有できるVPC数

AWS Google Cloud
Direct Connect接続あたりのVIF:50
Direct Connect Gateway毎のVGW:10
50 * 10 = 500
Trangit Gatewayを併用する構成パターンもあり
VLAN アタッチメント数のハードリミット:16
AWSのDirect Connect Gatewayに相当する機能なし
  • AWSのVPCはリージョンに紐づくが、Google CloudのVPCはリージョンを跨ぐ
  • Google Cloudで16を超えるVPCで専用線接続を共用するには、共有VPC又はハブandスポーク構成を採用する

DNSサービスからオンプレミスへのDNSクエリ転送

AWS Google Cloud
接続元IPアドレスとしてサブネットの任意のプライベートIPアドレスを指定可能
(Route53 Resolver Outbound Endpoint利用)
接続元IPアドレスはGoogleが管理するパブリックIPアドレス範囲の
35.199.192.0/19 固定となる
Cloud DNS転送ゾーン利用
  • Google Cloudの場合、オンプレミスNW側がプライベートIPアドレスとして35.199.192.0/19を受入れ可能か確認が必要
    • 受入れができない場合、VPC内にDNSフォワーダを建てるなどの手当が必要
  • 複数VPCから個別にクエリ転送すると送信元IPアドレスが重複してしまう

マネージドRDBMSのネットワークインタフェース配置先

AWS Google Cloud
利用者のVPC 利用者のVPCとピアリングされたGoogle管理のVPC
  • AWSではAmazon RDS、Google CloudではCloud SQLの仕様
  • Google Cloudの場合、VPCピアリングの推移的アクセス制限に注意が必要

VPCピアリングにおける選択的ルート設定可否

AWS Google Cloud
・ルートテーブルのピアリング先VPCへのルートは手動で設定する
ピアリング先VPC内の一部のIPアドレス範囲に限定したルート設定が可能
原則、ルートテーブルにピアリング先VPCの全サブネットへのルートが強制的に自動登録される。例外はプライベートで使用されるパブリック IPv4 アドレス(PUPI)を利用するサブネット
  • 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要

プライベートIPアドレス用のNAT Gateway

AWS Google Cloud
サービスあり サービスなし
(GKEのユースケースでは、IPマスカレードエージェントが利用可能)
  • 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要

専用IPアドレス・サブネット・VPCが必要なユースケース

AWS Google Cloud
比較的少ない 比較的多い
  • Google Cloud では Cloud SQL 等で専用サブネットが必要
  • 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要

VPCへのIPアドレス範囲事前割り当て要否

AWS Google Cloud
・要。VPCのIPアドレス範囲からサブネットのIPアドレス範囲を切り出す
・異なるIPアドレス範囲を利用する場合、VPCにセカンダリCIDRを割り当てる
セカンダリCIDRとして追加できるIPアドレスには制限事項あり
不要。サブネットへ直接IPアドレス範囲を割り当てる
  • 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要

サブネットがゾーンを跨ぐか

AWS Google Cloud
サブネットはAZを跨がない サブネットはゾーンを跨ぐ
  • AWS のサブネットは Availability Zone (AZ) に閉じる
  • Google Cloud のサブネットはゾーンをまたぐ (リージョン単位)

内部HTTPロードバランサの負荷分散方式

AWS Google Cloud
DNSラウンドロビン
ロードバランサの名前解決の都度、複数のIPアドレスが異なる順番で回答される
IPエニーキャスト
ロードバランサへは単一のIPアドレスを利用してアクセスする
  • Google Cloudは、IPアドレスの固定が容易

マネージドRDBMSのフェイルオーバ時のIPアドレス

AWS Google Cloud
フェイルオーバー時IPアドレスが変化する。クライアントの接続先切り替えには、再度の名前解決が必要 フェイルオーバー時、IPアドレスは変化しない
  • AWSではクライアント側のDNSキャッシュに注意が必要

内部HTTPロードバランサへのアクセス制限

AWS Google Cloud
ロードバランサへのアクセスをセキュリティグループで制限することが可能 ロードバランサにファイアウォールルールを適用することは不可能
・2023年1月現在、Cloud Armorで内部HTTPロードバランサを保護することは不可能
  • Google Cloudでプライベートなアプリへの接続にプライベートIPアドレス制限が必要な場合、アプリ側でX-Forwarded-Forヘッダをチェックする等の実装が必要

FaaSからのVPCへのアクセス

AWS Google Cloud
任意のサブネットに関数を紐づけることが可能Google Cloudのコネクタインスタンスに相当するリソースは不要 サーバレスVPCアクセス専用サブネット上のコネクタインスタンスを経由してVPCへアクセスする

舘山 浩之

みずほリサーチ&テクノロジーズ

先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。