把沙特节点当成一个点就错了：达曼的波斯湾出口和吉达的红海出口不是同一道题

2025 年 9 月 6 日那一夜，吉达外海断掉的不止一根缆

2025 年 9 月 6 日，沙特吉达近海的多条海缆被切断，涉及 SMW4、IMEWE、FALCON GCX 等系统，印度、巴基斯坦、科威特、阿联酋等广泛区域的网络受到影响。把这条消息当成"一次海底施工事故"读完就划走，是很多做中东架构的人最容易犯的错误。真正值得停下来看的，是它同时断掉的数量。

一根缆断掉，是概率问题；三根不同系统的缆在同一段近海同时断掉，是结构问题。它说明这几条缆在吉达外海共享的不只是海水，还共享同一片海底地形、同一批锚地、同一条繁忙的船舶走廊。你在架构图上把它们画成三条互为备份的线，物理世界里它们很可能是一个会被一次性击穿的故障域。

这件事对沙特尤其致命，因为沙特恰好是一个被两块完全不同性格的海夹住的国家：东边是波斯湾，西边是红海。同一个国家、同一套法规、同一张营业执照，往东出和往西出，走的是两套海缆系统、两段地缘风险、两组修复窗口。做节点选型时如果只写"沙特节点"四个字，等于把这两个完全不同的故障域当成了一个。

出海面：沙特节点第一个要定的变量

先给一个本文后面会反复用到的说法——出海面。它指的是流量离开这个国家时，第一步踏上的那段物理通路，包括从哪个海岸的海缆登陆点下海、或者从哪条陆路过境到邻国。出海面不是机房地址，也不是机房所在的城市名，而是"你的包从哪条边走出国界"。

把出海面放在第一位，是因为它决定了后面所有东西的量级。时延的第一公里不是机房里那台服务器的 CPU 决定的，而是出境那一段的海底距离和过境跳数决定的；可用性不是机房的电力冗余决定的，而是你选的那段海缆在过去两年被切断过几次、每次修了多久决定的；合规风险也不是机柜锁决定的，而是数据跨域时路径上会经过哪些司法辖区决定的。城市、配置、价格都是出海面定了之后的二级变量。

沙特境内有 15 个以上的海缆系统登陆点，这个数字本身就说明问题：登陆点多，不代表随便挑一个都一样。这些登陆点分成两簇，一簇在东岸波斯湾，核心是达曼；一簇在西岸红海，集中在吉达与延布。两簇之间的陆上距离横跨整个阿拉伯半岛，中间隔着利雅得。这意味着一旦你把应用放在一边、用户主要在另一边方向，你就要为每一次请求付一次横跨半岛的陆上往返。

东岸波斯湾：达曼这一侧接的是亚洲方向

达曼在东部省，是沙特面向波斯湾的门户。波斯湾一侧可查到的地区互联缆是 MENA Cable，在达曼登陆，设计容量约 12 Tbps。与红海一侧相比，东岸登陆的系统数量少得多，但方向性极强：这一侧的下海路径天然朝东，通往海湾对岸、南亚与更远的东亚方向。

东岸还有一层容易被忽略的优势，来自电力而不是网络。东部省的工业电网是围绕能源产业建设起来的，长期承载炼化、油气与重型工业负荷，这类地区的供电惯性和扩容逻辑，和以商业负荷为主的城市不完全一样。对需要长期跑稳定算力的业务来说，电力供给的确定性往往比机柜单价更值钱。

云区域的可得性也在往东岸倾斜。Google Cloud 的达曼区域在 2023 年 11 月上线，含 3 个可用区，截至 2026 年是沙特境内首个可用的超大规模区域；Google Cloud 与 Humain 在达曼的园区按 300 MW 规划，目标 2027 年。从行业部署角度看，一个超大规模厂商愿意把首个境内区域押在达曼而不是利雅得或吉达，本身就是对东岸电力、土地与出海条件的一次投票。当然，这说的是云厂商自己的判断，不代表任何一家 IDC 服务商在沙特有对应的落地节点——这类信息必须以官网实时披露为准。

西岸红海：吉达与延布的登陆点更密，也更可能一起断

