Google Cloud VPC 是什么，虚拟网络应该如何理解和规划

Google Cloud VPC（Virtual Private Cloud）是 Google Cloud 中构建私有网络架构的基础服务。很多刚接触云计算的人，会把VPC理解成“云服务器之间的一张虚拟局域网”，这个理解只能覆盖最表面的一层。

在实际生产环境中，VPC负责的是一整套云端网络基础设施，包括IP地址规划、子网、路由、防火墙、私有访问、互联网出口、跨网络连接以及不同Google Cloud资源之间的通信路径。Compute Engine虚拟机、Google Kubernetes Engine、负载均衡器、Cloud NAT以及许多其他云服务，都可能与VPC网络发生关系。

更重要的是，Google Cloud VPC的设计方式与一些其他云平台并不完全相同。Google Cloud VPC本身是全球级资源，而子网是区域级资源。理解这一点，是正确规划Google Cloud网络的第一步。

一、Google Cloud VPC首先不是一台虚拟路由器

传统数据中心里，人们通常会把网络理解成交换机、路由器、防火墙、网关以及物理链路组成的一套设备。

Google Cloud则把大量网络能力抽象成软件定义的资源。

创建一个VPC网络后，可以在其中建立多个区域子网，然后让不同区域中的计算资源接入对应子网。

例如：

VPC
├── us-central1 subnet
├── northamerica-northeast1 subnet
└── europe-west1 subnet

这里需要特别注意，VPC本身是全球性的，而Subnet是区域性的。

因此，Google Cloud VPC并不是简单地“一个VPC对应一个数据中心”。

同一个VPC可以跨多个Google Cloud区域使用。

这对于高可用架构非常重要。

如果业务同时部署在加拿大、美国和欧洲区域，可以让不同区域的资源使用同一个VPC网络体系，同时根据业务需要进行路由、防火墙和访问控制。

二、子网到底是什么

Subnet，也就是子网，是Google Cloud网络中实际分配IP地址的重要对象。

例如：

10.10.0.0/20

可以作为一个区域子网的IP范围。

虚拟机等资源获得的内部IP地址通常来自相应子网。

实际规划时，最重要的工作之一就是提前做好CIDR地址规划。

例如：

10.10.0.0/16

作为整体地址空间，可以进一步规划成不同区域的子网：

10.10.0.0/20
10.10.16.0/20
10.10.32.0/20

具体大小应该根据实际资源数量、扩容需求以及未来网络连接规划决定。

不要为了“看起来整齐”而随意给所有业务分配同样大小的子网。

如果未来需要通过Cloud VPN、Cloud Interconnect、VPC Peering或者其他网络与外部环境连接，还必须提前考虑CIDR是否冲突。

网络地址一旦规划得过于随意，后期迁移成本可能非常高。

三、Google Cloud的子网与传统三层网络不要机械对应

原稿把网络划分成“核心层、应用层、边缘层”，这种架构思想可以作为企业网络设计参考，但不能把它当成Google Cloud VPC的标准结构。

Google Cloud更常见的设计方式是根据区域、业务边界、环境以及安全要求规划子网。

例如一个企业可能设计：

生产网络
开发网络
测试网络
管理网络

也可以按照不同区域划分。

具体采用哪种方式取决于项目规模和组织管理方式。

更重要的是，不能认为“数据库一定应该放在一个叫数据库层的Subnet里”就自然获得了安全隔离。

Google Cloud中真正决定网络流量是否允许通过的核心控制之一是VPC Firewall。

因此，Subnet负责IP地址范围和网络接入，Firewall负责流量控制，两者职责不能混为一谈。

四、Google Cloud没有传统意义上的每个子网独立路由表

这是原稿中比较重要的一处技术错误。

很多接触AWS的开发者会自然地把Google Cloud网络理解成：

VPC
|
Route Table
|
Subnet

然后认为每个Subnet都有一张独立Route Table。

Google Cloud的路由体系并不是这种模型。

Google Cloud VPC使用VPC级路由体系。

系统会自动提供相应的本地子网路由，并可以通过自定义静态路由以及动态路由等机制实现更复杂的网络路径。

因此，在Google Cloud里讨论“给这个Subnet配置一张Route Table”并不是最准确的表达。

如果需要控制某个目标地址的流量路径，应该根据Google Cloud的路由机制分析目的地址、下一跳以及动态路由等因素。

这也是从其他云平台迁移到Google Cloud时非常容易产生概念误差的地方。

五、默认路由并不等于所有流量都会直接暴露到互联网

Google Cloud VPC中通常会存在默认互联网路由。

