Summary

  • Global Cloud Ltd is a real RIPE-visible network operator, not merely a directory name. The RIPE organisation object for ORG-GCL12-RIPE names Global Cloud Ltd, gives Israeli registration number 514919729, marks the organisation type as LIR, and lists HaMasik St 4, Emek Hefer, Israel, with the same phone number shown on the company's website.
  • The company is tied to AS61365, whose RIPEstat AS overview labels the holder GC-5222 Global Cloud Ltd and showed the AS as announced at the 2026-07-11 query time. RIPEstat's routing-status view showed four IPv4 prefixes, 1,024 visible IPv4 addresses, no visible IPv6 prefixes and two observed neighbours.
  • The company's address space is not a loose third-party block. The RIPE RDAP prefix record for 185.184.16.0/22 and RIPEstat whois view identify IL-GLOBAL-20170102, country IL, organisation ORG-GCL12-RIPE, status ALLOCATED PA, and a geofeed at geofeed.xprsit.net that maps the /22 and each /24 to Emek Hefer.
  • Route-origin assurance is better than many small hosted footprints. RIPEstat's RPKI validation responses for 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24 all returned valid under a 185.184.16.0/22 ROA with max length 24.
  • The upstream picture still needs customer testing. The RIPE aut-num object lists policy for AS1680, AS212616 and AS8551, while RIPEstat's ASN-neighbours view showed AS1680 and AS212616 as observed neighbours and its AS-routing consistency view showed AS8551 in whois policy but not in BGP at the query time.
  • The evidence grade is Medium. Public sources strongly support legal identity, network-resource control, current IPv4 reachability and route-origin validation. They do not prove the number of racks, facility ownership, spare-hardware depth, tested multi-site recovery, actual customer workload mix, contractual support response or data-portability limits.

The public record is concrete, but cloud capacity still has to be proved

Global Cloud Ltd deserves a different treatment from shell-like hosting names that appear only in scraped lists. The company has a public network identity, an official website, RIPE LIR status, an Israeli registration number in the RIPE organisation object, a live autonomous system and a registered IPv4 allocation. The RIPE RDAP aut-num record for AS61365 names the AS GC-5222, lists Global Cloud Ltd as an organisation entity, and repeats the HaMasik St 4, Emek Hefer, Israel address. The company's own English home page gives the contact line as Hamasek 4, Emek Hefer Industrial Park, publishes the 072-274-3030 phone number, and describes services around development, storage and security.

That combination makes the company observable enough to analyse. It does not make the service fully auditable from the outside. A customer buying cloud, hosting, virtual desktops or managed service is not only buying an AS number. The buyer is relying on cabinets, circuits, optics, routers, hypervisors, storage, backup jobs, licences, support people, power feeds, access control, billing systems and migration procedures. The public Internet can show that AS61365 is reachable; it cannot show whether a particular customer workload can be restored after a failed storage shelf, a supplier dispute, a power event or a routing change.

The most useful way to read Global Cloud is therefore as a mid-sized infrastructure surface with enough public evidence to avoid speculation and enough missing operational detail to require diligence. The company site's English cloud-services page says it offers data-centre and cloud services, DaaS, PaaS, Infrastructure as a Service, collaboration service, IT service and software service. It also says the support team works 24/7 and that Global Cloud emphasizes security and survivability. Those are relevant service claims. They are not the same as a recoverability test.

The evidence also contains a small but telling editorial clue. Parts of the English cloud page refer to "Xpress Technologies" while the domain, RIPE records and footer refer to Global Cloud. That may be legacy copy, a template remnant, a related brand or a translation artefact; public evidence does not settle it. The customer-risk point is not that the name mismatch proves anything bad. It is that broad cloud claims should be reconciled with current service contracts, current platform diagrams and current support boundaries rather than inferred from old or inconsistent website copy.

For this article, the operating thesis is simple: Global Cloud Ltd has a real Israeli network footprint and a public service catalogue broad enough to create customer dependency. The buyer's job is to verify how much of that catalogue is installed, where it is physically hosted, how the routes fail over, how staff respond after hours, and how workloads leave if the service no longer fits.

AS61365 gives Global Cloud a measurable edge

