Résumé

  • ZAP-Hosting GmbH dispose d'une piste légale, produit et de routage concrète. Lesmentions légalesindiquent ZAP-Hosting GmbH au Hafenweg 8, 48155 Muenster, Allemagne, avec Marvin Kluck comme PDG et HRB 15672 au Amtsgericht Muenster, tandis que les enregistrements RIPE lient AS206996 à ZAP-Hosting GmbH.
  • L'entreprise vend un large éventail de capacités hébergées:hébergement VPSavec KVM, stockage NVMe/SSD, protection DDoS et connectivité annoncée à 40 Gbit/s;hébergement de serveurs dédiésavec matériel nu et cartes réseau 10 Gbit/s;hébergement de serveurscouvrant les cas d'utilisation VPS, serveur racine et serveur de jeux; et des produits de jeux ou voix dans plus d'emplacements que le parc de serveurs dédiés.
  • La carte des emplacements publics n'est pas un cloud global uniforme. Ladocumentation des emplacementsde ZAP liste Francfort/Eygelshoven comme le seul emplacement où les serveurs de jeux, TeamSpeak, VPS et serveurs dédiés sont tous disponibles; Los Angeles, Dallas et Ashburn supportent les serveurs de jeux, TeamSpeak et VPS; Londres, Montréal, Sydney et Singapour supportent les serveurs de jeux et TeamSpeak mais pas les VPS ou serveurs dédiés dans cette matrice.
  • Les preuves réseau sont solides pour l'identité et le routage actif. Lavue d'ensemble ASde RIPEstat identifie AS206996 comme zap-hosting ZAP-Hosting GmbH, et lestatut de routagede RIPEstat a montré, pour la fenêtre de publication du 12 juillet 2026, 85 préfixes IPv4, 21 760 adresses IPv4 et trois préfixes IPv6 avec une visibilité complète RIPE RIS.
  • Les preuves de résilience sont plus limitées. Lesconditionsgarantissent une accessibilité moyenne annuelle du serveur de 99,5 % mais excluent les problèmes hors du contrôle de ZAP, réservent le droit de verrouiller ou supprimer après des retards de paiement, et placent la responsabilité de la sécurisation des données sur le client. Ladocumentation sur le stockage de sauvegardedécrit un stockage de sauvegarde utile, mais ce n'est pas la même chose qu'un plan de reprise complet testé.

La promesse de ZAP est la rapidité, mais sa dépendance est physique

ZAP-Hosting GmbH vend la rapidité comme une caractéristique produit. La navigation publique mise sur « serveur instantané en ligne »; lapage VPSindique qu'un serveur privé virtuel Linux ou Windows peut être provisionné en quelques minutes; lapage d'hébergement de serveursprésente le catalogue autour des VPS, serveurs racines et serveurs de jeux; et lapage de serveurs dédiéspromet du matériel nu pour les clients qui souhaitent du matériel complet plutôt qu'un partage virtualisé. Cette vitrine vise un marché qui achète souvent rapidement: les communautés de jeux, les groupes FiveM, les utilisateurs de TeamSpeak, les développeurs, les petits projets web, les opérateurs de bots et les clients qui veulent un accès root sans négocier un contrat de colocation.

La surface opérationnelle derrière cette promesse n'est pas rapide. Elle est lente, lourde et spécifique à l'emplacement. Un VPS a besoin de serveurs hôtes, de stockage, de nœuds de virtualisation, d'attribution d'adresses, de filtrage DDoS, d'un panneau de contrôle client, de files d'attente de support et d'assez de matériel de rechange pour absorber la croissance. Un serveur dédié nécessite un châssis particulier, un ensemble de disques, un chemin de gestion à distance, un port de commutateur, une alimentation électrique, un emplacement de baie et un chemin de technicien lorsqu'un composant tombe en panne.

Un serveur de jeux peut être provisionné en quelques secondes du point de vue du client, mais il dépend toujours de l'ordonnancement CPU, de la mémoire, du stockage, du traitement UDP, de la politique anti-DDoS et de la distance réseau entre les joueurs et la région sélectionnée.

C'est pourquoi ZAP mérite d'être examiné en tant que fournisseur de capacité hébergée plutôt que seulement comme une boutique web. Lesmentions légalesde l'entreprise fournissent un ancrage légal: ZAP-Hosting GmbH, Hafenweg 8, 48155 Muenster, Allemagne, avec Marvin Kluck nommé PDG, HRB 15672 au Amtsgericht Muenster, numéro de TVA DE 320366231, et contacts pour les abus et les autorités. Sapolitique de confidentialitérépète la même adresse et dit que le site web collecte des données de journal de serveur telles que le type de navigateur, le système d'exploitation, le référent, les pages visitées, la date, l'heure et l'adresse IP pour des raisons techniques. Ces pages ne prouvent pas la résilience de l'infrastructure, mais elles établissent que la vitrine, l'opérateur légal et la surface des données de compte font partie de la même empreinte commerciale allemande.

Les pages produits transforment l'identité légale en question d'infrastructure. Lapage de serveurs dédiésde ZAP indique que les serveurs dédiés sont des machines nues complètes, pas des serveurs virtuels partageant un hôte, avec des options Intel Xeon E5v2, jusqu'à 256 Go de RAM, du stockage SSD et des cartes réseau 10 Gbit/s SFP+ dans les configurations annoncées. La même page dit que les serveurs dédiés incluent l'accès ILO, le RAID matériel, un gestionnaire DDoS, le DNS inverse et la gestion IP, et une gestion automatique des pannes qui avertit les techniciens en cas de défauts matériels. Ce ne sont pas des slogans cloud. Ce sont des rappels que le service dépend d'un matériel spécifique et des personnes capables de le réparer.

Lapage VPSva dans une direction différente. Elle présente la virtualisation KVM, AMD EPYC Milan, le stockage NVMe/SSD, la protection DDoS, le trafic non mesuré selon des conditions d'utilisation raisonnables, le DNS inverse, les options de bureau à distance et une connectivité allant jusqu'à 40 Gbit/s. Un client achetant ce produit ne loue pas la machine entière; il loue une part d'un hôte, de stockage et de système réseau dont les performances dépendent de la densité de l'hôte, des contrôles de voisinage bruyant, de la contention de stockage, du filtrage DDoS, de l'automatisation logicielle et de la quantité de capacité inutilisée dans l'emplacement choisi. ZAP peut vendre à la fois des VPS et des serveurs dédiés sous une seule marque car la vitrine commerciale est partagée. Les modes de défaillance ne le sont pas.

