PT Cloud Four Cee Services has an Indonesian AS record, but no current route visibility to prove hosted capacity

Summary

• Indonesian registry data identifies PT Cloud Four Cee Services as the holder associated with AS147158, under the name IDNIC-CLOUD4C-AS-ID, and also identifies an IPv4 allocation covering 103.177.104.0/23. Those records establish number-resource stewardship; they do not establish installed servers, live customer workloads or a particular data-centre location.
• RIPEstat's current view shows no announced IPv4 or IPv6 space for AS147158, no observed neighbours and no collector visibility. Its history says the AS was first seen originating 103.177.104.0/24 in December 2021 and was last seen with 103.177.141.0/24 in December 2023. CAIDA likewise marks the AS as not seen, with zero cone prefixes and zero observed degree.
• Cloud4C's own website names PT Cloud Four Cee Services as its Indonesian contact entity and advertises private cloud, managed infrastructure, migration and recovery services. Those commercial claims may describe real services delivered on Cloud4C or partner infrastructure, but the public material examined here does not connect AS147158 to a current Indonesian production site, available compute or storage, active transit, or a tested recovery path.
• A buyer should therefore treat the AS record as an identity and historical-routing clue, not as a certificate of hosted capacity. Useful proof would include named production and recovery sites, current route and upstream evidence, an asset-responsibility matrix, recent restore and failover results, support escalation rights, and a tested data-export plan.

A number exists; a production footprint is another matter

The most consequential fact about PT Cloud Four Cee Services is not that the evidence is absent. It is that the evidence is split. One layer says the company has a recognised place in Indonesia's internet-number system. Another says its autonomous system is not currently visible to the public route collectors used for this review. A third, the Cloud4C website, presents a broad managed-cloud business whose services can be delivered across private infrastructure, public-cloud platforms and partner environments. These layers can all be true at once, but they answer different questions.

The RDAP record for AS147158 names the resource IDNIC-CLOUD4C-AS-ID, gives Indonesia as the country code and identifies PT Cloud Four Cee Services through its associated contact details. It records registration and last-change events on 13 December 2021. The RIPEstat WHOIS view, which republishes data from the relevant authorities, describes the holder as a corporate or direct IDNIC member and includes an import from AS58369 and an export to that same AS in the policy text. This is meaningful evidence of how the network was registered and intended to interconnect.

It is not the same as evidence that the policy is active now. The RIPEstat routing-consistency result makes the distinction unusually clear. It finds an IPv4 block and a declared relationship in registration data while marking both the prefix and the AS58369 relationship as absent from BGP at the time queried. Registry data is a statement about allocated resources and maintained records. BGP observation is a statement about routes that collectors can see. A hosting service adds further layers: servers, storage, virtualisation, licences, facility access, power, cooling, upstream contracts, support authority and customers actually assigned to the platform.

That hierarchy prevents two common mistakes. The first is to see an AS number and assume a live, self-operated cloud. The second is to see an inactive AS and assume the company itself has disappeared. A managed-service provider can run customer workloads in a hyperscale public cloud, in a partner's data centre, behind provider-assigned addresses, or in a customer's own environment without advertising its own prefixes. Conversely, an AS can originate routes without carrying any customer compute at all. AS147158 is therefore a useful starting point, but it cannot bear the commercial conclusion on its own.

The current route view is negative, not merely thin

At the observation time in the supplied public routing data, RIPEstat's routing-status endpoint reported zero IPv4 prefixes, zero IPv4 addresses, zero IPv6 prefixes and zero IPv6 /48 equivalents announced by AS147158. None of 327 listed IPv4 RIS peers and none of 322 listed IPv6 peers saw it. The announced-prefixes endpoint returned an empty prefix list, while the ASN-neighbours endpoint returned no neighbours.

CAIDA provides a methodologically separate cross-check. Its AS Rank record for AS147158 labels the AS as seen: false. The customer-cone fields show one AS, which is the origin itself, but zero prefixes and zero addresses; the observed degree is zero for providers, peers and customers. A Cloudflare Radar routing page recognises the same AS name and holder, but that recognition should not be confused with a currently visible production footprint.

