Résumé

  • GIVEME CLOUD SP Z O O a une identité d'entreprise polonaise vérifiable. L'API officielle KRS identifie KRS 0000543543, REGON 36077116400000, NIP 6482773317 et une adresse enregistrée à Varsovie au 9 Cybernetyki; RIPE enregistre la même organisation sous ORG-RSZO27-RIPE, en tant que LIR en Pologne.
  • Le réseau est visiblement routé. RIPE rapporte AS6681, nommégiveme-cloud, avec 9 préfixes IPv4, 2 304 adresses IPv4, 326 des 326 pairs de table complète RIS IPv4 le voyant et 42 voisins observés au point d'observation du 15 juillet 2026. RIPE rapporte AS208566, nommégiveme-waw, avec 2 préfixes IPv4, 512 adresses IPv4, un /29 IPv6 compté comme 524 288 /48s, une visibilité RIS IPv4 et IPv6 complète et 12 voisins observés.
  • PeeringDB auto-déclare AS208566 à Varsovie chez LIM Warsaw, Equinix WA1 et ATMAN Warsaw-2, plus une connexion d'échange Equinix Warsaw de 10 Gbps. Il auto-déclare AS6681 chez Equinix AM1/AM2 Amsterdam et une connexion NL-ix de 10 Gbps. Ces entrées sont des signaux utiles de localisation et d'interconnexion, pas la preuve que Giveme Cloud possède ces installations ou que chaque charge de travail client peut basculer entre elles.
  • Le site web de l'entreprise propose des plans cloud à partir de 12 EUR, fait la publicité de bundles vCPU, RAM et vSSD, indique des tarifs personnalisés pour vCPU, RAM, stockage et incréments de 10 Mbit, et revendique SSD entreprise, stockage HA, une connexion 20 Gb/s pour tous les serveurs, licences Windows, serveurs de messagerie, réseaux internes et support réactif. Les mêmes conditions disent que les utilisateurs sont responsables des sauvegardes, la disponibilité n'est pas garantie sans interruption et les services peuvent être suspendus en cas de problème de paiement ou de compte.
  • La question opérationnelle est donc spécifique. Giveme Cloud semble exécuter ou contrôler un bord de routage public, et il commercialise de vrais services d'hébergement, mais les preuves publiques ne tranchent pas le nombre de serveurs installés, la capacité de réserve utilisable, la conception de la réplication du stockage, l'alimentation des racks, les droits de remote-hands, le stock de matériel, le personnel de support, la diversité contractuelle des upstreams, les tests de reprise ou la portabilité des données clients.
  • Le niveau de preuve est Moyen. Le réseau existe et a une visibilité significative; l'affirmation de résilience cloud reste conditionnelle jusqu'à ce que l'entreprise ou les clients puissent montrer des preuves datées d'installation, d'alimentation, de stockage, de support et de restauration.

Un bord visible, pas une réponse cloud complète

La première erreur serait de rejeter GIVEME CLOUD SP Z O O comme une empreinte légère simplement parce que c'est un petit fournisseur d'hébergement. La seconde erreur serait de laisser une table de routage visible tenir lieu de preuve d'un service cloud récupérable. Le dossier public soutient une position intermédiaire: une véritable entreprise polonaise possède deux ASN routés et une offre cloud auto-décrite, mais les preuves s'arrêtent avant la profondeur opérationnelle dont un client a besoin avant de placer des charges de travail fragiles là-bas.

La couche d'identité est exceptionnellement facile à relier. L'extrait API KRS actuel pour KRS 0000543543identifie GIVEME CLOUD comme une société polonaise à responsabilité limitée, avec REGON 36077116400000, NIP 6482773317 et une adresse à Varsovie au 9 Cybernetyki. L'enregistrement RDAP de RIPE pour ORG-RSZO27-RIPEnomme GIVEME CLOUD SP Z O O, donne la Pologne comme contexte d'organisation, enregistre la même adresse au 9 Cybernetyki et liste le type d'organisation dans l'objet RIPE sous-jacent comme LIR. Lapage d'annuaire BTWpointe donc vers une entreprise qui a des enregistrements administratifs externes, pas seulement une phrase marketing.

La couche réseau est également active. L'aperçu AS de RIPE pour AS6681nommegiveme-cloud GIVEME CLOUD SP Z O Oet marque l'ASN comme annoncé. L'aperçu AS de RIPE pour AS208566nommegiveme-waw GIVEME CLOUD SP Z O Oet le marque également comme annoncé. Le propre site de l'entreprise àgiveme.cloudrésout en193.200.65.34, et lerésultat de chaîne DNS de RIPEmontre cette résolution directe tandis que le DNS inverse pointe vers un modèle de nommage réseau Giveme. C'est une empreinte plus forte qu'une entreprise dormante sans point de terminaison visible.

Pourtant, un client n'achète pas un ASN. Un client achète du calcul qui démarre, du stockage qui conserve l'état, une route qui reste acceptée par le reste d'Internet, un chemin de support qui répond pendant un incident, et un moyen de partir si le service ne convient plus. Ces choses peuvent exister, mais elles ne sont pas entièrement visibles dans les registres publics. Ce profil est donc un test de traduction: ce qui peut être converti de l'enregistrement et des preuves de routage en confiance opérationnelle, et ce qui reste une question pour l'approvisionnement, l'examen du contrat et les tests de service en direct.

