Summary

  • APNIC records AS136567 as the active autonomous system CyberWorld-AMS1, held by CyberWorld Data Center Co.,Ltd. in Thailand. That establishes a number-resource identity, not a powered site, routed service, rack, customer, or resilience boundary.
  • Refreshed public routing views on July 13, 2026 show AS136567 as unannounced, with no visible prefixes, no historical route origin above RIPEstat's threshold, no observed neighbours, and no current BGP routes.
  • The same registrant's CyberWorld-BKK2 network, AS136566, is publicly visible with one IPv4 /24, two IPv6 /48s, and two observed neighbours. BKK2 proves the company can leave routing evidence when one of its networks is live; it does not activate AMS1.
  • Bangkok's Cyber World Tower has separately documented CS Loxinfo and BKNIX infrastructure. Public records do not place AS136567 there, so those power, cooling, rack, and carrier details cannot be transferred to CyberWorld-AMS1.

The strongest fact is administrative

The most solid fact about CyberWorld-AMS1 is also the easiest to overread. APNIC's RDAP record for AS136567 names the autonomous system CyberWorld-AMS1, lists the country as Thailand, marks the autnum status active, and identifies CyberWorld Data Center Co.,Ltd. as the registrant. The record says the AS was registered on 15 May 2017 and last changed on 22 June 2020. The organisation record uses a Phaholyothin 48 Road address in Bangkok, while the abuse and technical contact records use 90 CyberWorld Tower, Ratchadapisek Road. One abuse mailbox was validated in March 2026, while another contact address was marked invalid.

Those are useful operating clues. They show that the number resource belongs to a named Thai company and that at least one registry contact channel received recent attention. They do not show a facility boundary. A registry address can be a company office, an older network-operations address, a third-party facility contact, or an administrative relic. An active AS registration can sit before a launch, after a closure, beside a private-only service, or inside a plan that has not reached commissioning. It is not a certification of power, cooling, cross-connects, customers, or route availability.

That distinction is not semantic. In a data-centre business, the expensive system begins where power enters a site and ends where customer traffic leaves it. An autonomous system number can be obtained without building the electrical plant, cooling plant, fire compartments, meet-me room, remote-hands operation, or recovery procedure that make the service usable. The name CyberWorld-AMS1 may be an intended node name; it may be an old label; it may be a reserved identity; it may be a private arrangement. The public registry record does not decide which of those states is true.

The article therefore starts from a narrow conclusion: CyberWorld Data Center Co.,Ltd. has responsibility for AS136567. It does not start from the broader conclusion that a CyberWorld-AMS1 data-centre node is operating. For a buyer, peer, investor, or customer trying to price dependency, that narrowness is the whole point. The relevant question is not whether a database line exists. It is whether that line maps to controlled space, deliverable power, heat removal, carrier paths, and tested recovery.

Public routing gives no live AMS1 footprint

The routing evidence is sharper than the registry evidence because it tests the part of the system that would normally be visible when an Internet-facing network operates. Refreshed RIPEstat's AS overview for AS136567 reports the holder as CyberWorld-AMS1 - CyberWorld Data Center Co.,Ltd. and marks the AS as unannounced for the July 13, 2026 query window. The announced-prefixes view returns an empty prefix list. The routing-status view reports zero IPv4 prefixes, zero IPv6 prefixes, zero announced address space, zero observed neighbours, and zero visibility among sampled IPv4 and IPv6 RIPE RIS peers.

The historical view does not repair the gap. RIPEstat's routing-history view returns no origin history above the service's visibility threshold through July 13, 2026. Its neighbour view shows no left, right, unique, or uncertain neighbours in the latest available view. The BGP-state endpoint returns an empty state and zero routes at the refreshed timestamp. PeeringDB's network query for ASN 136567 returns no network entity, so there is no public PeeringDB page declaring facilities, exchanges, traffic level, or peering policy for AMS1.

