摘要
- Cloud APAC 最强的公开身份锚点是AS132399 的 APNIC RDAP，其将 ASN 命名为
ATICLOUD-AP，描述为 SITA Cloud APAC，国家为 SG，注册人为国际航空电信组织 (SITA)。 - RIPEstat 的AS 概览当前将持有者报告为
ATICLOUD-AP - SITA Cloud APAC，并将 ASN 标记为已宣布，这比休眠的注册对象证据更强。 - 当前公开路由仍然狭窄。RIPEstat路由状态显示四个 IPv4 前缀，没有可见的 IPv6 前缀和一个观察到的邻居；RIPEstatASN 邻居将可见邻居识别为 AS15830。
- 已宣布的前缀可见，路由源验证检查为有效。RIPEstat已宣布前缀列出 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 和 57.191.160.0/19；RIPEstat 对这些四个源的验证返回有效状态。
- SITA 自身的公开页面显示了该工作负载可能具有操作重要性的原因。SITA 表示其服务航空通信和信息技术，在 1000 多个机场工作，并销售SITA Connect作为跨航空位置的管理连接。
- 公开记录没有识别 Cloud APAC 背后的数据中心、机架数量、服务器所有权、支持升级路径、备份边界、客户导出程序或多站点故障切换设计。网络证据等级为中等：当前 IPv4 路由可见且已验证，但客户可用的弹性尚未被证实。
云账单最终还是落在新加坡的机架上
云服务被作为抽象出售：区域、门户、管理连接、应用程序主机、支持队列和月度合同。用户看到的是一个账户、一个服务台、一个 IP 地址、一个延迟目标或一个服务仪表盘。操作系统看到的是更普通的东西。它看到机柜中的服务器或虚拟机、路由器端口、交叉连接、电源路径、冷却封装、存储池、备份目标、上游供应商以及能够在客户截止日期前完成变更的人员。
这是阅读 Cloud APAC 的有效方式。公开足迹看起来不像一个带有套餐卡和结账页面的零售 VPS 公司。它看起来像 SITA 航空技术环境中的一个新加坡编码的网络和云标记。APNIC RDAP for AS132399将 ASN 命名为ATICLOUD-AP，描述为 SITA Cloud APAC，国家为 SG，注册人为国际航空电信组织 (SITA)。RIPEstat 的whois 视图显示相同的 AS 名称、描述、国家和 APNIC 源，以及从 AS15830 导入和导出的路由策略行。
这些记录足以锚定公开身份。但它们不足以将“Cloud APAC”视为一个完整的、客户就绪的架构。客户无法仅从 ASN 推断服务是否使用自有机架、托管、租用裸机、虚拟化集群、公共云后端、机场边缘设备或供应商管理的容量。也无法推断同一平台是否承载旅客处理、机场连接、客户服务系统、内部应用程序或仅网络控制基础设施。
这种区别很重要，因为 SITA 更广泛的业务不是随意的基础设施。SITA 的官网称该公司是航空通信和信息技术的专家，并报告遍布国际目的地、客户和机场。其会员页面表示超过 13,500 个行业站点通过 SITA 网络连接，几乎每家航空公司和机场都与 SITA 有业务往来。其航空公司页面将综合航空公司系统作为旅客旅程的一部分。当云或网络元素处于该领域时，故障可能会波及值机柜台、离港控制系统、行李操作系统、机场连接、航空公司办公室以及支持团队。
因此，正确的问题不是 Cloud APAC 是否存在。公开记录表明它作为一个已路由的 ASN 存在。正确的问题是客户账户背后的容量是否具有航空运输和区域企业用户实际需要的弹性。如果机架断电，哪些服务会迁移？如果上游路径故障，哪条替代路径承载流量？如果硬件缺货，哪些工作负载会等待？如果支持链跨越时区或法律实体，谁负责事件时钟？如果客户需要迁移，是否能在账户或供应商关系成为问题之前导出可用数据？
公开路由证据证明了什么
AS132399 不是一个过时的条目。RIPEstat 的AS 概览报告持有者为ATICLOUD-AP - SITA Cloud APAC，并将 ASN 显示为已宣布。RIPEstat 的路由状态也显示当前的 IPv4 可见性：325 个 RIS 对等体在检查时间看到了该 ASN，四个 IPv4 前缀，16,896 个 IPv4 地址。这比没有观察到的路由的注册记录要强得多。
当前前缀列表是具体的。RIPEstat已宣布前缀在最近两周窗口内列出 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 和 57.191.160.0/19。RIPEstat 前缀概览检查显示这四个前缀由 AS132399 始发：57.250.51.0/24、57.191.95.0/24、57.191.96.0/19和57.191.160.0/19。
注册地理情况是混合的，应谨慎解释。APNIC RDAP 对于57.191.95.0/24将范围命名为SITA-SPC-SIN-add，国家 SG。APNIC RDAP 对于57.191.96.0/19命名为SITA-SPC-SIN-S1，国家 SG。APNIC RDAP 对于57.191.160.0/19命名为SITA-SPC-SIN-S2，国家 SG。然而，APNIC RDAP 对于57.250.51.0/24返回一个更广泛的 57.250.0.0 到 57.250.255.255 注册，命名为SITA-SC-Infrastructure，国家 BE，并有 SITA 实体。
这种混合并不使路由不可靠。但它意味着国家标签不应被用作完整的数据驻留证明。一个前缀可以注册在一个国家值，由亚太 ASN 始发，用于其他地方的基础设施，通过全球运营商路由，或分配给在多个司法管辖区存储数据的服务。对于客户来说，注册国家代码是起点。约束性事实是合同、设施位置、备份位置、支持工单位置、日志记录位置和导出路径。
路由源态势是积极的。RIPEstat 路由源验证对于57.250.51.0/24、57.191.95.0/24、57.191.96.0/19和57.191.160.0/19在检查时间返回 AS132399 的有效状态。有效的路由源验证不能防止每一个路由事件，但降低了源配置错误和劫持风险。在市场上一些小的托管网络仍有未知或不完整的 RPKI 态势，这是一个有意义的积极信号。
最大的警告是 IPv6。RIPEstat 路由状态在检查时间显示 AS132399 没有可见的 IPv6 前缀，尽管 APNIC whois 衍生的记录包括与 AS15830 的 IPv6 导入和导出策略行。这可能反映服务设计选择、未宣布的 IPv6 计划、收集器可见性问题或不需要在此 ASN 下可见 IPv6 的交付设计。但这仍然对客户很重要。如果 Cloud APAC 是现代托管或管理服务的一部分，双栈可达性、IPv6 过滤、路由源授权和监控应直接回答，而不是从仅 IPv4 的公开视图猜测。
一个可见的上游是设计问题，而非定论
路由策略和观察到的邻居图指向相同的方向。RIPEstat 的AS132399 的 whois 数据显示从 AS15830 导入接受任意，并导出到 AS15830 宣布 AS132399。RIPEstat 的ASN 邻居视图显示一个独特的可见邻居 AS15830。RIPE RDAP for AS15830将 AS 名称识别为 Equinix，并描述 Equinix Internet Access / Equinix Connect 作为全球 IP 传输平台。RIPEstat 的AS15830 的 AS 概览报告持有者为 Equinix，并且PeeringDB将 Equinix AS15830 列为网络服务提供商。
Equinix 是一个合理且高质量的上游环境，适用于面向新加坡的网络。Equinix 的新加坡页面描述了本地数据中心和互联存在，包括一般的新加坡数据中心页面、SG1 设施在 Ayer Rajah 和SG3 设施。这个环境使 Cloud APAC 路由路径可读：可见的互联网边缘与大型互联和传输生态系统相关联，而不是未知的消费者 ISP。
但一个可见的上游不等于完全冗余。至少需要区分四个层面。路由多样性询问 BGP 是否有多个路径。运营商多样性询问这些路径是否来自独立的商业供应商。物理多样性询问交叉连接、会面室、路由器、电源线路和建筑入口是否避免共享故障。容量多样性询问在第一条路径故障后，存留路径是否能承载负载。公开 BGP 可以提示前两个，但对后两个说得很少。
对于 AS132399，公开路由收集器当前显示一个可见上游。这可能对该 ASN 扮演的角色是足够的。如果 Cloud APAC 是一个受控的企业边缘、内部云段或由私有连接支持的区域入口，可见的互联网路径可能不是整个设计。如果它是作为面向客户的托管销售或依赖的，一个可见上游引发了采购问题。客户应该询问是否存在第二条互联网传输路径、私有 WAN 路由、云互联、冷备站点、单独 DDoS 路径或手动故障切换程序。
Equinix 的存在也可能造成一个微妙的采购错误。看到一个强大的上游品牌并不证明客户拥有专用机柜、专用端口、多样化的交接点或任何权利直接联系 Equinix 支持。客户合同可能是与 SITA 签订的，路由通过 Equinix，机架可能在 Equinix 设施或其他地方，操作工单可能通过服务台才能到达运营商手中。所有这些安排都可以工作。它们只需要在事件发生前记录下来。
这对于维修窗口尤其如此。供应商可以有出色的上游连接，但仍然可能因光纤部件故障、防火墙饱和、变更冻结、访问控制问题、本地智能手延迟或网络路径之外的存储故障而放缓。可见的 AS 路径告诉客户数据包去哪里，但不告诉客户谁有钥匙、谁有备件、谁有权回滚、谁决定何时可以打破维护窗口。
SITA 的航空角色提升了小故障的后果
SITA 的公开页面解释了为什么该基础设施值得比普通小型托管名称更仔细的阅读。SITA 主页将公司描述为航空通信和信息技术专家，并展示了广泛的机场和客户覆盖。其SITA 会员页面表示会员基础包括航空公司、机场和其他航空生态系统参与者，并且超过 13,500 个行业站点通过 SITA 网络连接。其SITA Connect页面销售跨 750 多个目的地、600 个预连接机场的管理连接，包括 SD-WAN、SASE 级安全性、多云连接和对航空应用的支持。
这些是广泛的产品和企业声明，不是具体的 Cloud APAC 设施图。它们仍然很重要，因为它们描述了 Cloud APAC 出现的环境。航空运输依赖于航空公司、机场、地勤、政府、行李系统、旅客处理系统、边境系统、服务台和网络之间的协调。该领域中的区域云或网络节点可能比零售主机承载更少的面向公众的网站，但仍然可能具有运营敏感性。一个数据包路径可能支持值机工作站、离港控制主机、行李消息、航空公司办公室 VPN、管理机场边缘、云管理平面或监控通道。
SITA 的服务管理页面增加了一个重要的支持信号。它描述了一个符合 ITIL 的服务管理套件、24/7 全球可用、主动监控以及对机场和航空公司运营需求的支持。关于我们页面称 SITA 服务管理由 SITA 全球服务支持，并指向 24/7 支持、全球客户服务和大量专业员工。这些声明在企业层面令人放心，但它们没有回答 Cloud APAC 特定的问题：哪个团队拥有 AS132399 事件，哪个团队拥有数据中心现场操作，以及哪些服务目标适用于特定的客户工作负载？
支持边界是基础设施的一个真实部分。在云和托管故障中，困难的问题通常不是识别出有东西坏了。困难的问题是让正确的权威迅速行动。一条路由可能需要运营商工单。服务器可能需要笼子中的现场操作。虚拟集群可能需要存储故障切换。客户可能需要 DNS 变更。安全事件可能需要防火墙规则、账户锁定、取证保留或备份隔离。在大型航空供应商中，支持链可能是成熟的，但也可能按产品、地理位置、严重性和合同进行分割。
因此，对于客户来说，实际问题不是“SITA 有服务台吗？”实际问题是我的 Cloud APAC 服务是否包含我需要的升级路径。它应命名严重级别、首次响应目标、恢复目标、非工作时间路径、联系 Equinix 或其他设施运营商的权限、客户电子邮件故障时的通信渠道以及事后报告标准。世界上最好的服务台，如果客户的特定账户不在升级安排之内，也是无用的。
新加坡是一个强大的枢纽，但有硬性电力限制
Cloud APAC 的 SG 国家标记和新加坡命名的前缀将该服务置于一个既具吸引力又受限的市场。新加坡是亚太地区最重要的互联枢纽之一，拥有密集的运营商、云和企业生态系统。这就是为什么新加坡网络边缘对航空、金融、物流和区域企业工作负载具有价值。它靠近主要海底电缆系统、区域云需求、跨国总部以及整个东南亚的机场运营。
同样的优势也造成了稀缺性。新加坡的绿色数据中心路线图表示该国旨在近期提供至少 300 MW 的额外数据中心容量，并通过绿色能源部署提供更多。IMDA 将其围绕可持续数字基础设施和能源效率进行框架化。这一政策背景对任何使用新加坡容量的提供商都很重要，因为云经济学不仅仅是机架经济学。它们是电力、冷却、土地、监管、可持续性和硬件更新经济学。
对于 Cloud APAC，公开证据没有识别设施。Equinix 路由环境使 Equinix 成为相关的传输和互联参考，但它并不证明 Cloud APAC 服务器在特定的 Equinix 建筑内。APNIC 前缀以SIN命名暗示面向新加坡的网络资源，但并未命名机架、笼子、机柜、数据厅或电源馈线。客户仍然需要设施声明：主站点、辅助站点、备份站点、管理平面位置、数据驻留边界和供应商访问安排。
这就是安装容量与可用容量的区别所在。提供商可以拥有地址空间和上游，但没有足够的备用计算能力来撤离故障集群。可以拥有机柜，但没有足够的电力余量用于增长。可以拥有备份存储库，但没有足够的恢复带宽用于区域事件。可以拥有单一连接良好的设施，但没有实际的备用站点。可以与大型数据中心运营商签订合同，但仍受访问窗口、远程现场操作队列或变更审批的限制。
新加坡的政策环境使这些问题更加具体。如果额外的数据中心容量与能源效率和绿色能源部署挂钩，那么新机架的成本和可用性可能会影响客户增长、续约定价和迁移选项。购买管理容量的客户应询问该平台是否在新加坡有扩展余量，溢出是否转到其他国家，备份存储是否离开新加坡，以及未来的硬件更新是否会改变本地性承诺。
数据主权也有更多层面，不仅仅是生产机架位置。服务可以将应用程序数据存储在新加坡，而日志、监控指标、支持工单、计费记录、配置备份或快照则位于其他地方。SITA 的全球运营足迹可能对支持覆盖是一个优势，但它使数据地图更加重要。关心新加坡驻留或亚太本地性的客户应要求生产数据、备份、日志、遥测、工单、管理员访问和分包商访问的地图。
托管容量通过普通路径失败
最可信的 Cloud APAC 失败路径并不奇特。第一个是机架或平台故障。主机节点、存储架、架顶交换机、防火墙、虚拟机管理程序集群、电源电路或管理设备可能故障。如果服务是虚拟化的，客户需要知道工作负载是否会在另一个节点上重新启动，存储是否复制，是否保留了备用容量，以及重新启动是否已在负载下测试。
第二个是上游故障。RIPEstat 显示 AS15830 是 AS132399 的可见邻居。如果该路径是唯一的公共互联网路由，那么 BGP 会话、运营商服务、物理交叉连接、路由器策略或 DDoS 保护路径中的故障可能会影响可达性，即使服务器健康。如果存在公共收集器未显示的私有航空网络路径或第二条运营商路径，客户应在服务设计中看到记录。如果没有，客户应了解风险并相应调整工作负载规模。
第三是硬件库存故障。云和管理服务客户很少看到备件架，但它决定了维修时间。故障磁盘、光纤模块、路由器线卡、防火墙设备、电源或存储控制器可能容易诊断但难以更换。在受限的数据中心市场中，交货时间和访问窗口很重要。客户应询问关键备件存放在何处，谁可以安装它们，哪些部件由供应商支持，以及哪些故障触发迁移而非维修。
第四是支持故障。SITA 的公开支持材料表明了规模和流程，但任何特定的 Cloud APAC 依赖关系仍然需要命名的升级路径。区域事件可能涉及网络工程、设施运营、服务管理、安全、应用程序所有者、客户账户团队和第三方传输提供商。如果服务重要，客户应知道谁领导桥梁电话，如何沟通状态，以及谁可以批准紧急变更。
第五是计费或供应商合同故障。这听起来是行政性的，但实际上它是基础设施。如果运营商合同、设施账户、软件订阅、支持权利或客户发票不一致，服务可能在最糟糕的时间被暂停或降级。对于出现在更大 SITA 运营环境中的提供商名称，客户应确保法律实体、产品名称、服务描述、支持权利和数据退出权利都一致。
第六是迁移故障。客户需要离开的那一天，才会发现服务是否可移植。能否导出机器映像、数据库、对象数据、日志、防火墙规则、DNS 记录、访问控制设置和监控历史？能否移动 IP 地址，还是必须重新编号？备份是否以标准格式可用？如果账户被暂停、争议或终止，是否有干净交接？一个没有经过测试的退出路径的云服务是一个依赖陷阱，即使在正常周表现良好。
恢复证据必须与工作负载匹配
恢复语言通常过于通用。供应商可能说服务是备份、监控或全天候支持的，但这些词的含义不同，取决于 Cloud APAC 实际为特定客户承载什么。网络边缘、管理虚拟服务器、私有云节点、面向乘客的应用、办公室 VPN 和监控收集器都以不同方式失败。恢复证据应足够具体，以便客户看到哪些部分先返回，哪些部分等待。
对于网络服务，恢复证据从可达性开始。客户应看到 AS132399 如何被监控，四个可见 IPv4 前缀如何检查，当路由被撤销时什么告警触发，以及如果 AS15830 路径降级谁采取行动。如果服务具有私有航空连接或其他非公共路径，客户应看到该路径如何单独测试。公共路由收集器可以显示 ASN 可见，但不能显示单个站点、防火墙区域或客户隧道是否已正确故障切换。
对于托管计算，恢复证据从工作负载状态开始。如果服务器故障，客户购买的是自动重启到另一个节点、手动重建、映像恢复、应用程序恢复还是仅尽力维修？恢复目标是否包括操作系统、附加存储、防火墙策略、证书、身份配置、监控检查和日志？如果备份恢复虚拟机但留下网络策略或 DNS 记录，从用户角度来看服务实际上并未恢复。
对于托管应用程序，恢复证据必须包括依赖关系。航空公司或机场系统可能依赖身份提供者、消息队列、数据库、第三方 API、本地工作站和网络隧道。仅恢复应用服务器可能使用户无法交易。客户应要求依赖关系列表，标识哪些系统一起恢复，哪些有独立时钟，以及哪些在 Cloud APAC 责任范围之外。
对于数据，关键区别是备份与可用恢复。备份可以存在但仍然在业务上失败，如果它太旧、太慢、不完整、在账户暂停期间不可访问、存储在错误司法管辖区或与损坏的凭据集绑定。客户应要求最新的成功恢复测试、最大的测试恢复大小、最近失败的恢复、保留的恢复点、删除过程和导出格式。在新加坡本地性情况下，相同证据应说明备份副本和恢复暂存区的位置。
对于事件通信，恢复证据必须包括带外路径。如果服务支持电子邮件、客户门户、VPN 或网络访问，这些相同渠道可能在故障期间不可用。SITA 的公开支持材料指向全球支持和主动监控，但 Cloud APAC 客户仍然需要一个在受影响服务故障时存活的事件渠道。
客户还应要求部分故障的证据。重大中断容易注意到。部分故障更难：一个前缀路由降级，一个机场站点高丢包，一个数据库副本滞后，一个存储池满，一个支持队列路由错误，或一个防火墙规则阻塞恢复路径。弹性服务具有监控，可以在客户从症状中拼凑之前发现这些部分状态。
最后，恢复证据应包括决策路径。在故障期间，必须有人决定是等待维修、移动工作负载、调用供应商、更改路由、从备份恢复还是开始客户迁移。这些决策可能被商业边界和变更控制习惯延迟。一个实用的 Cloud APAC 合同应说明谁有权宣布重大事件，谁可以联系 Equinix 或其他设施运营商，谁可以批准紧急路由更改，谁拥有客户通信，以及谁签字确认服务已恢复。没有这个决策路径，即使技术可恢复的平台也可能错过客户的真实截止日期。
RPKI 有帮助，但不是完整的路由安全答案
Cloud APAC 当前前缀的有效 RPKI 状态是一个重要的积极信号。RFC 6811描述了路由源验证：一种网络评估宣布的源 AS 是否被授权用于前缀的方式。实际上，有效的源验证有助于减少意外或恶意的源错误，特别是当上游执行过滤时。
但 RPKI 不是完整的弹性控制。它不证明路由是多样化的。它不证明前缀在每个上游内部都被正确过滤。它不阻止路径操纵、路由泄漏、容量耗尽、防火墙配置错误或数据中心交叉连接故障。它也不说明客户流量是否有 DDoS 保护、路由阻尼程序、维护通知、紧急联系人列表或测试过的回滚计划。
RFC 7454是有用的背景，因为它讨论了超越源验证的操作 BGP 安全实践，包括过滤和路由管理纪律。MANRS将路由安全作为网络运营商的操作承诺。这些不是 Cloud APAC 的认证。它们是客户在询问可见 ASN 如何保护时应使用的词汇。
对于 AS132399，问题集很简单。所有已宣布的前缀是否都由当前路由源授权覆盖？哪些上游执行路由源验证和前缀过滤？AS15830 是否是公共互联网可达性的唯一上游？是否存在公共收集器不可见的私有路由？什么监控检测撤回的路由、部分可达性或区域丢包？谁接收告警，他们能多快行动？哪些变更控制策略适用于 BGP 更新？
还有一个围绕 IPv6 的策略卫生问题。如果 AS132399 具有 IPv6 策略行但没有可见的 IPv6 宣布，客户应询问 IPv6 是故意缺失、通过另一个网络交付、计划用于后期阶段还是因兼容性原因禁用。对于现代航空运输系统，IPv6 可能对每个工作负载都不紧迫，但清晰胜过沉默。一个隐藏的设计选择在客户在集成或迁移期间发现时变成了风险。
当 Cloud APAC 故障时，谁受到影响
因为公开记录将 Cloud APAC 与 SITA 关联，受影响的人群可能与典型的共享主机不同。它可能包括使用管理连接的航空公司、依赖 SITA 网络访问的机场系统、连接到共享应用的地勤、使用管理互联网的机场办公室、交换操作消息的旅行系统以及依赖 SITA 管理的云或网络服务的企业团队。确切的客户列表不是公开的，不应猜测。暴露类别仍然清晰。
第一个受影响群体是边缘的操作用户：机场柜台、航空公司办公室、地勤、远程外站和本地技术团队。如果连接故障，这些用户可能经历旅客处理缓慢、操作消息延迟、通过移动链路的权宜措施、手动对账或服务台拥堵。区域云或网络节点可以将一个中央基础设施故障转化为许多本地症状。
第二个受影响群体是应用程序所有者。他们可能不关心哪个 ASN 承载流量，直到延迟上升、DNS 更改、应用程序会话中断或故障切换计划需要网络更改。对他们来说，重要的是依赖关系图、监控访问、服务级别目标和回滚程序。如果 Cloud APAC 是一个黑盒，应用程序所有者将更慢区分应用程序错误与网络或设施问题。
第三个受影响群体是安全和合规人员。他们需要知道数据移动到哪里，谁可以访问它，哪些日志被保留，以及支持活动是否跨越司法管辖区。新加坡标签的前缀不能回答这些问题。全球支持组织可以改进事件响应，但也可以增加跨境数据和访问考虑。客户应将网络本地性与数据本地性和管理员本地性分开。
第四个受影响群体是采购和财务。当续约、扩展或退出路径不明确时，托管容量在财务上变得脆弱。如果新加坡机架空间或电力稀缺，看似弹性的服务可能变成规划约束。如果客户无法干净地带走它的映像、地址或配置，即使技术服务水平普通，提供商也变得难以替换。这就是为什么迁移证据属于弹性审查，而不是未来的解散争夺。
第五个受影响群体是最终旅客和托运人，但只是间接的，取决于工作负载。本次审查中没有公开证据表明 AS132399 承载特定的旅客处理系统，所以声明应保持更窄：SITA 的航空角色提升了基础设施故障的后果。当技术支撑航空公司和机场运营时，小中断可能通过排队、行李处理延迟、手动柜台工作或恢复较慢而变得可见。
买家在依赖之前应核实什么
一个严肃的 Cloud APAC 审查应从当前服务图开始。它应识别确切的产品或账户、法律签约实体、主站点、备份或辅助站点、管理平面、起源 ASN 或 ASN、客户前缀（如果有）以及支持结构。如果服务使用 SITA 自己的 AS132399，该图应显示四个可见 IPv4 前缀并解释其角色。如果服务使用另一个 SITA 或供应商网络，该图应命名该网络。
第二份文件应是设施和电源声明。它不需要公开暴露敏感的笼子细节，但在合同下应说明服务是否在自有机架、托管、管理裸机、公共云或供应商平台中。它应说明主站点和备份站点是否共享建筑、园区、电源、交叉连接路径或运营商。它应解释当一个机架、数据厅、运营商交接或存储池故障时会发生什么。
第三份文件应是路由和传输声明。对于 AS132399，公开证据显示当前通过 Equinix AS15830 的 IPv4 宣布。客户应询问这是否是唯一的公共路径，是否存在私有航空网络路径，是否有第二个提供商，是否执行 RPKI，DDoS 保护是否在线，以及如何检测路由事件。如果答案是“我们不公开披露”，这没问题。如果答案在合同下也不可用，则风险更难接受。
第四份文件应是备份和恢复报告。备份计划是不够的。客户应看到什么被备份，存储在哪里，是否与生产凭据隔离，保留多长时间，多久恢复一次，上次恢复测试覆盖了什么，以及排除了什么。对于虚拟服务器，这意味着映像、卷、数据库和防火墙状态。对于托管应用，意味着应用数据、身份、日志、配置和依赖关系。对于网络服务，意味着设备配置、证书、路由策略和回滚文件。
第五份文件应是支持升级和通信计划。SITA 的广泛支持声明是宝贵的，但客户的事件路径必须明确。它应命名严重级别、响应目标、恢复目标、状态更新节奏、紧急联系人、非工作时间覆盖、运营商升级以及正常电子邮件或门户访问受影响时的通信渠道。它还应说明谁撰写事后报告以及包括什么证据。
第六份文件应是可移植性计划。客户应要求导出格式、账户终止规则、IP 重新编号影响、DNS 传输支持、映像导出权、配置导出权、日志保留访问和数据删除证据。一个无法安全离开的平台不仅具有粘性，而且是连续性风险。
证据等级为中等，意义狭窄
Cloud APAC 既不应被忽视，也不应被过度自信。公开网络证据比一个没有活动路由的薄目录名称更强。AS132399 在 APNIC 和 RIPEstat 视图中是活跃的。它当前有 IPv4 宣布。可见前缀是具体的。路由在 RIPEstat 的 RPKI 检查下验证。可见上游是 Equinix AS15830，一个已知的网络和互联提供商。SITA 的公开材料显示了一个大的航空技术背景和成熟的支持叙述。
限制同样重要。公开证据不显示客户门户、零售托管目录、命名的机架、设施所有权、虚拟机管理程序集群、备份存储库、恢复测试、备件硬件、多站点故障切换、DDoS 架构、此 ASN 的支持升级或数据可移植性程序。它也不显示 AS132399 下的可见 IPv6 宣布。国家代码 SG 和新加坡命名的前缀是有用的本地性信号，但不是完整的数据主权保证。
这就是为什么正确等级是中等。网络不是不可见的。当前的 IPv4 证据是有意义的，且在技术上比许多小型托管条目更干净。但证据并未一路延伸到可靠的托管容量。对于低关键性服务，通过主要上游的当前路由可能足够。对于具有恢复截止日期的航空公司、机场、政府、物流或企业工作负载，买家在将 Cloud APAC 视为弹性基础设施之前应要求缺失的操作证据。
最终测试很简单。如果 Cloud APAC 只是较大管理 SITA 服务内部的一个路由区域组件，客户需要该管理服务的服务级别图。如果它被作为云、托管、VPS、裸机或管理服务容量销售或消费，客户需要设施位置、传输多样性、支持升级、恢复性能和迁移权利的证明。公开记录可以启动对话。它不能完成弹性审查。