Le registre d'entreprise est réel, mais la limite d'adresse mérite d'être vérifiée

L'identité légale est plus solide que celle de nombreux petits profils d'infrastructure. L'extrait KRSrapporte que l'entreprise est une société à responsabilité limitée, enregistrée au KRS le 12 février 2015, l'extrait actuel reflétant l'état au 7 avril 2026 et la dernière entrée datant également du 7 avril 2026. Ses identifiants sont visibles: REGON 36077116400000 et NIP 6482773317. Son siège social et son adresse sont Varsovie, Cybernetyki 9, 02-677.

L'objet organisation de RIPE pointe dans la même direction. L'objet REST pour ORG-RSZO27-RIPEnomme GIVEME CLOUD SP Z O O, donne le paysPL, enregistrereg-nr360771164, marque le type d'organisation comme LIR, liste Cybernetyki 9, 02-677 Varsovie, et montre une date de création du 11 juillet 2019 avec une dernière modification le 13 mai 2026. L'enregistrement RDAP de RIPEexpose la même identité d'organisation, un rôle d'abus et des pointeurs de contact technique. Cette combinaison est importante car elle relie l'entité corporative au contexte du registre de numéros Internet derrière les deux ASN.

Il y a cependant un détail d'adresse qu'un client devrait concilier. Lapolitique de confidentialitéde Giveme Cloud et lesconditions de serviceidentifient Giveme Cloud Sp. z o.o. au Postepu 17a, 02-676 Varsovie. Les registres KRS et RIPE examinés ici montrent Cybernetyki 9, 02-677 Varsovie. Les deux rues se trouvent dans le quartier d'affaires Mokotow de Varsovie, et un changement d'adresse de bureau n'est pas inhabituel. Néanmoins, les contrats, factures, conditions de traitement des données et avis d'abus devraient s'accorder sur l'entité légale et l'adresse de service. Un décalage entre la copie web et les registres n'est pas la preuve d'un défaut opérationnel. C'est une raison de ne pas déduire l'emplacement de l'infrastructure à partir de l'une ou l'autre adresse.

Cette distinction est importante. Une adresse d'entreprise peut être un siège social, une adresse de correspondance ou un bureau de vente. Ce n'est pas automatiquement une salle de données. Ni KRS ni RIPE ne déclarent que Cybernetyki 9 abrite des serveurs clients, des nœuds de stockage, des salles d'alimentation, des salles de fibre ou du personnel de support. L'identité légale est donc établie, tandis que l'empreinte physique du service doit être lue à partir de preuves différentes.

Deux ASN donnent à l'entreprise une surface publique mesurable

AS6681 et AS208566 sont les actifs opérationnels les plus clairs. Lestatut de routage pour AS6681de RIPE rapporte un temps de requête le 2026-07-15T00:00:00, première vue en 2010 avec le préfixe195.191.234.0/23, dernière vue le 15 juillet 2026 avec89.150.33.0/24, 9 préfixes IPv4, 2 304 adresses IPv4 et aucun préfixe IPv6. Sa visibilité IPv4 est complète dans l'ensemble RIS de ce résultat: 326 des 326 pairs de table complète IPv4 voient la ressource. Son nombre de voisins observés est de 42.

AS208566 fournit l'autre moitié de la surface. Lestatut de routage pour AS208566de RIPE rapporte une première vue le 2 août 2019 avec45.128.216.0/24, dernière vue le 15 juillet 2026 avec le même préfixe, 2 préfixes IPv4, 512 adresses IPv4 et un préfixe IPv6. Cette entrée IPv6,2a0e:41c0::/29, est comptée par RIPE comme 524 288 /48s. La ressource est visible par 326 des 326 pairs IPv4 et 322 des 322 pairs IPv6 dans le résultat du statut de routage, avec 12 voisins observés.

Ces chiffres ne sont pas décoratifs. Une entreprise d'hébergement sans bord public actuel ne peut pas démontrer l'accessibilité Internet de base nécessaire pour les services clients sous sa propre politique de routage. Giveme Cloud peut démontrer un bord public. Lerésultat des préfixes annoncés pour AS6681de RIPE liste neuf /24 IPv4 actuels, incluant193.200.64.0/24,193.200.65.0/24,195.191.234.0/24,195.191.235.0/24,45.128.218.0/24,45.128.219.0/24,45.13.27.0/24,89.150.33.0/24et2.152.66.0/24. Lerésultat des préfixes annoncés pour AS208566de RIPE liste45.128.216.0/24,45.128.217.0/24et2a0e:41c0::/29.

La conclusion correcte est que le réseau est vivant, pas que le cloud est automatiquement résilient. La reachabilité BGP prouve que les préfixes sont annoncés et vus par les collecteurs. Elle ne prouve pas le nombre de serveurs derrière ces routes, la santé de la couche de stockage, la quantité d'alimentation de réserve dans les racks, la capacité du cluster d'hyperviseurs, la qualité des sauvegardes ou la rapidité de la reprise client. Elle donne à l'acheteur un point de départ pour commencer les tests.

