IBM-SG-AP IBM Singapore Server Farm sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The directory entity has a real registry anchor. APNIC whois and APNIC RDAP identify AS135291 / AS135291 RDAP as IBM-SG-AP, described as "IBM Singapore Server Farm", with IBM Singapore Pte Ltd as the registrant.
• The operating evidence for that exact AS is weak today. RIPEstat AS overview marks AS135291 as not announced, announced-prefixes returns no current prefixes, and routing-status shows zero visible IPv4 or IPv6 announcements and zero observed neighbours as of July 12, 2026.
• The last visible prefix RIPEstat records for the target AS is 103.212.168.0/24, last seen on December 3, 2024. APNIC now labels that /24 APPTIO-SG, which means the target record should be read as IBM Singapore network accountability, not as proof of current Singapore customer-hosting traffic on AS135291.
• IBM does have adjacent, active Singapore routing. AS136468, also IBM-SG-AP, is announced with 163.114.204.0/24 and two IPv6 /48s, but RIPEstat shows one observed neighbour and visible paths through AS1299 Arelion, so it does not solve the target AS's visibility gap.
• Evidence grade is Weak for the exact entity's public network operation. IBM Cloud documentation confirms Singapore classic data-centre and Direct Link context, but public data does not prove current AS135291 production traffic, rack locations, spare capacity, customer workloads, tested restore paths or transit diversity.

The registered name is specific, but current routing is absent

The starting point is unusually clean and unusually cautionary. APNIC's public whois record for AS135291 gives the as-name IBM-SG-AP, describes the resource as "IBM Singapore Server Farm", lists the country as SG, and places the organisation under IBM Singapore Pte Ltd. APNIC RDAP for autnum 135291 presents the same AS handle and registrant relationship. The directory card is therefore not an invented label. It is a public resource name attached to IBM Singapore.

That is the easy part. The harder part is that a registered AS is not the same thing as live hosted capacity. RIPEstat's AS overview for AS135291 identifies the holder as "IBM-SG-AP - IBM Singapore Server Farm" but marks the AS as not announced. Its announced-prefixes endpoint returns an empty list. Its routing-status endpoint reports zero visible IPv4 prefixes, zero visible IPv6 prefixes, zero announced IPs and zero observed neighbours at the July 12, 2026 query time. RIPEstat also records a first seen and last seen history for 103.212.168.0/24 on AS135291, with the last seen timestamp at December 3, 2024.

That gap changes the article's posture. A reader should not treat "Server Farm" as a current public BGP footprint. It may describe a historical or reserved IBM Singapore resource, a resource once used for a specific product boundary, a corporate route-registration pattern, a route object that can be revived, or a resource that has moved behind another origin. Public evidence does not settle which of those is true.

What it does settle is more important for customer risk: if a customer is trying to prove reachability, multi-site operation or active transit for the exact AS135291 edge, the public internet routing record currently does not provide that proof.

This is still a useful infrastructure profile because the absence is operationally meaningful. Hosted capacity is often sold with names that sound abstract: cloud, managed service, platform, server farm, virtual instance, regional presence. Each of those names eventually depends on a rack, a handoff, a support rota, a repair contract and a customer's ability to move data if the first path fails. In this case, the public record says the named AS exists under IBM Singapore, but the visible route has gone quiet. That does not prove customer harm.

It does prove that any buyer, partner or dependency owner needs to ask a much narrower question than "does IBM operate in Singapore?" The right question is: which IBM Singapore resource, which facility, which service, which prefix, which origin AS, which upstream, which restore route and which customer commitments are actually in scope?

The 103.212.168.0/24 clue points away from a simple Singapore hosting story

The historical prefix behind AS135291 adds nuance. RIPEstat's prefix overview for 103.212.168.0/24 currently says the prefix is not announced. APNIC whois for 103.212.168.0 shows the inetnum 103.212.168.0 - 103.212.168.255 with netname APPTIO-SG, an APNIC abuse contact under IBM Singapore, and route objects for origin AS135291 and origin AS3356. APNIC RDAP for the same address block also presents the range as APPTIO-SG and lists APPTIO SINGAPORE PTE LTD as the administrative and technical role.

