XSALTO35667 Alpilink Cloud S.A.S. vende uma capacidade hospedada que ainda depende de racks, trânsito e janelas de manutenção

Resumo

• O RDAP da RIPE registraAS35667como XSALTO35667 para Alpilink Cloud S.A.S.; o RIPEstat sinalizou o AS anunciado em 15 de julho de 2026, com94.143.216.0/21como alocação IPv4 visível eRPKI válidopara essa origem.
• A rota pública é estável, mas estreita:o status de roteamento do RIPEstatmostrou um prefixo IPv4, 2.048 endereços IPv4, nenhum prefixo IPv6 visível e um vizinho observado, enquantoos dados de vizinhança do RIPEstatidentificaram esse vizinho como AS28768.
• A própria páginaServices Cloudda Alpilink alega hospedagem, IaaS, máquinas virtuais, serviços gerenciados, backups e recuperação de desastres terceirizada, suporte especializado francês 24 horas, três data centers conectados, largura de banda garantida de 40 Gbit/s, mais de 1.500 servidores hospedados e 3 PB de dados armazenados; essas são declarações operacionais de primeira parte, não auditorias de capacidade independentes.
• A nota atual das evidências é Média-forte para identidade e controle de rota, mas apenas Média para resiliência do cliente. Os arquivos públicos apoiam um verdadeiro operador de nuvem e hospedagem francês, mas os clientes ainda precisam de evidências atuais sobre localização de racks, capacidade utilizável, projeto elétrico e de refrigeração, diversidade de rota além do AS pai, isolamento de backup, escalonamento de suporte e direitos de migração.

Arquivos públicos apontam para um verdadeiro operador de nuvem francês, não um nome de hospedagem descartável

O primeiro passo mais importante é a identidade. Um comprador não pode avaliar a capacidade hospedada até saber qual organização controla os endereços, contratos, suporte e patrimônio físico por trás do serviço. Nesse ponto, a XSALTO35667 Alpilink Cloud S.A.S. tem evidências públicas úteis. O RDAP da RIPE emhttps://rdap.db.ripe.net/autnum/35667nomeia AS35667 como XSALTO35667 e o vincula à Alpilink Cloud S.A.S., com o registro da organização mostrando um endereço na 2 Rue de la Viscose, Le Rayon Vert, 38130 Échirolles, França. A mesma resposta RDAP inclui contatos administrativos e de operações de rede XSALTO com um endereço em Seyssinet-Pariset. Esses detalhes não são garantia de desempenho, mas ancoram a empresa em um contexto operacional francês real.

O espaço de endereço também é claro. O RDAP da RIPE emhttps://rdap.db.ripe.net/ip/94.143.216.0/21identifica 94.143.216.0 a 94.143.223.255 como FR-XSALTO-20090310, alocado como PA, país FR, ativo e associado à Alpilink Cloud S.A.S. A visão geral do AS do RIPEstat emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS35667sinalizou o AS anunciado no momento da consulta em 15 de julho de 2026. Seu endpoint de prefixos anunciados emhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS35667mostrou 94.143.216.0/21 durante a janela de duas semanas encerrando em 15 de julho de 2026. Sua visão geral do prefixo emhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.143.216.0/21confirmou AS35667 como titular de origem.

A rede também é protegida por um objeto de origem de rota. O endpoint de validação RPKI do RIPEstat emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=35667&prefix=94.143.216.0/21retornou um status válido, com um ROA validador para o AS de origem 35667, prefixo 94.143.216.0/21 e comprimento máximo /21. Isso é um sinal de higiene significativo. Não garante disponibilidade, operações de segurança ou diversidade de rota, mas reduz uma classe de risco de roteamento evitável: uma autorização de origem de rota válida dá aos provedores upstream e validadores de rota uma maneira de rejeitar origens não autorizadas para o /21 anunciado.

Esses fatos técnicos importam porque a empresa vende uma dependência física embalada em um serviço de nuvem. A própria página de Serviços Cloud da Alpilink emhttps://www.alpilink.fr/services-cloud/lista hospedagem, IaaS, máquinas virtuais, serviços gerenciados, backups e recuperação de desastres terceirizada. Ela afirma que a Alpilink Services Cloud oferece a expertise e os serviços de um host soberano na França, com uma equipe francesa especializada disponível 24 horas, um compromisso de segurança e uma política corporativa sustentável. Ela também fornece números de escala: três data centers conectados, largura de banda garantida de 40 Gbit/s, mais de 1.500 servidores hospedados e 3 PB de dados armazenados. Essas não são alegações genéricas de software. Elas implicam racks, energia, refrigeração, conjuntos de armazenamento, links de rede, backups, pessoal de suporte e instalações.

O desafio para o comprador é que as evidências públicas são sólidas no nível de identidade e posicionamento de primeira parte, mas incompletas no nível de capacidade em tempo real. Podemos ver um AS atual, visibilidade de rota atual, validade RPKI, entradas de instalação no PeeringDB e uma página de nuvem detalhada de primeira parte. Não podemos ver o registro de capacidade cliente por cliente: racks disponíveis, energia reservada, portas livres, estoque de servidores, discos sobressalentes, saturação do cluster hipervisor, capacidade de backup, contratos de mão remota ou profundidade da fila de suporte.