L'espace d'adressage soutient le contrôle, pas la capacité

Les registres d'adresses RIPE montrent que Giveme Cloud contrôle ou est associé à plusieurs blocs d'adresses. Lavue WHOIS pour45.128.216.0/22nommePL-GIVEME-CLOUD-20190712, paysPL, organisation ORG-RSZO27-RIPE et le mainteneur Giveme. Lavue WHOIS pour193.200.64.0/23et lavue WHOIS pour195.191.234.0/23utilisent toutes deux le nom de réseaugiveme-cloudet pointent vers la même organisation. La plus récentevue WHOIS pour2.152.66.0/24se situe dans un inetnum enregistré comme2.152.66.0/23et a été créée le 22 juin 2026.

La couche de sécurité de routage semble également intentionnelle. Lavalidation RPKI pour193.200.65.0/24avec AS6681retourne valide. Lavalidation pour45.128.216.0/24avec AS208566retourne valide, de même que lavalidation pour2a0e:41c0::/29avec AS208566. Une autorisation d'origine de route valide n'est pas une disponibilité, mais elle réduit une classe d'ambiguïté de routage en montrant que l'origine observée est autorisée pour le préfixe.

Le site web de l'entreprise ajoute une vérification utile. Une recherche DNS et laréponse de la chaîne DNSde RIPE placentgiveme.cloudà193.200.65.34, à l'intérieur d'un bloc que RIPE enregistre sous Giveme Cloud et que AS6681 annonce actuellement comme193.200.65.0/24. C'est plus fort qu'un site hébergé sur une plateforme commerciale non liée, car le site web public lui-même se trouve sur l'espace routé de l'entreprise.

Mais l'espace d'adressage n'est pas une capacité de calcul. Un /24 peut accueillir de nombreux serveurs, quelques machines virtuelles ou seulement un site web et des services de gestion. L'espace IPv6 peut être vaste sur le papier et peu utilisé en pratique. L'inventaire des adresses ne dit pas grand-chose sur la réplication des disques, la pression mémoire, les hôtes de réserve, la marge de puissance, les licences d'hyperviseur, l'état de l'orchestration ou la restauration des sauvegardes. L'espace d'adressage de Giveme Cloud soutient le contrôle d'une surface réseau. Il ne quantifie pas l'offre cloud utilisable.

La carte des installations se concentre autour de Varsovie et Amsterdam

Les preuves physiques sont les plus solides au niveau de l'auto-déclaration d'interconnexion et de présence dans les installations. L'objet réseau PeeringDB pour AS208566liste le réseau commeRozetka, avec site webhttps://giveme.cloud, type contenu, trafic 5-10 Gbps et politique de peering sélective. Sesenregistrements d'installation PeeringDBplacent le réseau sur trois sites varsoviens: LIM Warsaw, Equinix WA1 - Warsaw, Centrum LIM, et ATMAN centres de données Warsaw-2 au Konstruktorska 5. Sonenregistrement d'échange PeeringDBmontre une connexion opérationnelle de 10 Gbps chez Equinix Warsaw.

AS6681 donne une géographie différente. L'objet réseau PeeringDB pour AS6681nommeGiveme Cloud AS6681, pointe vers le même site web, rapporte le type contenu, un trafic 20-50 Gbps et une politique de peering ouverte. Sonenregistrement d'installationle place chez Equinix AM1/AM2 - Amsterdam, Luttenbergweg. Sonenregistrement d'échangeliste une connexion opérationnelle de 10 Gbps chez NL-ix Main.

PeeringDB n'est pas un bail, une facture d'électricité ou un audit de centre de données. C'est un répertoire d'interconnexion volontaire. Ses entrées sont significatives car les opérateurs les utilisent pour décrire où les réseaux s'interconnectent et comment ils préfèrent le peering. Elles ne sont pas une preuve concluante que Giveme Cloud possède une cage, possède les serveurs, a des charges de travail clients dans chaque installation nommée, ou peut déplacer un client de Varsovie à Amsterdam pendant un incident.

Néanmoins, ces entrées d'installation changent le profil. Un client ne devrait pas penser seulement à une adresse de bureau à Varsovie. La carte opérationnelle probable est un bord varsovien pour AS208566, une présence séparée à Amsterdam pour AS6681, et un modèle d'interconnexion qui utilise à la fois des fournisseurs de transit et des échanges Internet. C'est une empreinte d'infrastructure plausible pour un petit fournisseur d'hébergement européen. La question de résilience est de savoir si ces points sont suffisamment indépendants et provisionnés pour survivre à une panne d'installation, d'upstream, d'alimentation ou de contrat.

La diversité des upstreams existe, mais des points de défaillance communs restent possibles