These absences have limits. RIPEstat excludes very low-visibility routes in some views. A private network can exist without being visible to public collectors. A customer-only or cold-standby arrangement might not maintain a PeeringDB profile. An operator may choose not to publish routing policy or facility lists. None of those caveats changes the procurement consequence: there is no public BGP or interconnection evidence that AS136567 is carrying live Internet-facing service now.

The failure analysis changes when a network has no baseline. If a normally routed ASN withdraws all prefixes, the withdrawal itself may be an incident signal. If an ASN is always invisible, an outside observer cannot tell whether it is unused, private, reserved, shut down, or waiting for commissioning. That is why a data-centre label needs more than an allocation. It needs a visible prefix, a private evidence package, a facility contract, or a clear statement of status. AS136567 presently supplies the allocation and not the operating proof.

BKK2 is the control, not the substitute

The negative view of AMS1 should not be turned into an argument that the company has no operating network capability. The same source set contains a useful control. APNIC's RDAP record for AS136566 names CyberWorld-BKK2 and lists the same registrant, CyberWorld Data Center Co.,Ltd. In the refreshed RIPEstat data, AS136566 is announced. Its announced-prefixes view shows 103.20.120.0/24, 2405:2500:11::/48, and 2405:2500:5::/48. Its routing-status view reports visibility to all 326 sampled IPv4 peers, visibility to 320 of 322 sampled IPv6 peers, and two observed neighbours.

BKK2 matters because it removes the laziest explanation for AMS1's silence. If every CyberWorld-related resource were invisible, stale registration records or a vanished operator would dominate the interpretation. Instead, one sibling network remains visible while AMS1 does not. The company appears capable of producing public routing evidence. That makes the lack of equivalent evidence for AS136567 specific to the AMS1 identity.

What BKK2 does not do is equally important. It does not establish that AMS1 shares the same facility, upstreams, engineers, customers, equipment, or recovery plan. It does not show that BKK2 can fail over into AMS1, or that AMS1 is a cold recovery platform for BKK2. It does not convert a Bangkok-labelled network into an Amsterdam-labelled or AMS-labelled operating node. A routed sibling ASN is positive company-level evidence and negative-transfer evidence at the same time: it helps calibrate the proof standard while refusing to carry the missing fact.

The difference can be expressed practically. If a customer asked whether CyberWorld Data Center Co.,Ltd. can operate a public route, BKK2 would be relevant. If the same customer asked whether AMS1 has powered racks and carrier diversity today, BKK2 would not answer. The operating boundary is the thing being purchased. A sibling route may justify diligence, but it cannot be used as capacity.

AMS1 is not a map

The label AMS1 invites a geographic story. In infrastructure naming, AMS often points to Amsterdam. But this record does not contain a Dutch address, exchange point, carrier name, rack reference, or facility identifier. APNIC's country field is Thailand. Its administrative addresses are Thai. PeeringDB has no network entry for AS136567. No route collector exposes an upstream path that could be tested for geography. No public page links the label to Amsterdam, Bangkok, or any specific building.

That matters because geography is not decorative in data-centre analysis. Location determines utility provider, grid constraint, flood exposure, route length, cross-border dependency, repair access, tax treatment, customer latency, and legal jurisdiction. A first Amsterdam node would raise different questions than a Bangkok rack, a private interconnect, or a reserved AS name. Amsterdam would need evidence of facility selection, Dutch carrier access, local power, and European operational control. Bangkok would need evidence tying AS136567 to an identified building, feeder, cooling plant, and meet-me room.

A private or dormant identity would need a status explanation.

The public evidence supports none of those mappings. It supports only an administrative name and a Thai registrant. Calling AMS1 an Amsterdam facility would turn a string into a coordinate. Calling it a Bangkok data centre would turn contact addresses into equipment placement. Calling it a live recovery node would turn a label into a failover design. Each step would add a fact that the public record does not carry.

The safer method is to hold geography open and state why the uncertainty is operationally material. A network that is actually in Amsterdam depends on Dutch grid and carrier conditions; a network in Bangkok depends on Thai utility and metro fibre conditions; a private cold site depends on activation rights and reserved capacity; a dormant registration may have no current customer exposure. Without the site, the failure path cannot be drawn.