Essa distinção não é hostil à Alpilink. É a diferença normal entre a prova de que um provedor existe e a prova de que a carga de trabalho específica de um cliente sobreviverá à próxima falha.

AS35667 está devidamente registrado, mas também é uma superfície de rota pública estreita

As evidências de roteamento são encorajadoras de um lado e limitantes do outro. O status de roteamento do RIPEstat emhttps://stat.ripe.net/data/routing-status/data.json?resource=AS35667relatou um prefixo IPv4, 2.048 endereços IPv4, zero prefixo IPv6 na visão visível do AS35667, 326 pares IPv4 RIS em 326 vendo a rota e um vizinho observado no momento da consulta em 15 de julho de 2026. Isso é uma forte visibilidade para a única rota IPv4. Significa que o AS não era apenas atribuído; era amplamente visto nos dados de roteamento públicos.

A restrição é o mesmo ponto de dados lido sob um ângulo de resiliência. Um prefixo visível e um vizinho observado não provam uma arquitetura de cliente multicaminho. O endpoint de vizinhos do RIPEstat emhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS35667mostrou AS28768 como o único vizinho observado na observação de 14 de julho de 2026. A visão whois do RIPEstat emhttps://stat.ripe.net/data/whois/data.json?resource=AS35667também registra import de AS28768 e export para AS28768. O endpoint de consistência emhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS35667encontrou 94.143.216.0/21 tanto no BGP quanto no whois, e AS28768 nas visões import e export. Isso é limpo. Também é concentrado.

AS28768 não é um pano de fundo sem importância. O objeto de rede do PeeringDB parahttps://www.peeringdb.com/api/net?asn=28768identifica XSALTO com 10 prefixos IPv4, 10 prefixos IPv6, um número de IX e três registros de instalação em seu perfil público, enquantohttps://www.peeringdb.com/api/netixlan?asn=28768lista uma entrada de peering France-IX AURA LyonIX. Os dados netfac do PeeringDB emhttps://www.peeringdb.com/api/netfac?net_id=9058mostram AS28768 presente em Cogent Grenoble, Orange Business - La Fabrique em Grenoble e XSALTO Grenoble em Seyssinet-Pariset. Isso sugere que a rede mais ampla da XSALTO/Alpilink é mais extensa do que apenas AS35667.

Mas a atribuição aqui é especificamente XSALTO35667 Alpilink Cloud S.A.S., e a visão pública do próprio AS35667 não mostra a mesma diversidade. O objeto PeeringDB para AS35667 emhttps://www.peeringdb.com/api/net?asn=35667lista um prefixo IPv4, um prefixo IPv6 em seu perfil, tráfego de 1 a 5 Gbit/s, escopo Europa, proporção equilibrada, zero número de IX e um número de instalação. O endpoint netfac emhttps://www.peeringdb.com/api/netfac?net_id=13798mostra essa instalação como XSALTO Grenoble em Seyssinet-Pariset. O endpoint netixlan para AS35667 não retornou linhas IX LAN públicas nesta revisão. Novamente, isso não significa que não exista diversidade operacional; significa que a evidência de diversidade pública para este AS é limitada.

Isso importa porque muitas falhas de clientes ocorrem na fronteira entre “o grupo tem resiliência” e “meu caminho de serviço exato tem resiliência”. Se as máquinas virtuais de um cliente são numeradas a partir de 94.143.216.0/21 e seu caminho para a Internet passa por AS35667 via AS28768, então o cliente deve perguntar como o AS28768 é projetado, onde estão os roteadores de borda, se a rota pode falhar dentro da rede do grupo, quais caminhos de trânsito e peering realmente transportam o tráfego, e se o DNS, suporte, backup e controle de acesso do cliente dependem da mesma instalação.

Um AS pai ou adjacente pode fornecer redundância real, mas apenas se estiver efetivamente no caminho de serviço do cliente.

O patrimônio físico está centrado em Grenoble, com camadas atuais e futuras que não devem ser confundidas

O lado físico das evidências aponta para Grenoble e seus arredores. Os registros RIPE incluem Échirolles e Seyssinet-Pariset. O PeeringDB lista XSALTO Grenoble como uma instalação em Seyssinet-Pariset. A página de Serviços Cloud de primeira parte fornece o endereço de contato no Le Rayon Vert, 2 rue de la Viscose, 38130 Échirolles. A página de garantias HDS emhttps://www.alpilink.fr/services-cloud/garanties-hds/nomeia ALPILINK CLOUD na 6 Avenue Pierre de Coubertin, 38170 Seyssinet-Pariset, e também nomeia Orange - La Fabrique (EOLAS) na 73 Rue Général Mangin, 38100 Grenoble, como subcontratada para dois racks. Essa é uma informação pública incomumente concreta para um provedor de nuvem regional.