"Negative" is the right grade for present AS-level operating evidence because the current tests do not merely find a small footprint. They find no public announcement at all. The wording has to remain narrow. Public route collectors do not see private paths, networks hidden behind another origin, customer-premises installations or services addressed from a partner's space. Collector coverage is broad rather than omniscient. Yet for the specific proposition that AS147158 itself demonstrates active hosted capacity, the evidence is negative.

That difference matters in procurement. A buyer assessing an internet-facing platform normally wants to know where the service edge is, which network originates the addresses, how many independent upstream paths exist, whether a second site can announce or otherwise serve the workload, and how a routing event affects recovery. When the provider's named AS has no current route visibility, none of those answers can be safely derived from the number. They have to come from a service-specific architecture and from operational tests.

The historical routes show life, then a break

The present silence is more informative because the AS was visible before. RIPEstat records the first observation as 103.177.104.0/24 originated by AS147158 at 16:00 UTC on 11 December 2021. Its last observation is 103.177.141.0/24 originated by AS147158 at 08:00 UTC on 19 December 2023. The dates bracket roughly two years in which at least part of the network appeared in public routing.

The first prefix sits within a block that is still legible in registration data. The IDNIC/APNIC RDAP record for 103.177.104.0/23 names IDNIC-CLOUD4C-ID, covers 103.177.104.0 through 103.177.105.255 and marks the allocation active. RIPEstat's consistency response also finds 103.177.104.0/23 in WHOIS while not finding it in BGP. This is a useful example of why the word "active" must be read in context: the allocation's registry status is active, but the block is not currently observed as an announcement from AS147158.

The last-seen prefix, 103.177.141.0/24, is not the same /24 as the first-seen prefix. That change suggests the visible footprint was not perfectly static. It does not reveal whether the company moved services, tested connectivity, renumbered, used separate sites, changed providers or simply stopped announcing after a business decision. A route collector can show that a prefix and origin pair appeared or disappeared; it cannot show the ticket, contract amendment, customer migration or equipment move that caused the change.

The break after December 2023 is therefore a question, not a story ready to be filled with conjecture. There may have been an orderly migration onto a hyperscaler or partner ASN. There may have been a change of Indonesian network provider. The registered AS may have been retained for future use. The old route may have supported only a narrow component, such as management access, rather than a broad cloud platform. It is also possible that a service was retired. Public evidence reviewed here does not choose among those explanations.

What would settle the issue is not an assertion that the ASN remains registered. It would be a dated account of what happened to workloads and addresses after the last public observation. If services moved, the provider could identify the new origin networks and the customer-notification and rollback process. If AS147158 is deliberately dormant, the provider could explain whether it remains in a recovery design. If the historical prefixes were never customer-bearing, it could state their function. Each answer has a different implication for resilience and exit risk.

The office record is an identity clue, not a facility map

Address records create another tempting shortcut. The 2021 RDAP data associates PT Cloud Four Cee Services with Revenue Tower in Jakarta's Sudirman Central Business District. Cloud4C's current global contact page instead lists the Indonesian entity at Intiland Tower, also on Jalan Jenderal Sudirman in Central Jakarta. The difference may simply reflect an office move or a lagging network contact record. It is evidence that administrative details should be refreshed; it is not evidence of a data-centre move.

Neither office address should be treated as the location of production racks. Corporate offices can hold sales, account management, engineering or administrative teams while equipment sits in a carrier-neutral data centre, a hyperscale region, a partner site or a customer facility. Even a registered abuse or technical contact address says where a responsible person or entity can be reached, not where packets terminate or disks spin.

This distinction is especially important in a city where commercial addresses and data-centre campuses can both be described simply as "Jakarta". The operational questions require facility-level precision: the legal operator of each site; the building or campus; the suite or cage responsibility; the power feeds available to the contracted service; generator and fuel arrangements; cross-connect ownership; carrier entrances; remote-hands terms; hardware sparing; and the distance and failure independence between production and recovery environments.

A provider may reasonably keep detailed layouts confidential. Security does not, however, require the customer to accept a blank. A due-diligence pack can identify facilities under confidentiality, describe control boundaries, provide relevant certifications, state the service's actual placement and document which facts are independently audited. Without that material, a Jakarta contact address demonstrates local corporate presence, not local hosted capacity.

Cloud4C markets a much broader service than this ASN can show

