Google Cloud VPC（Virtual Private Cloud）是 GCP 上所有计算资源的网络基础。Compute Engine 实例、GKE 集群、Cloud SQL 数据库，都运行在某个 VPC 网络之内。理解 GCP VPC 的设计逻辑，是在谷歌云上搭建任何生产架构的前提。
GCP VPC 和 AWS VPC 的架构设计存在较大的区别，从 AWS 迁移过来的团队需要特别注意这一点。了解这两套体系的异同，可以参考 谷歌云 vs AWS 的对比分析。
GCP VPC 的核心设计：全局网络与区域子网
GCP VPC 最重要的特性是全局性：一个 VPC 网络跨越 GCP 所有地域，不需要为每个地域单独创建一个 VPC。这和 AWS 完全相反——AWS 的 VPC 是区域级资源，us-east-1 的 VPC 和 ap-east-1 的 VPC 是完全独立的两个网络，需要通过 VPC Peering 或 Transit Gateway 才能互通。
在 GCP 中，部署在 us-central1 的实例和部署在 asia-east1 的实例，可以在同一个 VPC 内通过内网 IP 直接通信，不需要任何额外配置。这让多区域架构的设计和运维复杂度明显低于 AWS。
子网（Subnet）是区域级资源，每个子网属于一个地域（Region），并自动覆盖该地域内所有可用区（Zone）。这也和 AWS 不同——AWS 的子网绑定在单个可用区，跨可用区高可用需要在每个可用区分别创建子网。在 GCP 中，同一子网内的实例可以分布在不同可用区，高可用设计更简单。
每个 GCP 项目最多可以创建 5 个 VPC 网络（可申请提升），不同 VPC 之间默认完全隔离，流量不能跨 VPC 传输，除非通过 VPC 对等连接或 Shared VPC 明确打通。
两种 VPC 模式：自动模式与自定义模式
创建 VPC 网络时需要选择模式，这个选择决定了子网的创建方式和后续的网络扩展能力。
自动模式
自动模式 VPC 在每个 GCP 地域自动创建一个子网，使用 GCP 预定义的 IP 地址范围（10.128.0.0/9 地址块的子网段）。新开通的 GCP 项目默认有一个名为 default 的自动模式 VPC，便于快速启动测试。
自动模式的主要限制在于 IP 范围不可自定义，各地域的预定义范围在不同项目之间是固定的，这意味着来自不同项目的两个自动模式 VPC 之间存在 IP 地址重叠，无法建立 VPC 对等连接。此外，新地域上线时 GCP 会自动在自动模式 VPC 中添加子网，可能与已有的 IP 规划产生冲突。
自定义模式
自定义模式 VPC 创建时没有任何子网，完全由用户手动创建子网并指定 IP 范围。这是生产环境的唯一正确选择，原因有三：用户完全掌控 CIDR 分配，可以精确规划各子网范围；非重叠的 IP 规划为后续 VPC 对等连接留出空间；安全策略从最小权限出发，不携带任何预置防火墙规则。
用 gcloud CLI 创建一个自定义模式 VPC 网络：
gcloud compute networks create production-vpc \
–subnet-mode=custom \
–bgp-routing-mode=regional
–bgp-routing-mode 有两个选项：regional 模式下各地域路由独立，适合单区域或对路由隔离有要求的场景；global 模式下所有地域的动态路由在整个 VPC 内共享，适合需要 Cloud Router 跨地域学习路由的场景。
子网规划与网段选择
子网是部署计算资源的基础单元，规划不当会在后续扩展中产生麻烦。子网的 IP 范围一旦创建只能扩大不能缩小，且不能修改或替换（只能删除重建），因此前期规划需要留出足够的余量。
CIDR 的选择原则
子网的 IP 范围必须使用 RFC 1918 标准私网地址：10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16 的子集。子网最小掩码为 /29（8 个地址，其中 4 个保留给 GCP 系统使用，实际可用 4 个），生产环境通常使用 /20（4096 个地址）到 /24（256 个地址）之间的子网。
同一 VPC 内的所有子网 IP 范围不能重叠。如果计划未来在两个 VPC 之间建立对等连接，两个 VPC 内所有子网的范围也不能有任何重叠，因此跨 VPC 规划时应提前预留好各自的地址空间。
以一个多地域生产环境为例，合理的子网规划如下：
production-vpc（全局）
├── web-hongkong 10.10.0.0/20 asia-east2 Web 层
├── app-hongkong 10.10.16.0/20 asia-east2 应用层
├── db-hongkong 10.10.32.0/24 asia-east2 数据层
├── web-singapore 10.20.0.0/20 asia-southeast1 Web 层
└── app-singapore 10.20.16.0/20 asia-southeast1 应用层
各层使用不同子网隔离，通过防火墙规则控制层间访问，数据层子网分配更小的网段，Web 层和应用层留出足够的扩展空间。
GKE 集群的子网规划注意事项
如果子网用于 GKE 集群，需要额外配置次要 IP 地址范围：一个用于 Pod，一个用于 Service。GKE 集群中每个节点会从 Pod 次要范围分配 /24 的地址块（256 个 Pod IP），Service 范围通常使用 /24。Pod 范围建议使用 /18 到 /20，为集群扩展留出足够空间。
创建带次要范围的子网：
gcloud compute networks subnets create gke-subnet \
–network=production-vpc \
–region=asia-east2 \
–range=10.10.0.0/20 \
–secondary-range pods=10.100.0.0/18,services=10.200.0.0/24
防火墙规则配置
GCP 防火墙规则的工作方式和 AWS 安全组有本质区别，是初次使用 GCP 最需要重新理解的概念。
AWS 安全组是附加在网络接口上的有状态防火墙，每台实例关联一个或多个安全组。GCP 防火墙规则在 VPC 级别定义，但在每台 VM 实例上执行，类似分布式防火墙——规则跟着 VM 走，而不是跟着子网走。
目标 VM 的选择方式
GCP 防火墙规则通过两种方式指定目标 VM：网络标签（network tags）和服务账号（service accounts）。网络标签是附加在实例上的字符串，可以在创建实例时指定，也可以随时修改。防火墙规则指定目标标签后，只有带有该标签的实例会受到规则影响，没有标签的实例不受影响。
这个设计让防火墙规则的粒度非常灵活：同一子网内的两台实例可以应用完全不同的防火墙规则，只要它们带有不同的网络标签。以 Web 服务器和数据库服务器部署在同一子网为例，通过网络标签可以分别控制各自的入站端口，而不需要将它们放在不同子网。
默认隐式规则
每个 VPC 网络有两条隐式规则，不可见但始终生效：
- 优先级 65535，拒绝所有入站流量（ingress deny all）
- 优先级 65534，允许所有出站流量（egress allow all）
所有自定义防火墙规则的优先级都高于这两条隐式规则（优先级数值更小）。入站规则需要显式创建才能放行流量，出站流量默认全部放行，如果有需要限制出站的场景，需要单独添加出站拒绝规则。
常用防火墙规则配置
为 Web 服务器允许 HTTP 和 HTTPS 入站（目标标签 web-server）：
gcloud compute firewall-rules create allow-http-https \
–network=production-vpc \
–direction=INGRESS \
–priority=1000 \
–action=ALLOW \
–rules=tcp:80,tcp:443 \
–source-ranges=0.0.0.0/0 \
–target-tags=web-server
为管理员 SSH 访问限定来源 IP（不对公网开放）：
gcloud compute firewall-rules create allow-ssh-admin \
–network=production-vpc \
–direction=INGRESS \
–priority=1000 \
–action=ALLOW \
–rules=tcp:22 \
–source-ranges=203.0.113.0/24 \
–target-tags=bastion
允许数据库层只接受来自应用层的流量（通过服务账号定向）：
gcloud compute firewall-rules create allow-db-from-app \
–network=production-vpc \
–direction=INGRESS \
–priority=1000 \
–action=ALLOW \
–rules=tcp:5432 \
–source-service-accounts=app-service@project-id.iam.gserviceaccount.com \
–target-tags=database
防火墙规则是有状态的：允许了某个方向的连接，该连接的响应流量自动被放行，不需要单独配置反向规则。这和 AWS 安全组的行为一致，但和 AWS 网络 ACL 不同（ACL 是无状态的，需要双向配置）。
关于 Compute Engine 实例的创建和网络标签配置，可以参考 Cloud Compute Engine 使用教程中的网络配置部分。
删除默认 VPC：生产环境的必要操作
每个新项目都有一个名为 default 的自动模式 VPC，并预置了若干防火墙规则，包括：允许所有来源（0.0.0.0/0）的 SSH（22 端口）和 RDP（3389 端口）访问。这意味着在 default VPC 中创建带有公网 IP 的实例，会立即暴露在来自全球的暴力破解扫描中。
生产环境的标准做法是删除 default VPC，使用自定义模式 VPC 替代，并通过组织策略（Organization Policy）阻止项目中自动创建默认网络：
# 删除默认 VPC 的所有防火墙规则（须逐条删除）
gcloud compute firewall-rules delete default-allow-ssh
gcloud compute firewall-rules delete default-allow-rdp
gcloud compute firewall-rules delete default-allow-icmp
gcloud compute firewall-rules delete default-allow-internal
# 删除默认 VPC 网络
gcloud compute networks delete default
如果通过组织策略统一管理，可以设置 constraints/compute.skipDefaultNetworkCreation 为 True，新建项目不再自动创建默认 VPC。
Cloud NAT：私有实例访问公网
生产环境中，应用服务器和数据库通常部署为没有公网 IP 的私有实例，通过减少公网暴露面降低安全风险。但这些实例有时需要访问公网，例如下载软件包更新、调用外部 API。Cloud NAT 是 GCP 的全托管 NAT 服务，为私有实例提供出站公网访问能力，实例本身不持有公网 IP。
Cloud NAT 需要配合 Cloud Router 使用。Cloud Router 是托管的 BGP 路由器，Cloud NAT 将私有实例的出站流量路由给 Cloud Router，再由 Cloud Router 通过 NAT 映射到公网 IP 转发出去。
创建 Cloud Router 和 Cloud NAT：
# 创建 Cloud Router
gcloud compute routers create production-router \
–network=production-vpc \
–region=asia-east2
# 创建 Cloud NAT，自动分配公网 IP，覆盖所有子网
gcloud compute routers nats create production-nat \
–router=production-router \
–region=asia-east2 \
–nat-all-subnet-ip-ranges \
–auto-allocate-nat-external-ips
Cloud NAT 按每小时固定费用（约 $0.044/小时）加数据处理量计费。每个区域部署一个 Cloud NAT 即可覆盖该区域所有子网，非生产环境可以多个区域共用尽量少的 NAT 实例以节省固定费用。
VPC 对等连接与 Shared VPC
VPC 对等连接
当两个独立的 VPC 网络需要内网互通时，可以建立 VPC 对等连接（VPC Network Peering）。对等连接建立后，两个 VPC 内的实例通过内网 IP 直接通信，不经过公网。GCP 的 VPC 对等连接是全局的——建立连接后，两个 VPC 内所有地域的子网都可以互访，不需要按地域分别配置。
VPC 对等连接有两个约束需要提前确认：两侧 VPC 的所有子网 IP 范围不能有任何重叠，且对等连接不具传递性——如果 VPC-A 和 VPC-B 对等、VPC-B 和 VPC-C 对等，VPC-A 和 VPC-C 之间没有连通性，需要单独建立 A-C 之间的对等连接。
Shared VPC
Shared VPC 是多项目团队的网络集中管控方案。一个宿主项目（Host Project）拥有和管理 VPC 网络，多个服务项目（Service Project）将资源部署到宿主项目的子网中，各服务项目的实例使用共享 VPC 的内网 IP 互通，网络安全策略统一由宿主项目管理。
Shared VPC 适合以下场景：企业有多个 GCP 项目，需要统一管理网络配置和安全策略；不同团队各自管理自己的项目和应用，但需要通过同一内网互访；需要避免跨项目时建立大量 VPC 对等连接带来的管理复杂度。
路由配置
GCP VPC 创建子网后，系统自动生成两类路由：一类保证同一 VPC 内各子网之间的内网互通，另一类提供到 0.0.0.0/0 的默认出站路由（指向 VPC 的 Internet Gateway）。大多数场景下系统生成的路由已经够用，不需要手动配置。
需要自定义路由的场景主要是：将特定流量导向 Cloud VPN 网关（访问本地数据中心）、将出站流量强制通过 Cloud NAT 或安全代理、或者为 GKE Pod 网段配置特定路由。
网络层级选择：Premium vs Standard
GCP Compute Engine 的出站网络流量有两个层级，影响实际网络性能和成本。
Premium 层级将流量通过 Google 的全球骨干网络传输，从实例所在区域直接进入 Google 骨干，延迟更低、稳定性更好，适合对延迟和可靠性有要求的业务。Premium 层级的出站流量费用高于 Standard 层级。
Standard 层级使用公共互联网传输，流量在区域出口处进入公共互联网，成本约为 Premium 层级的 50%，但延迟和稳定性不如 Premium。适合对网络质量要求不高的批处理任务、归档备份或内部工具。
可以在子网级别设置默认网络层级，也可以在单个实例或负载均衡器上单独指定。谷歌云香港和新加坡节点的实际延迟表现，可以参考 谷歌云香港服务器 选择指南中的网络测评数据。
账号开通与代理充值
配置 GCP VPC 网络需要有效的谷歌云账号。GCP 新账号在开通阶段有一定的风控观察期，Cloud NAT、Cloud Interconnect 等高级网络产品在新账号下可能遇到配额限制。通过 谷歌云代理商 渠道开通的账号，账号稳定性更高，资源配额更宽松，同时支持 USDT 等灵活付款方式、免绑卡，充值享赠金返点（$100 充值到账 $110，$500 到账 $600，$1000 到账 $1250），适合正式业务长期使用。
