Summary

  • Cloud Holding International inc is not merely a name attached to an isolated address. LACNIC's 2024 electoral roll lists it among member organisations in Panama, and LACNIC records show three active IPv4 allocations under the name: 190.9.32.0/20, 200.6.152.0/21 and 190.114.0.0/19. Together they contain 14,336 addresses.
  • The network evidence demonstrates address control and current use, but not a self-contained cloud. At the July 15, 2026 observation, the two large aggregates and several portions of the /19 were originated by AS49915. RIPEstat identifies that ASN with Megaport (UK) Limited, making a supplier boundary visible in the public route.
  • The strongest public bridge to a commercial offer is G-Conex. A February 2026 third-party observation associated gconex.net, its address 190.9.39.16 and G-Conex-branded name servers with Cloud Holding International, while describing cloud computing, corporate email, Exchange and virtual private network services. That supports a brand-and-service connection, but it is not a current contract, service inventory or performance record.
  • Buyers should require a corporate certificate, a brand-to-company statement, an exact facility and subprocessor schedule, an address and ASN map, service-level terms, recovery evidence and named support escalation. Until those pieces are joined, the public footprint is evidence of network-resource stewardship, not proof that a particular workload will be available, recoverable, local or well supported.

A resource holder is visible before a cloud operator is

Cloud due diligence often begins in the wrong place. A buyer finds a product name, a website and perhaps an IP address, then assumes they describe one operator. In practice, the party on the contract may differ from the brand on the service portal, the organisation named in an address registry, the network originating the route and the company employing the person who answers an incident. Each identity can be legitimate. Reliability depends on knowing how they connect.

Cloud Holding International presents this problem in unusually clear form. The BTW directory entry identifies a Panama organisation and lists managed network, cloud, data-centre, colocation and hosting services, but marks those service assertions as not yet assessed. That is an appropriate starting boundary. A directory entry tells a reader what organisation is under examination; it does not make the service claims true.

The independent public identity evidence begins at LACNIC. The regional internet registry's 2024 electoral roll includes Cloud Holding International inc among organisations in Panama. Its contact entry CHI7 names Cloud Holding International Inc, gives a Panama City address, a Panama telephone number and [email protected], and assigns the contact administrative, technical and abuse roles. LACNIC marked the contact validated and recorded its most recent change in November 2024.

Those facts establish a durable identity inside regional internet administration. They show that the name has participated in the address-governance system, that current contact coordinates were maintained recently enough to avoid being purely historical, and that LACNIC recognises the contact for several network-facing functions. They do not prove incorporation, current corporate good standing, beneficial ownership, directors, authorised signatories, solvency or staff numbers. LACNIC allocates and documents internet resources; it is not Panama's corporate registry or a cloud-service auditor.

The distinction matters because the suffix inc can invite more confidence than the evidence supports. A procurement team needs the exact legal name as it appears on a recent Panama public-registry certificate, the company number, registered office, directors or authorised representatives, and evidence that the person signing the cloud contract can bind that entity. None of those details should be inferred from a network contact whose displayed full name is the company itself. The contact is useful for a routing or abuse matter, but it is not a substitute for a named officer.

The address in the resource record also has a limited meaning. LACNIC gives Plaza Obarrio, Avenida Samuel Lewis in Panama City for the registrant. That is an administrative location. It does not locate a data hall, a customer virtual machine, a backup copy, an operator console or a support shift. A provider can be registered in Panama while delivering workloads from another country; it can also use overseas transit while keeping equipment in Panama. Corporate geography, network geography and data geography need separate evidence.

This leaves a positive but modest identity conclusion. Cloud Holding International has a recognisable Panama-facing presence in LACNIC's public administration of internet resources. It is not an anonymous label invented for one sales page. The record is still one layer of the answer. Before a buyer relies on the company name, the legal identity must be connected to the commercial brand, the invoice, the service desk, the facilities and the suppliers that actually carry the service.

G-Conex is the commercial clue, not the completed identity chain

The public commercial trail points toward G-Conex. A February 2026 observation of gconex.net described the site as a G-Conex offer for cloud computing, business solutions, corporate email, Exchange collaboration and virtual private networks. The same observation placed the site at 190.9.39.16, identified Cloud Holding International inc as the hosting organisation and listed ns1.gconex.com, ns2.gconex.com and several cdns.gconex.net name servers.