A mesma página HDS também é importante para o limite do operador. Ela diz que a Alpilink Cloud possui seus próprios data centers que opera sem subcontratar, exceto pela hospedagem em colocation nos data centers listados na tabela. Ela descreve a Alpilink Cloud como o host, Orange - La Fabrique como subcontratada para uma atividade envolvendo dois racks, e o suporte ao produto 24 horas em parte por pessoal localizado no Taiti, com acesso criptografado.

Isso dá aos clientes um mapa real do limite: parte do serviço é operada diretamente pela Alpilink Cloud, existe alguma dependência de colocation, e o acesso ao suporte pode atravessar a geografia mesmo quando a alegação de hospedagem de dados é francesa.

Essa é uma divulgação valiosa, mas ainda deixa os detalhes operacionais que um cliente deve verificar. A página pública diz que a ISO 27001 está presente e que o HDS se aplica, mas não publica o escopo completo da auditoria, a localização dos racks do cliente, a topologia de backup, a separação exata entre as instalações de propriedade da Alpilink e os racks hospedados pela Orange, ou quais cargas de trabalho estão em qual local. Para um cliente de dados de saúde, a distinção entre localização de dados, acesso administrativo, repositório de backup, ferramenta de monitoramento e suporte é importante.

Para um cliente não relacionado à saúde, a mesma distinção importa para recuperação e responsabilidade contratual.

O anúncio do novo data center da Alpilink adiciona uma camada futura. O artigo de primeira parte de janeiro de 2026 emhttps://www.alpilink.fr/data center-souverain-a-grenoble-alpilink-groupe-renforce-son-offre-dhebergement-avec-un-nouveau-site-opere-par-alpilink-cloud/diz que o Grupo Alpilink está construindo um novo data center soberano em Grenoble, operado pela Alpilink Services Cloud, para fortalecer sua infraestrutura até o verão de 2027. Ele indica que o site será em Saint-Martin-d'Hères, em um prédio adquirido e adaptado para uso como data center. Ele descreve uma arquitetura modular de várias salas, teto alto, projeto de alta densidade, redundância elétrica e climática, geradores, segurança física reforçada, controle de acesso, supervisão, compatibilidade com requisitos avançados de recuperação de desastres e continuidade de negócios, um PUE alvo de cerca de 1,3 e um cronograma com obras em 2026, entrega e testes no início de 2027, e comissionamento progressivo no verão de 2027.

A página do projeto emhttps://www.alpilink.fr/services-cloud/nouveau-data center-alpilink-cloud-a-grenoble/repete o mesmo quadro: o futuro site é projetado para maior densidade, resiliência, soberania e eficiência energética; visa uma arquitetura equivalente ao Tier III; e ainda não está em operação no momento do cronograma publicado. Essa é uma fronteira importante entre capacidade instalada e capacidade utilizável. Um site planejado pode apoiar pré-vendas, reservas e planejamento arquitetônico. Ele não pode apoiar uma afirmação em julho de 2026 de que salas futuras, caminhos de energia, caminhos de refrigeração e procedimentos de migração do cliente já são utilizáveis para tráfego de produção.

A boa pergunta de due diligence é, portanto, dupla. Para o serviço atual, onde exatamente está a carga de trabalho do cliente hoje: na Alpilink, na Orange - La Fabrique, em outro site conectado, ou em um local gerenciado não nomeado publicamente? Para o projeto de 2027, quando o espaço reservado se tornará utilizável pelo cliente, quais testes de aceitação devem ser aprovados, como os clientes migrarão e o que acontece se o cronograma do novo site escorregar? Capacidade instalada é o equipamento e a instalação que podem ser energizados, resfriados, conectados e suportados hoje.

Capacidade anunciada é uma promessa sobre futuros equipamentos ou salas. Capacidade utilizável é o subconjunto que um cliente pode realmente consumir com condições contratuais, alcance de rede, política de backup e cobertura de pessoal.

O catálogo de serviços atual é amplo o suficiente para criar muitos caminhos de dependência

A lista da página Serviços Cloud incluindo hospedagem, IaaS, máquinas virtuais, serviços gerenciados, backups e recuperação de desastres terceirizada importa porque cada serviço tem uma forma diferente de falha. Hospedagem é a mais próxima da instalação física. O cliente pode possuir o hardware, mas a Alpilink fornece espaço em rack, energia, refrigeração, cross-connects, acesso físico e alguma mão remota. IaaS e máquinas virtuais transferem mais responsabilidade para o provedor: hipervisores, armazenamento, orquestração, manutenção de hosts, snapshots e, às vezes, modelos de sistema operacional.

Serviços gerenciados adicionam pessoal e procedimentos. Backup e recuperação de desastres adicionam uma promessa de recuperação separada que deve ser mais independente do que o ambiente de produção que protege.

Os números de primeira parte dão uma ideia da escala: três data centers conectados, largura de banda garantida de 40 Gbit/s, mais de 1.500 servidores hospedados e 3 PB de dados armazenados. Esses números são específicos o suficiente para serem úteis. Eles também são números de primeira parte. O registro de rota pública para AS35667 mostra um único /21 visível; o objeto mais amplo do AS28768 no PeeringDB sugere uma pegada de rede maior; a página Serviços Cloud sugere uma infraestrutura multissite; a página HDS nomeia um data center próprio e um local de rack subcontratado na Orange.

