トップ > Virtual Private Cloud (VPC) > AWS経験者から見たGoogle CloudとAWSの相違点(外部接続統制)

AWS経験者から見たGoogle CloudとAWSの相違点(外部接続統制)

Virtual Private Cloud (VPC) Google Cloud AWSとの比較・連携 G-gen・みずほRTコラボ
記事タイトルとURLをコピーする

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

みずほリサーチ&テクノロジーズ株式会社の舘山です。本日は Amazon Web Services (AWS) 経験者の視点から、ネットワークレイヤでの外部接続について、Google Cloud と AWS の差異について共有します。

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

はじめに

当記事の観点

当記事では、クラウド環境のネットワークレイヤでの外部接続という観点で、Google Cloud と AWS の相違点を紹介します。

ここでいう外部接続とは、インターネットとの接続のほかに、オンプレミスとの接続や他のクラウド環境との接続を含みます。自社の資産を安全に保管するために、クラウド環境の外部接続を適切に制御する必要があります。

関連記事

blog.g-gen.co.jp

blog.g-gen.co.jp

インターネットGatewayの削除可否

AWS Google Cloud
削除可能 削除不可能
  • AWSではアカウント払い出し時にインターネットGatewayを削除し、開発者からインターネットGatewy作成権限を剥奪するだけで、外部接続制限が可能なケースが多いです。

外部HTTPロードバランサーの通信経路

AWS Google Cloud
・外部ロードバランサー自体のノードは利用者のVPC内に配置される
・ルートテーブルにインターネットGatewayへの経路がなければ、開発者が外部ロードバランサを作成できても、インターネットからの通信は不可能		 ・外部ロードバランサ自体のノードは、VPC外のGoogleフロントエンドに配置される
・利用者のVPCのルートテーブル上、Ｇoogleフロントエンドとの経路は暗黙的に存在し、削除、上書き不可能
・GoogleフロントエンドのIP範囲は、内部ロードバランサのヘルスチェックの送信元IP範囲でもあるため、ファイアウォールルールでアクセス制限をかけると、内部ロードバランサの利用に支障が出る
  • AWSのApplication Load BalancerとGoogle Cloudのリージョン外部HTTPロードバランサーを比較しています。
  • Googleフロントエンドからの通信をファイアウォールルールで拒否すると、内部ロードバランサのヘルスチェックも疎通不可になります。
  • Google Cloudでの外部ロードバランサの利用制限はファイアウォールルールではなく、後述する組織ポリシーで実施します（関連記事参照）。
  • 構成図で表すと以下のようになります。

Application Load Balancerへのアクセス経路

リージョン外部HTTPロードバランサーへのアクセス経路

マネージドRDBMS等のパブリックIPアドレス宛通信の経路

AWS Google Cloud
・DBインスタンスのネットワークインタフェースは利用者のVPCに配置される
・インターネットからの通信は、利用者のVPCのインターネットGatewayを経由する
・ルートテーブルにインターネットGatewayへの経路がなければ、開発者がDBインスタンスにパブリックIPアドレスを付与できても、インターネットからの通信は不可能		 ・DBインスタンスのネットワークインタフェースは利用者のVPCとピアリングされた、Google管理のVPCに配置される
・インターネットからの通信は、利用者のVPCを経由しない
  • AWSのRDSとGoogle CloudのCloud SQLを比較しています。
  • Cloud SQLインスタンスは利用者のVPCとピアリング接続されたGoogle管理VPCに配置されます。
  • Google Cloudでのインターネット接続制限は後述する組織ポリシーで実施します（関連記事参照）。
  • 構成図で表すと以下のようになります。

RDS DBインスタンスへのアクセス経路

Cloud SQLインスタンスへのアクセス経路

FaaS（Lambda/Cloud Functions）のVPC接続

AWS Google Cloud
・任意のサブネットにLambda関数を紐づけることが可能
・VPCに紐づいた関数の全通信はVPCを経由する
・IAM条件でVPCに紐づく関数に限定した権限移譲が可能
・Google Cloudのコネクタインスタンスに相当するリソースは不要		 ・サーバレスVPCアクセス専用サブネット上のコネクタインスタンスを経由してVPCへアクセスする
・サーバレスVPCアクセスのデフォルト設定では、パブリックIPアドレス宛通信はVPCを経由しない
・IAM条件ではサーバレスVPCアクセスの利用を強制できない
  • Google Cloudでのインターネット接続統制は後述する組織ポリシーで実施します（関連記事参照）。
  • Google Cloudではコネクタインスタンスの稼働料金を考慮する必要があります。

FaaS(Lambda/Cloud Functions)のデプロイに、ユーザーのCode Build/Cloud Build環境が利用されるか

AWS Google Cloud
・ユーザーアカウントのCode Build環境は利用されない ・ユーザープロジェクトのCloud Build環境が利用される

内部ネットワーク経由のAPI呼び出し

AWS Google Cloud
・VPCエンドポイントを利用する
・エンドポイントはサービス毎に作成する
・外部アカウントへの接続は、VPCエンドポイントポリシーで制御する		 ・限定公開のGoogleアクセス、Private Service Connectを利用する
・外部プロジェクトへの接続は、VPC Service Controlsで制御する
  • VPC Service Controlsはサービス間連携機能による間接的なデータ持ち出しの予防も可能です。

プライベートリポジトリ経由でのパブリックリポジトリの参照

AWS Google Cloud
・Code Artifact経由で、npmレジストリ、PyPI、Maven Central等にアクセスが可能
・ECR プルスルーキャッシュリポジトリは、Dockerイメージの初回プル時、VPCからインターネット経由で外部リポジトリ（ECR Public、Quay）へアクセスが必要		 ・(2023/03/31現在プレビュー)Artifact Registryリモート リポジトリ経由でDocker Hub、Maven Central、npmレジストリ、PyPIへアクセスが可能
  • VPCエンドポイント/限定公開のGoogleアクセス、Private Service Connectを併用することで、インターネット接続不可のVPCでも間接的にパブリックリポジトリを参照できます。

通信先ドメインのホワイトリストによる通信制御

AWS Google Cloud
・AWS Network Firewallで、Hostヘッダ、SNI拡張のserver_nameの値をチェックする ・（2023/03現在プレビュー）ファイアウォールポリシーFQDNオブジェクトで、通信の宛先IPアドレスをチェックする

DNSサービスから外部ネームサーバへのクエリ制限

AWS Google Cloud
・Route 53 Resolver DNS Firewallを利用する ・Cloud DNSレスポンスポリシーを利用する
参考サイト：
Protecting from DNS exfiltration in GCP

舘山 浩之

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

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