Summary
- Tan VPS Company Limited is a Vietnamese company registered in April 2024 and listed by VNNIC as an Internet number-resource member from May 2024. APNIC records associate it with AS151932 and the portable IPv4 block
157.66.222.0/23, a pool of 512 addresses. - The block was publicly originated by AS151932 from May 2024 into March 2025. At the 12 July 2026 observation point, AS151932 announced no prefixes, while
157.66.222.0/23remained visible through AS150895, registered to EZ Technology Company Limited. A valid route-origin authorisation covered that origin. This proves a reachable and authorised routing arrangement, but not a data-centre location, server owner, customer contract or support obligation. - No cited public material identifies Tan VPS’s rack location, facility operator, power design, host count, storage architecture, spare inventory, backup regime, service catalogue, support hours or migration terms. Its registered office in Quy Nhon is not evidence that customer machines are installed there.
- Customers therefore need to evaluate the whole dependency chain: the facility and its power, the physical and virtual hosts, the current route origin and upstream path, the people allowed to repair equipment, the billing relationship, independent backups and a tested exit route.
- The operating-evidence assessment is Weak. The corporate registration, address allocation and routing history are concrete, but the public record does not establish the amount, location, ownership or recoverability of customer-facing hosted capacity.
A reachable address block is the beginning of the inquiry
Tan VPS has more public infrastructure evidence than a company whose name appears only in a business register. It also has less evidence than the word “VPS” in its name may encourage a buyer to assume.
The VNNIC list of Internet address members identifies Công ty TNHH Tân VPS under the network name TANTHOIVPS-VN and dates its allocation membership to 8 May 2024. The APNIC record for AS151932 associates the same network name with Tan VPS Company Limited and gives a Quy Nhon address. The APNIC address record names the company on 157.66.222.0 - 157.66.223.255, marks the range ALLOCATED PORTABLE, and records its last modification on 6 May 2024.
Those are meaningful facts. A /23 contains 512 IPv4 addresses, including network and broadcast addresses where conventional subnetting rules apply. Portable status means the address resource is not simply a small slice of a provider’s aggregate recorded under the provider’s name. An ASN gives a network an identity for exchanging reachability information through the Border Gateway Protocol. The records tie Tan VPS to scarce and operationally useful Internet number resources.
They do not reveal a CPU, a disk or a rack. The ASN has no built-in measure of bandwidth. The /23 does not disclose how many addresses are assigned to customers, held in reserve, used for infrastructure, filtered, idle or unavailable. Neither record says whether Tan VPS owns servers, leases dedicated machines, buys virtual instances, rents a cabinet, resells another host’s inventory or combines several of those models.
The corporate evidence has the same limit. Two Vietnamese company-information services, Infocom and Tra Cuu Nhanh, identify tax number 4101640518, an establishment date of 17 April 2024, Nguyen Van Tan as legal representative, and an active registration at 04 Tran Huy Lieu in Quy Nhon. They list data processing and related rental among the registered business lines. Registration supports the company’s legal existence and a business scope compatible with hosting. It is not an inspection report on a live service.
That distinction sets the standard for everything that follows. Tan VPS can be described as the registered company associated with these number resources. The block can be described as currently reachable. Any claim about sellable VPS capacity, machine ownership, facility quality, customer count or service resilience needs a separate link in the evidence chain.
The route changed even though the address holder did not
The most revealing public fact is not that Tan VPS once announced its block. It is that the origin changed.
The RIPEstat routing history for AS151932 shows 157.66.222.0/23 originated by that ASN from late May 2024 into March 2025. The more detailed history for the prefix shows three recent origin phases. AS150880 appeared briefly from 17 May 2024. AS151932 became broadly visible from 29 May 2024 and continued into March 2025. AS150895 then appeared from 13 March 2025 and remained the observed origin through 12 July 2026. The history contains a short overlap, rather than a perfectly clean midnight handover.
At the current observation point, the RIPEstat overview for AS151932 marked the ASN as not announced, and its announced-prefixes response returned an empty list. By contrast, the prefix overview marked the /23 as announced and identified AS150895, EZ Technology Company Limited, as the origin.
This is not evidence that the address allocation moved away from Tan VPS. Registration and routing answer different questions. The APNIC data identifies the resource holder; BGP identifies the ASN currently telling the Internet that it can deliver traffic to the block. A holder may authorise another network to originate its addresses. It may do so because the other network supplies transit, managed routing, colocation connectivity, denial-of-service protection, aggregation or a broader hosting platform.
The current origin is not merely an accidental path seen by one website. A RIPEstat route-origin validation response reports a valid Route Origin Authorisation for AS150895 with maximum length /23. Asking the same validator to test AS151932 against the block returns invalid_asn, because the active authorisation names AS150895. VNNIC’s 2024 Internet resources report explains the function: a ROA cryptographically identifies which ASN is authorised to announce a prefix.
Authorised does not mean fully explained. A ROA cannot say who owns the routers, who pays the transit invoice, where the servers are, whether the arrangement is wholesale or retail, or which company owes a customer a response during an outage. It reduces one class of routing ambiguity while leaving the commercial and physical boundary open.
For a buyer, the changed origin is therefore neither a scandal nor a triviality. It is a dependency that should be named. A current service map should say whether Tan VPS still controls address assignment, whether AS150895 provides only route origination or a larger infrastructure bundle, and what happens to customer addresses if the underlying agreement ends.
An origin ASN is not the same thing as an upstream, a facility or a host
Internet routing compresses a complicated supply chain into a short sequence of numbers. It is useful precisely because it is abstract. The abstraction can also tempt readers to give it more physical meaning than it has.
RFC 4271 defines BGP as a system for exchanging network reachability information between autonomous systems. The protocol carries routes and policy attributes. It does not carry rack leases, power diagrams, server serial numbers or support contracts. A visible origin tells other networks where a route ends at the autonomous-system layer. It does not prove that customer compute is owned by that origin operator or even installed in a building the origin operator controls.
The RIPEstat BGP state for the Tan VPS block showed hundreds of collector paths on 12 July 2026. The paths ended in AS150895 and repeatedly passed through AS18403, a large Vietnamese network associated with FPT. That is strong evidence about the public path seen from those collectors at that moment. It is not enough to declare a direct contract between Tan VPS and either company, because BGP paths do not disclose every contractual layer and can include route servers, resellers or managed relationships.
The visible arrangement does show why the operator boundary matters. If a customer workload uses an address in 157.66.222.0/23, at least four kinds of control may be separated:
1. Tan VPS may control the customer relationship and address assignment. 2. AS150895 controls, or is authorised to control, the current origin announcement. 3. Another network may carry the route onward as transit. 4. A facility operator or hardware supplier may control the physical machine and its access path.
One company can occupy several of these roles, but public routing data does not prove that it does. Every boundary adds an escalation requirement. If traffic disappears, Tan VPS must be able to determine whether the fault is inside a guest, on a host, in the top-of-rack network, at the origin router, in transit or at the facility edge. It must then reach the party with authority to repair the failing layer.
This is why “our network is online” is not a sufficient resilience statement. A route can remain visible while all customer machines behind it are unavailable. Conversely, a server can remain healthy while its prefix is withdrawn. A control panel can say a virtual machine is running while a saturated transit link makes it unusable. Infrastructure assessment has to preserve those layers rather than collapsing them into one green status light.
The registered office does not locate the rack
Tan VPS’s registration points to Quy Nhon. Its servers might be in Quy Nhon, but the cited evidence does not establish that. A legal address identifies the company’s registered place. An APNIC contact address identifies a party responsible for number resources. Neither is a colocation certificate.
This is more than a geographical technicality. Place determines the failure environment. Utility reliability, generator autonomy, flood and storm exposure, cooling design, building security, spare-parts delivery, local engineering coverage and the number of physically separate fibre entrances all attach to a real site. A virtual machine inherits those conditions even when the customer never sees the hardware.
Public IP geolocation cannot close the gap. Commercial databases may place addresses from the same block in Hanoi, Ho Chi Minh City, Quy Nhon or a broader Vietnamese region, depending on their method and update cycle. Those labels are estimates designed for network location, fraud controls or content delivery. They are not proof that a particular disk is in the named city. The registration country is similarly limited: it associates the resource with Vietnam, but does not trace every copy of customer data.
A credible placement statement for Tan VPS would identify the city and facility operator for the primary service, the city and operator for recovery capacity, and the ownership model for the equipment. It would distinguish an owned host from leased bare metal and both from a resold virtual machine. It would say which party controls physical access and which party can approve an emergency intervention.
That information need not expose a rack number or weaken security. Customers can assess concentration with a facility name, region, service model and independent assurance. Without even that level of disclosure, claims about domestic hosting or geographic redundancy remain hypotheses.
Vietnam’s wider infrastructure policy makes location economically relevant. VNNIC says the Vietnam National Internet Exchange operates multiple connection points and can improve domestic routing efficiency, latency and backup connectivity. The Ministry of Science and Technology’s digital infrastructure strategy summary describes national ambitions for new data centres, green standards and international cable capacity. Those national capabilities create options. They do not show which option Tan VPS actually buys.
Installed capacity is not usable capacity
Even if Tan VPS disclosed a row of servers tomorrow, the count would be a poor proxy for what customers can rely on. Hosting capacity has several different meanings, and cheap capacity often looks most generous before failure allowances are deducted.
Installed capacity is the hardware or virtual allocation nominally present: processor cores, memory, storage, ports and power. Sellable capacity is what the provider chooses to offer after reserving overhead. Delivered capacity is what customers can use under normal contention. Survivable capacity is what remains after a host, switch, storage node, circuit or power feed fails. Recoverable capacity is what can be brought back within the promised time using spares, backups and staff.
The public record provides no number for any of these Tan VPS layers. The 512-address pool is not a host count. A provider can place many virtual machines behind one address, assign several addresses to one machine, reserve ranges, or leave addresses unused. AS150895’s broader footprint, visible on BGP.tools, is not Tan VPS inventory. The origin network announces many blocks registered to different named organisations. Aggregating their address counts would create a false measure of Tan VPS capacity.
The same caution applies to bandwidth. A /23 does not imply a 1 Gbps, 10 Gbps or any other port. A route visible from hundreds of collectors can still sit behind a congested access circuit. A nominally diverse network can converge on one building entrance. A large transit provider may have enormous capacity globally while the customer’s particular handoff is small.
Useful capacity evidence would start with a service class. For VPS, it should disclose the virtualisation model, normal CPU allocation, memory commitment, storage medium, contention policy and host-failure behaviour. For bare metal, it should identify the replacement class and typical replacement time. For managed hosting, it should add operating-system and application responsibilities. Each class should have a failure-state capacity figure, not merely a catalogue maximum.
Customers should also ask how much headroom exists while equipment is under maintenance. Redundant components are often temporarily non-redundant during upgrades. A cluster that can absorb one failed host at normal utilisation may not absorb it during a seasonal peak. Storage rebuilds consume bandwidth and input/output capacity. Live migration can saturate internal links. The relevant promise is not “we have spare capacity” but “we demonstrated that this priority workload can restart or move while the system is already under the expected load.”
Until Tan VPS supplies that evidence, its capacity should be described as unquantified, not zero. The live prefix suggests some operational use, but an address block cannot tell a buyer how much compute sits behind it or how much survives a fault.
The rack and power chain defines the first hard failure boundary
Every hosted service rests on equipment that consumes power in a physical environment. A customer may buy a virtual CPU by the month, but the provider must still keep a host powered, cooled and connected. The dependency chain runs through utility feeds, switchgear, uninterruptible power systems, generators, fuel, cooling, fire controls, rack distribution units, power supplies and cabling.
No cited Tan VPS material identifies a facility tier, power topology, generator arrangement, cooling design or fire zone. That absence matters because a facility label alone would not settle resilience. The Uptime Institute’s Tier explanation distinguishes topology from operational sustainability and stresses that management behaviour affects long-term performance. A design claim must be paired with maintenance and operating evidence.
A single-rack incident can defeat an otherwise capable building. A failed rack power unit can take down every host in that rack. A top-of-rack switch failure can isolate machines while the wider facility remains online. A maintenance error can interrupt both nominally redundant feeds if the paths share a component. Fire suppression or an environmental alarm can require a controlled shutdown even when utility power is intact.
Ownership determines the repair clock. If Tan VPS owns hardware in colocation, it may replace server components but depend on the facility for common power and access. If it leases dedicated machines, the hardware supplier may control replacement. If it resells another cloud, Tan VPS may have no physical access and can only escalate. The customer’s restoration time then includes detection, diagnosis, handoff, supplier acknowledgement, facility access and the repair itself.
The Uptime Institute’s 2026 outage analysis reports that external infrastructure failures are becoming more prominent even as per-site outage frequency declines. That finding is broad industry context, not evidence of a Tan VPS incident. Its relevance is the shape of the risk: third-party dependencies do not disappear because the retail provider presents one invoice.
A serious Tan VPS service description would therefore identify the facility boundary, maintenance responsibilities, remote-hands target, spare access, and last tested response to loss of a rack feed or switch. Without those facts, the word “cloud” would not make the physical dependency any smaller.
Transit diversity has to survive a real path failure
The current route is visible and RPKI-valid. Those are positive signals. They show that the block can participate in modern route-origin validation and that its reachability is broadly propagated. They do not by themselves show diversity.
VNNIC’s 2024 report presents multihoming, collaboration with transit providers and RPKI as complementary parts of network redundancy and routing security. That is the right separation. RPKI helps networks reject an unauthorised origin; it does not create a second cable. Two BGP sessions can traverse one conduit. Two nominal carriers can buy capacity from the same upstream. Two routers can share a power feed.
The route snapshot for 157.66.222.0/23 repeatedly shows AS18403 immediately before AS150895 from many collector perspectives, although some paths contain repeated prepending and different networks farther away. This suggests a concentrated visible route at that observation time. It cannot prove that no hidden or backup path exists, because route collectors show selected best paths and do not expose an idle circuit that has never been activated.
That is precisely why failover evidence matters. Tan VPS or the operator responsible for its block should be able to demonstrate:
1. The current origin policy and authorised backup origin, if one exists. 2. The number and capacity of physical handoffs serving the customer platform. 3. Whether the handoffs use separate building entrances, routers, power domains and upstream networks. 4. Route behaviour when the primary session or circuit is withdrawn. 5. Available bandwidth and packet loss during the failure state. 6. The people and approvals required to change a ROA or routing policy in an emergency.
The origin migration from AS151932 to AS150895 is useful historical evidence that a routing change can occur. It is not a recovery test. A planned migration may have benefited from days of preparation, overlapping announcements and coordinated authorisation. An unplanned outage may require the same actions under pressure, with one party unreachable or a contract in dispute.
Operational routing practice also includes filters, maximum-prefix limits, session authentication and route-leak controls. RFC 7454 sets out BGP operational and security recommendations, while RFC 9234 addresses route-leak prevention through the roles networks assign to their relationships. Public data does not show whether every relevant Tan VPS path follows those recommendations. A customer need not audit every router, but it should ask for a clear routing design and incident responsibility.
The failure consequence is straightforward. If the sole effective origin arrangement fails, websites, APIs, game servers, mail systems, remote desktops and management interfaces on the block can all become unreachable at once. Healthy disks do not help a user who cannot reach them.
Hardware stock and storage design determine the repair window
Hardware fails gradually and suddenly. Drives accumulate errors. Power supplies stop. Fans seize. Memory faults appear. Optics degrade. Firmware updates expose latent problems. Hosting reliability comes not from pretending this will not happen, but from limiting the fault domain and restoring service with known parts and procedures.
Tan VPS’s public footprint does not disclose its physical host count, hardware generation, warranty coverage, local spare stock or supplier response time. It also does not show whether storage is local to each host, replicated across nodes, attached to a shared array or provided by an upstream cloud. These designs have different performance and recovery behaviour.
Local storage can keep a small VPS service simple, but a host failure may require a restore or movement of disks. Shared storage can enable faster restart on another compute node, while creating a storage-network and controller dependency. Replicated distributed storage can tolerate component loss, but rebuild traffic and correlated faults can reduce performance. Snapshots can speed rollback, but a snapshot on the same failed storage is not an independent backup.
NIST SP 800-125A explains that the hypervisor mediates access to physical CPU, memory, network and storage resources for multiple virtual machines. This is why a customer’s apparently isolated VPS still depends on shared host functions. The guidance is not a certification of Tan VPS. It supplies the correct technical frame for asking how the company secures and recovers those shared layers.
A useful repair commitment should name the event and the clock. “Replacement hardware available” is weaker than “a failed host of this class can be replaced or its priority guests restarted within four hours, and the last exercise completed in a measured time.” The evidence should cover spare drives, power supplies, memory, network adapters, optics and at least one compatible host or supplier replacement route.
Repair capacity also includes people. An engineer must be able to diagnose the fault, reach the site or remote-hands team, access configuration backups and make a safe change. A small company can provide excellent service, but concentration in one person is still a risk that should be managed through escalation coverage and documented authority.
Without disclosure, a buyer cannot tell whether Tan VPS’s real recovery window is minutes, hours or the next business day. The monthly price should be judged against that uncertainty.
Backup is a separate product even when it is bundled
Customers routinely confuse a VPS image, a snapshot, storage replication and a backup. Providers sometimes encourage the confusion by placing all four under a single “protected” label. The distinctions become visible only after deletion, corruption, compromise or facility loss.
A snapshot is a point-in-time state useful for rollback. Replication keeps another copy aligned, which helps with component failure but may also copy deletion or corruption. A backup should be recoverable independently of the production failure domain and protected by separate access controls. A disaster-recovery environment adds compute, network, configuration and people capable of using that backup within a target time.
No cited public source states what Tan VPS includes. A customer should assume nothing. Root access to a VPS often places application and data protection on the customer unless the contract says otherwise. A managed service may include backups but limit retention, restoration frequency or the number of free restores. A provider can keep backups yet lack the spare capacity to run them after the primary site fails.
The CISA ransomware guide recommends offline, encrypted backups and regular tests of availability and integrity. NIST SP 800-34 Revision 1 treats alternate storage, alternate processing, telecommunications and information-system backup as connected contingency controls. These are general standards, not claims about Tan VPS. They illustrate why a single “daily backup” statement would still be incomplete.
The contract should define a recovery point objective, the maximum tolerable data interval lost, and a recovery time objective, the maximum tolerable restoration time. Google’s disaster-recovery planning guide explains that tighter objectives generally cost more and require more complexity. Cheap hosting can rationally offer slower recovery, but the trade should be explicit.
A meaningful Tan VPS backup disclosure would identify frequency, retention, encryption, operator, physical or cloud location, credential separation, restore scope, measured restore speed and the result of the last test. It would say whether customers can export backups without opening a ticket. It would also state who pays for network transfer and how long access remains after cancellation.
Backups become especially important when the current route depends on another origin network. If the commercial relationship behind that route ends, a customer may need to rebuild elsewhere before the old address block or control plane is available. A backup that can be restored only inside the same supplier boundary is not a complete exit plan.
Support and billing can take down healthy machines
Infrastructure failure is not confined to broken equipment. An account can be suspended after a disputed invoice. A renewal notice can reach the wrong person. A control-panel credential can be lost. A domain used for authentication or status updates can expire. A customer can wait hours for a technically simple change because only one individual has authority to approve it.
The APNIC records include administrative and technical contacts, but those are number-resource contacts, not proof of a staffed customer support service. The cited company listings provide a corporate contact trail but no support hours, ticket target, emergency telephone, status page or incident communication policy. No public service terms cited here establish how billing disputes, abuse complaints, cancellation or data retrieval are handled.
That gap is material for a small hosting buyer. When the customer-facing company depends on a route-origin operator, transit carrier, facility and hardware supplier, the support desk becomes the coordinator across those layers. A fast acknowledgement is not the same as authority to repair. The provider should identify the escalation owner for routing, hardware, facility access and account state.
The management path should also be independent enough to survive the production fault. If the portal, support email, status page and customer servers share one route or authentication service, an outage can remove both the service and the means to report it. An alternative published contact points and out-of-band console reduce that risk.
Billing terms belong in the resilience review because the effect of suspension is binary. A customer should know the grace period, renewal responsibility, dispute process, data-retention period and charge for retrieval or transfer. Critical accounts should have multiple authorised contacts. The provider should be able to restore a mistakenly suspended service without waiting for an unrelated office function.
Hosting economics often hides here. A low headline price may exclude 24-hour engineering coverage, hands-on repairs, managed backups, assisted migration or long retention. None of those omissions makes a service illegitimate. It makes price comparison impossible unless the buyer compares the same recovery obligation.
Migration is where address control becomes commercially important
The ability to leave is one of the best tests of a hosting service. Migration exposes which assets belong to the customer, which depend on the provider and which can move only with another company’s cooperation.
Tan VPS’s portable /23 could provide useful address stability at the provider level, but a customer is unlikely to control the whole block. The current ROA authorises AS150895, not the customer’s destination network. Unless a contract grants portability and the route policy supports it, an individual VPS customer should assume its assigned address will not follow it to a new host.
Losing an address affects more than DNS. Firewalls, partner allowlists, mail reputation, certificates, webhook targets, monitoring and remote-access policies may all embed it. DNS can redirect many services, but cached records and hard-coded dependencies create delay. Reverse DNS may require the old provider. Mail systems face additional reputation and authentication work. A hurried migration can therefore turn a provider dispute into a multi-day application incident.
Data volume creates another constraint. A customer with several terabytes can have a valid backup and still miss its recovery target if the export path is slow. The provider’s normal outbound bandwidth may be shared or rate-limited. A failing storage system may read more slowly during recovery. Egress charges or manual approval may delay transfer. Installed storage capacity is not the same as export capacity.
A tested Tan VPS exit plan should cover data format, export method, available throughput, credential ownership, DNS and reverse-DNS changes, address replacement, final snapshot, validation and secure deletion. It should state how long a cancelled customer can retrieve data and whether the service stays online during a billing dispute. For managed workloads, it should also include configuration, database state, secrets and application dependencies rather than only a virtual disk image.
The 2025 origin change demonstrates that the block itself can be re-originated under a different authorised ASN. That history is encouraging only at the broad resource level. It does not prove that an individual customer can initiate or survive such a move. The relevant evidence would be a customer migration exercise with measured data transfer and service cutover.
Portability is also a bargaining issue. If the only current copy of the data, the customer address, the DNS controls and the support channel all remain inside one supplier boundary, the customer has little leverage during a failure. Independent backups, customer-controlled DNS and documented configurations turn migration from an emergency negotiation into an engineering task.
Data locality must trace every copy and every operator
Tan VPS is registered in Vietnam and its number resources carry the VN country attribute. The current origin network is also Vietnamese. These facts support a Vietnam-centred network identity. They do not prove that every customer workload, snapshot, log or support system stays in Vietnam.
Data locality has at least four layers. Physical locality asks where the primary and backup media sit. Network locality asks where traffic is routed and inspected. Administrative locality asks which organisations and staff can access the systems. Legal locality asks which obligations apply to the customer, provider, data type and cross-border transfer. A country code in an ASN record answers none of these completely.
Vietnam’s Law on Data, No. 60/2024/QH15, effective from 1 July 2025, covers digital-data management, protection, processing and use. The Government’s personal-data protection decree establishes additional duties around personal data. The exact obligations depend on the processing context and require legal advice. The procurement point is simpler: a customer cannot assess compliance or sovereignty without knowing where copies and access rights reside.
A Tan VPS locality statement should identify the primary facility region, backup region, support-access locations, subcontractors, telemetry services and any cross-border transfer. It should explain how customers select or verify location and how deletion propagates to snapshots and backups. If an upstream infrastructure provider is involved, that provider’s location and access terms are part of the answer.
Local hosting can reduce latency to Vietnamese users and support a customer’s locality preference, but domestic placement is not automatically resilient. Two sites in one city may share power or fibre risks. A geographically separate backup may improve recovery while creating a cross-border or regional policy question. The correct design follows the customer’s data classification and recovery objective, not a generic claim that local or foreign is always better.
The lack of a named Tan VPS facility means the Data sovereignty and locality topic remains a question to be resolved, not a benefit already demonstrated. The company’s Vietnamese registration is a starting point for due diligence, not the end of it.
The likely failure chain crosses several contracts
The current evidence supports a concrete scenario without claiming that it has happened. Imagine a customer application on an address inside 157.66.222.0/23. The virtual machine becomes unreachable. Public BGP still shows AS150895 originating the block, so the global route has not disappeared. The fault could be a guest problem, a failed host, a rack switch, an internal link, filtering, a denial-of-service control or a facility issue.
The customer contacts Tan VPS. If Tan VPS controls the hypervisor, it can inspect the guest and host. If hardware is leased, it may need the supplier. If the rack belongs to a colocation facility, access may require remote hands. If the issue sits at the origin network, AS150895’s operator may need to change routing or filters. If the route is propagated through a carrier path, another escalation may follow.
Now change the scenario: the route itself disappears because the origin arrangement is interrupted. Tan VPS’s own AS151932 currently has no active prefixes, and a ROA authorising it would not be valid under the observed state. Recovery might require restoring the AS150895 session, creating a new authorisation and origin, or moving services to addresses supplied elsewhere. Each route involves parties, credentials and lead time that a customer cannot infer from the company name.
Now add a billing disagreement or expired upstream contract. The hardware can remain healthy while the route or control access is withheld. Technical redundancy inside one facility may not protect against a common commercial dependency. The recovery plan needs contractual notice, account ownership, alternative connectivity and a data export path.
Finally, imagine a destructive compromise. Replicated storage copies the damage, and snapshots under the same credentials are deleted. The public route remains perfect. Recovery depends on an independent backup, clean credentials, spare compute and a tested rebuild procedure. This is why route reachability, high availability and disaster recovery are distinct promises.
These scenarios are not accusations against Tan VPS. They are the normal failure modes implied by the visible ownership and routing split. A provider can answer them well. The public evidence simply does not show that answer yet.
What would raise confidence
Tan VPS does not need to publish confidential diagrams or customer data to make its service legible. A compact evidence pack could move the assessment substantially.
First, it should publish or provide a service-to-infrastructure map. The map should name the product classes, primary and recovery facility regions, facility operator or service model, current customer prefixes, origin ASN and responsible party at each layer. It should distinguish resources Tan VPS owns from resources it leases or resells.
Second, it should explain the AS151932-to-AS150895 change. The useful facts are the reason for the origin arrangement, the services covered, the party controlling ROAs and route changes, the backup origin plan, and the effect of contract termination. A dated failover test would be stronger than a statement of intent.
Third, it should quantify capacity after failure. For each service class, customers need normal utilisation, reserved headroom, storage protection, host-failure behaviour, network capacity after one path fails, and the number of priority workloads that can restart at the recovery site. A catalogue’s maximum specification is not a survivability measure.
Fourth, it should provide operational evidence: facility assurance, last power or network exercise, spare inventory, remote-hands target, backup retention, restore-test results, support coverage and incident communication channels. Redacted results are sufficient if they preserve dates, scope, measured recovery and lessons.
Fifth, it should make the customer exit practical. That means a documented export method, customer-controlled DNS where possible, clear address replacement, transfer throughput, data-retention period and deletion process. A sample migration run should include the time required to move a realistically sized workload.
Finally, it should state locality and subcontracting boundaries in plain language. Customers should know where primary data, backups and logs are held, who can access them, and whether any supplier change can alter that location.
None of these requests depends on Tan VPS being large. Small providers can be transparent and disciplined; large providers can be opaque. The question is whether the company can connect a monthly service promise to the racks, routes, contracts and people that make it true.
The honest conclusion is a downgrade, not a dismissal
Tan VPS has a real corporate registration, a VNNIC membership entry, an APNIC-recorded ASN and a portable IPv4 allocation. Its block has a visible routing history and remains globally announced under a valid route-origin authorisation. These are stronger signals than a brand page or an unverified uptime claim.
They support only a limited operating conclusion. The company’s own AS151932 is currently inactive in the public route view. Its block is originated by AS150895. The cited record does not locate customer hardware, name a facility, identify server ownership, quantify usable capacity, show transit diversity, document backup restoration, establish support coverage or guarantee data portability.
The result is not “Tan VPS has no infrastructure.” Public evidence cannot establish that. The result is that Tan VPS’s customer-facing infrastructure cannot yet be reconstructed from public evidence with enough confidence to rate its resilience. The live block proves reachability; it does not prove the service behind it.
For a low-risk, replaceable workload, a buyer may accept that uncertainty in exchange for price or convenience, provided it keeps independent backups and controls its migration path. For a business-critical or regulated workload, the missing facility, operator, recovery and contract details should be resolved before deployment.
Hosted capacity is always physical somewhere and dependent on someone. Tan VPS’s routing transition makes that general truth unusually visible. The next step is not another marketing adjective. It is a map showing which rack, route, repair window and contract will carry the customer when the first component fails.