GCPのネットワークを学ぶとき、「Cloud SQLは自分のGCPリソースなのに、なぜVPC内ではないのか」「Cloud RunはGoogle管理サービスだからVPC内ではないのか」「Cloud StorageやBigQueryはどこにいるのか」が混乱しがちです。
「実行基盤」「DBサービス」「オブジェクトストレージ」「serverless」といった分類はクラウド全般に通じる考え方です。一方で、Cloud SQL、Cloud Run、Private Google Access、Direct VPC egress のような具体名とVPCへの接続方法はGCP固有です。本記事では、一般的な見方を使いながら、最終的にはGCP上でどう判定するかに絞って整理します。
この混乱は、以下の2つを混ぜることで起きます。
- 自分のGCPリソースか
- 自分のVPC/Subnetに直接ぶら下がっているか
本記事では、この2軸でVPC内外のリソースを整理します。
判定基準
まず判定基準はこれです。
- 作る場所としてVPC/Subnetを選ぶ: VPC内リソース
- 接続先としてVPCを設定する: VPC外サービスだがVPCと接続できる
ここで出てくるNICは、Network Interfaceのことです。物理サーバーでいうネットワークカードの仮想版で、VMがVPC/Subnetにつながるための「ネットワーク口」と考えると分かりやすいです。
VM
└── NIC
├── 接続先VPC
├── 接続先Subnet
└── 内部IPたとえばCompute Engine VMは、作成時にVPCとSubnetを選びます。VMのNICがSubnetに接続され、内部IPを持ちます。これはVPC内リソースです。
一方でCloud Runは、通常「どのSubnetに配置するか」を選んでVMのように置くものではありません。ただし、VPC内リソースへアクセスしたい場合にVPC egressを設定できます。これは「VPC内に置かれる」のではなく「VPCへ出られるようにする」設定です。
GCPリソースかどうかとVPC内かどうかは別
Cloud SQLが混乱しやすいのは、Console上では確かに自分のリソースとして存在するからです。Cloud SQL instance という名前も出ます。
しかし、Compute Engine VMのように自分のVPC/SubnetにNICを持つわけではありません。
| 観点 | Compute Engine VM | Cloud SQL |
|---|---|---|
| Console上のGCPリソース | はい | はい |
| instanceという名前 | VM instance | Cloud SQL instance |
| 自分でOS管理 | する | しない |
| 自分のVPC/SubnetにNICを持つ | はい | 基本は違う |
| VPCとの関係 | VPC内に置く | VPCからprivate接続する |
つまりCloud SQLは「自分のGCPリソース」ではありますが、「自分のVPC内に置いたVM」ではありません。
Cloud SQLは自分の持ち物ですが、自分のVPC内に置いたサーバーではありません。
VPC内に直接いる代表
VPC内リソースとしてまず押さえるのは、アプリを動かす実行基盤です。
| リソース | VPC内か | 理由 |
|---|---|---|
| Compute Engine VM | VPC内 | NICがVPC/Subnetに接続される |
| GKE node | VPC内 | 実体はCompute Engine VM |
| GKE Pod | ほぼVPC内として扱う | VPC-nativeではPod IPもVPC由来 |
| Internal Load Balancer | VPC内 | VPC内のprivate IPで待ち受ける |
ここでいう「VPC内の自前サービス」は、オンプレのことではありません。VPC内のVMやGKEに自分で載せているアプリやミドルウェアのことです。
Compute Engine VM
└── 自前APIアプリ
GKE
└── Pod
└── 自前APIアプリ設計図では、Compute Engine VMを「アプリサーバー」として省略表現することもあります。ただし厳密には、Compute Engineはアプリそのものではなく、アプリを載せる機械です。
VPC外にあるGoogleサービス
次に、VPC外として扱うGoogleサービスを分類します。ここで「マネージドサービス」という言葉を雑に使うと混乱します。GCPの多くのサービスはGoogleが管理するサービスですが、ネットワーク上の扱いは違います。
| 分類 | 例 | VPCとの関係 |
|---|---|---|
| Serverlessアプリ実行基盤 | Cloud Run, App Engine, Cloud Functions | VPC外。必要ならVPCへ接続する |
| Google API系 | Cloud Storage, BigQuery, Pub/Sub, Secret Manager | VPC外。APIとして呼ぶ |
| Google管理DB/Cache系 | Cloud SQL, Memorystore | VPC外。private接続で使うことが多い |
重要なのは、Cloud RunとCloud SQLを「どちらもGoogle管理サービスだから同じ」と見ないことです。
- Cloud Run: アプリ実行基盤。入る通信と出る通信を別々に考える
- Cloud SQL: DB接続先。VPC内アプリからprivate接続する対象
Serverless系はVPC外だがVPCへ接続できる
Cloud Run、App Engine、Cloud Functionsは、アプリケーション実行基盤としてはserverless系です。これらは基本的に自分のVPC内に直接置かれるものではありません。
| アプリの置き方 | 代表例 |
|---|---|
| VPC内でアプリを動かす | Compute Engine / GKE |
| VPC外のserverlessでアプリを動かす | Cloud Run / App Engine / Cloud Functions |
ただし、serverlessからVPC内リソースへアクセスすることはあります。その場合はDirect VPC egressやServerless VPC Accessを使います。
これは、VPC内リソースからCloud SQLやGoogle APIへ出る通信とは向きが逆です。ここではCloud Runなどのserverless実行基盤から、Your VPC内のリソースへ出ていく通信として見ます。
flowchart LR
run["Cloud Run<br/>VPC外のserverless実行基盤"]
subgraph vpc["Your VPC"]
app["VPC内リソース<br/>VM / GKE / internal API"]
end
run -->|"Direct VPC egress"| app
まとめ
- 「自分のGCPリソースか」と「自分のVPC内にいるか」は別の軸
- VPC内かどうかは、VPC/Subnetに直接ぶら下がるかで見る
- Compute Engine VMやGKE nodeはVPC内リソース
- Cloud SQLは自分のGCPリソースだが、自分のVPC内VMではない
- Cloud Run / App Engine / Cloud Functionsはserverless実行基盤で、基本はVPC外
- VPC外サービスでも、private接続やVPC egressによってVPCと接続できる