That is not the evidence one would expect if this were simply a broad public cloud edge advertised today from a Singapore data hall. It looks more like a specific corporate or product lineage that became part of IBM's network inventory. IBM announced on August 10, 2023 that it had completed its acquisition of Apptio, bringing ApptioOne, Cloudability and Targetprocess into IBM's automation portfolio. The APNIC route and inetnum changes in 2024 therefore fit a plausible administrative story: an Apptio-associated Singapore resource block sitting under IBM Singapore maintenance and route control. That is an inference from public registry timing, not a proof of production deployment.

The country fields make the story even less simple. The AS record is Singapore. The APNIC address block shows APPTIO-SG but carries a GB country value and a London descriptive address, while its role entity is a Singapore Apptio role. A literal reading would be a mistake. Address registry metadata often reflects legal, administrative or historical structure rather than where packets enter a rack. For this entity, that means Singapore identity is strong at the AS and registrant level, but rack locality for 103.212.168.0/24 is not proven by the prefix record.

The origin-authorisation record is better than the active-routing record. RIPEstat's RPKI validation endpoint for AS135291 and 103.212.168.0/24 returns a valid status for AS135291. That matters if the route returns: networks that enforce RPKI origin validation have a basis to accept the AS135291 origin and reject an origin that does not match the ROA. But RPKI does not create service. It does not prove a switch is powered, a port is lit, a service has customers, a backup has been restored, or a Singapore rack is carrying live traffic. It is a routing-hygiene control, not an availability warranty.

The same caution applies to the APNIC import and export lines. AS135291's whois record lists imports from AS3758 and AS4657 and exports to those ASNs, with export statements announcing AS10120. RIPEstat's routing-consistency endpoint for AS135291 shows those policy entries in whois, but none of the listed imports, exports or prefixes are visible in current BGP. That is the difference between a registry intention and a live dependency map. For a customer, only the live map can answer whether a failure at an upstream, exchange, data-centre meet-me room or carrier handoff would take traffic down.

The adjacent IBM Singapore ASN is active, but it is not a substitute for AS135291 evidence

IBM Singapore's network footprint does not disappear just because AS135291 is quiet. APNIC also has AS136468, with the same IBM-SG-AP as-name but the description "IBM Singapore Pte Ltd." APNIC RDAP for autnum 136468 ties that AS to the same IBM Singapore registrant. RIPEstat's AS overview for AS136468 marks it announced. RIPEstat announced-prefixes currently shows 163.114.204.0/24, 2402:cf80:100a::/48 and 2402:cf80:100b::/48. Its routing-status reports one visible IPv4 prefix, two visible IPv6 /48s and one observed neighbour.

That adjacent AS helps define the IBM Singapore operating surface, but it should not be merged into the target entity without evidence. The public directory card is AS135291-shaped, not AS136468-shaped. If a customer is pointed at IBM Singapore generally, AS136468 shows live IBM Singapore routing. If the question is the "IBM Singapore Server Farm" record itself, AS136468 is corroborating context, not proof.

AS136468 also carries its own concentration signal. RIPEstat BGP state for AS136468 shows global paths reaching the AS through AS1299, and RIPEstat's AS1299 overview identifies the holder as Twelve99 Arelion Sweden AB. The routing-consistency endpoint shows AS1299 visible in BGP even though AS3758 and AS4657 are listed in APNIC policy and are not visible in that view. Again, this does not prove that IBM lacks private resilience or other paths. It means that the public route-collector view, the part outside customers can audit without private diagrams, sees one neighbour for the active IBM Singapore AS.

For hosted-capacity diligence, that distinction matters. Customers often ask whether a provider has "Singapore" availability. That can mean at least four different things: a legal entity in Singapore, an IBM Cloud data-centre location in Singapore, an active local BGP origin, or a product-specific workload running in a local facility. This entity gives evidence for the first two in broad IBM terms, evidence for active local routing in an adjacent AS, and weak evidence for the exact target AS. Those categories should stay separate.