As evidências são consistentes com um provedor regional de nuvem maduro, mas não permitem que um observador externo aloque a alegação de 1.500 servidores entre instalações, clientes, tipos de serviço ou capacidade disponível.

O risco não é que os números estejam errados. O risco é que os compradores possam ler a escala agregada como proteção individual. Um provedor pode hospedar 1.500 servidores e ainda ter a carga de trabalho de um cliente concentrada em um único rack. Pode ter três data centers conectados e ainda vender um plano de backup particular que não inclui restauração entre sites. Pode garantir 40 Gbit/s no nível de rede e ainda ter portas de cliente, firewalls ou conjuntos de armazenamento como gargalo. Pode fornecer suporte 24 horas e ainda ter um caminho de substituição de hardware limitado pela disponibilidade de peças ou janelas de acesso.

A capacidade agregada é um ponto de partida útil; o design do serviço no nível da carga de trabalho é a decisão de compra.

Isso é especialmente verdadeiro para backup e recuperação de desastres. A Alpilink anuncia recuperação de desastres terceirizada, e a página HDS usa termos franceses para continuidade e garantias regulatórias. Um cliente deve perguntar se os repositórios de backup estão em uma instalação separada e com credenciais administrativas separadas, se as redes de backup passam por um domínio de falha diferente, se os testes de restauração são documentados, quanto tempo leva uma restauração completa, se os snapshots são imutáveis e como são gerenciados cenários de ransomware, erro de operador ou disputa de faturamento.

Um serviço de backup que depende da mesma conta, matriz de armazenamento e fila de suporte que a produção pode reduzir a perda acidental, mas falhar em uma falha mais ampla.

Serviços gerenciados criam outra dependência oculta: as pessoas. As páginas públicas da Alpilink enfatizam a disponibilidade de especialistas franceses, cobertura 24 horas e suporte local. A página HDS indica que parte do pessoal de suporte está no Taiti e parte na empresa. Isso pode ser uma força, pois o fuso horário pode melhorar a cobertura fora do horário comercial. Também requer clareza. Qual equipe pode realizar um ciclo de energia em um equipamento? Qual equipe pode acessar redes de gerenciamento? Quais incidentes requerem pessoal em Grenoble? Como os privilégios são controlados?

Como as restrições de acesso a dados de saúde são aplicadas? O que acontece quando um incidente de suporte requer simultaneamente o operador da instalação, a equipe de rede e um administrador do cliente?

As evidências de rota e DNS devem ser lidas como evidências de controle, não como um mapa de serviço completo

As evidências de rota públicas provam o controle de um recurso de Internet utilizável. Elas não nos dizem onde cada serviço reside. A geolocalização do RIPEstat emhttps://stat.ripe.net/data/geoloc/data.json?resource=94.143.216.0/21e MaxMind GeoLite emhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=94.143.216.0/21colocam o /21 na França na visão consultada. A consulta de cadeia DNS emhttps://stat.ripe.net/data/dns-chain/data.json?resource=xsalto.commostrou xsalto.com resolvendo para 81.200.40.205 com os servidores de nomes ns01.xsalto.net, ns02.xsalto.net e ns03.xsalto.net. Esse endereço web xsalto.com está fora do /21 do AS35667, portanto não deve ser usado como evidência da localização ou capacidade de 94.143.216.0/21.

Esse é um padrão normal. O site de marketing de uma empresa pode estar em uma plataforma separada, um bloco de endereços herdado, uma rede de grupo, um host web ou um provedor de distribuição de conteúdo. A localização do site público é útil apenas se a alegação for sobre o alcance do site. Não é um mapa direto da computação do cliente. Por outro lado, um /21 roteado é uma evidência de controle útil, mas não um catálogo de serviços. Pode hospedar sistemas de gerenciamento, VMs de cliente, DNS, monitoramento, gateways de backup e interfaces internas.

Sem um mapa de serviço público, observadores externos não podem dizer quais endereços correspondem a qual produto.

O PeeringDB adiciona outra camada, mas também tem limites. A entrada do PeeringDB para AS35667 emhttps://www.peeringdb.com/api/net?asn=35667lista XSALTO 2, sitehttp://www.xsalto.com, AS set AS-XSALTO, um prefixo IPv4, um prefixo IPv6 no perfil, escopo Europa, tráfego de 1 a 5 Gbit/s, zero número de IX público e um número de instalação. A API de instalação emhttps://www.peeringdb.com/api/fac/7114identifica XSALTO Grenoble em Seyssinet-Pariset, com duas redes e zero número de IX nesse registro de instalação. O PeeringDB é mantido pelos operadores e pode estar incompleto, mas continua sendo uma evidência pública útil de que o AS não é apenas uma inscrição abstrata.

