Summary

  • The strongest identity evidence is the registry record, not a live route. APNIC RDAP for AS132318 identifies EXABYTES-CLOUD-MY, country MY, Exabytes Cloud Sdn.Bhd. as registrant, and the address 1-18-8, Suntech @ Penang CyberCity, while RIPEstat AS overview marks AS132318 unannounced on 12 July 2026.
  • The named cloud ASN is not currently carrying visible public routes. RIPEstat routing status reports zero IPv4 prefixes, zero IPv6 visibility and zero observed neighbours for AS132318, with last visible activity on 25 April 2017; CAIDA AS Rank also marks the AS unseen with zero prefixes and zero external degree.
  • The assigned cloud address space still matters, because it appears to be routed elsewhere in the Exabytes group. APNIC RDAP for 45.127.4.0/22 assigns that block to EXABYTES-CLOUD-MY, but RIPEstat prefix overview shows the live origin as AS46015, Exa Bytes Network Sdn.Bhd.; RIPEstat RPKI validation marks that origin valid.
  • Exabytes' wider Malaysian network is visibly alive. RIPEstat routing status for AS46015 shows 24 IPv4 prefixes, 11,264 IPv4 addresses, one IPv6 /32 and seven observed neighbours, while PeeringDB's AS4769 profile lists Exabytes Enterprise MY01 with one facility, one exchange attachment and a 10G MyIX connection.
  • The public evidence supports a real Exabytes hosting operation but a downgrade for the assigned cloud label. Product pages for Exabytes Vision Cloud, NVMe VPS and colocation show commercial hosted-capacity offers, yet public material does not prove which Suntech racks hold customer workloads, whether AS132318 has any live role, how much capacity is spare, or how customers recover from power, upstream, hardware, billing or migration failure.

The Suntech registration is real, but the route is quiet

The assignment begins with a precise label: EXABYTES-CLOUD-MY 1-18-8, Suntech @ Penang CyberCity. That label is not just a marketing phrase. It is visible in APNIC's number-resource system. APNIC RDAP for AS132318 names the autonomous system EXABYTES-CLOUD-MY, gives Malaysia as the country, records 3 July 2012 as the registration date, and lists Exabytes Cloud Sdn.Bhd. as the registrant. The same record places the organisation at 1-18-8, Suntech @ Penang CyberCity, Lintang Mayang Pasir 1, with Exabytes Cloud network contacts and validated abuse contact remarks dated April 2026.

That is a useful anchor. It tells a customer that the Suntech label is attached to a real APNIC resource holder rather than only to an old directory scrape. It also tells us that Exabytes Cloud Sdn.Bhd. has had a long-lived resource identity in Malaysia. The APNIC RDAP record for 103.13.120.0/22 and the APNIC RDAP record for 45.127.4.0/22 both use the EXABYTES-CLOUD-MY name and the Suntech address. Those two IPv4 blocks are more concrete than a slogan because they are address resources customers or operators can route, filter, log and investigate.

The route table, however, makes the story more cautious. RIPEstat AS overview for AS132318 marks the assigned cloud ASN as not announced on 12 July 2026. RIPEstat routing status reports zero visible IPv4 prefixes, zero IPv6 equivalents and zero observed neighbours, while also showing the last visible route for AS132318 as 103.13.120.0/22 on 25 April 2017. RIPEstat announced prefixes returns an empty current-prefix set. CAIDA AS Rank reaches the same basic conclusion by marking AS132318 unseen, with zero cone prefixes and zero provider, peer or customer degree.

That does not mean Exabytes Cloud has no hosted capacity. It means AS132318 is not the public proof of that capacity today. A cloud service can be sold under one company name, held through one address registration and delivered through another related network. A provider can also keep an old autonomous-system number for administrative, migration or future use while customer workloads ride on a more established edge. The risk for a buyer is not that every quiet ASN is a dead company.

The risk is that a quiet ASN cannot answer the questions customers most need answered: which upstreams carry the service, which facility houses it, which address blocks are live, where failover goes, and how much route diversity exists during a maintenance event.

