Summary

  • Cloud APAC's strongest public identity anchor is APNIC RDAP for AS132399, which names the ASN ATICLOUD-AP, describes it as SITA Cloud APAC, gives the country as SG and lists the registrant as International organization of Aeronautics Telecommunications (SITA).
  • RIPEstat's AS overview currently reports the holder as ATICLOUD-AP - SITA Cloud APAC and marks the ASN as announced, which is stronger evidence than a dormant registry entity.
  • Current public routing is still narrow. RIPEstat routing status shows four IPv4 prefixes, no visible IPv6 prefixes and one observed neighbour; RIPEstat ASN neighbours identifies the visible neighbour as AS15830.
  • The announced prefixes are visible and route-origin validation checks are positive. RIPEstat announced prefixes lists 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 and 57.191.160.0/19; RIPEstat validation checks for those four origins return valid status.
  • SITA's own public pages show why the workload may be operationally important. SITA says it serves air-transport communications and information technology, works across more than 1,000 airports, and markets SITA Connect as managed connectivity across aviation locations.
  • The public record does not identify the data centre, rack count, server ownership, support escalation path, backup boundary, customer export procedure or multi-site failover design behind Cloud APAC. The network evidence grade is Medium: current IPv4 routing is visible and validated, but customer-usable resilience remains unproved.

The cloud bill still ends at a Singapore rack

Cloud services are sold as abstractions: regions, portals, managed links, application hosts, support queues and monthly contracts. The user sees an account, a help desk, an IP address, a latency target or a service dashboard. The operating system sees something more prosaic. It sees a server or virtual machine in a cabinet, a router port, a cross-connect, a power path, a cooling envelope, a storage pool, a backup target, an upstream provider and people who can get a change made before the customer's deadline expires.

That is the useful way to read Cloud APAC. The public footprint does not look like a retail VPS company with package cards and a checkout page. It looks like a Singapore-coded network and cloud marker inside SITA's air-transport technology environment. APNIC RDAP for AS132399 names the ASN ATICLOUD-AP, gives the description SITA Cloud APAC, lists the country as SG and records the registrant as International organization of Aeronautics Telecommunications (SITA). RIPEstat's whois view shows the same AS name, description, country and APNIC source, plus route-policy lines importing from and exporting to AS15830.

Those records are enough to anchor the public identity. They are not enough to treat "Cloud APAC" as a complete, customer-ready architecture. A customer cannot infer from an ASN alone whether the service uses owned racks, colocation, leased bare metal, virtualized clusters, public cloud backends, airport edge appliances or supplier-managed capacity. Nor can it infer whether the same platform hosts passenger processing, airport connectivity, customer service systems, internal applications or only network control infrastructure.

The distinction matters because SITA's broader business is not casual infrastructure. SITA's own homepage says the company is a specialist in air transport communications and information technology and reports presence across international destinations, customers and airports. Its membership page says more than 13,500 industry sites are connected by SITA's network and that nearly every airline and airport does business with SITA. Its airlines page frames integrated airline systems as part of the passenger journey. When a cloud or network element sits in that world, a fault can reach check-in counters, departure control systems, baggage operating routines, airport connectivity, airline offices and the support teams that keep them operating.

So the right question is not whether Cloud APAC exists. The public record says it does as a routed ASN. The right question is whether the capacity behind the customer account is resilient in the ways that air-transport and regional enterprise users actually need. If a rack loses power, which services move? If the upstream path fails, which alternate path carries traffic? If hardware is out of stock, which workloads wait? If a support chain crosses time zones or legal entities, who owns the incident clock? If a customer needs to migrate, can it export usable data before the account or supplier relationship becomes the problem?

What the public routing evidence proves

AS132399 is not a stale entry. RIPEstat's AS overview reports the holder as ATICLOUD-AP - SITA Cloud APAC and shows the ASN as announced. RIPEstat's routing status also shows current IPv4 visibility: 325 RIS peers seeing the ASN at the checked time, four IPv4 prefixes and 16,896 IPv4 addresses. That is a much stronger signal than a registry record with no observed routes.

The current prefix list is specific. RIPEstat announced prefixes lists 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 and 57.191.160.0/19 in the latest two-week window. RIPEstat prefix-overview checks show those four prefixes originated by AS132399: 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 and 57.191.160.0/19.

