XSALTO35667 Alpilink Cloud S.A.S. vende capacidad alojada que aún depende de los racks, el tránsito y las ventanas de mantenimiento

Resumen

• El RDAP de RIPE registraAS35667como XSALTO35667 para Alpilink Cloud S.A.S.; RIPEstat informó el AS anunciado el 15 de julio de 2026, con94.143.216.0/21como asignación IPv4 visible yRPKI válidopara este origen.
• La ruta pública es estable pero estrecha:el estado de enrutamiento de RIPEstatmostró un prefijo IPv4, 2.048 direcciones IPv4, ningún prefijo IPv6 visible y un vecino observado, mientras quelos datos de vecinos de RIPEstatidentificaron a este vecino como AS28768.
• La propia páginaServicios Cloudde Alpilink afirma alojamiento, IaaS, máquinas virtuales, servicios gestionados, copias de seguridad y recuperación ante desastres externalizada, soporte experto francés 24/7, tres centros de datos conectados, ancho de banda garantizado de 40 Gbit/s, más de 1.500 servidores alojados y 3 Po de datos almacenados; estas son declaraciones operativas de primera parte, no auditorías de capacidad independientes.
• La nota actual de las evidencias es Media-alta para la identidad y el control de ruta, pero solo Media para la resiliencia del cliente. Los archivos públicos respaldan un verdadero operador de nube y alojamiento francés, pero los clientes aún necesitan pruebas actuales sobre la ubicación de los racks, la capacidad utilizable, el diseño eléctrico y de refrigeración, la diversidad de ruta más allá del AS padre, el aislamiento de la copia de seguridad, la escalada del soporte y los derechos de migración.

Los archivos públicos apuntan a un verdadero operador de nube francés, no a un nombre de alojamiento desechable

El primer paso más importante es la identidad. Un comprador no puede evaluar la capacidad alojada hasta que sepa qué organización controla las direcciones, los contratos, la mesa de ayuda y el patrimonio físico detrás del servicio. En este punto, XSALTO35667 Alpilink Cloud S.A.S. tiene pruebas públicas útiles. El RDAP de RIPE enhttps://rdap.db.ripe.net/autnum/35667nombra AS35667 como XSALTO35667 y lo vincula a Alpilink Cloud S.A.S., con el registro de la organización mostrando una dirección en 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, Francia. La misma respuesta RDAP incluye contactos administrativos y de operaciones de red XSALTO con una dirección en Seyssinet-Pariset. Estos detalles no son una garantía de rendimiento, pero anclan la empresa en un contexto operativo francés real.

El espacio de direcciones también está claro. El RDAP de RIPE enhttps://rdap.db.ripe.net/ip/94.143.216.0/21identifica 94.143.216.0 a 94.143.223.255 como FR-XSALTO-20090310, asignado PA, país FR, activo y asociado a Alpilink Cloud S.A.S. La visión general del AS de RIPEstat enhttps://stat.ripe.net/data/as-overview/data.json?resource=AS35667informó el AS anunciado en el momento de la consulta del 15 de julio de 2026. Su punto final de prefijos anunciados enhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667mostró 94.143.216.0/21 durante la ventana de dos semanas que termina el 15 de julio de 2026. Su visión general del prefijo enhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21confirmó a AS35667 como titular de origen.

El red también está protegido por un objeto de origen de ruta. El punto final de validación RPKI de RIPEstat enhttps://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21devolvió un estado válido, con un ROA de validación para el AS de origen 35667, el prefijo 94.143.216.0/21 y una longitud máxima /21. Esta es una señal de higiene significativa. No garantiza la disponibilidad, las operaciones de seguridad o la diversidad de ruta, pero reduce una clase de riesgo de enrutamiento evitable: una autorización de origen de ruta válida da a los proveedores ascendentes y validadores de ruta un medio para rechazar orígenes no autorizados para el /21 anunciado.

Estos hechos técnicos importan porque la empresa vende una dependencia física envuelta en un servicio cloud. La propia página Servicios Cloud de Alpilink enhttps://www.alpilink.fr/services-cloud/lista alojamiento, IaaS, máquinas virtuales, servicios gestionados, copias de seguridad y recuperación ante desastres externalizada. Indica que Alpilink Services Cloud ofrece la experiencia y los servicios de un alojamiento soberano en Francia, con un equipo experto francés disponible 24/7, un compromiso de seguridad y una política empresarial sostenible. También da cifras de escala: tres centros de datos conectados, ancho de banda garantizado de 40 Gbit/s, más de 1.500 servidores alojados y 3 Po de datos almacenados. Estas no son afirmaciones de software genéricas. Implican racks, alimentación, refrigeración, bastidores de almacenamiento, enlaces de red, copias de seguridad, personal de soporte e instalaciones.

El desafío para el comprador es que las pruebas públicas son sólidas a nivel de identidad y posicionamiento de primera parte, pero incompletas a nivel de capacidad en vivo. Podemos ver un AS actual, visibilidad de ruta actual, validez RPKI, entradas de instalaciones de PeeringDB y una página cloud detallada de primera parte. No podemos ver el registro de capacidad cliente por cliente: armarios disponibles, potencia reservada, puertos libres, stock de servidores, discos de repuesto, saturación del clúster de hipervisores, reserva de copia de seguridad, contratos de mano remota o profundidad de la cola de soporte.

