CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED sells hosted capacity that still depends on racks, transit and repair windows

Summary

• VNNIC's public internet-resource member list includes Cong ty TNHH Truyen thong va Cong nghe Cloud Data under EDIGI-VN, dated 22 November 2023. APNIC's RDAP record for AS151872 identifies EDIGI-VN in Vietnam, with active status and a 16 November 2023 registration event, while RIPEstat's whois view gives the English name CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED and a Ho Chi Minh City address.
• AS151872 is publicly reachable. RIPEstat's AS overview showed the AS announced on 12 July 2026, and the routing-status view showed 3 IPv4 prefixes, 4 IPv6 prefixes, 1,024 IPv4 addresses, four IPv6 /48s, visibility to all 325 RIS IPv4 peers and all 322 RIS IPv6 peers, and one observed neighbour.
• The current prefix set is operationally mixed. RIPEstat's announced-prefixes view listed 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, 2001:df3:e4c0::/48, 2001:df3:e8c0::/48, 2401:9760::/48 and 2401:9920::/48. APNIC records attach several of those prefixes to other Vietnamese labels, not directly to EDIGI-VN.
• The company-named IPv4 block is not the current AS151872 proof. APNIC's 203.145.46.0/23 RDAP record names EDIGI-VN and CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, but RIPEstat's prefix overview showed that block originated by AS150862, MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED, and the RPKI check for AS150862 was valid.
• The public evidence grade is Medium-Weak. The route origin is alive and measurable, but the public record does not prove owned data-centre space, rack count, spare hardware, multi-site service, transit diversity beyond the visible FPT path, customer migration rights or the support authority that would decide repair windows.

The useful fact is AS151872, not a branded cloud map

The public record starts with a small but concrete number-resource identity. VNNIC's internet-resource member list includes Cong ty TNHH Truyen thong va Cong nghe Cloud Data under EDIGI-VN with a 22 November 2023 entry. APNIC's AS151872 RDAP record gives the handle AS151872, the name EDIGI-VN, country VN and active status. RIPEstat's whois record for AS151872 expands that into CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED and lists No. 338/22 Thoai Ngoc Hau, Phu Thanh Ward, Tan Phu District, Ho Chi Minh City, Vietnam.

That is enough to identify the company behind a routed autonomous-system record. It is not enough to identify a cloud platform. There is no public facility list in the AS record, no cabinet count, no named data hall, no published recovery region, no maintenance calendar and no customer-facing service-level promise attached to the number. For a customer buying hosted capacity, the difference matters. A registered AS can describe who originates routes. It does not say where servers sit, which power distribution units feed them, who has remote-hands access, how many spare disks are on site, or whether a customer can move data out under pressure.

The next layer of evidence is current routing. RIPEstat's AS overview marked AS151872 as announced on 12 July 2026. Its routing-status view showed the AS visible to all 325 IPv4 RIS peers and all 322 IPv6 RIS peers at the 11 July 2026 16:00 UTC query time. It also showed one observed neighbour. That is a stronger signal than a stale company listing. It says the network is present in the global routing table. But it still does not say what product sits behind the route.

This is why the company should be assessed as a hosted-capacity dependency rather than as a proven data-centre operator. A buyer can monitor AS151872. A buyer can test routes to its prefixes. A buyer can ask for route-origin authorisation, support escalation and export terms. What the buyer cannot do is turn the public AS record into a claim that CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED owns a particular building, controls a specific data hall or has spare capacity in a second site.

The active prefix set is real, but it is not simple ownership proof

RIPEstat's announced-prefixes data listed seven current resources for AS151872 in the late-June to 12 July 2026 window: 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, 2001:df3:e4c0::/48, 2001:df3:e8c0::/48, 2401:9760::/48 and 2401:9920::/48. BGP.Tools' AS151872 page displayed the same high-level shape: three IPv4 prefixes, four IPv6 prefixes, one upstream and one peer visible to that service. IPIP.NET's AS151872 page similarly showed three IPv4 prefixes, four IPv6 prefixes and 1,024 IPv4 addresses.

