AWSで読み替えるGoogle Cloud入門

これは豆蔵デベロッパーサイトアドベントカレンダー2025第12日目の記事です。

ビジネスソリューション事業部の塚野です。現在、私がアサインされている案件ではパブリッククラウドとして Google Cloud を利用しています。
もともとは AWS を業務や個人開発で使っており、インフラ構成もサービス選定も「AWS の考え方」を土台にしてきました。しかし案件アサインに際し Google Cloud を本格的に学びはじめ、その設計思想やネットワークモデルが AWS と大きく異なることに気づきました。
キャッチアップの際には、AWS の常識をそのまま Google Cloud に当てはめて混乱した経験があり、両者を横並びで比較した体系的な資料が欲しいと強く感じました。

そこで本記事では、AWS 上に用意したシンプルなデモアプリケーションを題材にしながら、
「同じ構成を Google Cloud で実現するとどうなるのか？」
という観点で、Google Cloud のプロダクトや設計思想を AWS と比較しながら紹介していければと思います。
また、本記事では AWS ユーザーを対象とし、AWS ユーザーが Google Cloud を理解する際の指針になることを目指すため、AWS 各サービスの説明は行いません。

本記事で考えるデモアプリは、簡単な ToDo アプリであるとします。
典型的な三層 Web アプリケーションに、非構造化データを保存するためのオブジェクトストレージを加えた構成です。

フロントエンドには Next / Nuxt の SSR（Server-Side Rendering） を採用し、
フロントエンドとバックエンド API を同一サーバー上でホストできる構成とします。

• フロントエンド： Next / Nuxt などで構築された Web UI（SSR によりサーバー側でレンダリング）
• バックエンド API：タスクの CRUD を提供する REST API
• 永続化層：RDBMS（ユーザー・タスク・プロジェクトなどのデータ）
• ファイルストレージ：ユーザーがアップロードするアイコン画像や添付ファイルなどを保存

本記事では AWS と Google Cloud の比較のためごく簡単なアプリケーションを題材とします。そのため高度な機械学習（Google Cloud の強みはここもあったりしますが）、メッセージング、DNS、イベント駆動アーキテクチャなどは含めず、

• ネットワーキング
• コンピューティング
• データベース
• オブジェクトストレージ

といったクラウドの基本要素にフォーカスしています。
また、実運用で考えるべきマルチAZ（マルチゾーン）やマルチリージョンな冗長化構成についても考慮しません。

まずは AWS でのデモアプリの構成です。

アプリを構築するリージョンは東京リージョン（ap-northeast-1）とします。
リージョン内にVPCを1つ作成し、VPC 内には AZ を1つ含めます。
その AZ 内にパブリックサブネットとプライベートサブネットを配置します。
さらに、Next / Nuxt の SSR やバックエンド API をホストするためのコンピューティングサービスとして EC2 をプライベートサブネット内に配置し、Auto Scaling グループを構成します。

パブリックサブネットには Application Load Balancer（ALB） を配置し、
インターネットからのトラフィックを Auto Scaling グループへルーティングします。
永続化層には、EC2 と同じプライベートサブネット内に
Amazon RDS（MySQL / PostgreSQL） を配置します。

ユーザーアップロード用のファイルは Amazon S3 バケット に保存し、
プライベートサブネット内の EC2 から S3 にアクセスします。

なお、実際には次のようなネットワーク構成が必要です

• EC2 の外向き（Outbound）通信には NAT Gateway が必要
• EC2 から S3 を安全に利用するには VPC エンドポイント（Gateway Endpoint for S3）が必要

ですが今回は構成をシンプルに保つため図からは省略しています。
また、NAT Gateway は個人利用ではコストがかかるため、EC2 をパブリックサブネットに置く構成も現実的です。しかし、AWS と Google Cloud の比較を明確にするため、本記事では EC2 をプライベートに置く構成としています。