This is why the public assessment has to separate identity from operation. The identity record is strong: Exabytes Cloud Sdn.Bhd., the Suntech address, MY country code, long-running APNIC registration, and validated contact remarks. The direct operating evidence for AS132318 is weak: no visible current routes and no public neighbours. The wider Exabytes operating evidence is stronger, but it belongs to a broader network surface that must be tied back to the assigned cloud label with care.

The live capacity evidence moves through other Exabytes network edges

Following the assigned cloud IPv4 space shows the first important bridge. APNIC RDAP for 45.127.4.0/22 identifies that block as EXABYTES-CLOUD-MY, assigned portable space for Exabytes Cloud Sdn.Bhd. at the Suntech address. But RIPEstat prefix overview for 45.127.4.0/22 says the prefix is currently announced by AS46015, whose holder is Exa Bytes Network Sdn.Bhd. RIPEstat prefix routing consistency shows the same route in BGP and APNIC route data, and RIPEstat RPKI validation marks AS46015 as a valid origin for that /22.

AS46015 is not a ghost. APNIC RDAP for AS46015 identifies Exa Bytes Network Sdn.Bhd., the Suntech Penang Cybercity address and a 2009 registration date. RIPEstat AS overview marks AS46015 announced, and RIPEstat routing status reports 24 IPv4 prefixes, 11,264 IPv4 addresses, one IPv6 /32 and seven observed neighbours. RIPEstat announced prefixes lists the live set, including 45.127.4.0/22, 103.6.196.0/22, 103.18.244.0/22, 103.233.0.0/22, 110.4.40.0/21, 117.53.152.0/22, 137.59.108.0/22 and 2402:6c00::/32. CAIDA AS Rank also sees AS46015, with two providers and eight peers in its inferred relationship view.

The second Exabytes edge is AS4769. APNIC RDAP for AS4769 also identifies Exa Bytes Network Sdn.Bhd. and the Suntech Penang address. RIPEstat routing status for AS4769 reports six visible IPv4 prefixes, 1,024 IPv4 addresses and five observed neighbours. RIPEstat announced prefixes includes 103.13.120.0/23 and 203.142.6.0/23 plus more-specific /24s. CAIDA AS Rank for AS4769 sees the AS as active, with two providers and six peers.

PeeringDB adds a facility and exchange clue for AS4769. PeeringDB's network entry for AS4769 calls the network Exabytes Enterprise MY01, includes an Exabytes cloud website field, marks the network type as content, states Asia Pacific scope, and lists one exchange count and one facility count. PeeringDB's facility attachment for that network places the local AS4769 presence at AIMS Kuala Lumpur. PeeringDB's exchange attachment shows MyIX, 10,000 Mbps, IPv4 address 218.100.44.97, IPv6 address 2001:de8:10::1e and route-server peering marked true.

This public route picture changes the risk discussion. It is not accurate to say Exabytes lacks a visible Malaysian routing operation. It plainly has one. It is more accurate to say the assigned Exabytes Cloud ASN is quiet, while related Exabytes network edges carry active prefixes and a live exchange/facility footprint.

For customers, that creates a boundary question: when they buy Exabytes Vision Cloud, VPS, dedicated server, colocation or managed capacity, which Exabytes legal entity contracts with them, which network originates their traffic, which facility houses the workload, and whether the cloud registration at Suntech has any operational role beyond registration and contact identity.

The answer matters because failure moves through the actual path, not the brand path. A customer does not suffer an outage at a logo. It suffers an outage where the server, hypervisor, storage fabric, switch, upstream, cabinet power feed, support queue or billing state fails. If the live path is AS46015, then the diversity and maintenance questions should be asked about AS46015. If a service rides through AS4769 at AIMS or MyIX, then facility and exchange dependency should be included. If old Exabytes Cloud address space is used on a related origin, then address-custody and route-origin controls should be verified.

The public evidence points to those questions; it does not finish them.

Exabytes sells real cloud and hosting products, but the public pages do not locate every dependency

The commercial layer is visible. Exabytes' Vision Cloud page describes enterprise virtual machines and markets the service around performance, sovereignty and economics. The NVMe VPS page offers VPS plans with full root access and premium support language. The dedicated server page presents physical-server rental as a managed hosting option. The colocation page markets rack space, network bandwidth, power and cooling. These are exactly the service categories that turn a cloud company into an infrastructure dependency: virtual machines, server hardware, cabinets, power, network ports, storage and people.