That alignment is more useful than a shared word in two company names. The observed website sat inside 190.9.32.0/20, one of the address blocks registered to Cloud Holding International. Its infrastructure used G-Conex-labelled hostnames. The page's captured description presented a coherent business technology catalogue rather than a generic parking page. Taken together, those details support the inference that G-Conex is a customer-facing brand or operating surface associated with Cloud Holding International.

The inference still needs a contractual bridge. The public material reviewed here did not expose a current page saying, in legally precise terms, that G-Conex is a trading name of Cloud Holding International inc, giving the company's registration number and registered address, and specifying which entity enters the agreement. A name-server relationship and an address match can establish technical association. They cannot establish whether the brand is owned by the company, licensed to it, operated by an affiliate or used in a reseller arrangement.

Domain history adds continuity but not legal certainty. Verisign's registry response for GCONEX.COM dates the domain's registration to October 2, 2003, records a July 2025 update and an October 2, 2026 expiry, and lists NS1.GCONEX.COM and NS2.GCONEX.COM. A domain maintained for more than two decades is a stronger commercial clue than a recently registered campaign domain. It says nothing by itself about continuous service quality, present ownership or whether the current registrant is the company under review, because the public response redacts the registrant and identifies only the registrar.

The dates also create a chronology that deserves verification. The G-Conex domain predates the May 2014 creation dates shown on Cloud Holding International's LACNIC registrant entry and contact. That need not indicate a problem. A brand can predate a later company, an address transfer or a change in regional resource administration. It does mean the reader should not casually rewrite the domain's entire history as Cloud Holding International's corporate history. The evidence supports present association more strongly than it supports ownership back to 2003.

At the observation point, attempts from the review environment to negotiate HTTPS with the G-Conex domains did not return a usable company page. That is not enough to declare the sites unavailable to every user: network filtering, server policy, geography or transient conditions can produce the same result. It is enough to explain why the current public terms, support page, privacy notice and service specifications could not be verified from the company-controlled surface in this assessment. The February observation remains a dated description, not a live warranty.

For a buyer, the repair is simple and documentable. The proposal should state: "G-Conex is the trading brand through which Cloud Holding International inc supplies this service," if that is true. It should repeat the exact company number and address from a current corporate certificate, name any affiliate or reseller, identify the merchant receiving payment and say which entity bears service credits, confidentiality, security, data-return and termination duties. A support portal, invoice and contract should use the same identity chain.

Without that statement, the buyer faces an avoidable incident problem. An engineer may open a ticket with G-Conex, finance may pay Cloud Holding International and a network abuse report may go to lacnap.com. If nobody has documented how those names divide responsibility, each channel can be authentic while the customer still loses time finding the accountable party. Brand evidence is therefore relevant, but its value comes from being joined to the legal and operational layers.

The address portfolio is substantial and unusually legible

Cloud Holding International's clearest operating asset is its IPv4 space. LACNIC's record for 190.9.32.0/20 covers 190.9.32.0 through 190.9.47.255, names Cloud Holding International inc as registrant and marks the allocation active. A /20 contains 4,096 addresses. The record also associates the block with origin AS49915 and provides reverse-DNS delegations across its component ranges.

The record for 200.6.152.0/21 does the same for 200.6.152.0 through 200.6.159.255. That /21 contributes another 2,048 addresses. LACNIC again marks the allocation active, names the same Panama registrant and records AS49915 as the origin autonomous system.

A third LACNIC response for 190.114.0.0/19 covers 190.114.0.0 through 190.114.31.255. Its 8,192 addresses bring the three allocations to 14,336 in total. The total is an address count, not a server count. One physical host can use many addresses, many customers can share one address, and unused addresses can remain inside an active allocation. It nevertheless represents a meaningful resource position for a regional cloud or hosting business.

The reverse-DNS material provides a small but current sign of stewardship. For portions of the 190.9.32.0/20 block, LACNIC recorded successful delegation checks in July 2026 against NS1.RDNSPRINCIPAL.COM and NS2.RDNSPRINCIPAL.COM. This shows that at least part of the reverse namespace was delegated and answering authoritatively when LACNIC checked it. Reverse DNS is operationally relevant for mail reputation, service identification and abuse investigation. It does not identify the servers behind the names or prove that every customer receives accurate records.

The scale should be interpreted in both directions. On one hand, 14,336 addresses are hard to dismiss as a purely nominal footprint. Internet addresses are administered assets with contact, routing and abuse obligations. The records suggest sustained participation, not a provider using one borrowed address behind an unrelated host. On the other hand, address holdings do not describe compute generation, storage durability, hypervisor isolation, backup retention, staff coverage or revenue. They can support several business models, including direct hosting, downstream assignment, network resale and legacy services.

