Google Cloud Subnet 怎么规划，不同业务环境如何划分网络地址

在 Google Cloud 中，Subnet 是云网络设计中最容易被低估的一层。很多企业刚开始部署云服务器时，只需要创建一个 VPC，再随手划一个较大的 IP 地址段，业务也能够正常运行。但当系统从几台虚拟机发展到几十、几百甚至更多计算实例，开始出现生产环境、开发环境、数据库、容器、GPU 集群、混合云和多区域部署后，Subnet 的地址规划就会直接影响后续扩容、网络互联、安全策略和运维复杂度。

理解 Google Cloud Subnet，首先需要摆脱传统机房网络的一些习惯。Google Cloud VPC 是全球级网络资源，而 Subnet 是区域级资源。一个 VPC 可以包含位于不同 Region 的多个 Subnet，这些 Subnet 共同属于同一个 VPC 网络体系。Subnet 本身主要解决的是 IP 地址范围和资源组织问题，并不意味着每个 Subnet 天然就是一个完全独立的安全区域。

网络安全通常由 VPC Firewall、层级防火墙策略、身份权限、应用层认证授权以及数据库访问控制共同完成。因此，Subnet 规划不能简单理解成“划几个网段就完成网络隔离”，而应该把地址规划、路由、网络访问控制和业务架构放在一起考虑。

Subnet规划首先要解决IP地址问题

Subnet 最基础的功能就是提供 IP 地址范围。设计时最重要的事情不是一开始就决定 /24 还是 /20，而是先估算未来几年需要多少地址，并考虑不同 Region、不同环境以及未来网络互联的需求。

例如，一个业务现在只有几十台 Compute Engine 实例，并不意味着给它一个刚好容纳几十台机器的网段就是合理方案。企业后续可能增加 MIG、GKE 节点、内部负载均衡相关资源、私有服务、测试环境或者其他依赖服务。如果地址空间已经没有余量，后续扩容就会变得麻烦。

同时，企业还应该提前考虑混合云、办公室网络、数据中心以及其他 VPC 的 CIDR。假如企业内部已经使用 10.20.0.0/16，而 Google Cloud 又使用相同地址空间，未来通过 Cloud VPN 或 Cloud Interconnect 建立连接时就可能产生严重的地址重叠问题。

因此，CIDR 规划应该先于服务器部署。企业可以根据环境、Region 和业务边界建立统一的地址分配表，例如预先为生产环境、开发环境和共享服务保留不同的地址范围，而不是每创建一个业务就临时选择一个网段。

还要注意，/24 并不意味着企业可以把 256 个地址全部作为虚拟机地址直接使用。Google Cloud Subnet 存在平台保留地址，因此计算可用地址时应该以 Google Cloud 当前文档和实际配置为准，而不能简单使用传统局域网“256 个地址就是 256 台设备”的算法。

不要把Subnet当成天然的安全边界

这是 Google Cloud 网络设计中非常容易出现的误区。

例如，把应用服务器放在 10.10.1.0/24，数据库放在 10.10.2.0/24，并不意味着应用服务器和数据库之间自动完成了安全隔离。两个 Subnet 如果属于同一个 VPC，其资源之间仍然可能按照 VPC 的路由和防火墙策略进行通信。

真正决定网络连接是否允许的，是 Firewall 规则以及更上层的安全策略。

因此，生产系统可以按照业务职责划分不同 Subnet，例如计算资源、应用服务、数据服务等，但安全设计不能停留在“不同 Subnet 就安全”。

例如数据库只需要接受应用服务器的 TCP 5432 连接，那么防火墙策略就应该限制来源范围、目标实例以及端口，而不是简单允许整个 VPC 内所有地址访问数据库。

同时，网络访问控制和 IAM 是两套不同的体系。一个 Google Cloud 身份拥有访问某项云资源的 IAM 权限，并不意味着它自动拥有向某台服务器建立 TCP 连接的网络权限。反过来也一样，网络连接能够建立，也不意味着应用程序一定拥有访问数据库中某张表的权限。

这也是现代云网络设计越来越强调“网络控制、身份控制和应用授权分别解决不同问题”的原因。

开发、测试和生产环境应该怎样划分

开发环境最重要的是降低实验成本和提高迭代速度，但这并不意味着应该让开发环境和生产环境处于完全没有边界的网络环境中。

对于规模较大的企业，比较常见的做法是通过不同项目管理不同环境，并利用 Shared VPC 等架构集中管理网络。具体是否使用独立 VPC、Shared VPC 或其他项目边界，需要根据企业组织结构、权限管理和运维模式决定，而不是简单规定所有企业都必须采用一种架构。

开发环境可以使用相对宽松的访问策略，但生产数据库、生产管理接口以及敏感内部服务不应该因为“都是公司内部网络”而默认开放。

