AWS SRE的第一天在GCP：7个令人惊讶的差异
Source: Dev.to
引言
我在不同公司使用 AWS 超过 10 年，负责大规模生产基础设施的建设和维护。虽然多年来一直听说 GCP，但从未认真去了解——直到上个周末。
我决定在 GCP 上启动一个个人机器学习项目，心想“会有什么不同？”四小时后，我真的被震撼了。不仅是功能，更是 GCP 对云基础设施的根本思考方式。
说实话：现在回头看 AWS，我会想到 Perl 和 Jenkins。它们之所以还能在生产环境中存活，是因为拥有现代方案的所有功能——但往往是通过多年积累的变通实现的。AWS 能工作，绝对没问题。但 GCP 给人的感觉是：它是事后设计的。
下面分享让我最惊讶的 7 条差异。
1. 组织结构：终于有了合乎逻辑的层级
在 AWS 中：
组织（Organizations）、组织单元（OUs）和 Control Tower 是事后才加上的——字面意义上的“插件”，在 AWS 推出多年后才引入。管理多账户结构感觉像是把组织概念强行套进一个本不支持它的系统。
在 GCP 中：
层级自然直观：Organization → Folders → Projects。这就像组织本地文件系统一样。需要按团队分组项目？创建一个文件夹。需要区分 dev / staging / prod？再建子文件夹。想在任意层级应用策略？直接操作即可。
为什么重要：
当你为多个项目编写基础设施模板时，GCP 的结构让你能够按大脑实际的思考方式组织和管理资源。而在 AWS 中，你始终在与账户模型作斗争。
2. 加密密钥：默认密钥在项目间真正可用
在 AWS 中：
KMS 默认密钥无法跨账户共享。如果需要跨账户加密，必须使用客户管理密钥（CMK）并编写复杂的跨账户 IAM 策略。很容易留下安全漏洞，或不小心把自己锁在外面。权限模型相当混乱。
在 GCP 中：
默认加密密钥可以在组织内的项目之间无缝使用。需要自定义密钥？权限模型简洁且易于维护。你可以在不进行 AWS 那种 IAM 策略体操的情况下授予访问。
真实影响：
我在 AWS 时花了大量时间调试跨账户使用 KMS 加密的 S3 桶的“Access Denied”错误。GCP 完全消除了这一类问题。
3. 跨可用区数据传输：免费
在 AWS 中：
跨 AZ（可用区）数据传输费用为每方向 $0.01/GB，往返相当于 $0.02/GB。对于高吞吐量应用，这笔费用会迅速累积。
在 GCP 中：
同一区域内的跨可用区数据传输 完全免费。零费用。
为什么这很重要：
- 区域性 Kubernetes 集群？跨区 Pod 间通信不产生额外费用。
- 多 AZ 数据库？复制流量免费。
- 高可用架构不因弹性而额外付费。
这一个差异对数据密集型工作负载每月可以省下数千美元。
4. 网络资源：共享 VPC 改变一切
在 AWS 中：
VPC 与单个账户紧密绑定。想要集中式网络管理？需要 Transit Gateway（$36/月基础费 + 数据传输费）、VPC 对等连接，或复杂的 PrivateLink 配置。每种方案都有权衡。
在 GCP 中：
Shared VPC 允许你在一个项目（例如 SRE/平台项目）中创建网络资源，并将其共享给其他项目。应用项目的开发者甚至看不到——更别说管理——底层网络配置。
范式转变：
- 在专门的“管理”项目中统一管理网络。
- 给开发者授予其应用项目的访问权限。
- 开发者部署时无需触碰 VPC、子网或防火墙规则。
- 网络策略和安全控制集中统一。
在 AWS 中实现同等程度的隔离需要更高的架构复杂度。
5. 安全组 → 防火墙规则：再次合乎逻辑
在 AWS 中：
Security Groups 还能……用。名字让人困惑（它们并不是真正的“组”），而且绑定模型（按实例/ENI）在大规模时会变得混乱。
在 GCP 中：
它们叫 Firewall Rules。在 VPC 级别生效。可以通过标签、服务账号或 IP 范围来定位资源。模型直观，尤其是对传统系统管理员而言。
我为何更喜欢它：
作为曾经管理防火墙后转云的工程师，GCP 的防火墙规则非常直观。可以在网络层面应用规则，用标签定位特定工作负载。这正是我们自然会想到的网络安全方式。
6. 全球负载均衡器：AWS 并没有真正的对应功能
在 AWS 中：
只有区域性负载均衡器（ALB、NLB）和用于 DNS 路由的 Route 53。想要真正的全球负载均衡，需要自行搭建健康检查、故障转移以及复杂的 DNS 配置。
在 GCP 中：
Global HTTP(S) Load Balancer 提供：
- 单一 anycast IP，可将流量路由到全球最近的健康后端。
- 在 150+ 边缘节点自动完成 SSL 终止。
- 与 Cloud CDN 无缝集成。
- 通过 Cloud Armor 提供内置 DDoS 防护。
实际影响：
设想东京的用户访问位于爱荷华的应用：
- 没有全球 LB： SSL 握手在爱荷华（≈150 ms 延迟）→ 总连接时间约 450 ms。
- 使用全球 LB： SSL 握手在东京（≈5 ms 延迟）→ 总连接时间约 50 ms。
对全球化应用来说，这堪称游戏规则改变者。Global LB + Cloud CDN 的组合让动态内容也能获得类似 CDN 的性能，而不仅仅是静态资源。
7. Terraform + CI/CD：终于出现清晰的模式
在 AWS 中：
- 为 Terraform 创建 IAM 角色。
- 选择 S3 作为状态后端（哪个账户？）。
- 使用 DynamoDB 实现状态锁定。
- 为多账户部署设置跨账户 assume‑role 链。
- 编写自定义脚本管理上述所有内容。
方案可用，但感觉是拼凑出来的。
在 GCP 中：
- 创建一个管理项目。
- 启用 Storage API。
- 创建 GCS 桶用于 Terraform 状态（内置版本控制和锁定）。
- 使用服务账号冒充。
完成。更简洁、更直接，也更易于新成员上手。
成本对比
经过 4 小时的探索，我对比了所评估服务的定价。GCP 在整体上 consistently 更便宜：
- 计算实例：相同规格下便宜 10–20 %。
- 存储：区域性 GCS ($0.020/GB) vs 区域性 S3 ($0.023/GB)。
- 跨区传输：免费 vs $0.02/GB。
- Kubernetes：GKE 控制平面免费（≤15 000 pod），而 EKS 收费 $0.10 /小时（≈$73/月/集群）。
这些节省在多集群或高吞吐工作负载下会迅速累积。
“大象”问题：为什么公司仍然使用 AWS？
如果 GCP 更便宜、更直观，并且为现代架构提供了更好的特性——为什么 AWS 仍然占据市场主导？
答案和一些公司在 2025 年仍在运行 Perl 代码库和 Jenkins 流水线的原因相同：惯性、已有投资以及组织动能。
AWS 具备：
- 先发优势： 2006 年上线；大多数企业在 GCP 可行之前就已在 AWS 上构建。
- 生态锁定： 大量第三方工具、集成和 Marketplace 解决方案。
- 企业销售实力： 超过 15 年的深度客户关系。
- 人才库： 更多具备 AWS 经验的工程师。
- 服务广度： AWS 总体提供的服务种类仍多于 GCP（尽管 GCP 正在追赶）。
这并不是说 AWS 差，只是它背负着……