从零规划一套云上 Landing Zone

很多团队的云上之旅都是这样的：先开一台 ECS 跑起来，再开一台，再开一台……直到有一天安全团队问"谁能告诉我我们云上到底有多少台机器、谁有权限登录、数据库的端口为什么对公网开着？"——然后所有人都沉默了。

Landing Zone 就是解决这个问题的。它不是某个具体产品，而是一套上云前的地基工程：在你大规模部署业务之前，先把网络、安全、身份、日志这些基础设施骨架搭好，后面所有业务资源都长在这套骨架上，天然合规、天然可控。

简单说：先修路盖房，再招商引资。

我规划了什么

我用华为云的能力，规划了一套覆盖六大支柱的 Landing Zone 架构。下面挨个说说，尽量不讲细节，讲思路。

1. 身份治理：不是所有人都能干所有事

最基础也最重要的一层。我设计了六个用户组，按角色分权：管理员、网络运维、安全审计、开发、测试、只读。每个组只能碰自己那摊事。

额外加了两个护栏：强制开启 MFA（多因素认证），以及一条自定义策略——禁止删除生产环境的核心资源。这条策略的意思是：就算管理员账号被盗，攻击者也删不掉生产数据库。

2. 网络拓扑：中心辐射型，不是蜘蛛网

网络设计我选了 Hub-Spoke（中心辐射）模式：一个中心 VPC 作为枢纽，多个业务 VPC 像辐条一样挂上去，通过企业路由器（ER）互联。

为什么不选 Full Mesh（全互联）？因为全互联的连接数是 N 的平方增长——3 个 VPC 还好，10 个 VPC 就是 45 条连接，维护噩梦。Hub-Spoke 只需 N 条，加一个 VPC 就挂一根辐条，现有拓扑完全不用动。

还有一个原则：业务 VPC 不直接绑公网 IP。所有出站流量统一走中心 VPC 的 NAT 网关出去。好处是公网 IP 数量可控、出站流量可审计，不会出现某台机器偷偷直连外网的情况。

3. 安全基线：层层收窄，最小权限

安全组按 Web → App → Data 三层设计，权限逐层收窄：

• Web 层：对外开放 80/443
• App 层：只接受 Web 层的流量
• Data 层：只接受 App 层的流量，对公网完全封闭

一个小技巧：安全组规则里用源安全组 ID 而不是 IP 网段来限定来源。这样实例增减时规则自动生效，不用每次手动改 IP 列表。

再叠加 WAF（Web 应用防火墙）和 Anti-DDoS，公网入口就有了双重防护。

4. 日志审计：出了事能查到

云上最怕的不是出事，而是出了事查不到是谁干的。

这套方案里，CTS（云审计服务）记录所有 API 操作——谁在什么时间创建了/删除了什么资源，全有日志。LTS（日志服务）汇聚应用日志，CES（云监控）配告警通知。三者配合，构成完整的可观测体系。

5. 资源组织：用企业项目和标签管好家

5 个企业项目按环境分层：生产、预发布、测试、沙箱、共享服务。再加上统一的标签策略，每 个资源都必须标明归属团队、环境、成本中心。

这样财务月底对账时，按企业项目一拉就清楚每个环境花了多少钱，不用人工数机器。

6. 治理护栏：防误删、防超支

最后加了几道软护栏：IAM 策略禁止删除生产资源（前面提过）、预算告警在花费超阈值时自动通知、沙箱环境定期自动回收。

这些不是限制效率，而是防止"凌晨三点某人不小心删错东西"这种灾难。

怎么落地

整个实施规划了 6 周，分 6 个阶段：

1. 基础治理 — 搭好 IAM 分权和审计
2. 网络基座 — 建中心 VPC 和路由器
3. 业务 VPC — 接入第一个业务环境
4. 安全加固 — 安全组、WAF、KMS 就位
5. 监控就绪 — 告警和日志通道打通
6. 验收交付 — 全链路验证，交付文档

每个阶段结束都有明确的验收标准，不是"差不多就行了"。

一点感悟

规划这套架构最大的体会是：Landing Zone 的核心不是技术难度，而是设计纪律。

技术上每一块都不复杂——建个 VPC、写条安全组规则、配个告警，单看都很简单。难的是你要忍住"先跑起来再说"的冲动，愿意花前两周不部署任何业务，只搭地基。

但这个投入是值得的。地基打好之后，后面每加一个业务环境都是"挂一根辐条"的事，安全合规自动继承，不用每次重新操心。

反之，如果先裸跑业务再补治理——我见过太多团队在这条路上走了两年，最后不得不推倒重来。

先修路，后盖房。 这句话值得写在每个云迁移项目立项文档的第一页。

本文基于华为云平台实践整理，适用于中大型团队的云上环境治理。如果你也在做类似的事情，欢迎交流。