Cyber World Tower proves a different boundary

The strongest physical infrastructure record near this company is also the main attribution trap. Bangkok's Cyber World Tower is real infrastructure territory. PeeringDB's facility record for CS LoxInfo Data Center - CW Tower names CS Loxinfo Public Company Limited as the organisation and places the facility at Cyber World Tower A, 90 Ratchadaphisek Road, Huai Khwang, Bangkok. The facility record lists exchanges and networks, but not AS136567. BKNIX's Bangkok location page identifies CSL CW at 90 CW Tower A and gives CS Loxinfo contact details. An APNIC Blog account of BKNIX says the exchange used Cyberworld Tower as a second Bangkok site to support redundancy and member access. BKNIX's own description discusses neutrality, carrier choice, support infrastructure, and 24x7 operation in its exchange environment.

That is a real operating ecosystem. It is not evidence that CyberWorld-AMS1 operates there. The operator names matter. The facility record points to CS Loxinfo. The location page points to CSL CW. The exchange record points to BKNIX and its participants. The known facility and exchange records show a building where interconnection exists; they do not show that AS136567 has a cage, rack, port, or cross-connect in that building.

CS Loxinfo's own material demonstrates how specific real facility evidence can be. Its IDC@Exchange brochure, mirrored by Data Center Map, locates a Cyberworld data centre on the fourth floor of Tower A and describes power, UPS, distribution, generator, fuel, cooling, fire, and water-control systems. A facility directory page attributes 1,500 square metres and 385 racks to CSL at the location. CS Loxinfo's colocation terms identify CS Loxinfo Public Company Limited as the service company for the defined colocation and related services. A Thai securities filing about CSL discusses CSL's Bangkok data-centre operations and identifies electricity as a major service cost.

Those details belong to CSL and CS Loxinfo unless a direct source connects them to CyberWorld Data Center Co.,Ltd. The naming similarity is dangerous: "CyberWorld Data Center" and "Cyberworld data centre" can blur in a search result. In infrastructure, that blur creates false capacity. A tenant, reseller, contact address, facility operator, exchange operator, building owner, and network registrant can all appear around the same tower while controlling different pieces of risk. The public evidence puts the known plant in CS Loxinfo's column. It keeps AS136567 in CyberWorld Data Center Co.,Ltd.'s registry column.

It does not bridge the two.

Power evidence starts before the rack

A data centre is a power-delivery system before it is a computing service. The useful first question for AMS1 is therefore not how many racks the name might imply, but where electricity would enter the operating boundary and how far it would remain protected.

Thailand's own investment framework gives a benchmark for what serious data-centre evidence looks like. The Board of Investment digital-infrastructure conditions describe requirements such as telecommunications links, concurrent maintainability, full-load continuous-rated generators, backup generation for unit failure, UPS and cooling backup, independent distribution, fire protection, and security. Those conditions do not certify AMS1. There is no public evidence that AMS1 is a promoted project, much less that it meets those requirements. They are useful because they show the level at which a government distinguishes a data-centre project from a mere label.

For AMS1, the key power facts are absent. No public source names the utility service, feeder, contracted capacity, transformer arrangement, switchgear topology, UPS system, battery autonomy, generator rating, fuel tank, refuelling arrangement, rack distribution, or load-test result. There is no statement of commissioned IT load, no occupied load, no saleable reserve, and no description of what remains powered during a utility interruption. Even a confirmed rack would not answer those questions; a rack can exist without enough protected capacity to support a customer promise.

This is where common overstatements begin. Two utility cables are not necessarily two independent upstream sources. Two transformers can still depend on one service. A and B rack feeds can converge at the same board. A generator can start but not carry the cooling load. A fuel tank can exist without reliable refuelling access during a city disruption. Real resilience is traced from the utility source through switchgear, UPS, distribution, generator, fuel, cooling, and rack load while a representative service is running. AMS1 has not made that chain visible.

