Summary
- Tai-Fu Cloud has a measurable operating footprint. At the 12 July 2026 observation point, AS131628 originated 54 IPv4 prefixes covering 41,472 addresses and was visible to every IPv4 collector peer in RIPEstat's routing-status result. It originated no IPv6 space. The record was first observed in May 2019 and showed two adjacent networks, AS9924 and AS3462.
- That footprint does not establish an independently owned cloud estate. APNIC registers the surrounding
175.96.0.0/14allocation to Taiwan Fixed Network and labels the more specific range used by AS131628 asTAIWANMOBILE-NET. Taiwan Mobile group filings separately list Tai-Fu Cloud Technology Co., Ltd. as a 100%-controlled cloud and information-services company. - Taiwan Mobile describes a substantial group infrastructure base, including multiple IDC sites, Tier III certifications and newer AI-focused capacity. No cited public disclosure assigns AS131628 workloads or Tai-Fu Cloud customers to a named site, rack, power domain or storage system. Group capacity is therefore a possible delivery base, not proof of placement or recovery.
- Route diversity is promising but incomplete. Public route observations show two network adjacencies, while APNIC's policy record names only AS9924 as the default and import path. Neither view proves separate building entrances, fibre ducts, edge routers or power domains. A common local failure could still remove both apparent paths.
- The commercial risk sits at the joins: customer contract to group affiliate, virtual machine to physical host, host to rack power, rack to facility, edge to upstream, backup to restore target, and support request to authorised engineer. Customers should require a service map, tested recovery objectives, spare-capacity evidence, escalation rights and export procedures before treating the visible address count as resilient cloud capacity.
The network is active, but the cloud is not self-explanatory
Tai-Fu Cloud's strongest public fact is not a product page or a facility brochure. It is a live autonomous system. The APNIC record for AS131628 names Tai-Fu Cloud Co., Ltd., gives a Taipei address and places the resource in Taiwan. It also supplies an operational contact using a Taiwan Mobile email address. This is current administrative evidence connecting the Tai-Fu Cloud name to a working part of the public internet.
The route observations are stronger still. The RIPEstat announced-prefixes result contained 54 IPv4 prefixes at the 12 July 2026 endpoint. Its routing-status result counted 41,472 announced IPv4 addresses, showed all 325 available IPv4 collector peers seeing the network, and dated its first observed route to 30 May 2019. The last observation fell on the article date. This is not a reserved number waiting for use, nor an isolated route visible from only a corner of the internet.
It is equally important to record what is absent. The same result showed no announced IPv6 prefix and no IPv6 collector visibility. The neighbour observation identified two adjacent autonomous systems: AS9924, Taiwan Fixed Network, and AS3462, Chunghwa Telecom's HiNet. A second AS131628 routing view independently presented 54 originated IPv4 prefixes and those two networks as upstreams.
These measurements establish public routing, but they do not identify a cloud product. A prefix can carry virtual machines, broadband users, enterprise circuits, content caches, security appliances or mixed traffic. An autonomous system proves that someone is operating routing policy; it does not reveal how many physical servers exist, who owns them, where they are installed, how storage is protected or whether an advertised address is assigned to a paying customer.
That distinction frames the whole company. Tai-Fu Cloud has more operating evidence than a business represented only by a registry entry. But the evidence is concentrated at the network layer. The service layer remains much less specific. The sensible conclusion is neither that the company is merely a name nor that 41,472 routed addresses equal 41,472 units of dependable cloud capacity. It is that an active network exists and the rest of the delivery chain needs to be mapped.
Two names point into one group boundary
Public records use closely related names. The internet registry says Tai-Fu Cloud Co., Ltd. Taiwan Mobile's financial disclosures use Tai-Fu Cloud Technology Co., Ltd., abbreviated TFC, and describe its business as cloud and information services. The company's Chinese registration is commonly rendered as 台富雲科技股份有限公司. The overlap in address, business description, group contacts and network identity supports treating these as references to the same operating company boundary, while preserving the formal wording used by each record.
The Taiwan Mobile 2024 consolidated financial statement lists TFC at 100% ownership in both 2024 and 2023. The 2025 consolidated statement again lists it at 100% and calls its activity cloud and information services. A corporate-record presentation reports incorporation on 11 January 2018, paid-in capital of NT$240 million and a Taipei registered office; Taiwan Mobile's own 2024 affiliate disclosure gives the same incorporation date, capital and business description.
This group position matters more than corporate genealogy for infrastructure analysis. Tai-Fu Cloud is not presented as a stand-alone hyperscaler raising its own data-centre estate from scratch. It sits inside a telecommunications group that owns fixed-network assets, operates enterprise services and markets data-centre capacity. The group can plausibly supply facilities, addresses, circuits, procurement leverage and support labour that would be expensive for a smaller cloud unit to recreate.
Group access, however, is not the same as direct control. A customer contract with TFC may depend on a facility run by Taiwan Mobile, address space registered to Taiwan Fixed Network, transit provided across group and external networks, and maintenance performed by another team. That can be an efficient operating model. It can also create ambiguity about who has authority during a fault.
The buyer needs the answer at contract level. Which legal company invoices for compute? Which company owns the server? Which one leases the rack? Who holds the cross-connect order? Which network operations centre can change a route? Which service desk has authority to dispatch remote hands? Who remains responsible for customer data if one affiliate changes its product or terminates an intercompany arrangement?
The public records show common control and operational proximity, not the allocation of each duty. A well-run group can make those joins invisible in normal operation. Recovery exposes them. When a switch fails at 2am, the useful fact is not that every company has the same ultimate owner. It is whether the person answering the incident has credentials, spare hardware, site access and authority to act.
The address space belongs to the wider telecom estate
The origin routes carry another important clue. An APNIC lookup of the covering address allocation shows 175.96.0.0 through 175.99.255.255 as TFN-NET, allocated to Taiwan Fixed Network Co., Ltd. The more specific 175.97.128.0 through 175.97.191.255 record is labelled TAIWANMOBILE-NET. AS131628 originates many prefixes carved from this broader address estate.
That is not an anomaly. Groups often delegate addresses to services or operating units while retaining registration at a network affiliate. It also means the address count should be interpreted as delegated routing scope rather than property owned outright by Tai-Fu Cloud. The usable commercial rights may arise from a group allocation, an operating agreement or a network-service arrangement that the registry does not disclose.
For a customer, address continuity depends on those rights. If a hosted service uses addresses from the Taiwan Fixed Network allocation, can a customer keep them when moving between Tai-Fu Cloud sites? Can the company continue announcing them if a group contract changes? Are customer allowlists built around addresses that remain stable through a migration? Can a customer bring its own prefixes, and if so, which company maintains route objects and Route Origin Authorisations?
One route-security signal is positive. A RIPEstat validation check for 175.97.128.0/23 reported the AS131628 origin as valid against a covering authorisation. That sampled result shows that at least one origin-prefix pair was aligned with the Resource Public Key Infrastructure at the observation time. It should not be stretched into a claim that every more-specific route, filter and registry object is always correct.
The lack of originated IPv6 is more than a scorecard omission. It may indicate an IPv4-focused customer base, a service design that has not exposed IPv6, or a routing policy that keeps IPv6 elsewhere in the group. It does not make the IPv4 service inoperable. It does narrow what can be claimed about dual-stack readiness and increases the need to ask how customers requiring IPv6 are served.
Addressing also affects exit. A virtual machine image is portable only if the application can tolerate a new address, DNS change, certificate update, firewall revision and third-party allowlist change. Provider-controlled IPv4 can be a source of switching cost even when disk export is technically easy. A credible migration plan therefore covers network identity as well as data transfer.
Two observed paths do not yet make a redundant edge
AS131628's two observed neighbours are encouraging because they show more than one external network in public paths. AS9924 is Taiwan Fixed Network, the group's fixed-line operator. AS3462 is HiNet, operated by Chunghwa Telecom. From a high level, a group path plus an external incumbent path is a more useful starting position than a single visible neighbour.
The registry and route collectors tell slightly different stories. APNIC's AS131628 object lists a default route to AS9924 and an import from AS9924, with no equivalent policy line for AS3462. Current route observations see both. Registry policy can lag production, omit detail or describe only a preferred configuration; collector data can see adjacency without revealing the commercial role or physical construction. The discrepancy is not evidence of a fault. It is a reason to request the current network diagram rather than inferring it from either view alone.
True diversity has several layers. The BGP sessions should terminate on separate edge devices. Their cross-connects should use independent ports and preferably independent meet-me rooms. Fibre should enter through different building paths and avoid a shared metro duct where practical. The routers should not depend on the same switch, power distribution unit or management plane. Each remaining path should have enough committed capacity to carry peak traffic when the other is removed.
None of that is visible in an AS path. Two autonomous-system numbers can still converge on one router or one building entrance. Conversely, a single upstream can sometimes provide physically diverse services. Public routing is excellent for showing propagation and origin. It is poor at proving local fault domains.
Customers should ask for maintenance-shaped evidence. When one edge router is upgraded, does traffic move without session loss beyond the stated tolerance? When one carrier circuit is disabled, what percentage of normal peak load uses the surviving path? Has the company tested a complete loss of AS9924 while retaining reachability through AS3462? Does the reverse test work? Are inbound and outbound paths both controlled, or does one direction fail differently?
The answer should include time. A path that can be restored in four hours is not the same as an active path that absorbs traffic in seconds. A circuit that exists on paper but is rate-limited below peak demand is not usable redundancy. Route diversity becomes service resilience only when failover behaviour, capacity and fault separation have been measured together.
Parent-group data centres are not proof of Tai-Fu placement
Taiwan Mobile has made detailed claims about its data-centre estate. In 2013 it announced an IDC cloud facility in Taipei's Neihu technology district with nearly 8,000 ping of floor area, NT$5 billion of investment and Tier III design and constructed-facility certifications. The launch description said the site used redundant power and cooling paths, N+1 equipment, segregated mechanical zones, managed services and a target PUE of 1.5.
In 2019 the group opened a Taichung IDC, describing it as designed around Tier III principles with ISO 27001 and ISO 27011 certifications. Taiwan Mobile's 2024 annual report says its cloud IDC server room holds Uptime Tier III certifications for design, construction and operational sustainability. A 2025 group statement said nine IDC sites could support energy-intensive AI applications and two had been upgraded for AI data-centre use.
These are meaningful group capabilities. They demonstrate that Tai-Fu Cloud's corporate family has experience with purpose-built facilities, enterprise connectivity and managed operations. They do not locate a single AS131628 address, customer virtual machine or backup copy. No cited disclosure says that Tai-Fu Cloud owns one of those buildings, leases a specific hall, uses all nine sites, or can move customer workloads among them.
That boundary prevents a common analytical error: converting a parent's estate into a subsidiary's guaranteed service footprint. Access can be shared selectively. One product may run in Neihu, another in Taichung, and a third on partner infrastructure. A subsidiary may sell group capacity without controlling facility engineering. It may also have reserved space across several sites. Public group totals cannot choose among those possibilities.
Site assignment should be proved per service. A buyer does not necessarily need a rack number published on the internet, but it should receive a city or campus, facility operator, data-hall class, power arrangement and network-entry design under appropriate confidentiality. It should know whether the secondary copy is in another building, another metropolitan area or merely another rack in the same hall.
This is especially important for simultaneous maintenance. Uptime Institute explains that Tier III means concurrently maintainable: each capacity component and distribution path can be removed on a planned basis without shutting down IT operations. It does not mean that every application is automatically multi-site, that operator error is impossible, or that customer architecture survives a complete facility loss. Facility certification is one layer; workload design remains another.
New AI capacity should not be confused with spare recovery capacity
Taiwan Mobile's newer AI infrastructure makes the installed-versus-usable distinction sharper. In March 2026 the group described an AI data centre with 25 MW of total power capacity, 16 MW of IT load, support for racks above 135 kW and space for as many as 1,700 standard racks. In June it said the Guishan, Taoyuan facility had been 100% sold during presales and paired its data-centre offer with GPU and dedicated-line services.
Those figures show serious infrastructure investment. They say nothing direct about the older IPv4 ranges originated by Tai-Fu Cloud. The June 2026 announcement speaks in Taiwan Mobile's name, refers to strategic partners and focuses on AI compute. It does not identify AS131628 as the delivery network or TFC as the contracting company.
The sold-out claim also illustrates why gross capacity is not recovery capacity. A 25 MW facility can be large and still have no uncommitted room for an emergency migration. Reserved capacity may belong to specific tenants, hardware may be incompatible with a failed workload, and network or storage dependencies may prevent a rapid move. If all sellable modules are committed, failover requires capacity that was deliberately withheld, contractually reserved or already running as a replica.
The same applies at smaller scale. A cloud cluster with 100 hosts is not N+1 if 100 hosts are needed at peak. A storage platform with three copies in one room is not site recovery. A second data centre is not a restore target if it lacks current images, network configuration or customer licences. Installed hardware is an inventory fact; usable capacity is what can accept work after reservations and maintenance; recoverable capacity is what can accept the right work within the promised time.
Tai-Fu Cloud customers should ask for those three numbers separately. How many physical hosts support the purchased service? What is normal and peak utilisation? How much memory, compute, storage and port capacity remains after one host, one rack or one site is removed? Is emergency capacity reserved contractually, or offered only if available? What was the largest restore or live migration tested in the past year?
A capacity claim becomes credible when tied to a failure scenario. The useful statement is not "multi-site cloud available." It is "all protected workloads in this service class can be started at the secondary site within this recovery time while the primary site is unavailable, and the last full exercise restored this volume at this measured rate." Public disclosures do not yet provide that level of detail for Tai-Fu Cloud.
Power turns virtual capacity back into a physical service
Every virtual server eventually becomes electrical load. Utility feeds, switchgear, uninterruptible power systems, batteries, generators, fuel, cooling and control systems determine whether the host remains available. Taiwan Mobile's Neihu description is useful because it acknowledges these layers explicitly: dual distribution paths, redundant critical equipment, segregated areas and the ability to maintain systems without stopping IT load.
The group also reports energy-efficiency and renewable-energy initiatives. Its product and service disclosure says the cloud IDC can reach a PUE of 1.5 at full load and describes 100% renewable electricity for the cloud data-centre service. Its climate-management page lists hot- and cold-aisle separation, free cooling, efficient equipment and energy-management controls.
These environmental claims matter to customers measuring hosted emissions, but they should not be used as uptime proxies. Renewable sourcing does not by itself create an independent utility path. PUE measures facility overhead relative to IT energy; it does not measure spare electrical capacity or application availability. Efficient cooling can be well engineered while a particular rack still depends on one power strip.
Taiwan's grid is generally reliable, yet data centres are designed around the consequences of the remaining outages. Taipower's reliability reporting tracks interruption frequency and duration, while its sustainability reporting describes ongoing high-voltage outage review and reliability work. A cloud provider must bridge any grid interruption long enough for generators to start and then sustain load through fuel delivery or grid restoration.
The customer-facing questions are concrete. Are both power supplies on each server connected to independent rack distribution units? Do those units follow separate upstream paths? How long can batteries carry the current load? When were generators last tested under load? Is refuelling contracted during a regional emergency? Does cooling remain available throughout generator operation? Are network routers and storage on the same protected power architecture as compute?
The repair window matters too. Concurrent maintainability supports planned work, but emergency failure can overlap with equipment already removed for maintenance. Buyers should ask what redundancy remains during planned work and whether high-risk maintenance is communicated. A service may satisfy the facility's topology and still expose a customer if the customer's own equipment is single-corded or concentrated in one rack.
Earthquake and regional failure require distance, not just duplication
Taiwan's seismic environment makes location diversity more than a procurement slogan. The Central Weather Administration publishes earthquake potential maps and continuing event data. The issue is not that every earthquake disables data centres. It is that correlated failure can affect power, transport, fibre routes, staff access and supplier logistics across a region even when a building performs as designed.
Two copies in the same room protect against a disk failure. Two racks in the same hall may protect against a rack-level power fault. Two halls in one building may reduce some local risks. None provides the same separation as a second metropolitan area with independent utilities, carrier entrances and operations staff. The recovery design has to match the event being claimed.
Taiwan Mobile's named facilities in Taipei, Taichung and Taoyuan suggest that the group can operate across more than one location. They do not prove that a given Tai-Fu Cloud service replicates among those places. The AS131628 route table cannot reveal where prefixes terminate internally, and a secondary IP path does not imply a secondary compute site.
Customers should request a failure-domain map that marks city, facility, hall, rack, power path, carrier path and storage replica. The map should state which failures each arrangement survives. It should also identify dependencies that remain shared, such as one identity service, one billing platform, one DNS provider, one configuration database or one support team.
Distance introduces trade-offs. Synchronous storage replication needs low latency and can transmit a fault or operator error quickly. Asynchronous replication tolerates more distance but accepts a recovery-point gap. Backups can protect against deletion or ransomware only if credentials, retention controls and storage domains are sufficiently independent. A multi-site design without a tested promotion sequence may create two copies that no one can safely start.
The decisive evidence is an exercise. When was the primary site assumed unavailable? How many workloads started elsewhere? What data was lost relative to the stated recovery-point objective? How long did DNS, routing, firewall and customer access changes take? Were staff able to run the exercise without the same people who built the primary system? Facility geography sets the opportunity for resilience; a completed restore proves whether the service can use it.
Hardware stock and support labour set the real repair clock
Cloud interfaces encourage the idea that servers are interchangeable. At the physical layer, a failed component still needs diagnosis, a compatible spare, site access and an authorised person. Disks, power supplies, memory, network cards, optics, top-of-rack switches and edge routers have different replacement paths. A platform can automate workload restart and still run short of healthy hosts after several failures.
Tai-Fu Cloud's public network footprint does not disclose its hardware arrangement. It could use owned servers, leased bare metal, a group private cloud, partner capacity or a mixture. Each choice moves the repair obligation. Owned hardware gives more direct control but requires inventory and vendor support. Leased hardware transfers stock responsibility but places the customer behind another provider's priority queue. A group platform can bring scale while adding affiliate handoffs.
The economics are uncomfortable but simple. Spare equipment earns little while idle, so a provider has an incentive to minimise it. Resilience requires the opposite: compatible components, empty host capacity and network ports held back for failures. The gap between those incentives is where service-level promises need evidence.
Customers should ask which spares are on site, which are held elsewhere in Taiwan and which depend on international shipment. They should ask whether one failed switch can be replaced from stock, whether configurations are backed up, and whether a replacement can be installed without waiting for a named specialist. For servers, the useful measure is how many simultaneous host failures the cluster can absorb at peak utilisation.
Labour can be the scarcer resource. A broad fault creates support demand at the same time engineers are troubleshooting. If the same people run routing, virtualisation, storage and customer communication, ticket queues can lengthen even with healthy spare hardware. Group scale may help Tai-Fu Cloud, but public group headcount does not show which team is committed to TFC services or what its response authority is.
A credible escalation plan names roles rather than merely a telephone number. Who acknowledges the incident? Who can declare severity? Who can enter the facility? Who can call AS9924 or AS3462? Who can approve moving data to another site? Who updates customers if the billing account or identity system is unavailable? The service clock should start when monitoring detects the fault, not when a customer eventually reaches the right affiliate.
Billing and provider contracts are infrastructure dependencies
Some outages begin without a broken machine. A cross-connect can be suspended over a contract dispute. A supplier can decline an urgent change because the requesting company is not the account holder. A software licence can expire. A domain, certificate or cloud-management subscription can lapse. A facility can deny entry to staff whose access list is out of date.
Tai-Fu Cloud's group position makes commercial mapping especially important. AS131628 uses address resources registered to Taiwan Fixed Network and contacts at Taiwan Mobile. The group advertises data-centre and managed services under Taiwan Mobile's enterprise business. A customer may encounter several names across quotation, invoice, IP registration, support and facility documentation.
That arrangement can be entirely deliberate and well governed. The risk is not the presence of affiliates; it is an unstated responsibility boundary. If the seller promises an uptime credit but another company controls the circuit, does the seller have a matching commitment from that company? If customer hardware is housed in a group facility, who must authorise removal during contract termination? If a customer disputes an invoice, are data export and service continuation protected while the dispute is resolved?
Exit terms are part of availability. A buyer should know how long data remains accessible after cancellation, what export formats are available, whether snapshots can be downloaded without the management portal, and when provider-controlled encryption keys are destroyed. It should know whether public addresses can move, whether DNS zones can be transferred, and whether there are bandwidth or handling charges for a large export.
The same concerns apply if Tai-Fu Cloud changes an upstream or internal platform rather than if the customer leaves. Provider-led migration should define notice, maintenance windows, rollback, address changes and customer responsibilities. A service that can be sold quickly but takes months to leave is not fully elastic from the customer's perspective.
The contract should therefore mirror the physical chain. It should identify the service provider, network operator, facility operator and material subcontractors by role; state where responsibility transfers; and preserve escalation across those boundaries. Corporate common control can simplify negotiation, but only written rights ensure that a customer is not stranded between affiliated help desks during a failure.
Data locality is a workload fact, not a Taiwan label
Tai-Fu Cloud's routes are registered in Taiwan and its corporate address is in Taipei. Those facts support a Taiwanese network and company identity. They do not show where every disk block, backup, monitoring record or support session is located. Data locality has to be established for each service and each copy.
Taiwan's rules make that precision commercially important. The government's cloud-service security guidance says government-agency cloud data access, backup and redundancy locations must not be in mainland China, Hong Kong or Macao, and related data must not transit those territories. Taiwan's government data-centre guidelines say government data-centre locations should in principle be domestic, with legal compliance and full control required for overseas placement.
Those provisions apply to specified government contexts; they are not a blanket rule that every private workload must remain in Taiwan. Taiwan's Personal Data Protection Act defines cross-border transfer and allows the relevant authority to restrict a non-government agency's transfer in stated circumstances. The official Article 21 presentation includes major national interests, treaty requirements, inadequate protection in the receiving country and transfers intended to evade the law.
The practical lesson is that "Taiwan cloud" is not enough for regulated procurement. A customer needs the physical country of primary data, replicas, backups and logs; the locations from which support staff can access them; and the legal entities acting as processors or subcontractors. It also needs to know whether traffic to a domestic site takes an unexpected international path, though internet path observation alone cannot establish legal data processing.
Locality and resilience can conflict if handled lazily. Keeping every copy in one building improves geographic certainty but weakens disaster recovery. Sending backups overseas may improve regional separation but create legal, contractual or latency concerns. A robust service offers clearly defined placement choices and documents how each option changes recovery.
Tai-Fu Cloud's active Taiwanese routing and group facilities make local delivery plausible. The cited records do not prove a locality commitment for a specific product. Customers should obtain that commitment in the service description, including the treatment of backups and remote administration, rather than inferring it from the company's name, ASN country code or invoice address.
Backups matter only when they can be restored outside the fault
Hosted capacity is recoverable only if customer state survives the failure. A provider can keep virtual-machine snapshots and still lose them with the primary storage array. It can replicate data and reproduce an accidental deletion instantly. It can advertise backups that require a management portal which is unavailable during the incident.
The minimum useful description separates local snapshots, replicas and backups. Local snapshots support fast rollback but usually share the storage system. Replicas support continuity after hardware loss but may share credentials or receive corrupted data. Backups should have retention, immutability or deletion protection appropriate to the risk, plus a restore target that does not depend on the failed system.
CISA's ransomware guidance recommends frequent backups, offline or cloud-to-cloud copies where appropriate, deletion protection or object lock, versioning and a clear understanding of shared responsibility. Those controls apply to customers as well as providers. A cloud vendor may protect its platform while leaving guest operating systems, application data and backup policy to the customer.
Tai-Fu Cloud's public disclosures do not define that boundary. A buyer should ask which layers the service backs up by default, how often, where copies reside, who controls encryption keys and whether deletion by a compromised administrator reaches the backup. It should ask for measured restore throughput rather than retention language alone.
Restore scale is often overlooked. Recovering one test machine does not prove that hundreds of virtual machines can return within the same window. Network bandwidth, storage read speed, image conversion, boot ordering, database consistency and licence checks can all lengthen recovery. The provider should state whether recovery objectives apply per machine, per customer or to the whole service during a regional event.
Customers also need an independent path to their data. Regular exports in documented formats, infrastructure definitions, configuration backups and application-level replication reduce dependence on a single provider's control plane. That is not a vote of no confidence. It is recognition that provider recovery and customer continuity are separate obligations.
Portability is the final test of hosted capacity
Cloud capacity is easiest to evaluate at entry: price, core count, memory, storage and bandwidth. Portability tests the service at exit, when platform differences and data volume become visible. The National Institute of Standards and Technology's cloud reference architecture treats portability and interoperability as distinct cloud functions. For infrastructure services, it describes the ability to capture virtual-machine images and move applications and data even when providers use different virtualisation technologies.
That standard does not make every image portable. Provider-specific drivers, boot modes, network configuration, metadata services, managed databases and security controls can block a straightforward move. Large data volumes may take days to export over the customer's ordinary link. Egress charging and support scheduling can turn technical portability into an economic constraint.
Tai-Fu Cloud customers should ask which image formats can be exported, whether snapshots can be converted, whether APIs are documented, and how long a bulk transfer of their current dataset would take. They should know whether an export requires the source service to remain online and billable. They should test a restore on infrastructure outside the Taiwan Mobile group before a crisis.
Network portability is a separate workstream. If the customer cannot retain an address, DNS time-to-live values, certificate automation, firewall rules, partner allowlists and mail reputation all need preparation. If the service uses provider DNS or load balancers, their configurations need a portable representation. A migration that copies disks but leaves identity and routing behind is incomplete.
Data portability also provides evidence about sovereignty. An export inventory should identify what data exists and where it was retrieved from. A deletion certificate should cover replicas and backups according to the retention policy. The customer should understand what records remain for billing, security or legal reasons after service termination.
The best time to test exit is before renewal, not after an incident. A small representative workload can be exported, started elsewhere, re-addressed and validated. The result reveals undocumented dependencies while support is available. It also gives the customer a measured migration rate from which a full exit time can be estimated.
What the public record supports, and where confidence stops
The evidence supports a clear positive conclusion: Tai-Fu Cloud is associated with an active, globally visible Taiwanese IPv4 network. AS131628 has years of route history, 54 current prefixes, complete visibility in the cited IPv4 collector result and two observed adjacencies. Current corporate filings place the cloud-services company within the Taiwan Mobile group under 100% control. This is materially stronger than a brand with no routable surface or current corporate trace.
Confidence falls when the question moves from network presence to cloud delivery. The address ranges are registered to the wider Taiwan Fixed Network and Taiwan Mobile estate. Group disclosures describe substantial facilities and enterprise services, but do not assign Tai-Fu Cloud workloads to a named data centre. There is no cited Tai-Fu-specific public statement of host inventory, storage design, service-level terms, support coverage, spare parts, recovery objectives, backup placement or export format.
The two observed network adjacencies improve the picture but do not prove physical route diversity. The absence of originated IPv6 narrows the visible service surface. Group data-centre certifications support confidence in the parent's engineering capability, but they cannot be inherited by an unidentified customer deployment. New AI capacity demonstrates investment, yet sold or reserved capacity may not be available for recovery.
This produces a medium network-evidence grade and a lower service-transparency grade. The company should not be treated as dormant, but neither should its routed address count be used as a substitute for capacity or resilience evidence. The most important unknown is placement: which equipment, in which facility, under whose operational control, carries the service associated with AS131628.
Several documents would materially improve confidence without exposing sensitive details. A service architecture naming facility cities and operators; a responsibility matrix across TFC, Taiwan Fixed Network and Taiwan Mobile; a current edge diagram; service-level and support terms; backup and restore specifications; and a data-location schedule would close most gaps. A recent recovery exercise would be stronger than another general availability claim.
Until that evidence is available, procurement should use explicit conditions. Critical workloads should have customer-controlled backups, tested export, independent DNS and a documented alternative host. Contracts should preserve access during disputes and assign responsibility across affiliates. Recovery objectives should be proven at the scale purchased. Locality should cover every copy, not only the primary server.
The diligence questions that determine whether the cloud can recover
The first questions concern the service itself. What does Tai-Fu Cloud sell under its own contract: virtual machines, bare metal, colocation, managed operating systems, storage, backup, connectivity or a bundled enterprise service? Which legal entity appears on the order, and which entity is responsible for data protection, incident notice and service credits? A product name without these answers leaves the customer unable to locate accountability.
The second group concerns physical placement. Which city and facility hold the primary compute? Who owns the servers and storage? Is capacity dedicated or pooled? Are redundant power supplies connected to separate distribution paths? Which failure domains separate hosts, racks, halls and sites? Where are replicas and backups, and what dependencies remain common?
The third concerns the network. Which AS131628 prefixes serve customers? What are the commercial and physical roles of AS9924 and AS3462? Do sessions terminate on different routers and power paths? Can either path carry peak traffic alone? Are Route Origin Authorisations and route-policy objects maintained for every production prefix? How are customers notified of address or upstream changes?
The fourth concerns usable capacity. What is peak utilisation after reservations? How much capacity remains after one host, rack or site is removed? Is failover capacity reserved or merely subject to availability? How many compatible spares are on site? Which components require vendor shipment? When was a full-load failover last exercised?
The fifth concerns people. Is monitoring continuous? What are acknowledgement and escalation times? Who can enter the facility outside business hours? Who has authority to change BGP, replace an edge switch, promote storage or invoke a disaster declaration? Does support remain available if the ordinary customer portal is down?
The sixth concerns data. What is backed up by default, at what interval and in which location? Are copies immutable or protected from the same administrator credentials? What recovery-point and recovery-time objectives apply during a broad event? What export formats, bandwidth and fees apply? Has the customer restored a copy outside the provider group?
The final questions concern termination. Can addresses move? How long is data accessible after cancellation? Can the provider suspend service during a good-faith billing dispute? When are encryption keys and backups destroyed? Which subcontractors retain logs or customer data? A service that cannot answer exit questions has not fully described its availability architecture.
Tai-Fu Cloud's visible routes make these questions worth asking. There is an operating network to examine and a large telecommunications group behind it. What remains is to connect that promising surface to the racks, circuits, contracts and recovery tests that determine what customers actually receive. Hosted capacity is never only a number in a portal. It is a claim on finite machines and finite attention, and its value appears most clearly during the repair window.