Résumé
- Bird Hosting Inc. est le registrant actif attaché à AS19133 dans le registre public d'ARIN, avec des ressources IPv4 et IPv6 directement enregistrées et une visibilité de routage mondiale actuelle.
- L'identité visible par le client est différente: PeeringDB associe AS19133 à Innovative Scaling Technologies, Inc., également connu sous le nom d'InnoScale, et les conditions juridiques d'InnoScale désignent cette entreprise comme le fournisseur contractant.
- Les pages de service public proposent des produits concrets, des emplacements, un SLA et des canaux de support, mais leurs promesses doivent être lues en parallèle des exclusions, des procédures de crédit, du langage de transfert de données et des coordonnées de support incohérentes.
- Le dossier soutient le traitement d'AS19133 comme un réseau opérationnel réel. Il ne fait pas, en soi, du nom Bird Hosting Inc. une assurance complète sur le vendeur, l'architecture du service, la localisation des données ou la réponse aux incidents.
Les preuves d'identité les plus solides commencent par le réseau
Bird Hosting Inc. n'est pas simplement un nom de marque trouvé sur une vieille liste d'hébergement. Le registre de l'American Registry for Internet Numbers pour AS19133 identifie le système autonome comme BIRD-HOSTING, le marque actif et nomme Bird Hosting Inc. comme le registrant. L'enregistrement AS date de janvier 2011. Le dossier d'organisation lié, BIRDH, date de mai 2010 et a été modifié pour la dernière fois en août 2025.
Ce dossier est important car un système autonome est un identifiant opérationnel, pas une catégorie marketing. Il est utilisé pour originer des routes selon une politique de routage commune. ARIN publie également quatre enregistrements de ressources directs pour l'organisation: 71.19.224.0 à 71.19.239.255, 192.64.72.0 à 192.64.79.255, 204.11.16.0 à 204.11.19.255, et l'allocation IPv6 commençant par 2605:7900::. La liste de ressources d'ARIN fournit donc une preuve plus solide de responsabilité d'infrastructure qu'une affirmation générique d'offrir de l'hébergement.
L'entrée de l'annuaire BTW ajoute une vue utile mais nuancée. Elle décrit Bird Hosting comme une entreprise privée américaine, liste les services d'hébergement et de réseau géré, et montre 17 enregistrements de réseau liés plus une adhésion au Seattle Internet Exchange. Les étiquettes de service sont marquées comme non encore évaluées, tandis que l'adhésion à l'échange a une confiance moyenne. C'est la bonne façon de lire une surface d'annuaire: il organise les indices et relations publics, mais ne doit pas être confondu avec un certificat de disponibilité ou une déclaration sur qui a la responsabilité contractuelle.
La première conclusion est donc assez ferme. Bird Hosting a une identité durable dans les registres de ressources numériques Internet, et cette identité est attachée à une infrastructure qui reste visible. La question plus difficile est ce que ce nom signifie pour un client achetant un serveur cloud aujourd'hui.
Un réseau présente deux noms d'entreprise
Le dossier d'ARIN lui-même s'éloigne d'une vitrine autonome de Bird Hosting. Ses commentaires d'organisation citent innoscale.net, et ses contacts techniques, d'exploitation réseau et d'abus utilisent des adresses e-mail InnoScale. Un contact technique nommé utilise également le domaine InnoScale. Ces liens rendent la connexion entre Bird Hosting et InnoScale bien plus qu'une conjecture.
Le profil PeeringDB pour AS19133 rend la connexion explicite sous un autre angle. Il nomme le réseau Innovative Scaling Technologies, Inc., donne InnoScale comme nom alternatif, lie à innoscale.net, et attribue le même ASN. Le profil décrit une politique de peering ouverte et classifie le réseau à travers les fonctions d'accès, de contenu, d'entreprise et de fournisseur de services réseau.
Pourtant, les noms ne sont pas interchangeables dans les documents qu'un acheteur est invité à accepter. Les conditions de service d'InnoScale stipulent que l'accord est entre Innovative Scaling Technologies, Inc. et le client identifié dans le bon de commande. Les conditions définissent les services incluant les serveurs cloud, les clusters, le cloud privé et les serveurs dédiés. Bird Hosting Inc. n'apparaît pas comme la contrepartie dans cet accord publié.
Ce n'est pas une preuve que l'un ou l'autre nom est faux. Les entreprises conservent souvent d'anciens noms de détention de ressources, commercent sous une marque différente, ou placent les actifs réseau et les contrats clients dans des entités distinctes. C'est une preuve que l'identité doit être résolue au niveau de la commande. Un client potentiel devrait demander si Bird Hosting Inc. possède ou exploite les ressources pertinentes pour Innovative Scaling Technologies, si une entité est un nom commercial ou une filiale de l'autre, et quelle entité accepte les obligations de service, de confidentialité et financières.
La réponse devrait apparaître dans le bon de commande ou un autre document contraignant, pas seulement dans une explication du service commercial.
Les routes montrent un réseau actif, pas un score de qualité
Le 15 juillet 2026, la vue du statut de routage de RIPEstat a rapporté 25 préfixes IPv4 visibles couvrant 13 824 adresses et 13 préfixes IPv6 visibles, représentés par 13 /48. Le réseau était visible par tous les 326 pairs IPv4 et tous les 322 pairs IPv6 à alimentation complète comptés par cette vue. RIPEstat a également enregistré une route originée par AS19133 le jour de la publication.
C'est une preuve significative. Cela montre qu'AS19133 n'est pas seulement enregistré mais participe au routage global au moment de l'observation. Cela soutient également l'idée que le réseau dispose de suffisamment d'espace d'adressage et de diversité de routes pour servir plus qu'une simple présence web symbolique.
Il ne montre pas la latence vers une application particulière, la perte de paquets sur le chemin choisi par le client, la qualité du contrôle des changements, la capacité de réserve, la reprise après sinistre ou la compétence d'un ingénieur d'astreinte. La visibilité de routage est une preuve binaire d'accessibilité depuis les pairs de surveillance, pas une mesure de l'expérience utilisateur final.
Les détentions d'adresses ne disent rien non plus sur la densité avec laquelle un fournisseur alloue les serveurs, si le trafic client est correctement filtré ou si un emplacement annoncé dispose d'alimentation électrique et de chemins réseau indépendants.
PeeringDB ajoute d'autres indices opérationnels, bien que ses champs fournis par l'opérateur doivent être traités comme des déclarations. Le profil rapporte une portée mondiale, 50 à 100 Gbps de trafic, 30 préfixes IPv4 et 10 préfixes IPv6. Ses enregistrements liés listent cinq installations: Equinix AM1/AM2 à Amsterdam, DataBank IAD1 à Ashburn, Evocative DAL6, DataBank SFO1 à Santa Clara et l'installation Tukwila de Wowrack. Des enregistrements d'échange séparés montrent AS19133 sur deux réseaux Seattle Internet Exchange, chacun à 10 Gbps annoncés et chacun transportant des adresses IPv4 et IPv6.
Pris ensemble, ARIN, RIPEstat et PeeringDB soutiennent une thèse de réseau opérationnel. Ils ne valident pas indépendamment les chiffres de performance ou les affirmations de service client faites sur les propres pages d'InnoScale.
Le catalogue de services est concret, mais les affirmations restent des affirmations
Le site public d'InnoScale contient désormais suffisamment de détails pour compter comme une preuve de service plutôt qu'une brochure vide. Sa navigation propose des serveurs cloud, cloud privé, clusters gérés, Kubernetes, hébergement d'applications spécialisées, e-mail, hébergement IA privé et support d'infrastructure. La page des serveurs cloud publie des familles d'instances avec CPU virtuel, mémoire, stockage et prix horaires. Elle revendique également un SLA de disponibilité de 99,999 %, des performances de stockage de 250 000 IOPS et sept centres de données mondiaux.
La spécificité est utile. Un acheteur peut comparer les dimensions d'instance publiées avec une charge de travail prévue, demander comment les performances de stockage ont été mesurées, et vérifier si le SLA cité s'applique à l'architecture sélectionnée. Les conditions disent également qu'InnoScale peut attribuer et gérer des adresses IP dédiées et peut les modifier ou les supprimer. Cette clause relie la preuve de détention de ressources à un service client plausible, tout en précisant qu'un client n'obtient pas le contrôle des droits d'adresse sous-jacents.
Mais un tableau de prix et un titre de performance ne sont pas une vérification indépendante. Le dossier public examiné ici n'inclut pas de méthodologie de benchmark, d'historique de statut, de chiffres de disponibilité audités ou d'architecture de référence spécifique au client. Le site compare même ses performances et coûts avec un grand hyperscaler sans publier une comparaison reproductible au même endroit. Ces déclarations sont des propositions commerciales à tester, pas des faits à intégrer dans un modèle de risque sans modification.
Une réponse d'approvisionnement utile consiste à rendre l'offre mesurable. Demandez la génération exacte du CPU, la politique de surengagement, la conception de réplication du stockage, les conditions de test des IOPS, les limites des ports réseau, les limites de sauvegarde et le processus de restauration. Demandez si le service proposé est une machine virtuelle unique, un cluster répliqué ou une application gérée. Ces détails déterminent si le chiffre de disponibilité affiché a une signification pratique.
Le choix de l'emplacement n'est pas la même chose que la souveraineté des données
La page des serveurs cloud nomme Seattle, Santa Clara, Chicago, Washington, Dallas, Londres et Amsterdam, avec un emplacement Asie-Pacifique décrit comme à venir. Cette liste est plus large que les cinq installations du dossier PeeringDB actuel. La différence n'est pas nécessairement une contradiction. Un fournisseur peut vendre un emplacement sans y exploiter un port de peering public, et un dossier d'installation peut omettre un site de service. Cela signifie qu'aucune des listes ne doit être utilisée comme substitut à un emplacement de déploiement contraignant.
Le texte juridique est plus révélateur. L'accord de traitement des données d'InnoScale nomme Innovative Scaling Technologies comme le sous-traitant, couvre l'hébergement, l'infrastructure cloud, le stockage, les sauvegardes et le support technique, et permet le transfert de données personnelles vers les États-Unis ou d'autres pays où InnoScale ou ses sous-traitants maintiennent des installations. Il dit qu'une liste de sous-traitants est disponible sur demande et fait référence à des garanties pour les transferts internationaux.
Pour un client avec des obligations de résidence, ce langage fait de la sélection d'une ville seulement le début de la discussion. Le serveur principal peut se trouver à Amsterdam tandis que la télémétrie, les sauvegardes, l'accès au support ou un sous-traitant franchissent une autre juridiction. Le DPA public ne fournit pas la liste des sous-traitants demandée, une géographie d'accès au support fixe ou une carte de flux de données spécifique au service.
L'assurance opérationnelle nécessite donc un calendrier de localisation écrit. Il devrait identifier séparément les données de production, les réplicas, les sauvegardes, les journaux, les données du plan de gestion et l'accès au support. Il devrait indiquer si chacun peut quitter la juridiction sélectionnée, nommer les sous-traitants impliqués et expliquer ce qui se passe lors du basculement. Sans ce calendrier, une étiquette de localisation décrit une option de produit, pas une frontière de souveraineté complète.
La responsabilité du support fonctionne sur deux horloges différentes
La page de support d'InnoScale promet une disponibilité 24 heures sur 24, une réponse dans les 30 minutes pour les problèmes critiques, une assistance multilingue, des services de surveillance et de réponse aux incidents. Elle présente les canaux e-mail, chat, téléphone et ticket et liste [email protected] comme voie e-mail. La navigation du site dirige le support technique et la facturation vers un portail client.
Le dossier réseau public d'ARIN raconte une histoire plus étroite. Ses commentaires sur les opérations réseau indiquent des heures de 9h à 17h heure du Pacifique et dirigent les contacts après les heures pour laisser un message ou envoyer un e-mail. L'adresse opérationnelle et d'abus listée est [email protected]. Le SLA publié donne encore une autre voie d'incident, [email protected].
Ces détails peuvent se référer à différentes fonctions. Un contact NOC de registre existe pour le routage, les abus et l'administration des ressources; il ne s'agit pas nécessairement de la même équipe qui gère les incidents de support géré payants. Un bureau d'assistance 24 heures sur 24 peut également trier les cas avant qu'un spécialiste en infrastructure ne soit engagé. Malgré tout, la présentation publique laisse un acheteur avec trois modèles d'e-mail et deux modèles de couverture apparents.
Cette ambiguïté devrait être résolue avant une panne. La commande devrait nommer le canal d'incident autorisé, les définitions de gravité, l'objectif d'accusé de réception, l'objectif d'engagement technique et l'objectif de restauration. Elle devrait dire si la promesse de 30 minutes est un accusé de réception ou l'arrivée d'un ingénieur qualifié. Elle devrait également identifier qui peut effectuer des modifications de route, restaurer des sauvegardes et communiquer lors d'un incident de sécurité en dehors des heures normales de travail du Pacifique.
La main-d'œuvre de support locale importe ici. Un badge indiquant 24/7 ne dit rien sur l'endroit où le personnel est employé, si la couverture est dotée en personnel ou d'astreinte, ou si les personnes recevant le ticket ont un accès privilégié aux systèmes affectés. Les acheteurs qui dépendent de la langue régionale, des restrictions juridictionnelles ou d'une intervention pratique rapide devraient demander l'emplacement du support et le modèle d'escalade par écrit.
Le SLA est un cadre de recours, pas cinq neuf isolément
Le SLA d'InnoScale est plus utile qu'un simple slogan de disponibilité car il explique une partie du recours. Il dit que l'entreprise utilisera des efforts commercialement raisonnables pour maintenir une disponibilité mensuelle de 99,999 %. Il offre des crédits de 5, 10 ou 25 % à des niveaux de disponibilité inférieurs, plafonne le crédit mensuel à 25 % du montant du service affecté et exige une réclamation écrite dans les dix jours ouvrables. L'éligibilité est déterminée par InnoScale, et les crédits approuvés sont appliqués à une facture ultérieure.
Les conditions réduisent le titre. Les exclusions incluent les télécommunications tierces, les logiciels clients, les événements hors du contrôle d'InnoScale, la maintenance programmée et d'urgence, la conduite du client, les contraintes de provisionnement, le matériel ou logiciel spécifié, et un serveur cloud de développement unique ou un serveur dédié unique. Les pannes programmées sont exclues de la mesure. Les bandes de crédit publiées passent également d'une limite supérieure de 99,98 % à une limite inférieure de 99,99 %, laissant un petit intervalle qui mérite clarification.
Pour un client, les questions pratiques sont simples. Quelle source de surveillance détermine la disponibilité? L'unité est-elle un hôte, une machine virtuelle, un cluster, une région ou un point de terminaison de service? Un effondrement partiel des performances compte-t-il comme indisponible? Quelle architecture est éligible, étant donné l'exclusion du serveur unique? Qui préserve les preuves nécessaires pour soumettre une réclamation dans les dix jours ouvrables?
Le SLA peut encore être précieux. Il crée une voie documentée vers un crédit et établit un concept de mesure mensuelle. Mais même le crédit maximum n'est pas une compensation pour les données perdues, les transactions manquées ou le préjudice de réputation. La résilience doit être conçue dans le service acheté; elle ne peut pas être déduite du nombre de neuf sur la page de vente.
Ce qu'un acheteur devrait exiger avant de se fier au nom
Le dossier public de Bird Hosting a suffisamment de substance pour justifier une diligence continue. L'enregistrement réseau est ancien. Les ressources d'adresse sont identifiables. Les observations de routage actuelles montrent une large visibilité. Une marque publique liée propose des services tarifés, un portail de compte, des conditions juridiques, un DPA, un SLA et des canaux de support. C'est considérablement plus de preuves qu'un nom d'entreprise sans surface opérationnelle derrière.
Les lacunes restantes sont également suffisamment concrètes pour être comblées. Un acheteur devrait exiger cinq choses: une explication signée de la relation entre Bird Hosting, Innovative Scaling Technologies et InnoScale; un bon de commande nommant la contrepartie responsable; un diagramme de service liant la charge de travail achetée à AS19133, aux installations et aux chemins de basculement; un calendrier de localisation des données et des sous-traitants; et une matrice de support qui concilie les heures, les canaux, les objectifs de gravité et l'autorité d'escalade.
Ces demandes ne sont pas de la paperasse pour elle-même. Elles connectent quatre surfaces que l'Internet public maintient séparées: le détenteur des ressources numériques, l'opérateur du réseau routé, le vendeur du service et l'équipe responsable en cas de défaillance du service. Lorsque les quatre sont alignés, le dossier public devient une corroboration utile. Lorsqu'ils ne le sont pas, un nom d'hébergement familier peut créer de la confiance sans attribuer de responsabilité.
Le verdict équitable n'est donc ni un rejet ni un soutien. Bird Hosting Inc. a une empreinte réseau réelle et active derrière son nom. Les preuves sont les plus solides sur l'enregistrement et le routage, raisonnablement développées sur la définition du service, et plus faibles là où les clients ont besoin des promesses les plus exactes: responsabilité d'entreprise, localité spécifique au service et réponse opérationnelle après les heures. Jusqu'à ce que ces liens soient rendus contraignants, AS19133 est une preuve d'opération, pas une garantie de résultat.