但一台虚拟机是否能够直接访问互联网，还涉及它是否具有外部IP、是否通过Cloud NAT、Firewall是否允许，以及目标服务本身如何提供访问。

例如一台没有External IP的Compute Engine实例，仍然可以通过Cloud NAT访问公网。

典型结构可以理解为：

Private VM
|
VPC
|
Cloud NAT
|
Internet

这也是生产环境中非常常见的设计。

数据库服务器、内部应用服务器等资源通常没有必要直接配置公网IP。

如果它们只需要访问软件仓库、API、更新服务器或者其他公网服务，可以通过Cloud NAT提供出站访问能力。

六、Cloud NAT解决的是出站访问问题

Cloud NAT容易被初学者误解成“云端防火墙”。

它不是。

Cloud NAT主要解决没有外部IP的资源如何访问互联网等外部网络的问题，同时提供地址转换能力。

例如：

Private VM
10.10.1.10

可以通过Cloud NAT访问公网。

外部网站看到的则是NAT使用的公网地址，而不是虚拟机的内部IP。

但Cloud NAT不是用来决定“哪个端口允许访问”的主要安全控制。

访问控制仍然需要依靠VPC Firewall以及应用层安全机制。

因此：

Cloud NAT负责网络地址转换和出站连接。

Firewall负责允许或拒绝符合条件的网络流量。

两者不能互相替代。

七、Google Cloud Firewall与传统Network ACL并不一样

原稿把Network ACL作为Google Cloud VPC的重要组成部分，这一点需要修正。

Google Cloud VPC并不存在一个与AWS传统Network ACL完全对应的Subnet级无状态ACL体系。

Google Cloud的核心网络访问控制机制是VPC Firewall。

Firewall规则可以根据源IP范围、目标、协议、端口以及网络标签、服务账号等条件匹配流量。

这意味着在Google Cloud中设计网络安全时，不应该简单照搬：

Subnet
Network ACL
Security Group

这样的其他云平台模型。

应该按照Google Cloud自己的Firewall模型设计。

八、Firewall规则需要理解方向和优先级

Google Cloud Firewall规则可以控制进入和离开资源的流量。

设计时首先需要明确：

谁访问谁？

从哪里来？

访问什么端口？

使用什么协议？

是否只允许特定服务账号或网络身份？

例如Web服务器可能允许HTTP和HTTPS流量，而数据库服务器只允许来自应用服务器的数据库端口。

这比简单地“打开数据库端口给整个10.0.0.0/8”安全得多。

生产环境中应该尽量缩小允许范围。

例如：

Internet
|
Load Balancer
|
Web / Application
|
Database

数据库不需要直接面对互联网。

应用服务器也不应该因为“方便调试”而开放所有端口。

九、不要把VPC防火墙当成完整的应用安全系统

VPC Firewall控制的是网络流量。

它不能代替身份认证、授权、应用程序输入验证、SQL参数化、API权限控制以及数据层安全。

例如一个HTTPS请求成功通过Firewall，并不代表这个用户就应该有权限读取某个数据库记录。

网络层解决：

“这个连接能不能到达服务器？”

应用层还要解决：

“这个用户有没有权限执行这个操作？”

这两者必须分开。

因此生产系统通常需要同时考虑VPC Firewall、IAM、应用身份认证、服务账号权限、数据库权限以及Secret管理。

十、Shared VPC适合大型企业组织

当一个企业拥有大量Google Cloud项目时，网络管理可能出现一个问题。

如果每个项目自己创建VPC，网络地址、Firewall、审计和连接管理容易逐渐失控。

Google Cloud提供Shared VPC。

可以由Host Project管理共享网络，然后让其他Service Project中的资源使用这个网络。

这种架构特别适合大型组织。

例如：

Host Project
|
Shared VPC
|
Production Project
Development Project
Analytics Project
AI Project

这样可以把网络管理与业务项目管理分离。

网络团队可以集中管理网络基础设施，而应用团队继续管理自己的Compute Engine、GKE以及应用资源。

对于企业级Google Cloud环境，Shared VPC往往比“每个项目自己造一套网络”更加容易形成统一的治理体系。

十一、VPC Peering适合不同VPC之间建立私有连接

如果两个VPC需要互相通信，可以考虑VPC Network Peering。

例如：

VPC A
|
VPC Network Peering
|
VPC B

流量可以通过Google Cloud的内部网络进行私有通信，而不需要绕到公网。

但VPC Peering并不是把两个网络简单合并成一个VPC。

两个网络仍然是独立的管理边界。

而且CIDR地址不能随意重叠，路由可达性以及安全策略仍然需要单独规划。

如果企业网络越来越复杂，仅靠大量VPC Peering可能形成难以管理的连接关系。