测试环境尤其容易被忽略。很多企业为了方便测试，会直接复制生产数据库或者允许测试服务器访问大量生产服务。这样虽然短期内方便开发人员调试，但一旦测试主机、开发账号或者测试应用出现安全问题，攻击面就会迅速扩大。

比较合理的思路是让开发、测试和生产环境在网络、身份和数据权限上形成明确边界，同时只开放业务确实需要的通信路径。

生产环境不要为了“看起来专业”而疯狂切Subnet

生产环境可以按照业务职责组织网络，但 Subnet 并不是越多越好。

例如一个中小型 SaaS 系统可能只有 Web、应用和数据库三类主要资源。为了这三个组件分别规划合理的地址范围可以帮助运维和安全管理，但如果进一步把每一个微服务、每一个服务器甚至每一个进程都划成独立 Subnet，网络架构很快就会变得难以维护。

Subnet 的划分应该有实际管理价值。

如果两个资源在地址管理、安全策略、生命周期或者运维责任方面没有明显区别，仅仅为了“网络隔离”而不断创建新的 Subnet，最终可能得到大量复杂配置，却没有获得相应的安全收益。

对于现代云原生系统，还要考虑 GKE 等平台的网络模型。容器 Pod、节点、服务地址等资源并不一定按照传统“一个服务器对应一个 IP”的方式进行设计，因此不能把传统物理服务器网络规划原封不动搬进 Kubernetes。

多Region部署需要提前考虑地址和通信

高可用系统经常需要跨 Region 部署。

由于 Google Cloud VPC 是全球性的，一个 VPC 可以包含多个 Region 的 Subnet。因此，多 Region 架构并不需要通过 VPC Peering 把同一个 VPC 的不同 Subnet“连接起来”。

真正需要解决的是跨 Region 通信、数据复制、负载均衡、故障切换、延迟和成本。

例如一个应用部署在北美两个 Region，应用实例分别使用两个区域的 Subnet。业务流量可以通过适合的 Google Cloud 负载均衡架构进行分发，而数据库、缓存或者对象存储的数据同步则需要根据具体产品和应用架构设计。

跨 Region 通信通常会带来额外网络延迟和相关费用，因此不能为了追求“多区域高可用”就把所有组件机械地复制到多个 Region。

如果业务属于强实时交易、低延迟 AI 推理或者高频数据处理，Region 选择甚至可能比 Subnet 本身更加重要。

混合云环境最怕CIDR地址冲突

Subnet 规划一旦涉及企业数据中心、办公室网络或者其他云平台，地址空间规划的重要性会明显提高。

例如企业本地网络使用 10.10.0.0/16，Google Cloud 又使用相同地址段，两个网络以后通过 VPN 或 Interconnect 互联时，路由系统就无法清晰判断某个目标地址究竟属于哪一边。

这种问题不是换一个防火墙规则就能够解决的。

因此，混合云项目应该在建设初期建立统一 CIDR 规划。不同环境、Region、云平台以及企业内部网络最好提前分配互不冲突的地址空间。

Cloud VPN 可以提供加密的网络隧道连接，Cloud Interconnect 则可以提供企业网络与 Google Cloud 之间的专用连接方式。两者解决的问题并不完全相同，企业还需要结合带宽、延迟、可用性、路由、安全和成本进行选择。

Interconnect 也不能简单理解成“天然比互联网安全”。网络连接方式、加密要求、身份控制和应用层安全是不同层次的问题。

Cloud NAT不是跨Subnet通信工具

原稿把 Cloud NAT 放在 Subnet 与公网互联以及跨 Subnet 性能优化的位置，这个概念需要纠正。

Cloud NAT 的主要用途是让没有外部 IP 地址的资源进行出站访问，例如私有 IP 的 Compute Engine 实例需要访问互联网中的软件仓库、更新服务或者第三方 API。

它不是用来优化 VPC 内部 Subnet 之间通信的工具，也不是传统意义上的防火墙。

同样，Private Google Access 解决的是私有 IP 资源访问 Google APIs 和相关服务的问题。Cloud NAT、Private Google Access、VPC Firewall 和 Cloud Router 分别承担不同职责，不能简单归类成一个“网络出口工具”。

Cloud Router 则主要用于动态路由场景，例如通过 BGP 与 VPN 或 Interconnect 等连接交换路由信息。

AI和GPU集群不能只靠Subnet解决性能问题

AI 训练和推理系统经常需要高带宽网络，因此有人会认为“给 GPU 单独划一个 Subnet，就能够获得更高网络性能”。

这种理解过于简单。

Subnet 本身并不会因为被单独划出来，就自动获得更高的物理带宽，也不会把普通网络变成 GPU 高速互联网络。

GPU 集群的性能通常取决于实例类型、网络带宽、Zone 布局、GPU 之间的互联方式、存储系统、数据加载方式以及训练框架的通信模式。

对于分布式训练，GPU 到 GPU 的通信效率尤其重要。某些 Google Cloud GPU 实例提供专门的高速互联能力，但这属于实例和底层基础设施能力，并不是通过创建一个特殊 Subnet 就可以获得。