La meilleure lecture des documents publics de ZAP n'est donc ni cynique ni crédule. Il y a de véritables preuves d'infrastructure. Il y a des lieux nommés, des modèles de matériel, des enregistrements de routage, des fournisseurs DDoS, des outils de sauvegarde et des voies de support. Mais le mot « hébergement » ne dit pas au client si son service est protégé contre une baie défaillante, un fournisseur amont défaillant, un renouvellement de paiement échoué, une restauration échouée, un emplacement complet, ou une file d'attente de support après un incident régional. Ces questions doivent être posées au niveau du produit et de l'emplacement.

La carte des emplacements est une carte produit, pas un cloud unique

Les preuves d'emplacement de ZAP sont inhabituellement spécifiques pour un fournisseur d'hébergement de masse, mais elles doivent être lues comme une matrice produit plutôt que comme une garantie de centre de données global. Ladocumentation des emplacementsindique que ZAP a étendu ses services depuis sa fondation en 2010 et maintient un réseau global façonné par la demande des clients. Elle liste ensuite la disponibilité par produit: Francfort/Eygelshoven, DE supporte les serveurs de jeux, TeamSpeak, VPS et serveur dédié; Londres, UK supporte les serveurs de jeux et TeamSpeak mais pas les VPS ou serveurs dédiés; Los Angeles, Dallas et Ashburn supportent les serveurs de jeux, TeamSpeak et VPS mais pas les serveurs dédiés; Montréal, Sydney et Singapour supportent les serveurs de jeux et TeamSpeak mais pas les VPS ou serveurs dédiés dans le tableau.

Cette division change la conversation sur la résilience. Une carte qui dit que ZAP a des emplacements en Allemagne, aux États-Unis, au Royaume-Uni, au Canada, en Australie et à Singapour n'est pas la même chose qu'une carte qui dit qu'un client peut placer le même type de charge de travail dans chaque région. Cela signifie qu'une communauté de jeux peut choisir une région de latence qu'un client de serveur dédié ne peut pas. Cela signifie qu'un client VPS peut choisir des régions américaines qu'un client de serveur dédié ne peut pas.

Cela signifie qu'un client allemand de serveur dédié peut avoir moins d'options de relocalisation pratique dans l'ensemble de produits ZAP qu'un client de serveur de jeux.

Les pages produits publiques font le même point de manière plus concrète. Sur lapage VPS, ZAP décrit Dallas, Ashburn et Los Angeles comme des emplacements avec son propre matériel et sa technologie réseau dans les installations Psychz, tout en décrivant également la configuration de Francfort/Eygelshoven comme la principale infrastructure allemande de ZAP. Sur lapage de serveurs dédiés, la section emplacement se concentre sur FFM/Eygelshoven, GER, avec du matériel dédié, des commutateurs Juniper et un emplacement principal à Francfort-sur-le-Main. C'est un signal allemand fort, pas une preuve de capacité dédiée globale interchangeable.

Pour les clients, la matrice des emplacements doit être convertie en une déclaration de placement de service. Si le service commandé est un serveur de jeux, quelle région transporte réellement les joueurs? S'il s'agit d'un VPS, laquelle des régions VPS prises en charge est utilisée, et peut-elle être déplacée sans réinstaller ou changer d'adresses publiques? S'il s'agit d'un serveur dédié, le placement pratique est-il uniquement en Allemagne? S'il s'agit d'un serveur racine ou d'un pack d'espace web, quelles pages et conditions sous-jacentes s'appliquent?

Si le service est annoncé comme « à vie », que se passe-t-il s'il est inactif ou si l'emplacement est modifié?

La matrice importe également pour la souveraineté des données. ZAP est une entreprise allemande, mais tous les services hébergés par ZAP ne sont pas nécessairement en Allemagne. Un serveur de jeux à Singapour, un service TeamSpeak à Londres, un VPS à Dallas et un serveur dédié à Francfort/Eygelshoven ont des histoires de localité légale et opérationnelle différentes. Lapolitique de confidentialitéest utile pour les données du site web et du compte, mais une question de placement de charge de travail nécessite des preuves spécifiques au service: où vivent les fichiers, où les sauvegardes sont stockées, où les journaux sont conservés, où le support peut accéder au système, et où le trafic est filtré.

C'est la première leçon pratique. Le client ne devrait pas seulement demander: « Est-ce que ZAP a des emplacements globaux? » Il devrait demander: « Quel produit est disponible à mon emplacement choisi, quelle capacité y est installée, quelles fonctionnalités y sont indisponibles, et que se passe-t-il si j'ai besoin de déménager? » L'entreprise donne suffisamment d'informations publiques pour commencer cette enquête. Elle ne rend pas l'enquête inutile.

Francfort/Eygelshoven est la principale histoire de capacité

L'emplacement allemand est le centre de l'histoire de l'infrastructure publique de ZAP. Lapage VPSdit que ZAP offre sa propre infrastructure de serveur avec son propre réseau et son matériel dédié à son emplacement principal à Francfort-sur-le-Main, et dit que l'entreprise a été fondée à cet emplacement en 2010. Elle dit également que le centre de données SkyLink Tier III à Eygelshoven, près d'Aix-la-Chapelle et directement à la frontière néerlandaise, a été introduit en mars 2020 comme une branche du centre de données de Francfort, avec tout le trafic routé via Francfort afin que les clients bénéficient de la qualité de connexion et de la protection DDoS. Lapage de serveurs dédiésrépète le même cadrage d'emplacement allemand et donne une adresse à Francfort: Dieselstrasse 37, 60314 Frankfurt am Main.

Ce libellé est utile car il indique aux clients où se situe l'évidente dépendance allemande. Ce n'est pas seulement « Allemagne » comme étiquette de pays. C'est une paire opérationnelle Francfort/Eygelshoven où la page publique dit que le trafic d'Eygelshoven est routé via Francfort. Si un client se soucie de la localité, de la latence, du filtrage DDoS, des fenêtres de maintenance ou de la diversité des routes, cela compte. Francfort peut être le point de concentration du trafic et de la protection même lorsque l'équipement est physiquement à Eygelshoven.

Une défaillance dans une installation secondaire est différente d'une défaillance dans le chemin de trafic dont dépend l'installation secondaire.

Le détail du matériel est également concret. Les pages produits de ZAP décrivent des commutateurs Juniper, des systèmes blade HP C7000 G3 ProLiant, des blades HP G8/G9, des processeurs E5-2690v2/v4, de la mémoire ECC et des commutateurs 10G SFP+ pour l'infrastructure allemande. Ces affirmations ne prouvent pas l'inventaire actuel jusqu'à chaque baie, mais elles montrent le type de parc vendu: châssis blade, commutation partagée, machines dédiées, hôtes de virtualisation et matériel réseau privé.