Allocation status is also different from route status. An address block can remain active in a registry while no route carries it to the global internet. Conversely, only parts of a larger block may be advertised. This is visible in the 190.114.0.0/19 allocation. RIPEstat's July 2026 view did not show the /19 as one intact global route. It showed several constituent announcements from AS49915, including 190.114.0.0/22, 190.114.4.0/23, 190.114.6.0/24, 190.114.7.0/24, 190.114.8.0/23, 190.114.11.0/24, 190.114.12.0/24, 190.114.16.0/24 and 190.114.24.0/24 during the July 1 to July 15 window.

That pattern supports current use of portions of the allocation. It also warns against adding the entire /19 to a capacity claim. The unadvertised portions might be reserved, privately used, temporarily withdrawn, routed through a view not captured by the service or unused. The public route record cannot choose among those explanations. A buyer should ask which exact prefixes support the purchased service and which facility, provider and mitigation policy applies to each.

Address reputation creates another operating obligation. A large hosting range can accumulate customer-generated complaints, stale reverse names or block-list history even when the provider itself acts responsibly. The evidence here does not support a general claim about Cloud Holding International's abuse rate, and isolated reports would be a poor proxy for a diverse range. What can be assessed is process: an acknowledgement target, escalation path, customer suspension standard, false-positive review, reverse-DNS ownership and evidence that the provider measures time to contain abuse without disrupting innocent tenants.

The useful conclusion is that the address portfolio is genuine, material and partly active. It gives Cloud Holding International more evidential weight than a brand with no identifiable network resources. It also creates questions a mature operator should answer easily: allocation-to-service mapping, utilisation, route authority, upstream dependence, IPv6 strategy, address portability, abuse handling and what happens to a customer's addresses during exit.

The public route exposes a provider boundary

The most important network fact is not the quantity of addresses. It is who announces them. RIPEstat's overview for AS49915 identified the ASN as announced on July 15, 2026 and named its holder as Megaport (UK) Limited. The announced-prefix view included Cloud Holding International's 190.9.32.0/20, 200.6.152.0/21 and multiple routes carved from 190.114.0.0/19 throughout the returned July window.

The BGP state for 190.9.32.0/20 showed 333 collected routes with AS49915 at the origin. The same view for 200.6.152.0/21 showed 332 and the same origin. Sample paths reached AS49915 through large transit networks including AS174 and AS3257. These collector counts are observations, not service-level measurements, but they show that the two aggregates were broadly visible through more than one observed upstream path.

This is real service-proof evidence at the network layer. A customer address cannot receive ordinary internet traffic unless a route reaches it. The observations show that company-registered space was not sitting entirely dormant and that the current origin matched the origin ASN stated in the two LACNIC records. They also make clear that Cloud Holding International was not presenting those aggregates through an ASN publicly attributed to its own name.

That difference should not be framed as a defect. Managed connectivity is normal. A provider may use Megaport for virtual connectivity, route origination, transit access or a broader managed-network arrangement while retaining responsibility to its customers. Public BGP cannot reveal the commercial contract. It can reveal a dependency that needs to appear in the service design and recovery plan.

The dependency has several practical dimensions. Who controls route announcements and withdrawals? Who can change filters after an address transfer? How is an urgent hijack response authenticated? Does Cloud Holding International have a second path that can originate the prefixes if AS49915 becomes unavailable? Are the sample paths through AS174 and AS3257 deliberate diversity, or do they converge on one logical service before reaching the customer equipment? Which party communicates during a route leak?

The frozen evidence does not answer those questions. It also does not show a Cloud Holding International ASN, a PeeringDB facility inventory, internet-exchange participation, router count or network diagram. It would therefore be unsafe to describe the company as operating an independent backbone. The stronger and fairer description is that it controls a sizeable LACNIC address portfolio whose public reachability is currently delivered through Megaport's AS49915.

Route-origin authorisation improves one part of this picture. RIPEstat's RPKI validation for 190.9.32.0/20 returned valid, naming AS49915 and limiting the authorised length to /20. The validation for 200.6.152.0/21 was also valid, with maximum length /21. Valid authorisations reduce the chance that networks enforcing route-origin validation accept an unauthorised origin for those exact aggregates.

