Summary

  • Global Cloud Ltd is a genuine network operator visible through RIPE, not just a name in a directory. TheRIPE organisation entity for ORG-GCL12-RIPEmentions Global Cloud Ltd, gives the Israeli company number514919729, indicates organisation typeLIR, and provides the address HaMasik St 4, Emek Hefer, Israel, with the same phone number that appears on the company website.
  • The company is linked to AS61365, whoseRIPEstat AS overviewlists the holder asGC-5222 Global Cloud Ltdand showed the AS as announced at the query date of 11/07/2026. TheRIPEstat routing status viewdisplayed four IPv4 prefixes, 1,024 visible IPv4 addresses, no visible IPv6 prefix, and two observed neighbours.
  • The company’s address space is not an independent third-party block. TheRIPE RDAP prefix registration for 185.184.16.0/22and theRIPEstat whois viewidentifyIL-GLOBAL-20170102, country IL, organisationORG-GCL12-RIPE, statusALLOCATED PA, and a geofeed file atgeofeed.xprsit.netthat associates the /22 and each /24 with Emek Hefer.
  • Route origin assurance is better than that of many small hosted footprints. The RIPEstat RPKI validation responses for185.184.16.0/24,185.184.17.0/24,185.184.18.0/24and185.184.19.0/24all returnedvalidunder a ROA 185.184.16.0/22 with maximum length 24.
  • The transit provider situation still requires customer testing. TheRIPE aut-num entitylists policies for AS1680, AS212616 and AS8551, while theRIPEstat ASN neighbours viewshowed AS1680 and AS212616 as observed neighbours and itsAS routing consistency viewshowed AS8551 in the whois policy but not in BGP at the time of the query.
  • The evidence level 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, depth of spare hardware, tested multi‑site recovery, the actual range of customer workloads, contractual support response times, or data portability limits.

The public record is concrete, but cloud capacity remains unproven

Global Cloud Ltd deserves different treatment from the hollow‑shell hosting names that appear only in aggregated lists. The company has a public network identity, an official website, RIPE LIR status, an Israeli company number in the RIPE organisation entity, an active autonomous system and a registered IPv4 allocation. TheRIPE aut‑num RDAP record for AS61365names the ASGC‑5222, lists Global Cloud Ltd as the organisational entity, and repeats the address HaMasik St 4, Emek Hefer, Israel. The company’sEnglish‑language homepagegives the contact line as Hamasek 4, Emek Hefer Industrial Park, publishes the phone number 072‑274‑3030, and describes services related to development, storage and security.

This combination makes the company sufficiently observable to be analysed. But it does not make the service fully verifiable from the outside. A customer who buys cloud, hosting, virtual desktops or a managed service is not just buying an AS number. They are betting on racks, circuits, optics, routers, hypervisors, storage, backup jobs, licences, support teams, power supplies, 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 storage shelf failure, a provider dispute, a power cut or a routing change.

The most useful way to read Global Cloud is therefore to see it as a mid‑sized infrastructure surface with enough public evidence to avoid speculation and enough missing operational detail to demand diligence. The English‑languagecloud services pageon the company site states that it offers data centre and cloud services, DaaS, PaaS, Infrastructure as a Service, collaboration services, IT services and software services. It also says that the support team works 24/7 and that Global Cloud emphasises security and survivability. These are relevant service claims. They do not replace a recoverability test.

The evidence also contains a small tell‑tale editorial clue. Parts of the English cloud page refer to “Xpress Technologies” while the domain, the RIPE records and the footer speak of Global Cloud. It could be legacy content, a template remnant, a related brand or a translation artefact; the public evidence does not decide the matter. The risk point for the customer is not that this name inconsistency proves anything negative. It is that broad cloud promises ought to be reconciled with current service contracts, current platform schematics and current support limits, instead of being inferred from old or inconsistent web content.

For this article, the operational 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 routes fail over, how staff respond outside business hours, and how workloads can leave the service if it no longer suits.

AS61365 gives Global Cloud a measurable advantage