Les données de voisinage de RIPE montrent un environnement de chemins réel. Lerésultat des voisins AS pour AS6681rapporte 42 voisins observés uniques. Parmi les voisins de gauche de plus haute puissance visibles dans le résultat figurent AS1299, identifié par RIPE comme Twelve99 Arelion Sweden AB; AS35320, Eurotranstelecom; AS9002, RETN Limited; et AS6939, Hurricane Electric. Lerésultat des voisins AS pour AS208566rapporte 12 voisins observés uniques et inclut le même motif Arelion, Eurotranstelecom, Hurricane et RETN, plus M247 et le contexte d'échange lié à Equinix.

C'est plus qu'un seul upstream. Cela suggère que l'entreprise n'est pas dépendante d'un seul chemin de transit public au niveau BGP. Lerésultat AS Rank de CAIDA pour AS6681marque l'ASN vu, lui donne le rang 10256, un cône de 2 ASN, 12 préfixes et 3 072 adresses, et rapporte 5 fournisseurs, 43 pairs et 1 client. Lerésultat AS Rank de CAIDA pour AS208566marque également cet ASN vu, donne le rang 6051, un cône de 3 ASN, 131 préfixes et 43 008 adresses, et rapporte 3 fournisseurs, 3 pairs et 1 client.

Cependant, la diversité BGP et la diversité physique sont différentes. Deux sessions de transit peuvent entrer dans la même salle de données par la même salle de rencontre. Deux opérateurs peuvent partager des gaines, des colonnes montantes, une distribution électrique, un port en gros, ou le même revendeur contractuel. Un port d'échange Internet peut améliorer la reachabilité locale mais encore tomber en panne avec le bâtiment, la matrice d'échange, la traversée, le routeur ou le port du client.

Même des entrées séparées à Varsovie et Amsterdam ne prouvent pas que les images clients, les sauvegardes et les systèmes de contrôle sont répliqués entre les deux villes.

C'est là que le test de l'acheteur d'hébergement passe de « le réseau route-t-il? » à « qu'est-ce qui tombe en panne ensemble? ». Une bonne réponse cartographierait chaque chemin public vers un routeur, un port, une traversée, une installation, un contrat d'opérateur et une fenêtre de maintenance. Elle montrerait quelles charges de travail utilisent AS6681, lesquelles utilisent AS208566, s'il existe un déplacement automatique du trafic, comment le DNS est géré, et si la couche de stockage suit la couche de routage. Le registre BGP public prouve la reachabilité. Il ne prouve pas encore l'isolement des pannes.

L'offre cloud est publique, mais ses affirmations nécessitent un contexte opérationnel

Le site web de Giveme Cloud n'est pas vague sur la vente de capacité hébergée. Lapage d'accueilfait la publicité d'une offre « réel cloud », avec un plan standard à partir de 12 EUR, 1 vCPU, 1 Go RAM et 10 Go vSSD; un plan business à 66 EUR, 4 vCPU, 16 Go RAM et 100 Go vSSD; et un plan entreprise personnalisé tarifé par vCPU, RAM, stockage et incréments de 10 Mbit. Lapage à proposdit que l'entreprise est basée en Pologne, décrit le cloud public, privé et hybride, et déclare que ses principaux clients sont des réseaux publicitaires fortement chargés. Elle répète également des affirmations de SSD entreprise, stockage HA, connexion 20 Gb/s pour tous les serveurs, licences Windows, serveurs de messagerie, réseaux internes et support réactif.

Ces pages sont commercialement importantes car elles font passer l'entreprise de « opérateur réseau » à « vendeur de services cloud ». Elles créent également les cibles exactes de due diligence. Quelle plateforme crée un serveur entièrement opérationnel en minutes? Quel hyperviseur, panneau de contrôle et conception de stockage se cachent derrière vSSD? Que signifie « stockage HA »: disques en miroir dans un seul hôte, stockage par blocs répliqué dans une seule salle, stockage synchrone entre salles, ou un niveau de sauvegarde hors site?

La connexion 20 Gb/s est-elle un port physique par serveur, une liaison montante de cluster, une affirmation de matrice partagée ou un plafond marketing? Quel est le véritable goulot d'étranglement après la surréservation?

Les pages légales réduisent la promesse. Lesconditions de servicedéclarent que la disponibilité peut être interrompue par la maintenance, des pannes ou des circonstances hors du contrôle de l'entreprise et que la disponibilité sans interruption ou sans erreur n'est pas garantie. Elles déclarent que les utilisateurs sont responsables de la création et de la maintenance des sauvegardes de leur contenu et que Giveme Cloud ne garantit pas que le contenu sera sauvegardé. Elles décrivent également les offres de support, incluant des objectifs pour les niveaux de support supérieurs et la surveillance et le remplacement du matériel dans les centres de données, tout en précisant qu'un accord de niveau de service signé peut remplacer les conditions génériques.

Cette combinaison est normale dans l'hébergement, mais elle compte. La page marketing parle en langage cloud; les conditions allouent le risque. Un client devrait lire les deux. Si une charge de travail ne peut tolérer une perte de données, l'acheteur ne devrait pas se fier à une phrase d'accueil. Il devrait exiger le contrat exécuté, le calendrier des sauvegardes, les preuves de restauration, la période de conservation, la conception du stockage, le niveau de support et la procédure d'exportation des données.

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