红海一侧的清单长得多的多。AAE-1 在吉达登陆，由 Mobily 运营；2Africa 在吉达和延布都有登陆点；Blue-Raman 落在 KAEC 与吉达；JADI 是吉达—吉布提之间约 20 Tbps 的系统；Tsubame 在延布在建；Saudi Vision Cable 也在延布。再加上 SMW4、IMEWE、FALCON GCX 这些经过红海的国际系统，西岸的系统密度和总容量都明显高于东岸。

密度高是好事，也是陷阱。好事在于，可选的国际方向多：往北经地中海进欧洲，往南经曼德海峡进东非，往东南经亚丁湾接印度洋。陷阱在于，这些系统在吉达外海到曼德海峡这一段是挤在一起的，红海是一条窄而长的走廊，船舶密度高、水深条件复杂、沿岸地缘形势紧张。多缆同时受损不是理论上的尾部风险，2024 年和 2025 年已经各发生了一次。

所以西岸的正确读法不是"冗余多所以更安全"，而是"出口多、但共享走廊，必须把走廊当成单一故障域来算"。你为欧洲方向买的第二条、第三条冗余链路，如果它们的海底段都从吉达外海那一小片水域过，那么在那个特定场景下它们会一起失效，冗余数量并不等于冗余效果。

经埃及陆路与经海湾邻国：两条不在沙特境内却经常被忽略的过境路径

出海面不一定非要在沙特自己的海岸。AAE-1 的登陆点清单里，埃及有阿布塔拉特与扎法兰纳两处，地中海一侧还有马赛、巴里、哈尼亚。这意味着沙特到欧洲的一部分流量，可以先在陆上过境到埃及，再从埃及的地中海登陆点下海，绕开曼德海峡那一段。这条路更短，但代价是把可用性的一部分交给了过境国的许可与地面段维护。

另一条是经海湾邻国中转。AAE-1 在阿曼的布斯坦、阿联酋的富查伊拉、卡塔尔的多哈都有登陆点，波斯湾一侧的流量可以先到这些登陆点再上国际系统。这条路对亚洲方向友好，但它同样引入邻国因素：跨境陆上段的政策、许可与维护节奏都不在你手里。

把这两条路纳入视野的意义在于，它们给了你"第三个出海面"。只比较达曼和吉达，是在二选一；把埃及陆桥和海湾邻国中转加进来，问题才变成真正的多选题。但要注意，多选题的每一个选项都带有不同性质的不确定性：海缆断是物理事件，修复时间取决于船只和许可；过境受阻是政策事件，持续时间往往更难预测。2024 年 AAE-1 的修复被拖延，卡点就不在技术上，而在也门方面的许可未批。

2024 与 2025 两次断缆，把故障域从理论变成了可以算的量

2024 年 2 月 26 日，红海多处海缆受损，涉及 AAE-1、SEACOM、EIG，约 25% 的欧洲—亚洲—中东间流量受到影响，其中一处原因被假设为 MV Rubymar 号被弃船后拖锚所致。时间线更值得记住：到 2024 年 5 月 13 日，AAE-1 仍因也门方面许可未批而未能修复，最终在 2024 年 7 月完成修复。也就是说，从受损到恢复，中间跨了差不多四个月，其中相当一部分时间不是用来修缆，而是用来等批文。

2025 年 9 月 6 日那次又是另一个形状：吉达近海一次事件同时切断多条系统，影响范围扩散到印度、巴基斯坦、科威特、阿联酋。一个是拖锚、许可拖延、跨月修复；一个是多缆同时、区域扩散。两次事件的共同点是，受损的不是某一家运营商的某一条缆，而是"这一段水域"。

由此可以给出一个可操作的判断方法：不要按"我有几条出海链路"来估可用性，要按"我这几条链路里，有几个会在同一次事件中同时失效的分组"来估。这个分组就是故障域。在沙特，红海—吉达外海是一个明确的故障域；红海—延布因为登陆位置不同、海底段走向不同，可以算作弱相关的第二个域；东岸波斯湾是第三个域；经埃及陆桥是第四个，且它和红海海域的故障相关性很低，但引入了过境政策这一新的风险项。

用户在哪一侧，决定应用该放哪一侧：三种业务三种放法

把出海面和业务方向对上，结论会变得很直接。