The result is not an alarmist finding. It is a scoping finding. IBM is a global cloud and infrastructure provider. IBM Cloud's public documentation shows Singapore capacity. IBM Singapore has live routing elsewhere. But AS135291 itself is not publicly carrying prefixes today. Any buyer relying on the "Server Farm" identity should ask IBM to map the service to its current origin AS, data-centre location, Direct Link location, restore design and portability terms instead of assuming that the registered AS name equals current capacity.

Singapore 01 is classic infrastructure, not a three-zone IBM Cloud region

IBM Cloud's location documentation supplies the physical context that the AS record alone cannot. The IBM Cloud locations page describes regions, multizone regions, single-campus multizone regions and classic data centers. It says classic data centers are physical locations for servers that provide cloud services, and that they host power, cooling, compute, network and storage resources used for services and applications. It also warns that classic data centers do not provide isolation from multizones in a location.

The same page lists "Singapore 01" with the code SNG01 in the Asia Pacific classic data-centre table. That is the concrete Singapore footprint readers should distinguish from the quiet AS135291 record. SNG01 is a classic data-centre location. It is not presented on that page as an IBM Cloud multizone region with three separate zones. IBM's MZR definition on the same page describes three or more data centers in multiple zones, with independent power, cooling and network connectivity intended to isolate failures to a single zone.

By contrast, classic data centers depend on PODs, racks, servers, networks, storage and backup power generators within a data-centre architecture.

That distinction changes the failure model. A three-zone regional application can be designed so that a zone failure leaves the application running in other zones. A classic data-centre application may still be resilient, but the customer and provider have to design that resilience explicitly: separate POD placement, backup targets, replication, DNS or load-balancer behaviour, a recovery site, and a tested restoration path. "The workload is in Singapore 01" and "the workload is highly available across independent Singapore-area sites" are not the same claim.

IBM Cloud's service-availability page reinforces the split. It describes services that are hosted globally, services that are deployed in regions, and classic infrastructure services that are available to be deployed in data centers. It also lists cloud services such as Direct Link, Cloud Object Storage and classic infrastructure offerings under their relevant availability groupings. A customer reading those tables has to ask which service surface is involved. A bare-metal or classic virtual-server commitment in SNG01 has a different failure path from a global Object Storage control plane, a VPC region, or a Direct Link circuit terminating at a provider location.

IBM's VPC overview describes VPC regions and zones, saying each region contains logically isolated zones with independent infrastructures and that customers can deploy resources in multiple zones for fault tolerance and high availability. It also says one VPC per region can communicate with classic resources. That is important for Singapore because a customer may connect modern VPC resources and classic Singapore resources in one architecture. The connection does not erase the difference between the two designs. It simply creates another dependency boundary.

Direct Link reveals the carrier and facility handoff surface

Hosted capacity becomes real at interconnection points. IBM Cloud's Direct Link locations page gives useful public names. It lists Direct Link Connect providers and locations, including Singapore 1 with Digital Realty, Megaport and Tata Communications, and Singapore 2 with Equinix. In the Direct Link Dedicated APAC table, it lists Singapore 1 as a data-centre location with Digital Realty and site code SIN10.

That does not prove AS135291 terminates in SIN10, Equinix, Tata, Megaport or any particular building. It does prove that IBM Cloud's Singapore connectivity story is tied to named data-centre and provider handoffs. That is where cloud availability leaves product language and becomes physical work: cross-connects, meet-me rooms, port capacity, carrier maintenance notices, optical inventory, facility access windows, remote-hands response, and the contractual boundary between IBM, the facility operator, the customer and a network provider.

For customers, Direct Link can reduce public-internet exposure and create predictable private connectivity. It also creates dependencies. A circuit that depends on a single exchange provider or a single data-centre meet-me room can fail even when the compute platform is healthy. A customer may see the application itself running, but their users or back-office systems cannot reach it because the private route is partitioned.

