EUROPE Anexia Cloud Solutions GmbH sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The strongest public identity signal is AS42360. RIPEstat's AS overview names the holder as "SSP-EUROPE Anexia Cloud Solutions GmbH" and marks the AS as announced; RIPE's RDAP record for AS42360 shows registration on 2017-05-11 and a 2021 last-changed event.
• Current routing evidence is real, not merely historical. RIPEstat's announced-prefixes view showed twelve recent prefixes, including eleven IPv4 /24s under 94.16 space and one IPv6 /48, while the BGP-state view showed thousands of observed routes.
• The dependency is concentrated. RIPEstat's ASN-neighbours response showed AS47147 as the single observed neighbor for AS42360; AS47147 and AS42473 are both Anexia network identities, but this still makes the European segment dependent on the parent Anexia backbone boundary rather than independently diverse in public BGP.
• Anexia's public service pages are unusually detailed for a hosted-capacity provider: the company publishes cloud, virtual data center, colocation, IP transit, power, monitoring, storage, DDoS, GDPR, certification and digital-sovereignty material. Those pages support a serious operating footprint, but they are group-level claims and should not be read as proof of a specific rack, customer workload or spare inventory behind every AS42360 prefix.
• The evidence grade is Medium. Public route visibility, Anexia legal records and official infrastructure pages support active hosted-capacity relevance; the open watchpoints are AS42360's single observed neighbor, incomplete AS42360-specific facility mapping, IPv4 RPKI gaps for the checked /24, and the need for customer-specific proof of restore time, data location and migration rights.

A live European segment inside a larger Anexia network

EUROPE Anexia Cloud Solutions GmbH is best understood as a network-facing European segment of Anexia Cloud Solutions GmbH rather than as a standalone cloud brand with its own public retail story. The routing identity is concrete. RIPEstat's AS42360 overview reports the holder as "SSP-EUROPE Anexia Cloud Solutions GmbH" and marks the AS as announced. The RIPE whois-derived view for AS42360 gives the AS name SSP-EUROPE, says it is "powered by ANX," lists ORG-AIG10-RIPE, and shows imports and exports involving AS47147 and AS42473. The RIPE RDAP entity for AS42360 records a 2017 registration and a 2021 last-changed date.

The organisation entity matters because it connects the routing label to a real company boundary. RIPE's organisation record for ORG-AIG10-RIPE names Anexia Cloud Solutions GmbH, marks it as an LIR, and gives a Klagenfurt address. Anexia's own imprint lists Anexia Cloud Solutions GmbH in Austria at Feldkirchner Strasse 140, 9020 Klagenfurt am Worthersee, with managing directors Malte von dem Hagen and Markus Narrenhofer, and also lists a German Anexia Cloud Solutions GmbH address in Karlsruhe. This gives the buyer a legal and registry surface that is much stronger than a casual hosting name.

The important caution is that the directory name says "EUROPE" but the assignment's region is Global. That is not contradictory if the record is read correctly. Anexia markets a global cloud and worldwide infrastructure, while AS42360 is a European or subsidiary segment in the network documentation. The company page for Anexia World Wide Cloud says Anexia operates more than 100 server locations worldwide across more than 70 countries, while the Europe data center page says it has more than 30 high-technology centers in Europe. Those are not the same claim. One describes Anexia's global estate; the other describes regional European capacity. AS42360 should be treated as a European network slice inside that larger estate.

That distinction changes the risk analysis. A buyer should not ask only whether Anexia can sell a virtual server somewhere. The buyer should ask whether the exact service ordered is placed in a named region, routed through the expected AS or parent network, protected by the expected RPKI and filtering policy, covered by the right support team, and restorable into a second location if the rack, facility, upstream, billing account or customer control surface fails. Public evidence proves that Anexia is a serious infrastructure operator. It does not automatically prove every customer-specific recovery design.

What the live route table proves, and what it does not prove