The registry geography is mixed in a way that should be interpreted carefully. APNIC RDAP for 57.191.95.0/24 names the range SITA-SPC-SIN-add with country SG. APNIC RDAP for 57.191.96.0/19 names it SITA-SPC-SIN-S1 with country SG. APNIC RDAP for 57.191.160.0/19 names it SITA-SPC-SIN-S2 with country SG. APNIC RDAP for 57.250.51.0/24, however, returns a broader 57.250.0.0 through 57.250.255.255 registration named SITA-SC-Infrastructure with country BE and SITA entities.

That mix does not make the routes unreliable. It does mean country labels should not be used as a complete data-residency proof. A prefix can be registered with one country value, originated by an APAC ASN, used for infrastructure elsewhere, routed through a global carrier, or assigned to a service that stores data in more than one jurisdiction. For customers, the registry country code is a starting point. The binding facts are the contract, the facility location, the backup location, the support-ticket location, the logging location and the export path.

The route-origin posture is positive. RIPEstat route-origin validation for 57.250.51.0/24, 57.191.95.0/24, 57.191.96.0/19 and 57.191.160.0/19 returns valid status for AS132399 at the checked time. Valid route-origin validation does not prevent every routing incident, but it lowers one important class of origin-misconfiguration and hijack risk. In a market where some small hosting networks still have unknown or incomplete RPKI posture, that is a meaningful positive signal.

The strongest caveat is IPv6. RIPEstat routing status shows no visible IPv6 prefixes for AS132399 at the checked time, even though the APNIC whois-derived record includes IPv6 import and export policy lines with AS15830. That may reflect a service design choice, an unannounced IPv6 plan, a collector visibility issue or a delivery design that does not need visible IPv6 under this ASN. It still matters for customers. If Cloud APAC is part of a modern hosted or managed service, dual-stack reachability, IPv6 filtering, route-origin authorization and monitoring should be answered directly, not guessed from an IPv4-only public view.

One visible upstream is a design question, not a verdict

The route-policy and observed-neighbour picture point in the same direction. RIPEstat's whois data for AS132399 shows imports from AS15830 accepting any and exports to AS15830 announcing AS132399. RIPEstat's ASN neighbour view shows one unique visible neighbour, AS15830. RIPE RDAP for AS15830 identifies the AS name as Equinix and describes Equinix Internet Access / Equinix Connect as a global IP transit platform. RIPEstat's AS overview for AS15830 reports the holder as Equinix, and PeeringDB lists Equinix as15830 as a network service provider.

Equinix is a plausible and high-quality upstream context for a Singapore-facing network. Equinix's Singapore pages describe local data centre and interconnection presence, including the general Singapore data centres page, the SG1 facility at Ayer Rajah and the SG3 facility. That context makes the Cloud APAC routing path legible: the visible internet edge is tied to a large interconnection and transit ecosystem rather than an unknown consumer ISP.

But one visible upstream is not the same as full redundancy. There are at least four layers to separate. Route diversity asks whether BGP has more than one path. Carrier diversity asks whether those paths are with independent commercial suppliers. Physical diversity asks whether cross-connects, meet-me rooms, routers, power circuits and building entries avoid shared failure. Capacity diversity asks whether the surviving path can carry the load after the first path fails. Public BGP can hint at the first two. It says little about the last two.

For AS132399, public route collectors currently show one visible upstream. That may be sufficient for the role the ASN plays. If Cloud APAC is a controlled enterprise edge, an internal cloud segment or a regional front door backed by private connectivity, the visible internet path may not be the whole design. If it is sold or relied on as customer-facing hosting, one visible upstream raises a procurement question. A customer should ask whether there is a second internet transit path, a private WAN route, a cloud interconnect, a cold-standby site, a separate DDoS path or a manual failover procedure.

Equinix's presence can also create a subtle procurement mistake. Seeing a strong upstream brand does not prove the customer has a dedicated cabinet, dedicated port, diverse handoff or any right to direct Equinix support. The customer contract may be with SITA, the route may be through Equinix, the racks may be in an Equinix facility or elsewhere, and the operational ticket may move through a service desk before it reaches carrier hands. All of those arrangements can work. They just need to be written down before an incident.

That is especially true for repair windows. A provider can have excellent upstream connectivity but still be slowed by a failed optics part, a saturated firewall, a change freeze, an access-control issue, a local smart-hands delay or a storage fault outside the network path. The visible AS path tells the customer where packets go. It does not tell the customer who has the key, who has the spare part, who has the rollback authority or who decides when a maintenance window can be broken.

SITA's aviation role raises the consequence of small failures