The strongest company-specific evidence begins with AS61365. RIPEstat's AS overview labels the holder GC-5222 Global Cloud Ltd and showed the AS as announced at 08:00 UTC on 2026-07-11. RIPEstat's routing-status endpoint showed four IPv4 prefixes, 1,024 IPv4 addresses, no IPv6 prefixes, 326 of 327 IPv4 RIS full-feed peers seeing the route, and zero IPv6 visibility. The four current announced prefixes in the announced-prefixes response were 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24.

That is a meaningful routed edge. It is also not a hyperscale footprint. A /22 broken into four /24 announcements can support customer services, hosted platforms, VPNs, mail, desktop services, management networks, static access customers or a mix of uses. It does not by itself prove a large public cloud estate. The number of announced IPv4 addresses is not the number of servers, virtual machines, tenants, backup repositories or restore targets. The absence of visible IPv6 in RIPEstat also matters because IPv6 readiness is now part of many buyers' network planning, even when the immediate service can run over IPv4.

RIPEstat's prefix-count endpoint adds useful history. It shows Global Cloud's current pattern of four IPv4 prefixes after earlier visibility changes and no IPv6 prefix count through the 2026-07-11 query window. The routing-history endpoint shows older AS61365 visibility for 94.30.220.0/24 in 2012-2014 and then the 185.184.16.0/22 family from 2017 onward. That history is a positive sign at the routing layer: AS61365 is not a one-week experiment.

But route continuity is not service continuity. The move from an older 94.30.220.0/24 history into the 185.184.16.0/22 family may reflect a provider change, service change, address-resource acquisition, customer change or simply the visible record of different prefixes. Public BGP does not explain the business reason. It only shows that the AS has had observed routes at different periods and that the current routed footprint is the four /24s under 185.184.16.0/22.

Customers should therefore treat AS61365 as a strong starting fact and a weak finishing proof. It can justify asking detailed questions. It cannot replace the answers. If Global Cloud sells virtual servers, the buyer needs host and storage architecture. If it sells desktop as a service, the buyer needs user-session capacity, identity dependencies and link performance. If it sells managed applications, the buyer needs operational ownership and backup detail. If it sells IaaS, the buyer needs to know which part of the stack is automated and which part is a manually supported hosting estate.

The /22 allocation supports control, not unlimited scale

The address-space evidence is unusually helpful because it ties the routed prefixes back to Global Cloud rather than a completely unrelated address lessor. The RIPE RDAP prefix record for 185.184.16.0/22 shows the handle 185.184.16.0 - 185.184.19.255, name IL-GLOBAL-20170102, type ALLOCATED PA, country IL, and the Global Cloud organisation entity. The RIPE REST inetnum object repeats the same allocation and adds a geofeed URL. The organisation object shows Global Cloud Ltd as an LIR. That matters because it is a stronger identity position than a small provider merely announcing someone else's block.

The more-specific registry labels add colour without proving customer use. RIPEstat's address-space hierarchy response lists 185.184.16.0/24 as SHVDOM-1-Subnet, 185.184.17.0/24 as SHVDOM-Core-Subnet, 185.184.18.0/24 as LNS-Static-Subent, and 185.184.19.0/24 as SHVDOM-Subnet. Those names suggest internal segmentation and at least one static-access or network-service label. They do not prove what products are sold from each subnet, which customers use them, or whether the labels are current operational descriptions rather than administrative names.

This distinction is central to hosting economics. A provider can own or operate an address allocation and still have limited installed server capacity behind it. A provider can use a /24 for customer static service, another for management or core functions, and another for hosted workloads. A provider can also sell services whose control plane or website sits in a different network. The public address map tells the buyer where to begin, not where every dependency ends.

The company's public website illustrates that point. A simple DNS lookup during research showed globalcloud.me and www.globalcloud.me resolving to 212.29.210.119, and RIPEstat's whois view for 212.29.210.119 places that address inside IL-NETVISION-980831, not inside Global Cloud's 185.184.16.0/22 allocation. That is not unusual. Many providers host their marketing site with another carrier or platform. The point is only that the website endpoint should not be treated as proof of where customer cloud workloads live.