The strongest company‑specific evidence starts with AS61365. TheRIPEstat AS overviewlists the holder asGC‑5222 Global Cloud Ltdand showed the AS announced at 08:00 UTC on 11 July 2026. TheRIPEstat routing status endpointdisplayed four IPv4 prefixes, 1,024 IPv4 addresses, no IPv6 prefixes, 326 out of 327 full‑feed RIS IPv4 peers seeing the route, and zero IPv6 visibility. The four prefixes currently announced in theannounced prefixes responsewere 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24.

This is a meaningful network entry point. It is also not a hyperscale footprint. A /22 chunked into four /24 announcements can support customer services, hosted platforms, VPNs, email, desktop services, management networks, static‑access customers or a mix of uses. It does not by itself prove a broad public‑cloud estate. The count of announced IPv4 addresses is not the count of servers, virtual machines, tenants, backup repositories or restore targets. The absence of IPv6 visible in RIPEstat also matters, because IPv6 readiness is now part of many buyers’ network planning, even if immediate service may work on IPv4.

TheRIPEstat prefix count endpointadds useful history. It shows Global Cloud’s current pattern of four IPv4 prefixes after earlier visibility changes and no IPv6 prefix count during the query window of 11/07/2026. Therouting history endpointshows an older visibility of AS61365 for 94.30.220.0/24 in 2012‑2014, then the 185.184.16.0/22 family from 2017 onwards. This history is a positive sign at the routing level: AS61365 is not a one‑week experiment.

But route continuity is not service continuity. The shift from an old history in 94.30.220.0/24 to the 185.184.16.0/22 family may reflect a provider, service, address‑resource acquisition or customer change, or simply the visible registration of different prefixes. Public BGP does not explain the commercial reason. It shows only that the AS has had observed routes at different periods and that the current routed footprint consists of the four /24s beneath 185.184.16.0/22.

Customers should therefore treat AS61365 as a strong starting fact and a weak final proof. It can justify asking detailed questions. It cannot replace the answers. If Global Cloud sells virtual servers, the buyer needs host architecture and storage. 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‑managed hosting estate.

The /22 allocation supports control, not unlimited scale

The address‑space evidence is especially useful because it ties the routed prefixes to Global Cloud rather than to a wholly separate address lessor. TheRIPE RDAP prefix recordfor 185.184.16.0/22 shows the handle185.184.16.0 – 185.184.19.255, the nameIL‑GLOBAL‑20170102, typeALLOCATED PA, country IL, and the organisational entity Global Cloud. TheRIPE REST inetnum entityrepeats the same allocation and adds a geofeed URL. Theorganisation entitypresents Global Cloud Ltd as an LIR. This 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. TheRIPEstat address‑space hierarchy responselists 185.184.16.0/24 asSHVDOM‑1‑Subnet, 185.184.17.0/24 asSHVDOM‑Core‑Subnet, 185.184.18.0/24 asLNS‑Static‑Subentand 185.184.19.0/24 asSHVDOM‑Subnet. These names suggest internal segmentation and at least one static or network‑service label. They do not prove which 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 the economics of hosting. A provider can own or operate an address allocation and yet have limited installed server capacity behind it. A provider can use one /24 for static customer 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 start, not where every dependency ends.

The company’s public website illustrates the point. A simple DNS lookup during research showed thatglobalcloud.meandwww.globalcloud.meresolved to 212.29.210.119, and theRIPEstat whois view for 212.29.210.119places that address inIL‑NETVISION‑980831, not in Global Cloud’s 185.184.16.0/22 allocation. This is not unusual. Many providers host their marketing website with another carrier or on another platform. The point is only that the website endpoint should not be taken as proof of where customer cloud workloads live.

For customers, the right question is therefore not “Does Global Cloud own addresses?” It does. The better question is how those addresses are allocated to services, whether customer IP address assignments are portable, how reverse DNS and reputation are managed, how renumbering would work, and whether the buyer receives sufficient notice if Global Cloud changes transit providers, subnets or service platforms.

RPKI is a genuine strength in the current public evidence