Esta distinción no es hostil a Alpilink. Es la diferencia normal entre la prueba de que un proveedor existe y la prueba de que la carga de trabajo específica de un cliente sobrevivirá al próximo fallo.

AS35667 está correctamente registrado, pero también es una superficie de ruta pública estrecha

Las pruebas de enrutamiento son alentadoras por un lado y limitantes por el otro. El estado de enrutamiento de RIPEstat enhttps://stat.ripe.net/data/routing-status/data.json?resource=AS35667informó un prefijo IPv4, 2.048 direcciones IPv4, cero prefijos IPv6 en la vista visible de AS35667, 326 pares IPv4 RIS de 326 viendo la ruta y un vecino observado en el momento de la consulta del 15 de julio de 2026. Esta es una alta visibilidad para la única ruta IPv4. Significa que el AS no estaba simplemente asignado; era ampliamente visto en los datos de enrutamiento públicos.

La limitación es el mismo punto de datos leído desde un ángulo de resiliencia. Un prefijo visible y un vecino observado no prueban una arquitectura de cliente multi-ruta. El punto final de vecinos de RIPEstat enhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667mostró AS28768 como el único vecino observado en la observación del 14 de julio de 2026. La vista whois de RIPEstat enhttps://stat.ripe.net/data/whois/data.json?resource=AS35667también registra import desde AS28768 y export hacia AS28768. El punto final de consistencia enhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667encontró 94.143.216.0/21 tanto en BGP como en whois y AS28768 en las vistas import y export. Esto es limpio. También es concentrado.

AS28768 no es un telón de fondo sin importancia. El objeto de red PeeringDB parahttps://www.peeringdb.com/api/net?asn=28768identifica XSALTO con 10 prefijos IPv4, 10 prefijos IPv6, un número de IX y tres registros de instalaciones en su perfil público, mientras quehttps://www.peeringdb.com/api/netixlan?asn=28768lista una entrada de interconexión France-IX AURA LyonIX. Los datos netfac de PeeringDB enhttps://www.peeringdb.com/api/netfac?net_id=9058muestran AS28768 presente en Cogent Grenoble, Orange Business - La Fabrique en Grenoble, y XSALTO Grenoble en Seyssinet-Pariset. Esto sugiere que la red más amplia de XSALTO/Alpilink es más extensa que AS35667 solo.

Pero la asignación aquí es específicamente XSALTO35667 Alpilink Cloud S.A.S., y la vista pública de AS35667 en sí misma no muestra la misma diversidad. El objeto PeeringDB para AS35667 enhttps://www.peeringdb.com/api/net?asn=35667lista un prefijo IPv4, un prefijo IPv6 en su perfil, un tráfico de 1 a 5 Gbit/s, un alcance Europa, una relación equilibrada, cero número de IX y un número de instalaciones. El punto final netfac enhttps://www.peeringdb.com/api/netfac?net_id=13798muestra esta instalación como XSALTO Grenoble en Seyssinet-Pariset. El punto final netixlan para AS35667 no devolvió ninguna línea IX LAN pública durante esta revisión. Una vez más, esto no significa que no exista diversidad operativa; significa que la prueba de diversidad pública para este AS es limitada.

Esto importa porque muchos fallos de clientes ocurren en el límite entre "el grupo tiene resiliencia" y "mi ruta de servicio exacta tiene resiliencia". Si las máquinas virtuales de un cliente están numeradas desde 94.143.216.0/21 y su camino a Internet toma AS35667 a través de AS28768, entonces el cliente debería preguntar cómo está diseñado AS28768, dónde están los routers de borde, si la ruta puede conmutar por error dentro de la red del grupo, qué caminos de tránsito e interconexión llevan realmente el tráfico, y si el DNS, soporte, copia de seguridad y control de acceso del cliente dependen de la misma instalación.

Un AS padre o adyacente puede proporcionar redundancia real, pero solo si está realmente en la ruta de servicio del cliente.

El patrimonio físico se centra en Grenoble, con capas actuales y futuras que no deben confundirse

El lado físico de las pruebas apunta a Grenoble y sus comunas circundantes. Los registros RIPE incluyen Échirolles y Seyssinet-Pariset. PeeringDB lista XSALTO Grenoble como una instalación en Seyssinet-Pariset. La página Servicios Cloud de primera parte da la dirección de contacto en Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles. La página de garantías HDS enhttps://www.alpilink.fr/services-cloud/garanties-hds/nombra a ALPILINK CLOUD en 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, y también nombra a Orange - La Fabrique (EOLAS) en 73 Rue Général Mangin, 38100 Grenoble, como subcontratista para dos racks. Esta es una información pública inusualmente concreta para un proveedor cloud regional.

La misma página HDS también es importante por el límite del operador. Dice que Alpilink Cloud posee su propio centro de datos que explota sin subcontratar, a excepción del alojamiento en colocalización en los centros de datos listados en la tabla. Describe a Alpilink Cloud como el alojador, a Orange - La Fabrique como subcontratista para una actividad que involucra dos racks, y al soporte de producto 24/7 en parte por personal situado en Tahití, con acceso cifrado.