Cloud4C's public proposition is not limited to operating one Indonesian autonomous system. Its cloud-services page presents the company as an end-to-end managed cloud provider, promising migration, automation, performance management and centralised visibility. Its Indonesian private-cloud page describes compute, storage and networking, local hosting zones, backup and recovery, and the option to host an SAP community cloud in Cloud4C private data centres or on platforms such as Microsoft Azure, AWS, Google Cloud and Oracle.

This hybrid delivery language explains why AS147158 cannot be used as a census of everything the Indonesian company may manage. A workload on AWS can use AWS-originated addresses. A managed Azure environment can sit on Microsoft's network. A private installation at a customer site can use the customer's connectivity. A partner data centre may supply transit and IP space. Cloud4C may provide operations, security and application management while another organisation controls the physical host and route origin.

The same breadth creates a procurement problem. "Cloud4C service" can describe materially different dependency structures. One customer may buy virtual machines on provider-controlled private infrastructure. Another may buy managed operations for its own public-cloud account. A third may buy disaster recovery across several environments. A fourth may buy application support whose main physical dependencies belong to a hyperscaler. Group-level scale, staffing or availability claims do not automatically flow into every Indonesian statement of work.

Cloud4C's Indonesian infrastructure-modernisation page advertises a four-way disaster-recovery architecture, round-the-clock support and a single service-level agreement. The private-cloud page advertises 99.95 per cent availability and deployment across multiple data-centre locations. These are consequential promises, but they remain marketing claims until attached to a defined service. A customer needs to know which architecture applies to its workload, which components are included in the availability calculation, which exclusions apply, where the four copies or recovery positions reside, and who can act when a third-party platform is the pacing dependency.

The sensible conclusion is neither to dismiss the product pages nor to treat them as measurements. They establish what the supplier offers and therefore what it should be able to specify. They do not prove that AS147158 currently fronts that offer, that a certain amount of Indonesian compute is installed, or that a particular customer receives the advertised topology.

Hosted capacity has several denominators

Cloud capacity sounds like a number, but it is a stack of denominators. A provider can have space contracted in a data centre without racks installed. It can have racks installed without servers delivered. It can have servers powered without enough storage, licences or network ports to sell the resulting capacity. It can have resources provisioned but reserved for existing customers or recovery. It can have a technical surplus that support staffing or commercial commitments make unavailable to a new buyer.

For PT Cloud Four Cee Services, the public evidence examined here supplies none of the quantities needed to calculate customer-available Indonesian capacity. There is no verified rack count, power allocation, server inventory, storage tier, usable core count, available memory, committed bandwidth, oversubscription policy or free headroom. The active registration for an IPv4 /23 indicates stewardship of up to 512 addresses in that block, before reservation and operational use are considered, but addresses are not processors, disks or kilowatts. At present, the AS is not even observed originating that block.

A serious capacity statement should separate at least five stages. Design capacity is what an architecture could support. Contracted capacity is what the provider has rights to use. Installed capacity is equipment physically in place. Lit capacity is installed equipment with power, network and software ready. Customer-available capacity is the portion that can be committed without consuming protected recovery headroom or breaching existing obligations. Only the last category answers a new customer's immediate question, and only tested recovery capacity answers the follow-on question of what remains after a site or supplier failure.

Economics further complicate the picture. Managed-cloud providers can avoid heavy capital spending by leasing space, using hyperscalers and buying hardware as demand arrives. That flexibility can be efficient. It also moves critical dependencies into facility contracts, cloud commitments, licence terms, supplier credit, spare-part lead times and support entitlements. The customer is buying an operating system of contracts as much as an operating system of software.

This is why a dormant or externally invisible AS deserves attention even when it does not imply a dormant business. If customer services now rely mainly on third-party clouds or provider networks, the decisive capacity lies in quotas, reservations, tenancy design, account control and escalation rights. The customer should examine those dependencies directly rather than asking AS147158 to answer a question it no longer appears to answer.

The physical service boundary has to be drawn

Every cloud service becomes physical somewhere. Virtual machines execute on servers. Storage replicas occupy devices. Network overlays cross switches and fibres. Identity systems depend on databases and keys. Support staff need consoles, credentials and communications. The useful diligence question is not whether the cloud is physical, but which party owns or controls each physical and operational layer.