这时候通常需要考虑更集中化的网络架构。

十二、Cloud VPN适合快速建立加密连接

如果企业需要把本地数据中心与Google Cloud连接起来，可以使用Cloud VPN。

典型结构是：

企业数据中心
|
IPsec VPN
|
Google Cloud VPC

VPN通过互联网建立加密隧道，部署相对方便。

对于管理网络、测试环境、中等规模业务或者对带宽要求不高的场景，VPN非常实用。

但VPN并不是所有企业生产网络的最佳选择。

如果业务需要稳定的大带宽、低延迟以及企业级网络连接能力，就需要进一步考虑Cloud Interconnect。

十三、Cloud Interconnect适合企业级混合云网络

Cloud Interconnect可以提供企业数据中心与Google Cloud之间的专用或合作伙伴互联能力。

与通过公网建立IPsec VPN相比，Interconnect通常更适合长期运行的大规模混合云架构。

例如：

企业数据中心
|
Cloud Interconnect
|
Google Cloud
|
VPC

它可以提供更稳定的网络连接以及更高的带宽选择。

但不能简单说“Interconnect一定比VPN更安全”。

VPN的优势之一就是通过加密隧道保护通信内容。

Interconnect与VPN的安全模型、加密需求和架构设计需要结合具体场景考虑。

在对数据机密性要求较高的场景中，还需要进一步规划加密和访问控制。

十四、Private Google Access非常值得理解

很多企业希望私有IP的Google Cloud资源访问Google API和Google服务，同时不希望每台服务器都拥有公网IP。

Private Google Access就是这类场景中的重要能力。

例如没有External IP的VM，可以在满足条件的情况下通过Google Cloud提供的私有路径访问Google API等服务。

这类设计可以减少服务器直接暴露公网的需求。

对于企业内部应用、数据库、AI计算节点以及数据处理环境来说，这种网络设计非常常见。

十五、Cloud Storage并不是简单的“VPC里面的一台存储服务器”

原稿把Cloud Storage与VPC的关系描述得比较像传统网络存储设备。

实际上Google Cloud Storage属于Google Cloud的托管对象存储服务，并不是在你的VPC子网里创建一台“Storage Server”。

访问Cloud Storage涉及Google Cloud API、IAM、存储桶权限以及网络访问路径等多个层面。

如果业务需要限制访问来源，可以结合Private Google Access、VPC Service Controls以及IAM等机制设计。

因此：

VPC解决网络层面的连接和隔离。

IAM解决身份和资源权限。

VPC Service Controls则可以进一步帮助构建数据访问边界。

三者属于不同安全层级。

十六、VPC Service Controls不是Firewall的替代品

涉及敏感数据时，很多企业会进一步考虑VPC Service Controls。

它主要用于构建Google Cloud服务之间的数据访问边界，降低数据从受保护环境中被非法导出的风险。

这与VPC Firewall解决的问题不同。

Firewall关注网络流量。

IAM关注身份和权限。

VPC Service Controls关注特定Google Cloud服务的数据访问边界。

企业如果只配置Firewall，却忽略IAM和数据访问控制，依然可能存在严重的权限风险。

十七、AI和高性能计算网络需要单独考虑

AI训练和大规模分布式计算对网络的要求与普通Web应用不同。

如果几十台甚至几百台GPU服务器需要频繁交换数据，网络带宽和延迟会直接影响分布式训练效率。

这类环境需要重点考虑Google Cloud提供的高性能网络能力、GPU之间的互联、区域和Zone布局、集群网络以及作业调度。

但不能简单说“把计算节点和存储节点放在不同Subnet，然后优化Route Table就能提高AI训练性能”。

在Google Cloud中，Subnet本身通常不是决定高性能计算速度的主要因素。

更加重要的是实例类型、Zone布局、网络带宽、GPU互联、存储系统以及具体分布式计算框架。

因此AI基础设施网络规划应该从整个系统架构出发，而不是单独优化Subnet。

十八、不要把QoS理解成VPC里的通用网络加速开关

原稿提到通过配置网络QoS来优先保障关键业务流量，这种表述也需要谨慎。

Google Cloud的网络性能和流量管理并不是传统企业交换机上简单配置一个QoS优先级就可以解决。

生产环境需要结合负载均衡、网络架构、实例网络能力、服务等级设计以及应用层流量控制综合考虑。

对于高并发业务，连接池、队列、缓存、限流和服务拆分有时候比所谓“提高网络QoS优先级”更加有效。

十九、高可用不能简单理解为“多放几个Subnet”

Google Cloud资源通常会涉及Region和Zone两个不同层级。

如果应用只部署在一个Zone，即使VPC和Subnet设计得很好，也可能受到Zone级故障影响。