The product mix is important because each offer fails differently. A VPS customer depends on the host node, hypervisor, shared storage or local disks, upstream network, provisioning panel, backup state and support response. A dedicated-server customer depends on the physical machine, spare parts, remote-hands response, boot media, out-of-band access and replacement policy. A colocation customer may own the server but still relies on the provider for rack power, cooling, cross-connects, facility access, escorted work and incident communication.

A Vision Cloud customer may be trying to replace capital expenditure with rented virtual capacity, but that capacity still sits on servers in a building with contracts, maintenance windows and finite capacity.

The difference between installed capacity and usable capacity is the discipline here. A hosting company can advertise packages before every underlying constraint is easy to inspect from the outside. Installed capacity is what the provider has physically deployed: server nodes, storage arrays, switches, power distribution and rack space. Usable capacity is what remains after overhead, reserved failover headroom, replacement stock, network commit, support coverage, maintenance windows and existing customer load. Sellable capacity is the commercial layer that appears on product pages. A customer can see the sellable layer.

Public evidence rarely shows the installed or usable layers unless the operator publishes facility scope, hardware inventory, occupancy, redundant power design, route diversity and recovery tests.

Exabytes' pages prove market intent and service availability at a brand level. They do not prove how much capacity is currently free in Penang, which racks are assigned to cloud versus hosting, whether Vision Cloud capacity is in Penang, Kuala Lumpur, Cyberjaya, another Malaysian facility, or a mixed footprint, how spare parts are staged, or whether every advertised server class can be replaced during a regional supply delay. The Exabytes service-level-agreement PDF is useful because it frames support and availability promises, but public SLA language is not the same as a live-load report or a customer recovery exercise.

The data-centre pages widen the picture without closing it. Exabytes' colocation page and colocation terms describe hosting in data-centre terms, including rack space, bandwidth, power, access conditions and customer responsibilities. Exabytes' data-centre visitation guide for OpenDC PG1 shows that Exabytes has procedural controls for a Penang data-centre visit environment. That is operationally relevant because cloud capacity is not abstract when a technician needs access, an escorted visit must be scheduled, or hardware has to be touched.

But a visit guide is not an occupancy statement. A colocation page is not a route-diversity test. A product page is not a spare-hardware ledger. The fair reading is that Exabytes operates a real Malaysian hosting portfolio, while the public record still requires facility-by-facility verification before a customer treats a particular workload as physically placed, resilient and recoverable at the Suntech cloud registration.

The Penang address is an anchor, not a complete facility map

The Suntech address appears in multiple independent places. APNIC's AS132318 record, APNIC's 45.127.4.0/22 record, APNIC's AS46015 record and Exabytes' Malaysia contact page all point to 1-18-8, Suntech @ Penang Cybercity, Bayan Baru/Penang context. That consistency matters. It shows that the address is not a one-off typo or a stale third-party copy.

Still, an office or registered network address should not be treated as proof that every customer workload lives in that room or building. Suntech may be a corporate, support, network-contact, administrative or facility-adjacent anchor. APNIC records identify resource holders and contact addresses; they do not publish rack diagrams. WordPress business-address markup gives a business address; it does not state which floors contain production servers, which power feeds are used, which carriers terminate there, or whether cloud workloads are split between Penang and Kuala Lumpur.

This distinction is especially important because Exabytes has public evidence of Kuala Lumpur and AIMS-related network presence. APNIC RDAP for AS46015 includes Exabytes network-operation contact addresses at Menara AIMS in Kuala Lumpur. PeeringDB's facility record for AIMS Kuala Lumpur lists the facility at Ground Floor, Menara AIMS, Changkat Raja Chulan, with a large network count. PeeringDB's AS4769 facility attachment specifically places Exabytes Enterprise MY01 at AIMS Kuala Lumpur. That does not contradict the Penang registration; it shows that the wider Exabytes operating surface is multi-address and multi-context.

For customers, the basic diligence question is placement. Where is the primary instance? Where is the storage? Where are snapshots or backups? Where are logs? Where is the control panel? Which address appears on the contract? Which Exabytes entity can access the data? Which data centre provides remote hands? Which carriers are used for public Internet and private links? Which location carries disaster recovery? A Malaysian company, a Penang address and a MY country field are useful, but they do not by themselves answer these placement questions.