続いて、同じデモアプリケーションを Google Cloud 上で構成した場合を見ていきます。

見た目は AWS よりもスッキリしています。
VPC やロードバランサなど、AWS でもよく見かけるリソース名が Google Cloud にも登場しますが、その配置のされ方を見ると 「おや？」 と感じる部分があるかもしれません。

この違いこそが、AWS と Google Cloud の思想的な差分であり、
以降の章ではこれらのリソースの役割や設計上の特徴を詳しく比較していきます。

まずはネットワークリソースから見ていきます。
ここで扱うのは以下のリソースです。

• VPC
• サブネットとゾーン
• ロードバランサ

まず、AWS と Google Cloud で大きく異なるのが VPC のスコープです。
AWS では VPC はリージョンに紐づくリージョナルリソースです。
AZ をまたいでの構成は可能ですが、リージョンをまたいで1つの VPC の構成はできません。
一方、Google Cloud では VPC はグローバルリソースです。
そのため、1つの VPC の中に複数リージョンを含めることができ、AWS と比べてマルチリージョンなネットワークを容易に構成できます。

AWS と比較したときの Google Cloud の大きな特徴として、グローバルリソースを前提にした設計思想があります。
Google Cloud はまず グローバルな VPC を作成し、その中でリージョンやAWSのAZに当たるゾーンといったパーティションを切っていくというトップダウンの構成をとります。
一方 AWS は VPC をリージョンごとに作成し、必要があればリージョン間を接続してマルチリージョン化します。つまりリージョンを基本単位としたボトムアップ型のアプローチです。
この設計思想の違いこそが、AWS ユーザーが Google Cloud に触れたときに最初に戸惑うポイントといえます。

次に、サブネットとゾーンの扱いについて触れます。
Google Cloud では、作成した VPC に対してサブネットを追加しますが、AWS と異なりサブネットはリージョン単位のリソースです。
AWS のようにサブネット＝AZ 単位ではありません。
さらに、Google Cloud のサブネットにはパブリック／プライベートの区別がありません。
サブネットに割り当てるルート（デフォルトルートをインターネットゲートウェイに向けるかどうか）と、ファイアウォールルールによってパブリック／プライベートの性質が決まります。
また、「ゾーン」は、Google Cloud における AWS の AZ に相当する最小単位のデータセンター群です。
AWS 同様リージョンを分ける単位として機能しますが、サブネットがどこに紐づくかが異なります。
AWSの場合、サブネットは AZ 単位で作られますが、Google Cloudの場合、逆にサブネット内にゾーンが存在します。

以上Google Cloud の構成を整理すると、次のようになります。

• サブネットはリージョン全体に広がるため、リージョン内のすべてのゾーンから利用可能
• アプリケーションをデプロイするゾーンはサブネット内で選択する
• パブリック／プライベートの区別はルートとファイアウォールで制御する

このため、AWS の AZ ごとにサブネットを作り冗長化するモデルに比べ、
Google Cloud はサブネット構成がシンプルで、ゾーン冗長を実現しやすいのが特徴です。

ロードバランサ（LB）の設計思想も AWS と Google Cloud で異なります。
ここではL7のLBのみ言及します。AWSにおけるL7 LB はALBですが、これはリージョンリソースで各リージョンごとにエンドポイントが異なります。
したがって、グローバルに公開したい場合は Route 53 や CloudFront を併用する必要があります。
一方、Google CloudにおけるL7 LBは 外部 HTTP(S) ロードバランサです。これにもいろいろ種類があるのですが^[1]デフォルトではこちらもVPCと同じくグローバルリソースです。
AWS でグローバル LB を構成しようとすると複数サービスを組み合わせる必要がありますが、
Google Cloud では LB 単体でグローバル公開ができる点が大きな違いです。