O perfil mais amplo do AS28768 emhttps://www.peeringdb.com/api/net?asn=28768é onde a história de interconexão mais ampla aparece. Ele lista um IX e três instalações, e o endpoint netixlan lista France-IX AURA LyonIX. Isso pode apoiar uma hipótese de que a rede mais ampla da Alpilink tem mais caminhos do que apenas AS35667. Isso não prova, sem um esquema de rede específico do cliente, que o tráfego do cliente do AS35667 tem provedores upstream independentes, roteadores de borda independentes, rotas de fibra independentes ou failover automático entre sites. A rota pública do AS35667 aparece atrás do AS28768; os clientes devem perguntar qual diversidade existe por trás desse limite.

A validade RPKI é o ponto de higiene de rota mais forte nas evidências atuais do AS35667. Ela reduz o risco de conflito de origem acidental ou malicioso. Ela não resolve todos os problemas de roteamento. Se o AS28768 falhar, se uma instalação perder energia, se um cross-connect for cortado, se um firewall falhar fechado, se um evento DDoS sobrecarregar a interface, ou se o DNS do cliente depender de um caminho de provedor único, o RPKI não pode restaurar o aplicativo. É um controle de autenticação de rota, não um plano de recuperação operacional.

Energia, refrigeração e densidade são áreas onde a capacidade anunciada deve ser tratada com cautela

As páginas do novo data center da Alpilink são notáveis porque falam diretamente sobre densidade de energia e design térmico. O artigo de janeiro de 2026 diz que o futuro site é projetado para cargas de aplicação crescentes, sistemas de informação críticos e cargas de trabalho de dados/IA. Ele menciona arquitetura modular de várias salas, tetos altos, redundância elétrica, redundância climática, geradores, segurança física, controle de acesso, supervisão, compatibilidade com recuperação de desastres avançada e continuidade de negócios, e um PUE alvo de cerca de 1,3.

A página do projeto diz que o futuro data center visa uma arquitetura equivalente ao Tier III, redundância elétrica total, design modular de várias salas, densidade de energia e gestão eficiente de fluxo quente/frio.

Essas alegações são comercialmente significativas. Elas mostram que a Alpilink entende o problema que muitos provedores regionais de nuvem enfrentam agora: a densidade por rack está aumentando mais rápido do que as salas herdadas foram projetadas para absorver. Uma sala de servidores construída para virtualização modesta pode se tornar restrita quando os clientes solicitam armazenamento denso, análise, IA, appliances de segurança ou hosts com muita memória.

A restrição de capacidade não é mais apenas o número de racks; é a energia por gabinete, o caminho de refrigeração, o gerenciamento de cabos, a capacidade do UPS, a autonomia do gerador, a seletividade do disjuntor, o monitoramento e a capacidade humana de substituir componentes com falha sem perturbar cargas vizinhas.

O momento é importante. As mesmas páginas colocam obras e adaptação em 2026, entrega e testes no início de 2027, e comissionamento progressivo no verão de 2027. Na data de publicação deste artigo, essas salas futuras devem ser tratadas como planejadas ou em desenvolvimento, não como capacidade utilizável já comprovada. Um comprador reservando espaço pode se beneficiar do projeto; um comprador que precisa de recuperação de produção imediata não pode contar com esse futuro site até que esteja comissionado, testado, conectado, contratado e aceito.

As alegações atuais de hospedagem verde também devem ser lidas com cautela. O artigo sobre sustentabilidade de julho de 2024 emhttps://www.alpilink.fr/alpilink-cloud-notre-engagement-envers-un-hebergement-durable/diz que a Alpilink usa parte de sua infraestrutura em um data center ecorresponsável com 100% de eletricidade renovável, refrigeração por calorias de água subterrânea sem consumo de água, conformidade com o Código de Conduta Europeu para Eficiência Energética de Data Centers e eficiência energética abaixo de 1,30 PUE. O artigo de junho de 2024 emhttps://www.alpilink.fr/un-data center-peut-il-etre-vert/diz que o data center da Alpilink Cloud perto de Grenoble é projetado para ser tão virtuoso quanto possível e usa energia hidrelétrica.

Essas alegações de sustentabilidade podem ser forças operacionais. Refrigeração eficiente e energia renovável local podem reduzir custos operacionais e exposição ao risco. Mas PUE e energia verde não provam por si só capacidade de reserva. Uma instalação com baixo PUE pode estar cheia. Um site alimentado por renováveis ainda pode ter restrições de gerador, UPS, refrigeração, manutenção ou pessoal. Um ciclo de vida sustentável do equipamento pode reduzir o desperdício, mas aumenta a necessidade de entender a idade do hardware, política de peças sobressalentes e planejamento de renovação.

Os clientes devem, portanto, perguntar sobre capacidade atual por rack, consumo de energia, alocação de refrigeração e nível de serviço, em vez de confiar apenas na linguagem de sustentabilidade.

Localização de dados é uma força, mas deve ser especificada serviço por serviço