Une défaillance de châssis blade, une défaillance de commutateur top-of-rack, un événement de pression de stockage ou une pénurie de capacité affecteraient les clients différemment selon qu'ils ont acheté un VPS, un serveur de jeux ou un serveur dédié.

L'histoire DDoS allemande est le seul endroit où les pages publiques nécessitent une manipulation prudente. Lapage VPSet lapage de serveurs dédiésdécrivent la protection DDoS Combahton avec le pré-filtrage Corebackbone à Francfort et Eygelshoven depuis décembre 2019. Ladocumentation plus récente sur la protection DDoSindique que différents systèmes de protection sont déployés par emplacement et liste PletX pour FFM/Eygelshoven. Lapage plus détaillée sur la protection DDoS PletXdit que la protection est adaptée à chaque emplacement de centre de données, tandis que lesite public de PletXdécrit la protection DDoS pour les serveurs de jeux et les réseaux d'entreprise.

Ce changement apparent ne doit pas être lu comme un scandale; les fournisseurs changent de fournisseurs d'atténuation et la documentation peut vieillir de manière inégale. Il doit être lu comme une question d'assurance. Un client plaçant un service de jeux sensible à la latence ou sujet aux attaques en Allemagne devrait demander quelle pile DDoS est active pour le service commandé maintenant, où se produit le filtrage, s'il y a une visibilité en temps réel des attaques dans le gestionnaire DDoS, comment les faux positifs sont traités, et si le trafic vers Eygelshoven traverse toujours Francfort.

Si la page produit et la documentation nomment différents fournisseurs d'atténuation, la commande actuelle devrait régler la question.

Il en va de même pour la réparation. La page dédiée de ZAP mentionne une gestion automatique des pannes qui informe les techniciens après des défauts matériels. C'est précieux pour le remplacement de matériel. Ce n'est pas la même chose qu'un engagement de délai de récupération publié pour chaque composant. Le remplacement d'une blade, d'un disque, d'un contrôleur RAID ou d'un commutateur peut être rapide seulement si les pièces de rechange, les mains à distance, les autorisations d'accès et le temps du personnel s'alignent.

Pour les clients utilisant des serveurs dédiés bon marché comme infrastructure de production, la fenêtre de réparation fait partie du prix.

Les emplacements américains sont une portée hébergée, pas une indépendance de campus propriétaire

L'empreinte américaine de ZAP est décrite avec une limite différente. Lapage VPSdit qu'à Dallas, ZAP a emménagé dans le Psychz centres de données au Texas avec son propre matériel et sa technologie réseau, des commutateurs Juniper EX3300 avec des liaisons montantes 4x10G SFP+, des serveurs Dell R720 avec des processeurs Xeon, une forte protection DDoS et un support de première ligne sur site avec un technicien 24h/24. Elle donne une adresse à Dallas: 1515 Round Table Dr, Dallas, TX 75247.

Pour Ashburn, la même page décrit un centre de données Psychz en Virginie, du matériel et une technologie réseau ZAP, des commutateurs Juniper QFX5100 avec des liaisons montantes 40G QSFP+, des serveurs HP C7000 Bladecenter et un support de première ligne sur site avec des techniciens 24h/24. Elle donne l'adresse de Psychz Network: 3873 Park Center Rd #75, Herndon, VA 20171. Pour Los Angeles, la page décrit à nouveau un centre de données Psychz en Californie, des commutateurs Juniper QFX5100 et des serveurs HP C7000 Bladecenter, avec une adresse au 700 Wilshire Boulevard.

Ce sont des signaux d'emplacement forts. Ils indiquent à un acheteur que la portée VPS américaine n'est pas simplement une étiquette CDN ou une ligne de revendeur dans un panneau. Les pages revendiquent du matériel et une technologie réseau appartenant à ZAP dans des installations Psychz nommées. En même temps, elles montrent la limite de l'opérateur. L'installation, l'accès physique, le support de première ligne sur site et certaines conditions amont ne sont pas simplement des affaires internes de ZAP.

Ils dépendent de l'hôte du centre de données, du processus local de mains à distance, du chemin DDoS local, de l'expédition ou de l'inventaire de pièces de rechange, et de tout cross-connect ou arrangement amont sur ce site.

Cette limite est normale dans l'hébergement. Les fournisseurs petits et moyens placent souvent leurs propres serveurs et commutateurs dans des centres de données tiers. Le risque client n'est pas que ce modèle soit illégitime. Le risque est de supposer que « notre propre matériel » signifie une indépendance opérationnelle totale. Si un site Psychz a un problème d'alimentation, d'accès, de sécurité, de mains à distance ou d'amont, un client ZAP peut le vivre comme un incident de service ZAP même si une étape de réparation clé est en dehors des mains directes de ZAP.

La documentation DDoS ajoute une autre limite. Ladocumentation principale DDoSindique que ZAP utilise différents systèmes de protection selon l'emplacement du centre de données et l'infrastructure réseau. Elle liste actuellement PletX pour FFM/Eygelshoven et OVH pour Londres/Singapour sur la page de comparaison, tandis que le texte de la page produit pour Ashburn décrit un matériel de filtre interne utilisant un logiciel de protection aurologic développé plus loin à l'emplacement de Francfort. Ce mélange devrait amener les clients à demander quel emplacement américain utilise quel chemin d'atténuation aujourd'hui. Un serveur de jeux sous attaque n'a pas de patience pour une réponse vague sur « une forte protection DDoS ».

La capacité américaine change également le tableau de la souveraineté des données. Un fournisseur allemand peut héberger des charges de travail américaines. Un client allemand peut choisir un emplacement américain pour la latence vers les joueurs américains. Un client américain peut acheter auprès d'une entreprise allemande. La bonne question de conformité n'est pas seulement la nationalité du fournisseur. C'est là où se trouvent réellement les données de production, les sauvegardes, les journaux, les données de compte et l'accès au support, et si le client est à l'aise avec l'étendue légale et opérationnelle.

La portée des jeux et de la voix ne doit pas être confondue avec la profondeur de la flotte de serveurs

La promesse géographique la plus large de ZAP se trouve dans l'hébergement de jeux et de voix. Ladocumentation des emplacementsliste Londres, Montréal, Sydney et Singapour pour les serveurs de jeux et TeamSpeak, même là où la disponibilité des VPS et serveurs dédiés est marquée comme indisponible. Cela a du sens pour le marché. Les communautés de jeux et de voix se soucient beaucoup de la latence, et un fournisseur peut supporter ces produits dans des régions où il n'offre pas le catalogue complet de VPS ou de bare-metal.