なお、インターネット接続の扱いも AWS と Google Cloud では少し異なります。
AWS では VPC を外部に公開するために Internet Gateway（IGW）を明示的に作成し、パブリックサブネットのルートテーブルに紐づける必要があります。一方、Google Cloud では IGW に相当するリソースをユーザーが直接意識することなく、外部 HTTP(S) ロードバランサ などの外部向けリソースを作成すると、自動的に Google のエッジネットワークがインターネットとの入口として機能します。

そのため、Google Cloud では「どこをインターネットに公開するか」を細かいネットワーク構成として指定することが少なく、AWS に比べて抽象度が高いという特徴があります。

ここまでを踏まえると、デモアプリのネットワーク構成は以下のようになります。

• グローバルリソースとして VPC を1つ作成し、その中に東京リージョン（asia-northeast1）を含める。
• 東京リージョン内にリージョンサブネットを作成する。
• リージョンサブネット内の特定のゾーン内（今回の場合はゾーンA）にコンピューティングやDBを配置する
• L7 LBはグローバルリソースとして配置する

Google Cloudのネットワーク構成図

続けて、コンピューティングサービスについて見ていきます。
アプリケーションを実際に実行するサーバーをどのように冗長化し、スケールさせるかは AWS と Google Cloud の大きな比較ポイントの一つです。

AWS では、EC2 インスタンスでフロント/バックエンドサーバーをホストし、EC2インスタンスを Auto Scaling グループに配置しています。これにより、一定条件下でインスタンス数を自動的に増減させることが可能です。

Google Cloud において EC2 にあたるコンピューティングサービスとして Google Compute Engine（GCE） があります。
GCE でも EC2 と同様に仮想マシンを利用してアプリケーションをホストしますが、スケーリングや冗長化の仕組みが少し異なります。Google Cloud では、GCE インスタンスを Managed Instance Group（MIG） にまとめることで、スケールイン/アウトや自己修復などを自動化できます。
ここで AWS と比べて特徴的なのは、Google Cloud では MIG をリージョン単位で作成できるという点です。
AWS の Auto Scaling グループが複数 AZ にまたがることで高可用性を実現するのと似ていますが、MIG は「リージョン MIG」として構成することで、リージョン内の複数ゾーンにコンピューティングリソースが自動的に分散配置されます。
これは前章で触れた「サブネットがリージョン単位」である Google Cloud のネットワーク設計にも関わっています。

AZをまたがるように配置可能なAWSのAuto Scalingグループ（左）とリージョン単位で作成可能なGoogle Cloud リージョナルMIG（右）

今回のデモアプリでは構成をシンプルに保つため、GCE インスタンスは asia-northeast1 の中の 1 つのゾーン（例：asia-northeast1-a）に配置しています。しかし実運用を想定する場合は、リージョン MIG を使って複数ゾーンにまたがって配置するのが定石です。複数ゾーンにまたがることで単一ゾーン障害に対する耐性を持たせることができます。

また、AWS の Auto Scaling グループと異なり、Google Cloud の MIG は GCE インスタンスのひな形となるインスタンステンプレートのバージョニングや、ローリングアップデートといったデプロイメントに関する機能も標準で備えています。このため、MIG は単なるスケーリングの仕組みではなく、インフラ管理の一部を抽象化してくれる存在でもあります。

お次はデモアプリで利用するデータベースとストレージについて見ていきます。

デモアプリでは、ユーザーやタスクを保存するための RDB と、ユーザーがアップロードする画像ファイルなどを保存するオブジェクトストレージを利用しています。AWS では、RDB には Amazon RDS を、ストレージには Amazon S3 を利用しています。EC2 で動くアプリケーションは、プライベートサブネットの内部から RDS に接続し、ユーザーがアップロードしたファイルを S3 に保存します。

一方、Google Cloud で同じアプリケーションを構築する場合、対応するプロダクトは Cloud SQL と Cloud Storage になります。Cloud SQL は MySQL や PostgreSQL をマネージドで提供するサービスで^[2]、Cloud Storage は S3 と同様にオブジェクトストレージとして利用できます。ここまでは AWS とさほど大きな違いはありませんが、ネットワーク構成に踏み込むと、Google Cloud らしい特徴が見えてきます。