Bangkok utility context reinforces the question without answering it. The Metropolitan Electricity Authority publishes planned outage notices, and its outage-management description describes distribution monitoring and restoration systems. Those materials do not show a CyberWorld-AMS1 feeder or incident. They show that utility events are ordinary enough that an operator must be able to bridge them. A data-centre claim lives or dies at that handoff.

Capacity cannot be borrowed

No public source gives an AMS1 capacity number. There is no design megawatt figure, no installed critical power, no commissioned IT load, no floor area, no rack count, no occupied capacity, no contracted capacity, no saleable reserve, no lit bandwidth, and no failure-condition reserve. That absence prevents a more subtle error: treating any nearby number as if it belonged to the subject.

The CS Loxinfo figures at Cyber World Tower are the clearest example. The 1,500-square-metre and 385-rack claims in Data Center Map, and the transformer, UPS, generator, cooling, fire, and water-control details in the CS Loxinfo brochure, are useful contrast evidence. They show the sort of physical denominators that a real facility discloses. But the sources attribute those denominators to CSL or CS Loxinfo, not to CyberWorld Data Center Co.,Ltd. or AS136567. Borrowing them would turn a separate operator's plant into CyberWorld capacity.

The same rule applies to routing numbers. BKK2's 103.20.120.0/24 and two IPv6 /48s are live network evidence for AS136566. They are not data-centre capacity, and they do not indicate how much server load, rack power, or transit capacity the company can sell. AS136567's zero visible prefixes are not a capacity number either. They are an absence of public lit-route evidence. Capacity requires a defined asset, unit, status, and operating condition.

In data centres, the relevant unit is often not square metres but protected kilowatts. A room can fit racks that cannot be powered at the density customers need. A transformer can have nameplate capacity that cannot be fully sold because of UPS, cooling, generator, or reserve constraints. A generator can support a critical subset rather than the full IT load. A site can have built capacity that is not energised, energised capacity that is not commissioned, commissioned capacity that is occupied, and installed capacity that cannot be used during a component failure. AMS1 discloses none of those layers.

Thailand's policy direction also makes capacity precision more important. In May 2025, the BOI linked data-centre investment promotion to power-use effectiveness and resource management. In July 2026, the BOI said power readiness, water, environmental effects, and clean-energy transition would be examined together for data-centre projects. Those are national policy signals, not subject evidence. They underline the same discipline: power, water, cooling, and environmental readiness cannot be inferred from a company name.

Cooling, fire, and water decide whether power is useful

Power continuity is only half the facility story. A server can remain electrically alive while heat accumulates, air paths fail, a water leak crosses a room, or fire systems force a shutdown. For AMS1, none of the public records describes cooling topology, design temperature, humidity range, chiller or precision-cooling reserve, pump or condenser dependency, environmental monitoring, fire compartmentation, suppression, leak detection, drainage, or emergency access.

The CS Loxinfo brochure is again useful only by contrast. It describes precision cooling, FM200 suppression, fire-rated walls, sealed junctions, and leak sensors for the CS Loxinfo Cyberworld facility. Those are the sorts of details that let an engineer ask whether a single failed cooling unit, pump, power board, or control system can move the data hall toward thermal shutdown. They cannot be assigned to AMS1. If AS136567 is in that building as a customer or tenant, the relevant question would be which systems are supplied by the host and which remain under CyberWorld's control. Public evidence does not answer that.

City risk context has the same boundary. The World Bank's Thailand Economic Monitor discusses Thailand and Bangkok flood exposure and recalls the scale of the 2011 flood disaster. That does not locate AMS1 in a flood-prone room, nor does it say a CyberWorld facility has ever flooded. It explains why an unidentified Bangkok-linked data-centre claim needs site-specific elevation, drainage, barrier, access, generator-placement, and fuel-storage evidence. A fourth-floor data hall and a ground-level generator yard do not have the same exposure; a tower office and an operating data room do not carry the same recovery burden.