L'erreur serait de traiter cette portée comme une redondance cloud générale. Un client ne peut pas déduire d'un emplacement de serveur de jeux à Singapour qu'il peut placer un serveur dédié ZAP à Singapour. Une option TeamSpeak à Londres ne prouve pas qu'un produit VPS londonien existe. Un emplacement de jeux à Montréal ne prouve pas un accès root contrôlé par le client, un réseau personnalisé, des machines dédiées ou des options de migration pour une charge de travail web. La matrice produit dit le contraire pour plusieurs régions.

Les pages DDoS montrent la même nuance. Lapage de protection DDoS OVHdit qu'OVH opère une infrastructure anti-DDoS toujours active, surveille le trafic en temps réel, redirige les attaques vers un réseau de nettoyage et propose des couches de filtrage spécifiques aux jeux pour les services UDP et sensibles à la latence. Lacomparaison principale DDoSindique qu'OVH est utilisé pour Londres et Singapour dans ses emplacements listés et décrit plus tard la couverture OVH pour les emplacements au Royaume-Uni, en Asie et en Australie. C'est une déclaration utile pour les services de jeux et de voix. Cela ne prouve toujours pas la capacité, le comportement de perte de paquets ou la gestion des faux positifs pour chaque titre et chaque modèle d'attaque.

L'hébergement de serveurs de jeux introduit également différents chemins de défaillance. Une application web peut échouer parce que le stockage a disparu ou qu'une base de données est inaccessible. Un service de jeux peut rester « en ligne » alors que l'expérience est inutilisable parce que le filtrage UDP est trop agressif, que la fréquence CPU est insuffisante pour un serveur moddé, que le stockage plante lors de la sauvegarde du monde, ou que les joueurs sont routés via un chemin de nettoyage éloigné.

Un service TeamSpeak peut être techniquement joignable alors que la qualité est mauvaise parce que la gigue ou la perte de paquets est trop élevée pour la communauté. Ce ne sont pas des détails secondaires pour le marché de ZAP; ce sont le produit.

C'est pourquoi les signaux clients non officiels peuvent être informatifs mais limités. Les pages d'avis publics et les publications communautaires peuvent montrer que de nombreux utilisateurs consommateurs interagissent avec le service, se plaignent du support, louent la rapidité de configuration ou discutent des performances. Ils ne peuvent pas prouver l'inventaire en baie, la capacité de réserve, les fournisseurs amont actuels, ou le comportement de récupération d'une région spécifique. Si un acheteur utilise les avis, il devrait les utiliser comme signaux de demande et de charge de support, pas comme preuve d'infrastructure.

La distinction d'emplacement importe également pour la migration. Si une communauté passe de Londres à Francfort ou de Singapour à un autre fournisseur, le travail technique ne consiste pas seulement à copier des fichiers. Il inclut les changements d'adresse publique, les enregistrements DNS ou SRV, la configuration du jeu, les mods, les données des joueurs, les permissions, le timing de sauvegarde, les changements de profil anti-DDoS et la notification aux utilisateurs. Plus un serveur de jeux est facile à démarrer, plus il est facile d'oublier combien de pièces doivent bouger lors d'une panne.

AS206996 est une véritable surface de routage public

La preuve d'infrastructure indépendante la plus forte est l'enregistrement de routage. Lavue d'ensemble ASde RIPEstat pour AS206996 identifie le titulaire comme zap-hosting ZAP-Hosting GmbH et marque l'ASN comme annoncé. Lestatut de routagede RIPEstat a montré AS206996 visible de 327 pairs à alimentation complète IPv4 de RIPE RIS sur 327 et 322 pairs à alimentation complète IPv6 sur 322, avec la dernière route vue dans cette vue le 12 juillet 2026. Le même instantané rapportait 85 préfixes IPv4 couvrant 21 760 adresses IPv4 et trois préfixes IPv6 couvrant 12 288 /48.

Ce n'est pas un enregistrement de route mince. Lavue des préfixes annoncéslistait 88 entrées de préfixes actuelles dans la fenêtre de révision, y compris des IPv4 /24 tels que 147.189.171.0/24, 5.249.160.0/24, 194.62.1.0/24 et les routes IPv6 2a0c:3580:1000::/36, 2a0c:3580:2000::/36 et 2a0c:3580:3000::/36. Les vérifications de lavue d'ensemble du préfixede RIPEstat sur des préfixes représentatifs reliaient ces annonces à AS206996 et à la chaîne de titulaire ZAP-Hosting.

Les preuves du registre RIPE sont également cohérentes. Lesdonnées whoisde RIPEstat pour AS206996 et l'objet aut-numde RIPE REST montrent as-name zap-hosting, org ORG-ZHG2-RIPE, statut assigné, et lignes de politique référençant AS49581, AS62403 et AS44592. L'objet organisationde RIPE REST liste ZAP-Hosting GmbH comme un LIR DE à Hafenweg 8, 48155 Muenster, Allemagne, avec une création en 2019 et une date de dernière modification en 2026 dans l'enregistrement vérifié. Ces entrées ne prouvent pas la qualité de service, mais elles prouvent une relation de registre vivante.

Les agrégateurs de routage indépendants s'accordent largement sur les grandes lignes.BGP.tools pour AS206996identifie le réseau comme ZAP-Hosting GmbH, actif dans RIPE, avec un large ensemble de préfixes IPv4 et trois préfixes IPv6.La boîte à outils BGP de Hurricane Electricliste AS206996 comme ZAP-Hosting GmbH et montre les routes IPv4 et IPv6 originaires.La page AS206996 de IPinfonomme ZAP-Hosting GmbH et catégorise l'ASN comme hébergement.Cloudflare Radarfournit une autre lentille de routage public pour l'ASN.

La note de routage est donc forte pour l'identité et la présence active. Ce n'est pas un chèque en blanc pour la résilience. Un nombre de préfixes ne dit pas à un acheteur si son service se trouve sur une seule baie ou plusieurs, si tous les emplacements de jeux sont derrière le même fournisseur DDoS, si une route locale a suffisamment de capacité de réserve sous attaque, ou si chaque préfixe a une maturité opérationnelle correspondante. Les preuves de routage disent que ZAP a une surface réseau publique significative. Les preuves d'architecture doivent encore être spécifiques au produit.

Les preuves de transit et d'interconnexion présentent des lacunes

Le tableau public du transit est plus étroit que le nombre de préfixes. Lavue des voisins ASNde RIPEstat a montré deux voisins observés dans l'instantané: AS40676 et AS62403. La vue d'ensemble AS de RIPEstat identifieAS40676comme Psychz Networks etAS62403comme PletX GmbH. Les lignes de politique aut-num de RIPE, quant à elles, référencentAS49581Tube-Hosting, AS62403 PletX, etAS44592SkyLink centres de données BV.