The maximum lengths are also an operational constraint. If a recovery plan requires AS49915 or another provider to announce more-specific /24 routes from those blocks, the current authorisations would not validate those announcements. A planned origin change would require the appropriate authorisation to be changed first. An operator should be able to identify the person who controls that change, the authentication protecting it, the expected completion time and how the team tests the procedure without creating an outage.

RPKI must retain its narrow meaning. A valid route says that the observed ASN is authorised to originate a prefix. It does not certify the Megaport service, a physical circuit, a router configuration, a data centre, a virtual machine, an application or a backup. It cannot tell a customer whether traffic is encrypted, whether the server is patched, whether two carriers share a duct, or whether an engineer will answer at 03:00. Route hygiene is a positive sign, but it is one control among many.

The visible supplier boundary changes the procurement question from "Does Cloud Holding International own addresses?" to "How does Cloud Holding International turn those addresses and its Megaport relationship into a reliable service?" The first question has a strong public answer. The second needs contracts, diagrams, tests and named accountabilities.

A route cannot settle data locality

Cloud services are often sold with geographic shorthand. A Panama company, a Panama address allocation or an IP geolocation label can each be presented as if it answered where customer data resides. None does. The registered organisation, route origin, server location, backup location, operator location and legal access path are separate facts.

LACNIC's country association supports a Panama administrative connection. It does not place equipment at the Plaza Obarrio address. AS49915's UK company name does not place the servers in the United Kingdom. BGP paths through AS174 or AS3257 describe network reachability, not where a storage volume is mounted. Commercial IP-geolocation databases can disagree or lag, particularly when portable address space is used in several facilities.

The G-Conex offer increases the importance of this distinction because virtual private networks, corporate email and Exchange-style collaboration can hold sensitive messages, credentials, address books and business documents. A cloud platform can add databases, backups, machine images and administrator logs. For each category, a customer needs to know the primary processing country, replication country, backup country, support-access country and the entity acting as processor or subprocessor.

The public evidence examined here did not provide a current facility list, data-processing agreement, subprocessor list, replication map or data-return schedule. It therefore cannot support a claim that workloads remain in Panama, in the United States, in Latin America or anywhere else. It also cannot support a claim that Megaport stores the customer's content; a network provider may carry traffic without administering the hosted application. Supplier role must be established, not guessed from the route.

A useful locality schedule is workload-specific. It names the service and data class; the primary and recovery facilities; the legal entity operating each facility; the country from which privileged support can connect; the encryption and key-control arrangement; the retention period; and the deletion evidence supplied at exit. If the provider can move a workload during maintenance or disaster recovery, the schedule should say where and under what notice.

Network evidence can then verify part of the schedule. The customer can compare assigned addresses with the declared prefixes, observe routes, measure latency from relevant locations and inspect reverse DNS. These checks can identify an unexplained move or a supplier change. They cannot prove disk location or exclude hidden copies. Technical observation and contract disclosure are complementary.

This matters for performance as well as regulation. A business in Panama may accept a remote backup but require the primary system nearby for latency. Another customer may accept remote compute while requiring support access to remain within a defined jurisdiction. A third may care most about restore time and choose two countries deliberately. "Cloud" is not one locality decision. It is a set of placement and access decisions that should be visible at the level where failure affects the customer.

Cloud Holding International's public address evidence is valuable because it gives a customer something concrete to test. It does not complete the locality case. Until the company supplies an exact facility and supplier schedule, country labels attached to the company or its addresses should be treated as administrative clues rather than residency guarantees.

Service categories need control evidence

The G-Conex description names plausible business services: cloud computing, corporate email, Exchange collaboration and virtual private networking. Each can be delivered well. Each also fails in a different way, and a category name says little about the controls that determine the outcome.

For compute, a buyer needs to know the virtualisation platform, tenancy boundary, host-maintenance process, capacity policy, image provenance and recovery method. For storage, the decisive details include redundancy domain, snapshot schedule, independent backup, immutability, restore testing and who can delete copies. For corporate email, mail-flow redundancy, anti-abuse controls, mailbox backup, identity recovery and domain administration matter more than the word Exchange. For a VPN, authentication, key rotation, gateway diversity, logging and an emergency access path are central.

The public material did not expose those controls. Nor did it provide current plan limits, prices, software versions, service credits, certification scope or measured availability. That does not establish that the controls are absent. It means a buyer cannot treat the service labels as evidence that they are present.