The missing cooling and protection data also limits recovery analysis. Without a thermal design and current load, there is no way to estimate ride-through time after a cooling fault. Without fire compartmentation and suppression scope, there is no way to understand whether an incident is isolated to one room or disrupts the entire service. Without water detection and drainage evidence, city flood context stays general. Infrastructure analysis needs the path from hazard to service failure; AMS1 currently provides the hazard context and not the path.

Carrier diversity must be physical

The carrier test is stricter than asking whether a building has many networks nearby. A data-centre customer needs to know which carriers enter the facility, where the meet-me room sits, whether entrances are diverse, whether routes share ducts or street corridors, whether exchange access survives a local fault, and whether traffic can move under load after a maintenance event or fibre cut.

Cyber World Tower's CS Loxinfo and BKNIX environment appears rich. PeeringDB and BKNIX sources show exchanges and networks around the CSL CW location. The APNIC Blog account explains why BKNIX used two Bangkok sites. Those facts matter for Bangkok interconnection history. They do not place AS136567 on a port, cross-connect, carrier, or exchange fabric. The PeeringDB network query for AS136567 returns no entity, and RIPEstat sees no neighbours. There is no public routing policy, looking glass, route-origin authorisation package, or customer prefix list for AMS1.

Even BKK2's two observed neighbours cannot be lifted into AMS1. Observed AS neighbours are logical adjacencies, not proof of physically independent carriers. Two BGP sessions can share a building entrance, duct, metro provider, bridge, power board, or optical platform. Conversely, a private service can be physically diverse without appearing in public route collectors. The point is not that public routing is the only evidence. The point is that AMS1 supplies neither public routing evidence nor a private disclosure that would replace it.

A credible AMS1 carrier claim would identify the facility, meet-me room, cross-connect provider, carriers, exchange ports, prefixes, route policy, physical entrances, and recovery behaviour. It would show that a carrier maintenance event or single fibre failure does not simply remove the service. If the node is private, counterparties should receive equivalent documentation under confidentiality. If the node is cold standby, activation steps and reserved circuits should be stated. At present, the public record leaves the carrier boundary blank.

The failure paths remain hypothetical

Because AMS1 has not been tied to a site, each failure path has to be written as a conditional. That is less dramatic than inventing an outage, but it is more useful.

If AMS1 is an operating colocation or hosted-infrastructure node, the first failure path is utility loss. The service would need UPS ride-through, generator start, fuel continuity, and cooling support under load. The first affected parties would be customers whose servers or network devices sit behind that boundary. The consequence could be a clean ride-through, a controlled transfer, thermal stress, hard shutdown, or carrier-only outage depending on the design. No public record says which.

If AMS1 is a routed network service, the first failure path may be carrier loss rather than power. A router can remain alive while an upstream circuit, meet-me room, or optical system fails. Customers would see withdrawn routes, packet loss, higher latency, or manual rerouting depending on prefix design and alternate paths. With no AS136567 prefixes or neighbours visible, there is no public baseline from which to measure a withdrawal or a congested alternate.

If AMS1 is a recovery site for another CyberWorld identity, the principal failure may occur at activation. A cold site can fail because reserved racks were not powered, data replication was incomplete, IP space could not move, DNS changes were slow, credentials were missing, or carrier circuits were not live. A hot site usually leaves more evidence. Neither case is confirmed here, and BKK2's live route table should not be treated as a recovery proof.

If AMS1 is planned, reserved, or dormant, the failure path lies before customer service: permitting, utility allocation, equipment procurement, carrier provisioning, commissioning, or commercial demand may never have reached an operating state. That possibility fits the long gap between the 2017 registration and the current absence of visible routing. It does not prove cancellation. It does mean a current milestone, service statement, or route activation is needed before the label can carry operational weight.

These conditionals matter because they avoid false severity. There is no evidence of an AMS1 outage affecting customers. There is also no evidence of a live AMS1 service that would absorb a failure. The defensible statement is that the public record cannot yet trace a failure from a component to a customer impact.

Customers need a boundary map before they need a logo