The provider should be able to draw a responsibility map for the contracted service. At the bottom are site operator, power, cooling, fire suppression, physical security and access. Above that are racks, cabling, network devices, servers and storage. Above those sit virtualisation, orchestration, backup, monitoring, identity, security tooling and the application stack. Connectivity cuts across every layer through cross-connects, local loops, upstream transit, peering, DNS and customer access circuits.

Cloud4C's managed SD-WAN page illustrates the breadth of this boundary by describing centrally hosted orchestration, edge components, optimisation and security. Its Desktop as a Service page describes virtual desktops, data held in cloud data centres, round-the-clock monitoring and built-in backup and recovery. Each offer combines several ownership domains. A desktop session can fail because compute is unavailable, because identity is down, because a customer's access circuit is broken, because an orchestration service is unreachable or because the support team lacks authority to change a supplier-controlled component.

Without a responsibility map, "end to end" can conceal handoffs rather than eliminate them. A single invoice may improve accountability, but it does not give the provider physical control over every dependency. A single service-level agreement may simplify remedies, but a credit after an outage is not the same as a repair path during one. Buyers need both commercial simplicity and operational specificity.

AS147158 would ordinarily help locate one part of that boundary: the public route origin. Its current absence means the customer should identify the actual origins and networks used by each service component. The answer may be entirely reasonable. What matters is that it is explicit, current and tied to the architecture the customer will receive.

Seven failure paths matter more than the service label

The first failure path is the facility. A rack loses utility power, a power distribution unit trips, cooling degrades, a fire-suppression event closes a room, or physical access is delayed. A high-level claim of multiple sites is useful only if the customer's workload is actually distributed across them and the sites do not share the same critical utility, campus risk or operations bottleneck. The recovery question is not "Do you have another data centre?" but "Can this workload run there now, at the required scale, with its data and dependencies intact?"

The second path is routing and upstream connectivity. A route can be withdrawn, filtered, leaked or hijacked. A carrier can suffer a fibre break or control-plane event. A nominally diverse pair of circuits can share a duct or upstream. The historical policy for AS147158 names AS58369, but the current routing view observes no neighbour at all. That does not show a failed contract; it shows that the old registry declaration is not current proof of usable transit. The buyer should request actual path diversity for the service addresses, including the origin AS, upstreams, physical entrances and failover behaviour.

The third path is hardware and storage. A provider may have enough aggregate equipment yet lack the correct drive, controller, memory module, network card or licensed appliance needed to restore one workload. Spare stock, supplier lead time, firmware compatibility and hands-on access determine repair time. Replication protects against some device failures but can copy corruption, deletion or malicious changes. Backups protect a different failure set, and only restore tests show whether they are usable.

The fourth path is the control plane. A functioning server is of limited use if administrators cannot authenticate, orchestration cannot place workloads, keys are inaccessible, DNS cannot be changed or monitoring has lost sight of the environment. Cloud4C's public materials emphasise automation and central visibility. Those features can accelerate recovery, but they also create shared services whose own resilience and access controls need examination.

The fifth path is support. An incident can outlast the technical fault when the first-line desk cannot reach the facility, the carrier, the cloud platform or the engineer with change authority. Round-the-clock support is not the same as round-the-clock repair authority. Customers should know where the responding team is, which languages and escalation windows apply, how severity is set, when a senior engineer takes ownership, and whether the provider has a sufficiently strong support plan with each upstream supplier.

The sixth path is billing and contract control. Public-cloud accounts can be suspended, quotas can block recovery, licences can expire and disputed invoices can interrupt services. A reseller or managed provider may control subscriptions the customer needs during migration. Contract termination can turn an operational dependency into an immediate data-access problem. These risks are less visible than a broken fibre but can produce the same outcome: the workload is unreachable and the customer cannot fix it alone.

The seventh path is migration. A service can remain technically healthy while the customer discovers that exporting data is slow, expensive, incomplete or dependent on proprietary formats. The exit path also needs network capacity, credentials, staff time and a receiving environment. If the service is addressed from provider-controlled space, renumbering and DNS changes may be part of the move. A portability test belongs in resilience planning because a failed supplier relationship can be as consequential as a failed rack.

Redundancy must be proved at workload level