La table de routage publique peut faire paraître un petit fournisseur plus grand que sa réserve cloud utilisable. RIPE compte les adresses et les préfixes, pas les hôtes sains. PeeringDB compte les installations et les ports d'échange, pas le CPU de réserve. Un tableau de prix sur un site web compte les unités vendables, pas l'inventaire derrière elles. C'est pourquoi la capacité installée par rapport à la capacité utilisable est au centre du profil.

La capacité installée commence par les actifs qui existent physiquement: serveurs, disques, commutateurs, routeurs, optiques, alimentations, espace en rack et licences logicielles. La capacité mise en service est la partie qui a été configurée, testée et mise en production. La capacité disponible est ce qui reste après déduction des clients existants, des réserves de maintenance, des disques défaillants, des ressources de veille et de la politique de surréservation. La capacité utilisable est ce qu'un nouveau client ou un client existant peut provisionner sans compromettre les engagements existants.

La capacité récupérable est ce qui reste après une panne d'installation, de stockage, d'upstream ou de compte.

Les preuves publiques de Giveme Cloud prouvent plus clairement la capacité d'adresse et de route que la capacité de calcul. RIPE montre 2 304 adresses IPv4 sous AS6681 et 512 sous AS208566 au point d'observation, plus le /29 IPv6 sous AS208566. Le site web vend vCPU, RAM et vSSD. PeeringDB montre des emplacements possibles de rack et d'échange. Rien de tout cela ne révèle le nombre d'hôtes installés, le nombre d'hôtes défaillants, la quantité de RAM libre, le budget d'endurance SSD, la part du stockage réservée aux snapshots, la densité maximale de clients par nœud ou le temps réel de remplacement d'une alimentation défaillante.

Le risque économique est simple. Un petit cloud peut être rentable tout en fonctionnant près de sa capacité, mais une utilisation proche de la capacité réduit la marge de manœuvre en cas de panne. Il peut également annoncer une capacité personnalisée flexible tout en dépendant d'un fournisseur en gros, mais alors la reprise du client dépend de l'inventaire du grossiste et des conditions contractuelles. Il peut maintenir du matériel de réserve, mais les registres publics révèlent rarement cela.

Les acheteurs devraient donc demander une capacité en unités opérationnelles datées, pas en adjectifs: hôtes actuels, cœurs disponibles, RAM disponible, stockage utilisable après réplication, transit engagé, trafic de pointe, alimentation de réserve, optiques de réserve, disques de remplacement et le temps maximal testé pour récupérer un nœud défaillant.

La dépendance à l'alimentation et aux installations n'est pas facultative

Chaque serveur virtuel se termine dans un rack. La question de l'installation n'est donc pas cosmétique. La présence d'AS208566 sur PeeringDB chez LIM Warsaw, Equinix WA1 et ATMAN Warsaw-2 suggère une surface opérationnelle à Varsovie. La présence d'AS6681 chez Equinix AM1/AM2 Amsterdam suggère une deuxième ville ou au moins un deuxième point d'interconnexion. Mais la nature de ces points n'est pas visible. Un réseau peut lister une installation parce qu'il y a un routeur, une armoire, une traversée, un port distant ou un arrangement avec un opérateur. Cela ne dit pas combien de serveurs clients s'y trouvent.

La dépendance à l'alimentation commence à l'alimentation du serveur et remonte à travers les PDU de rack, les onduleurs, les générateurs, les alimentations électriques, les équipements de transfert et les arrangements de carburant ou de service. Un fournisseur d'hébergement peut ne posséder aucune de ces infrastructures tout en étant responsable envers les clients quand elles tombent en panne. Si l'entreprise est colocalisée dans un site tiers, elle dépend de l'opérateur du site pour l'alimentation, le refroidissement, la sécurité, les systèmes d'incendie et l'accès physique.

Si elle utilise une plateforme en gros, elle peut même ne pas pouvoir envoyer de personnel dans la salle. Si elle ne possède que des routeurs dans une installation et héberge le calcul ailleurs, la carte d'interconnexion ne révélera pas l'emplacement du calcul.

Les preuves publiques n'identifient pas un centre de données appartenant à Giveme Cloud, une cage privée, un nombre de racks, une allocation d'alimentation ou une conception de refroidissement. Ce n'est pas inhabituel pour un petit fournisseur. Cela signifie que le risque lié aux installations devrait être écrit dans la due diligence de l'acheteur.

Le client devrait savoir quelle installation héberge la copie primaire de la charge de travail, quelle installation contient les sauvegardes, si les deux partagent une dépendance de bâtiment métro, si Amsterdam est un site de reprise ou seulement un site de peering, et qui a un accès physique quand le matériel tombe en panne.

L'alimentation compte aussi pour les affirmations réseau. Plusieurs voisins BGP n'aident pas si les deux routeurs sont derrière la même PDU de rack. Une autorisation d'origine de route n'aide pas si le commutateur de tête de rack est sombre. Une connexion d'échange n'aide pas si le cluster de stockage a perdu ses deux contrôleurs. La preuve de routage prouve que le bord est accessible maintenant; la preuve d'installation ne prouve pas encore comment il survit à un événement au niveau du site.

Le support fait partie de l'infrastructure