The customer question is not whether the word "data centre" appears in a company name. It is which organisation controls each part of the service when something breaks. A tenant may own servers. A facility operator may own the data hall, power chain, cooling plant, fire system, and security procedures. A network operator may own routers and addressing. Carriers may own external fibre. A building owner may control access, risers, and structural systems. A utility controls distribution up to the service boundary. A customer may control workload failover.

The Cyber World Tower evidence shows why those roles must be separated. CS Loxinfo is the public operator attached to the known CW Tower data-centre records. BKNIX is the exchange operator attached to the known exchange context. CyberWorld Data Center Co.,Ltd. is the registrant attached to AS136567 and AS136566. Public evidence does not collapse those roles into one. If CyberWorld is a tenant, reseller, customer, or former contact at the tower, the operational responsibilities would be different from ownership of the facility plant. If AMS1 is elsewhere, the tower evidence may not be relevant at all.

For a prospective customer, the minimum boundary map would identify the data-hall operator, rack or cage scope, power circuits, cooling zone, meet-me room, carriers, prefixes, upstreams, support desk, maintenance notice path, emergency access, and recovery site. It would also state which parts are under CyberWorld's control and which are purchased from a host or carrier. Without that map, a buyer cannot tell who can authorise repairs, reroute traffic, add power, prioritise restoration, or compensate for failure.

The same requirement applies to investors and partners. A company with a live ASN and a data-centre name may be a legitimate niche operator, but valuation changes sharply depending on whether it owns physical plant, leases racks, resells services, operates routing only, or holds dormant resources. Number-resource control is valuable but light. Energised space, contracted power, cooling, carrier diversity, staff, and tested recovery carry the capital weight. AMS1 has not made those heavier assets public.

What would turn the label into operating evidence

CyberWorld Data Center Co.,Ltd. would not need to publish sensitive floor plans or customer names to strengthen the AMS1 record. A compact set of current operating facts would be enough.

First, identify the site or state the non-site status. If AMS1 is in a third-party facility, name the facility operator and the boundary between host systems and CyberWorld systems. If it is not an Amsterdam node, clarify the label. If it is reserved, private, dormant, or closed, say that directly. Ambiguity is what allows a label to be mistaken for capacity.

Second, identify the power and cooling state. State contracted utility capacity, commissioned IT load, occupied load, saleable reserve, redundancy basis, UPS topology, generator support, fuel autonomy, cooling design, environmental monitoring, fire protection, and water controls. The useful distinction is not "has power" versus "does not have power"; it is design capacity versus installed capacity versus energised capacity versus usable capacity under failure conditions.

Third, identify connectivity. Publish or privately supply the prefixes intended for AS136567, route-origin authorisations, routing policy, upstream carriers, exchange ports, meet-me room, cross-connect arrangements, and physical-entrance diversity. Once a public service is live, route collectors should see it. If the service is intentionally private, counterparties still need evidence of path diversity and activation rights.

Fourth, identify recovery. A tested failover is different from a design claim. The useful record says when power transfer was tested, what load was present, whether cooling stayed inside limits, which carrier path was removed, how routes moved, how long customers noticed impairment, and what failed. Maintenance history matters because concurrent maintainability is proven during isolation and replacement, not on a diagram.

These disclosures would not make AMS1 large. They would make it legible. Small infrastructure can be reliable when its boundaries are clear and tested. Large claims can be fragile when their denominators are hidden. CyberWorld-AMS1 is not being penalised for being small or quiet; it is being held to the ordinary burden of an infrastructure dependency.

Maintenance is the proof that the diagrams worked

The last missing category is maintenance evidence. Design language often makes infrastructure sound deterministic: dual feeds, redundant UPS modules, spare cooling units, multiple carriers. The real test comes when one of those components is deliberately isolated, repaired, replaced, or fails at the same time as another dependency. A service that looks resilient on a drawing can become exposed during a maintenance window if the remaining path is undersized, if the reserve component is already unavailable, or if staff have to choose between keeping customers online and protecting equipment.