AS42360 is currently visible in public routing. RIPEstat's announced-prefixes response returned twelve prefixes for the recent 2026-06-30 to 2026-07-14 window: 2a00:11c0:77::/48 and IPv4 /24s including 94.16.0.0/24, 94.16.2.0/24, 94.16.3.0/24, 94.16.4.0/24, 94.16.6.0/24, 94.16.7.0/24, 94.16.9.0/24, 94.16.11.0/24, 94.16.13.0/24, 94.16.20.0/24 and 94.16.96.0/24. That is a materially different starting point from a dormant ASN with no current routes.

Prefix-level visibility reinforces the point. RIPEstat's routing status for 94.16.0.0/24 showed origin AS42360, RIPE route objects, 326 of 326 IPv4 RIS peers seeing the prefix, first-seen time of 2018-09-24, and last-seen time of 2026-07-15 00:00 UTC. The routing status for 94.16.20.0/24 gave the same 326-of-326 IPv4 visibility and the same origin AS42360. The routing status for 94.16.96.0/24 showed origin AS42360 and a first-seen date in 2018. For IPv6, RIPEstat's 2a00:11c0:77::/48 routing status showed AS42360 as origin, 321 of 321 IPv6 peers seeing it, a first-seen date in 2018, and last-seen time of 2026-07-15 00:00 UTC.

This proves routable address space and a current internet edge. It does not prove usable hosted capacity by itself. A prefix can be announced while servers are full, a rack is reserved for one customer, storage is unavailable, a product is sold only through a private account, or capacity is concentrated in a single facility. The route table can tell a buyer that AS42360 is alive; it cannot tell whether a specific virtual machine can be provisioned, how quickly it can be restored, whether support can move it across regions, or whether a customer's IP address is portable after termination.

The BGP-state view adds scale but not complete redundancy. RIPEstat's BGP-state response for AS42360 showed 4,167 observed route entries in the checked response, with sample paths reaching AS42360 through AS47147. That is good public visibility, but the ASN-neighbours response showed only one observed neighbor, AS47147. In other words, AS42360 looks well propagated once it is behind the Anexia parent network, but its visible upstream dependency is concentrated at the segment boundary. For a customer, the question is not simply "is AS42360 up?" It is "what happens if AS47147 policy, backbone maintenance, route filtering or a parent-network incident affects this segment?"

The parent-network boundary is the operating surface

The clearest dependency in the public graph is Anexia's own network hierarchy. RIPEstat's overview for AS47147 names it "AS-ANX Anexia Cloud Solutions GmbH" and marks it announced. RIPEstat's overview for AS42473 names it "AS-ANEXIA Anexia Cloud Solutions GmbH" and also marks it announced. The AS42360 routing-consistency response showed AS47147 present in both BGP and whois for imports and exports, while AS42473 appeared in whois but not in BGP for that AS42360 check. That is not a failure; it is evidence of how the segment is publicly reachable at the checked moment.

Anexia's own network documentation makes the hierarchy easier to interpret. The ANX Unified Network page describes AS47147 as an Anexia backbone or European 100G-based backbone connecting Vienna, Klagenfurt, Frankfurt and Nuremberg. It describes AS42473 as Anexia World Wide Cloud, visible in Europe behind AS47147 and connected worldwide to different upstreams. It describes AS42360 as SSP Europe, an Anexia subsidiary in Nuremberg, Germany. This page is valuable because it gives meaning to the route table: AS42360 is not presented as the independent global backbone; it is one part of a group network.

PeeringDB also supports the separation. The PeeringDB API for AS42360 returned no network record, while the PeeringDB API for AS42473 returned an Anexia profile with global scope, selective peering policy, content type, 1,000 IPv4 and 500 IPv6 prefix counts, and a website field. That profile is useful for understanding the Anexia network family, but it is not an AS42360-specific facility map. A buyer should not read AS42473's PeeringDB profile as proof that AS42360 itself has independent exchange presence or physically separate ingress.