Route origin validation is one of the few public checks where Global Cloud’s footprint appears stronger than the information‑poor baseline. The RIPEstat RPKI validation endpoint returnedvalidfor 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 and 185.184.19.0/24 when queried for AS61365. Each response pointed to a validating ROA for 185.184.16.0/22, origin AS61365, maximum length 24. This means the four current /24 announcements match the published route origin authorisation at the time of query.

The technical value is narrow but real.RFC 6811explains BGP prefix origin validation as a way for a router to determine whether the AS that claims to announce the prefix is authorised by the prefix holder. RPKI does not encrypt packets, prevent all route leaks, prove that the path is the best, that a data centre is resilient, or solve application security. It does, however, reduce a class of mis‑origin announcement risks when networks enforce validation policies.

For Global Cloud, this matters because the routed footprint is compact. If a provider has four currently visible /24s and no visible IPv6, route origin errors can affect a large part of the public service surface. Valid ROAs for the current /24 announcements give customers a stronger starting position than anunknownorinvalidresult would. They also show that the relationship between the address holder and the origin has at least one modern routing‑security control in place.

The caveat is that RPKI is not a customer SLA. It does not say whether AS1680, AS212616 or any other transit path has enough capacity to carry traffic after a failure. It does not say whether the routers are redundant. It does not say whether anti‑DDoS filtering is active. It does not say whether customer backups are recoverable. It does not even say whether every operational route object is in order. TheRIPEstat prefix routing consistency responseshowed the aggregate route object 185.184.16.0/22 in whois, 185.184.19.0/24 in both BGP and whois, and the announcements 185.184.16.0/24, 185.184.17.0/24 and 185.184.18.0/24 in BGP without matching whois route objects in that specific consistency view. TheRIPEstat AS routing consistency responseshows the same divergence.

This divergence is not a crisis because the RPKI status is valid and the aggregate route object exists. It remains useful operational evidence. Customers should ask whether Global Cloud intentionally relies on the aggregate route object plus RPKI for the /24s, whether the IRR filters used by transit providers accept the current announcements, and what change‑control process protects ROA and route‑entity updates. A small inconsistency in a registry view can become a significant incident if a provider filter, route server or transit provider interprets it differently during maintenance.

The short version: RPKI is a strength. It should be recognised as a current control and then kept in its proper place.

Transit diversity is visible, but the failover story remains unfinished

The most important operational question is not how many carrier names appear in a policy entity. It is which paths can carry traffic when a path, router, interconnect or commercial contract fails. Global Cloud’s public record provides enough evidence to ask that question precisely.

TheRIPE aut‑num entity for AS61365includes policy entries for AS1680, AS212616 and AS8551. RIPEstat identifiesAS1680as Cellcom Fixed Line Communication L.P,AS212616as K.M.A ADVANCED TECHNOLOGIES LTD, andAS8551as Bezeq International Ltd. These are serious Israeli network names. TheASN neighbours endpointshowed, however, two observed neighbours at the last 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 in BGP at that time.

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. This is not a complete 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 at least for the 185.184.19.0/24 view.

Customers should not read this as “single‑homed” or “fully redundant” without more evidence. It is better read as “partially visible multi‑homing or provider‑policy complexity”. The customer should ask which ASNs are active production transits, which are backups, which are historic, and which carry specific customer services. The answer should include bandwidth commitments, router diversity, physical interconnect diversity, maintenance windows, DDoS management, escalation contacts and recent failover tests.

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

These questions are not accusatory. They are the difference between a service catalogue and an operational design. A hosting provider can honestly sell a resilient service from a compact public edge if it has tested routes, backup capacity and clear escalations. It can also sell a wide catalogue from a narrow dependency chain that works well until the first major rack or provider incident. The public data place Global Cloud somewhere between those two conclusions. Direct customer diligence determines which side reality is closer to.

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

Global Cloud has several overlapping Israeli locality signals. TheRIPE organisation entitylists HaMasik St 4, 3877701, Emek Hefer, Israel. TheRDAP aut‑num entityrepeats the address. TheGlobal Cloud homepagegives Hamasek 4, Emek Hefer Industrial Park, and the same phone number. Thegeofeed file referenced in the RIPE inetnum entitymaps 185.184.16.0/22 and each of the four /24s toIL, IL‑HA, Emek Hefer.