For a data-centre operator, credible maintenance evidence starts with scope. Which systems can be worked on while customers remain in service: utility switchgear, UPS modules, batteries, generators, fuel pumps, power distribution units, cooling units, controllers, fire systems, access systems, routers, optical shelves, and meet-me-room cross-connects? Which work is intrusive enough to require a customer notice? Which work removes the last layer of redundancy? Which work is prohibited during high-risk weather, grid events, or carrier maintenance periods? AMS1 has no public policy or history answering those questions.

Recovery evidence is narrower and more demanding. It should show that a representative customer load stayed online after a utility failure, that generators carried both IT and cooling, that temperatures remained within limits, that a cooling unit could be lost without thermal escalation, that a carrier path could be removed without isolating prefixes, and that escalation contacts actually reached people with authority to act. The useful record is not a generic statement that redundancy exists.

It is a dated exercise or incident account that says what was removed, what load remained, how long transfer took, which alarms fired, what customers saw, and what was corrected afterward.

AS136567's routing silence makes this maintenance gap more severe. If the network had stable public prefixes, a reader could at least compare maintenance claims against observed withdrawals, neighbour changes, or route history. If the facility were listed in an interconnection directory, the reader could identify ports and possible carrier alternatives. If the data hall were disclosed, the reader could ask whether host-facility maintenance windows are separate from CyberWorld's own network maintenance. In the current record, those cross-checks are missing together.

This is also where the BKK2 control remains useful but bounded. A live sibling network may have its own operational routines, but those routines do not prove AMS1 readiness. A failover exercise from BKK2 into AMS1 would be important evidence if it existed publicly: it would show reserved capacity, routing preparation, data or service replication, and staff procedures. No such exercise is public. Until it is, maintenance and recovery remain the place where AMS1's data-centre label is weakest.

The investment question is option value

Thailand is attracting heavier data-centre attention, and policy has moved toward tighter scrutiny of power, water, environmental effects, and resource efficiency. In that market, a company whose name includes Data Center and whose registrant controls Internet number resources can look strategically positioned. The risk is that thin public evidence gets priced as if it were physical plant.

On the current record, AMS1 is best treated as option value. The company identity exists. The AS registration exists. The sibling BKK2 network is live enough to show that the registrant can operate visible routes. Those facts justify diligence. They do not justify treating AMS1 as a commissioned facility, a second geography, a recovery site, or a saleable data-centre asset.

That distinction protects both sides of a transaction. A customer should not depend on AMS1 until the site, power, cooling, carrier, and recovery facts are shown. A lender should not value unnamed capacity as if transformers, generators, and cooling plant were already commissioned. A partner should not assume the CS Loxinfo tower plant belongs to CyberWorld. CyberWorld, if it is building or reserving something legitimate, should not have its position distorted by search-result confusion with a different operator's facility.

The practical sequence is clear. Corporate identity and AS registration open the door. BKK2's public routes justify asking technical questions. A production dependency waits for current AMS1 operating evidence. That is the restrained conclusion a sparse infrastructure record deserves.

Verdict

CyberWorld-AMS1 is a valid APNIC autonomous-system identity held by CyberWorld Data Center Co.,Ltd. It is not, on public evidence refreshed on July 13, 2026, a verified operating data-centre node.

The decisive point is the combination of absences: no announced AS136567 prefixes, no visible route history above RIPEstat's threshold, no observed neighbours, no current BGP routes, no PeeringDB network entity, no disclosed facility, no subject-specific power design, no cooling design, no capacity statement, no customer dependency, and no tested recovery record. The live BKK2 sibling proves that the registrant can produce public routing evidence. The CS Loxinfo and BKNIX records prove that similarly named Bangkok infrastructure exists under other operating boundaries. Neither fact supplies the missing AMS1 boundary.

The fair reading is neither accusation nor promotion. AS136567 may be reserved, private, planned, dormant, or awaiting a future service. Those states can all be legitimate. What they cannot carry without more evidence is a claim of current, resilient data-centre capacity. To make the label stand up, CyberWorld-AMS1 has to connect its name to a site, a power chain, a cooling chain, carrier paths, live or private routing evidence, and a recovery record that survives something breaking.