まずは DB サービスの比較です。RDS が VPC 内のサブネットにインスタンスを持つのに対し、Cloud SQL のインスタンスは VPC 内には存在しません。Cloud SQL は Google の管理ネットワーク内にあり、GCE などからアクセスする場合は Private Service Connect（PSC） を介してプライベート接続を行います。Cloud SQL 自体はサブネットを持たず、PSC を通じて「VPC 内にプライベートアクセス用の入口だけを作る」という方式です。つまり、見かけ上サブネットにインスタンスが配置されているかのように隠蔽されているということです。RDS のように冗長化構成をとる場合にも、レプリカをどのサブネットに置くかといった細かいネットワーク設計を行わず、リージョンの指定のみで冗長化・レプリカ配置は Google がよしなにやってくれます。
この、Cloud SQL は内部構造がユーザーに隠蔽されている点や、冗長化方式の抽象化という観点では、AWS の Amazon Aurora に近い部分もあります。しかし、個人開発や小規模アプリではコストメリットの観点から RDS がまず選択肢となること、Amazon Aurora は多機能であるため純粋な RDB サービスの比較として本記事では RDS を対象としています。

Amazon RDS はサブネットに配置され（左）、Cloud SQL インスタンスの実体はサブネットにはなくGoogleによって管理される（右）

オブジェクトストレージについても似た特徴があります。AWS の場合、EC2 がプライベートサブネットにある場合は NAT Gateway または S3 用の VPC エンドポイント（Gateway Endpoint）を明示的に用意して、外向きトラフィックをどう流すかを設計する必要があります。一方、Google Cloud の Cloud Storage では、特別な設定をしなくても VPC 内から Cloud Storage へプライベート接続できる仕組みが整っています。内部的には Google のバックボーンネットワークを経由して通信が完結するため、インターネットを経由せずに安全かつ高速にアクセスができます。

こうした差異から見えてくるのは、AWS と Google Cloud のネットワーク設計に対する考え方の違いです。AWS では、利用者がネットワークの経路やセキュリティを比較的細かく指定することが前提となっており、VPC・サブネット・NAT・VPC エンドポイントといった多くのリソースを組み合わせる必要があります。対して Google Cloud は、Google 自身が世界規模で運用してきたネットワークを前提とし、ユーザーが意識しなくても安全で効率的な通信が成立するように抽象化されています。結果として、アプリケーション開発者は「どのネットワーク経路を通すか」よりも「どのサービスを使うか」に集中しやすくなります。

今回、同じデモアプリを題材に AWS と Google Cloud のアーキテクチャを比較してみました。

Google Cloud は、VPC やロードバランサがグローバルであるように、グローバルなネットワークや抽象化を前提としたクラウドです。Cloud SQL のように内部構造をユーザーに見せず、シンプルな設定だけで安全に利用できるサービスが多いため、構成は AWS よりもスッキリまとまります。ただし、抽象化が強いぶん「どこからどこまでが自分の設計領域か」が直感的に理解しづらい場面もあります。

一方 AWS は、VPC・サブネット・AZ といった ネットワーク境界が明確で、ボトムアップで積み上げる構成を取りやすい のが特徴です。インターネット接続やプライベートアクセスをユーザーが明示的に選択できるため、要件に応じて細かくコントロールできる点は大きな利点です。筆者としても、この「スコープが見えやすい構造」は理解しやすく、設計上の安心感があります。

どちらが優れているという話ではなく、Google Cloud はシンプルで抽象化されたモデル、AWS は構造が明確でコントロールしやすいモデルという違いがあります。
どちらのクラウドもそれぞれの強みがあり、アプリケーションの規模や要件に応じて最適解は変わります。本記事が、AWS を使っている読者が Google Cloud を理解するきっかけになれば幸いです。