Cloud4C's product pages describe backup, replication, automatic recovery and multi-location deployment. Those are the right concepts. The missing link is workload-level evidence for PT Cloud Four Cee Services' Indonesian offer. A buyer should seek a topology that distinguishes production, high-availability and disaster-recovery components. It should show where data is synchronously or asynchronously replicated, which failure domains are independent, and which steps still require human approval.

The test results matter more than the diagram. A recent exercise should state when the test occurred, what was deliberately failed, how detection worked, which team declared the event, how traffic or users moved, how long service restoration took, how much data was lost or replayed, and what broke after the main workload returned. A restore into an isolated environment tests something different from a site failover. A route withdrawal tests something different from a storage corruption. A support drill tests something different from both.

Capacity during recovery is another frequent blind spot. Four locations do not provide four useful recovery positions if they are full, if the customer's data is absent, if licences cannot be activated or if network paths cannot carry the shifted load. Providers should identify protected headroom and explain whether it is reserved, pooled or obtained on demand. Customers should ask what happens when several tenants invoke recovery after the same regional event.

The public absence of AS147158 can be incorporated into such a test rather than treated only as a deficiency. If the service does not depend on the AS, the provider can demonstrate the actual path. If the AS is retained for failover, a controlled exercise can demonstrate that routes can be originated, accepted and validated when needed. If addresses have moved permanently, the architecture and registry records can be brought into alignment. Each outcome turns ambiguity into operational knowledge.

Routing security starts after there is a route

Indonesia's routing-security environment has strengthened. APNIC's account of Indonesia's RPKI progress reported rapid growth in Route Origin Authorisation coverage, while its later report from APRICOT 2026 in Jakarta described IDNIC and the Indonesian Internet Exchange moving towards a "secure first" baseline for new peers. APNIC explains that RPKI binds number resources to cryptographic authority and lets holders specify which AS may originate a prefix.

That context raises the standard for any future return of AS147158 to public routing. The holder should maintain appropriate Route Origin Authorisations, ensure the prefix length is covered, test that upstreams accept valid announcements and avoid leaving stale authorisations that widen the set of plausible origins. Route-origin validation addresses whether an origin is authorised. It does not prove that the route is stable, that the path is diverse or that the service behind it is secure.

At present, there is no current AS147158 route in the examined data to validate. An empty validation result should not be described as invalid routing; it means there is no observed announcement in scope. If the company's services use another origin, the relevant RPKI and path assessment belongs to that origin and those prefixes. Again, the service architecture must identify them.

The historical visibility also makes record hygiene important. Contacts, routing policy and authorisations should reflect the intended operational state. Stale data can slow incident coordination or mislead counterparties. Fresh registration data cannot create capacity, but it reduces uncertainty about who can act when routing changes.

Data locality is a property of the service, not the corporate address

Cloud4C's Indonesian private-cloud material puts considerable emphasis on local hosting, compliance and data-residency needs. This is commercially relevant in Indonesia, but locality has to be specified with more precision than a country flag. Data can exist in primary storage, replicas, backups, logs, monitoring systems, support tools, key-management systems and temporary migration stores. Each copy can have a different location and operator.

Indonesia's Government Regulation No. 71 of 2019 distinguishes public-scope and private-scope electronic system operators. Among other provisions, it requires public-scope operators to manage, process or store their systems and electronic data in Indonesia subject to a stated exception, while private-scope operators may use Indonesia or locations abroad provided that oversight and law-enforcement effectiveness can be ensured. Sector-specific rules and the nature of the customer can add further obligations, so a slogan about sovereignty is not a substitute for legal and technical mapping.

For a buyer, the practical questions are concrete. Which datasets must remain in Indonesia? Where is the primary copy? Where are replicas and backups? Can support staff outside Indonesia access content or metadata? Which legal entities act as processors or subcontractors? Which cloud account and encryption keys control the data? What happens to copies after termination? The official private electronic-system registration portal also underscores that operating an electronic system is a regulated activity, distinct from holding an ASN.

AS147158's country code and Jakarta contacts do not answer any of those questions. IP geolocation and ASN registration are particularly poor proxies for storage location in a hybrid environment. A workload can be managed by an Indonesian company while running abroad, or use an overseas-owned platform located in Indonesia. A local IP endpoint can front data stored elsewhere. A foreign origin can reach a local private connection. Data sovereignty therefore belongs in the service schedule, architecture and audit evidence.