Ces noms ont du sens à côté des pages produits publiques: Psychz apparaît dans les descriptions d'emplacements américains, PletX apparaît dans la documentation DDoS, et SkyLink apparaît dans la description du centre de données d'Eygelshoven. Mais les voisins BGP observés et les lignes de politique d'import/export RIPE ne sont pas la même chose. Les routes observées peuvent changer avec les points de vue de mesure, l'ingénierie du trafic et les chemins temporaires. Les lignes de politique du registre peuvent être obsolètes, larges ou ne pas refléter pleinement le routage en direct.

L'article peut les utiliser comme preuve d'une carte de dépendance plausible; il ne doit pas les traiter comme un registre de contrats en direct.

PeeringDB n'ajoute pas grand-chose dans ce cas. Unerequête API PeeringDB pour AS206996n'a retourné aucune entité réseau dans la réponse vérifiée. Lapage à proposde PeeringDB décrit le service comme une base de données maintenue par les utilisateurs pour les réseaux, les échanges, les installations et les informations d'interconnexion. L'absence de PeeringDB ne signifie pas que ZAP n'a pas d'installations ou de présence d'échange. Cela signifie que les lecteurs publics ne peuvent pas utiliser cette base de données pour confirmer les points d'échange, les listes d'installations, les niveaux de trafic, la politique de peering ou les contacts d'exploitation réseau.

La validation d'origine de route est plus encourageante dans des échantillons vérifiés. Lavalidation RPKIde RIPEstat a retourné un statut valide pour le préfixe IPv4 actuel représentatif 147.189.171.0/24, et les vérifications pour 5.249.160.0/24, 194.62.1.0/24 et 2a0c:3580:1000::/36 ont également retourné un statut valide dans la révision. C'est un signe utile d'hygiène d'origine de route. C'est encore un signe ponctuel à moins que chaque route actuelle ne soit vérifiée en continu, et la validation d'origine RPKI ne protège pas contre tous les problèmes de routage.

La question pratique du client est plus étroite que « Qui est le transit de ZAP? » C'est: pour ce service et cet emplacement exacts, quel fournisseur transporte l'entrée et la sortie, où le filtrage DDoS est-il appliqué, que se passe-t-il si l'amont observé est dégradé, et combien de trafic peut être absorbé après la défaillance d'un chemin? Un client de serveur de jeux à Ashburn, un client VPS à Francfort/Eygelshoven et un client TeamSpeak à Singapour peuvent avoir des réponses différentes.

La protection DDoS est une dépendance produit, pas une fonctionnalité secondaire

La protection DDoS est centrale pour le marché de ZAP. Les serveurs de jeux, les serveurs vocaux et les produits VPS bon marché attirent les abus, le trafic de bots, les inondations UDP, les attaques de rivalité et les scanners mal configurés. Ladocumentation sur la protection DDoSde ZAP indique que l'entreprise utilise des solutions de protection éprouvées adaptées à l'emplacement du centre de données, fonctionnant automatiquement et en temps réel pour filtrer le trafic malveillant avant qu'il n'affecte les performances ou la disponibilité. Le tableau de comparaison liste la protection toujours active, la protection de base, le filtrage réseau et applicatif, le filtrage spécifique aux jeux et aucune interruption pendant l'atténuation pour les catégories PletX et OVH, tandis que la visualisation de surveillance en temps réel dans le gestionnaire DDoS est listée pour PletX mais pas pour OVH.

Cette distinction est précieuse car elle relie l'expérience du client à un choix de fournisseur spécifique à l'emplacement. Un service allemand derrière PletX peut exposer une visibilité et des boutons de filtrage d'attaque différents d'un service londonien ou singapourien derrière OVH. Un service américain peut utiliser un autre chemin décrit sur les pages produits. Un client qui a besoin de comprendre une panne ne peut pas s'arrêter à « protégé DDoS ».

Il devrait savoir quel réseau d'atténuation voit l'attaque, quels protocoles sont filtrés, quel trafic est abandonné, comment les faux positifs sont escaladés, si les règles de pare-feu du client interagissent avec l'atténuation, et si le trafic propre a un chemin plus long pendant l'atténuation.

Lapage DDoS OVHdécrit une surveillance permanente, une redirection automatique vers un réseau de nettoyage et un filtrage supplémentaire spécifique aux jeux pour les protocoles UDP. Lapage DDoS PletXcadre le filtrage autour des emplacements des centres de données de ZAP et du système PletX. Lesite public de PletXdécrit l'atténuation à l'aide d'un logiciel basé sur XDP/eBPF et le traçage de connexions. Ces pages sont un contexte utile, mais elles ne sont pas un rapport d'attaque mesuré pour un service ZAP donné.

La dépendance DDoS change également le support. Lors d'une attaque, le client peut avoir besoin du support ZAP, de l'équipe politique du fournisseur d'atténuation, d'une action de l'installation ou de l'amont, et parfois de changements au niveau de l'application. Si le trafic d'un joueur est mal classifié comme trafic d'attaque, une communauté de jeux le vit comme une indisponibilité même si le serveur est en ligne. Si une grande attaque sature une liaison avant le nettoyage, le service peut être dégradé avant que la politique d'atténuation ne compte.

Si une route est dirigée via un centre de nettoyage distant, la latence peut augmenter suffisamment pour rendre un jeu injouable.

Pour ZAP, la bonne note publique n'est pas « DDoS non prouvé ». L'entreprise publie plus d'informations sur l'atténuation que de nombreux petits fournisseurs d'hébergement, et sa table de routage est active. La bonne note est « DDoS spécifique au service ». Le chemin de protection fait partie intégrante du service acheté, et les clients devraient traiter le fournisseur DDoS, l'emplacement, la visibilité et l'escalade comme faisant partie du contrat d'hébergement.

Le stockage de sauvegarde est utile, mais la récupération reste la responsabilité du client

La documentation de sauvegarde de ZAP est pratique et modeste. Lapage de stockage de sauvegardeindique que chaque compte comprend 10 Go de stockage de sauvegarde gratuit, extensible jusqu'à 200 Go moyennant des frais. Elle indique que les sauvegardes sont créées à partir de l'interface web du service respectif, stockées centralement, restaurées directement via la fonction de sauvegarde du service ou téléchargées pour un stockage local, et accessibles via FTP en utilisant des identifiants affichés dans l'interface web. Elle dit également que la zone messages enregistre les actions liées aux sauvegardes.