O posicionamento da Alpilink é construído em torno da soberania francesa. A página Serviços Cloud diz que a empresa oferece hospedagem soberana na França e suporte francês. O artigo sobre Tech & Fest 2026 emhttps://www.alpilink.fr/techfest-2026-alpilink-services-cloud-au-coeur-des-enjeux-de-souverainete-numerique/enquadra a Alpilink Services Cloud em torno da soberania, nuvem e continuidade de negócios em Grenoble. A página de garantias HDS aborda explicitamente a hospedagem de dados de saúde, localização de dados, certificação, papéis dos subcontratados e risco de acesso por um país terceiro. Essa é uma divulgação mais útil do que um mero selo de “nuvem segura”.

A regra prática é sempre serviço por serviço. A VM de produção de um cliente pode estar na própria instalação da Alpilink. Uma cópia de backup pode estar em outro data center conectado. Uma dependência de rack para dados de saúde pode envolver a Orange - La Fabrique. O acesso ao suporte pode envolver pessoal no Taiti via acesso criptografado. O DNS pode estar em um sistema, as faturas em outro e a documentação do cliente em outro.

Uma alegação de soberania é mais forte quando cada uma dessas superfícies é mapeada: computação, armazenamento, backups, logs, tickets, monitoramento, e-mail, credenciais, administração e runbooks de recuperação de desastres.

A página HDS dá uma vantagem aos clientes porque nomeia os papéis e diz que nenhuma transferência de dados de saúde pessoais para um país terceiro fora do Espaço Econômico Europeu é feita pela Alpilink Cloud nesse contexto. Ela também indica que a Alpilink Cloud não é qualificada SecNumCloud 3.2 na tabela exibida. Essa distinção é importante. HDS e ISO 27001 podem ser controles sólidos para usos particulares, mas não são idênticos à qualificação SecNumCloud, nem prova de resiliência completa, nem garantia de que cada produto, cliente ou componente subcontratado está no mesmo escopo.

Para cargas de trabalho não relacionadas à saúde, a mesma diligência se aplica com rótulos diferentes. Onde estão os dados? Quem pode acessá-los? Qual país rege o contrato? Quais subcontratados fornecem rack, rede, energia, monitoramento ou suporte? Com que rapidez o cliente pode exportar seus dados? Os backups são armazenados no mesmo domínio jurídico e operacional que a produção? Os logs são mantidos na França? As chaves de criptografia são detidas pelo cliente, pelo provedor ou compartilhadas?

Se um cliente precisar sair, ele pode obter imagens de disco, dumps de banco de dados, exportações de armazenamento de objetos e controle DNS sem esperar por uma fila de suporte manual?

A versão mais forte da oferta da Alpilink é local, específica e operacional: pessoal centrado em Grenoble, instalações francesas, certificações nomeadas, racks concretos, recursos de rede conhecidos e caminhos de migração acessíveis. A versão mais fraca seria um slogan de soberania amplo sem mapeamento por serviço. Os arquivos públicos estão mais próximos da versão forte do que muitos provedores, mas um comprador ainda precisa do cronograma exato e do escopo do produto para sua própria implantação.

Caminhos de falha: o que quebra primeiro e quem é afetado

O caminho de falha mais óbvio é um problema de rack ou instalação. Clientes de hospedagem podem perder energia, refrigeração, cross-connects ou acesso a mão remota. Clientes de IaaS podem sofrer falha de host, armazenamento ou rede. Clientes de serviços gerenciados também podem perder a sequência de operações de pessoal necessária para diagnosticar incidentes. Se o local afetado for o próprio data center da Alpilink, o provedor controla mais a resposta. Se o ativo afetado for um rack de colocation subcontratado, o provedor deve coordenar com o operador de colocation. Essa distinção importa durante uma falha noturna ou de fim de semana.

O caminho de falha de rota é mais estreito, mas visível. O AS35667 transita publicamente pelo AS28768 nos dados observados. Se a fronteira interna entre AS35667 e AS28768, os roteadores do AS pai, ou o tecido de provedor upstream/de peering atrás do AS28768 tiverem problemas, os clientes numerados a partir de 94.143.216.0/21 podem ver efeitos de alcance. A validade RPKI não ajudará se o caminho autorizado estiver fisicamente ou operacionalmente fora de serviço.

Os clientes devem perguntar se os prefixos do cliente podem ser movidos, se existem vários dispositivos de borda, onde os dispositivos estão localizados e se a diversidade de caminho é testada em vez de apenas configurada.

O caminho de falha de suporte é humano. A alegação de suporte 24 horas da Alpilink é valiosa, e a referência da página HDS ao suporte baseado no Taiti pode melhorar a cobertura. Mas os clientes devem saber o que esse suporte pode realmente fazer. A equipe noturna pode reiniciar um host? Pode substituir um disco? Pode acessar a instalação? Pode aprovar mudanças de rota? Pode restaurar um backup? Pode se comunicar no idioma exigido pelo cliente? Pode agir quando restrições de dados de saúde se aplicam? A diferença entre “vimos o alerta” e “restauramos o serviço” é a diferença entre monitoramento e recuperação.