La fiabilité d'un petit cloud échoue souvent d'abord dans la réponse humaine, pas dans le BGP. Un flap d'upstream, une alarme de disque, un travail de sauvegarde échoué, une suspension de paiement, un filtre DDoS, un client abusif, une image client cassée et une mauvaise annonce de route nécessitent tous une personne ou un chemin de contrôle automatisé conçu par une personne. Le matériel public de Giveme Cloud fait du support une partie du produit, mais il ne spécifie pas entièrement le système de support.

Le site web annonce un support technique réactif. Lapage d'aideprésente un formulaire de contact. Les conditions décrivent les responsabilités du compte, les droits de suspension, les règles de remboursement et les niveaux de support. La politique de confidentialité dit que l'entreprise peut collecter des informations de demande de support et peut utiliser des fournisseurs de services tels que des processeurs de paiement, des fournisseurs de centres de données et des services d'analyse. Ce sont des modèles normaux de fournisseur de services. Ils pointent également vers des dépendances en dehors du routeur.

Les questions de support sont pratiques. Le support est-il disponible 24h/24 pour tous les plans ou seulement pour les niveaux business et entreprise? Les objectifs de remplacement du matériel sont-ils contraignants ou seulement des cibles? Le client a-t-il un contact unique pour les incidents d'installation, de réseau, de stockage et de facturation? Que se passe-t-il quand un litige de facturation coïncide avec une panne? Giveme Cloud peut-il restaurer un snapshot sans intervention du client? Peut-il fournir une copie des données client si le panneau de contrôle est en panne?

Le traitement des abus a-t-il l'autorité de suspendre un préfixe client, et comment un faux positif est-il inversé?

Les conditions rendent un risque client particulièrement clair: les utilisateurs restent responsables des sauvegardes à moins qu'un arrangement séparé n'en dise autrement. Ce n'est pas une accusation; c'est une limite contractuelle. Cela signifie qu'un acheteur ne devrait pas traiter le « stockage HA » comme un substitut à sa propre stratégie de sauvegarde, de restauration et d'exportation. L'infrastructure est faite de machines, de routes et de personnes. Le BGP public prouve la couche de route. La preuve de support doit venir des contrats, des enregistrements de tickets, des métriques de réponse et des récupérations testées.

La localité des données est européenne par identité, mais l'emplacement de la charge de travail a encore besoin de preuve

L'identité de l'entreprise est polonaise et les preuves opérationnelles se concentrent en Pologne et aux Pays-Bas. Cela compte pour l'analyse de souveraineté des données, d'autant plus que Giveme Cloud commercialise l'hébergement et des services connexes aux clients. Lapolitique de confidentialitédit que l'entreprise est le responsable du traitement pour le site, fait référence au RGPD et au droit polonais, décrit les données de compte, de facturation et de support, et dit que les données personnelles seront principalement traitées dans l'Espace économique européen tandis que certains fournisseurs peuvent être en dehors de l'EEE. Letexte du RGPD de l'UEfournit le contexte juridique pour le traitement, les relations avec les sous-traitants, la sécurité et les transferts internationaux.

Cela ne prouve pas où chaque charge de travail client s'exécute. Un port d'échange à Varsovie n'est pas un emplacement de stockage. Un enregistrement d'installation à Amsterdam n'est pas une politique de sauvegarde. Un site web hébergé sur193.200.65.34n'est pas une déclaration que les machines virtuelles des clients s'exécutent dans le même bloc. Si l'entreprise utilise des fournisseurs de centres de données tiers, la référence de la politique de confidentialité aux fournisseurs de services devient opérationnellement pertinente: les clients doivent savoir qui sont ces fournisseurs, où les données sont stockées, où résident les sauvegardes, qui peut accéder aux consoles de support et quelles garanties s'appliquent si des données quittent l'EEE.

Les preuves publiques soutiennent le sujet contrôlé de la souveraineté des données parce que les limites de localisation et de traitement font partie du risque de service. Elles ne soutiennent pas une conclusion que Giveme Cloud viole ou satisfait une exigence spécifique de résidence des données d'un client. Cela dépend du contrat du client, du plan choisi, de l'installation réelle, de la région de sauvegarde, du modèle d'accès au support et de l'identité des sous-traitants.

Un acheteur avec des obligations de localité devrait transformer « entreprise polonaise, signaux réseau Varsovie et Amsterdam » en clauses spécifiques. Le contrat devrait nommer l'entité légale, l'emplacement du service, l'emplacement de la sauvegarde, la géographie d'accès au support, le processus de retour des données, le calendrier de suppression et la liste des sous-traitants. Il devrait aussi clarifier si les données client peuvent être transférées en dehors de l'EEE via les fournisseurs de paiement, de support, de surveillance ou d'analyse.

Le dossier public donne suffisamment de raisons de demander; il ne répond pas pour chaque charge de travail.

Le chemin de défaillance commence avec le rack, mais il ne s'arrête pas là

Le principal chemin de défaillance de l'affectation - rack, upstream, stock de matériel, support, facturation, migration ou défaillance du contrat du fournisseur - est exactement la bonne façon de lire cette entreprise. Les preuves de Giveme Cloud sont suffisamment larges pour que plusieurs de ces défaillances soient plausibles et spécifiques.