For customers, the right question is therefore not "does Global Cloud have addresses?" It does. The better question is how those addresses are allocated to services, whether customer IP assignments are portable, how reverse DNS and reputation are handled, how renumbering would work, and whether the buyer receives enough notice if Global Cloud changes upstreams, subnet assignments or service platforms.

RPKI is a genuine strength in the current public evidence

Route-origin validation is one of the few public controls where Global Cloud's footprint looks stronger than the low-information baseline. RIPEstat's RPKI validation endpoint returned valid for 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24 when queried against AS61365. Each response pointed to a validating ROA for 185.184.16.0/22, origin AS61365, max length 24. That means the four current /24 announcements fit the published route-origin authorization at the query time.

The technical value is narrow but real. RFC 6811 explains BGP prefix origin validation as a way for a router to determine whether the AS claiming to originate a prefix is authorized by the prefix holder. RPKI does not encrypt packets, prevent all route leaks, prove the path is best, prove a data centre is resilient, or solve application security. It does reduce a class of origin-misannouncement risk when networks enforce validation policies.

For Global Cloud, this matters because the routed footprint is compact. If a provider has four current visible /24s and no visible IPv6, route-origin mistakes can affect a large share of the public service surface. Valid ROAs for the current /24 announcements give customers a better starting position than an unknown or invalid result would. They also show that the address holder and origin relationship has at least one modern routing-security control in place.

The caveat is that RPKI is not a customer SLA. It does not say AS1680, AS212616 or any other transit path has enough capacity to carry traffic after a failure. It does not say the routers are redundant. It does not say DDoS filtering is active. It does not say customer backups are recoverable. It does not even say every operational route object is tidy. RIPEstat's prefix-routing-consistency response showed the aggregate 185.184.16.0/22 route object in whois, 185.184.19.0/24 both in BGP and whois, and the 185.184.16.0/24, 185.184.17.0/24 and 185.184.18.0/24 announcements in BGP without matching whois route objects in that specific consistency view. RIPEstat's AS-routing consistency response presents the same split.

That split is not a crisis because the RPKI state is valid and the aggregate route object exists. It is still useful operational evidence. Customers should ask whether Global Cloud intentionally relies on the aggregate route object plus RPKI for the /24s, whether IRR filters used by upstreams accept the current announcements, and what change-control process protects ROA and route-object updates. A small mismatch in a registry view can become a large incident if an upstream filter, route server or transit provider interprets it differently during maintenance.

The short version: RPKI is a strength. It should be praised as a current control and then placed back in its lane.

Transit diversity is visible, but the failover story is unfinished

The most important operational question is not how many provider names appear in a policy object. It is which paths can carry traffic when one path, router, cross-connect or commercial contract fails. Global Cloud's public records give enough evidence to ask that question precisely.

The RIPE aut-num object for AS61365 includes policy entries for AS1680, AS212616 and AS8551. RIPEstat identifies AS1680 as Cellcom Fixed Line Communication L.P, AS212616 as K.M.A ADVANCED TECHNOLOGIES LTD, and AS8551 as Bezeq International Ltd. Those are serious Israeli network names. The ASN-neighbours endpoint, however, showed two observed neighbours at the latest available query time: AS1680 and AS212616. The AS-routing consistency endpoint showed AS1680 and AS212616 in both BGP and whois, while AS8551 appeared in whois but not BGP at that time.

The path samples sharpen the picture. For 185.184.16.0/24, sampled BGP paths ended with AS1680 AS61365. For 185.184.17.0/24 and 185.184.18.0/24, the dominant visible last-hop pattern also ended with AS1680 AS61365. For 185.184.19.0/24, the visible pattern ended with AS1680 AS212616 AS61365. That is not a full carrier map, and public collectors can miss private or low-visibility sessions. It is still a useful clue: different /24s may take different adjacent or near-adjacent paths, and AS212616 is visible in the route path for at least the 185.184.19.0/24 view.

Customers should not read this as either "single-homed" or "fully redundant" without more evidence. It is better read as "partly visible multihoming or provider-policy complexity." The customer should ask which ASNs are active production transits, which are backups, which are historical, and which carry customer-specific services. The answer should include bandwidth commits, router diversity, physical cross-connect diversity, maintenance windows, DDoS handling, escalation contacts and recent failover tests.