第一种，用户主要在亚洲——印度次大陆、海湾邻国、东南亚、中国方向。这类业务放东岸更合理，因为出境第一步就是朝东，路径上少一次横跨半岛的折返。典型场景是面向南亚用户的 SaaS、游戏与内容分发，以及东岸能源、工业企业自己的生产系统。

第二种，用户主要在欧洲和非洲。这类业务放西岸，用吉达或延布的出口下红海、经地中海进欧洲，或者走埃及陆桥。硬要把欧洲方向的应用放在达曼，等于让每一个请求先在半岛内部横穿一次，再折回红海下海，多出来的一进一出会直接体现在首包时延和抖动上。

第三种，用户主要在沙特本地、且涉及个人数据。这类业务的第一约束不是时延而是数据位置，出海面的选择要让位于合规安排，出海只作为对外互联的部分存在。这类场景放到下一节和 PDPL 那一节一起讲。

这里要补一句限制条件：面向某个方向"更近"是拓扑意义上的判断，实际延迟仍需按运营商、线路和具体机房测试确认。同一城市不同机房、不同上游的差别，有时能抵消掉一个方向的拓扑优势。选型时把它当起点而不是终点。

应用与数据库分开放：一次写入横穿整个半岛要付什么代价

东西两岸之间横穿整个阿拉伯半岛，这个距离决定了"应用放一边、数据库放另一边"不是随手就能做的决策。应用层是无状态的，可以多副本、可以就近；数据库是有状态的，写入要在主库上落盘，复制要跨城传输。一次写入如果每次都要跨越半岛往返确认，事务的响应时间里就多了一段你无法通过加机器消除的物理时延。

判断能不能分开，看三个变量。第一是写比例：读多写少的业务，把读副本放到用户侧、主库留在合规侧，代价可控；写密集的业务，比如订单、支付、库存扣减，跨城写入会被放大成每个事务的额外等待。第二是一致性要求：能接受秒级复制延迟的，可以做异步复制和读写分离；要求强一致的，跨城同步提交的代价会直接压在响应时间上。第三是故障切换的容忍度：如果主库所在那一侧的出海面断了，业务还能不能靠另一侧活着，这需要在切换策略里提前设计，而不是断缆当晚临时决定。

一个相对稳的排布是：应用与接入层按需在两侧部署，数据库主副本放在合规与数据位置要求最明确的一侧，另一侧放只读副本或缓存层；跨岸之间只跑复制流量和管理流量，不跑用户请求的东西向往返。这个排布的代价是架构复杂度上升，收益是任何一侧出海面失效时，业务不至于整体失联。是否值得，取决于业务对中断的容忍时间有多短。

带宽与 IP 的账，要按出海面算而不是按城市算

带宽预算最容易算错的地方，是把"单岸峰值"当成"总带宽需求"。如果两侧都要承载用户，那么每一侧都要按各自峰值独立配，不能按总和打折——因为它们不会互相救场，反而在一侧断缆时，另一侧要接住全部流量。这意味着按 N+1 的思路配，实际要按"单侧能扛住全量的一部分"来配，冗余系数通常比单地部署更高，成本也随之上升。

IP 的账同样要按岸算。地址段的归属、路由宣告的位置、Anycast 的覆盖点，都和出海面绑定。同一个地址段在东西两岸同时宣告，故障时的收敛行为和只在单岸宣告完全不同。需要向服务商问清楚的，是这个段从哪个岸出、故障时能不能自动切到另一个岸、切换后源地址会不会变——源地址变化对有白名单的下游系统是硬伤。

还有一项容易被漏掉：回源流量。如果你的沙特节点只是边缘，真正的源站还在欧洲或亚洲，那么回源路径同样要过一次出海面，而且方向可能和用户方向相反。用户从吉达进来、源站在新加坡，回源就要从红海出去绕一圈，这段流量要单独计费、单独算时延。把回源流量和用户流量画在同一张图上，才会发现带宽账里少算了哪一块。

以上都只涉及方法，不涉及价格。带宽与 IP 的具体计费口径需实时询价，以官网实时报价为准，不同岸、不同上游、不同承诺带宽区间的差异都很大，任何提前给出的固定数字都不可靠。

PDPL 生效之后，数据位置不再只是技术问题