Une défaillance de rack pourrait toucher le calcul, le stockage, le routage ou les trois, selon l'endroit où vit réellement la charge de travail du client. Si les serveurs primaires se trouvent dans un site varsovien et que l'entrée Amsterdam n'est qu'un point de peering ou de transit, Amsterdam ne restaurera pas automatiquement le client. Si les copies primaire et de sauvegarde se trouvent derrière le même système de contrôle de stockage, une deuxième route ne sauvera pas des données corrompues.

Si l'entreprise utilise des mains à distance, le délai de remplacement dépend du processus de l'opérateur d'installation, du niveau de support du client et de la disponibilité des pièces de rechange.

Une défaillance d'upstream est plus facile à imaginer à partir du graphe de routage. AS6681 et AS208566 ont plusieurs voisins observés, incluant des noms de transit majeurs, et tous deux ont un contexte d'échange Internet. C'est un signe positif. Mais le véritable test est de savoir si les préfixes clients restent accessibles quand Arelion, RETN, Hurricane, un port d'échange local, une traversée ou un routeur tombent en panne. Lacohérence de routage pour AS6681de RIPE montre les /24 annoncés correspondant aux informations de route RIPE, et lacohérence de routage pour AS208566fait de même pour les /24 actifs et le /29 IPv6. C'est une preuve d'hygiène de routage, pas une preuve de basculement.

Les défaillances de facturation et de contrat du fournisseur sont souvent plus dommageables que les clients ne le pensent. Les conditions disent que les services peuvent être suspendus ou annulés dans plusieurs circonstances, y compris les problèmes de paiement et les violations de politique. Si le contrat d'upstream, d'installation ou de gros de Giveme Cloud était contesté, les clients publics pourraient subir une panne de réseau comme une défaillance de dépendance commerciale. Le client ne le verra pas depuis le BGP jusqu'à ce que les routes disparaissent, soient filtrées ou se dégradent.

La continuité contractuelle est donc une dépendance d'infrastructure.

La migration est le dernier chemin de défaillance. Si un client doit partir, peut-il exporter les disques, snapshots, logs, DNS, attributions IP, DNS inverse, files d'attente de messagerie et définitions de réseau interne rapidement? Le site web annonce des réseaux internes et des serveurs de messagerie, ce qui signifie que l'état client peut exister au-delà d'un seul disque VM. Les registres publics ne montrent pas d'outil de portabilité ou de processus de sortie testé. Pour toute charge de travail ayant de réels besoins de continuité, le plan de migration devrait être testé avant le premier incident.

Qui serait affecté en cas de défaillance?

La population cliente publique n'est pas connue. La page à propos de Giveme Cloud dit que ses principaux clients sont des réseaux publicitaires fortement chargés et affirme que ces clients délivrent de très gros volumes de publicités. C'est une déclaration de l'entreprise, pas une liste de clients vérifiée indépendamment.

Elle aide néanmoins à identifier le type de dommage qu'une défaillance pourrait causer si la déclaration décrit des clients actuels: livraison de publicités sensible à la latence, points de suivi, systèmes de campagne, services de messagerie, hébergement web, réseaux privés et environnements de machines virtuelles personnalisés.

Les charges de travail de réseau publicitaire sont un cas de stress utile car elles convertissent les millisecondes et la perte de paquets en perte de revenus. Un petit problème de routage peut réduire les réponses d'enchères, la précision du suivi, la livraison des campagnes ou la télémétrie de contrôle de fraude. Un problème de stockage peut endommager les logs, les preuves de facturation ou l'état de la campagne. Un retard de support peut laisser un client incapable de distinguer entre sa propre défaillance d'application et la défaillance d'infrastructure du fournisseur.

Si Giveme Cloud héberge de telles charges de travail, les clients affectés ne sont pas seulement des utilisateurs finaux ouvrant un site web; ce sont des entreprises dont le chemin de revenus dépend de transactions rapides et répétées.

Il y a aussi des utilisateurs indirects. La politique de confidentialité décrit la création de compte, l'achat, le support et les données de paiement. Les serveurs de messagerie sont annoncés. Les réseaux internes sont annoncés. Les licences Windows sont annoncées. Ce sont des signes que les clients peuvent exécuter des applications métier, de la messagerie, des systèmes de gestion et des interconnexions privées.

En cas de défaillance d'un rack ou d'un contrat fournisseur, ces clients peuvent perdre non seulement l'accessibilité publique mais aussi l'accès administratif, la continuité des licences, les files d'attente de messagerie, les sauvegardes et les options de retour des données.

La contrainte importante est que rien de tout cela n'établit un nombre. Les registres publics ne montrent pas combien de clients utilisent le service, quels clients sont actifs, quel trafic leur appartient, combien de VM s'exécutent, quelle part de l'espace d'adressage est utilisée ou si les plus grandes charges de travail sont à Varsovie, Amsterdam ou ailleurs. L'article peut identifier des catégories affectées, pas des entreprises affectées. Un acheteur sérieux devrait demander des références, des métriques de fiabilité anonymisées, un historique de statut et un modèle actuel d'impact client.