This 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 that every customer workload, backup, log, admin session or disaster‑recovery copy is physically in Emek Hefer. The IP registry address, the geofeed locality and the contact details do not constitute a facility audit. A provider may operate racks in one site, rent capacity in another, use remote backup services, run support tools through cloud platforms, or host some public services with other operators.

Geolocation also shows why caution is needed. TheRIPEstat geoloc viewand theMaxMind GeoLite viewplaced the /22 in Israel but in Ar Rayna, not Emek Hefer. This conflict does not disprove the geofeed. IP geolocation databases often differ, and geofeed data can represent operator intent or self‑published locality. It proves that buyers should not use an IP geolocation lookup as a physical placement guarantee.

Locality matters because Global Cloud’s service catalogue includes data‑centre‑type, cloud, desktop, platform, software and backup services. The officialIsraeli Privacy Protection Authority page on data securitydescribes data security regulations that apply to private and public sectors and put in place organisational mechanisms around database security. The same government portal publishesregulatory privacy documents concerning data transferred to Israel from the European Economic Area. These official pages do not tell us which Global Cloud customers process personal data or whether Global Cloud acts as a processor under a specific contract. They explain why a buyer cannot leave data location as a mere marketing phrase.

For a customer, the practical questions are simple. Where are the primary workloads hosted? Where are backups stored? Are backups encrypted and tested? Which employees, subcontractors or suppliers can access systems from outside Israel? Are logs, monitoring streams, support tickets or identity systems processed on foreign platforms? If the customer must prove Israeli, EEA or sector‑specific data handling, what contractual pieces and technical controls does Global Cloud provide?

Global Cloud’s public evidence supports the data‑sovereignty and data‑locality theme because the company has an Israeli network and office footprint and sells cloud‑adjacent services. It does not support a global compliance statement.

The service catalogue is broad enough to create serious customer dependency

Global Cloud’sEnglish cloud pageis not limited to a simple web‑hosting proposition. It describes data centre and cloud services, integration between enterprise systems and endpoints, continuous monitoring and maintenance, virtualisation on VMware‑ and KVM/XEN/Hyper‑V‑type platforms, a secure Internet connection, secure storage, DaaS, PaaS, Infrastructure as a Service, a collaboration service, IT as a Service and Software as a Service. TheEnglish hosting pagerepeats the data centre and cloud theme and lists hosting, DaaS and telephony services. Theabout pagestates in Hebrew that Global Cloud Ltd was founded in 2013 and positions the company around personalised service by local experts.

These claims matter because they place Global Cloud in the dependency layer rather than the commoditised domain‑name layer. An enterprise using DaaS depends on session brokering, identity, storage, endpoint performance and support. One using IaaS depends on compute, storage, networking, image management and recovery. One using collaboration or telephony services depends on availability, call flows, directories, user provisioning and configuration export. One using managed software depends on patching, backups, access control and change approval.

The public network footprint can support such services, but it does not disclose their installed depth. Four visible /24s can support a meaningful regional platform, especially for a targeted Israeli provider. They can also mask a much narrower estate if services are delivered through third‑party platforms or rented capacity. The website claims around security, survivability and 24/7 support need to be turned into measurable commitments: support channels, response times, incident notification, backup frequency, restore time, restore point, data export, customer‑side failover and termination assistance.

A practical tension in the website evidence concerns support hours. The English homepage header lists office hours Sunday to Thursday 09:00–18:00, closed Friday and Saturday. 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 guaranteed 24/7? What is on‑call? Which severity level gets an immediate response? Which contact path works during a network outage? Is the support portal hosted outside the affected environment? Who can approve emergency changes outside normal office hours?

The service catalogue also creates a licence and platform dependency. The cloud page refers to VMware‑, XEN‑ and Microsoft‑type infrastructure support. A customer should ask whether their service is dedicated, multi‑tenant or sub‑contracted; 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 lesson for customer risk is that Global Cloud’s public evidence is credible enough to take seriously, yet also broad enough that the buyer should not accept a single generic “cloud” assurance. Every 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, rented or configured under normal conditions. Usable capacity is what remains available when something fails, when a customer grows, when a provider changes terms, or when a migration has to happen under constraint. Global Cloud’s visible footprint is large enough for a genuine hosted service and small enough that customers should ask how much headroom exists behind it.