SITA's public pages explain why this infrastructure deserves a more careful reading than an ordinary small hosting name. SITA's homepage describes the company as a specialist in air-transport communications and information technology and presents broad airport and customer reach. Its SITA Membership page says the membership base includes airlines, airports and other aviation ecosystem entities, and that more than 13,500 industry sites connect through SITA's network. Its SITA Connect page markets managed connectivity across more than 750 destinations, 600 pre-connected airports, SD-WAN, SASE-grade security, multi-cloud connectivity and support for air-transport applications.

Those are broad product and corporate claims, not specific Cloud APAC facility diagrams. They still matter because they describe the environment in which Cloud APAC appears. Air transport runs on coordination among airlines, airports, ground handlers, governments, baggage systems, passenger-processing systems, border systems, service desks and networks. A regional cloud or network node in that world may carry fewer public-facing websites than a retail host, but it can still be operationally sensitive.

A packet path may support a check-in workstation, a departure control host, a baggage message, an airline office VPN, a managed airport edge, a cloud management plane or a monitoring channel.

SITA's Service Management page adds an important support signal. It describes an ITIL-aligned service-management suite, 24/7 worldwide availability, proactive monitoring and support for airport and airline operational needs. The About Us page says SITA Service Management is supported by SITA Global Services and points to 24/7 support, global customer service and a large specialist workforce. These statements are reassuring at the corporate level, but they do not answer the Cloud APAC-specific question: which team owns AS132399 incidents, which team owns the data-centre hands, and what service objectives apply to a particular customer workload?

The support boundary is a real part of the infrastructure. In cloud and hosting failures, the hard problem is often not identifying that something is broken. The hard problem is getting the right authority to act quickly. A route may need a carrier ticket. A server may need hands in a cage. A virtual cluster may need storage failover. A customer may need a DNS change. A security incident may require a firewall rule, account lock, forensic hold or backup isolation. In a large aviation supplier, the support chain may be mature, but it may also be segmented by product, geography, severity and contract.

For customers, the practical question is therefore not "does SITA have a service desk?" The practical question is "does my Cloud APAC service include the escalation path I need?" It should name the severity levels, the first response target, the restoration target, the after-hours path, the authority to contact Equinix or another facility operator, the communication channel if customer email is down, and the post-incident report standard. The best service desk in the world is not useful if the customer's particular account is outside the escalation arrangement.

Singapore is a strong hub with hard power limits

Cloud APAC's SG country marker and Singapore-named prefixes put the service in a market that is both attractive and constrained. Singapore is one of Asia-Pacific's most important interconnection hubs, with dense carrier, cloud and enterprise ecosystems. That is why a Singapore network edge can be valuable for aviation, finance, logistics and regional enterprise workloads. It is close to major submarine cable systems, regional cloud demand, multinational headquarters and airport operations across Southeast Asia.

The same strengths create scarcity. Singapore's Green Data Centre Roadmap says the country aims to provide at least 300 MW of additional data-centre capacity in the near term, with more through green-energy deployments. IMDA frames this around sustainable digital infrastructure and energy efficiency. That policy context matters for any provider using Singapore capacity because cloud economics are not only rack economics. They are power, cooling, land, regulatory, sustainability and hardware-refresh economics.

For Cloud APAC, the public evidence does not identify a facility. The Equinix route context makes Equinix a relevant transit and interconnection reference, but it does not prove the Cloud APAC servers are in a particular Equinix building. The APNIC prefixes named with SIN suggest Singapore-facing network resources, but they do not name a rack, cage, cabinet, data hall or power feed. The customer still needs a facility statement: primary site, secondary site, backup site, management-plane location, data-residency boundary and supplier access arrangement.

This is where installed capacity differs from usable capacity. A provider can have address space and an upstream but not enough spare compute to evacuate a failed cluster. It can have cabinets but not enough power headroom for growth. It can have a backup repository but not enough restore bandwidth for a regional incident. It can have a single well-connected facility but no practical alternate site. It can have a contract with a large data-centre operator but still be constrained by access windows, remote-hands queues or change approval.

Singapore's policy environment makes these questions more concrete. If additional data-centre capacity is tied to energy efficiency and green-energy deployment, then the cost and availability of new racks can affect customer growth, renewal pricing and migration options. A customer buying managed capacity should ask whether the platform has expansion headroom in Singapore, whether overflow goes to another country, whether backup storage leaves Singapore, and whether a future hardware refresh changes the locality promise.

