Google Cloud ネットワーク構築の第一歩！VPCとサブネットの基本を実践的に徹底解説


この記事では、Google Cloudのネットワーク構築に不可欠なVPCやサブネットといった基本要素を解説します。クラウドインフラの基礎概念から、コマンドを使った実践的な構築・確認方法までを網羅し、ネットワーク設計の第一歩をサポートします。

はじめに

昨今、多くの企業でクラウド活用が進む中、Google Cloud Platform (グーグル・クラウド・プラットフォーム)はその柔軟性と拡張性から注目を集めています。しかし、クラウド上にシステムを構築する第一歩であるネットワーク設計、特に「VPC」や「サブネット」といった概念につまずいてしまう方も少なくありません。

「オンプレミスとは考え方が違う？」「リージョンやゾーンはどう選べばいいの？」

この記事では、そのような疑問をお持ちのインフラ担当者の皆様に向けて、Google Cloud Platform のネットワークの根幹をなす VPC(Virtual Private Cloud)、サブネット、リージョン、ゾーンの基本概念から、実践的な設定方法、そして設計におけるベストプラクティスまでを、ステップバイステップで分かりやすく解説します。

この記事を読めば、Google Cloud Platformでセキュアかつ効率的なネットワークを構築するための基礎知識が身につき、自信を持ってクラウドインフラの設計・構築を進められるようになります。

Google Cloud ネットワーク解説

2.1 まずはここから！Google Cloud ネットワークの基本要素

Google Cloud Platform 上でネットワークを構築する上で、絶対に押さえておきたい4つの基本要素があります。それぞれの役割をしっかり理解することが、最適なネットワーク設計への近道です。

2.1.1 リージョンとゾーン：インフラの物理的な「場所」

リージョンとは、データセンターが集約された特定の地理的エリア（例：東京、大阪）を指します。一方、ゾーンはリージョン内にある独立したデータセンターの単位です。リソースを複数のゾーンに分散させることで、万が一特定のゾーンで障害が発生してもサービスを継続できる、高い可用性を実現します。

リージョンの選び方
  • レイテンシー: サービスを提供するユーザーに近いリージョンを選ぶことで、通信の遅延を最小限に抑えます。
  • 法規制: データの所在地に関するコンプライアンス要件を満たすリージョンを選択します。
  • サービス: 利用したいサービスが提供されているリージョンかを確認します。
ゾーンの役割
  • 冗長化: 複数のゾーンにリソースを分散配置することで、システムの耐障害性を高めます。東京 (asia-northeast1) や大阪 (asia-northeast2) リージョンは3つのゾーンを持っており、堅牢なシステム構築が可能です。

2.1.2 VPC (Virtual Private Cloud)：クラウド上のプライベートネットワーク

VPC (Virtual Private Cloud) は、Google Cloud Platform 上に構築する、論理的に分離されたプライベートな仮想ネットワーク空間です。VPCを利用することで、独自のIPアドレス範囲やサブネット、ファイアウォールルールを定義でき、オンプレミス環境と同じような感覚でセキュアなネットワークを管理できます。

VPCの主な利点
  • セキュリティ: ファイアウォールルールにより、仮想マシン (VM) インスタンスへの通信を厳密に制御できます。
  • 柔軟性: グローバルVPCにより、複数のリージョンにまたがるネットワークを単一のVPCでシンプルに構成できます。
  • 拡張性: ビジネスの成長に合わせてネットワークを柔軟に拡張・縮小できます。

2.1.3 サブネット：VPCを効率的に分割・管理

サブネットは、VPCのIPアドレス範囲をさらに細かく分割した単位で、特定のリージョンに属します。リソースを用途やセキュリティ要件に応じてグループ化し、効率的に管理するために利用します。

サブネット設計のポイント
  • IPアドレス計画: 将来の拡張性を考慮してIPアドレスの範囲を計画します。Google Cloud PlatformではダウンタイムなしでサブネットのIPアドレス範囲を拡張できますが、縮小はできないため注意が必要です。
  • 機能分離: Webサーバー用、データベース用など、役割ごとにサブネットを分割することで、セキュリティと管理性を向上させます。

2.2 失敗しないためのネットワーク設計ベストプラクティス

堅牢でスケーラブルなネットワークを構築するためには、いくつかの重要なポイントがあります。

2.2.1 スケーラビリティを考慮した設計

  • 複数リージョン・ゾーンへの分散: 1つのVPC内に東京と大阪など、異なるリージョンのサブネットを配置することで、大規模な災害時にも対応できるDR(Disaster Recovery) 構成を実現します。
  • デフォルトサブネットは利用しない:VPC作成時に自動で作成されるデフォルトサブネットは、広すぎるIPアドレス範囲を持つため、セキュリティや管理の観点から削除し、要件に合わせたカスタムサブネットを利用することを推奨します。
  • IaC (Infrastructure as Code) の活用: Terraformなどのツールを用いてインフラ構成をコード化することで、構築の自動化、再現性の確保、ヒューマンエラーの削減が可能です。

