Summary
- The strongest operating evidence is AS153005, registered by APNIC as
PTCLOUD-VNfor Phu Thanh Cloud Company Limited. The ASN was visibly announcing one IPv4 block,160.187.156.0/23, on 12 July 2026. That establishes a live routing surface, not a verified cloud platform or a match between every version of the company name. - The visible network is small and concentrated. It has 512 IPv4 addresses, no observed IPv6 announcement, one observed upstream through Proxel Innovations, no public PeeringDB profile and no disclosed data-centre or internet-exchange location. A valid route authorization improves routing hygiene but does not create physical redundancy.
- The corporate domain remains delegated and can receive email, but its apex published no web address on the reporting date. Public material does not identify a current VPS catalogue, hypervisor, storage design, rack count, facility owner, power topology, spare-hardware pool, service commitment or recovery objective.
- Customers should therefore treat service availability, Vietnamese data location and multi-site recovery as unverified until the contracting company supplies facility-level evidence, route and carrier diagrams, tested restore results, support escalation terms and a practical export path.
- The evidence supports a weak operating assessment: there is a real legal-and-network trail and a newly active prefix, but too little public proof to translate that trail into installed compute, usable customer capacity or recoverable service.
The missing word in the name is the first infrastructure problem
The headline entity is THANH CLOUD COMPANY LIMITED. The network attached to it is AS153005. Yet the APNIC registration for AS153005 does not use that shortened name. It identifies PTCLOUD-VN as PHU THANH CLOUD COMPANY LIMITED, gives a fourth-floor address on Vuong Thua Vu in Hanoi and names administrative and technical contacts using the ptcloud.vn domain. The APNIC registration for its IPv4 block repeats the Phu Thanh name and address.
Vietnamese company-information services point in the same direction. Infocom's company page identifies Cong Ty TNHH Phu Thanh Cloud, tax number 0110062087, as a one-member limited company established in July 2022. It lists PT Cloud as the short name and data processing, hosting and related activities as the principal registered business line. VNBIS reports the English legal name as Phu Thanh Cloud Company Limited and the same Hanoi address. These are secondary presentations of company data rather than a substitute for a fresh certificate, but their agreement with APNIC is meaningful.
That evidence makes Phu Thanh Cloud the most plausible legal identity behind AS153005. It does not entitle a reader to erase the difference between that name and THANH CLOUD COMPANY LIMITED. A missing word can arise from truncation, aliasing, translation, data cleaning or a genuinely different company. The public material reviewed here does not contain a corporate filing that says the shortened name is a formal legal alias. Nor does it show a transfer, parent-subsidiary structure or trading-name licence that would explain the variation.
For a hosting customer, this is not clerical trivia. The legal entity on the order form determines who owes a refund, who controls customer data, who can authorize engineers to enter a facility and who remains responsible if a carrier or colocation contract ends. The resource holder in APNIC determines who is accountable for the route registration. The brand on a website or invoice may be another layer again. If those names differ, the contract should connect them explicitly.
The right conclusion is narrow. AS153005 is authoritative evidence about a network registered to Phu Thanh Cloud Company Limited. It is the only strong technical anchor currently associated with the headline entity. The association is credible enough to examine, but not strong enough to treat every claim about one name as automatically proven for the other. Any serious purchase should begin with the current Vietnamese business certificate, tax identity, bank-account beneficiary, service contract and a signed explanation of the PT Cloud and THANH CLOUD names.
What can be proved to exist
The public record supports four concrete propositions.
First, a Vietnamese company called Phu Thanh Cloud Company Limited has a coherent legal footprint. The company-information pages agree on its 2022 formation, Hanoi address, representative and principal activity. A registered activity is broad permission or classification; it is not proof that every possible hosting product is currently sold. Still, it is more relevant than a name alone because data processing and hosting are central rather than incidental to the recorded business.
Second, APNIC assigned AS153005 and 160.187.156.0/23 to the company in October 2024. The block is portable address space, not merely a few addresses borrowed invisibly from another provider. The ASN and prefix records use the same organisation description, address and contacts. That alignment makes the network identity substantially stronger than an unverified social-media page or a generic cloud label.
Third, the network was active on the article date. The RIPEstat ASN overview reported AS153005 as announced on 12 July 2026. Its announced-prefix history saw 160.187.156.0/23 from 28 June through 12 July. The current BGP.tools view likewise showed the prefix in the global table. This matters because older third-party snapshots still described the ASN as inactive. The difference is best explained by timing: the route appeared after those snapshots were collected.
Fourth, the route was covered by a valid Route Origin Authorization. The RIPEstat validation result says AS153005 is authorized to originate the /23, with more-specific announcements allowed down to /24. That is sound routing hygiene. It reduces the chance that networks enforcing route-origin validation will reject the legitimate announcement and makes some forms of accidental or malicious origin misuse easier to filter.
These propositions establish an organisation, number resources and a live route. They do not identify a data hall, prove that a hypervisor cluster is running, show that customers occupy the addresses or demonstrate that the route has stayed available for a meaningful service period. The public route had been visible for roughly two weeks at the end of the observation window. A new announcement can be a production launch, a migration, a connectivity test, an address-leasing arrangement or an intermediate step. Without service and facility evidence, its purpose remains open.
A routed block is not a cloud
AS153005's /23 contains 512 IPv4 addresses. That is a useful network resource, but it is a poor unit for measuring cloud capacity. One physical server can host many virtual machines with public addresses. Many virtual machines can sit behind a shared address. Addresses can be reserved, filtered, assigned to network equipment, held for future customers or routed without any customer workload behind them. Conversely, a substantial private cloud may expose only a small public range.
The standard definition is helpful here. NIST SP 800-145 describes cloud computing through on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. It also distinguishes infrastructure, platform and software service models. None of those characteristics can be inferred from an ASN. A route supports broad network access; it says nothing by itself about automated provisioning, metering, tenant isolation or elastic resource pools.
The public material does not settle whether PT Cloud offers virtual private servers, bare metal, shared hosting, managed applications, address transit, remote desktops, proxy capacity or another service entirely. It does not show an order page, a product specification, a current service commitment or a customer portal. The ptcloud.vn domain is delegated to Cloudflare name servers and has Google mail exchangers, showing that the domain remains configured for communications. But the public A-record response and AAAA response returned no address for the apex on the reporting date. No www address was visible either.
That is not evidence that the company has stopped operating. A company can sell through direct contacts, use another brand, keep a website temporarily offline or run its service console on an undisclosed hostname. The active route points in the opposite direction from a simple closure theory. The correct finding is that a reader cannot independently inspect a current public catalogue or customer terms at the obvious corporate domain.
The distinction matters because each service has a different dependency map. A VPS offer depends on compute nodes, storage, virtual networking, address management and a control system. Bare metal adds physical inventory and hands-on replacement. Shared hosting adds web, mail, database and control-panel dependencies. Managed service adds engineers and software licences. Transit or address service may rely more heavily on routing contracts than on compute. Before judging capacity or failure, the product must be named.
The Hanoi address is an office, not a demonstrated data centre
The fourth-floor address in Thanh Xuan District is consistent across the company and network records. It is evidence of an administrative location. Nothing in those records says that it contains a production data hall, generator-backed power, precision cooling, fire suppression, secure loading access or carrier entrances. Treating an office address as the server location would turn a contact field into a physical claim it does not make.
That leaves three broad possibilities. The company may lease rack space in a Vietnamese data centre, resell infrastructure operated by another provider, or place equipment outside Vietnam while retaining a Vietnamese company and ASN. It may also use more than one of these arrangements. The public evidence does not choose among them.
Vietnam has a concentrated data-centre market. A Ministry of Information and Communications report said Viettel, VNPT, FPT and CMC accounted for about 97 per cent of the domestic market in 2024. That concentration makes leased infrastructure a practical route for small providers: they can buy racks, power and connectivity rather than finance a complete building. It does not show that Phu Thanh uses any of those four companies, and none should be treated as its supplier without a contract, cross-connect order or facility confirmation.
The facility question has to be answered at building level. A useful disclosure would identify the city and operator, whether the company owns or leases the rack, the power allocation per cabinet, the A and B power paths, generator and fuel arrangements, cooling design, fire zone, physical-access rules and carrier entrances. If there is a second site, it should identify which services are actually running there and whether it shares power, metro fibre or management systems with the first.
Facility standards should also be precise. The Uptime Institute's Tier explanation distinguishes basic capacity, redundant components, concurrent maintainability and fault tolerance. A seller saying that its servers are in a "Tier III" building is not the same as showing a current certification for the exact site, and even a certified facility does not automatically make the tenant's rack, network or software concurrently maintainable. Single-corded servers, one top-of-rack switch or one storage controller can reintroduce a failure point inside a resilient building.
No public site certification, rack photograph, facility contract or named data-centre relationship was found for the company. The physical location of customer capacity therefore remains unverified.
Installed capacity and usable capacity are different numbers
Even if a rack inventory appeared tomorrow, the customer-relevant number would not be the count of servers. Installed hardware becomes usable cloud capacity only after allowances for failure, maintenance, replication, oversubscription and growth.
Consider a small cluster with several compute nodes. Some CPU and memory must remain available so virtual machines can restart when one node is removed. Storage may keep two or three copies of data. Snapshots consume space and input-output capacity. Network links need headroom for attacks, backups and migration. A provider that allocates every visible core or every nominal terabyte has no room to absorb a failure. The same server count can therefore support a robust service or a brittle one depending on reserve policy.
Nothing public states the number or generation of PT Cloud's servers, the processor and memory inventory, storage medium, replication factor, hypervisor, oversubscription ratio, bandwidth commit, backup retention or spare capacity. There is no evidence of how much of the /23 is assigned. A customer cannot calculate installed compute, saleable compute or recoverable compute from 512 addresses.
Hardware age also changes the equation. A catalogue can advertise a virtual CPU without saying whether the underlying processors are uniform. Mixed generations complicate live migration and capacity planning. Storage performance can fall as arrays fill. Flash wear, failed disks and rebuild traffic can reduce usable input-output long before nominal terabytes run out. Firmware and software licences can limit which spare machine is actually deployable.
The evidence needed is operational rather than promotional: a dated inventory by site, current utilization ranges, failure reserve, storage replication, backup separation, network commits and the amount of capacity that remains after losing the largest node or rack. Those figures can be shared confidentially with customers. Their absence from the open web is understandable for a small private company; their absence from a serious procurement would not be.
The visible route has one observed upstream chain
Current route observation gives the clearest view of external dependency. BGP.tools showed AS153005 connected to AS401561, Proxel Innovations LLC, for IPv4. It did not show a second upstream or IPv6 path. The AS401561 record in turn showed Hurricane Electric AS6939 as its upstream. Another network directory view also placed AS153005 among Proxel's downstreams.
This does not mean packets physically travel from Hanoi to Missouri and back. An ASN's registration country is not a cable map, and a commercial relationship can be delivered through remote peering, tunnels, third-party facilities or another transport provider. It also does not prove that Proxel is the only contract: private links, backup sessions and routes invisible to the observation set may exist.
What it does show is that the global table exposed one logical exit for the prefix on 12 July. If that BGP session is withdrawn, if Proxel stops carrying the route, or if a configuration error removes AS153005 from the accepted path, the /23 can become unreachable even while every server remains powered. If AS401561's own path to Hurricane Electric fails and no alternative is available, the same result can occur one level higher.
The route's valid authorization helps with origin validation but not path diversity. RPKI says that AS153005 may originate the prefix. It does not promise that the session is up, that a second carrier exists, that cables take different entrances or that traffic is protected from congestion and distributed denial-of-service attacks. Security of the announcement and availability of the service are separate properties.
There is also no public PeeringDB network entry for AS153005. That means no voluntarily disclosed traffic level, peering policy, exchange port, facility list or operational contact can be checked there. Many small networks do not use PeeringDB, so the empty result is a disclosure gap rather than proof of isolation. In a market with a national exchange and many domestic networks, however, the absence makes it impossible to confirm local peering or a second path from that source.
Vietnam's broader Internet is actively expanding. VNNIC's Internet-resource insights count hundreds of autonomous systems and track the country's IPv6 deployment, while the government's digital infrastructure strategy calls for new international cable routes and greener data centres. National progress does not automatically diversify one small ASN. PT Cloud's own carrier sessions, physical paths and IPv6 plan still need to be shown.
Rack failure: the smallest physical fault can have the widest effect
A rack is a shared failure domain. Servers that look independent in a control panel may use the same power distribution unit, top-of-rack switch, fibre patch, management switch and cooling aisle. If the provider places compute, storage and backup in one cabinet, one breaker trip or switch failure can remove all three.
The first resilience question is therefore not how many virtual machines the platform can create. It is whether a customer workload, its storage replicas and the systems needed to recover it cross a real power-and-network boundary. Two storage copies in the same chassis protect against a disk failure but not a chassis failure. Two hosts on the same power strip protect against one motherboard but not the strip. A backup server in the next rack may still share the same electrical room and facility.
Public evidence supplies no rack layout. It also gives no maintenance policy. Planned work can expose a design that appears redundant under normal conditions: one power path is already out for service when the other fails, or one switch is being upgraded when a routing change goes wrong. Concurrent maintainability must include the tenant's equipment and operating procedure, not just the landlord's building.
Customers affected by a rack failure would vary by product. A virtual machine with replicated storage might restart elsewhere after a pause. A single bare-metal server remains down until repair. Shared hosting can take hundreds of sites offline together. A control panel can be unavailable while existing workloads continue, leaving customers unable to restart or change them. The provider should state these modes separately rather than collapse them into one uptime percentage.
Power and cooling failure: the lease transfers control, not consequence
If PT Cloud leases space, it buys electricity and cooling from a facility operator. That can be efficient, but it divides responsibility. The landlord controls utility feeds, switchgear, generators, fuel, chillers and physical security. The tenant controls its cabinet load, cabling and servers. A customer contracts with the cloud seller and may never have a direct claim against the building.
This boundary becomes important during a long outage. Generator runtime depends on load, fuel stock and replenishment. Cooling may become the limiting system even when power remains. A rack that exceeds its contracted density can create localized heat or trip protection. A facility may meet its obligation while a tenant's single power distribution unit fails.
No public evidence identifies PT Cloud's facility-level service commitment or whether compensation from a landlord flows through to customers. There is no published maintenance-notice period, power incident procedure or maximum rack density. A buyer should not assume that a building commitment and a cloud commitment are identical.
The economic incentive can work both ways. Leasing lets a small provider obtain professional plant without owning generators and chillers. It also creates fixed monthly obligations. If a colocation bill is disputed or a contract ends, the technical problem becomes access: who can enter, who owns the servers, how quickly can equipment be removed, and where can it go? A provider-contract failure can therefore resemble a hardware outage to customers even when no equipment is broken.
Route failure: powered servers can still disappear
The visible routing design is the most immediate concentration risk because only one upstream is observable. A configuration error at either end of the AS153005-to-AS401561 relationship could withdraw the /23. Filtering changes could reject it. A fibre cut could isolate the delivered session. Congestion or attack traffic could leave the route present but the service unusable.
Different mitigations address different failures. A second BGP session over the same cross-connect protects against one router, not one cable tray. A second carrier delivered through the same metro route protects against a carrier configuration error more than a civil-works cut. A remote tunnel can restore reachability but may add latency and depend on the local access network it is meant to replace. Real diversity needs logical and physical evidence.
The lack of an IPv6 announcement is another constraint. It does not make the IPv4 service non-operational, and many customers can function entirely over IPv4. It does mean the public network has no visible second protocol family through which native IPv6 customers could reach workloads. Adding IPv6 would improve protocol reach but would not count as carrier diversity if it follows the same router, fibre and upstream.
Customers should ask for the two upstream ASNs, port sizes, facilities, handoff types, last-mile owners and whether routes use separate entrances. They should also ask what happens to customer addresses during failover. A provider may have backup transit but be unable to announce the prefix from it because filters, letters of authorization or route objects were not prepared. A recovery design exists only when the route has been tested.
Hardware-stock failure: a replacement promise needs inventory
Bare metal and small clusters have a physical queue behind them. A failed disk, power supply, fan, memory module or motherboard must be diagnosed, accessed and replaced. The recovery time depends on spare stock, compatible firmware, remote hands and travel permissions, not just an alert.
The company's registered activities include computer and telecommunications equipment trading and computer repair alongside hosting. That combination is compatible with a business that can source and maintain hardware. It is not evidence of stock on a shelf at the facility. A reseller can legally trade equipment while waiting days for a distributor.
For virtual services, spare capacity can substitute for a same-model part if workloads move to another healthy node. That requires the storage and network to remain available and enough reserve to absorb the load. For dedicated servers, the customer may need an exact or equivalent replacement. If the failed machine contains local disks, repair can become a data-recovery problem rather than a simple swap.
A support commitment should therefore define the clock. Does replacement time begin when monitoring detects a fault, when a customer opens a ticket, when an engineer confirms the diagnosis or when a spare arrives? Is remote-hands service available around the clock? Who approves destructive work? Are encrypted disks and failed media retained or destroyed? None of these terms is publicly visible for PT Cloud.
Support failure: a small team can be the hidden single point
The APNIC record provides named administrative and technical contacts. That is useful accountability for number resources, but two names do not establish a 24-hour support organization. The business-information pages do not disclose headcount, shifts or an operations centre. The non-serving website leaves no public status page, ticket portal, escalation matrix or incident history to assess.
Small providers can deliver excellent service because customers reach experienced engineers directly. They can also concentrate knowledge in one or two people. An incident during illness, travel or a public holiday can outlast the technical fault. Password custody, signing keys, registrar access, facility authorization and billing approval may all depend on the same individuals.
Support capacity has an installed-versus-usable distinction of its own. Five engineers on a company page do not equal five people available during one incident. Planned projects, concurrent customer faults and facility travel reduce effective coverage. The relevant measures are monitored services per shift, time to acknowledge, time to engage a qualified engineer, escalation to carriers and the authority to make emergency changes.
Customers also need an out-of-band path. If the provider's domain, network and ticket system share the failed infrastructure, ordinary support channels can disappear together. The configured Google mail route suggests corporate email is external to AS153005, which is a modest positive separation signal. It does not show that the ticket system, phone service, status page or facility credentials are similarly independent.
Billing and contract failure: service can stop without a technical incident
Cloud capacity is a chain of recurring obligations. The provider may owe the facility for rack space and power, a carrier for transit, a software vendor for virtualisation or control-panel licences, a registrar for domains and suppliers for hardware. Customers owe the provider. A failure at any commercial link can become a service event.
The identity ambiguity raises the stakes. If an invoice bears THANH CLOUD while the ASN and bank beneficiary bear Phu Thanh Cloud, a customer needs to know which party owns the hardware and which can cure a default. If a reseller sits between the customer and facility, the reseller may not control physical access. If addresses are portable but the routers are held in a disputed rack, portability on paper may not restore them quickly.
No adverse event is established here. The point is structural: an SLA covering power and packet loss may say nothing about supplier termination, insolvency, licence expiry or disputed invoices. A resilient agreement should provide notice, grace periods, data access during a dispute, customer export rights and cooperation with an orderly transition. It should distinguish suspension for abuse from suspension for billing and preserve a way to retrieve data where lawful.
The company's recent route activation can be read positively as investment in an independent network identity. It can also increase fixed cost and operational responsibility. The evidence does not reveal the balance. Customers should judge contract durability from audited or confidential commercial evidence, not from the existence of an ASN.
Migration failure: backup is not the same as escape
A provider can restore its own platform and still leave a customer unable to leave it. Portability depends on image formats, data extracts, network configuration, keys, bandwidth and time. A virtual disk export without firewall rules, DNS, entity data or encryption keys may be incomplete. A large export over a congested link may take longer than the notice period.
ISO/IEC 19941 treats cloud interoperability and portability as distinct cross-cutting concerns. NIST's cloud use-case work frames the practical question directly: can a customer move away at low cost and disruption? That question is especially important when the seller has one visible prefix and no published multi-site design.
No public PT Cloud terms specify export formats, egress charges, snapshot access after termination, address portability for customers, deletion timing or transition assistance. There is no published maximum time to produce an export. Customers should assume none of these rights until they appear in the contract.
A credible exit test would move a representative workload to another provider while the original service is healthy. It would measure data volume, transfer rate, conversion work, DNS change, certificate reissue, firewall reconstruction and rollback. The customer should retain its own application code, configuration and independent backup where possible. Provider snapshots are useful for rapid rollback but can fail with the same account, storage system or contract.
This is not an argument against small clouds. It is an argument for reducing the difference between a normal migration and an emergency one. The less a customer knows about physical location and supplier dependencies, the more valuable a tested exit becomes.
Multi-site recovery is not visible
No reviewed public material claims or demonstrates that the service operates from two data centres. The active /23 does not encode location. A single prefix can be announced from one site, multiple sites or a remote router. The upstream ASN's US registration does not locate PT Cloud's servers. IP geolocation databases often repeat registration country or infer location from sparse measurements; they are not proof that a customer disk sits in Hanoi.
Multi-site also has several meanings. A provider can keep backups in a second building without running compute there. It can run spare compute without current data. It can stretch one storage cluster across two rooms that share a metro fibre path. It can operate active workloads in two cities but leave the account and identity systems in one site. Each design recovers from a different set of failures.
The customer needs recovery time and recovery point objectives for each service. NIST's contingency-planning guidance distinguishes alternate equipment, alternate processing and recovery at an alternate location. Google Cloud's recovery-testing guidance usefully emphasizes data integrity, recovery time, recovery point and restoration of the whole application stack. Those principles apply regardless of provider size.
A backup log is not enough. Evidence should show the last successful restore, what was restored, into which isolated environment, how long it took and what data interval was lost. If failover requires new servers, the hardware must exist. If it requires a route from a second site, the filtering and authorization must be ready. If it requires a particular engineer, that person must not be the only holder of credentials.
Until PT Cloud identifies a second operating site and supplies test results, customers should plan as though the service has one physical region and one visible network exit.
Data locality cannot be inferred from a Vietnamese ASN
The company is Vietnamese, its ASN is registered in Vietnam and third-party network directories label the prefix Vietnamese. None of those facts proves where customer data is stored. Registration country describes the resource holder. BGP describes reachability. A server can originate a Vietnamese-registered prefix from another country, and a Vietnamese control panel can provision storage elsewhere.
The legal context makes precision more important. Decree 53/2022 sets Vietnamese storage requirements for specified data and circumstances under the Cybersecurity Law. Decree 13/2023 regulates personal-data processing and applies to Vietnamese organisations as well as relevant foreign parties. The 2024 Law on Data, effective from July 2025, adds rules for data storage and special treatment for national, core and important data.
Those laws do not turn every server marketed in Vietnam into verified local storage. Applicability depends on the customer, data and service. Compliance also involves processing purpose, access, transfer, retention and security, not only the country of the disk. Customers should obtain legal advice for their own obligations.
The provider's contract should state the production and backup countries, named facilities or at least cities, subprocessors, cross-border support access, log location and conditions for moving data. It should explain whether snapshots and disaster-recovery copies remain in Vietnam. It should say which party acts as data controller or processor under the relevant arrangement and how deletion is evidenced.
PT Cloud's public footprint supplies none of that detail. Data sovereignty and locality therefore remain an important topic precisely because the answer is unresolved. A claim such as "Vietnam IP" or "Vietnam cloud" would not settle it. Facility and processing disclosures would.
The economics favour leasing, but the contract must reveal the dependency
A company formed in 2022 with a small address block is unlikely to reproduce the full economics of a national data-centre operator. That is an inference, not a finding about PT Cloud's exact architecture. For a small host, leasing rack space and buying transit can be rational: capital is directed to servers, software and support while the facility spreads generators, cooling and security across many tenants.
The model creates a layered bill. Customers pay the host; the host pays for hardware, rack units, kilowatts, cross-connects, transit, software and labour. Capacity is profitable only when utilization is high enough to cover those fixed costs, but resilience requires unused headroom, spare parts and duplicate systems. The temptation to sell too close to physical limits is built into hosting economics.
The newly active /23 may improve control over addresses and routing. Portable space can make it easier to change transit providers than provider-assigned addresses, assuming new sessions and filters are prepared. It may also support cleaner customer allocation and abuse handling. But the address resource does not reduce the cost of a second rack, second city or staffed night shift.
The key commercial question is what the low price, if any, omits. Is backup included or merely available? Does the service commitment exclude upstream incidents? Is support hands-on or remote? Is hardware replacement stocked? Are exports charged by bandwidth? Can the customer choose a data location? Without a current catalogue and terms, none of these can be answered publicly.
Customers do not need the provider to own every dependency. They need the provider to name the dependency, contract for it responsibly and explain the recovery boundary. Outsourcing power to a data-centre operator can strengthen resilience. Hiding the operator prevents the customer from evaluating concentration.
Who is affected when the system fails
There is no verified public customer list, so it would be wrong to name organisations as dependent on PT Cloud. The affected population can instead be described by service type.
If the company sells VPS or shared hosting, small businesses, web shops, software teams and agencies can lose sites, applications, mail or databases. A route withdrawal makes all workloads on the /23 unreachable at once. A storage fault can corrupt a smaller set but create longer recovery. A control-system outage may leave running applications online while customers cannot reboot, resize or restore them.
If it sells bare metal, each customer may depend on one chassis and the local spare queue. If it resells another platform, the end customer depends on both companies and may not know which support desk can act. If it supplies addresses or transit, downstream networks can inherit the single visible upstream path. If it supplies managed services, customer recovery depends on staff knowledge and credentials in addition to infrastructure.
The incident clock also varies. Cached web content can mask an origin failure. Existing virtual machines can survive a billing-panel outage. A database corruption can continue serving wrong data while every monitor remains green. A mass route withdrawal is immediate. An exhausted spare pool becomes visible only when the next machine fails.
This is why a single uptime number is inadequate. Customers need separate commitments for network reachability, compute, storage durability, backup restoration, control functions and support response. They also need to know which exclusions pass landlord and carrier risk back to them.
Evidence that would change the assessment
The current assessment can improve quickly because the missing evidence is specific.
Identity would be resolved by a current business certificate and contract showing the relationship between THANH CLOUD COMPANY LIMITED, Phu Thanh Cloud Company Limited and PT Cloud. The contract, invoice and bank beneficiary should identify the same responsible party or explain each role.
The service would be defined by a current catalogue: VPS, bare metal, hosting, managed service, transit or another product. It should state resource guarantees, virtualization and storage architecture, customer isolation, provisioning method, metering and supported operating systems. A public website would help, but contractual specifications matter more.
The physical estate would be established by named facilities, rack ownership or lease, city, power allocation and site-level certifications. A customer under confidentiality can review colocation invoices, rack diagrams, access lists and cross-connect orders without exposing sensitive security details.
Network resilience would be established by two current upstreams, their ASNs, port sizes and physically diverse delivery. Looking-glass or route-monitoring evidence should show the prefix through both paths. IPv6 allocation and announcement would improve protocol coverage. Attack-mitigation ownership and capacity should be stated separately from ordinary transit.
Recovery would be established by dated restore and failover results. The evidence should include recovery point, recovery time, data-integrity checks, route changes, control-system availability and the people involved. A second site should be described by workload state, not merely by the word "backup".
Hardware resilience would be established by an inventory of active nodes, reserved capacity, replication, spare parts and replacement targets. Support resilience would be established by shift coverage, acknowledgement and escalation times, out-of-band communications and at least two credential holders for critical systems.
Portability would be established by export formats, transfer rates, fees, notice periods, deletion evidence and a completed trial migration. Data locality would be established by production and backup locations, subprocessors and access arrangements.
These are ordinary facts for operating a hosting service. None requires disclosing customer names, exact rack coordinates, passwords or exploitable topology. They convert a cloud promise into a service that can be evaluated.
A live route deserves attention, not a resilience premium
AS153005 changed the picture in late June 2026. The network is no longer merely an allocated but invisible ASN in current telemetry. It originates a validly authorized /23 and has a visible path to the global Internet. Together with the matching APNIC and company information, that is credible evidence of recent network activity.
The change is too new and too narrow to support a strong operating conclusion. The route has one observed upstream, no observed IPv6, no public exchange or facility disclosure and no visible service catalogue at the corporate domain. The public evidence cannot connect the addresses to customer machines, identify the rack or show one successful restore. It cannot prove that the headline name and the APNIC legal name are contractually identical.
The sensible classification is therefore weak, not negative. There is something real to verify: a company, an ASN, a portable block, current routing and maintained email-domain configuration. A negative assessment would ignore that evidence. A medium or strong assessment would convert routing into cloud capacity and assume the missing physical layers.
For customers, the immediate task is straightforward. Verify the legal counterparty, product, facility, two route paths, available failure reserve, support escalation, tested recovery and export process before placing an important workload. Until those facts are supplied, the service should be treated as a single-region, single-visible-upstream dependency with unknown recovery characteristics.
Cloud language makes capacity feel detached from place. AS153005 shows the opposite. Behind the account there must still be a rack, a power contract, a route, hardware that someone can replace and people authorized to act. For THANH CLOUD COMPANY LIMITED, those dependencies are not disproved. They are simply not yet visible enough to price as resilience.