The public absence of current routes makes that discipline even more important. If Cloud4C's Indonesian services are delivered chiefly through hyperscalers or partners, the locality statement should name the relevant region, facility class and cross-border support arrangement. If PT Cloud Four Cee Services operates private Indonesian capacity not visible under its own AS, the provider can disclose the actual network and facility boundaries under suitable confidentiality. Either answer is more useful than inferring locality from IDNIC-CLOUD4C-AS-ID.

Who carries the impact when a hidden dependency fails

Cloud4C's customer proposition is enterprise-oriented. Its public pages refer to application modernisation, SAP environments, virtual desktops, databases, security operations and managed cloud. When these systems fail, the first affected party may be an IT administrator, but the effects can spread to employees unable to log in, customers unable to transact, finance teams unable to close books, warehouses unable to process orders, or security teams unable to see events.

The impact depends less on the provider's corporate scale than on what one customer has concentrated in the service. A small Indonesian route footprint could once have supported a narrow but critical management endpoint. A workload using no PT Cloud Four Cee Services address space could still depend heavily on the company's engineers and control systems. Route visibility is therefore one signal in a larger dependency analysis.

Customers should classify services by tolerable outage and tolerable data loss, then test the supplier architecture against those thresholds. A recovery time objective is not useful if DNS, identity or a customer access circuit takes longer. A recovery point objective is not useful if the restored database cannot reconcile with transactions held elsewhere. A support target is not useful if it measures first response rather than restoration. Contract language should follow the actual chain of harm.

The provider, for its part, benefits from specificity. It can avoid having group-level marketing interpreted as an unlimited promise. It can distinguish services hosted on its private infrastructure from services managed on a customer's hyperscaler account. It can state which recovery options are included and which require separate capacity. It can identify where PT Cloud Four Cee Services has direct control and where it acts as coordinator. Clarity protects both sides during an incident.

The evidence a buyer should request

The first request should be a service-specific architecture, dated and versioned. It should identify production and recovery locations, the legal and operational site owners, actual route origins, address ownership, upstream networks, DNS responsibility, cloud accounts, storage replication, backup repositories, identity dependencies and monitoring. It should mark customer-managed components and subcontractors rather than presenting the service as one undifferentiated box.

The second should be a capacity statement. It should separate installed, lit, committed, available and recovery-reserved resources. For public-cloud delivery, it should identify reservations, quotas and account ownership. For private infrastructure, it should identify compute, memory, storage performance, usable storage after protection, network limits, power constraints and hardware replacement arrangements. The date matters because available capacity changes.

The third should be current network proof. That can include the service prefixes and origin ASNs, live looking-glass or monitoring evidence, upstream diversity, route-origin authorisations and a recent failover result. If AS147158 is not part of the customer path, the supplier should simply say so and identify what is. If it is intended as a standby origin, the supplier should show that the standby path has been exercised.

The fourth should be recovery evidence. Customers should ask for restore and failover reports relevant to their architecture, including observed recovery time, observed data loss, unresolved findings and the date of the next exercise. A certificate or generic business-continuity policy can support governance, but it cannot replace a workload test.

The fifth should be the support and supplier matrix. It should name the team that responds, the escalation route, the authority available at each level, the facility and carrier support entitlements, and the communication cadence during a major incident. It should also describe what happens if the supplier itself cannot access a third-party account or site.

The sixth should be a data-location and access schedule. That schedule should cover primary data, replicas, backups, logs, support access, subprocessors, encryption keys, deletion and legal jurisdiction. It should match the actual technical topology rather than relying on the Indonesian identity of the contracting company.

The seventh should be an exit rehearsal. A sample workload or data set should be exported, integrity-checked and restored or imported into a receiving environment. The exercise should measure time, egress cost, format compatibility, credential transfer, address changes and the assistance the provider must supply. A customer who can leave is also better prepared to recover from a severe supplier failure.

What the public signals suggest, and what they cannot prove