C'est un bon ensemble de fonctionnalités pour les petits clients d'hébergement. Cela leur donne un endroit pour copier les sauvegardes de service, un chemin de restauration directe et un moyen de télécharger leur propre copie. Mais cela ne doit pas être confondu avec une reprise après sinistre complète. Dix à deux cents gigaoctets peuvent suffire pour de nombreux mondes de jeux, configurations et petits sites; cela peut être trop petit pour un grand serveur moddé, une bibliothèque multimédia, une base de données, plusieurs images VPS ou un client essayant de maintenir une longue rétention.

Un espace de sauvegarde peut exister alors que la bande passante de restauration, la capacité cible, les changements DNS ou la réparation de l'application restent non testés.

Lesconditionsrendent la responsabilité du client explicite. Elles disent que le client est obligé de sécuriser les données, que les services de sauvegarde fournis par ZAP sont gratuits, et que ZAP n'est pas responsable des dommages en cas de perte de données. Elles disent également que ZAP n'est pas responsable de la perte de données due à un cas de force majeure ou à une erreur humaine, la protection des données sensibles du serveur étant assignée au client. Ce langage contractuel est le bord dur derrière une page de sauvegarde sympathique.

Pour un acheteur, la question opérationnelle n'est pas « Est-ce que ZAP a des sauvegardes? » C'est « Qu'est-ce qui est exactement sauvegardé, à quelle fréquence, où est-ce stocké, quelle taille cela peut-il avoir, puis-je le télécharger sans serveur sain, et combien de temps prend une restauration complète? » Un administrateur de serveur de jeux devrait tester si la sauvegarde inclut les fichiers du monde, les mods, les configurations, les permissions et les fichiers de base de données. Un administrateur VPS ne devrait pas supposer qu'une sauvegarde d'interface web est une image bare-metal complète à moins que le produit ne le dise.

Un client de serveur dédié devrait se rappeler que la récupération bare-metal peut nécessiter une réinstallation du système d'exploitation, une reconstruction RAID, un téléchargement de sauvegarde et une reconstruction de l'application.

L'histoire de la sauvegarde recoupe également le statut du compte. Si un problème de paiement peut verrouiller ou supprimer des services, et si l'accès à la sauvegarde est lié au panneau de contrôle du compte, le client devrait conserver des copies locales indépendantes des éléments qu'il ne peut pas se permettre de perdre. La propre documentation de ZAP soutient cela en offrant des téléchargements via le stockage de sauvegarde. L'utilisation la plus sûre de la fonctionnalité n'est pas seulement la restauration sur place; c'est l'exportation régulière vers un emplacement extérieur au même compte et fournisseur.

Le support est une file d'attente, pas une couche de réparation magique

La documentation de support de ZAP fixe des attentes raisonnables pour un service d'hébergement de masse. Leguide de supportconseille aux clients de vérifier l'état actuel du service, de consulter les journaux, d'inclure les erreurs dans le contenu du ticket, et d'utiliser le système de tickets officiel pour le support lié au compte plutôt que les canaux sociaux. Il indique que les clients peuvent s'abonner par e-mail aux notifications pour les services sur le réseau via le site de statut. Lapage de statutpublique présente une surface de statut centrale, et le pied de page renvoie également àSmokepingpour la visibilité des performances réseau.

Ce sont des signaux positifs. Un fournisseur qui expose l'état et les tests réseau donne aux clients plus qu'une boîte noire. La documentation demande également aux clients des informations de diagnostic, ce qui peut raccourcir la résolution lorsque le défaut se trouve à l'intérieur du système d'exploitation, de la configuration du jeu, de la pile de plugins ou des paramètres IP du client. Ladocumentation du tableau de bord VPSet ladocumentation de la console VNCde ZAP montrent que les clients peuvent accéder à une console de serveur via l'interface web, et leguide VPS sans internetexplique comment VNC peut aider à réparer la configuration réseau lorsque RDP ne fonctionne pas.

Mais le support a toujours des limites de capacité. Lorsqu'un client configure mal un VPS Windows, un ticket et une console VNC peuvent résoudre le problème. Lorsqu'un emplacement de centre de données, un fournisseur d'atténuation, un amont ou un composant de plateforme est dégradé, de nombreux clients peuvent ouvrir des tickets en même temps. La file d'attente de support devient alors partie de la panne. L'expérience client dépend des règles de triage, du personnel, de l'autorité de modifier la politique réseau, de la disponibilité des mains à distance et du fait que la page de statut reflète le composant affecté exact.

Le support a également des limites de périmètre. Si ZAP fournit le serveur mais que le client installe des mods tiers, des plugins de jeux, des bases de données, des applications web ou des pare-feu personnalisés, tous les échecs ne sont pas une faute du fournisseur. La demande du guide de support pour les journaux et les étapes de dépannage reflète cette limite. Un client exploitant une infrastructure de production sur un VPS bon marché devrait donc maintenir son propre runbook, ses identifiants, ses sauvegardes et sa surveillance plutôt que de s'attendre à ce que la file d'attente de tickets du fournisseur serve d'équipe d'exploitation.

Les conditions renforcent cette limite. Elles limitent le service de ZAP à la fourniture de ressources serveur et de connectivité jusqu'au point de transfert de son propre réseau de communication, et elles disent que ZAP ne peut pas influencer le trafic de données en dehors de son propre réseau de communication. C'est un langage contractuel normal, mais cela signifie qu'un client devrait distinguer la panne du fournisseur, la panne de l'amont, le problème de chemin Internet, le problème du FAI local, le problème de filtrage DDoS et la mauvaise configuration du client.

Le support de ZAP peut aider avec certains de ces points; il ne peut pas tous les posséder.

La facturation et les changements de produit peuvent devenir des défaillances d'infrastructure

Les services hébergés échouent souvent par des voies administratives qui semblent ennuyeuses jusqu'à ce qu'elles interrompent la production. Lesconditionsde ZAP disent que le paiement est dû au moment de la commande, que ZAP se réserve le droit de verrouiller les serveurs et autres services après des retards de paiement de plus de sept jours, et qu'elle se réserve le droit de supprimer irrévocablement les serveurs et services après plus de vingt et un jours de retard. Pour les produits de serveurs dédiés, les conditions réservent une suppression irrévocable après plus de dix jours de retard de paiement. Cela fait de l'état de facturation une dépendance directe de disponibilité.

Les mêmes conditions disent que ZAP peut changer un service pour un produit différent si le service original ne peut plus être offert, et peut changer ou étendre les services lorsque le développement technique le nécessite ou le permet, dans un cadre raisonnable pour les clients. Encore une fois, ce n'est pas inhabituel. Les fournisseurs ont besoin de marge pour remplacer le matériel ancien, retirer des produits et gérer les stocks. Mais le client devrait traiter le cycle de vie du produit comme faisant partie du risque.