The labels attached to the active prefixes make the operating story more complicated. APNIC's 157.66.198.0/23 RDAP record identifies DAZITT-VN and DAZI MARCOM CO., LTD, not EDIGI-VN. APNIC's 160.30.10.0/23 RDAP record identifies IPXO-VN and IPXO Technology Company Limited. APNIC's 2001:df3:e4c0::/48 identifies GENLOGIN-VN, 2001:df3:e8c0::/48 identifies CLEMAX-VN, 2401:9760::/48 identifies THCLOUD-VN, and 2401:9920::/48 returns DAZITT-VN again.

Those labels do not prove a resale arrangement, a customer relationship or a facility relationship. They show only that the active AS151872 route set includes prefixes whose public registry names belong to several Vietnamese resource labels. In cloud and hosting markets, that pattern can appear when a provider originates delegated resources, when customers or affiliates use a provider's routing platform, when address holders use hosted BGP, or when number-resource administration and service operation sit in different hands. Public routing cannot decide which explanation applies here.

The procurement implication is plain: do not treat the routed address count as owned server capacity. The 1,024 IPv4 addresses and four IPv6 /48s indicate addressable network surface, not usable compute, storage or support depth. A buyer should ask which prefixes would be assigned to its service, whose name appears in the route and registry records, who can authorise route changes, and whether the customer can keep, renumber or replace those addresses during migration.

The EDIGI-named block is the biggest caution

The strongest reason to slow down is 203.145.46.0/23. APNIC's RDAP record for 203.145.46.0/23 names EDIGI-VN, describes CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, and gives the same Ho Chi Minh City address used in the AS151872 whois record. A quick reading would call that the company's primary IPv4 block. The current route table says something narrower.

RIPEstat's prefix overview for 203.145.46.0/23 showed the block announced by AS150862, not AS151872. RIPEstat's AS150862 overview identifies that origin as MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED. The RPKI view also supports the current origin: 203.145.46.0/23 with AS150862 returned valid, while the same prefix with AS151872 returned invalid_asn.

That does not mean the EDIGI-named block is misused, abandoned or unavailable. It means the current public route origin is not the company AS that the rest of the article is testing. The block may be served by another Vietnamese operator, moved for operational reasons, used under a customer arrangement, or no longer relevant to a buyer's hosted product. The public evidence cannot decide that. It can only warn the buyer not to assume that an EDIGI registry label and an AS151872 service path are the same thing.

For continuity planning, this distinction is crucial. If a customer receives addresses from 203.145.46.0/23, the incident path may not be the same as the path for 157.66.198.0/23 or 160.30.10.0/24 under AS151872. If the customer monitors only AS151872, it may miss the EDIGI-labelled block. If it monitors only the EDIGI-labelled block, it may miss the active AS151872 service. A serious service review has to map the address pool, origin AS, route authorisation, support owner and migration terms for each customer-facing prefix.

One visible neighbour turns transit into a test, not a slogan

The public neighbour evidence points to FPT. RIPEstat's ASN-neighbours view showed one observed neighbour for AS151872, AS18403. RIPEstat's AS18403 overview identifies AS18403 as FPT-VN - FPT Telecom Company, and the AS18403 whois record gives FPT Telecom Company in Vietnam. BGP.Tools also displays AS18403 as the upstream and peer visible for AS151872.

That is a useful operating fact, but it should not be stretched. A public route collector can show a visible neighbour. It cannot show every private cross-connect, backup service, commercial contract or route policy. AS151872 may have internal arrangements that are not exposed in this view. It may also have a very thin public edge. The practical buyer assumption is neither "there is no redundancy" nor "FPT makes everything resilient." The practical assumption is "the visible public route path starts with FPT, so the provider should explain what happens when that path is degraded or withdrawn."

The looking-glass data for 157.66.198.0/23 showed public collector paths ending in AS151872, commonly through AS18403 after upstreams such as Telstra, PCCW, Lumen or other global carriers in the observed paths. That is normal global reachability. It is not proof that AS151872 buys directly from each remote carrier. The customer-facing question remains local: what path carries the packets out of the facility, what equipment terminates it, and who repairs it?