The parent network's policy page is reassuring in several ways. The ANX Unified Network page says the network rejects prefixes with RPKI invalid state, filters reserved ASNs and prefixes, does ingress filtering based on prefix lists for BGP neighbours, and applies BCP38 on IP access interfaces. These are the right kinds of controls for a hosting network, because customer infrastructure often becomes risky when bad route objects, spoofed traffic, weak filtering or stale prefix lists are tolerated. But this is still a policy claim. The customer's diligence should ask how those controls apply to the exact service, the exact assigned prefixes, the exact transit handoff, and the exact mitigation path during an attack or route leak.

Route authorization is mixed enough to create a watchpoint

RPKI is one place where AS42360 looks partly mature and partly incomplete. RIPEstat's RPKI validation for AS42360 and 2a00:11c0:77::/48 returned a valid origin for AS42360 with max length 48. That is a strong positive signal for the IPv6 prefix in this segment. It means the visible IPv6 origin is aligned with an authorization record in the checked validator output.

The IPv4 result is less strong. RIPEstat's RPKI validation for AS42360 and 94.16.0.0/24 returned "unknown" and no validating ROAs in the checked response. "Unknown" is not the same as invalid. It does not mean the route is hijacked, and it does not contradict the route's visibility. It means the checked RPKI view did not find a ROA that positively validates AS42360 for that prefix. For a provider selling hosted capacity, unknown RPKI is a watchpoint because many networks increasingly use RPKI state in filtering, incident triage and route-risk scoring.

There is a useful contrast with Anexia's main web route. DNS for anexia.com and www.anexia.com resolved locally to 188.172.220.146. RIPEstat's network-info response for 188.172.220.146 aligned that address to 188.172.220.0/24 and AS42473. RIPEstat's routing status for 188.172.220.0/24 showed AS42473 origin with full IPv4 RIS visibility, and the RPKI validation for AS42473 and 188.172.220.0/24 returned valid. That tells a buyer Anexia can operate validated routing on some group prefixes; it does not remove the unknown state observed for AS42360's checked IPv4 /24.

The buyer implication is practical. If a customer receives addresses from the AS42360 94.16 space, it should ask whether ROAs exist for the exact origin and max length, whether the prefix will be advertised only from AS42360 or also through a parent AS, what the route object and IRR policy are, and how quickly Anexia can change RPKI if a migration or mitigation requires a different origin. If a route remains RPKI unknown, the customer should understand that the route may still work globally but could be less clean in networks that prefer fully validated route sets. In a cloud sale, route hygiene is part of service durability.

The product surface is broad, but the exact capacity still needs mapping

Anexia's service pages show a broad hosted-capacity business rather than a narrow transit-only network. The managed hosting page says Anexia provides and maintains virtual IT infrastructure and support, with configurable servers, managed clusters, managed databases, load balancing, shared storage, virtual firewall, DDoS protection and web application firewall features. The virtual data center page says customers can decide processing power, memory, disk capacity and bandwidth, add components such as virtual firewalls, storage and load balancers, and pay for resources actually used. The virtual server page says Anexia uses KVM, offers around-the-clock technical support with reaction times of no more than 30 minutes, and markets adjustable RAM, disk, vCore and operating-system options.

That is enough to support the article's premise: hosted capacity sold under this corporate group still depends on physical and network assets. The marketing language is not only about abstract software. It names virtual servers, storage tiers, load balancers, firewalls, DDoS protection, backup and recovery, and support. These are all service layers that sit on top of racks, top-of-rack switching, storage arrays, power feeds, upstream routing, monitoring systems, ticket processes and customer account controls.

The colocation page is especially useful because it names the physical unit choices behind the cloud vocabulary: individual units, quarter racks, half racks, full 42U racks, cages, 24/7 access, and round-the-clock support with stated reaction times. The shared storage page names NetApp-based shared storage, SATA, SAS and SSD tiers, IOPS figures, mirroring, spare disks, support replacement within four hours, and redundant links to the Anexia Core. These claims are not AS42360-specific, but they show the sort of operational substrate a hosted-capacity customer should expect to be made explicit in a proposal.