Data sovereignty also has more layers than production rack location. The service may store application data in Singapore while logs, monitoring metrics, support tickets, billing records, configuration backups or snapshots sit elsewhere. SITA's global operating footprint can be a strength for support coverage, but it makes the data map more important. A customer that cares about Singapore residency or APAC locality should request the map for production data, backups, logs, telemetry, tickets, administrator access and subcontractor access.

Hosted capacity fails through ordinary paths

The most credible Cloud APAC failure paths are not exotic. The first is rack or platform failure. A host node, storage shelf, top-of-rack switch, firewall, hypervisor cluster, power circuit or management appliance can fail. If the service is virtualized, the customer needs to know whether workloads restart on another node, whether storage is replicated, whether spare capacity is reserved and whether the restart has been tested under load.

The second is upstream failure. RIPEstat shows AS15830 as the visible neighbour for AS132399. If that path is the only public internet route, then a fault in the BGP session, carrier service, physical cross-connect, router policy or DDoS protection path can affect reachability even when servers are healthy. If there is a private aviation network path or a second carrier path that public collectors do not show, the customer should see that documented in the service design. If there is not, the customer should understand the risk and size the workload accordingly.

The third is hardware-stock failure. Cloud and managed-service customers rarely see the spare-parts shelf, but it decides repair time. A failed disk, optics module, router line card, firewall appliance, power supply or storage controller can be easy to diagnose and slow to replace. In a constrained data-centre market, lead times and access windows matter. The customer should ask where critical spares are held, who can install them, what parts are vendor-supported, and which failures trigger migration rather than repair.

The fourth is support failure. SITA's public support materials indicate scale and process, but any specific Cloud APAC dependency still needs a named escalation path. A regional incident can cross network engineering, facility operations, service management, security, application owners, customer account teams and a third-party transit provider. If the service is important, the customer should know which team leads the bridge call, how status is communicated, and who can approve emergency changes.

The fifth is billing or provider-contract failure. This sounds administrative, but it is infrastructure in practice. If a carrier contract, facility account, software subscription, support entitlement or customer invoice is misaligned, services can be suspended or slowed at the worst possible time. For a provider name that appears inside a larger SITA operating environment, the customer should make sure the legal entity, product name, service description, support entitlement and data-exit rights all line up.

The sixth is migration failure. The day a customer needs to leave is the day it discovers whether the service was portable. Can it export machine images, databases, entity data, logs, firewall rules, DNS records, access-control settings and monitoring history? Can it move IP addresses, or must it renumber? Are backups available in a standard format? Is there a clean handover if the account is suspended, disputed or ending? A cloud service without a tested exit path is a dependency trap, even if it performs well during normal weeks.

Recovery proof has to match the workload

Recovery language is often too generic. A supplier may say a service is backed up, monitored or supported around the clock, but those words have different meanings depending on what Cloud APAC actually carries for a given customer. A network edge, a managed virtual server, a private cloud node, a passenger-facing application, an office VPN and a monitoring collector all fail differently. The recovery evidence should be specific enough that the customer can see which parts return first and which parts wait.

For a network service, recovery proof starts with reachability. The customer should see how AS132399 is monitored, how the four visible IPv4 prefixes are checked, what alert fires when a route is withdrawn, and who acts if the AS15830 path is degraded. If the service has private aviation connectivity or another non-public path, the customer should see how that path is tested separately. A public route collector can show that an ASN is visible, but it cannot show whether an individual site, firewall zone or customer tunnel has failed over correctly.

For hosted compute, recovery proof starts with workload state. If a server fails, is the customer buying automatic restart on another node, manual rebuild, image restore, application restore or only best-effort repair? Does the recovery target include the operating system, attached storage, firewall policy, certificates, identity configuration, monitoring checks and logs? If a backup restores a virtual machine but leaves the network policy or DNS records behind, the service is not actually recovered from the user's point of view.

For managed applications, recovery proof has to include dependencies. An airline or airport system may depend on identity providers, message queues, databases, third-party APIs, local workstations and network tunnels. A restore of the application server alone may leave users unable to transact. The customer should ask for a dependency list that identifies which systems are restored together, which have independent clocks, and which are outside Cloud APAC's responsibility.

For data, the key distinction is backup versus usable restore. A backup can exist and still fail the business if it is too old, too slow, incomplete, inaccessible during account suspension, stored in the wrong jurisdiction or tied to a damaged credential set. The customer should ask for the latest successful restore test, the largest tested restore size, the most recent failed restore, the retained recovery points, the deletion process and the export format. In Singapore-locality cases, the same evidence should say where the backup copy and restore staging area are located.