For a hosted service, transit diversity is meaningful only if it is separated at the right layers. Two upstream names do not help if they enter the same rack through the same router, depend on the same power feed, share the same building meet-me room, or require the same support queue to change route policy. Conversely, a single public upstream can be acceptable for a lower-risk workload if the service is explicitly priced and documented as single-homed and if the customer has an exit path. The risk is not singleness by itself. The risk is a customer believing it bought diversity when the public evidence shows only one visible neighbour.

RPKI is split between valid and unknown

Route-origin validation adds another layer of mixed evidence. RIPEstat's RPKI checks returned valid for 160.30.10.0/24 with AS151872, valid for 160.30.11.0/24 with AS151872, valid for 2001:df3:e4c0::/48, valid for 2001:df3:e8c0::/48, and valid for 2401:9760::/48. It returned unknown for 157.66.198.0/23 and unknown for 2401:9920::/48.

Unknown is not invalid. It means the public validation view did not find a positive route-origin authorisation covering that origin and prefix at the time checked. For many small networks, that status is still common. For a customer buying critical hosted capacity, it is still a meaningful question. If upstreams or peers enforce strict route filtering, unknown status can change failure behaviour. If a route leak or hijack occurs, authorised origins make filtering and diagnosis easier.

The relevant standards do not certify this company. They explain what to ask. RFC 6811 defines BGP prefix-origin validation. RFC 7454 describes operational practices for BGP filtering and routing security. MANRS frames route filtering, anti-spoofing and coordination norms. APNIC's resource-certification page explains RPKI in the APNIC region.

The customer should ask for a route-authentication statement by prefix. Which customer-facing prefixes have valid ROAs? Which are intentionally left unknown? Who can create or change the authorisation? How quickly can the provider repair an invalid route-origin state? A small hosting provider can still be reliable if these answers are clear. A provider with live routes and unclear authorisation can leave customers exposed during upstream policy changes.

A Ho Chi Minh address is not a rack location

The company address appears consistently in public records. RIPEstat whois lists No. 338/22 Thoai Ngoc Hau, Phu Thanh Ward, Tan Phu District, Ho Chi Minh City, Vietnam for AS151872. APNIC's EDIGI-named 203.145.46.0/23 record gives the same address. MaSoThue's tax-code mirror also lists the Vietnamese company name, tax code 0318010419, the English name and the Thoai Ngoc Hau address, while reporting a negative status for the registered address. Because that page is a business-information mirror rather than an official network registry, its status field should be treated as a signal to verify, not as a complete operating judgement.

Even without the negative status signal, the address should not be read as a data-centre map. A registered office, administrative contact, tax address, route contact or commercial address can be separate from the racks that hold customer workloads. A small cloud or hosting provider may colocate equipment in a third-party facility, rent bare-metal nodes from another provider, originate customer or partner prefixes, or manage servers remotely. None of those arrangements is automatically bad. Each one changes the repair path.

If a customer is buying a Vietnam-local service, it should ask where each layer sits: production compute, storage, backup, monitoring, support records, billing records, management access and export staging. "Ho Chi Minh City" as an address is not enough. The customer needs to know whether production is in Ho Chi Minh City, another Vietnamese city, a leased rack in a carrier facility, a virtualised environment on another provider, or a mixture.

The point is not to demand sensitive floor plans. The point is to locate responsibility. If a server fails, who can enter the rack? If a switch fails, who owns the spare? If power maintenance is scheduled, who receives notice? If a route needs to move, who can change BGP? The public company address does not answer those questions, and it should not be asked to do more than it can.

Hosted capacity is a chain of borrowed and operated parts

The current AS151872 evidence looks like a small hosted-capacity chain, not a self-contained hyperscale cloud. That distinction matters for expectations. A small network can provide good service when it knows exactly which parts it owns, which parts it rents, which parts are customer-controlled and which parts sit with upstream providers. It becomes fragile when those boundaries are hidden.