The gap is not that Anexia has no service story. The gap is that public pages cannot tell a customer where a particular workload is placed or what part of the Anexia estate serves it. A European customer buying from a European entity may assume placement in Europe, but the Anexia World Wide Cloud page and Cloud Connect page both emphasize global locations. That is useful for latency and expansion; it also means the customer needs written site selection, subprocessor, backup-location and failover-location terms. Capacity is not just available because the company has many locations. It is available when the exact requested site, hardware class, storage tier, address range and recovery target are in stock and contractually covered.

Power and monitoring claims reduce risk only when scoped to the purchased service

Anexia publishes unusually concrete infrastructure quality pages. The power connection page says Anexia offers data-center customers complete n+1 redundancy, says each Anexia system has at least two power supplies connected to different phases, says UPS phases are backed by two districts, and says a diesel generator starts automatically if both phases fail and can supply a data center for up to 72 hours. It also says the setup gives more than 99.99% annual availability. These are meaningful details because power design is one of the most common places where a cloud buyer discovers that a "virtual" service is physical after all.

The network connection page adds routing and backbone claims: redundant routes, contracts with numerous independent carriers and providers, offices connected to at least two different core routers, more than 1,000 peering partners, connection to important internet nodes, routers at least 4x10G connected to the Anexia Backbone, HSRP/VRRP for redundant default gateways, continuous NOC monitoring, internal BGP and OSPF, redundant ring structures, redundant routing and management engines, and certified Cisco and Juniper network engineers. These are credible categories of network resilience, but the public page does not identify which of those designs applies to AS42360's current observed path through AS47147.

The server monitoring page says Anexia monitors more than 50,000 parameters around the clock, uses external measurement points, provides 24/7 monitoring of core infrastructure, sends email and SMS notifications, and uses distributed monitoring points to identify international routing problems. This is directly relevant to a buyer because the failure path in a small cloud often begins as a detection problem. A backup that exists but is not monitored, a route that is reachable from one internal point but not from customers, or a storage array that is degraded but not escalated can turn a recoverable fault into a long service incident.

Even strong power and monitoring claims need scope. If the customer buys a VM in a third-party facility reached through the Anexia backbone, is the UPS design Anexia-owned or facility-owned? If the customer buys a colocation rack, are both power supplies actually connected to separate feeds, and is the customer required to cable dual power correctly? If AS42360 is routed through AS47147, is monitoring performed at the AS42360 prefix level, at the parent backbone level, or at the customer's service endpoint? If a remote site loses hands-on access, who replaces hardware and under what time commitment? Public pages give the right categories.

A production contract has to bind them to the purchased service.

Transit, DDoS and Cloud Connect make the route a managed dependency

The IP Transit page says Anexia sells transit through AS42473, offers a 24x7 NOC, cites a 230 Gbit Anexia backbone, says it is connected to numerous internet exchanges, and lists services including BGP full table, partial table, static routing, IPv4 and IPv6, redundant connections with or without VRRP, managed routers and ASN service. This page matters because it shows Anexia is not merely using transit as a hidden input for its own cloud. It sells network connectivity as a product, which means routing policy, customer route filtering, blackholing, DDoS handling and port billing are part of the business surface.

The DDoS protection page says Anexia DDoS Guard provides 2 Tbps available bandwidth, covers layers 3 and 4 and, on request, layer 7, uses Netscout Arbor extended with Anexia technology, supports BGP Flowspec, and has 24/7 NOC availability. These are useful claims for hosted customers because the failure path may not be a disk or power event. A volumetric attack can consume transit, trigger filtering, expose route-policy limits, or force traffic through mitigation capacity. If AS42360 prefixes carry customer workloads, the customer should ask whether DDoS Guard is active by default, optional, tied to AS42473, or separately provisioned for the exact prefix.

The Cloud Connect page says BGP is feasible for most data centers, describes in-data-center, last-mile, near-data-center and VPN connection models, and says customers can use Cloud Connect worldwide to reduce latency and obtain presence in jurisdictions of their choice. This is important for data sovereignty and dependency. Direct or near-data-center connections can reduce internet exposure, but they also introduce leased-line, router, cross-connect, tunnel and customer-premises failure paths. If the customer uses Cloud Connect as a continuity path, the buyer should ask whether the connection terminates in the same failure domain as the VM or storage service.

