主权云升温，香港服务器“一台覆盖亚太”还成立吗

Bharti Airtel 在 6 月这个季度结束时，Airtel Cloud 的企业客户数是 33 家，季内新增 11 家。数字本身不大，却被反复引用，因为看上去像是"主权云正在起量"的证据。

同一场业绩沟通里还有另外几句话，信息量其实更大。Airtel 副董事长 Gopal Vittal 讲得挺直白：把工作负载从自建机房或者别家云上搬过来，本身就是个慢活；已经落在别家云上的客户，光是把数据取出来的出网费用就不便宜。目前真正跑起来的，是灾备、备份、存储和视频监控这几类；体量更大的主权云单子，还停留在受监管行业和公共部门里"逐渐成形"的阶段。

两段合起来读，画面比"主权云要来了"这句口号温和得多——现阶段主权云的客户是政府和受监管行业，先落地的是灾备存储这类边缘负载，主力系统迁移的阻力相当大。 对做跨境电商、独立站、面向海外用户 SaaS 的团队来说，这条新闻本身还不构成动架构的理由。

但有一个默认假设，确实到了该复核的时候

出海项目里有个用了很多年的默认答案：一台香港服务器，覆盖整个亚太。

这个答案过去基本成立，倒不是因为香港有多特殊，而是因为亚太大部分市场当年对"数据放在哪"没有硬性要求。用户在马尼拉、胡志明市还是雅加达，服务器都在香港，延迟能接受，也没人过问。

现在得一个国家一个国家去看了。

需要先分清楚的是，这跟"数据能不能从内地传出去"是两个方向的问题。后者约束的是数据离开来源地这一跳，香港在其中属于境外，规则来自内地——这部分栏目里那篇《香港服务器会被数据本地化卡住吗？》已经写过，不重复。这篇要讲的是反过来的那一端：你要做生意的那个国家，允不允许它的用户数据停在香港。

目标市场那一端的规则，长得不太一样

印度的框架是"默认放行"。DPDP 法本身没有设一般性的数据本地化要求，个人数据原则上可以传到境外，除非中央政府专门发文限制某些国家。但有两处会让这个默认答案翻转：一是被认定为重要数据受托人（Significant Data Fiduciary）之后，政府可以禁止特定类别的个人数据出境；二是行业规则从来单独算数——印度储备银行 2018 年那份支付系统数据存储通函，要求相关数据只能存放在印度境内，这一条跟 DPDP 并行有效，不因为新法宽松而作废。另外 DPDP 的各项条款是分阶段生效的，时间表本身也是个变量。

越南的做法更值得单独看一眼。本地存储要求来自网络安全法的配套法令 53/2022：对越南本国企业，电信、互联网、数据存储、电子商务、在线支付、出行应用、社交网络、通讯、游戏这些业务，用户个人信息、用户生成数据（账号、会话时间、支付卡信息、邮箱、IP、注册手机号）和关系数据这三类必须存在境内。但对外国企业，这个要求不是自动生效的，而是触发式的——需要公安部发出书面要求才启动，触发之后有 12 个月的合规窗口，相关数据留存不少于 24 个月。

这个区别对架构决策的意义很大。它意味着风险不是"今天没落地就违规"，而是"被点名的那一天，你能不能在 12 个月内把一套本地存储建起来"。前者要求你现在就改，后者只要求你现在留好改的余地。

与此同时，越南的个人数据保护法（91/2025）和配套法令 356/2025 已于 2026 年 1 月 1 日生效，替代了原来的 13/2023 号法令，跨境传输这条线上的评估和备案要求比之前更实。存储和传输是两套规则，得分开算。

印尼则是按主体身份切的：GR 71/2019 要求公共电子系统运营者把数据中心和灾备中心放在印尼境内，私营运营者满足条件可以放在境外。所以同样是印尼业务，接政府和公共部门的项目，跟纯粹 to C 的电商站，答案完全不同。

三个市场对下来，共同点比差异更值得注意：几乎没有哪个市场要求"全部数据必须落地"，切口都开在主体身份、行业属性和数据类别上。所以真正要回答的问题从来不是"香港服务器还能不能用"，而是"我这摊业务里，哪一小块被切走了"。

被切走之后，通常不是精细拆分，而是整块复制

这里有个和直觉相反的地方。

看到"数据要落地"，很多人的第一反应是把系统拆细：应用留香港，数据库落到目标国，只把加工过的结果传回来。听上去很优雅，但把工程账算一遍，多数团队最后不会这么做。

原因是跨区域调用要付延迟。应用在香港、数据库在孟买或者雅加达，每一次查询都要多一段跨境往返。单次几十毫秒看着不多，可一个页面背后往往是十几次甚至几十次数据库交互，串起来就是用户能明显感觉到的卡顿。而且能拆的类型有限：读多写少的好拆，强一致事务不好拆，跨表 join 的报表最难拆。

所以更常见的落地形态是粗粒度的——那个市场的业务整套复制过去，香港节点继续服务其余市场。冗余是有的，成本也高一点，但它避免了每个请求跨海一次，也让合规边界和部署边界重合，出问题的时候容易说清楚。

真正值钱的架构准备，因此不是"现在就把香港这台拆干净"，而是留住"以后能低成本再拆一次"的能力。落到具体动作上就几条：

• 数据库连接串和对象存储路径别硬编码在代码里；
• 多租户系统的租户维度要能路由到不同的数据落地点；
• 备份目标和日志投递目的地要能单独配置，别跟着整机备份一起被同步走；
• 香港这个节点尽量别做成有状态的中枢，否则任何一次切分都得动它。

这些事在没有合规压力的时候做，成本几乎为零；等到客户合同里写明"数据存储在本地"再回头改，改的就不是配置，是架构。

香港节点在这个格局里，角色反而更清楚了

需要说明的是，主权云和数据落地这两件事，短期内影响的仍然是特定类型的业务：接政企项目的、做受监管行业的、在单一市场用户量已经大到会被单独盯上的。多数中小出海团队的实际状态是——目标市场一个门槛都还没触发，香港一个节点跑完整套业务，和过去没什么区别。

而当越来越多市场开始要求落地，香港这个节点的定位其实更明确了：它承载那些不需要落地的业务，同时充当各个落地节点之间的调度和聚合层。它的价值来自网络位置——对内地和东南亚都近，数据进出没有本地限制——而不是"免备案"这个标签，更不是"放这儿就合规了"这种从来没成立过的假设。

前提是线路本身对得起这个位置。做区域枢纽意味着流量要在这里汇聚和转发，回程线路质量、晚高峰丢包、国际出口这些老问题，在多节点架构下暴露得比单机部署更明显。可以看这篇文章：香港服务器租用怎么选？2026线路、配置、带宽与避坑指南，这里不展开。

一个能立刻做的动作

如果要把这篇变成手上的事，建议就一件：把目标市场列成一张表，每个市场后面标三个字段——用户量级、是否属于受监管行业、有没有本地实体或者本地大客户。三个字段都是空的市场，香港节点继续用，不用管主权云的新闻。任何一个字段亮起来，就把那个市场的规则单独找出来看一遍，再决定要不要给它单独一套部署。

这比跟着新闻热度调整架构，靠谱得多。