The address-space evidence already shows multiple labels. DAZITT-VN, IPXO-VN, GENLOGIN-VN, CLEMAX-VN and THCLOUD-VN appear on current AS151872-originated prefixes. EDIGI-VN appears on 203.145.46.0/23, but that block is currently originated by AS150862. The routing evidence shows AS18403/FPT as the public neighbour for AS151872. The company-domain clue also adds uncertainty: the AS contacts use edigi.vn email addresses, but a direct request to https://edigi.vn returned a Cloudflare 521 response during this review, which usually indicates that Cloudflare could not reach the origin server. That observation does not prove customer services are down, but it weakens confidence in public customer-facing documentation.

For hosting economics, the question is how the company turns these dependencies into usable capacity. Does it hold its own servers in leased racks? Does it resell another provider's VPS or bare-metal inventory? Does it originate customer prefixes for third-party systems? Does it provide network services to other Vietnamese software or cloud labels? Public data cannot settle those questions. It does show that any customer should avoid the word "cloud" as a shortcut.

Installed capacity is what exists on paper: addresses, AS number, upstream reachability, racks or contracts. Usable capacity is what can actually carry customer workloads after power, cooling, route filtering, failed hardware, support response and spare-stock constraints are considered. Recoverable capacity is what can be restored within the customer's deadline. The public AS tells us the first layer exists. It does not tell us the second or third.

Support labour is a physical dependency

In a small hosting environment, support labour is part of the infrastructure. If a customer cannot reach the person or team that can change a route, replace a disk, restart a console, unlock billing, retrieve backups or coordinate with the upstream, the service can fail even while the route stays visible. AS151872's current route visibility is therefore only the start of the support question.

The public records give administrative and technical contact handles through APNIC and RIPEstat, but they do not publish a customer escalation map. They do not say whether after-hours support is internal, outsourced, handled by a facility, handled by the upstream or handled by another hosting operator. They do not show whether the same support path covers the active AS151872 prefixes and the EDIGI-named 203.145.46.0/23 block now routed by AS150862. They do not show whether billing status can suspend a server before the customer exports its data.

For buyers, the right evidence is practical. Open a support ticket that asks for a route-origin statement by prefix. Ask how to reach emergency support if the customer portal is unavailable. Ask who is authorised to contact FPT or another upstream on the customer's behalf. Ask whether the customer can receive facility-maintenance notices. Ask for the maximum time to replace common hardware, restore a virtual machine and export a full backup during a degraded state.

The answer may be modest, and that is fine if the price and workload match it. A low-cost VPS service does not need to pretend it is a multi-region enterprise cloud. The danger is mismatched dependency. If the customer's application, reseller service or public-service workload depends on rapid repair, the customer needs written escalation and tested recovery, not only an invoice and an IP address.

Data locality has to be specified one component at a time

The assignment of VN in APNIC and VNNIC records supports a Vietnamese number-resource identity. It does not prove where customer data is stored. For data sovereignty and locality, the customer needs a component-level answer. Production compute can be in one place, storage in another, backup in another, support access from another and billing records in another. A route that originates in Vietnam does not by itself decide any of those locations.

Vietnam's legal and regulatory context makes the distinction important. Customers handling personal information, regulated data, state-sector workloads, payment data or sensitive business records need to know which data can move, who can access it and what happens during termination. The public AS151872 record answers none of that. The company website availability check answers none of that. The EDIGI-labelled 203.145.46.0/23 mismatch makes the question more urgent because it shows that registry names and route origins can sit apart.

The right request is a locality schedule. It should state where production disks sit, where backups sit, where logs and monitoring data sit, where support tickets sit, where account and billing records sit, and where administrators can connect from. It should also state whether those locations are contractual guarantees, normal operating practice or provider discretion. A customer that needs Vietnam-only data handling should not rely on a country code in an AS record.

Locality also affects recovery. A provider may keep backups in another site for resilience, but the customer must know whether those backups are usable during a local outage and whether restoring them changes jurisdiction, IP addresses, latency or compliance evidence. A provider may use another Vietnamese AS or facility to support failover, but the customer must know who controls that failover. Locality is not a label. It is a set of operational facts.

Migration is the honest test of dependence