2.2.2 セキュリティの考慮

ファイアウォールルールの最適化
  • 最小権限の原則: 通信はデフォルトですべて拒否し、必要な通信のみを許可するルールを設定します。
  • ステートフルファイアウォール: Google Cloud Platformのファイアウォールはステートフルであり、一度許可した通信の戻りのトラフィックは自動的に許可されるため、シンプルなルール管理が可能です。
  • 定期的な見直し: 不要になったルールが残存しないよう、定期的に棚卸しを実施します。
  • セキュアなアクセス管理:限定的な接続: オンプレミス環境との接続には、Cloud VPN や Cloud Interconnectといったセキュアな接続サービスを利用します。
  • IAM (Identity and Access Management) の活用:ユーザーやサービスアカウントごとに詳細な権限を設定し、「誰が」「何に」アクセスできるかを厳密に管理します。

2.3 実践！gcloudコマンドでVPCとVMインスタンスを構築してみよう

ここからは、実際にコマンドラインツール (gcloudコマンド) を使用して、以下の構成のネットワークを構築する手順を紹介します。VPC、サブネット、リージョン、ゾーンの関係性を具体的にイメージしながら進めていきましょう。

2.3.1 VPCとサブネットの作成

まず、カスタムモードでVPC「labvpc」を作成します。

  1. gcloud compute networks create labvpc --subnet-mode custom

次に、東京 (asia-northeast1) と大阪 (asia-northeast2) の各リージョンに、サブネットを2つずつ作成します。

  1. 東京リージョンにサブネットを作成
  2. gcloud compute networks subnets create subnet11 
  3. --network labvpc 
  4. --region asia-northeast1 
  5. --range 10.24.11.0/24
  6. gcloud compute networks subnets create subnet12 
  7. --network labvpc 
  8. --region asia-northeast1 
  9. --range 10.24.12.0/24
  11. 大阪リージョンにサブネットを作成
  12. gcloud compute networks subnets create subnet21 
  13. --network labvpc 
  14. --region asia-northeast2 
  15. --range 10.24.21.0/24
  16. gcloud compute networks subnets create subnet22 
  17. --network labvpc 
  18. --region asia-northeast2 
  19. --range 10.24.22.0/24

2.3.2 VMインスタンスの作成

作成したサブネット内に、複数のゾーンにまたがる形でVMインスタンスを配置します。今回は外部IPアドレスを持たない、よりセキュアな構成とします。

  1. 東京リージョンにVMインスタンスを3台作成 (CentOS Stream 9)
  2. gcloud compute instances create vm-tokyo-01 
  3. --zone asia-northeast1-a --subnet subnet11 
  4. --private-network-ip 10.24.11.11 --no-address 
  5. --machine-type e2-micro --image-project centos-cloud --image-family centos-stream-9 
  6. --tags=iap-access,icmp-access
  7. gcloud compute instances create vm-tokyo-02 
  8. --zone asia-northeast1-a --subnet subnet12 
  9. --private-network-ip 10.24.12.12 --no-address 
  10. --machine-type e2-micro --image-project centos-cloud --image-family centos-stream-9 
  11. --tags=iap-access,icmp-access
  12. gcloud compute instances create vm-tokyo-03 
  13. --zone asia-northeast1-b --subnet subnet12 
  14. --private-network-ip 10.24.12.21 --no-address 
  15. --machine-type e2-micro --image-project centos-cloud --image-family centos-stream-9 
  16. --tags=iap-access,icmp-access
  18. 大阪リージョンにVMインスタンスを3台作成 (Windows Server 2022)
  19. gcloud compute instances create vm-osaka-01 
  20. --zone asia-northeast2-a --subnet subnet21 
  21. --private-network-ip 10.24.21.11 --no-address 
  22. --machine-type e2-medium --image-project windows-cloud --image-family windows-2022 
  23. --tags=iap-access,icmp-access
  24. gcloud compute instances create vm-osaka-02 
  25. --zone asia-northeast2-b --subnet subnet22 
  26. --private-network-ip 10.24.22.21 --no-address 
  27. --machine-type e2-medium --image-project windows-cloud --image-family windows-2022 
  28. --tags=iap-access,icmp-access
  29. gcloud compute instances create vm-osaka-03 
  30. --zone asia-northeast2-c --subnet subnet22 
  31. --private-network-ip 10.24.22.31 --no-address 
  32. --machine-type e2-medium --image-project windows-cloud --image-family windows-2022 
  33. --tags=iap-access,icmp-access

2.3.3 ファイアウォールルールの作成