If a customer uses Singapore 1 Direct Link Dedicated, the question becomes whether there is a second circuit, a second provider, a separate physical path, a tested VPN fallback or an internet failover plan that has been exercised with real routes.

This is where the active AS136468 evidence becomes a useful warning sign rather than a complete answer. Public BGP sees AS136468 through AS1299. The target AS135291 has no visible neighbours. Direct Link tables show multiple Singapore connectivity options, but those tables describe product availability, not customer-specific circuit diversity. A customer who needs resilience must not infer that because several providers appear in a public Direct Link table, their own service has several independent paths. Diversity only exists when the customer's actual circuits, ports, routers, optical paths and routing policies are diverse.

The same point applies to maintenance windows. A hosted service can be fully healthy and still become unreachable during carrier work, cross-connect replacement, router maintenance, route-filter changes, DDoS mitigation changes or facility access delays. IBM can have strong internal operations, but a customer still needs to know how planned and emergency maintenance are communicated, what parts of the stack are single-homed, and whether support can distinguish between an IBM service fault, a carrier fault and a customer-side route fault. The public AS135291 record cannot answer those questions.

Object storage and backup choices decide whether locality is resilience or exposure

IBM Cloud Object Storage documentation makes the locality problem concrete. The endpoints and storage locations page says a bucket's resiliency is defined by the endpoint used to create it. It distinguishes cross-region resiliency, regional resiliency and single data-center resiliency. It says single data-center buckets distribute data across multiple physical storage appliances within one data center, but do not maintain availability in a site outage or destruction and do not provide automated backup for site destruction.

This is the clearest public statement of a hosting dependency that matters for Singapore. Locality is valuable when a customer needs low latency, data placement clarity, local access or a jurisdictional posture. Locality can also become exposure if the customer chooses a single-site storage target and assumes it behaves like a multi-site region. In Singapore, where physical data-centre capacity is expensive and carefully managed, the difference between one site and several sites is not paperwork. It determines whether a facility event becomes a service interruption or a disaster-recovery exercise.

The same Object Storage page says regional buckets distribute data across three data centers in a metro area and that cross-region buckets distribute data across three regions in a geographical location. Those are stronger resilience patterns, but they may change cost, latency and data-placement decisions. A customer that wants Singapore-only locality may resist cross-region replication if it moves data outside Singapore. A customer that wants site-failure resilience may need to accept additional locality complexity. IBM's documents give the menu; the customer's architecture decides the risk.

That is why data sovereignty and locality belong in this profile even though AS135291 is inactive. The AS and prefix records alone cannot tell where data rests. IBM Cloud's storage documentation says location and resiliency are chosen through endpoint and bucket design. Singapore's privacy regime then adds a governance layer. The Personal Data Protection Commission's 2026 Guide to Cross-Border Data Transfers frames transfer decisions around how organisations meet obligations when personal data leaves Singapore. For IBM customers, the operational question is not simply "is the provider in Singapore?" It is whether each component - compute, object storage, backups, logs, monitoring, support access, replicas and exports - is placed and governed as the customer expects.

This is also a portability issue. If a customer keeps production in SNG01, stores backups in one site, connects through one private circuit and does not test cross-site restoration, a local outage can become a trapped-dependency problem. Moving data during an incident is slower than designing replication before one. A serious customer conversation should cover backup location, restore point, restore time, recovery credentials, export format, DNS control, application secrets, private-network changes and whether the destination environment has enough spare capacity.

Singapore capacity is valuable because it is constrained

Singapore is an attractive cloud and interconnection market because it is close to regional users, financially sophisticated, highly connected and governance-heavy. It is also constrained by land, power, cooling and sustainability policy. IMDA's 2024 Green Data Centre Roadmap announced a sustainable growth path for additional data-centre capacity, including a target of at least 300 MW of additional capacity in the near term with more through green energy deployments. IMDA and EDB had earlier announced in 2023 that about 80 MW of new capacity would be awarded to four data-centre operators through a pilot data-centre application exercise, according to the official July 2023 announcement.