Automation deserves particular care. A regional provider may offer a portal, scripts or managed operations that reduce manual work. The value depends on control ownership. Who can provision a machine, reset a password, restore a snapshot, change a firewall rule, rotate a VPN key or export an audit log? Are those actions available to the customer, performed by support or dependent on an upstream platform? Is there a documented API, role model and event history?

These questions connect directly to incident recovery. A service can be reachable while its control plane is unavailable. A customer that cannot change DNS, recover an administrator account or restore a backup is not operationally in control. The public routing evidence proves reachability for address space at one layer; it does not prove that G-Conex or Cloud Holding International can perform the application and platform actions a customer will need under pressure.

A short evaluation can turn marketing categories into service proof. Provision a representative workload. Rebuild it from an approved image. Restrict administrative roles and test separation. Take a backup, delete a non-production instance and perform a timed restore. Rotate a VPN credential without a full outage. Export the relevant logs. Trigger a support escalation outside the local business day. Record who performs each action, which supplier interface appears and how long the state change takes.

The point is not to demand hyperscale tooling from every regional provider. Smaller operators can deliver excellent service precisely because experienced people understand a customer's environment. Human expertise becomes assurance when it is named, available, repeatable and supported by records. A promise that "our team handles it" is weaker than a runbook exercised with the customer and tied to response and restoration targets.

The test should also expose supplier boundaries. If a route change requires Megaport, a mail recovery requires a software vendor or a failed host requires a facility technician, the customer should see how Cloud Holding International coordinates those parties. The provider remains valuable as the accountable integrator, but only if its contract and incident process make that role explicit.

Service categories are therefore the beginning of diligence, not the conclusion. The G-Conex material provides a credible outline of what may be sold. Evidence of provisioning, isolation, backup, recovery, identity and audit control is what turns that outline into an operating service.

Support is the missing link between a footprint and an outcome

Cloud infrastructure becomes most legible when it breaks. The customer discovers whether a portal, network contact, commercial account manager and on-call engineer are parts of one service or separate channels with no shared owner. Cloud Holding International's public material identifies a network operations and abuse contact. It does not establish a customer-support organisation.

The distinction protects both parties. The [email protected] address in LACNIC's CHI7 record is intended for network administration, technical coordination and abuse. It may be monitored by capable staff. Its existence does not promise a response time for a failed virtual machine, a locked mailbox or an urgent restore. Publishing a telephone number also does not show hours, languages, escalation levels or authority to make a service decision.

The G-Conex service description implies a customer relationship, but the frozen public material did not expose a current support schedule, severity definition, acknowledgement target, restoration target or service-credit method. A claim of continuous support would need more than a contact form. It needs an on-call design: who receives the alert, what constitutes severity one, when the duty manager is paged, how suppliers are engaged and how the customer receives updates.

Local support is often a regional provider's strongest advantage. A team in the customer's time zone can understand business context, communicate in the customer's language and coordinate an application problem across hosting, connectivity and identity. Those advantages depend on labour that remains largely invisible in the public footprint. The company should name the support location, coverage window, minimum roles on call, handover method and escalation owner without exposing personal details.

Staffing claims should remain proportionate. A small team can provide dependable support with disciplined rotation and good supplier coverage; a larger team can still fail through unclear ownership. Buyers should ask for the operating model rather than an unverified employee count. Useful evidence includes anonymised duty rosters, recent response and restore distributions by severity, a sample incident report, exercise records and references from customers using comparable services.

The contract should distinguish response from restoration. A fast acknowledgement may only confirm that a ticket exists. Restoration may depend on diagnosis, replacement hardware, a route change, a backup or a customer decision. Targets should specify the measured clock, exclusions, update cadence, escalation threshold and remedy. Where no restoration commitment is possible, the provider should at least commit to communications and the work it controls.

Supplier escalation belongs in the same document. Because AS49915 originates the visible routes, a routing incident may cross the Megaport boundary. That does not mean a Cloud Holding International customer should be told to contact Megaport. The contracted provider should own the case, authenticate the request, coordinate the supplier and report progress. Similar logic applies to facilities, software licences, domain registrars and backup platforms.

Exit is another support event. A customer needs time and assistance to export data, move addresses or DNS, recover encryption keys, obtain final logs and verify deletion. If a customer uses provider-assigned addresses, the migration plan must account for renumbering. If the company permits portable customer space, the route and authorisation change process must be rehearsed. Exit terms reveal whether the provider has designed for customer control or only for onboarding.