Un achat « à vie » n'est pas la même chose que la possession d'une unité en baie ou l'utilisation perpétuelle d'une génération de matériel.

Les pages de configuration produit de ZAP montrent un autre couplage commercial-technique. Lapage de configuration du shop VPSdécrit les choix de CPU, mémoire, stockage, adresse IP et bande passante, et avertit sur certains changements qu'une valeur de mise à niveau ou de rétrogradation ne peut pas être changée facilement et qu'une nouvelle installation peut être nécessaire. Cela importe pour la migration et la mise à l'échelle. Si un client découvre lors d'un incident qu'il a besoin de plus de CPU, de mémoire, d'adresses ou de stockage, le changement requis peut ne pas être un simple curseur en direct.

Les serveurs dédiés portent le même problème sous forme physique. Un client bare-metal ne peut pas supposer que le fournisseur peut instantanément ajouter des disques, déplacer une machine, remplacer un châssis ou fournir une pièce de rechange de mêmes spécifications sans stock. La page dédiée de ZAP fait la publicité de configurations et de fenêtres de provisionnement, et son langage de gestion automatique des pannes est utile, mais la capacité matérielle est toujours finie. Si un modèle est indisponible ou si une pièce de rechange est retardée, le client peut devoir migrer vers une configuration différente.

C'est l'économie de l'hébergement sous les prix d'entrée bas. Les clients obtiennent de la rapidité, une flexibilité prépayée, un choix de produits et une capacité relativement bon marché. En retour, ils acceptent des conditions autour du paiement, du changement de produit, du périmètre du support, de la responsabilité des données et de la disponibilité des emplacements. Le meilleur client conçoit pour ce compromis.

Il maintient un renouvellement de paiement sain, exporte les sauvegardes, documente les étapes de reconstruction, vérifie si la mise à l'échelle nécessite une réinstallation, et évite de supposer qu'un serveur bon marché peut être réparé comme une plateforme gérée d'entreprise.

La localité des données est un placement choisi, pas une étiquette de marque

L'identité légale allemande de ZAP est claire. Lesmentions légaleset lapolitique de confidentialitéplacent l'entreprise à Muenster et décrivent le contexte de protection des données allemand pour le site web et la surface du compte. L'objet organisationde RIPE identifie ZAP-Hosting GmbH comme un LIR DE. Ces faits sont utiles pour la contractualisation et la gouvernance au niveau du compte.

Ils ne rendent pas chaque charge de travail allemande. La matrice des emplacements et les pages produits de ZAP montrent des empreintes produit en Allemagne, aux États-Unis, au Royaume-Uni, au Canada, en Australie et à Singapour. Lapage VPSnomme explicitement les installations Psychz américaines. Lesdocuments d'emplacementmontrent des services de jeux et TeamSpeak dans plusieurs régions non allemandes. Un client qui a besoin de résidence des données dans l'UE ne devrait pas se fier uniquement au siège social de l'entreprise. Il devrait sélectionner un emplacement allemand, confirmer où se trouvent les sauvegardes et les journaux, et éviter d'utiliser des emplacements hors UE à moins que le responsable de la conformité ne les accepte.

L'inverse est également vrai. Une communauté de jeux américaine peut préférer Dallas, Ashburn ou Los Angeles pour la latence même si le fournisseur est allemand. Cela peut être un bon choix opérationnel. Cela signifie également que les données de compte, les données de paiement, les communications de support, les journaux de serveur et les données de charge de travail hébergée peuvent ne pas partager une seule géographie légale.

Le client devrait savoir quelles catégories de données se trouvent en Allemagne, lesquelles se trouvent dans la région d'hébergement sélectionnée, et quels systèmes tiers traitent les informations de compte ou de paiement.

La localité des données affecte également la réponse aux incidents. Si un service hébergé en Allemagne tombe en panne et que la sauvegarde est locale au même compte ou région, le chemin de récupération peut rester en Allemagne. Si un service hébergé aux États-Unis a besoin de support depuis l'Allemagne, d'une action d'installation aux États-Unis et d'un filtrage DDoS via un autre fournisseur, l'incident traverse les fuseaux horaires, les fournisseurs et les contextes juridiques. L'utilisateur peut ne voir qu'un statut de panneau de contrôle. La chaîne de réparation réelle peut être beaucoup plus longue.

La souveraineté des données doit donc être traitée comme une discipline de placement, pas une étiquette. ZAP fournit suffisamment d'informations pour qu'un client fasse des choix de localité. Il ne fournit pas une carte de flux de données publique par service. Les clients sérieux devraient demander le placement des données de production, des sauvegardes, des journaux, des données du plan de contrôle, des enregistrements de support, de la télémétrie DDoS et des données de compte, et devraient tester si le service choisi peut être déplacé sans changer ces hypothèses.

La capacité installée n'est pas la même que la capacité utilisable

Le dossier public de ZAP montre une capacité installée significative: un ASN en direct avec des dizaines d'annonces IPv4, des annonces IPv6, un statut LIR allemand, des pages produits avec des détails matériels, des partenaires d'installations américaines nommés, une page de statut, une documentation DDoS et un stockage de sauvegarde. La question plus difficile est de savoir quelle partie de cette capacité reste utilisable après un défaut. La capacité installée est ce qui existe quand tout est sain. La capacité utilisable est ce qui peut porter les clients à travers une défaillance.

La différence importe le plus dans la configuration allemande. Si Eygelshoven est une branche dont le trafic est routé via Francfort, alors le service combiné dépend du chemin de trafic et de protection de Francfort. Si la protection DDoS allemande passe d'un fournisseur à un autre, les hypothèses de route et de support peuvent changer. Si un châssis blade, un commutateur, un chemin d'alimentation ou un profil d'atténuation tombe en panne, les clients affectés peuvent ne pas être en mesure de passer instantanément à une région de jeux distante ou à une région VPS américaine sans changer de produit, de latence ou de conformité.

Cela importe également pour les VPS américains. Dallas, Ashburn et Los Angeles sont des emplacements séparés, mais chacun porte sa propre dépendance d'installation et de mains à distance. Un client ne devrait pas supposer qu'un VPS peut être migré en direct entre ces emplacements sans reconstruction, changement d'adresse ou travail de support. La documentation publique montre les emplacements et le matériel; elle ne fait pas la publicité d'un produit de basculement multisite. Un client qui a besoin de continuité entre régions devrait concevoir sa propre réplication, son basculement DNS, ses sauvegardes et son déploiement d'application.