The clearest way to test a hosted service is to leave it once, deliberately and while there is no emergency. That is especially true where public evidence shows mixed prefix labels and a separate current origin for the company-named block. A customer that cannot export, rebuild and renumber a small workload during calm conditions should assume a crisis migration will be slow.

For CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, the migration test should include addresses, not only data. If the workload uses 157.66.198.0/23, 160.30.10.0/24 or 160.30.11.0/24 space originated by AS151872, can the customer move those addresses? If the workload uses 203.145.46.0/23 space registered to EDIGI-VN but originated by AS150862, who approves changes? If the customer uses IPv6 /48 space under AS151872, are route-origin records, firewall rules and partner allow-lists documented?

Data export should be just as concrete. Can the customer export disk images, entity data, databases, snapshots, DNS settings, firewall rules, access logs and billing records without manual intervention? Can exports be run if the control panel is degraded? Are exports throttled? How long are backups retained after cancellation? Who can authorise emergency export if the usual account holder is unavailable?

The answer determines the economic risk of the hosting relationship. Cheap hosted capacity can become expensive if it creates captive dependencies around provider-assigned IPs, undocumented backups and slow support. A smaller provider can still be a good choice if the customer can move away cleanly. Portability is not a lack of loyalty. It is the customer's disaster-recovery proof.

Who feels the failure

The visible customer of AS151872 may be a Vietnamese application operator, reseller, small business, software service, agency, systems integrator or another network using hosted routing. The end user may never see the name CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED. They will notice slower applications, unreachable login pages, bounced mail, blocked API calls, failed backups or failed address allow-lists.

The failure paths are layered. A public route problem can withdraw reachability from all current AS151872 prefixes. A local fibre or upstream fault can degrade reachability through AS18403. A rack power issue can leave BGP visible while servers are down. A disk or storage-pool failure can make the route look healthy while data is unavailable. A support bottleneck can extend an incident after the technical cause is known. A billing or account-status problem can block recovery even when the infrastructure is repairable. A mismatch between registry name, route origin and customer contract can slow the first hour of diagnosis.

The EDIGI-named 203.145.46.0/23 block adds a specific downstream risk. If customers or partners have recorded that block as "EDIGI" because of APNIC data, but the current route origin is AS150862, monitoring and incident contact lists may point in different directions. The customer should not wait until an outage to decide which contact owns which prefix.

The public evidence is not a reason to reject the provider outright. It is a reason to map the service before depending on it. The network exists. It is currently visible. Several prefixes have valid route-origin authorisation. The unresolved questions are physical and contractual: where the workload sits, who repairs it, how many paths exist, what happens to the EDIGI-named block, and how a customer exits.

How to verify before relying on the service

The first verification step is identity. Ask the provider to confirm whether the customer service is delivered by AS151872, by 203.145.46.0/23 under AS150862, by another routed block, by private addressing or by a mix. Compare the answer with APNIC's AS151872 and 203.145.46.0/23 records, RIPEstat's AS151872 routing status, and RIPEstat's 203.145.46.0/23 prefix overview.

The second verification step is topology. Ask for the production facility type, recovery facility type, public transit path, private-connectivity path if any, upstream escalation path and maintenance-notice process. The provider does not need to disclose sensitive rack coordinates to answer this. It can state whether the customer is single-site, multi-site, single-upstream, dual-upstream, backed up in another location or dependent on a third-party colocation provider.

The third step is routing security. Request a prefix-by-prefix ROA statement and compare it with RIPEstat's RPKI views. Valid entries for 160.30.10.0/24, 160.30.11.0/24 and several IPv6 /48s are positive. Unknown entries for 157.66.198.0/23 and 2401:9920::/48 should be explained. The valid AS150862 status for 203.145.46.0/23 should also be explained if the customer expects EDIGI-branded service.

The fourth step is a recovery drill. Restore one representative workload from backup, move it to another environment, update DNS or partner allow-lists, confirm logs, verify data integrity and record elapsed time. Include support escalation in the test. If the support path cannot execute a small planned move, it is unlikely to execute a large emergency move cleanly.

The provider boundary needs a prefix matrix