Esto da a los clientes un mapa real del límite: una parte del servicio es operada directamente por Alpilink Cloud, existe cierta dependencia de colocalización, y el acceso al soporte puede cruzar la geografía incluso cuando la afirmación de alojamiento de datos es francesa.

Esta es una divulgación valiosa, pero aún deja los detalles operativos que un cliente debe verificar. La página pública dice que ISO 27001 está presente y que HDS se aplica, pero no publica el alcance completo de la auditoría, la ubicación de los racks del cliente, la topología de copia de seguridad, la separación exacta entre las instalaciones propias de Alpilink y los racks alojados por Orange, o qué cargas de trabajo están en qué ubicación. Para un cliente de datos de salud, la distinción entre ubicación de datos, acceso administrativo, repositorio de copia de seguridad, herramienta de monitoreo y mesa de ayuda importa.

Para un cliente no relacionado con la salud, la misma distinción importa para la recuperación y la responsabilidad contractual.

El anuncio del nuevo centro de datos de Alpilink añade una capa futura. El artículo de primera parte de enero de 2026 enhttps://www.alpilink.fr/centros de datos-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/dice que el Grupo Alpilink está construyendo un nuevo centro de datos soberano en Grenoble, operado por Alpilink Services Cloud, para reforzar su infraestructura para el verano de 2027. Indica que el sitio estará en Saint-Martin-d'Hères, en un edificio adquirido y acondicionado para uso de centro de datos. Describe una arquitectura modular multi-sala, techo alto, diseño de alta densidad, redundancia eléctrica y climática, generadores, seguridad física reforzada, control de acceso, supervisión, compatibilidad con requisitos avanzados de recuperación ante desastres y continuidad del negocio, un PUE objetivo alrededor de 1.3 y un calendario con obras en 2026, entrega y pruebas a principios de 2027, y puesta en servicio progresiva en el verano de 2027.

La página del proyecto enhttps://www.alpilink.fr/services-cloud/nouveau-centros de datos-alpilink-cloud-a-grenoble/repite el mismo marco: el futuro sitio está diseñado para mayor densidad, resiliencia, soberanía y rendimiento energético; apunta a una arquitectura equivalente a Tier III; y no está aún en servicio en el momento del calendario publicado. Este es un límite importante entre capacidad instalada y capacidad utilizable. Un sitio planificado puede respaldar preventas, reservas y planificación arquitectónica. No puede respaldar una afirmación de julio de 2026 de que las futuras salas, caminos de alimentación, caminos de refrigeración y procedimientos de migración de clientes ya son utilizables para tráfico de producción.

Por lo tanto, la buena pregunta de diligencia es doble. Para el servicio actual, ¿dónde exactamente está la carga de trabajo del cliente hoy: en Alpilink, en Orange - La Fabrique, en otro sitio conectado, o en una ubicación gestionada no nombrada públicamente? Para el proyecto 2027, ¿cuándo el espacio reservado se vuelve utilizable por el cliente, qué pruebas de aceptación deben pasar, cómo migrarán los clientes, y qué sucede si el calendario del nuevo sitio se desliza? La capacidad instalada es el equipo y la instalación que pueden ser alimentados, refrigerados, conectados y soportados hoy.

La capacidad anunciada es una promesa de futuros equipos o salas. La capacidad utilizable es el subconjunto que un cliente puede realmente consumir con condiciones contractuales, alcanzabilidad de red, política de copia de seguridad y cobertura de personal.

El catálogo de servicios actual es bastante amplio para crear muchos caminos de dependencia

La lista de la página Servicios Cloud que incluye alojamiento, IaaS, máquinas virtuales, servicios gestionados, copias de seguridad y recuperación ante desastres externalizada importa porque cada servicio tiene una forma de fallo diferente. El alojamiento es lo más cercano a la instalación física. El cliente puede poseer el hardware, pero Alpilink proporciona espacio en rack, alimentación, refrigeración, cross-connects, acceso físico y algo de mano remota.

El IaaS y las máquinas virtuales transfieren más responsabilidad al proveedor: hipervisores, almacenamiento, orquestación, mantenimiento de hosts, instantáneas y a veces plantillas de sistema operativo. Los servicios gestionados añaden personal y procedimientos. La copia de seguridad y la recuperación ante desastres añaden una promesa de recuperación separada que debe ser más independiente que el entorno de producción que protege.

Las cifras de primera parte dan una idea de la escala: tres centros de datos conectados, ancho de banda garantizado de 40 Gbit/s, más de 1.500 servidores alojados y 3 Po de datos almacenados. Estas cifras son lo suficientemente específicas para ser útiles. También son cifras de primera parte. El registro de ruta pública para AS35667 muestra un solo /21 visible; el objeto más amplio de AS28768 en PeeringDB sugiere una huella de red más grande; la página Servicios Cloud sugiere una infraestructura multi-sitio; la página HDS nombra un centro de datos propio y una ubicación de rack subcontratada en Orange.

Las pruebas son consistentes con un proveedor cloud regional maduro, pero no permiten a un observador externo asignar la afirmación de 1.500 servidores entre instalaciones, clientes, tipos de servicio o capacidad disponible.