VMインスタンスへの通信を許可するため、ファイアウォールルールを作成します。今回は、セキュアなリモート接続を実現する IAP (Identity-Aware Proxy) からの通信と、疎通確認のためのICMP通信を許可します。

  1. IAPからのSSH/RDP通信を許可
  2. gcloud compute firewall-rules create allow-iap-ssh-rdp 
  3. --network=labvpc 
  4. --direction=INGRESS 
  5. --action=ALLOW 
  6. --rules=tcp:22,tcp:3389 
  7. --source-ranges=35.235.240.0/20 
  8. --target-tags=iap-access
  10. 内部からのICMP通信（ping）を許可
  11. gcloud compute firewall-rules create allow-icmp 
  12. --network=labvpc 
  13. --direction=INGRESS 
  14. --action=ALLOW 
  15. --rules=icmp 
  16. --source-ranges=0.0.0.0/0 
  17. --target-tags=icmp-access

2.4 構築したネットワークの疎通を確認する

設定が完了したら、実際にVMインスタンス間で通信ができるか確認してみましょう。

2.4.1 東京リージョンのLinuxサーバーからの疎通確認

IAPを利用して東京リージョンのvm-tokyo-01にSSH接続し、他のすべてのVMインスタンスに対してpingコマンドを実行します。リージョンやゾーン、サブネットが異なっていても、同一VPC内であれば問題なく通信できることがわかります。

  1. [hisato@vm-tokyo-01 ~]$ ping -c 2 10.24.12.12
  2. PING 10.24.12.12 (10.24.12.12) 56(84) bytes of data.
  3. 64 bytes from 10.24.12.12: icmp_seq=1 ttl=64 time=1.30 ms
  4. 64 bytes from 10.24.12.12: icmp_seq=2 ttl=64 time=0.404 ms
  6. --- 10.24.12.12 ping statistics ---
  7. 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
  8. rtt min/avg/max/mdev = 0.404/0.850/1.296/0.446 ms
  9. [hisato@vm-tokyo-01 ~]$
  10. [hisato@vm-tokyo-01 ~]$
  11. [hisato@vm-tokyo-01 ~]$ ping -c 2 10.24.21.11
  12. PING 10.24.21.11 (10.24.21.11) 56(84) bytes of data.
  13. 64 bytes from 10.24.21.11: icmp_seq=1 ttl=128 time=10.2 ms
  14. 64 bytes from 10.24.21.11: icmp_seq=2 ttl=128 time=8.24 ms
  16. --- 10.24.21.11 ping statistics ---
  17. 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
  18. rtt min/avg/max/mdev = 8.236/9.204/10.172/0.968 ms

2.4.2 大阪リージョンのWindowsサーバーからの疎通確認

同様に、IAPを利用して大阪リージョンのvm-osaka-01にRDP (リモートデスクトップ) 接続し、コマンドプロンプトからpingコマンドで疎通確認を行います

  1. C:>ping -n 2 10.24.11.11
  3. Pinging 10.24.11.11 with 32 bytes of data:
  4. Reply from 10.24.11.11: bytes=32 time=9ms TTL=64
  5. Reply from 10.24.11.11: bytes=32 time=8ms TTL=64
  7. Ping statistics for 10.24.11.11:
  8. Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
  9. Approximate round trip times in milli-seconds:
  10. Minimum = 8ms, Maximum = 9ms, Average = 8ms
  12. C:>
  13. C:>
  14. C:>ping -n 2 10.24.22.21
  16. Pinging 10.24.22.21 with 32 bytes of data:
  17. Reply from 10.24.22.21: bytes=32 time=2ms TTL=128
  18. Reply from 10.24.22.21: bytes=32 time=1ms TTL=128
  20. Ping statistics for 10.24.22.21:
  21. Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
  22. Approximate round trip times in milli-seconds:
  23. Minimum = 1ms, Maximum = 2ms, Average = 1ms

2.5 Network Topologyで構成を可視化する

Google Cloud Console の Network Topology という機能を使うと、VPCネットワーク内のトラフィックやリソースの構成を視覚的に確認できます。今回構築したリソースが、意図した通りに各リージョン・ゾーンに配置されていることが一目でわかります。

まとめ

本記事では、Google Cloud Platform のネットワーク基盤であるVPC、サブネット、リージョン、ゾーンの基本概念から、設計におけるベストプラクティス、そして実際の構築手順までを解説しました

  • リージョンとゾーンで物理的な配置を決定する
  • VPCでプライベートなネットワーク空間を確保する
  • サブネットでVPC内を効率的に分割・管理する

これらの関係性を正しく理解し、スケーラビリティとセキュリティを考慮して設計することが、Google Cloud Platform を最大限に活用するための鍵となります。

富士ソフトでは、お客様のビジネス要件に合わせた最適な Google Cloud Platform の導入・設計・構築・運用をご支援しています。クラウド移行やインフラ構築でお困りの際は、ぜひお気軽にご相談ください。