沙特个人数据保护法自 2024 年 9 月 14 日起执行，要求境内的个人数据留在王国境内，跨境转移须有经 SDAIA 认可的保障措施或合同条款。这一条把"数据放哪"从架构偏好变成了合规义务，而且它的判定单位是"境内"而不是"某个城市"——这一点反而给了出海面选择一些空间：东西两岸都在境内，把数据从吉达搬到利雅得或者达曼，不构成跨境。

真正需要盯的是出境那一刻。日志、埋点、用户画像、客服工单这些看起来无害的数据，一旦包含可识别到自然人的信息，走哪个出海面、在哪个国家落一次地，就都要纳入判断。举例说，把分析类日志经红海出口送到欧洲的分析平台，和经东岸送到亚洲的分析平台，面对的跨境路径与途经辖区不同，需要准备的保障措施也不同。

工程上可行的做法是分层：身份、支付、联系方式这类强个人信息严格留在境内，且备份和容灾副本也在境内；脱敏后的聚合指标可以出境做分析；需要出境的部分，提前把 SDAIA 认可的保障措施或合同条款准备好，而不是上线后再补。这套分层和出海面的关系是：境内部署位置决定时延与冗余，出境部分决定合规工作量，两者要分开算。

云区域与自建托管的可得性：东西两岸不是同时具备的

如果走公有云路线，可得性本身就是地区差异的一部分。Google Cloud 达曼区域 2023 年 11 月上线、3 个可用区，截至 2026 年是沙特境内首个可用的超大规模区域；AWS 沙特区域计划投入 53 亿美元、3 个可用区、计划 2026 年上线；Microsoft Azure 的 Saudi Arabia East 三个可用区 2024 年 12 月建成、计划 2026 年第四季度正式可用；Oracle 在利雅得与吉达分别于 2022 年、2024 年落地；华为云利雅得区域在 2024 年落地。

把这些时间和地点排在一起看，规律很清楚：已公开落地的区域大多集中在中部利雅得与西岸吉达，东岸的超大规模区域到 2026 年才由达曼的 Google Cloud 区域率先可用。如果你的架构强依赖某个云厂商的托管服务，那么"选东岸"这个决定很可能暂时落不了地，只能退而求其次：在中部或西岸用云，在东岸用自建或托管补上接入层。

自建与托管路线的变量则是另一套：机柜、电力、跨境带宽、本地运维人力、备件到位时间。这些东西在不同城市的差异，往往不是价格而是可得性——某个城市有没有可用的机柜、能不能拉到你要的那条出海通路，比单价更能决定项目排期。这类信息没有统一的公开口径，只能逐项向服务商确认。

方案对比：三种业务形态对应三种放法

把前面的条件收拢起来，方案层面可以分成三类，每一类的判断依据不同。

第一类是亚洲方向为主、对时延敏感、数据可留在境内的业务。放东岸达曼，出海面走波斯湾，接入层与计算层同侧，数据库主副本放境内东部或中部。冗余靠"东岸主用 + 经海湾邻国中转备用"来兜，而不是靠红海那一侧。

第二类是欧洲非洲方向为主、或者需要多向国际出口的业务。放西岸吉达，延布作为弱相关第二出口。这里的关键动作是把吉达和延布当成两个域来配，而不是当成同一个城市的两个机房；同时为欧洲方向准备经埃及陆桥的应急路径，因为 2024 年那次修复拖了近四个月，纯海缆方案缺少可用的应急出口。

第三类是本地合规优先、用户全在境内的业务。地点选择让位于数据位置与运维可达性，出海只保留必要的对外互联，重点放在境内双岸互备与跨域复制，而不是国际出口的多样性。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。就本文讨论的这类双岸国家而言，从行业部署角度看，真正需要提前锁定的不是某个城市的机柜，而是出海面、故障域分组与数据位置这三项的组合关系，其余参数都可以在这三项确定后再逐项谈。

部署风险清单：出海面判断错了会在哪五处付出代价