The failure path is concrete. If AS1680 has a regional incident or a routing filter problem, can all four /24s continue through AS212616 or another path? If AS212616 is part of the 185.184.19.0/24 path, what customer service depends on that /24? If AS8551 is in the policy object but not currently visible in BGP, is it a standby session, an inactive historical arrangement, a planned path or a policy artefact? If traffic shifts after a failure, does the provider have enough upstream capacity and clean route preference to avoid packet loss?

Those questions are not accusatory. They are the difference between a service catalogue and an operational design. A hosted provider can honestly sell resilient service from a compact public edge if it has tested routes, spare capacity and clear escalation. It can also sell a broad catalogue from a narrow dependency chain that works well until the first major upstream or rack event. Public data puts Global Cloud somewhere between those conclusions. Direct customer diligence decides which side is closer to reality.

Emek Hefer is a strong locality signal, not a rack certificate

Global Cloud has several overlapping Israeli locality signals. The RIPE organisation object lists HaMasik St 4, 3877701, Emek Hefer, Israel. The RDAP aut-num entity repeats that address. The Global Cloud home page gives Hamasek 4, Emek Hefer Industrial Park, and the same phone number. The geofeed file referenced in the RIPE inetnum object maps 185.184.16.0/22 and each of the four /24s to IL, IL-HA, Emek Hefer.

That is enough to discuss Israel and Emek Hefer as the dominant public location signal for the company and its address space. It is not enough to say every customer workload, backup, log, administrator session or disaster-recovery copy is physically in Emek Hefer. IP registry address, geofeed locality and office contact details do not equal a facility audit. A provider can operate racks in one site, lease capacity in another, use remote backup services, run support tools through cloud platforms, or host some public services on other carriers.

The geolocation evidence also shows why caution is needed. RIPEstat's geoloc view and MaxMind GeoLite view placed the /22 in Israel but at Ar Rayna, not Emek Hefer. That conflict does not disprove the geofeed. IP geolocation databases often differ, and geofeed data can represent operator intent or self-published locality. It does prove that buyers should not use an IP geolocation lookup as a physical placement guarantee.

The locality question matters because Global Cloud's service catalogue includes data-centre, cloud, desktop, platform, software and backup-like services. Israel's official Privacy Protection Authority data-security page describes data-security regulations that apply to private and public sectors and put organizational mechanisms around database security. The same government portal publishes privacy regulation material on data transferred to Israel from the European Economic Area. Those official pages do not tell us which Global Cloud customers handle personal data or whether Global Cloud is a processor in any specific contract. They explain why a buyer cannot leave data locality as a marketing phrase.

For a customer, the practical questions are straightforward. Where are primary workloads hosted? Where are backups stored? Are backups encrypted and tested? Which staff, contractors or vendors can access systems from outside Israel? Are logs, monitoring feeds, support tickets or identity systems processed on foreign platforms? If the customer must show Israeli, EEA or sector-specific data handling, what contractual exhibits and technical controls does Global Cloud provide?

Global Cloud's public evidence supports the Data sovereignty and locality topic because the company has an Israeli network-resource and office footprint and sells cloud-adjacent services. It does not support a blanket compliance claim.

The service catalogue is broad enough to create serious customer dependency

Global Cloud's English cloud page is not limited to a simple web-hosting pitch. It describes data-centre and cloud services, integration between enterprise systems and terminals, ongoing monitoring and maintenance, virtualization on VMware and KVM/XEN/Hyper-V-like platforms, secure Internet connection, secure storage, DaaS, PaaS, Infrastructure as a Service, collaboration service, IT as a Service and Software as a Service. The English hosting page repeats the data-centre and cloud theme and lists hosting, DaaS and telephony service. The about page says in Hebrew that Global Cloud Ltd was founded in 2013 and positions the company around personal service by local experts.

Those claims matter because they put Global Cloud into the dependency layer rather than the commodity domain-name layer. A business using DaaS depends on session brokering, identity, storage, endpoint performance and support. A business using IaaS depends on compute, storage, network, image management and recovery. A business using collaboration or telephony service depends on uptime, call flows, directories, user provisioning and configuration export. A business using managed software depends on patching, backups, access control and change approval.