同样，100Gbps 甚至更高的网络能力也不能简单等同于“训练一定很快”。如果数据读取、CPU 数据预处理、存储 I/O、GPU 显存、通信拓扑或者分布式同步机制成为瓶颈，单纯提高网络带宽并不能解决问题。

AI 推理也存在类似问题。模型服务通常需要同时考虑 GPU 显存、KV Cache、并发请求、网络带宽、请求调度以及跨 GPU 通信。如果模型分片部署在多个 GPU 上，通信拓扑可能直接影响 Token 生成速度。

因此，AI 网络设计应该围绕实际工作负载和通信模式，而不是简单按照“GPU 一个 Subnet、存储一个 Subnet”的方式套模板。

VPC Firewall比Subnet数量更重要

网络安全设计最终需要落实到访问控制。

Google Cloud VPC Firewall 是有状态的网络访问控制机制，可以根据方向、优先级、协议、端口、来源、目标等条件建立规则。大型企业还需要考虑组织和文件夹层级的防火墙策略。

例如，生产数据库可以只允许应用服务器访问必要的数据库端口，而管理接口则可以限制来源网络或管理系统。

防火墙规则应该尽量遵循最小权限原则。

但也不能把所有安全问题都交给 Firewall。一个 API 即使只允许内网访问，也可能存在身份验证、授权、SQL 注入、对象级权限错误或者租户隔离漏洞。

对于 SaaS 系统尤其如此。网络层只能帮助控制“谁可以连接到这个服务”，应用层还必须继续判断“这个用户是否有权访问这个对象”。

Cloud DNS解决的是名称解析，不是Subnet安全

Cloud DNS 可以承担 DNS 托管和解析工作，并可以结合 Google Cloud 的其他网络和负载均衡能力提供域名解析服务。

但 DNS 不应该被描述成“管理 Subnet 内服务并保证负载均衡”的统一工具。

服务发现、内部 DNS、负载均衡、网络访问控制和应用服务注册是不同问题。具体架构应该根据 Compute Engine、GKE、负载均衡器以及企业内部服务发现机制决定。

Terraform应该成为Subnet规划的一部分

当企业网络规模扩大后，手工在控制台创建 Subnet、Firewall、路由和 NAT 配置很容易出现环境漂移。

Terraform 可以把 VPC、Subnet、防火墙、Cloud NAT、Cloud Router 等基础设施配置纳入代码管理，通过 Git 进行版本控制，并通过代码审查降低误配置风险。

原稿同时提到 CloudFormation，这里需要明确区分。CloudFormation 是 AWS 的基础设施即代码服务，并不是 Google Cloud 的原生 Terraform 替代品。Google Cloud 环境中通常应该根据企业现有平台选择 Terraform 或 Google Cloud 自身的基础设施管理工具。

对于生产环境，更重要的并不是“用了 Terraform 就安全”，而是把网络配置变成可审查、可测试、可回滚的基础设施代码。

例如，一个生产防火墙规则如果从“允许整个内部网段访问”改成“只允许应用服务访问数据库端口”，应该能够在 Git 中留下清晰的变更记录，而不是只能依靠某个人记得几个月前在控制台修改过什么。

Subnet规划应该从地址表开始，而不是从控制台开始

成熟的 Google Cloud 网络规划通常应该先回答几个问题：企业有多少环境，需要多少 Region，未来几年需要多少 IP 地址，是否存在混合云，是否需要 VPN 或 Interconnect，哪些资源需要公网访问，哪些资源应该保持私有，哪些服务需要跨 Subnet 通信，哪些数据库或管理接口必须严格限制访问，以及未来是否需要 GKE、GPU 集群或者其他高性能计算资源。

回答这些问题之后，再确定 VPC 和 Subnet 的地址结构。

一个简单的生产系统可能只需要少量 Subnet，而大型企业可能需要根据 Region、环境和业务边界进行更加复杂的地址规划。没有任何一个 /16、/20 或 /24 可以成为所有企业的标准答案。

Subnet 的价值也不是把网络切得越碎越好，而是在地址管理、业务组织、安全策略、扩容能力和运维复杂度之间找到合理边界。

Google Cloud 的网络设计最终应该形成一个清晰的层次：VPC负责整体网络范围，Subnet负责区域级 IP 地址组织，路由负责决定网络路径，Firewall负责网络访问控制，IAM负责云资源和身份权限，应用负责身份认证与授权，数据库负责数据层访问控制，监控和日志负责发现异常。

当这些层次能够各自承担明确职责时，Subnet 就不再只是一个“给虚拟机分 IP 的网段”，而会成为整个云端基础设施规划中的重要组成部分。对于准备从小规模服务器逐步扩展到多环境、多区域、混合云甚至 AI 基础设施的企业来说，提前做好 CIDR、Region、访问边界和自动化管理，往往比后期不断修改网络结构更加省成本。