The /22 holds 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, email, VPNs, desktop gateways or network equipment, the pool of public addresses available for new hosted services may be smaller than the raw number suggests. If some services are privately addressed behind gateways, the public address pool may under‑count compute capacity. Public BGP alone cannot resolve this.

The more specific subnet labels add to the question.SHVDOM‑Core‑Subnetlooks like core infrastructure;LNS‑Static‑Subentsuggests a static‑access or subscriber function;SHVDOM‑SubnetandSHVDOM‑1‑Subnetsuggest service‑specific segmentation. These are only registry labels, but they should prompt the buyer to map the purchased service to the actual dependency. Is a DaaS customer served from a desktop farm on one /24? Is a static‑access or LNS function tied 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 repair depend on vendor stock and import lead times? If a router or firewall fails, is there a spare unit on site with current config? If a storage shelf degrades, is there enough margin to rebuild without crushing performance? If a hypervisor cluster loses a node, are the remaining hosts sized for N+1 or only for average load?

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

Racks, transit providers, hardware, support and billing are the real failure paths

The main failure path in this dossier is not theoretical. For Global Cloud, the most plausible public failure paths are a rack or facility outage, a transit‑provider or route‑filter problem, a hardware shortage, a support‑escalation failure, a billing or supplier‑contract dispute, and migration limits.

A rack or facility failure would test physical access. If Global Cloud’s cloud capacity is concentrated in a single room or with a single data‑centre provider, a power, cooling, fibre, access‑control or remote‑hands problem could become a service outage. The company website claims security and survivability, and its Hebrew cloud content claims multiple geographically separated data centres and disaster‑recovery options. The public record does not verify the number, identity or independence of those sites.

A customer should request a site list under confidentiality if necessary, but the answer should still indicate whether primary, backup and management systems share a common failure domain.

A transit‑provider failure would test the dependency on AS1680 and AS212616. The public neighbour and consistency records show two observed peers, with AS8551 in policy but not visible in BGP at the time of query. A customer should ask whether each routed /24 has at least two active paths, whether those paths enter through different routers and buildings, whether all paths are sized for failover, and whether DDoS mitigation depends on a single carrier. The answer should be a current network design, not merely a registry entity.

A hardware‑stock shortage would test the economics behind the service. Small providers can deliver excellent service with prudent local spares and clear vendor cover. They can also be in trouble if a failed disk, power supply, router module or firewall enclosure has to be sourced after the incident. The customer should ask for replacement targets per service type: virtual host, dedicated server, storage shelf, top‑of‑rack switch, edge router, firewall, backup appliance and customer‑premises equipment where applicable.

A support failure would test the difference between the 24/7 phrase and actual escalation. The 24/7 support claim on the website is helpful, but customers should define severity levels, ticket channels, telephone 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 supplier‑contract failure is less dramatic than a power cut but can be just as disruptive. Because Global Cloud is an LIR and holds its own address space, the address‑resource dependency appears more controlled than for providers that announce rented blocks. Nevertheless, upstream transit, software licences, data‑centre leases, backup services and Microsoft‑type services can all create contractual dependencies. Customers should ask what notice applies before price, IP‑address, platform or supplier changes affect them.

A migration failure is the quietest risk. If a customer wants to leave, can they export virtual machine images, desktop profiles, email data, software databases, telephony configuration, firewall policy, DNS zones, logs and backups in usable formats? Does Global Cloud offer a paid overlap window? Can the customer’s IP addresses be moved or only DNS names? The right time to answer these questions is before the service becomes critical.

Who is affected when this type of provider fails

The affected users are unlikely to be abstract hyperscale customers. Global Cloud’s website speaks to enterprises that need integration, virtual desktops, software systems, telephony, collaboration, hosting and managed IT. That points to small and medium‑sized organisations, call centres, development teams, retailers, professional‑services firms and local businesses that may not want to run their own infrastructure. For these customers, the provider is not just a vendor. It may be where employees log in every morning, where applications run, where backups rest, or where telephony and collaboration tools depend on identity and network access.