The public network footprint can support such services, but it does not reveal their installed depth. Four visible /24s can carry a meaningful regional platform, especially for a focused Israeli provider. They can also mask a much smaller estate if services are delivered through third-party platforms or leased capacity. The website's claims of security, survivability and 24/7 support should be converted into measurable commitments: support channels, response times, incident notification, backup frequency, restore time, restore point, data export, customer-side failover and termination assistance.

One practical tension in the website evidence is support timing. The English home page header gives office hours as Sunday through Thursday, 09:00-18:00, with Friday and Saturday closed. The cloud page says the support team works 24/7. There may be a simple explanation: sales office hours differ from technical support coverage. The buyer should make that distinction explicit in the contract. What is staffed 24/7? What is on-call? Which severity level gets immediate response? Which contact path works during a network outage? Is the support portal hosted outside the affected environment?

Who can approve emergency changes after normal office hours?

The service catalogue also creates licensing and platform dependency. The cloud page references VMware, XEN and Microsoft-like infrastructure support. A customer should ask whether its service is dedicated, multi-tenant or subcontracted; whether platform licences are included; whether snapshots are portable; whether virtual-machine images can be exported in standard formats; and whether identity, telephony or collaboration data can be migrated without a long manual project.

The central customer-risk lesson is that Global Cloud's public evidence is credible enough to take seriously. It is also broad enough that the buyer should not accept a single generic "cloud" assurance. Each service in the catalogue has a different failure mode.

Installed capacity and usable capacity can diverge quickly

Cloud buyers often confuse installed capacity with usable capacity. Installed capacity is what a provider has built, leased or configured under normal conditions. Usable capacity is what remains available when something breaks, when a customer grows, when a supplier changes terms, or when a migration has to happen under stress. Global Cloud's visible footprint is large enough for real hosted service and small enough that customers should ask how much spare room exists behind it.

The /22 contains 1,024 IPv4 addresses. Public IPv4 is scarce, and control of a /22 is valuable for a regional hosting provider. But address count is not compute count. If some addresses are used for infrastructure, static customer access, NAT, management, mail, VPN, desktop gateways or network equipment, the public address pool available for new hosted services may be smaller than the raw number suggests. If some services are private-addressed behind gateways, the public address pool may understate compute capacity. Public BGP alone cannot resolve that.

The more-specific subnet labels add to the question. SHVDOM-Core-Subnet sounds like core infrastructure; LNS-Static-Subent suggests a static subscriber or access function; SHVDOM-Subnet and SHVDOM-1-Subnet suggest service-specific segmentation. Those are only registry labels, but they should lead a buyer to map purchased service to actual dependency. Is a DaaS customer served from a desktop farm on one /24? Is a static access or LNS function linked to customer connectivity? Are cloud management and customer workloads separated? Are backup networks visible or private?

Usable capacity also depends on hardware stock. If a server fails, can Global Cloud replace it locally, or does the repair depend on vendor stock and import timing? If a router or firewall fails, is there an on-site spare with current configuration? If a storage array degrades, is there enough headroom to rebuild without crushing performance? If a hypervisor cluster loses a node, are remaining hosts sized for N+1 or merely for average load?

None of those questions is answered by RIPE records or website claims. That is exactly why they should be asked. The public record proves a real operator and current reachability. The contract should prove service capacity and recovery capacity.

Rack, upstream, hardware, support and billing are the real failure paths

The assignment's main failure path is not theoretical. For Global Cloud, the most plausible public failure paths are rack or facility interruption, upstream or route-filter trouble, hardware shortage, support escalation failure, billing or provider-contract friction, and migration limits.

A rack or facility failure would test physical access. If Global Cloud's cloud capacity is concentrated in one room or one data-centre provider, a power, cooling, fibre, access-control or remote-hands issue could become a service outage. The company's website claims security and survivability, and its Hebrew cloud material claims multiple geographically separated data centres and disaster-recovery options. Public records do not verify the number, identity or independence of those sites.

A customer should ask for a site list under confidentiality if needed, but the answer should still identify whether primary, backup and management systems share a failure domain.