The network product pages make Anexia look operationally mature. They do not eliminate the need for segment-specific diligence. AS42360's public neighbor view showed AS47147 only. The parent Anexia network has broad peering and transit material, but the customer still needs to know the exact service chain: AS42360 prefix, AS47147 backbone, AS42473 world-wide network, facility, cross-connect, DDoS guard, customer portal, monitoring point and support escalation. Each layer can work independently while the customer's application still fails if two layers are misaligned during maintenance.

The buyer should separate three Anexia layers

The public record is easiest to read if the buyer separates three layers: the AS42360 segment, the Anexia backbone family, and the purchased service. The first layer is visible in the route table. AS42360 originates a defined set of prefixes, appears under the SSP-EUROPE name, and is currently seen through AS47147. This layer answers the question "does the European segment have public internet reachability?" The answer is yes, with the caveat that the observed neighbor set is narrow and the checked IPv4 RPKI state is not fully positive.

The second layer is the Anexia network family around AS47147 and AS42473. This layer answers a different question: "is there a larger operator behind the European segment?" The answer is also yes. The official ANX network documentation describes AS47147 as a European backbone and AS42473 as the World Wide Cloud network. Anexia's website describes network, transit, DDoS, monitoring, power and storage capabilities that belong to the broader operating company. This layer is what makes AS42360 materially stronger than a small isolated ASN.

If the segment has trouble, it is not visibly stranded; it sits within a larger Anexia operating environment.

The third layer is the customer service. This layer is the most important and the least visible in public evidence. A customer does not buy AS42360 in the abstract. It buys a VM, a managed cluster, a storage tier, colocation space, transit, DDoS protection, Cloud Connect, backup, or a combination of those services. That order has a country, a legal entity, a service level, a support path, an IP assignment, a data-retention rule, a restore target and an exit path.

Public routing and product pages can help test whether the supplier is credible, but they cannot prove that a particular order has dual-site replication, spare nodes, clean RPKI, sufficient IPv4 inventory or a tested restore drill.

This separation prevents two common mistakes. The first mistake is to over-discount the provider because AS42360 looks like a narrow segment. That would miss the fact that Anexia publishes substantial service, network and compliance material, and that AS42360 has current prefix visibility. The second mistake is to over-credit the provider because Anexia's group pages are detailed. That would miss the fact that group-level claims do not automatically attach to a specific AS, a specific European rack, a specific customer account or a specific disaster-recovery design.

For procurement, the correct posture is to request evidence at all three layers. At the AS42360 layer, request current routes, RPKI state, IRR objects, upstream path and monitoring views. At the Anexia backbone layer, request how AS47147 and AS42473 carry the service, which mitigations are active, which network policies apply and whether maintenance on the parent network can affect the customer. At the service layer, request the placement schedule, hardware class, storage tier, backup country, support escalation path, restoration evidence and export rights.

Only when those three layers match can the buyer treat the service as resilient rather than merely reachable.

Data locality is a contract question, not a map slogan

The assignment's topics include data sovereignty and locality, and Anexia gives this topic unusually explicit public treatment. Its digital sovereignty page says Anexia provides a global cloud solution architected and secured within Europe, says the company is headquartered in Austria, says it follows GDPR, says it is not subject to the CLOUD Act, and says it is a CISPE board member or member entity through its founder and CEO. It also says Anexia operates data centers in over 70 countries while keeping data under European control. These are strong positioning claims for European buyers seeking alternatives to non-European hyperscalers.

The Data Protection and GDPR page says Anexia created contractual obligations for customers using its products and services in compliance with GDPR, references Article 28 processor obligations, offers a General Privacy Policy for Anexia Cloud Solutions GmbH Austria and Germany, and provides data processing agreement materials for both. The certification page says Anexia is certified to ISO 9001, ISO 27001, ISO 27701 and ISO 14001, gives certification scopes including Anexia Virtual Server Infrastructure, IT Services, Managed Hosting, Software Development and Data Center Operations, and says annual audits confirm the management systems.