El riesgo no es que las cifras sean falsas. El riesgo es que los compradores puedan leer la escala agregada como protección individual. Un proveedor puede alojar 1.500 servidores y aún tener la carga de trabajo de un cliente concentrada en un solo rack. Puede tener tres centros de datos conectados y aún vender un plan de copia de seguridad particular que no incluye restauración entre sitios. Puede garantizar 40 Gbit/s a nivel de red y aún tener puertos de cliente, cortafuegos o matrices de almacenamiento como cuellos de botella.

Puede asegurar soporte 24/7 y aún tener un camino de reemplazo de hardware limitado por disponibilidad de piezas o ventanas de acceso. La capacidad agregada es un punto de partida útil; el diseño del servicio a nivel de carga de trabajo es la decisión de compra.

Esto es particularmente cierto para la copia de seguridad y la recuperación ante desastres. Alpilink promociona recuperación ante desastres externalizada, y la página HDS utiliza términos franceses para continuidad y garantías regulatorias.

Un cliente debería preguntar si los repositorios de copia de seguridad están en una instalación separada y con credenciales administrativas separadas, si las redes de copia de seguridad pasan por un dominio de fallo diferente, si las pruebas de restauración están documentadas, cuánto tiempo toma una restauración completa, si las instantáneas son inmutables, y cómo se manejan los escenarios de ransomware, error de operador o disputa de facturación.

Un servicio de copia de seguridad que depende de la misma cuenta, misma matriz de almacenamiento y misma cola de soporte que la producción puede reducir la pérdida accidental mientras falla durante un fallo más amplio.

Los servicios gestionados crean otra dependencia oculta: las personas. Las páginas públicas de Alpilink enfatizan la disponibilidad de expertos franceses, cobertura 24/7 y soporte local. La página HDS indica que parte del personal de soporte está en Tahití y parte en la empresa. Esto puede ser una fortaleza, ya que la diferencia horaria puede mejorar la cobertura fuera del horario laboral. También requiere claridad. ¿Qué equipo puede realizar un ciclo de alimentación en un equipo? ¿Qué equipo puede acceder a las redes de gestión? ¿Qué incidentes requieren personal en Grenoble? ¿Cómo se controlan los privilegios?

¿Cómo se aplican las restricciones de acceso a datos de salud? ¿Qué sucede cuando un incidente de soporte requiere simultáneamente al operador de la instalación, al equipo de red y a un administrador del cliente?

Las pruebas de ruta y DNS deben leerse como pruebas de control, no como un mapa de servicio completo

Las pruebas de ruta públicas prueban el control de un recurso de Internet utilizable. No nos dicen dónde vive cada servicio. La geolocalización de RIPEstat enhttps://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21y MaxMind GeoLite enhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21colocan el /21 en Francia en la vista consultada. La consulta de cadena DNS enhttps://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.commostró xsalto.com resolviendo a 81.200.40.205 con los servidores de nombres ns01.xsalto.net, ns02.xsalto.net y ns03.xsalto.net. Esta dirección web xsalto.com está fuera del /21 de AS35667, por lo que no debe usarse como prueba de la ubicación o capacidad de 94.143.216.0/21.

Este es un patrón normal. El sitio de marketing de una empresa puede estar en una plataforma separada, un rango de direcciones heredado, una red de grupo, un alojador web o un proveedor de entrega de contenido. La ubicación del sitio web público solo es útil si la afirmación es sobre la alcanzabilidad del sitio web. No es un mapa directo de la computación del cliente. Inversamente, un /21 enrutado es una prueba de control útil pero no un catálogo de servicios. Puede alojar sistemas de gestión, VM de clientes, DNS, monitoreo, pasarelas de copia de seguridad e interfaces internas.

Sin un mapa de servicio público, los observadores externos no pueden decir qué direcciones corresponden a qué producto.

PeeringDB añade otra capa pero también tiene limitaciones. La entrada PeeringDB de AS35667 enhttps://www.peeringdb.com/api/net?asn=35667lista XSALTO 2, sitio webhttp://www.xsalto.com, AS set AS-XSALTO, un prefijo IPv4, un prefijo IPv6 en el perfil, alcance Europa, tráfico de 1 a 5 Gbit/s, cero número de IX público y un número de instalaciones. La API de instalaciones enhttps://www.peeringdb.com/api/fac/7114identifica XSALTO Grenoble en Seyssinet-Pariset, con dos redes y cero número de IX en ese registro de instalación. PeeringDB es mantenido por los operadores y puede estar incompleto, pero sigue siendo una prueba pública útil de que el AS no es simplemente un registro abstracto.

El perfil más amplio de AS28768 enhttps://www.peeringdb.com/api/net?asn=28768es donde aparece la historia de interconexión más amplia. Lista un IX y tres instalaciones, y el punto final netixlan lista France-IX AURA LyonIX. Esto puede respaldar una suposición de que la red más amplia de Alpilink tiene más caminos que AS35667 solo. No prueba, sin un esquema de red específico del cliente, que el tráfico del cliente de AS35667 tenga proveedores ascendentes independientes, routers de borde independientes, rutas de fibra independientes o conmutación por error automática entre sitios. La ruta pública de AS35667 aparece detrás de AS28768; los clientes deberían preguntar qué diversidad existe detrás de ese límite.

