NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ
    トップ > クラウド > AWS経験者が知るべきGoogle Cloudネットワークの基本思想と主要サービス比較

    AWS経験者が知るべきGoogle Cloudネットワークの基本思想と主要サービス比較

    クラウド Google Cloud AWS 比較記事 ネットワークウィーク

    本記事は  ネットワークウィーク  4日目の記事です。
    💻  3日目  â–¶â–¶ æœ¬è¨˜äº‹ â–¶â–¶  5日目  ðŸŒ

    はじめに

    クラウド事業推進部の小野内です。ネットコムに入社して、もうすぐ3年半となります。
    多くのインフラエンジニアにとって、AWSのネットワーク構成はもはや共通言語と言っても過言ではないでしょう。VPC、サブネット、セキュリティグループといったコンポーネントを組み合わせて、要件に合わせたネットワークを設計するのはおなじみの作業かと思います。

    しかし、いざGoogle Cloudを触ってみると、同じ「VPC」という名前でもその挙動が大きく異なり、戸惑った経験はないでしょうか？ 私も最初は「サブネットがアベイラビリティゾーンをまたいでいる？」「ファイアウォールをインスタンスに直接紐付けない？」など、AWSの常識が通用しない部分で多くの気づきや学びがありました。

    この記事では、AWSでのネットワーク構築経験を持つエンジニアがGoogle Cloudを学ぶ際に、単なる機能の横比較だけでなく、その背景にある「設計思想の違い」にフォーカスを当てて解説します。この思想の違いを理解することが、Google Cloudネットワークをスムーズに習得するための最短ルートだと考えています。

    対象読者

    • AWSでのネットワーク（VPC, Subnet, Security Groupなど）の設計・構築経験がある方
    • これからGoogle Cloudを学び始める、または学び始めたインフラエンジニアの方
    • AWSとGoogle Cloudのネットワークにおける、具体的なサービスの違いと設計思想の違いを体系的に理解したい方

    この記事で伝えたいこと

    • Google Cloudネットワークの根底にある「グローバル」という思想と、それがもたらす具体的なメリット
    • AWSの知識を活かしつつ、Google Cloudの各サービスをどう置き換えて理解すればよいか
    • AWS経験者がGoogle Cloudネットワークを学ぶ上でハマりやすいポイントとその考え方

    すべての基本：AWSとGoogle Cloudの「思想の壁」

    Google Cloudネットワークを理解する上で、最初に乗り越えるべき最も大きな「思想の壁」は、リソースのスコープに対する考え方です。

    • AWS：リージョン中心（Regional First）
      • VPCをはじめ、ほとんどのリソースはリージョンに閉じています。可用性を高めるためには、アベイラビリティゾーンを意識した設計が必須です。これは、障害の影響範囲を限定し、各地域で独立した堅牢なシステムを構築する思想に基づいています。
    • Google Cloud：グローバル中心（Global First）
      • VPCやロードバランサなど、多くのサービスがグローバルリソースとして提供されます。Googleが持つ強靭なグローバルバックボーンネットワークをユーザーが最大限活用できるように、という思想が根底にあります。リージョンやゾーンは、リソースを物理的にどこに配置するかの単位として存在します。

    この違いを念頭に置くと、各サービスの仕様の違いが「なぜそうなっているのか」の理解が深まります。

    主要サービス比較：AWSの知識をGoogle Cloudに置き換えて理解する

    それでは、具体的なサービスを比較しながら、AWSの知識をGoogle Cloudの概念に置き換えて理解していきましょう。

    1. 仮想ネットワーク (VPC)

    比較項目 AWS Google Cloud
    スコープ リージョン グローバル
    リージョン間通信 VPCピアリング等で明示的に接続 デフォルトで可能

    AWSではおなじみのリージョン単位のVPCですが、Google CloudではVPCはグローバルリソースです。 これは、東京リージョン（asia-northeast1）と大阪リージョン（asia-northeast2）の仮想マシンが、デフォルトで同じVPC内のプライベートIPアドレスで通信できることを意味します。このおかげで、リージョンをまたいだサービスのデプロイやDR（ディザスタリカバリ）構成の設計が劇的にシンプルになります。

    【公式ドキュメント】 Google Cloud: Virtual Private Cloud (VPC) network overview

    2. サブネット

    比較項目 AWS Google Cloud
    スコープ アベイラビリティゾーン リージョン
    冗長化構成 複数AZにSubnetを作成 単一Subnetで複数ZoneにVM配置

    AWS経験者が次に驚くのがサブネットの仕様です。AWSではサブネットは必ず単一のAZに紐付きますが、Google Cloudのサブネットはリージョンに紐付きます。

    これはつまり、asia-northeast1リージョンにサブネットを1つ作成すれば、そのサブネットのIPアドレス範囲から、asia-northeast1-a, -b, -c いずれのゾーンにも仮想マシンを作成できるということです。AZごとにサブネットのCIDRを設計する必要がないため、IPアドレス管理が非常にシンプルになり、リソース配置の柔軟性が格段に向上します。

    【公式ドキュメント】 Google Cloud: Subnets overview | Virtual Private Cloud

    3. ファイアウォール

    比較項目 AWS Google Cloud
    適用単位 インスタンス (Security Group) タグ / サービスアカウント
    拒否ルール SGでは不可, NACLで可 可能 (優先度で制御)

    AWSではインスタンスに直接セキュリティグループをアタッチしますが、Google CloudのVPCファイアウォールルールは、インスタンスに付けた「ネットワークタグ」や「サービスアカウント」をターゲットとして適用します。

    例えば、「web-server」というタグを持つ全てのインスタンスに対して「TCP:443を許可する」というルールを1つ定義するだけです。これにより、インスタンスの増減や入れ替えが発生しても、ルールを都度変更する必要がありません。インフラの構成管理（IaC）との相性が非常に良い設計と言えます。

    【公式ドキュメント】 Google Cloud: VPC firewall rules overview

    4. ロードバランサ + CDN

    比較項目 AWS Google Cloud
    グローバルLB Route 53等を組み合わせ実現 単一サービスで提供
    CDN連携 CloudFrontを別途設定 LBのチェックボックスで有効化

    Google Cloudの「グローバル外部HTTP(S)ロードバランサ」は、Google Cloudネットワークの強みを象徴するサービスです。 このロードバランサを作成すると、世界中で単一のエニーキャストIPアドレスが提供されます。ユーザーがどこからアクセスしても、Googleのネットワークが自動的に最も近いバックエンドにトラフィックを誘導してくれます。

    さらに驚くべきは、このロードバランサの設定で「Cloud CDNを有効にする」というチェックボックスを1つ入れるだけで、CDN機能が有効になることです。AWSでCloudFrontのディストリビューションを別途設定する手間がなく、負荷分散とコンテンツ配信が一体となったグローバル配信基盤を極めてシンプルに構築できます。

    【公式ドキュメント】 Google Cloud: Cloud Load Balancing overview
    Google Cloud: Cloud CDN overview

    AWS経験者が意識すべきポイント

    これまでの比較を踏まえ、AWS経験者がGoogle Cloudを学ぶ際に特に意識転換が必要な点をまとめます。

    1. 「とりあえずリージョンを選ぶ」から卒業する

      • AWSでは何をするにもまずリージョン選択から始まりますが、Google CloudではVPCやロードバランサなど、グローバルな視点で設計を始める必要があります。「どのリージョンでVPCを作るか」ではなく、「どのリージョンにサブネットやVMを配置するか」という思考に切り替えましょう。

    2. ファイアウォール制御の粒度と運用思想の違いを意識する

      • AWSでも、実際の運用ではEC2個別にSecurity Group（SG）を手動でアタッチするよりも、起動テンプレートやIaC（Infrastructure as Code）で役割ごとにSGを定義し、自動的に適用するケースが一般的です。 そのため「役割ごとにまとめて制御する」という点では、GCPのネットワークタグやサービスアカウント単位でのファイアウォールルール適用と近い運用も可能です。 ただし、GCPではインスタンスに付与したタグやサービスアカウント単位で柔軟にルールを適用できるため、AWSのSGよりもさらに抽象度の高い制御や、動的なグルーピングがしやすいのが特徴です。 この「タグやサービスアカウント単位での柔軟な制御」が、GCPならではの運用思想と言えるでしょう。

    3. 「サブネット＝IPアドレスの範囲」とシンプルに捉える

      • AWSではサブネットがAZやルートテーブルと密接に結びついていますが、Google Cloudではまず「リージョンで利用するIPアドレスの範囲」とシンプルに捉え、可用性はインスタンスをどのゾーンに配置するかで担保する、というように関心事を分離して考えるとしっくりきます。

    おわりに

    今回は、AWS経験者向けにGoogle Cloudネットワークの設計思想と主要なサービスの違いを解説しました。

    Google Cloudのネットワークは、一見するとAWSと大きく異なり戸惑うかもしれませんが、その根底にはGoogleの強力なグローバルインフラを「シンプルに、最大限活用する」という一貫した思想があります。特にグローバル展開を前提としたサービスを設計する際には、その恩恵を大きく受けられるはずです。

    AWSの知識は決して無駄にはなりません。むしろ、その知識があるからこそ、Google Cloudのアーキテクチャの特徴やメリットをより深く理解できるはずです。この記事が、皆さんの新しいクラウド学習への挑戦の一助となれば幸いです。

    執筆者：小野内 貴啓

    LinkedIn

    2022年キャリア入社。猫好きのデータエンジニア(インフラエンジニア)です。
    ユーザ系SIerや独立系SIerでオンプレ・AWSメインのインフラ運用保守エンジニアを経て現職。
    Google Cloud+AWSインフラ担当。