The most useful document a customer could request is a prefix matrix. It does not need to reveal sensitive internal diagrams. It should simply connect each customer-facing network block to its registry label, route origin, route-authorisation state, upstream path, support owner and customer impact. For AS151872, that matrix would start with 157.66.198.0/23, 160.30.10.0/24, 160.30.11.0/24, the four visible IPv6 /48s, and the EDIGI-named 203.145.46.0/23 block that is currently outside AS151872's origin set.

The matrix should answer a basic question for every prefix: if this route changes, who can fix it? The answer may be CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED. It may be a customer that supplied its own address space. It may be an upstream or another Vietnamese operator. It may be a combination. Public routing sees the result, not the authority chain. Customers need the authority chain because route repair is often a permissions problem before it is a technical problem.

The same matrix should separate production use from reserved or administrative use. A prefix can appear in the global route table but carry management interfaces, test hosts, customer NAT, mail, DNS, backup endpoints, monitoring probes or no paid customer workload at all. If a customer is sold capacity on a public address block, it should ask whether that block is dedicated, shared, filtered, portable or replaceable. It should also ask what happens if the registry label, route origin or RPKI state changes during the contract.

The mixed AS151872 evidence makes this especially important. The active AS contains resources whose public registry names belong to several Vietnamese labels, while the EDIGI-named IPv4 block has another current origin. That is not automatically a warning sign; it may be normal operational delegation. But normal delegation still needs documentation. Without it, a customer can lose hours during an outage deciding whether to call the hosting account contact, the AS151872 route contact, the AS150862 operator, the address holder, or the upstream.

The buyer should also ask whether any customer-facing addresses are protected by provider anti-abuse filters, geofencing, DDoS mitigation, outbound-mail limits or special route policy. Those controls can be valuable, but they can also complicate migration and incident response. A prefix matrix turns those hidden constraints into operating facts the customer can test.

Power, spares and maintenance are invisible from BGP

BGP makes routes visible; it does not make the physical service visible. AS151872 can be fully reachable from route collectors while a single rack, switch, storage node or power circuit is the actual point of customer failure. The routing table does not expose whether servers are in owned rooms, leased cabinets, third-party colocation, rented bare-metal inventory or another provider's virtualised estate. It also does not expose whether common spare parts are held on site.

That matters because hosting failures often start with ordinary physical constraints. A server can lose a disk. A top-of-rack switch can fail. A power distribution unit can trip. A UPS maintenance window can remove redundancy. A facility can require remote-hands scheduling. A replacement part can be delayed. The public AS may remain announced throughout all of that. From the outside, the route looks healthy while the customer's application is unavailable.

For CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED, the public record gives no rack count, data-hall name, power design or hardware-stock evidence. The correct conclusion is not that those elements are absent. It is that customers must ask for them directly. At minimum, a production customer should know whether its workload is single-rack or multi-rack, whether storage is local or replicated, whether backup is off-rack and off-site, and whether maintenance can affect all customer-facing services at once.

The support boundary intersects with the physical boundary. If the company leases space in another facility, the facility may control access and remote hands. If it rents servers from another provider, the other provider may control hardware replacement. If it uses an upstream for BGP and another party for colocation, a route fault and a power fault may require entirely different escalation paths. A good provider can manage those dependencies, but the customer should not discover them only after failure.

Customers should request evidence in practical form: sample maintenance notices, a description of redundant power per customer service tier, replacement targets for common hardware, the backup-retention location, and a recent restore exercise. These are not grand enterprise demands. They are the minimum facts needed to decide whether the service is appropriate for a workload that cannot tolerate a long repair window.

Billing and account state can become an infrastructure outage

The article title mentions racks, transit and repair windows, but account state belongs in the same list. A hosted service can be technically healthy and still unavailable to the customer because a bill is disputed, an administrator left the company, a password-reset path fails, an abuse ticket locks the account, or a service suspension blocks access to backups. Small hosting providers can be especially exposed if commercial and technical authority are concentrated in the same small team.