La validez RPKI es el punto de higiene de ruta más fuerte en las pruebas actuales de AS35667. Reduce el riesgo de conflicto de origen accidental o malintencionado. No resuelve todos los problemas de enrutamiento. Si AS28768 tiene un fallo, si una instalación pierde alimentación, si un cross-connect se corta, si un cortafuegos falla en modo cerrado, si un evento DDoS satura la interfaz, o si el DNS del cliente depende de un solo camino de proveedor, el RPKI no puede restaurar la aplicación. Es un control de autenticación de ruta, no un plan de recuperación operativa.

La alimentación, la refrigeración y la densidad son áreas donde la capacidad anunciada debe tratarse con cuidado

Las páginas del nuevo centro de datos de Alpilink son notables porque hablan directamente de densidad de potencia y diseño térmico. El artículo de enero de 2026 dice que el futuro sitio está diseñado para cargas aplicativas crecientes, sistemas de información críticos y cargas de trabajo de datos/IA. Menciona arquitectura modular multi-sala, techos altos, redundancia eléctrica, redundancia climática, generadores, seguridad física, control de acceso, supervisión, compatibilidad con recuperación ante desastres avanzada y continuidad del negocio, y un PUE objetivo alrededor de 1.3.

La página del proyecto dice igualmente que el futuro centro de datos apunta a una arquitectura equivalente a Tier III, redundancia eléctrica completa, diseño modular multi-sala, densidad energética y gestión eficiente de flujo caliente/frío.

Estas afirmaciones son comercialmente significativas. Muestran que Alpilink entiende el problema al que muchos proveedores cloud regionales se enfrentan ahora: la densidad por rack aumenta más rápido de lo que las salas heredadas fueron diseñadas para absorberla. Una sala de servidores construida para virtualización modesta puede volverse limitada cuando los clientes demandan almacenamiento denso, análisis, IA, appliances de seguridad o hosts de alta memoria.

La limitación de capacidad ya no es solo el número de racks; es la potencia por armario, la ruta de refrigeración, la gestión de cables, la capacidad del SAI, la autonomía de los generadores, la selectividad de los interruptores, la supervisión y la capacidad humana para reemplazar componentes fallidos sin perturbar cargas vecinas.

El tiempo es importante. Las mismas páginas sitúan las obras y el acondicionamiento en 2026, la entrega y pruebas a principios de 2027, y la puesta en servicio progresiva en el verano de 2027. En la fecha de publicación de este artículo, estas futuras salas deben tratarse como planificadas o en desarrollo, no como capacidad utilizable ya probada. Un comprador que reserva espacio puede beneficiarse del proyecto; un comprador que necesita recuperación de producción inmediata no puede confiar en este futuro sitio hasta que esté en servicio, probado, conectado, contratado y aceptado.

Las afirmaciones actuales de alojamiento ecológico también deben leerse con precaución. El artículo sobre sostenibilidad de julio de 2024 enhttps://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/dice que Alpilink utiliza parte de su infraestructura en un centro de datos ecológico con 100% de electricidad renovable, refrigeración por calorías de agua subterránea sin consumo de agua, conformidad con el Código de Conducta Europeo para la Eficiencia Energética de Centros de Datos y eficiencia energética inferior a 1.30 PUE. El artículo de junio de 2024 enhttps://www.alpilink.fr/un-centros de datos-peut-il-etre-vert/dice que el centro de datos de Alpilink Cloud cerca de Grenoble está diseñado para ser lo más virtuoso posible y utiliza energía hidroeléctrica.

Estas afirmaciones de sostenibilidad pueden ser fortalezas operativas. Una refrigeración eficiente y energía renovable local pueden reducir costos operativos y exposición al riesgo. Pero el PUE y la energía verde no prueban por sí mismos capacidad de reserva. Una instalación con bajo PUE puede estar llena. Un sitio alimentado por renovables puede aún tener limitaciones de generador, SAI, refrigeración, mantenimiento o personal. Un ciclo de vida sostenible del equipo puede reducir residuos mientras aumenta la necesidad de entender la edad del hardware, la política de piezas de repuesto y la planificación de renovación.

Por lo tanto, los clientes deberían preguntar por la capacidad actual por rack, consumo eléctrico, asignación de refrigeración y nivel de servicio en lugar de confiar únicamente en el lenguaje de sostenibilidad.

La localización de datos es una fortaleza, pero debe especificarse servicio por servicio

El posicionamiento de Alpilink está construido alrededor de la soberanía francesa. La página Servicios Cloud dice que la empresa ofrece alojamiento soberano en Francia y soporte francés. El artículo sobre Tech & Fest 2026 enhttps://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/enmarca a Alpilink Services Cloud en torno a la soberanía, la nube y la continuidad del negocio en Grenoble. La página de garantías HDS aborda explícitamente el alojamiento de datos de salud, la localización de datos, la certificación, los roles de subcontratistas y el riesgo de acceso por un tercer país. Esta es una divulgación más útil que una simple insignia de "nube segura".