Those numbers are macro policy context, not IBM-specific capacity. They still matter for hosted capacity because every provider in Singapore feels the same physical market. Data-centre power is not infinitely elastic. A customer asking for more bare-metal capacity, a larger private link, higher replication volume or emergency migration space may face lead times shaped by facility power, equipment stock and provider allocation choices. A global provider can move work elsewhere, but customers often choose Singapore because "elsewhere" is not an equal substitute for latency, governance, support or contractual reasons.

IBM's public cloud data-centre page markets the ability to deploy locally and scale globally, and says facilities optimise space, power, network, personnel and internal infrastructure across locations at ibm.com/solutions/cloud-data-centers. That statement is useful, but it is not a slot-level capacity commitment. The question for IBM-SG-AP IBM Singapore Server Farm is narrower: what current capacity is actually tied to the target entity, what IBM Singapore facility or service currently carries it, and how much usable headroom exists after normal customer reservations, internal overhead, maintenance buffers and recovery reserves.

Installed capacity and usable capacity are different. Installed capacity is the rack, server, storage, network and address space that exists. Usable capacity is what remains after operational constraints: power draw, cooling headroom, spare hardware, support staff, licensing, storage replication bandwidth, backup windows, private-circuit port speed and customer isolation rules. A server farm can be registered, announced, reserved or marketed while offering little emergency headroom for a particular customer. Conversely, a quiet AS can sit beside healthy product capacity elsewhere. Public evidence does not decide which is true for AS135291.

It only tells the reader not to assume.

The support boundary is as important as the rack boundary

IBM's scale can hide the human dependency. A global provider has support portals, status pages, product teams, field operations, facility partners, hardware logistics and account teams. That does not mean every Singapore service dependency has the same escalation path. IBM Cloud has a public status page and support navigation, but incident response still has to map a customer's symptom to the correct layer: application, DNS, certificate, IAM, storage endpoint, Direct Link, public BGP, classic infrastructure, facility event, customer-side route, or a third-party provider.

The AS135291 record makes that mapping harder, not easier. If a customer sees an old design document, route object or dependency inventory that references AS135291, the public route tables will not currently confirm live traffic. If the service has moved to AS136468, AS3356, a CDN, a cloud front door, a private endpoint or a product-specific address pool, the customer needs a current dependency map. Without one, a support incident can waste time in the wrong queue. A network team may look for a prefix that is no longer announced. An application team may declare the service healthy while a routing or private-link dependency is broken.

A security team may try to validate an allowlist against stale origins.

Hardware-stock risk is also easy to underestimate in a large cloud. Bare metal, classic virtual servers, storage appliances and network gear still rely on spares. If a customer buys single-tenant or specialised capacity, the recovery path may require compatible hardware, not just any cloud instance. If a Singapore site is constrained, replacement hardware or expansion capacity may need staging, shipment, installation, or a decision to rebuild in another location. That is where support labour, facility access and spare inventory become part of the capacity sold.

Repair windows are the practical bridge between service language and business impact. A maintenance notice may be acceptable for a test host and unacceptable for a payments gateway, booking engine, trading application, logistics system or enterprise identity dependency. Customers should ask whether maintenance affects the control plane, data plane, private connectivity, storage, support access or only a subset of hosts. They should also ask how IBM distinguishes emergency work from planned maintenance and how customers are told when a carrier or facility partner is the limiting party.

The assignment's failure paths - rack, upstream, hardware-stock, support, billing, migration and provider-contract failure - all live at this boundary. Billing or contract failure can be as disruptive as a cable cut if it freezes access to a service, circuit, domain, licence, backup repository or support entitlement. Migration failure can trap a customer when the service is technically recoverable but the data, secrets, certificates or build notes are not portable fast enough. The target AS does not prove any of those failures are happening. It tells readers exactly which private answers they need before they rely on the card.

Who is affected if this surface fails