The combined public signals suggest that PT Cloud Four Cee Services is a genuine Indonesian corporate and number-resource presence within the wider Cloud4C business. The matching company name across the ASN record and Cloud4C contact page is stronger than a stray brand reference. The registered /23 and the 2021-to-2023 route history show that the number resources were not merely hypothetical paperwork at the beginning of the period.

The signals also suggest a material change after December 2023. The named AS no longer appears in the current route views, its historical registered upstream relationship is not observed, and independent AS Rank data does not see a prefix or adjacency. This is not the pattern of a small but currently visible standalone network. It is the pattern of a registered network whose present public operating role is unproved.

What the signals cannot prove is why. They cannot show whether a platform moved, whether customers were migrated, whether services now use public-cloud networks, whether a partner originates the addresses, whether the company retains private capacity, whether a contract ended, or whether the AS is being held for future use. They cannot establish a current outage. They cannot establish the absence of customers. They cannot measure the company's support organisation or financial capacity.

They also cannot turn Cloud4C's broad marketing claims into local asset facts. A statement about multiple locations does not identify the Indonesian workload's sites. A global virtual-machine count does not reveal capacity available to PT Cloud Four Cee Services customers. A promise of local hosting does not name where every copy of data resides. A single SLA does not prove that every supplier obligation is aligned behind it.

The gap is resolvable. A refreshed network record, a current service architecture and a few recent operational test results would answer much of it. Until those arrive, the honest interpretation is deliberately bounded: the company and its resources are identifiable; the historical routing is observable; current AS147158 route visibility and AS-level hosted capacity are not.

What to watch next

The clearest public change would be a new route announcement from AS147158. If one appears, observers should record the prefix, first-seen time, upstream paths, visibility across collectors and RPKI state. A route returning briefly through one upstream would mean something different from a stable, widely visible, authorised prefix with diverse paths. The reappearance would establish current routing, not by itself establish customer compute.

A second signal would be refreshed registry data. Updated contacts, policy, maintenance entities or address details could show that the holder is actively maintaining the resource. If the AS is intentionally dormant, a public explanation or clearly updated corporate architecture would prevent the old policy from being mistaken for a live topology.

A third would be a maintained interconnection profile. The PeeringDB API query for AS147158 did not return a current network entity in the supplied research, and a PeeringDB search is therefore a useful periodic check rather than present proof. A future profile could disclose traffic policy, facilities or exchange participation, though self-published directory data would still need operational corroboration.

A fourth would be greater specificity on Cloud4C's Indonesian site. Naming production regions, service boundaries, recovery locations or relevant local certifications would narrow the distance between a general product and PT Cloud Four Cee Services' deliverable. The strongest disclosure would distinguish provider-owned private capacity from capacity managed on hyperscalers and from customer-premises deployments.

Customers need not wait for all of these facts to become public. They can request them under confidentiality and write the verified architecture into the contract. Public evidence is most useful as a way to ask better questions and detect change. It is not a substitute for access to the service's actual design.

A narrow conclusion is the strongest one available

PT Cloud Four Cee Services has more than a name on a generic company page. It has an Indonesian autonomous-system registration, a matching holder label, a registered IPv4 block and a period of historical route visibility. Cloud4C's website also identifies the legal entity as its Indonesian contact and presents a substantial portfolio of managed-cloud, private-cloud and recovery services. These facts establish a credible corporate and resource context.

They do not establish current hosted capacity under AS147158. The route evidence as of 11 July 2026 shows no announced prefixes, no visible neighbours and no collector visibility. CAIDA's independent summary likewise says the AS is not seen and has no cone prefixes or observed degree. The last public route observation reported by RIPEstat is from 19 December 2023.

The missing route is not a verdict on every Cloud4C-managed workload in Indonesia. It is an evidence gap around the specific network identity that public records attach to PT Cloud Four Cee Services. Services may sit on other networks and in other parties' facilities. If so, those networks, facilities and responsibility boundaries are the evidence customers need.

That leaves a practical standard. Do not buy resilience from an AS number, an office address or a global availability claim. Buy a defined placement, measured capacity, diverse paths, tested restoration, empowered support and a rehearsed exit. When PT Cloud Four Cee Services can connect those proofs to a particular Indonesian service, the assessment can move from negative AS-level visibility to a positive account of usable hosted capacity. Until then, the registered resources describe what existed and who held it; they do not prove what is serving customers now.