La regla práctica es siempre servicio por servicio. La VM de producción de un cliente puede estar en la propia instalación de Alpilink. Una copia de seguridad puede estar en otro centro de datos conectado. Una dependencia de rack para datos de salud puede involucrar a Orange - La Fabrique. El acceso al soporte puede involucrar personal en Tahití a través de acceso cifrado. El DNS puede estar en un sistema, las facturas en otro y la documentación del cliente en otro.

Una afirmación de soberanía es más fuerte cuando cada una de estas superficies está mapeada: computación, almacenamiento, copias de seguridad, registros, tickets, monitoreo, correo electrónico, credenciales, administración y runbooks de recuperación ante desastres.

La página HDS da una ventaja a los clientes porque nombra los roles y dice que no se realiza ninguna transferencia de datos personales de salud a un tercer país fuera del Espacio Económico Europeo por parte de Alpilink Cloud en este contexto. También indica que Alpilink Cloud no está calificado SecNumCloud 3.2 en la tabla mostrada. Esta distinción es importante. HDS e ISO 27001 pueden ser controles sólidos para usos particulares, pero no son idénticos a la calificación SecNumCloud, ni una prueba de resiliencia completa, ni una garantía de que cada producto, cliente o componente subcontratado está en el mismo alcance.

Para cargas de trabajo no relacionadas con la salud, la misma diligencia se aplica con etiquetas diferentes. ¿Dónde están los datos? ¿Quién puede acceder a ellos? ¿Qué país rige el contrato? ¿Qué subcontratistas proporcionan el rack, la red, la alimentación, el monitoreo o el soporte? ¿Con qué rapidez puede el cliente exportar sus datos? ¿Las copias de seguridad están almacenadas en el mismo dominio legal y operativo que la producción? ¿Los registros se conservan en Francia? ¿Las claves de cifrado son retenidas por el cliente, por el proveedor o compartidas?

Si un cliente debe irse, ¿puede obtener imágenes de disco, volcados de base de datos, exportaciones de almacenamiento de objetos y control de DNS sin esperar una cola de soporte manual?

La versión más fuerte de la oferta de Alpilink es local, específica y operativa: personal centrado en Grenoble, instalaciones francesas, certificaciones nombradas, racks concretos, recursos de red conocidos y rutas de migración accesibles. La versión más débil sería un eslogan de soberanía amplio sin mapeo por servicio. Los archivos públicos están más cerca de la versión fuerte que muchos proveedores, pero un comprador aún necesita el cronograma exacto y el alcance del producto para su propio despliegue.

Caminos de fallo: qué se rompe primero, y quién se ve afectado

El camino de fallo más obvio es un problema de rack o instalación. Los clientes de alojamiento pueden perder alimentación, refrigeración, cross-connects o acceso a mano remota. Los clientes de IaaS pueden sufrir un fallo de host, almacenamiento o red. Los clientes de servicios gestionados pueden también perder la secuencia de operaciones del personal necesaria para diagnosticar incidentes. Si la ubicación afectada es el propio centro de datos de Alpilink, el proveedor controla más la respuesta. Si el activo afectado es un rack de colocalización subcontratado, el proveedor debe coordinarse con el operador de colocalización.

Esta distinción importa durante un fallo nocturno o de fin de semana.

El camino de fallo de ruta es más estrecho pero visible. AS35667 transita públicamente por AS28768 en los datos observados. Si la frontera interna entre AS35667 y AS28768, los routers del AS padre, o el tejido de proveedor ascendente/interconexión detrás de AS28768 tienen problemas, los clientes numerados desde 94.143.216.0/21 pueden ver efectos de alcanzabilidad. La validez RPKI no ayudará si el camino autorizado está física u operativamente fuera de servicio.

Los clientes deberían preguntar si los prefijos de cliente pueden moverse, si hay múltiples dispositivos de borde, dónde están los dispositivos, y si la diversidad de camino se prueba en lugar de solo configurarse.

El camino de fallo del soporte es humano. La afirmación de soporte 24/7 de Alpilink es valiosa, y la referencia de la página HDS al soporte basado en Tahití puede mejorar la cobertura. Pero los clientes deberían saber qué puede hacer realmente ese soporte. ¿Puede el equipo nocturno reiniciar un host? ¿Puede reemplazar un disco? ¿Puede acceder a la instalación? ¿Puede aprobar cambios de ruta? ¿Puede restaurar una copia de seguridad? ¿Puede comunicarse en el idioma requerido por el cliente? ¿Puede actuar cuando se aplican restricciones de datos de salud?

La diferencia entre "hemos visto la alerta" y "hemos restaurado el servicio" es la diferencia entre monitoreo y recuperación.

El camino de fallo de la migración es el más silencioso y a menudo el más costoso. Los servicios cloud actuales de Alpilink y el futuro proyecto de centro de datos hacen de la migración una cuestión central. Los clientes pueden necesitar pasar de una sala Alpilink existente al nuevo sitio de Saint-Martin-d'Hères, de un rack heredado a una sala de alta densidad, de servidores físicos a IaaS, o de Alpilink a otro proveedor. Cada movimiento depende de re numeración de red, TTL de DNS, exportación de copia de seguridad, replicación de almacenamiento, ventanas de mantenimiento, dependencias de aplicaciones y disponibilidad de personal.

Una construcción de centro de datos futuro no mejora la resiliencia hasta que se realiza el plan de migración.