The reason to push on placement is not academic. Cloud failure is usually local before it is global. A switch fabric can fail in one facility. A cooling event can affect a rack row. A planned building power shutdown can create customer maintenance windows. A carrier path can be diverse on paper and still share a meet-me room or duct. A support team can have authority to reboot a virtual server but not to replace a failed power supply until a data-centre access rule is satisfied. If a customer is buying data locality or low-latency Malaysian hosting, it needs the exact physical and legal locality, not only the brand's national market.

The public record gives enough evidence to identify Exabytes' Malaysian footprint as real. It does not give enough evidence to say that the assigned Suntech cloud label alone contains the whole service delivery map.

Transit and peering are visible, but redundancy has to be proven on the live path

AS132318 cannot prove current route diversity because it is not visibly announced. The more relevant network diversity evidence is on AS46015 and AS4769. RIPEstat ASN neighbours for AS46015 reports seven unique neighbours in the latest available snapshot, with two left-side neighbours and five uncertain neighbours. RIPEstat AS routing consistency for AS46015 lists import and export relationships visible in BGP for AS38182, AS9930, AS1828, AS24482, AS35280, AS38001 and AS55720. That is materially stronger than a single-upstream host.

The names need careful interpretation. A neighbour list is not a service-level commitment. It does not show contract terms, default-route acceptance, traffic engineering, geographic separation, physical entrance diversity, maintenance coordination or whether all neighbours can carry customer load during a failure. Some neighbours can be peers, some can be transit, some can appear through exchange fabric, and some can be uncertain in path inference. Route diversity, carrier diversity and physical diversity are related but not identical.

AS4769 adds a peering clue. PeeringDB's network entry for AS4769 says Exabytes Enterprise MY01 has one exchange count and one facility count, and PeeringDB's exchange attachment shows operational MyIX connectivity at 10G. RIPEstat ASN neighbours for AS4769 reports five unique neighbours. These are positive signs for reachability, especially for Malaysian and Asia-Pacific traffic. They do not tell us whether the cloud product is delivered through AS4769, whether the assigned Suntech cloud blocks ride that path, or whether customer traffic has automatic failover to a different facility or carrier.

The strongest safe conclusion is this: the wider Exabytes network has visible route and exchange activity; the assigned cloud ASN does not. Therefore, a customer should make redundancy questions conditional on the service actually purchased. For a VPS using an address out of 45.127.4.0/22, the relevant path appears to be AS46015. For an enterprise service using AS4769-connected capacity, MyIX and AIMS context may matter. For a colocation customer, the customer's own carriers may matter more than Exabytes' own origins. For a managed-cloud customer, the provider's internal design may determine failover before BGP does.

The settlement evidence is straightforward. Exabytes could provide a current route map for the purchased service, the exact originating AS, upstream and peering list, physical data-centre location, carrier handoff diversity, RPKI and route-object controls, maintenance-notice practice, and test evidence showing that one upstream or exchange event does not make the service unreachable. Public route data gets the customer to the first hard questions. It does not replace the answers.

Maintenance notices show the cloud is tied to buildings, power and upstream windows

Public support notices are valuable because they puncture the illusion that hosted capacity is frictionless. Exabytes' support site includes several notices that show service dependency on buildings, upstream links, billing systems and server-specific repair work. A notice for Penang SUNTECH power maintenance ties service planning to a building power event. A notice for MY data-centre upstream network maintenance shows that upstream work can be scheduled and customer-facing. A billing-system maintenance notice reinforces the same point from the administrative side: a cloud or hosting provider's operating calendar includes rooms, circuits, customer accounts and maintenance windows.

Those notices are not evidence of chronic weakness. Mature providers publish maintenance notices because infrastructure has to be maintained. The relevant lesson is more practical: customers who treat hosted capacity as an always-on utility still need to understand the provider's maintenance calendar, notification lead time, expected risk, rollback procedure, support channel and customer action requirements. If a customer has a single VPS, a billing portal, an application database and backups all in the same dependency chain, even a planned window can become a business incident.