O caminho de falha de migração é o mais silencioso e muitas vezes o mais caro. Os serviços de nuvem atuais da Alpilink e o futuro projeto de data center fazem da migração uma questão central. Os clientes podem precisar mudar de uma sala existente da Alpilink para o novo site de Saint-Martin-d'Hères, de um rack legado para uma sala de alta densidade, de servidores físicos para IaaS, ou da Alpilink para outro provedor. Cada mudança depende de renumeração de rede, TTLs de DNS, exportação de backup, replicação de armazenamento, janelas de manutenção, dependências de aplicativos e disponibilidade de pessoal.

Uma construção de data center futuro só melhora a resiliência após a execução do plano de migração.

As partes afetadas são mais amplas do que o comprador direto. Os serviços de nuvem da Alpilink atendem organizações que se preocupam com soberania, hospedagem de dados de saúde, operações gerenciadas, continuidade de negócios e suporte local. Se um rack, rota, cluster de armazenamento ou processo de suporte falhar, os usuários finais podem perder sites públicos, sistemas de turismo ou comércio, aplicativos internos relacionados a pagamentos, serviços internos corporativos, fluxos de trabalho de dados de saúde, restaurações de backup ou etapas de recuperação de desastres.

Os artigos públicos em torno do Tech & Fest descrevem CIOs, CISOs e equipes de negócios em busca de modelos regionais e soberanos de nuvem. Esses são precisamente os usuários para os quais o tempo de recuperação, localização de dados e escalonamento de suporte não são preocupações abstratas.

O que faria a nota das evidências subir ou descer

A nota atual das evidências é Média-forte para identidade e higiene de rede porque RIPE RDAP, RIPEstat e PeeringDB concordam sobre a empresa, o AS, o bloco de endereços, a visibilidade de rota e o contexto da instalação francesa. É Média para resiliência do cliente porque as evidências públicas não mostram o mapa de serviço em tempo real por trás das alegações agregadas. A Alpilink publica mais detalhes operacionais do que muitos provedores pequenos, mas os clientes ainda precisam de confirmação direta sobre localização atual de racks, capacidade utilizável, design de energia, isolamento de backup e autoridade de suporte.

A nota melhoraria se a Alpilink publicasse uma declaração de infraestrutura datada que mapeia os serviços atuais para instalações, explica quais data centers estão conectados pelo anel óptico, indica onde estão os dispositivos de borda do AS35667 e AS28768, nomeia os acordos atuais de provedor upstream/transit no nível de serviço, fornece uma página de status ou histórico de incidentes pública, descreve a separação de backup e distingue a capacidade atual do site de 2027.

Melhoraria se a empresa publicasse orientações de migração legíveis pelo cliente para a construção de Saint-Martin-d'Hères, incluindo testes de aceitação, rollback, planos de rota e janelas de suporte.

A nota diminuiria se o AS35667 perdesse ampla visibilidade de rota, se o status RPKI válido desaparecesse sem explicação, se as informações de instalação do PeeringDB se tornassem obsoletas ou contraditórias, se as páginas de primeira parte parassem de distinguir serviços atuais de capacidade futura, se as declarações HDS/ISO se tornassem pouco claras, ou se os clientes não conseguissem obter fatos atuais sobre instalação e recuperação no contrato. Também diminuiria se o projeto de futuro data center fosse comercializado como redundância de produção utilizável antes de ser comissionado e testado.

O ponto mais importante é que os arquivos públicos da Alpilink não estão vazios. Eles são substanciais. A cautela vem da precisão, não da ausência. Um comprador tem evidências suficientes para justificar uma avaliação séria. Ainda não tem evidências públicas suficientes para pular a diligência técnica.

O que os clientes devem exigir antes de contar a capacidade

A maneira mais prática de comprar da Alpilink é solicitar um mapa de carga de trabalho antes de tratar qualquer número global como capacidade disponível. O mapa deve nomear a instalação onde a computação de produção é executada hoje, a instalação onde os backups residem, o caminho de rota usado pelos endereços públicos do cliente, a camada de armazenamento por trás das máquinas virtuais, a equipe de suporte que pode agir fora do horário comercial e o método de migração se o cliente se mudar para o site planejado de Saint-Martin-d'Hères. Esse pedido não é tratamento especial.

É a tradução mínima das alegações de infraestrutura pública em um plano operacional específico do cliente.

Para resiliência de rota, o mapa deve separar AS35667 do contexto mais amplo do AS28768. As evidências públicas do RIPEstat mostram AS35667 com um único /21 IPv4 visível e um vizinho observado, enquanto o PeeringDB mostra AS28768 com uma pegada de instalação e troca mais ampla. Essa diferença pode ser perfeitamente razoável dentro de um grupo de provedores, mas um cliente não deve assumir que cada caminho do AS28768 protege cada serviço do AS35667.

O contrato deve dizer qual AS origina os endereços do cliente, onde estão os roteadores de borda, quais caminhos de provedor upstream ou peering transportam o tráfego, se o failover foi testado e se o DNS e o acesso de controle do cliente dependem do mesmo local.

Para resiliência de instalações, o mapa deve distinguir a operação do próprio data center da Alpilink da dependência de rack na Orange - La Fabrique mencionada na página de garantias HDS. Um cliente cuja carga de trabalho está hospedada em uma sala operada pela Alpilink enfrenta um modelo de resposta; um cliente cuja carga de trabalho depende de racks subcontratados enfrenta outro.