The likely affected population depends on which IBM Singapore service is actually using the infrastructure. If AS135291 is only a dormant administrative resource, the direct customer blast radius may be low today. If the Apptio-labelled 103.212.168.0/24 returns to AS135291 or remains part of an IBM technology-business-management product surface, the affected users could include FinOps teams, cloud-cost analysts, enterprise IT finance teams, internal automation users or integration endpoints.

IBM's Apptio acquisition release says the portfolio includes ApptioOne, Cloudability and Targetprocess, which are not generic hosting products but enterprise management tools that can still depend on application availability, identity, data ingestion and regional network paths.

If the dependency is broader IBM Cloud Singapore capacity, the affected population is larger: enterprises running classic infrastructure in SNG01, customers using Singapore Direct Link, workloads depending on local storage or backup targets, and teams that chose Singapore for latency or governance reasons. Those customers may not know or care which AS originates a route. They care whether their application is reachable, whether private links are alive, whether support can act, and whether recovery does not violate their data-placement expectations.

The failure mode is not always a dramatic outage. A quiet route transition can break allowlists. A stale route object can confuse an auditor. A storage endpoint choice can leave backups available inside one site but not after a site event. A single Direct Link dependency can make a private application unreachable even though public IBM Cloud services remain online. A support-account mismatch can delay a repair because the service is owned by one team, the network by another, and the contract by a third. A migration plan can fail because exports are available but environment rebuild notes, secrets and private routing are incomplete.

That is why "server farm" should be read through operating commitments, not just address records. The public record says IBM Singapore owns or maintains relevant resources. It does not say which customer workloads exist today. It does not publish rack counts, hardware stock, utilisation, port reservations, backup success rates, support staffing or real recovery tests. Those are the variables that decide customer impact.

The questions customers should put to IBM

A customer or partner assessing this entity should start by asking whether AS135291 is in current service at all. If yes, which prefixes, products, customers or internal systems use it, and why are they not visible in public BGP at the time of review? If no, why is the AS still registered as IBM Singapore Server Farm, and should customer dependency records be updated to another origin AS, endpoint or product identifier? This is not a gotcha. It is basic dependency hygiene.

The second question is rack locality. Does the service sit in SNG01, another Singapore facility, a Direct Link Singapore location, a regional IBM Cloud service, a non-Singapore IBM Cloud region, a CDN-backed origin, or an acquired-product environment inherited from Apptio? The answer should distinguish control-plane location from data-plane location and storage location. A customer can have a Singapore support relationship while data, logs, backups or product control functions sit elsewhere.

The third question is route diversity. For AS135291, public BGP shows none today. For AS136468, public BGP shows one observed neighbour. If IBM has private or customer-specific diversity, the customer should see it in an architecture diagram or contract attachment: independent routers, independent carriers, separate physical paths, DDoS arrangements, route policy, failover test dates and how traffic changes during maintenance. A generic statement that multiple providers exist in Singapore is not enough.

The fourth question is storage and restore design. For every customer workload, where are the backups, how often are they restored, what data age is acceptable, which identity and encryption dependencies are needed to restore, and how does the plan behave if Singapore 01 is unavailable? IBM's Object Storage documentation makes clear that single data-center storage behaves differently from regional or cross-region storage. Customers need to know which pattern they bought.

The fifth question is portability. If the service cannot be restored in place, can the customer rebuild it elsewhere? That requires exports, images, deployment notes, DNS control, certificate access, secrets handling, network allowlist changes, private-link changes, application configuration, support contacts and a destination with enough capacity. Portability should be a design feature, not an incident-day improvisation.

The sixth question is commercial resilience. Which vendor contracts, facility agreements, support entitlements, billing accounts, domain records, licences and interconnection contracts are required to keep the service alive? A provider-contract failure is not visible in BGP until it becomes operational, but it can be just as damaging as a network fault if it blocks renewal, replacement, access or escalation.

What would raise the evidence grade