For incident communications, recovery proof has to include out-of-band paths. If the service supports email, customer portals, VPNs or network access, those same channels may be unavailable during a fault. SITA's public support material points to global support and proactive monitoring, but a Cloud APAC customer still needs an incident channel that survives the affected service. That may be a phone bridge, a separate portal, pre-agreed emergency contacts or a customer operations room. The important point is that the incident channel should not depend entirely on the thing that is broken.

The customer should also ask for evidence of partial failure. Major outages are easy to notice. Partial failures are harder: one prefix route is degraded, one airport site has high packet loss, one database replica lags, one storage pool is full, one support queue is misrouted, or one firewall rule blocks a recovery path. A resilient service has monitoring that finds these partial states before customers piece them together from symptoms.

Finally, recovery proof should include a decision path. During a fault, someone has to decide whether to wait for repair, move the workload, invoke a supplier, change routing, restore from backup or start customer migration. Those decisions can be delayed by commercial boundaries and change-control habits. A practical Cloud APAC contract should say who has authority to declare a major incident, who can contact Equinix or another facility operator, who can approve emergency routing changes, who owns customer communication, and who signs off that the service is recovered.

Without that decision path, even a technically recoverable platform can miss the customer's real deadline.

RPKI helps, but it is not the whole routing-security answer

The valid RPKI state for Cloud APAC's current prefixes is an important positive signal. RFC 6811 describes route-origin validation: a way for networks to evaluate whether an announced origin AS is authorized for a prefix. In practical terms, valid origin validation helps reduce accidental or malicious origin mistakes, especially when upstreams enforce filtering.

But RPKI is not a complete resilience control. It does not prove that the route is diverse. It does not prove that the prefix is filtered correctly inside every upstream. It does not stop path manipulation, route leaks, capacity exhaustion, misconfigured firewalls or a broken data-centre cross-connect. It also does not say whether customer traffic has DDoS protection, route dampening procedures, maintenance notification, emergency contact lists or a tested rollback plan.

RFC 7454 is useful context because it discusses operational BGP security practices beyond origin validation, including filtering and route-management discipline. MANRS frames routing security as an operational commitment by network operators. These are not certifications of Cloud APAC. They are the vocabulary customers should use when asking how a visible ASN is protected.

For AS132399, the question set is straightforward. Are all announced prefixes covered by current route-origin authorizations? Which upstreams enforce route-origin validation and prefix filters? Is AS15830 the only upstream for public internet reachability? Are there private routes not visible to public collectors? What monitoring detects a withdrawn route, partial reachability or regional packet loss? Who receives alerts, and how quickly can they act? What change-control policy applies to BGP updates?

There is also a policy hygiene question around IPv6. If AS132399 has IPv6 policy lines but no visible IPv6 announcements, customers should ask whether IPv6 is intentionally absent, delivered through another network, planned for a later phase, or disabled for compatibility reasons. For modern air-transport systems, IPv6 may not be urgent for every workload, but clarity beats silence. A hidden design choice becomes risk when customers discover it during integration or migration.

Who is affected when Cloud APAC fails

Because the public record ties Cloud APAC to SITA, the affected population is likely different from a typical shared host. It may include airlines using managed connectivity, airport systems that rely on SITA network access, ground handlers connecting to shared applications, airport offices using managed internet, travel systems exchanging operational messages, and enterprise teams that depend on SITA-managed cloud or network services. The exact customer list is not public, and it should not be guessed. The classes of exposure are still clear.

The first affected group is operational users at the edge: airport desks, airline offices, ground handlers, remote outstations and local technical teams. If connectivity fails, these users may experience slow passenger processing, delayed operational messages, workarounds over mobile links, manual reconciliation or service-desk congestion. A regional cloud or network node can turn a central infrastructure fault into many local symptoms.

The second affected group is application owners. They may not care which ASN carries traffic until latency rises, DNS changes, application sessions break or a failover plan requires network changes. For them, the important facts are dependency maps, monitoring access, service-level objectives and rollback procedures. If Cloud APAC is a black box, application owners will be slower to distinguish an application bug from a network or facility problem.

The third affected group is security and compliance staff. They need to know where data moves, who can access it, which logs are retained, and whether support activity crosses jurisdictions. A Singapore-labeled prefix does not answer those questions. A global support organization can improve incident response, but it can also add cross-border data and access considerations. The customer should separate network locality from data locality and administrator locality.