An upstream failure would test AS1680 and AS212616 dependency. The public neighbour and consistency records show two observed peers, with AS8551 in policy but not visible in BGP at query time. A customer should ask whether every routed /24 has at least two active paths, whether those paths enter different routers and buildings, whether all paths are sized for failover, and whether DDoS mitigation depends on one carrier. The answer should be a current network design, not only a registry object.

A hardware-stock failure would test the economics behind the service. Smaller providers can deliver excellent service with careful local spares and clear vendor coverage. They can also struggle if a failed disk, power supply, router module or firewall appliance must be sourced after the incident begins. The customer should ask for replacement targets by service type: virtual host, dedicated server, storage shelf, top-of-rack switch, edge router, firewall, backup appliance and customer premise device if any.

A support failure would test the difference between 24/7 wording and live escalation. The website's 24/7 support claim is useful, but customers should define severity levels, ticket channels, phone escalation, language coverage, after-hours authority and incident communications. If the support site or email depends on the same provider network, the customer should know the out-of-band path.

A billing or provider-contract failure is less dramatic than a power cut but can be just as disruptive. Because Global Cloud is an LIR and has its own address space, the address-resource dependency looks more controlled than for providers announcing leased blocks. Still, upstream transit, software licences, data-centre leases, backup services and Microsoft-related services can all create contractual dependencies. Customers should ask what notice applies before price, IP, platform or supplier changes affect them.

A migration failure is the quietest risk. If a customer wants to leave, can it export virtual-machine images, desktop profiles, mail data, software databases, telephony configuration, firewall policy, DNS zones, logs and backups in usable formats? Does Global Cloud provide a paid overlap window? Can customer IP addresses move or only DNS names? The correct time to answer those questions is before the service is critical.

Who is affected when this type of provider fails

The affected users are probably not abstract hyperscale customers. Global Cloud's website speaks to businesses that need integration, virtual desktops, software systems, telephony, collaboration, hosting and managed IT. That points toward small and medium organisations, call centres, development teams, retailers, professional-service firms and local enterprises that may not want to operate their own infrastructure. For those customers, the provider is not just a vendor.

It may be the place where employees log in every morning, the place where applications run, the place where backups sit, or the place where phone and collaboration tools depend on identity and network access.

The operational impact of failure therefore depends on the service. A website-hosting customer may face public downtime and DNS changes. A DaaS customer may lose employee work sessions. A managed application customer may lose business process continuity. A telephony customer may lose call routing. An IaaS customer may face server recovery, storage consistency and firewall reconstruction. A software-service customer may face data export and licensing questions.

This is why Global Cloud's broad service catalogue increases the diligence burden. A provider selling only static web hosting can be evaluated with one set of checks. A provider selling data-centre service, cloud, desktop, platform, software, collaboration and IT service needs a service-by-service risk map. The same AS61365 edge may be relevant to several products, but each product has different state, recovery and migration requirements.

The impact also differs by data sensitivity. A customer handling employee records, health-related information, financial records or European personal data has more to verify than a customer running a public brochure site. The official Israeli privacy materials cited above make clear that database security and cross-border data handling are regulated topics. The buyer should require a written division of responsibility: which party is the controller or processor, who manages access, how backups are protected, how incidents are reported, and where data is transferred.

Global Cloud may be a practical regional provider for customers that want local support and Israeli routing. The public evidence supports that possibility. It does not remove the need to test the failure paths before the provider becomes a single point of business continuity.

What would upgrade the evidence grade

The current public evidence earns a Medium grade because the network-resource layer is strong while the service-capacity layer is under-documented. The grade would improve if Global Cloud published or provided several kinds of verifiable operational evidence.

First, it could provide a current facility and platform summary. That does not need to expose sensitive floor plans. It should identify primary and secondary sites, whether the sites are owned or colocated, whether they are geographically and power-domain independent, which services run where, and how backups are separated. The website's claims about multiple data centres and disaster recovery would become much more persuasive if matched to current site roles and service types.

Second, it could provide a current routing and transit summary. AS1680 and AS212616 are visible in BGP; AS8551 is in policy. The provider could say which are active, standby or historical; whether each /24 has active route diversity; whether failover is tested; and what customers should expect during maintenance. It could also publish a PeeringDB profile. A PeeringDB API query for ASN 61365 returned a 404 entity-not-found response at research time, which means there was no public PeeringDB network profile available through that API query. PeeringDB is voluntary, so absence is not evidence of absence. It is still a missed disclosure opportunity for interconnection, facility and contact information.