• 把两岸当成同一故障域。问题：在吉达一次性断缆时，以为自己还有三条备份链路，实际三条同段失效。原因：多系统的海底段在同一走廊重叠，逻辑冗余不等于物理分离。判断：凡是出口段都从吉达外海过的系统，都应按单一域计。规避：在架构图上按海底走廊而不是按系统名分组，确保至少有一个域是物理分离的（如东岸或埃及陆桥）。
• 按单点峰值而不是按单岸全量配带宽。问题：一侧断缆后，另一侧带宽瞬间打满。原因：带宽按常态峰值预算，没有把故障态的流量转移算进去。判断：冗余系数必须按"另一侧接住多少"来定，而不是按平均负载。规避：先定故障态下愿意保住多少比例的流量，再反推每一侧的带宽，这部分成本不能省。
• 应用与数据库跨岸放置却没有算写入代价。问题：上线后每个写事务都多出一段跨半岛往返，接口超时率上升。原因：只按地理距离估时延，忽略了同步复制与事务确认的放大效应。判断：写密集且要求强一致的业务不适合跨岸主从。规避：读多写少的做读写分离，写密集的把主库与同侧应用放一起，另一侧只放缓存与只读副本。
• 把修复时间按技术修复时间估。问题：以为断缆两周能修好，实际拖了近四个月。原因：红海区域的修复还受沿岸许可与通行条件约束，2024 年 AAE-1 就是卡在也门方面的许可上。判断：这类事件的恢复时间上限由政策环节决定，不由工程能力决定。规避：容灾方案按"数月级不可用"做最坏打算，应急路径必须包含非海缆选项。
• 合规分层没做，出海时才补。问题：日志与用户数据默认出境，PDPL 执行后被要求整改。原因：数据分层在架构阶段没做，出境路径上也没有准备 SDAIA 认可的保障措施或合同条款。判断：PDPL 自 2024 年 9 月 14 日起执行，强个人信息留在境内是最省事的做法。规避：上线前完成数据分类，能不出境的不出境，必须出境的提前准备保障措施与合同条款。

把这五条放在一起看，会发现它们指向同一个动作：节点选择不是一次询价行为，而是一件需要逐项确认的事——出海面归哪个故障域、带宽按故障态怎么配、数据库跨岸怎么摆、最坏情况的恢复时间按什么量级估、数据分层怎么切——每一项都要落到书面确认，而不是口头承诺。一万网络在处理这类跨境与多岸部署咨询时的思路与此一致，先把可确认项逐条核实、把不可确认项标注为待定；具体到某个国家的落地方式与当期报价，仍需以官网实时信息或咨询确认为准。

本文不解决的三个问题：跨云迁移步骤、沙特公司注册与税务、具体产品报价

第一，本文不提供跨云迁移的具体步骤。文中提到的云区域可得性只用来说明东西两岸在时间点上的差异，不涉及从某一个云迁到另一个云的操作流程、数据搬迁方式或停机窗口设计。

第二，本文不讨论沙特的公司注册与税务问题。在沙特落地业务涉及的主体设立、许可、税种与申报义务属于法律与财税范畴，需要咨询当地持牌机构，不作为节点选型的技术依据。

第三，本文不给出具体产品报价。带宽、IP、机柜与算力的计费口径受出海面、承诺带宽、上游与合同期限影响，全部需实时询价，以官网实时报价为准，本文只讨论计算方法和需要向服务商确认的条目。

关于沙特节点最常被追问的六个判断

1. 达曼和吉达到底差在哪？差别不在城市级别，而在出海面。达曼面向波斯湾，可查到的地区互联缆是 MENA Cable，约 12 Tbps，天然接亚洲方向；吉达面向红海，登陆系统密集，包括 AAE-1、2Africa、Blue-Raman、JADI、SMW4、IMEWE、FALCON GCX 等，接欧洲非洲方向。两地之间陆上横跨半岛，不是同城双机房的关系，而是两个故障域的关系。

2. 红海断缆时，欧洲方向的流量会怎么样？不会立刻断，但会绕行且拥塞。2024 年 2 月 26 日那次多缆受损，约 25% 的欧洲—亚洲—中东间流量受影响；2025 年 9 月 6 日吉达近海多缆切断，影响扩散到印度、巴基斯坦、科威特、阿联酋。可用流量的下降会推高剩余路径的时延与丢包，实际延迟仍需按运营商、线路和具体机房测试确认。

3. PDPL 是不是要求所有数据都留在境内？按已核验的表述，PDPL 自 2024 年 9 月 14 日起执行，要求境内的个人数据留在王国境内，跨境转移须有经 SDAIA 认可的保障措施或合同条款。约束对象是个人数据，不是全部数据。境内部署位置的选择（东岸还是西岸）不构成跨境，真正需要准备保障措施的是出境那一步。