Hardware-specific notices matter too. Exabytes has published service disruption notices for named hosts, such as a service disruption notice for a server in 2020 and other support updates that show the ordinary world of hosting: a server name, an incident, a status update, and a restoration effort. The public point is not the old server itself. It is that the cloud stack still reduces to physical boxes, disks, network cards, controllers and storage. A virtual server is easy to move only if the provider has spare capacity, shared storage or good backups. A dedicated server is replaceable only if stock, access and configuration state are available.

The Acronis backup page for VPS is relevant in the same way. Backup is a commercial product because recovery is not automatic by default. A customer who assumes the provider can restore any workload after a node failure may be wrong unless backup is included, configured, tested and retained in a separate failure domain. The Exabytes legal service-level-agreement page should also be read closely by buyers, because contractual credits, support response, customer responsibilities and service exclusions often define the real recovery economics.

The article's title mentions repair windows for this reason. Cloud buyers often focus on benchmark performance and monthly price. The hard dependency is time: time to detect, time to notify, time to gain data-centre access, time to replace hardware, time to reroute, time to restore data, time to migrate a customer, and time to resolve billing or account locks. The public record does not prove Exabytes fails these tasks. It proves that the tasks exist and that customers should not buy capacity without asking how they are handled.

Hosting economics make overcommit and spare capacity central

Hosting economics sits behind every resilience promise. VPS and cloud products usually work because providers pool CPU, memory, storage, IP addresses, network transit and support labour across many customers. That pooling lowers prices and improves utilisation. It also creates the need for discipline. If too much capacity is sold too tightly, a hardware failure or maintenance event leaves too little spare headroom. If spare headroom is large, prices rise or margins compress.

Customers rarely see the tradeoff directly, but they experience it when a migration is delayed, a replacement node is not immediately available, or support asks them to wait for the next maintenance window.

Exabytes' public pages show the commercial breadth of the portfolio. NVMe VPS emphasises fast storage and root access. Dedicated servers emphasise physical resource control. Vision Cloud frames virtual machines as an enterprise alternative to capital expenditure. Colocation offers rack and facility dependency to customers who bring their own equipment. Each product has a different spare-capacity problem.

For VPS, the hidden constraint is cluster headroom. If a host node fails, can all affected virtual machines be restarted elsewhere without oversubscribing the remaining nodes? If storage is local, how does data move? If storage is shared, what protects the storage fabric? If a customer buys low-cost VPS capacity, how much noisy-neighbour isolation exists? Public route data cannot answer those questions.

For dedicated servers, the hidden constraint is inventory. If a server's motherboard, drive controller or power supply fails, is the same class of replacement immediately available? If a customer has a bespoke disk layout or older hardware profile, does replacement require procurement? Does the provider stock spare disks and NICs at the relevant facility? Does the customer have an image, backup or configuration-management path? A dedicated server can be more predictable than a shared VPS until it breaks; then it is only as resilient as the parts shelf, data state and technician access.

For colocation, the hidden constraint is responsibility split. The provider may deliver power, rack, cross-connect and remote-hands support, while the customer owns the server and application design. If power at a rack PDU fails, the provider is central. If a customer's RAID controller fails, the customer may be central. If a carrier cross-connect is moved or congested, both parties may need to coordinate. A colocated workload can be highly resilient if the customer buys dual power, multiple carriers and off-site recovery. It can be fragile if it is simply a single server in a professional room.

For enterprise virtual machines, the hidden constraint is the contract between marketing and engineering. A page can describe sovereignty and economics, but the buyer needs workload-level architecture: availability zone or site options, backup location, snapshot consistency, data export path, hypervisor maintenance procedure, security boundary, support escalation and exit rights. Without those details, "enterprise" describes the target customer more than the proven recovery behaviour.

This is why the assigned Exabytes Cloud registration should be treated as a starting point, not a guarantee. The company has visible hosting offers and active related networks. The public record does not reveal the ratio between sold, spare and reserved capacity at the Suntech-linked operation. Buyers should ask for that ratio in service-specific terms.

Data sovereignty is a placement and access question, not a country code