Public evidence does not disclose how CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED handles suspension, account recovery, deletion, abuse review or emergency export. That absence should not be filled with assumptions. A buyer should ask what happens if the customer misses a payment by accident, if a fraud review is triggered, if a phishing complaint is filed against a compromised server, or if the named account owner is unavailable during an incident. The answer should state whether the customer can still retrieve backups and whether suspension affects DNS, route announcements, console access and support.

The EDIGI-named block adds another administrative question. If 203.145.46.0/23 appears in customer documentation because of the APNIC record, but the current route origin is AS150862, the customer needs to know which entity controls commercial status for addresses on that block. If a service is suspended, who has the power to restore route visibility? If the customer leaves, who coordinates renumbering or cleanup? If there is an abuse complaint, who receives it and who can close it?

These questions are not signs of mistrust. They are part of resilience. A provider that can explain billing grace periods, abuse escalation, emergency contacts, account-owner transfer and data-export rights gives customers a way to recover from administrative faults. A provider that treats those details as back-office trivia leaves customers exposed to outages that never appear in a route collector.

The safest customer posture is to document an emergency commercial path alongside the technical path. The technical path says who can restore packets, servers and backups. The commercial path says who can prevent a paperwork issue from blocking restoration. Both should be known before the service is important.

What would upgrade the evidence

The evidence would become materially stronger if the company or a customer-facing product page connected the public routing facts to the service being sold. The most valuable upgrade would be a plain service map: AS151872 role, 203.145.46.0/23 role, active customer prefixes, upstreams, production location type, recovery location type, support owner, backup location and export method. It would not need to publish cabinet numbers or sensitive security details. It would need to remove ambiguity about which public records still matter to customers.

A second upgrade would be current route-control evidence. That could include a published or customer-provided ROA plan for every active prefix, an explanation for the unknown RPKI status on 157.66.198.0/23 and 2401:9920::/48, and an explanation for the valid AS150862 origin on the EDIGI-named 203.145.46.0/23 block. The aim is not cosmetic routing hygiene. The aim is to make route changes diagnosable during an incident.

A third upgrade would be an interconnection or facility profile. The PeeringDB API query for AS151872 returned no public network profile during this review. PeeringDB absence is not a negative verdict; many small providers and customer networks have no public profile. But a profile or equivalent customer-facing document could state exchange points, facilities, traffic policy and support contacts. That would help customers distinguish public transit from private or facility-level resilience.

A fourth upgrade would be recovery proof. A provider can claim that backups exist, but the stronger evidence is a restore report that states what was restored, where it was restored, how long it took, what dependencies failed and what the customer had to do. For a hosted service with mixed prefix labels, that report should include address changes, DNS updates, firewall changes and allow-list updates. The customer needs to know whether recovery is only a server operation or a full network-and-data operation.

Finally, the public web footprint could be clearer. The edigi.vn domain being unavailable through a Cloudflare 521 response at check time is only a transient signal, but it leaves customers without an easy place to read current service terms, status, support channels or product boundaries. A stable public support and status page would not prove resilience by itself. It would make the dependency easier to operate.

Evidence grade

The evidence grade is Medium-Weak. It is stronger than a pure shell record because AS151872 is currently visible, has three IPv4 prefixes, four IPv6 prefixes and measurable global reachability. It also has several valid route-origin records. VNNIC and APNIC identify the EDIGI-VN resource label and the company, and public route collectors consistently show AS151872 as active.

The weak side is equally important. Public evidence does not identify owned facilities, leased racks, rack count, power design, spare hardware, support coverage, customer contracts, product pages, recovery objectives or data-export terms. PeeringDB's API query for AS151872 returned no public network profile, so it does not provide facilities, exchange points or peering policy. The active route set includes prefixes with other registry labels. The EDIGI-named 203.145.46.0/23 block is currently originated by AS150862, not AS151872. The public web domain tied to contact email was not serving a normal public site at the time checked.

The conclusion is narrow: CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED has a measurable Vietnamese routing footprint, but public research does not prove a self-contained cloud platform. A customer should treat the service as a dependency to verify by prefix, rack, route, support owner, backup location and exit path before placing important workloads on it.