4. 面向亚洲用户放东岸一定更快吗？拓扑上更近，但不保证更快。东岸出海第一步朝东，路径上少一次横穿半岛的折返，这是结构性优势；但最终延迟还取决于具体机房的上游、路由策略与对端网络。判断时把拓扑优势当起点，用实测确认，不要只看地图上哪边更近。

5. 应用和数据库能不能分开放两个城市？能，但要看写比例和一致性要求。读多写少的业务适合跨岸读写分离，主库留在合规侧、另一侧放只读副本；写密集且要求强一致的业务不适合，跨半岛的同步确认会被放大成每个事务的额外等待。无状态的接入层可以两侧都放，有状态的主副本不宜随意拆分。

6. 没有公开报价时预算怎么估？先算量再问价。按故障态而不是常态配带宽——确定一侧失效时另一侧要接住多少流量；IP 按岸算而不是按总数算，确认段的出海位置与故障切换行为；回源流量单独列一项。量算清之后，带宽与 IP 的计费口径需实时询价，以官网实时报价为准，不要用行业估算值直接当预算。

达曼与吉达这道题的答案，取决于你的流量往哪边出

回到开头那次断缆。同一个国家，同一个法规环境，同一张发票，往东出和往西出是两套完全不同的物理系统、两段完全不同的风险历史。2024 年 2 月 26 日红海多缆受损、约 25% 的欧亚中东流量受影响，AAE-1 因也门方面许可未批拖到 2024 年 7 月才修复；2025 年 9 月 6 日吉达近海多缆同时切断，影响扩散到印度、巴基斯坦、科威特、阿联酋。这两次事件的修复窗口都在按月计，不是按小时计。

所以选型的顺序应该是：先定流量往哪边出——亚洲方向优先东岸波斯湾的达曼，欧洲非洲方向优先西岸红海的吉达与延布；再定故障域分组，确保至少有一个物理分离的第二域；然后定数据分层与数据库位置，让合规约束先落地；最后才谈带宽、IP、算力与价格。把这个顺序倒过来，先问哪个城市便宜，就会在断缆那天把差价连本带利还回去。

本文的海缆、法规与云区域信息来源

海缆中断事件与修复时间线：2024 年 2 月 26 日红海多处海缆受损（含 AAE-1、SEACOM、EIG）及约 25% 流量受影响的比例、MV Rubymar 号拖锚假设、AAE-1 至 2024 年 5 月 13 日因也门方面许可未批未修复、2024 年 7 月完成修复，以及 2025 年 9 月 6 日吉达近海 SMW4、IMEWE、FALCON GCX 等被切断的公开报道与行业通报。

海缆系统与登陆点：AAE-1 系统资料（2017 年 6 月商用，原设计 40 Tbps / 5 对纤，2022 年 5 月经 Infinera ICE6 800G 升级后设计容量超 100 Tbps，登陆点含马赛、巴里、哈尼亚、阿布塔拉特/扎法兰纳、吉达、吉布提、亚丁、布斯坦、富查伊拉、多哈、卡拉奇、孟买等）；2Africa、Blue-Raman、JADI（吉达—吉布提约 20 Tbps）、Tsubame、Saudi Vision Cable、MENA Cable（达曼，约 12 Tbps）的公开系统资料；沙特境内 15 个以上海缆系统登陆点的统计口径。

法规：沙特个人数据保护法（PDPL）及其自 2024 年 9 月 14 日起执行、境内个人数据留存与跨境转移须经 SDAIA 认可的保障措施或合同条款的相关要求，以 SDAIA 公开发布为准。

云区域可得性：Google Cloud 达曼区域 2023 年 11 月上线（3 个可用区）、Google Cloud 与 Humain 达曼园区按 300 MW 规划目标 2027 年、AWS 沙特区域计划投入 53 亿美元与 3 个可用区计划 2026 年上线、Microsoft Azure Saudi Arabia East 三可用区 2024 年 12 月建成计划 2026 年第四季度正式可用、Oracle 在利雅得与吉达分别于 2022 年与 2024 年落地、华为云利雅得区域 2024 年，均取自各厂商公开发布信息，实际可用状态以厂商官网为准。