Las partes afectadas son más amplias que el comprador directo. Los servicios cloud de Alpilink atienden a organizaciones que se preocupan por la soberanía, el alojamiento de datos de salud, las operaciones gestionadas, la continuidad del negocio y el soporte local. Si un rack, una ruta, un clúster de almacenamiento o un proceso de soporte falla, los usuarios finales pueden perder sitios web públicos, sistemas de turismo o comercio, aplicaciones internas vinculadas a pagos, servicios internos de empresa, flujos de trabajo de datos de salud, restauraciones de copia de seguridad o pasos de recuperación ante desastres.

Los artículos públicos en torno a Tech & Fest describen CIOs, CISOs y equipos de negocio buscando modelos cloud regionales y soberanos. Estos son precisamente los usuarios para quienes el tiempo de recuperación, la localización de datos y la escalada del soporte no son preocupaciones abstractas.

Lo que haría subir o bajar la nota de las evidencias

La nota actual de las evidencias es Media-alta para la identidad y la higiene de red porque RIPE RDAP, RIPEstat y PeeringDB coinciden en la empresa, el AS, el bloque de direcciones, la visibilidad de ruta y el contexto de la instalación francesa. Es Media para la resiliencia del cliente porque las pruebas públicas no muestran el mapa de servicio en vivo detrás de las afirmaciones agregadas.

Alpilink publica más detalles operativos que muchos proveedores pequeños, pero los clientes aún necesitan confirmación directa de la ubicación actual de los racks, la capacidad utilizable, el diseño de alimentación, el aislamiento de la copia de seguridad y la autoridad del soporte.

La nota mejoraría si Alpilink publicara una declaración de infraestructura fechada que mapee los servicios actuales a las instalaciones, explique qué centros de datos están conectados por el bucle óptico, indique dónde están los dispositivos de borde de AS35667 y AS28768, nombre los acuerdos actuales de proveedor ascendente/tránsito a nivel de servicio, proporcione una página de estado o historial de incidentes pública, describa la separación de la copia de seguridad, y distinga la capacidad actual del sitio de 2027.

Mejoraría si la empresa publicara consejos de migración legibles por el cliente para la construcción de Saint-Martin-d'Hères, incluyendo pruebas de aceptación, reversión, planes de ruta y ventanas de soporte.

La nota bajaría si AS35667 perdiera amplia visibilidad de ruta, si el estado RPKI válido desapareciera sin explicación, si la información de instalaciones de PeeringDB se volviera obsoleta o contradictoria, si las páginas de primera parte dejaran de distinguir los servicios actuales de la capacidad futura, si las declaraciones HDS/ISO se volvieran poco claras, o si los clientes no pudieran obtener los hechos actuales sobre la instalación y la recuperación en el marco del contrato. También bajaría si el proyecto de futuro centro de datos se comercializara como redundancia de producción utilizable antes de estar en servicio y probado.

El punto más importante es que los archivos públicos de Alpilink no están vacíos. Son sustanciales. La prudencia viene de la precisión, no de la ausencia. Un comprador tiene suficientes pruebas para justificar una evaluación seria. Aún no tiene suficientes pruebas públicas para saltarse la diligencia técnica.

Lo que los clientes deberían exigir antes de contar la capacidad

La manera más práctica de comprar en Alpilink es pedir un mapa de carga de trabajo antes de tratar cualquier cifra global como capacidad disponible. El mapa debería nombrar la instalación donde se ejecuta la computación de producción hoy, la instalación donde residen las copias de seguridad, la ruta de red utilizada por las direcciones públicas del cliente, la capa de almacenamiento detrás de las máquinas virtuales, el equipo de soporte que puede actuar fuera del horario laboral y el método de migración si el cliente se traslada al sitio previsto de Saint-Martin-d'Hères. Esta solicitud no es un trato especial.

Es la traducción mínima de las afirmaciones de infraestructura pública a un plan operativo específico del cliente.

Para la resiliencia de ruta, el mapa debería separar AS35667 del contexto más amplio de AS28768. Las pruebas públicas de RIPEstat muestran AS35667 con un solo /21 IPv4 visible y un vecino observado, mientras que PeeringDB muestra AS28768 con una huella de instalaciones e intercambio más amplia. Esta diferencia puede ser perfectamente razonable dentro de un grupo de proveedores, pero un cliente no debería asumir que cada camino de AS28768 protege cada servicio de AS35667.

El contrato debería decir qué AS origina las direcciones del cliente, dónde están los routers de borde, qué caminos de proveedor ascendente o interconexión llevan el tráfico, si la conmutación por error se ha probado, y si el DNS y el acceso de control del cliente dependen de la misma ubicación.

Para la resiliencia de las instalaciones, el mapa debería distinguir la operación del propio centro de datos de Alpilink de la dependencia de rack en Orange - La Fabrique nombrada en la página de garantías HDS. Un cliente cuya carga de trabajo está alojada en una sala operada por Alpilink enfrenta un modelo de respuesta; un cliente cuya carga de trabajo depende de racks subcontratados enfrenta otro.