The planned topic of data sovereignty is well supported because Exabytes sells Malaysian-hosted services and its Vision Cloud page uses sovereignty language. But sovereignty is easy to oversimplify. A Malaysia country field in APNIC does not prove that every customer file, snapshot, log, ticket, monitoring alert, administrator account or backup copy stays in Malaysia. A Penang address does not prove that every production instance lives in Penang. A local cloud brand does not prove that no overseas supplier, software vendor or support system can touch the environment.

Malaysia's legal context also matters. The Personal Data Protection Act 2010 creates duties around personal data processing, and Section 129 is often central to cross-border transfer discussions. That does not mean every customer must keep every workload in Malaysia. It means regulated customers should know where personal data is processed, where it is backed up, who can access it, and what contractual controls apply. A cloud service can help with locality only if its placement and access controls are explicit.

For Exabytes customers, the questions are practical. If a business buys Vision Cloud for Malaysian data residency, which data centre is used? Are backups in the same country? Is management access restricted by region or role? Are tickets and logs stored in a separate customer-support system? Does the provider use offshore subcontractors for support? Can the customer obtain an architecture diagram for its own service? Can the customer export data in a usable form if it needs to leave?

Data locality also intersects with resilience. Keeping data close may reduce latency and simplify legal analysis, but it can concentrate risk if the primary service and backups are in the same building or metro area. A Penang-only design can be attractive for local control; it can also be vulnerable to a regional power, fibre or access event. A Kuala Lumpur or Cyberjaya recovery option may improve resilience; it may change the customer's locality claim. A public Internet route can cross borders even when the server sits in Malaysia. The right answer is not a slogan. It is a placement matrix.

The public evidence does not show Exabytes' full placement matrix. It does show enough to require one. APNIC records tie cloud resources to Penang. PeeringDB ties AS4769 to AIMS Kuala Lumpur and MyIX. Product pages sell cloud, VPS, dedicated and colocation capacity. Support notices show maintenance and facility procedures. Those facts together make locality a real topic, not a decorative compliance claim.

Customers should therefore treat data sovereignty as an architectural question. "Malaysia" is the first line. The complete answer is facility, rack, backup, log, ticket, administrator, supplier, transit path, contract and exit plan.

Billing, support and migration are infrastructure too

The failure path is not only power or BGP. Hosted capacity can fail administratively. A late invoice, payment dispute, domain renewal problem, suspended account, expired card, locked portal or unresolved abuse ticket can take a service offline as surely as a failed switch. Exabytes' legal and agreement pages and service-level-agreement page are therefore not boring boilerplate; they define operational risk. Customers should read the notice periods, support scope, refund or credit terms, suspension rights, customer responsibilities and exclusions before deciding whether the service can host critical work.

Support scope changes the failure experience. Exabytes' dedicated-server guidance and product pages distinguish different levels of provider involvement. A managed service can reduce customer burden if the provider has authority, access and staffing. It can also create dependency if the customer cannot act independently during an incident. An unmanaged or root-access VPS gives the customer control, but it may leave the customer responsible for backup, patching, security hardening and application restoration. Neither arrangement is automatically better; each must match the workload and staff skill.

Migration is the final test of whether cloud capacity is portable. A customer should know how to leave before it enters. Can a VPS image be exported? Can snapshots be downloaded? Are backups in a format the customer can restore elsewhere? Does a dedicated server customer receive rescue access, disk images or only file-level backup? How long does DNS, IP renumbering or reverse-DNS update take? Can the customer bring its own IP space? Can a colocated customer schedule equipment removal without waiting for a narrow access window? Public product pages rarely answer every portability question.

The route evidence makes portability even more important. If customer IP space is tied to Exabytes Cloud allocations but originated by AS46015 or AS4769, migration may require renumbering unless the customer brings portable space. If traffic depends on MyIX peering or a specific Malaysian carrier mix, moving to another provider can change latency and reachability. If backups are sold as an add-on, a customer without that add-on may discover that its "cloud" service was never a recovery product.

In resilience analysis, support and billing are not soft factors. They are control surfaces. When the system fails, the customer meets the provider through tickets, notices, invoices, access forms, escalation names and restoration commitments. The public record establishes that Exabytes has a broad support and product apparatus. It does not prove how quickly a specific Suntech-linked workload will be migrated, restored or released under stress. That proof has to be obtained before the workload becomes critical.