The fourth affected group is procurement and finance. Hosted capacity becomes financially fragile when the renewal, expansion or exit path is unclear. If Singapore rack space or power is scarce, a service that looked elastic can become a planning constraint. If a customer cannot take its images, addresses or configuration away cleanly, the provider becomes hard to replace even when the technical service is ordinary. That is why migration evidence belongs in the resilience review, not in a future offboarding scramble.

The fifth affected group is end passengers and shippers, but only indirectly and depending on the workload. There is no public proof in this review that AS132399 carries a particular passenger-processing system, so the claim should stay narrower: SITA's aviation role raises the consequence of infrastructure failures. When technology underpins airline and airport operations, small outages can become visible to travelers through queues, delayed baggage processes, manual desk work or slower recovery.

What a buyer should verify before relying on it

A serious Cloud APAC review should start with a current service map. It should identify the exact product or account, the legal contracting entity, the primary site, the backup or secondary site, the management plane, the origin ASN or ASNs, the customer prefixes if any, and the support structure. If the service uses SITA's own AS132399, the map should show the four visible IPv4 prefixes and explain their role. If the service uses another SITA or supplier network, the map should name that instead.

The second document should be a facility and power statement. It does not need to expose sensitive cage details publicly, but under contract it should say whether the service is in owned racks, colocation, managed bare metal, public cloud or a supplier platform. It should state whether the primary and backup sites share a building, campus, power source, cross-connect path or operator. It should explain what happens when one rack, data hall, carrier handoff or storage pool fails.

The third document should be a route and transit statement. For AS132399, public evidence shows current IPv4 announcement through Equinix AS15830. The customer should ask whether that is the only public path, whether private aviation network paths exist, whether there is a second provider, whether RPKI is enforced, whether DDoS protection is in line, and how route incidents are detected. If the answer is "we do not disclose this publicly," that is fine. If the answer is unavailable even under contract, the risk is harder to accept.

The fourth document should be a backup and restore report. Backup schedules are not enough. The customer should see what is backed up, where it is stored, whether it is isolated from production credentials, how long it is retained, how often it is restored, what the last restore test covered and what was excluded. For a virtual server, that means images, volumes, databases and firewall state. For a managed application, it means application data, identity, logs, configuration and dependencies. For a network service, it means device configuration, certificates, routing policy and rollback files.

The fifth document should be a support escalation and communications plan. SITA's broad support claims are valuable, but the customer's incident path must be explicit. It should name severity levels, response targets, restoration targets, status-update cadence, emergency contacts, after-hours coverage, carrier escalation and the communication channel if normal email or portal access is affected. It should also state who writes the post-incident report and what evidence it includes.

The sixth document should be a portability plan. Customers should ask for export formats, account termination rules, IP renumbering implications, DNS transfer support, image export rights, configuration export rights, log-retention access and data-deletion evidence. A platform that cannot be left safely is not simply sticky; it is a continuity risk.

The evidence grade is Medium, with a narrow meaning

Cloud APAC deserves neither dismissal nor overconfidence. The public network evidence is stronger than a thin directory name with no live routes. AS132399 is active in APNIC and RIPEstat views. It has current IPv4 announcements. The visible prefixes are specific. The routes validate under RIPEstat's RPKI checks. The visible upstream is Equinix AS15830, a known network and interconnection provider. SITA's public materials show a large aviation technology context and a mature support narrative.

The limits are just as important. Public evidence does not show a customer portal, a retail hosting catalogue, named racks, facility ownership, hypervisor clusters, backup repositories, restore tests, spare hardware, multi-site failover, DDoS architecture, support escalation for this ASN, or a data-portability procedure. It also does not show visible IPv6 announcements under AS132399. The country code SG and Singapore-named prefixes are useful locality signals, but they are not a complete data-sovereignty guarantee.

That is why the right grade is Medium. The network is not invisible. The current IPv4 evidence is meaningful and technically cleaner than many small hosting entries. But the evidence does not reach all the way to dependable hosted capacity. For a low-criticality service, current routing through a major upstream may be sufficient. For airline, airport, government, logistics or enterprise workloads with recovery deadlines, the buyer should require the missing operational evidence before treating Cloud APAC as resilient infrastructure.

The final test is simple. If Cloud APAC is only a routed regional component inside a larger managed SITA service, customers need the service-level map for that managed service. If it is sold or consumed as cloud, hosting, VPS, bare-metal or managed-service capacity, customers need proof of facility placement, transit diversity, support escalation, restore performance and migration rights. The public record gets the conversation started. It does not finish the resilience review.