Third, it could document backup and restore targets for each product. DaaS, IaaS, hosting, software and telephony should not share one generic backup promise. Each should have a last-tested restore date, recovery-time target, recovery-point target, exclusions and customer responsibilities. If restore depends on customer-purchased backup options, that should be clear.

Fourth, it could document migration rights. Hosted-service trust improves when customers know how they can leave. Export formats, DNS and IP transition windows, image portability, database dumps, profile exports, mail exports, telephony configuration exports and log retention should be clear before a dispute or outage.

Fifth, it could clean and align public service language. The English service page is usable, but the mixture of Global Cloud and Xpress Technologies wording, spelling issues and partly translated content makes it harder for outsiders to know which claims are current. A cleaner service catalogue would not prove resilience, but it would reduce ambiguity.

Those upgrades are not cosmetic. They would turn a credible routed footprint into a more auditable customer dependency.

The buyer's practical questions

A customer considering Global Cloud should start with the facts that are already good. Ask the company to confirm that AS61365 and 185.184.16.0/22 are the current production edge for the purchased service. Ask which of 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24 are used for the service. Ask whether RPKI ROAs remain valid and who approves route changes. Ask whether the route-object and IRR state is sufficient for all upstream filters.

Then ask the physical questions. Where is the primary service hosted? Is the rack, cage or data hall owned, leased or subcontracted? Which power feeds, UPS systems, generators, cooling systems and remote-hands processes are involved? Which spares are on site? Who can enter after hours? Which services share the same building and which are split?

Then ask the network questions. Which upstreams carry production traffic today? Which are standby? Can AS1680 or AS212616 independently carry the full load? What is AS8551's current role? Are there separate routers and cross-connects? Are DDoS controls carrier-specific? Are BGP changes peer-reviewed and tested?

Then ask the support questions. What does 24/7 mean in practice? Does it cover phone support, engineer response, monitoring, emergency changes and customer communications? What happens on Friday or Saturday when the public office-hours line says closed? What is the out-of-band contact path if the provider's own network is impaired?

Then ask the data questions. Where are primary data, backups, logs and support-ticket data held? Which platforms process identity, mail, monitoring or collaboration data? Which regulations does the customer need to satisfy, and which evidence can Global Cloud provide? How are backups encrypted, restored and deleted?

Finally, ask the exit questions. How can the customer export systems, data and configuration? Can it keep IP addresses, or must it renumber? How long is the overlap window? What assistance is included? What happens if termination follows a billing dispute, service incident or supplier change?

These questions do not assume Global Cloud is weak. They assume hosted capacity is physical, contractual and operational even when sold as cloud.

The conclusion: credible network, incomplete recoverability proof

Global Cloud Ltd is more substantial in public records than the assignment's thin-footprint hypothesis would suggest. The company has a RIPE LIR organisation object, a live AS, a clear IPv4 allocation, four current visible /24 announcements, valid RPKI route-origin coverage, Israeli locality signals and an official service catalogue around cloud, hosting, desktop, software, collaboration and managed IT. That is enough to establish a credible infrastructure-company subject.

The remaining uncertainty is not about whether the name exists. It is about how much recoverable service sits behind the name. Public data does not prove the number of racks, sites, servers, storage systems, support engineers, failover tests or customer workloads. It does not prove whether the broad service catalogue is delivered from Global Cloud-owned infrastructure, colocated infrastructure, partner platforms or a mixture. It does not prove whether a customer can migrate cleanly during stress.

That is why the article's title is intentionally physical. Global Cloud sells hosted capacity, but the value of that capacity still depends on racks, transit and repair windows. AS61365 can be visible while a customer still faces a restore problem. A /22 can be well registered while a buyer still needs proof of spare hardware. A valid ROA can protect origin validation while an upstream incident still tests failover. A 24/7 support claim can be true while the customer still needs escalation details.

The evidence grade should stay Medium until Global Cloud or its customers can verify facility independence, route failover, support escalation, backup restore and migration rights. The public network layer is real and comparatively well documented. The service-resilience layer remains a diligence task.