O comprador deve saber quem controla o acesso físico, quem pode substituir equipamentos, quem possui a resposta a incidentes de energia, quais janelas de manutenção se aplicam e quais créditos de serviço ou direitos de saída se aplicam se um ou outro site estiver indisponível. Sem esse detalhe, a frase “três data centers conectados” continua sendo um contexto de marketing útil, em vez de prova de redundância no nível do cliente.

Para capacidade instalada versus capacidade utilizável, o comprador deve solicitar números atuais em vez de números de projeto. Os 1.500 servidores hospedados, 3 PB de dados armazenados e 40 Gbit/s de largura de banda da página Serviços Cloud descrevem uma escala agregada. As páginas do projeto Grenoble 2027 descrevem futuras salas de alta densidade, resiliência com geradores e metas de PUE. Nenhum desses conjuntos de números diz a um cliente específico quanta CPU, RAM, armazenamento, energia de gabinete, capacidade de cross-connect ou tempo de suporte estão disponíveis hoje.

Um cliente planejando uma implantação crítica deve perguntar qual capacidade está livre, qual está reservada, qual está sobreassinada, qual requer compra de hardware e qual depende do cronograma de comissionamento de 2027.

Para recuperação, o mapa deve incluir prova de restauração. Backups e recuperação de desastres terceirizados só valem a pena se o caminho de backup estiver suficientemente separado da falha de produção. Os clientes devem exigir evidências recentes de teste de restauração, localização do backup, controles de acesso ao backup, propriedade das chaves de criptografia, estimativas de tempo de restauração, prioridades de ordem de restauração e uma rota de exportação de dados que não dependa de uma única fila de suporte sobrecarregada.

Um provedor pode ter forças regionais reais e ainda deixar um cliente exposto se o processo de recuperação for manual, não documentado ou vinculado ao mesmo sistema de armazenamento falho.

Essas perguntas não tornam a Alpilink um candidato fraco. São as perguntas que um provedor regional credível deve ser capaz de responder. As evidências públicas já mostram um operador de nuvem francês roteável com um investimento de infraestrutura visível. A peça que falta não é a identidade; é a prova de resiliência específica do cliente. Uma vez que o mapa de carga de trabalho existente, a presença local da Alpilink, suas alegações de conformidade, seu foco em Grenoble e seu futuro projeto de data center podem ser avaliados em relação a um modelo de falha real, em vez de um folheto.

Conclusão para operadores dependentes

XSALTO35667 Alpilink Cloud S.A.S. deve ser tratado como um operador regional francês real de nuvem e hospedagem com evidências de identidade pública mais fortes que a média. AS35667 está registrado na Alpilink Cloud S.A.S., seu principal /21 IPv4 visível é amplamente anunciado, o RPKI é válido, o PeeringDB lista XSALTO Grenoble, e as próprias páginas de nuvem da Alpilink descrevem hospedagem, IaaS, máquinas virtuais, serviços gerenciados, backups, recuperação de desastres, certificações, garantias de dados de saúde e uma história de múltiplos data centers. O quadro operacional é específico o suficiente para contar.

O quadro de dependências também é específico o suficiente para ser questionado. A superfície de rota pública do AS35667 é estreita. A rede mais ampla do AS28768 parece mais diversificada, mas o caminho exato do cliente deve ser verificado. As alegações de escala dos Serviços Cloud são de primeira parte e agregadas. O novo projeto de data center em Grenoble está planejado para 2027 e não deve ser contado como capacidade de produção utilizável em julho de 2026. As alegações HDS, ISO 27001 e de sustentabilidade são valiosas, mas devem ser mapeadas para a instalação, serviço e caminho de suporte reais do cliente.

Para um cliente atual, as perguntas práticas são diretas. Qual instalação hospeda minha carga de trabalho hoje? Qual AS e prefixo a transportam? Quais provedores upstream e roteadores estão em meu caminho? Os backups estão fora do domínio de falha de produção? Qual equipe pode agir fora do horário comercial? Qual é meu tempo de restauração para um host com falha, um sistema de armazenamento, um evento de energia de rack, um problema de rota ou uma falha de site? Se eu precisar migrar para o novo data center, o que deve mudar e quem possui cada etapa?

Para um novo comprador, os arquivos públicos apoiam uma conversa qualificada, não uma compra cega. A Alpilink tem os ingredientes visíveis de um provedor regional de nuvem credível: recursos de roteamento reais, contexto de instalação nomeado, operações locais, alegações de conformidade e um plano de investimento em infraestrutura. A decisão de compra deve depender de evidência atual de capacidade utilizável, isolamento de falha e direitos de saída. A capacidade hospedada sempre se resolve em dependências físicas.

No caso da Alpilink, essas dependências são visíveis o suficiente para fazer perguntas melhores: racks em Grenoble, controle de rota via AS35667 e AS28768, limites de energia e refrigeração, autoridade de suporte 24 horas, separação de backup e caminho de migração das salas de hoje para o site prometido de amanhã.