Pour l'hébergement de jeux et de voix, la capacité utilisable est principalement l'expérience du joueur. Une région peut avoir des serveurs installés, mais si l'atténuation augmente la latence, si les mods de jeux populaires consomment trop de CPU, si les sauvegardes sont trop petites ou si le stockage est saturé, le service peut être techniquement en ligne et commercialement décevant. Une communauté de jeux devrait tester la charge, pas seulement commander la région la moins chère.

Pour les serveurs dédiés, la capacité utilisable dépend du stock et de la réparation. ZAP fait la publicité de configurations bare-metal et de fonctionnalités matérielles, mais si un disque, un contrôleur RAID, une carte mère ou une alimentation tombe en panne, le délai de service dépend des pièces, du personnel, de l'accès à l'installation et de l'état de préparation à la restauration du client. Un serveur dédié est souvent plus prévisible sous charge normale qu'un VPS, mais moins élastique lorsque des changements matériels sont nécessaires.

L'approche la plus sûre pour le client est d'écrire la défaillance qu'il veut survivre. Une baie? Un hôte? Un disque? Un fournisseur DDoS? Une région? Un amont? Un problème de compte? Une file d'attente de support? Ensuite, il devrait demander si le produit ZAP acheté survit réellement à cette défaillance. Sans cette cartographie, « protégé DDoS », « instantané en ligne », « 40 Gbit/s » et « propre matériel » peuvent tous être vrais tandis que le plan de récupération du client reste faible.

Ce qu'un acheteur sérieux devrait demander avant de compter sur ZAP

Un acheteur sérieux devrait commencer par l'identité et le périmètre du service. Le contrat est-il avec ZAP-Hosting GmbH à l'adresse de Muenster listée dans lesmentions légales? Quelle famille de produits est achetée: serveur de jeux, TeamSpeak, VPS, serveur racine, espace web ou serveur dédié? Quelles conditions publiques s'appliquent? Le service est-il prépayé, mensuel ou à vie? Quelles fonctionnalités sont incluses et lesquelles nécessitent une capacité payante séparée?

Ensuite, il devrait tester le placement. Pour les services allemands, la charge de travail se trouve-t-elle à Francfort, à Eygelshoven ou les deux? Si le trafic d'Eygelshoven passe par Francfort, que se passe-t-il lorsque Francfort a un incident réseau ou de chemin DDoS? Pour les VPS américains, quel emplacement Psychz est impliqué? Pour les services de jeux et de voix, l'emplacement choisi supporte-t-il uniquement ce produit, ou le client peut-il migrer vers un VPS ou un serveur dédié dans la même région si nécessaire?

Ensuite, il devrait tester la dépendance réseau. Le service utilise-t-il des adresses AS206996? Quels préfixes actuels portent le service? Quel fournisseur amont ou d'atténuation est sur le chemin? Les ROA RPKI valident-ils l'origine de la route pour le préfixe concerné? Le client a-t-il accès à la télémétrie du gestionnaire DDoS? Lapage de statutcorrespond-elle clairement au service commandé? Les résultats deSmokepingcorrespondent-ils à la base d'utilisateurs du client?

Ensuite, il devrait tester la sauvegarde et la sortie. Le quota de stockage de sauvegarde est-il suffisant? Les sauvegardes sont-elles automatiques ou déclenchées par le client pour le produit? Le client peut-il télécharger une sauvegarde complète via FTP alors que le service original est défaillant? La sauvegarde inclut-elle les bases de données, les plugins, les fichiers de mods, les permissions, les tâches planifiées et la configuration? Si un produit est verrouillé après un retard de paiement, les sauvegardes peuvent-elles encore être exportées? Quel est le temps de reconstruction sur un nouveau produit ou fournisseur?

Enfin, il devrait tester le support et la réparation. Quelles preuves le client devrait-il inclure dans un ticket? Quel chemin de support s'applique aux problèmes de compte, aux problèmes DDoS, aux défauts matériels et à la mauvaise configuration du client? Qui peut faire des changements d'atténuation? Qui peut demander des mains à distance dans un centre de données tiers? Que se passe-t-il en dehors des heures de bureau allemandes? Le remplacement matériel est-il inclus dans le produit de base ou dépend-il du stock disponible et de l'action de l'installation?

Ces questions ne font pas de ZAP un fournisseur inhabituellement risqué. Elles font correspondre le risque visible au service réel. Le dossier public de ZAP est suffisamment solide pour qu'un acheteur puisse poser des questions précises. Le danger est seulement de laisser une vitrine à faible friction se transformer en une hypothèse de résilience à faible friction.

La note des preuves

La note finale des preuves réseau pour zap-hosting ZAP-Hosting GmbH est Forte, avec une réserve sur la résilience du service. Les preuves d'identité sont fortes: lesmentions légales, lapolitique de confidentialité, l'objet organisationde RIPE, l'objet aut-numde RIPE et lavue d'ensemble ASde RIPEstat s'alignent sur ZAP-Hosting GmbH et AS206996. Les preuves de routage sont également fortes: RIPEstat a vu AS206996 annoncé avec 85 préfixes IPv4, 21 760 adresses IPv4 et trois préfixes IPv6 dans la fenêtre de publication, et des pages indépendantes commeBGP.tools,Hurricane Electric,IPinfoetCloudflare Radardonnent des vues publiques globalement cohérentes.

Les preuves produit sont plus fortes que ce qu'une lecture à empreinte légère suggérerait. ZAP publie des matrices d'emplacement, des descriptions matérielles, une documentation DDoS, des procédures de support, des instructions de stockage de sauvegarde, des surfaces de statut et des conditions contractuelles. C'est suffisant pour dire que l'entreprise est un véritable opérateur de capacité hébergée avec une empreinte réseau significative et un centre opérationnel allemand spécifique.

La réserve est que la résilience est encore commandée, pas supposée. Les pages publiques ne prouvent pas la capacité de réserve par baie, le basculement actif-actif entre régions, le fournisseur DDoS actuel à chaque emplacement, le temps de restauration mesuré, la présence d'installations PeeringDB, le débit de support lors d'un incident large ou la qualité de migration sous pression. La conclusion publique la plus forte n'est pas « ZAP est automatiquement résilient ». C'est « ZAP a suffisamment d'infrastructure visible pour que les clients testent la chaîne de dépendance exacte qu'ils achètent ».

Pour un VPS bon marché, cette chaîne peut être acceptable. Pour une communauté de production, un service web commercial ou une plateforme de jeux sensible à la latence, elle devrait être vérifiée avant que la prochaine fenêtre de réparation ne la trouve.