These pages support a strong compliance and locality story. The open question is where the customer's bytes and operational metadata actually sit. A global cloud can be European-controlled and still place workloads, backups, logs, monitoring data or support records in different countries. A customer may want low latency in London, Frankfurt, Vienna or Madrid while also wanting Austrian or German contract terms, EU-only support handling, EU-only backups, and no third-country access. Those are not the same requirement. The Europe data center page supports a large European footprint; the locations and services page supports service discovery across locations. Neither page replaces a binding placement schedule.

Locality also intersects with routing. If a customer receives AS42360 addresses, the route may be European in network identity, but packets can traverse international carriers, route servers, mitigation systems or customer VPN paths. If a customer uses a global Anexia service, failover may move compute or storage to another jurisdiction unless the contract forbids it. If a customer chooses a cheap global capacity pool, the selected site may prioritize price, spare capacity and latency over strict data location.

The buyer's correct diligence question is not "is Anexia European?" It is "which legal entity contracts with me, which country hosts my primary data, which country hosts backups and logs, which staff can access it, which AS and transit path carry it, and what changes during incident recovery?"

Hosted-capacity economics still depend on spare parts and support labor

Anexia's virtual data center economics are attractive because they turn physical capacity into adjustable service units. The virtual data center page says customers can add processing power, memory, bandwidth and licenses as required and pay only for services actually used. The virtual server page describes adjustable resources ranging from small to large RAM, disk and vCore profiles, preconfigured virtual machines for peak times, and availability within minutes. These claims are normal for a mature cloud provider, but they also hide a physical inventory problem.

Elastic capacity is only elastic within the limits of installed hardware, power, cooling, storage, network ports, software licenses and operations staff. A customer can click for more RAM only if the cluster has spare memory. A VM can move between locations only if image transfer, IP address policy, firewall state, storage replication and licensing allow it. A disaster recovery site can reduce downtime only if it is continuously synchronized, tested, and capable of serving the workload under real load. Anexia's disaster recovery page says it creates emergency data restoration plans, offers geographically separated redundancies, and can synchronize mission-critical applications, services or websites. Those are useful features, but buyers should still ask for the actual recovery point and recovery time for their design.

Storage economics create another hidden dependency. The shared storage page lists multiple storage tiers, IOPS figures, mirroring, spare disks, replacement within four hours, and redundant 1 Gbit/s and 10 Gbit/s links to the Anexia Core. That detail is good because it shows the company understands storage as a performance and recovery surface. It also means buyers need to choose carefully. A low-cost SATA tier, a high-performance SSD tier, a backup array and a replicated shared-storage volume have different failure behavior. "Cloud" does not make those differences disappear.

Support labor is a final economic constraint. Anexia repeatedly says it offers 24/7 support and no more than 30-minute reaction times on relevant pages. Reaction time is not repair time. In a real failure, response must be followed by diagnosis, escalation, parts availability, supplier coordination, route change, storage restore, customer notification and verification from outside the affected network.

A buyer should ask not only how fast a ticket is acknowledged but also what happens if a rack switch fails, if a storage controller degrades, if AS47147 filters a route, if DDoS mitigation changes the path, if a billing issue blocks control access, or if a customer needs to leave the platform quickly.

The main failure paths to test before production use

The first failure path is the AS42360 to AS47147 boundary. Public routing shows AS42360 visible through AS47147. That may be the intended design, but it should be tested. The buyer should request a current route proof for the exact assigned prefixes, the origin AS, the upstream path, the route objects, the RPKI state and the monitoring locations. If the service uses AS42360 for customer workloads, the customer should ask what happens if AS47147 maintenance or filtering affects the segment. If the service uses AS42473 or another Anexia AS instead, the customer should ask why the directory-visible AS is not the production path.