因此高可用架构通常需要把关键工作负载部署在多个Zone，必要时进一步跨Region。

例如：

Region A
Zone A
Zone B

Region B
Zone C
Zone D

然后结合负载均衡、健康检查、自动扩缩容以及数据复制机制实现高可用。

网络只是高可用架构的一部分。

数据库复制、存储、应用状态以及故障切换同样重要。

二十、VPC规划首先应该从地址空间开始

实际建立企业VPC时，可以按照以下思路进行。

第一步是确定整体CIDR地址空间。

例如：

10.0.0.0/8

然后根据区域和业务规模进一步规划。

第二步是确定生产、测试、开发等环境的网络边界。

第三步是规划Region和Subnet。

第四步是确定哪些资源允许公网访问，哪些资源必须使用Private IP。

第五步是规划Internet出站路径，例如直接External IP还是Cloud NAT。

第六步是设计VPC Firewall规则。

第七步是确定是否需要Shared VPC、VPC Peering、Cloud VPN或者Cloud Interconnect。

第八步是确定日志、监控和网络故障排查机制。

最后再根据业务实际流量测试网络性能。

二十一、一个比较典型的企业架构

一个中型企业可以设计成类似这样的结构：

Internet
|
Global Load Balancer
|
Application
|
Database
|
Private Services

Private VM
|
Cloud NAT
|
Internet

On-Premises
|
Cloud VPN / Interconnect
|
VPC

公网用户首先进入负载均衡层。

应用服务器尽可能使用内部网络。

数据库不直接暴露互联网。

需要访问公网的私有服务器通过Cloud NAT出站。

企业本地数据中心则通过VPN或者Interconnect连接Google Cloud。

这比“所有服务器都拥有公网IP，然后靠防火墙挡住危险流量”的设计更加容易控制。

二十二、网络日志是生产环境不可缺少的一环

网络架构部署完成并不代表工作结束。

生产环境需要持续观察网络流量、Firewall规则命中、负载均衡请求、VPN或Interconnect状态以及异常连接。

Google Cloud提供VPC Flow Logs等能力，可以帮助分析网络流量。

如果出现“服务器访问不了数据库”这种问题，可以按照路径逐层排查：

首先确认实例是否运行。

然后确认两端IP地址和Subnet。

再检查VPC路由。

随后检查Firewall。

再检查目标服务是否监听正确端口。

如果跨VPC，则检查Peering或其他连接方式。

如果跨本地数据中心，则继续检查VPN或Interconnect。

如果访问公网，则检查External IP、Cloud NAT以及出口路径。

这种分层排查方式比不断修改Firewall规则更加可靠。

二十三、Google Cloud VPC真正需要规划的不是一张网络图

很多网络架构图看起来非常漂亮，但真正部署之后却出现IP冲突、权限混乱、Firewall规则越来越多、跨项目连接难以管理等问题。

原因通常不是缺少某一个网络组件，而是最开始没有考虑整个生命周期。

VPC规划至少应该考虑四个问题。

第一是地址空间未来是否够用。

第二是不同项目和不同环境之间的管理边界是否清晰。

第三是公网访问和私网访问路径是否明确。

第四是未来是否需要连接其他VPC、其他Region或者企业本地数据中心。

如果这些问题在设计阶段没有考虑，后期再修改网络地址和连接关系，成本通常远高于最初多花一点时间规划。

Google Cloud VPC并不是一个简单的“虚拟交换机”。

它是Google Cloud整个网络架构的基础层。Subnet负责区域级IP地址规划，VPC路由体系负责决定网络可达路径，Firewall负责网络访问控制，Cloud NAT负责私有资源的出站NAT，Private Google Access帮助没有公网IP的资源访问Google服务，VPC Peering用于不同VPC之间的私有互联，Shared VPC用于大型组织统一网络管理，而Cloud VPN和Cloud Interconnect则负责把Google Cloud与外部网络连接起来。

理解这些组件之间的职责边界，比记住几十个网络产品名称更加重要。

对于小型项目，一个简单VPC、合理的Subnet、明确的Firewall规则和Cloud NAT往往已经足够。随着企业进入多项目、多Region、混合云以及AI计算环境，网络设计才会逐渐涉及Shared VPC、复杂路由、跨VPC互联、高性能网络以及集中化安全治理。

因此，Google Cloud VPC的规划重点并不是把网络做得越复杂越好，而是让IP地址、路由、访问控制、互联网出口、私有服务访问以及企业内部网络之间形成清晰的边界。网络越大，越应该依靠明确的设计原则和自动化治理，而不是不断增加临时规则来解决眼前的问题。