What would raise the evidence grade

The first missing item is a current service-to-network map. Exabytes could state which services use AS132318, AS46015, AS4769 or another network, which address blocks are assigned to each product, and how route-origin authorisation is managed. The public data already shows that assigned cloud space can be originated by AS46015. That may be perfectly normal inside the Exabytes group, but customers should not have to guess which AS carries their workload.

The second missing item is a facility scope statement. The statement should explain which services are delivered from Penang, which from AIMS Kuala Lumpur, which from Cyberjaya or other sites, and which are multi-site. It should distinguish office address, network registration address, data-centre location and recovery location. It should say whether a customer can select placement or whether placement is assigned by product tier.

The third missing item is power and cooling evidence. Public maintenance notices show that power and data-centre work occurs. Customers need the underlying design: dual-feed options, generator and UPS arrangement, maintenance bypass, rack-density limits, cooling redundancy, fuel arrangements, environmental monitoring and historical incident communication. For a VPS customer, this can be summarised by service tier. For colocation, it should be available as a facility pack.

The fourth missing item is hardware inventory and restoration practice. How many spare nodes are kept for a virtual cluster? How are failed dedicated servers replaced? What is the restore path for a disk failure, storage failure or hypervisor failure? Are backups included, optional or customer-managed? Are restores tested? How long do restores take for common workload sizes? The Acronis backup offer makes recovery visible as a product, but buyers need to know whether their purchased service includes it.

The fifth missing item is support escalation. Critical customers need named escalation paths, out-of-hours coverage, severity definitions, expected response times, maintenance-notice lead times and a clear division between customer-owned and provider-owned tasks. A general support promise is useful, but infrastructure due diligence requires the incident chain.

The sixth missing item is exit and portability. A provider that makes it easy to leave is more credible as a critical host, not less. Exportable images, documented backup formats, clear cancellation procedures, IP portability options and data-deletion certificates reduce lock-in risk. They also reduce panic during a failure because the customer already knows the migration path.

None of these missing items proves that Exabytes is weak. They mark the gap between public evidence and customer-grade assurance. Exabytes has enough public evidence to be treated as a real Malaysian hosting provider with active related route surfaces. It does not have enough public evidence, around the assigned cloud label alone, to be treated as a fully proven resilient cloud dependency.

The evidence grade

The right public grade for EXABYTES-CLOUD-MY 1-18-8, Suntech @ Penang CyberCity is Weak, with a positive caveat for the wider Exabytes network. The weak part is specific: AS132318 is registered, active in APNIC, tied to Exabytes Cloud Sdn.Bhd. and the Suntech address, but it is not currently announced in RIPEstat, has no current visible prefixes, no observed neighbours, and is marked unseen by CAIDA. That means the assigned cloud ASN does not itself prove live hosted capacity in July 2026.

The positive caveat is equally important. Exabytes' broader Malaysian hosting operation is not weak in the same way. AS46015 is visible with 24 IPv4 prefixes, 11,264 IPv4 addresses, a valid origin for the EXABYTES-CLOUD-MY 45.127.4.0/22 block, one IPv6 /32 and seven observed neighbours. AS4769 is also visible, and PeeringDB places Exabytes Enterprise MY01 at AIMS Kuala Lumpur and MyIX. Exabytes' own public pages sell cloud, VPS, dedicated, backup and colocation services. Support notices show real maintenance and facility procedures.

The grade therefore should not be read as "Exabytes is not operating." It should be read as "the assigned cloud registration does not by itself prove the operating capacity customers care about." For ordinary hosting, customers may accept the broader Exabytes track record and product terms. For critical workloads, the buyer should require service-specific proof of placement, origin AS, facility, power, cooling, upstream diversity, spare hardware, backup inclusion, restore tests, support escalation, billing continuity and migration rights.

Cloud capacity is often sold as if it floats above rooms and routes. The Exabytes evidence says otherwise. It begins at a Penang address, passes through APNIC registrations, moves onto related Exabytes route surfaces, touches AIMS and MyIX context, and returns to the practical work of maintenance notices, backup products, support procedures and customer contracts. The company can sell hosted capacity. The customer still has to verify the racks, transit and repair windows before treating that capacity as resilient infrastructure.