La preuve de redondance nécessiterait plus que des voisins visibles

Giveme Cloud a déjà certains signaux qu'un acheteur veut voir: deux ASN, une visibilité RIS complète pour les routes actives, un RPKI valide pour les préfixes testés, plusieurs voisins observés, une présence sur les échanges Internet et des entrées d'installation PeeringDB dans plus d'une ville. Cette combinaison est meilleure qu'une page d'hébergement mono-site sans preuve réseau. La question restante est de savoir si le système a une redondance au niveau de la couche service, pas seulement au niveau de la couche adresse.

Un dossier de redondance solide inclurait un schéma réseau daté montrant les rôles d'AS6681 et AS208566, les upstreams, les ports d'échange, les routeurs, les installations et les traversées physiques. Il identifierait quels services clients utilisent chaque ASN. Il montrerait si Varsovie et Amsterdam sont actif-actif, actif-passif, routage seulement, sauvegarde seulement ou des empreintes non liées. Il fournirait des résultats d'un test de panne d'opérateur, d'un test de panne de routeur, d'une panne de contrôleur de stockage, d'une évacuation d'hôte, d'une restauration de sauvegarde et d'une exportation de données client.

Il distinguerait le basculement automatique de la récupération manuelle.

La preuve d'alimentation nécessiterait la même précision. Un nom d'installation ne suffit pas. L'acheteur devrait connaître la puissance du rack, les alimentations doubles, la couverture onduleur et générateur, le préavis de fenêtre de maintenance, l'accès à distance, les optiques de rechange, les disques de rechange, les SLA de remplacement et qui paie pour le travail d'urgence. La preuve matérielle devrait séparer l'équipement installé de l'équipement sain disponible.

La preuve de stockage devrait indiquer le facteur de réplication, le domaine de défaillance, la rétention des snapshots, l'isolement des sauvegardes et le temps de restauration. La preuve de support devrait fournir des chemins d'escalade, les heures, les objectifs de réponse et les conséquences si les objectifs ne sont pas atteints.

L'absence de ces détails publics ne signifie pas que l'entreprise en manque. De nombreux fournisseurs d'hébergement gardent ces informations privées pour des raisons de sécurité et commerciales. Cela signifie que la note publique ne peut pas dépasser Moyen. Le réseau est réel. La couche de résilience cloud n'est pas auditée publiquement ici. Pour un site à faible risque, cela peut être acceptable. Pour les paiements, la santé, les données personnelles réglementées, les revenus de livraison de publicités, la messagerie critique ou les applications métier essentielles, la preuve manquante devrait être réglée avant la migration.

Le verdict: un vrai petit réseau avec des questions de risque cloud sans réponse

GIVEME CLOUD SP Z O O devrait être traité comme une entreprise d'infrastructure opérationnelle, pas comme une simple entrée d'annuaire nominale. Le registre KRS, l'objet organisation RIPE, deux ASN, des préfixes annoncés, des routes testées valides RPKI, un DNS sur son propre espace d'adressage et des entrées PeeringDB le montrent clairement ensemble. Un client peut voir un bord réseau et une offre d'hébergement commerciale.

Le facteur limitant n'est pas l'identité; c'est l'assurance. Les plans cloud du site web et la table de routage montrent ce que l'entreprise vend et comment des parties du réseau apparaissent depuis Internet. Ils ne montrent pas les serveurs installés, la capacité libre réelle, la disposition des racks, les contrats d'installation, les chemins d'alimentation, le personnel de support, le matériel de rechange, le succès des sauvegardes, le timing de restauration, l'outillage de sortie client ou les conditions contractuelles qui détermineraient ce qui se passe dans une mauvaise semaine.

Les conditions de service rendent certains de ces risques explicites en mettant la responsabilité des sauvegardes sur les clients à moins qu'un arrangement séparé ne change la limite et en évitant une promesse générale de disponibilité ininterrompue.

Pour un client, la bonne posture est une confiance conditionnelle. L'entreprise a suffisamment de preuves d'infrastructure publique pour justifier un essai, un questionnaire technique et un test de basculement en direct. Elle n'a pas suffisamment de preuves publiques pour justifier de supposer une résilience multi-site, une récupération automatique, une marge de manœuvre infinie ou une portabilité des données garantie.

L'acheteur devrait vérifier quel ASN et quelle installation sa charge de travail utilise, si Giveme Cloud ou un fournisseur contrôle le rack, combien d'upstreams indépendants desservent le service, ce qui se passe si un fournisseur tombe en panne, quelles preuves de sauvegarde et de restauration existent, comment la suspension de facturation est gérée, et à quelle vitesse les données peuvent être exportées.

La note de preuve réseau est Moyenne car le bord est réel et visible, tandis que la preuve de résilience du service client reste incomplète. Giveme Cloud vend de la capacité hébergée. Les registres publics montrent que cette capacité repose toujours sur des faits d'infrastructure ordinaires: racks, routes, alimentation, contrats d'upstream, main-d'œuvre de support et la capacité du client à partir avant qu'un incident local ne devienne une panne d'entreprise.