The grade would rise quickly with a small set of public or customer-verifiable facts. A current IBM statement that AS135291 is retired, reserved or mapped to a named product would close the ambiguity. A live route announcement with a current prefix list, visible neighbour diversity and valid RPKI would improve network confidence. A published mapping between IBM Cloud Singapore 01, Direct Link Singapore 1, AS135291 and customer-facing services would improve location confidence. A recovery design showing multi-site restore, backup targets and tested failover would improve service confidence.

Evidence could also come from customer documents, if handled safely: architecture diagrams, support agreements, service descriptions, route tables, Direct Link circuit details, restore-test summaries or migration plans. Those would not need to be public to be useful to a customer. But this public article cannot assume them. It can only say what the public evidence supports.

Several facts would lower confidence. If AS135291 remains registered but unexplained while customers still have it in dependency records, stale documentation risk rises. If 103.212.168.0/24 remains unannounced without a migration note, attribution remains weak. If AS136468 continues to show only one visible neighbour, public proof of transit diversity remains thin. If IBM Cloud Singapore services are used as single-site targets without explicit recovery design, the customer risk is site concentration. If Singapore data-centre capacity tightens further, emergency hardware or migration headroom may become more valuable and more expensive.

None of those lower-confidence signals prove poor operation. They identify what the public record cannot prove. The evidence has to be graded against the exact directory entity, not against IBM's global reputation. IBM may operate stronger private controls than public route tables show. The public evidence simply does not let an outside reader verify them for AS135291.

Watchpoints for the next review

The first watchpoint is the return of any visible AS135291 announcement. If RIPEstat announced-prefixes begins showing 103.212.168.0/24 or another prefix again, the question becomes whether the origin is stable, whether the route is RPKI-valid, and which upstreams appear in public paths. A return through a single provider would still be a concentration story; a return through multiple independent neighbours would materially improve public confidence.

The second watchpoint is a change in APNIC records. If the AS description, organisation, route objects, maintainers or address-block labels change, the market should re-read the entity as either a retired resource, an Apptio-linked product surface, a revived IBM Singapore edge, or a migrated address pool. Registry changes are not service proof, but they often precede or follow real network moves.

The third watchpoint is IBM Cloud Singapore product documentation. If IBM adds Singapore as a full multizone region, changes SNG01 classic availability, updates Direct Link Singapore locations, or publishes migration guidance for a Singapore facility, the recovery assumptions in this article should be revisited. A stronger regional pattern would not automatically prove AS135291 use, but it would change the broader hosting-economics context.

The fourth watchpoint is customer-facing locality language. If IBM or Apptio product documents make stronger claims about Singapore residency, local backup, private connectivity or regional isolation, those claims should be matched against storage endpoint design, support access and route visibility. Locality claims are useful only when they map to the components customers actually depend on.

Working conclusion

IBM-SG-AP IBM Singapore Server Farm is a real IBM Singapore registry identity with a weak current public routing footprint. APNIC ties AS135291 to IBM Singapore and describes it as a Singapore server farm. RIPEstat says the AS is not currently announced and has no visible prefixes or neighbours. The last visible prefix, 103.212.168.0/24, is now APNIC-labelled APPTIO-SG and not announced, with route objects that point to both AS135291 and AS3356. IBM Singapore's adjacent AS136468 is active, but it is a separate resource and shows one observed neighbour in public route data.

IBM Cloud documentation confirms Singapore classic data-centre and Direct Link context, but it does not prove the target AS carries live hosted capacity today.

For customers, the practical lesson is to treat the card as a dependency question, not as a finished answer. The relevant risks are not abstract. They are rack loss, single-site storage, upstream or private-link failure, stale allowlists, hardware-stock limits, support routing, billing or contract blockers, data locality mismatches and migrations that have not been rehearsed. Those risks can be managed, but only if the customer knows which IBM Singapore surface they actually depend on.

The evidence grade is therefore Weak for the exact AS135291 operating surface and Medium for the broader IBM Singapore infrastructure context. The company and its Singapore cloud footprint are real. The target entity's current public network operation is not proven. Any decision that depends on this server-farm identity should require a current IBM dependency map, live route confirmation or a customer-specific service description before treating the name as active hosted capacity.