El comprador debería saber quién controla el acceso físico, quién puede reemplazar equipos, quién posee la respuesta a incidentes de alimentación, qué ventanas de mantenimiento se aplican y qué créditos de servicio o derechos de salida se aplican si cualquiera de los sitios no está disponible. Sin este detalle, la frase "tres centros de datos conectados" sigue siendo un contexto de marketing útil en lugar de una prueba de redundancia a nivel de cliente.

Para la capacidad instalada frente a la capacidad utilizable, el comprador debería pedir cifras actuales en lugar de cifras de proyecto. Los 1.500 servidores alojados, 3 Po de datos almacenados y 40 Gbit/s de ancho de banda de la página Servicios Cloud describen una escala agregada. Las páginas del proyecto Grenoble 2027 describen futuras salas de alta densidad, resiliencia con generadores y objetivos de PUE. Ninguno de estos conjuntos de cifras dice a un cliente específico cuánta CPU, RAM, almacenamiento, potencia de armario, capacidad de cross-conexión o tiempo de soporte están disponibles hoy.

Un cliente que planifica un despliegue crítico debería preguntar qué capacidad está libre, cuál está reservada, cuál está sobresuscrita, cuál requiere compra de hardware y cuál depende del calendario de puesta en servicio de 2027.

Para la recuperación, el mapa debería incluir una prueba de restauración. Las copias de seguridad y la recuperación ante desastres externalizada solo valen si la ruta de copia de seguridad está suficientemente separada del fallo de producción. Los clientes deberían exigir pruebas recientes de prueba de restauración, la ubicación de la copia de seguridad, los controles de acceso a la copia de seguridad, la propiedad de las claves de cifrado, las estimaciones de tiempo de restauración, las prioridades de orden de restauración y una ruta de exportación de datos que no dependa de una sola cola de soporte sobrecargada.

Un proveedor puede tener fortalezas regionales reales y aún dejar expuesto a un cliente si el proceso de recuperación es manual, no documentado o está vinculado al mismo sistema de almacenamiento fallido.

Estas preguntas no hacen de Alpilink un candidato débil. Son las preguntas que un proveedor regional creíble debería poder responder. Las pruebas públicas ya muestran un operador cloud francés enrutable con una inversión en infraestructura visible. La pieza faltante no es la identidad; es la prueba de resiliencia específica del cliente. Una vez que el mapa de carga de trabajo existente, la presencia local de Alpilink, sus afirmaciones de conformidad, su enfoque en Grenoble y su futuro proyecto de centro de datos pueden evaluarse contra un modelo de fallo real en lugar de un folleto.

Conclusión para los operadores dependientes

XSALTO35667 Alpilink Cloud S.A.S. debe ser tratado como un operador regional francés de cloud y alojamiento real con pruebas de identidad pública más fuertes que el promedio. AS35667 está registrado en Alpilink Cloud S.A.S., su principal /21 IPv4 visible es ampliamente anunciado, el RPKI es válido, PeeringDB lista XSALTO Grenoble, y las propias páginas cloud de Alpilink describen alojamiento, IaaS, máquinas virtuales, servicios gestionados, copias de seguridad, recuperación ante desastres, certificaciones, garantías de datos de salud y una historia multi-centro de datos. El panorama operativo es lo suficientemente específico para contar.

El panorama de dependencias también es lo suficientemente específico para ser cuestionado. La superficie de ruta pública de AS35667 es estrecha. La red más amplia de AS28768 parece más diversa, pero la ruta exacta del cliente debe ser verificada. Las afirmaciones de escala de Servicios Cloud son de primera parte y agregadas. El nuevo proyecto de centro de datos de Grenoble está planificado para 2027 y no debe contarse como capacidad de producción utilizable en julio de 2026. Las afirmaciones HDS, ISO 27001 y de sostenibilidad son valiosas, pero deben mapearse a la instalación, el servicio y la ruta de soporte reales del cliente.

Para un cliente actual, las preguntas prácticas son directas. ¿Qué instalación aloja mi carga de trabajo hoy? ¿Qué AS y prefijo la llevan? ¿Qué proveedores ascendentes y routers están en mi camino? ¿Las copias de seguridad están fuera del dominio de fallo de producción? ¿Qué personal puede actuar fuera del horario laboral? ¿Cuál es mi tiempo de restauración para un host fallido, un sistema de almacenamiento, un evento de alimentación de rack, un problema de ruta o un fallo de sitio? Si debo migrar al nuevo centro de datos, ¿qué debe cambiar y quién posee cada paso?

Para un nuevo comprador, los archivos públicos respaldan una conversación calificada en lugar de una compra a ciegas. Alpilink tiene los ingredientes visibles de un proveedor cloud regional creíble: recursos de enrutamiento reales, contexto de instalación nombrado, operaciones locales, afirmaciones de conformidad y un plan de inversión en infraestructura. La decisión de compra debería basarse en una prueba actual de capacidad utilizable, aislamiento de fallo y derechos de salida. La capacidad alojada siempre se resuelve en dependencias físicas.

En el caso de Alpilink, estas dependencias son suficientemente visibles para hacer mejores preguntas: racks en Grenoble, control de ruta a través de AS35667 y AS28768, límites de alimentación y refrigeración, autoridad del soporte 24/7, separación de copia de seguridad, y ruta de migración desde las salas de hoy al sitio prometido de mañana.