The public footprint cannot demonstrate these support outcomes. It can make them easier to ask about. The company name, addresses, current origin ASN and technical contact give a buyer a map of the parties likely to appear during an incident. A mature proposal should turn that map into one accountable chain.

What a buyer should verify before production use

Cloud Holding International merits further diligence rather than dismissal. The LACNIC evidence is too substantial for the company to be treated as an untraceable cloud label. The missing assurance is also too significant for address ownership to carry the purchase decision. A focused evidence request can resolve much of the gap.

First, establish identity. Obtain a recent Panama corporate certificate showing the exact legal name, number, status, registered office and authorised representatives. Ask for a signed statement connecting Cloud Holding International inc, G-Conex, gconex.com, gconex.net, lacnap.com and the billing entity. Reconcile those names across the contract, invoice, privacy terms, support portal and domain contacts.

Second, map the service. Identify the exact compute, storage, email, VPN, colocation or managed-network components being purchased. For each, name the company that operates it, the facility, the country, the upstream platform and the party with administrative access. The map should distinguish Cloud Holding International's own assets from leased capacity and managed supplier services without treating either model as inherently inferior.

Third, map the network. Record the customer prefixes, origin ASN, normal transit paths, failover path, route-filter ownership, denial-of-service response and RPKI change authority. Explain why AS49915 is the current origin and what customer-visible obligation Cloud Holding International has if that service fails. Demonstrate a controlled route or connectivity failover where the design permits one.

Fourth, establish locality. Provide the primary, replica, backup, log and support-access locations for each data class. Name subprocessors and explain cross-border transfer and government-request handling where relevant. State whether Cloud Holding International can relocate processing without customer approval or notice. Do not use an IP geolocation screenshot as the sole evidence.

Fifth, prove recovery. Agree recovery-point and recovery-time objectives, then restore a representative workload from the same backup path intended for production. Record elapsed time, missing dependencies, operator steps and customer decisions. Verify that backup deletion requires appropriate authority and that a production credential compromise cannot silently remove every recovery copy.

Sixth, test support. Open tickets at several severities, including outside ordinary business hours. Verify acknowledgement, identity checks, technical competence, escalation and update cadence. Ask who owns a Megaport routing case, a facility power case, a domain case and a mail-delivery case. The answer should be a role and process, not a request for the customer to navigate the provider's suppliers.

Seventh, test customer control. Provision and decommission a service, change an access role, rotate a VPN credential, export logs, retrieve data in a documented format and run an exit exercise. Confirm which actions are self-service, which require support and which depend on a third party. Measure them against the business's actual operating window.

Eighth, define evidence maintenance. Corporate certificates age, contacts change, routes move and service locations evolve. The provider should commit to notifying the customer of material changes and refreshing the facility, supplier, contact and control schedules at an agreed interval. The July 2026 routing picture should not be presumed permanent merely because it is well supported at this observation point.

These requests are not a demand for public disclosure of security-sensitive diagrams or customer information. Evidence can be shared under confidentiality, redacted to protect individuals and scoped to the purchased service. What matters is that the buyer can distinguish a tested control from a general assurance.

The likely outcome may be favourable. Cloud Holding International could have a capable regional operation, a deliberate Megaport design, experienced support and well-controlled G-Conex services that are simply under-documented in public. The current sources cannot confirm that. Good diligence gives the provider a fair way to demonstrate it and gives the customer a record that survives a change of salesperson or engineer.

The right conclusion is narrower than the footprint

Cloud Holding International inc has a real and material internet-resource presence. LACNIC associates the Panama name with 14,336 active IPv4 addresses, recent contact maintenance and regional membership. Current route observations show the two large aggregates and portions of the third allocation in use. Valid route-origin authorisations for 190.9.32.0/20 and 200.6.152.0/21 add a precise positive control.

The same evidence reveals the boundary of that conclusion. Megaport's AS49915 originates the routes. The public G-Conex material identifies service categories but does not establish the full legal bridge, service inventory, facility geography, recovery performance or support model. Registry addresses do not locate customer data, and a valid route does not make a workload recoverable.

That is not a verdict against the provider. It is a rule for reading infrastructure evidence. Address resources prove that there is something concrete to investigate. Operating assurance begins when the company joins those resources to a named service, a controlled supplier chain, tested recovery, explicit locality and accountable people. Until then, 14,336 addresses remain a strong clue, not an SLA.