The second failure path is facility concentration. Anexia markets more than 100 locations worldwide and more than 30 centers in Europe, but the customer workload will be in a finite set of halls, cages, racks and storage clusters. A buyer should ask whether the service runs in one data center, two buildings in one metro, two metros, or a global active-passive design. It should ask whether backups are in the same site, another Anexia site, a supplier facility or a separate service tier.

It should ask whether both power feeds are actually used by the customer's equipment and whether the generator and UPS design described on the public page applies to that location.

The third failure path is stock and spare capacity. If a host fails, can the workload move to spare hardware in the same location? If a storage shelf fails, are spare disks and support replacement available within the claimed window? If a customer needs emergency scale-out, does the exact site have enough CPU, RAM, SSD capacity and public IPv4 addresses? Anexia's product pages support the idea that the company sells configurable capacity, but public pages cannot prove availability at a particular moment. That evidence must come from a quote, capacity reservation, service order or status confirmation.

The fourth failure path is control and exit. The customer should ask whether it can export VM images, disks, databases, DNS zones, firewall rules, monitoring data, logs and support history. If a billing account is suspended or the customer portal is unreachable, is there an emergency export path? If the customer uses Anexia-assigned IP addresses, are they portable? If the customer uses its own AS or PI space, will Anexia support BGP, RPKI and IRR updates during a move? The public IP Transit page suggests Anexia understands managed routers and ASN services, but customer exit rights are contractual.

How to read the risk without overstating it

This is not a weak-company file. The evidence is far stronger than for a thin hosting name with an inactive ASN and a dead website. AS42360 is announced. Its prefixes are visible. It sits inside a larger Anexia routing structure with AS47147 and AS42473. Anexia publishes detailed infrastructure, power, monitoring, storage, DDoS, certification and data-protection material. Its legal and RIPE records are consistent enough to support a real operating company. A buyer can reasonably include Anexia in a serious hosting or cloud procurement process.

The risk is more subtle: public evidence is strong at the group and route-visibility level, but less complete at the exact-service level. AS42360's current public neighbor concentration through AS47147 is not necessarily bad, but it is a dependency to understand. The lack of a PeeringDB profile for AS42360 is not necessarily bad, but it means AS42473's PeeringDB data should not be misread as AS42360-specific interconnection proof. The RPKI valid state for IPv6 is positive, while the checked unknown state for one AS42360 IPv4 /24 should be treated as an address-governance watchpoint.

The official global-location claims are positive, while site-specific placement still needs proof.

Customers affected by a failure are not only large enterprises. The product set includes virtual servers, managed hosting, colocation, shared storage, DDoS protection, transit and cloud connectivity. A failed route can affect hosted websites, APIs, SaaS platforms, customer portals, backups, test environments, wholesale customers and resellers. A failed storage tier can affect databases and stateful applications. A failed power path can affect racks and customer-owned equipment. A failed support escalation can slow every other recovery step. The physical layer remains present even when the customer interface is virtual.

The practical buyer read is therefore balanced. Anexia has enough public evidence to be considered a credible European infrastructure provider with global reach. EUROPE Anexia Cloud Solutions GmbH, through AS42360, has live route evidence and a clear parent-network dependency. For low-risk workloads, the public evidence may be enough to justify direct commercial inquiry.

For production workloads, the buyer should require prefix-specific routing proof, site-specific capacity and power scope, backup and restore test evidence, DDoS and route-mitigation terms, data-location schedules, support escalation contacts, export rights and RPKI/IRR hygiene for the exact addresses assigned.

The final evidence grade is Medium. The positive evidence is substantial: current AS42360 announcements, full RIS visibility for checked prefixes, a visible Anexia parent network, detailed Anexia infrastructure pages, legal entity records, GDPR materials and certifications. The unresolved evidence is also material: AS42360 has a single observed neighbor in RIPEstat, AS42360 lacks its own PeeringDB profile, at least one checked IPv4 prefix returned RPKI unknown for AS42360, and public pages do not prove the exact rack, site, spare inventory or restore time behind a customer's service.

Hosted capacity is credible here, but the buyer should verify the physical and contractual recovery surface before treating it as resilient.