The operational impact of a failure therefore depends on the service. A web‑hosting customer may face public unavailability 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 rebuild. A software‑service customer may encounter data‑export and licensing questions.

This is why Global Cloud’s broad service catalogue increases the diligence burden. A provider that sells only static web hosting can be assessed with a single set of checks. A provider that sells data centre, cloud, desktop, platform, software, collaboration and IT services requires a per‑service risk map. The same AS61365 edge may be relevant for multiple products, but each product has different state, recovery and migration requirements.

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 one running a public brochure site. The Israeli official privacy documents cited earlier make clear that database security and cross‑border data processing are regulated topics. The buyer should demand a written division of responsibilities: which party is controller or processor, who manages access, how backups are protected, how incidents are notified, and where data are transferred.

Global Cloud can be a convenient 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 failure paths before the provider becomes a single point of business continuity.

What would improve the evidence level

The current public evidence deserves a medium level because the network‑resource layer is strong while the service‑capacity layer is under‑documented. The level would improve if Global Cloud published or provided several types of verifiable operational evidence.

First, it could provide a current facility and platform summary. This does not require exposing sensitive floor plans. It should identify primary and secondary sites, whether sites are owned or colocated, whether they are independent geographically and in power‑domain terms, which services run where, and how backups are separated. The website claims about multiple data centres and disaster recovery would become far more convincing if matched with 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 historic; 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. APeeringDB API query for ASN 61365returned a 404 entity‑not‑found response at research time, meaning no public PeeringDB network profile was available through that API query. PeeringDB is voluntary, so absence is not evidence of absence. It is still a missed disclosure opportunity for interconnect, facility and contact information.

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

Fourth, it could document migration rights. Trust in a hosted service improves when customers know how they can leave. Export formats, DNS and IP transition windows, image portability, database extracts, profile exports, email exports, telephony configuration exports and log retention should be clear before a dispute or a failure.

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

These improvements are not cosmetic. They would turn a credible routed footprint into a more verifiable 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 the RPKI ROAs remain valid and who approves route changes. Ask whether the route‑entity and IRR state is sufficient for all transit‑provider filters.

Then ask the physical questions. Where is the primary service hosted? Is the rack, cage or data hall owned, leased or sub‑contracted? What power feeds, UPS, generators, cooling systems and remote‑hands processes are involved? What spare parts are on site? Who can enter out of hours? Which services share the same building and which are separate?

Then ask the network questions. Which transit providers carry production traffic today? Which are standby? Can AS1680 or AS212616 independently support the full load? What is the current role of AS8551? Are there separate routers and interconnects? Are anti‑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 telephone support, engineer response, monitoring, emergency changes and customer communications? What happens on a Friday or Saturday when the public office‑hours phone line says closed? What is the out‑of‑band contact path if the provider’s own network is down?

Then ask the data questions. Where are primary data, backups, logs and support‑ticket data located? Which platforms process identity, email, monitoring or collaboration data? Which regulations must the customer meet, and what 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 config? Can they keep the IP addresses, or must they renumber? How long is the overlap window? What assistance is included? What happens if termination follows a billing dispute, a service incident or a supplier change?

These questions do not assume that Global Cloud is weak. They assume that 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 the public record than the assumption of a thin dossier footprint would suggest. The company has a RIPE LIR organisation entity, an active AS, a clear IPv4 allocation, four currently visible /24 announcements, valid RPKI route‑origin coverage, Israeli locality signals and a formal 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 the existence of the name. It is about how much recoverable service sits behind that name. Public data do not prove the number of racks, sites, servers, storage systems, support engineers, failover tests or customer workloads. They do not prove whether the broad service catalogue is delivered from Global Cloud‑owned infrastructure, colocation infrastructure, partner platforms or a mix. They do not prove whether a customer can cleanly migrate under stress.

This 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 suffers 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 a transit‑provider incident still tests failover. A 24/7 support claim can be true while the customer still needs escalation details.

The evidence level should remain 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 relatively well‑documented. The service‑resilience layer remains a diligence task.