cnh-primary CLOUD & HEAT Technologies GmbH vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• cnh-primary mapeia para AS203592, o sistema autônomo registrado no RIPE denominado "cnh-primary" e registrado na CLOUD & HEAT Technologies GmbH. O RDAP do RIPE mostra o AS como ativo, e o RIPEstat mostrou que foi anunciado em 15/07/2026 às 00:00 UTC.
• A superfície de rota é atual e excepcionalmente bem documentada para este lote: o RIPEstat listou 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 e 2a0c:2c0:dd80::/44 como anunciados pelo AS203592, com RPKI válido para todas as quatro origens observadas.
• O PeeringDB registra AS203592 como CLOUD & HEAT Technologies GmbH, com uma instalação listada, IBH Dresden C2, e uma conexão DD-IX a 10 Gbps com endereços IPv4 e IPv6 e participação em servidor de rotas.
• As páginas da própria empresa descrevem IaaS, Kubernetes gerenciado, distribuição on-premises baseada em OpenStack, instâncias GPU, armazenamento Ceph, hospedagem em data center alemão, certificações ISO 27001 e ISO 9001, trabalho em nuvem compatível com SCS e clientes como Scalytics, tracetronic, Nyris, elevait, alphaspeech, flow.d e N+P.
• A nota da evidência é Forte para identidade de rede e existência do produto, Médio para instalação e localidade de interconexão, e apenas Médio para resiliência porque o material público não divulga número de racks, topologia de energia, pools de servidores sobressalentes, posicionamento exato de zonas de disponibilidade, prova de backup, testes de exportação de cliente ou histórico de incidentes.

O nome começa como rota, mas a empresa é mais ampla que uma rota

A entrada do diretório emhttps://btw.media/en/directory/cnh-primary-cloud-heat-technologies-gmbhaponta para uma identidade de infraestrutura pública muito específica: cnh-primary CLOUD & HEAT Technologies GmbH. A parte "cnh-primary" não é floreio de marketing. É o nome AS do RIPE para AS203592, mostrado no Banco de Dados do RIPE emhttps://rest.db.ripe.net/ripe/aut-num/AS203592.jsone no RDAP emhttps://rdap.db.ripe.net/autnum/203592. O AS foi registrado em 4 de dezembro de 2015 e alterado pela última vez em 28 de janeiro de 2026. O RDAP identifica o registrante como CLOUD & HEAT Technologies GmbH, com o endereço de Dresden também visível nas páginas de contato da própria empresa. Isso dá ao artigo um ponto de partida mais firme do que muitos perfis de pequenas nuvens: há uma empresa nomeada, um AS nomeado, uma identidade de escritório público e um registro ativo de número de Internet.

A segunda camada é a evidência do produto. A página inicial em inglês da CLOUD & HEAT emhttps://www.cloudandheat.com/en/descreve a empresa como um provedor de serviços e tecnologia de nuvem de Dresden com produtos construídos em OpenStack, Proxmox VE e Kubernetes. Sua página de IaaS emhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/infrastructure-as-a-service/vende tamanhos de computação, armazenamento de bloco e objeto, instâncias GPU e capacidade de nuvem hospedada na Alemanha. Sua página de Kubernetes gerenciado emhttps://www.cloudandheat.com/en/products/cloud-services-in-germany/managed-kubernetes-germany/descreve modelos de Kubernetes autogerenciados, sob demanda, básicos e de serviço completo. Sua página Patron emhttps://www.cloudandheat.com/en/products/on-premises-cloud-infrastructures/on-premises-cloud-tailored/cloudandheat-a-ready-to-use-openstack-distribution/vende uma distribuição OpenStack e suporte opcional de operações. Isso não é meramente um AS adormecido anexado a uma página vazia.

No entanto, a empresa tem mais de uma camada operacional, e essas camadas não devem ser colapsadas. AS203592 é a camada de roteamento pública. As páginas de IaaS e Kubernetes são páginas de produto. As páginas Patron e on-premises são ofertas de consultoria, software e operação gerenciada. As páginas de eficiência energética e perfis OpenInfra descrevem sustentabilidade e posicionamento em código aberto. Um cliente que compra uma máquina virtual depende de coisas diferentes de um cliente que compra uma distribuição OpenStack suportada para seu próprio hardware.

Um cliente que usa Kubernetes gerenciado depende de acesso à API, clusters, volumes persistentes, monitoramento e janelas de manutenção. Um cliente que compra consultoria depende de pessoas e processos mais do que de AS203592. A evidência pública da empresa é real, mas cada produto tem um caminho de falha diferente.

A questão principal, portanto, não é se a CLOUD & HEAT existe. Ela claramente existe. A questão é o que a evidência pública suporta quando a empresa é lida como infraestrutura hospedada. RIPE, RIPEstat e PeeringDB suportam um mapa de rede AS203592. O site da empresa suporta um catálogo de nuvem pública e serviço gerenciado. O OpenStack Marketplace emhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslista serviços de nuvem da Cloud & Heat e diz que o produto é OpenStack Powered. O perfil de empresa apoiadora do OpenStack emhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdescreve a Cloud & Heat como um provedor de Dresden de serviços e tecnologias de nuvem. Nenhuma dessas fontes, no entanto, fornece uma auditoria completa de capacidade pública.

Esta é a distinção que importa para os compradores. Um AS público pode estar saudável enquanto uma zona de disponibilidade não tem máquinas sobressalentes. Uma nuvem OpenStack pode ser listada enquanto uma classe específica de GPU está esgotada. Uma oferta de Kubernetes gerenciado pode prometer monitoramento enquanto um cliente ainda precisa de seu próprio plano de backup, implantação e exportação. Uma entrada de instalação pode mostrar uma presença em Dresden sem revelar número de racks, design de alimentação elétrica ou termos de mão remota.

O registro público é forte o suficiente para colocar cnh-primary em uma categoria séria de infraestrutura, mas ainda tem que ser lido com cautela de engenharia.

A evidência de rota é atual, visível e mais limpa que uma página de empresa simples

A visão geral do AS do RIPEstat para AS203592 emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS203592identificou o titular como "cnh-primary CLOUD & HEAT Technologies GmbH" e mostrou announced=true em 15/07/2026 às 00:00 UTC. Esse é um sinal específico no tempo, mas importante: o AS não estava apenas registrado; estava visível nos dados de roteamento público na data de publicação. O endpoint de prefixos anunciados do RIPEstat emhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS203592listou quatro rotas na janela de duas semanas terminando em 15 de julho de 2026: 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29 e 2a0c:2c0:dd80::/44.

O endpoint de status de roteamento emhttps://stat.ripe.net/data/routing-status/data.json?resource=AS203592tornou o sinal mais forte. Ele relatou dois prefixos IPv4, dois prefixos IPv6, 1.280 endereços IPv4, 524.288 unidades IPv6 /48, quatro vizinhos observados e visibilidade total observada no conjunto de peers RIPE RIS para IPv4 e IPv6 no momento da consulta. Esses números não são capacidade de cliente. Eles mostram que AS203592 era amplamente visível a partir de coletores de rota e não uma nota de rodapé privada de um único peer.

As visualizações individuais de prefixo se alinham. O RIPEstat mostrou 185.128.116.0/22 anunciado por AS203592 emhttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.128.116.0/22e 94.198.185.0/24 anunciado por AS203592 emhttps://stat.ripe.net/data/prefix-overview/data.json?resource=94.198.185.0/24. Também mostrou o agregado IPv6 2a0c:2c0::/29 emhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0::/29e o mais específico 2a0c:2c0:dd80::/44 emhttps://stat.ripe.net/data/prefix-overview/data.json?resource=2a0c:2c0:dd80::/44. A relação mais específica do IPv6 é importante porque sugere uso segmentado de IPv6 em vez de uma única alocação indiferenciada.

RPKI também está alinhado. O RIPEstat retornou válido para AS203592 e 185.128.116.0/22 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=185.128.116.0/22, válido para 94.198.185.0/24 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=94.198.185.0/24, válido para 2a0c:2c0::/29 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0::/29e válido para 2a0c:2c0:dd80::/44 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=AS203592&prefix=2a0c:2c0:dd80::/44. A validade do RPKI não impede uma falha de rack, mas reduz uma classe de falha de roteamento: redes restritas têm menos probabilidade de rejeitar essas origens como inválidas.

O Banco de Dados do RIPE também mostra continuidade administrativa por trás dos prefixos. A visão WHOIS de 185.128.116.0/22 emhttps://stat.ripe.net/data/whois/data.json?resource=185.128.116.0/22mostra netname DE-CLOUDANDHEAT-20151125, país DE, organização ORG-CHTG1-RIPE e um objeto de rota originado por AS203592. A visão de 94.198.185.0/24 emhttps://stat.ripe.net/data/whois/data.json?resource=94.198.185.0/24mostra netname DE-CLOUDANDHEAT-20081029, país DE e um objeto de rota originado por AS203592 após uma atualização de janeiro de 2026. A visão de 2a0c:2c0::/29 emhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0::/29mostra uma alocação RIPE de 2018 para a mesma organização e objetos route6 para AS203592. A visão de 2a0c:2c0:dd80::/44 emhttps://stat.ripe.net/data/whois/data.json?resource=2a0c:2c0:dd80::/44é especialmente interessante porque é nomeada IBH-DD8 e tem uma data de criação de dezembro de 2025. Isso aponta para um segmento local de Dresden mais recente, mas ainda não revela as cargas de trabalho por trás dele.

Para um cliente, a conclusão da rota é direta. AS203592 é uma rede ativa, e a evidência pública de roteamento é forte. A conclusão mais difícil é sobre capacidade de serviço. Prefixos e ROAs não nos dizem quantos hipervisores estão instalados, quantos inquilinos estão ativos, quais sabores estão esgotados, onde o pool de GPU está fisicamente localizado ou com que frequência o armazenamento em bloco é testado após uma falha de nó. Eles respondem à pergunta de identidade de rede. Eles não respondem à pergunta de aquisição.

O registro de instalação e intercâmbio de Dresden é real, mas não é a nuvem inteira

O PeeringDB adiciona a pista física pública mais clara. A consulta de rede emhttps://www.peeringdb.com/api/net?asn=203592lista CLOUD & HEAT Technologies GmbH como AS203592, com escopo regional, IPv6 habilitado, política de peering aberta, um intercâmbio e uma instalação. O objeto de rede emhttps://www.peeringdb.com/api/net/40650mostra o conjunto de instalações como IBH Dresden C2 e o intercâmbio como DD-IX. O endpoint netfac emhttps://www.peeringdb.com/api/netfac?net_id=40650repete a associação IBH Dresden C2. O endpoint netixlan emhttps://www.peeringdb.com/api/netixlan?asn=203592lista DD-IX, campo de velocidade 10 Gbps, endereço IPv4 193.201.151.80, endereço IPv6 2001:7f8:79::3:1b48:1, peer de servidor de rotas verdadeiro e operacional=true.

Essa combinação é excepcionalmente útil. Ela coloca AS203592 em um ambiente de interconexão nomeado em Dresden, em vez de deixar os leitores apenas com um endereço corporativo. O registro de instalação do PeeringDB emhttps://www.peeringdb.com/api/fac/14039identifica IBH Dresden C2 como uma instalação da IBH connect GmbH em Dresden, com o caminho público do site para housing e rackpace emhttps://www.ibh.de/rechenzentrum/housing-rackpace. O registro de intercâmbio DD-IX emhttps://www.peeringdb.com/api/ix/4282identifica DD-IX como um intercâmbio em Dresden, lista IBH Dresden C2 e SachsenEnergieCenter Dresden em seu conjunto de instalações, e aponta parahttps://dd-ix.net,https://dd-ix.net/statsehttps://status.dd-ix.net. O site da DD-IX descreve o intercâmbio como uma plataforma não comercial para Dresden, construída para manter o tráfego local local e servir a região da Saxônia.

A leitura física ainda deve ser precisa. O PeeringDB prova que AS203592 tem uma associação de instalação listada na IBH Dresden C2 e uma conexão DD-IX. Não prova que toda a computação IaaS da CLOUD & HEAT está nessa única instalação. Não prova o layout de armazenamento. Não revela se a porta DD-IX está diretamente conectada a hipervisores de cliente, um roteador de borda, um segmento de laboratório, uma rede de gerenciamento ou uma borda voltada para intercâmbio.

Não revela diversidade de cross-connect, diversidade de switch, alimentações elétricas de rack, cobertura de gerador, redundância de resfriamento ou compromissos de reparo de mão remota.

A própria empresa amplia o quadro além de uma única instalação do PeeringDB. Sua página de IaaS diz que a infraestrutura de nuvem pública é operada exclusivamente em data centers na Alemanha e que os dados do cliente são processados e armazenados em conformidade com o GDPR. A página de Kubernetes gerenciado diz que os dados do Kubernetes são processados e armazenados em data centers certificados ISO 27001 em conformidade com o GDPR na Alemanha. Seu artigo SCS de 2024 emhttps://www.cloudandheat.com/en/news-press/strengthening-digital-sovereignty-new-ways-in-the-cloud-with-yaook-and-scs-compatibility/discute um projeto de data center em Leipzig com envia TEL, Yaook e SCS. Sua notícia de certificação de 2026, proveniente do mesmo site, diz que a Cloud&Heat recebeu reconhecimento "Certified SCS-compatible IaaS" e que o prêmio seria apresentado no SCS Summit em 21 de junho de 2026. Esses pontos tornam a pegada mais do que uma história de porta AS única, mas não transformam todo o mapa de capacidade em conhecimento público.

Energia e resfriamento fazem parte da dependência física, não apenas uma afirmação de sustentabilidade. A página de IaaS diz que a Cloud&Heat usa resfriamento direto a água quente e integração em circuitos de aquecimento locais para permitir operação eficiente em energia e uso de calor residual do servidor. A página do OpenStack marketplace também descreve servidores resfriados a água e o reuso do calor residual do servidor.

Este é um contexto útil: se a nuvem é projetada em torno do reuso de calor, a planta do edifício, o circuito de água, o trocador de calor, a retirada de calor local e as janelas de manutenção tornam-se parte da dependência do serviço. Um cliente de data center convencional pergunta principalmente sobre redundância de energia e resfriamento. Um cliente da Cloud&Heat também deve perguntar como a manutenção do reuso de calor é isolada da disponibilidade de computação.

A evidência de Dresden, portanto, suporta uma afirmação intermediária. Há prova pública de um ponto de interconexão em Dresden e prova pública da empresa de hospedagem em nuvem alemã. Não há prova pública suficiente para mapear cada carga de trabalho de cliente para um rack, cada zona de disponibilidade para um edifício ou cada instância GPU para uma cadeia específica de energia e resfriamento. Os compradores podem tratar Dresden como um centro operacional significativo, não como um diagrama de infraestrutura completo.

A evidência do produto é mais forte para OpenStack e Kubernetes do que para capacidade sobressalente

As páginas de produto da CLOUD & HEAT são excepcionalmente concretas para um provedor de nuvem regional. A página de IaaS lista tamanhos de computação de 1 vCPU / 2 GB RAM / 15 GB SSD até 8 vCPU / 30 GB RAM / 100 GB SSD, oferece famílias de preço padrão e Memory+, anuncia armazenamento HDD em bloco/objeto e diz que os clusters de armazenamento são clusters Ceph triplamente redundantes para armazenamento de objeto e bloco. Também lista classes de instância GPU, incluindo T4, A10, V100 e A100. Essa página diz explicitamente que um pool NVMe triplamente replicado pode ser fornecido dentro das capacidades disponíveis.

Essa frase é importante: a empresa vende recursos úteis, mas também reconhece que alguma classe de armazenamento é limitada em capacidade.

A página de Kubernetes gerenciado é igualmente específica. Ela descreve uma opção autogerenciada no OpenStack, suporte sob demanda, Managed Kubernetes Basic com suporte 9/5 e tempo de resposta de quatro horas, e Managed Kubernetes Full Service com diferentes níveis de suporte. Ambos os níveis gerenciados listam implantação em várias zonas de disponibilidade para alta disponibilidade, proteção de API via VPN, administração de cluster baseada em GitOps, serviço de balanceador de carga, volumes persistentes OpenStack Cinder, armazenamento estático e dinâmico local e políticas de rede.

Full Service adiciona ingress, Certmanager, uma pilha de monitoramento Prometheus e Grafana, monitoramento e alerta de cluster 24/7 e instâncias GPU. Essas são afirmações operacionais, não apenas slogans.

A página Patron fortalece o lado OpenStack da história. Ela diz que Cloud&Heat Patron é uma distribuição OpenStack pronta para uso, baseada em gerenciamento de ciclo de vida de código aberto com Yaook, com componentes de nível empresarial, compatibilidade SCS, automação, sem vendor lock-in e opções de suporte. A página oferece um modelo onde o cliente opera a nuvem e um modelo onde a Cloud&Heat fornece operação e monitoramento, análise de falhas, reparo de falhas e manutenção, como atualizações. Ela menciona opções de contrato de suporte 9-5 e 24/7.

Isso nos diz que a CLOUD & HEAT não está apenas revendendo máquinas virtuais; ela vende conhecimento operacional em torno do próprio OpenStack.

Fontes do OpenInfra corroboram o posicionamento de infraestrutura aberta. A página do OpenStack Marketplace emhttps://www.openstack.org/marketplace/public-clouds/cloud-and-heat/cloud-heat-cloud-serviceslista serviços de nuvem da Cloud & Heat e diz que o produto é OpenStack Powered. A página de empresa apoiadora do OpenInfra emhttps://www.openstack.org/community/supporting-organizations/profile/cloud-and-heatdescreve sua pilha de tecnologia como incluindo OpenStack, Kubernetes, Yaook e Krake, e diz que a empresa contribui para os esforços do Sovereign Cloud Stack. A página do Fórum de Padrões SCS emhttps://sovereigncloudstack.org/en/about-scs/forum-scs-standards/lista a Cloud&Heat Technologies GmbH entre os membros comprometidos com infraestruturas de nuvem seguras e observa a colaboração com a Open Infrastructure Foundation.

O sinal do cliente também é público. A página de IaaS nomeia Scalytics, tracetronic, Nyris, elevait, alphaspeech e flow.d entre os clientes. A página de Kubernetes gerenciado nomeia N+P Informationssysteme GmbH e elevait GmbH & Co. KG. A página inicial traz citações de N+P, elevait e STACKIT: N+P e elevait descrevem a Cloud&Heat como seu provedor de Kubernetes gerenciado, enquanto a STACKIT descreve a Cloud&Heat como um parceiro de tecnologia de nuvem ajudando com conhecimento de OpenStack. A página do OpenStack Marketplace linka para estudos de caso de clientes para elevait, N+P, Nyris e flow.d.

Esses são sinais significativos de partes afetadas, mas não são um inventário de inquilinos.

A distinção entre instalado e utilizável é onde a análise tem que desacelerar. Capacidade instalada são os servidores, armazenamento, GPUs, switches, portas DD-IX, upstreams, clusters OpenStack, planos de controle Kubernetes e ferramentas de suporte sob o controle ou gerenciamento da empresa. Capacidade utilizável é a porção que um cliente pode pedir, alocar, manter em execução, recuperar e sair sem tempo de inatividade inaceitável. As páginas públicas mostram classes de produto, modelos de suporte, nomes de clientes e escolhas de tecnologia.

Elas não mostram estoque atual de GPU, cotas por sabor, contagem total de hipervisores, design de domínio de falha do Ceph, índices de sobreassinatura, calendários de manutenção, retenção de backup ou recuperação testada entre zonas.

A ressalva "dentro das capacidades disponíveis" na nota de armazenamento NVMe é uma janela útil para a realidade da economia de nuvens menores. Um provedor de nuvem pode anunciar uma classe de armazenamento e ainda limitar essa classe porque unidades de alto desempenho são caras, a energia da instalação é finita, a replicação de armazenamento consome capacidade bruta e a demanda do cliente muda. Isso não torna a oferta fraca. Isso a torna física. Um comprador deve traduzir cada linha de serviço em uma pergunta de capacidade: quanto está instalado, quanto está reservado, quanto pode ser entregue este mês e o que muda quando a demanda dispara?

O risco de upstream, suporte e reparo fica abaixo da camada de marketing

A política de roteamento público no Banco de Dados do RIPE lista AS3320, AS15372, AS6830 e AS8220 em torno de AS203592. O endpoint de vizinhos observados do RIPEstat emhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS203592viu AS15372, AS3320, AS8220 e AS213973 em 14 de julho de 2026. O RIPEstat identifica AS15372 como IBH connect emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS15372, AS3320 como Deutsche Telekom emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS3320, AS8220 como Colt emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS8220, AS6830 como Liberty Global emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS6830e AS213973 como BCIX Management emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS213973. Esta é uma mistura crível de sinais de conectividade local, nacional e comercial.

A ressalva é que uma lista de vizinhos públicos não é um mapa de contrato. Ela não diz qual caminho é trânsito pago, qual caminho é peering, qual caminho é backup, quais prefixos são aceitos onde, quais filtros de rota são restritos, quais janelas de manutenção se sobrepõem, ou se o tráfego do cliente está fixado em uma borda específica. Também não prova que um endpoint de API Kubernetes e um backend de armazenamento IaaS têm proteção de rede idêntica. A boa notícia é que AS203592 não é publicamente visível como uma ilha de vizinho único.

A questão de aquisição é se o serviço relevante do cliente tem diversidade de caminho real suficiente para sobreviver à falha específica com a qual o cliente se preocupa.

A falha de instalação é a próxima camada. Se uma carga de trabalho é executada em um data center alemão conectado a AS203592, o serviço depende de energia do rack, resfriamento, cross-connects upstream, switches, roteadores, redes de armazenamento e acesso de pessoal. A instalação do PeeringDB para IBH Dresden C2 lista diversas subestações de alimentação=true, o que é uma pista positiva em nível de instalação.

Ainda não divulga o design de energia do rack da CLOUD & HEAT, cobertura de alimentação dupla, bypass de manutenção, tempo de bateria, histórico de teste de gerador ou se uma VM específica do cliente pode ser movida para longe da instalação afetada durante um incidente local. A conexão DD-IX ajuda com a troca de tráfego local, mas uma interrupção de intercâmbio e uma interrupção de data center são eventos diferentes.

A falha de suporte é igualmente importante. A página de Kubernetes gerenciado fornece um nível de suporte 9/5 com tempo de resposta de quatro horas para Basic e monitoramento e alerta 24/7 para Full Service. A página Patron oferece opções de contrato de suporte 9-5 e 24/7 para ambientes OpenStack operados. A página de IaaS promete aconselhamento pessoal e orientado a serviço de especialistas em OpenStack e DevOps. Esses são compromissos públicos úteis, mas o cliente ainda precisa do contrato.

A página não divulga metas de escalonamento para falha de armazenamento, evacuação de hipervisor, substituição de GPU, vazamento de rota, interrupção de DNS, ticket de abuso, bloqueio de faturamento ou exportação de dados de emergência.

A evidência de DNS adiciona uma pista operacional pequena, mas útil. Uma consulta DNS durante esta revisão resolveuwww.cloudandheat.comatravés de cloudandheat.com para 185.128.119.78, que está dentro do prefixo 185.128.116.0/22 anunciado por AS203592. A mesma consulta mostrou mail.cloudandheat.com como MX, nameservers INWX e registros SPF que incluem o host de mail e Google. Isso sugere que o site público é servido a partir do próprio espaço roteado da empresa, em vez de apenas de um grande CDN de terceiros. Isso é positivo para identidade de rede, mas também significa que o site público da empresa pode ser afetado por seu próprio AS, host web ou dependências de instalação.

O caminho de impacto do cliente segue da pilha de produtos. Uma falha de rede pode afetar a acessibilidade da nuvem pública, APIs Kubernetes gerenciado, balanceadores de carga, entrada de cliente, endpoints de distribuição de software e possivelmente o próprio site ou superfícies de suporte do provedor. Uma falha de armazenamento pode afetar volumes e armazenamento de objetos. Um incidente de energia ou resfriamento pode afetar hipervisores e máquinas GPU. Uma escassez de suporte ou operações pode estender o tempo de restauração mesmo se o hardware for reparável.

Uma falha de contrato ou faturamento pode bloquear alterações, exportações ou dimensionamento urgente. O material público prova que a empresa é experiente nesses domínios; não prova que todos os caminhos de falha foram ensaiados.

Isso não é uma crítica exclusiva à CLOUD & HEAT. É a forma normal da dependência de nuvem regional. O provedor pode ser mais transparente, mais alinhado com código aberto e mais local do que uma plataforma de hiperescala, enquanto ainda está sujeito às mesmas restrições físicas: espaço, energia, resfriamento, óptica, peças de reposição, filtros de rota, janelas de manutenção e disponibilidade humana.

A localidade dos dados é um ponto forte, mas localidade não é recuperabilidade automática

A promessa mais forte voltada para o leitor da CLOUD & HEAT é localidade e soberania digital. A página de IaaS diz que a infraestrutura de nuvem pública é operada exclusivamente em data centers na Alemanha e que os dados são processados e armazenados em conformidade com o GDPR. A página de Kubernetes gerenciado diz que os dados do Kubernetes são processados e armazenados em data centers certificados ISO 27001 em conformidade com o GDPR na Alemanha. A página inicial diz que os clientes podem usar a infraestrutura da CLOUD & HEAT ou implantações on-premises.

As fontes SCS e OpenInfra enquadram a empresa em torno de padrões abertos, portabilidade e soberania digital.

Essas afirmações são importantes. Um cliente alemão ou europeu tentando evitar hospedagem offshore opaca tem um modelo de risco diferente quando a página de nuvem pública diz Alemanha, OpenStack e pilha de código aberto em vez de uma região global genérica. O material relacionado ao SCS é importante para a interoperabilidade. O artigo da empresa de 2024 diz que os padrões SCS visam aumentar a interoperabilidade e portabilidade de aplicações em nuvem. A notícia de certificação de 2026 diz que a Cloud&Heat recebeu o reconhecimento "Certified SCS-compatible IaaS". O perfil OpenInfra diz que a empresa contribui para padrões como SCS.

Tudo isso é relevante para o tópico de soberania e localidade de dados.

Mas a localidade não deve ser confundida com recuperação. Um cliente pode saber que os dados estão na Alemanha e ainda não saber se estão replicados entre Dresden e Leipzig, entre duas salas em Dresden, em duas zonas de disponibilidade em um edifício ou dentro de um cluster de armazenamento com domínios de falha. A página de Kubernetes gerenciado diz implantação em várias zonas de disponibilidade para alta disponibilidade, mas não define essas zonas publicamente.

A página de IaaS diz clusters Ceph triplamente redundantes e um pool NVMe triplamente replicado opcional dentro da capacidade disponível, mas não divulga se as réplicas são locais ao rack, locais à sala, locais ao edifício ou separadas por campus. As páginas públicas não mostram localização de backup ou histórico de restauração.

Isso é importante para clientes com obrigações de conformidade. Se uma carga de trabalho requer armazenamento alemão, as páginas públicas da CLOUD & HEAT suportam a afirmação inicial. Se a carga de trabalho requer um estado alemão específico, zona de energia, separação de zona de disponibilidade, segregação de backup, exportação com gap de ar ou plano de continuidade de setor regulado, as páginas públicas não são suficientes. O cliente deve solicitar uma declaração de localização de dados, subprocessadores, localização de backup, escopo de replicação de armazenamento, acesso de pessoal, janelas de manutenção e restauração testada.

Se a carga de trabalho usa Kubernetes gerenciado, o cliente também deve perguntar onde o plano de controle, etcd, volumes persistentes, registro de imagens, dados de monitoramento e logs residem.

O caminho de migração é mais claro por causa das escolhas tecnológicas. OpenStack, Kubernetes, volumes Cinder, armazenamento apoiado por Ceph, GitOps e compatibilidade SCS podem reduzir o lock-in se implementados com direitos de exportação e ferramentas testadas. Um cliente pode executar infraestrutura como código, manter backups externos, manter DNS sob seu próprio controle, conteinerizar aplicações e preparar um ambiente OpenStack ou Kubernetes de destino. Mas as páginas públicas não prometem que cada imagem, volume, snapshot, bucket de objeto, IP flutuante, balanceador de carga ou carga de trabalho GPU pode ser exportado rapidamente.

Tecnologias padrão tornam a migração possível; não a tornam automática.

A conclusão correta é, portanto, mista. A CLOUD & HEAT tem uma história de soberania crível porque combina hospedagem alemã, OpenStack, Kubernetes, trabalho SCS e interconexão local. A mesma história deve ser testada no limite do serviço: qual serviço é hospedado na Alemanha, qual parte é on-premises em um cliente, qual parte depende de IBH ou DD-IX, qual parte depende de DNS ou mail de terceiros, e qual parte pode se mover durante uma interrupção do provedor? Soberania não é apenas sobre país. É sobre controle durante o estresse.

Quem é afetado se cnh-primary falhar?

O primeiro grupo afetado são os clientes de nuvem pública e IaaS. A página de IaaS nomeia clientes incluindo Scalytics, tracetronic, Nyris, elevait, alphaspeech e flow.d. Ela vende recursos de computação, GPU e armazenamento e posiciona a nuvem para proteção de dados alemã e soberania digital. Se AS203592 ou o caminho de instalação relevante falhar, as máquinas virtuais do cliente podem permanecer ligadas, mas se tornar inacessíveis. Se a camada de armazenamento falhar, a disponibilidade de dados e a anexação de volume se tornam o problema.

Se a capacidade for esgotada, o cliente pode ser incapaz de escalar mesmo que as instâncias existentes continuem funcionando.

O segundo grupo são os clientes de Kubernetes gerenciado. A página de Kubernetes gerenciado nomeia N+P Informationssysteme GmbH e elevait GmbH & Co. KG. Ela descreve acesso à API via VPN, volumes persistentes OpenStack Cinder, balanceadores de carga, monitoramento, ingress, Certmanager e implantação multi-zona. Se a camada de nuvem do provedor falhar, o Kubernetes pode reagendar pods, mas ainda perder volumes, ingress ou acessibilidade externa. Se o plano de controle ou caminho VPN falhar, os desenvolvedores podem perder o acesso de gerenciamento.

Se a pilha de monitoramento fizer parte da oferta de serviço completo do provedor, a visibilidade de incidentes pode degradar junto com o próprio serviço.

O terceiro grupo são os clientes que usam a CLOUD & HEAT como parceiro de operações OpenStack em vez de como host. A página inicial cita a STACKIT dizendo que a Cloud&Heat suporta o desenvolvimento e a expansão da infraestrutura de nuvem com conhecimento de OpenStack. A página Patron vende distribuição OpenStack, instalação, comissionamento, operação, monitoramento, análise de falhas e atualizações. Uma falha em AS203592 pode não derrubar diretamente uma nuvem operada pelo cliente, mas uma interrupção de suporte ainda pode ser importante durante atualizações, incidentes ou mudanças de emergência.

Clientes de consultoria e operação gerenciada são afetados através da disponibilidade de pessoal, acesso remoto, documentação e escalonamento, não necessariamente através de rotas cnh-primary.

O quarto grupo são as redes regionais e participantes de tráfego local. A evidência do PeeringDB e DD-IX coloca AS203592 na DD-IX em Dresden. Um caminho de intercâmbio local pode melhorar a latência e resiliência regional quando funciona; também pode se tornar uma dependência se os clientes assumirem que o tráfego local permanecerá local. A própria DD-IX é um intercâmbio mais amplo com múltiplos participantes e instalações, então um problema da CLOUD & HEAT não é um problema da DD-IX por padrão.

Mas clientes usando serviços perto de Dresden devem monitorar tanto o status de AS203592 quanto da DD-IX porque o caminho de interconexão local é parte da história de desempenho.

O quinto grupo é a própria presença pública do provedor. O DNS colocouwww.cloudandheat.comdentro de 185.128.116.0/22. Se a mesma rede ou pilha de hospedagem suportar o site público da empresa, um incidente de infraestrutura pode tornar as páginas de produto e alguns pontos de entrada de cliente indisponíveis no momento em que os clientes precisam de informações. A evidência pública de DNS não prova que o sistema de tickets de suporte está na mesma pilha, e o registro SPF inclui Google, então o mail pode ter um caminho de dependência diferente. Ainda assim, as comunicações públicas devem fazer parte da due diligence do cliente: onde está a página de status, o que acontece se o site principal estiver indisponível e quais contatos de emergência permanecem acessíveis?

É por isso que a linguagem da região afetada deve ser conservadora. A atribuição marca a região como Global porque os serviços de nuvem e hospedados são acessíveis globalmente e a categoria do diretório é serviço de nuvem global. A região operacional mais forte em evidência pública é a Alemanha, especialmente Dresden e Saxônia, com uma conexão DD-IX documentada e afirmações de data center alemão. Clientes fora da Alemanha ainda podem usar os serviços, mas a dependência física não é global no sentido de hiperescala. É um provedor alemão de nuvem e tecnologia de nuvem com acessibilidade global.

A prova de redundância é boa na borda da rede e incompleta na camada de serviço

Existem vários sinais positivos de redundância. AS203592 tem quatro vizinhos observados no RIPEstat, não um. Tem visibilidade de roteamento público em todos os pares RIS observados para IPv4 e IPv6 no momento da consulta. Tem origens RPKI-válidas para todos os quatro prefixos observados. O PeeringDB mostra participação em servidor de rotas na DD-IX. A página de Kubernetes gerenciado promete implantação multi-zona de disponibilidade para alta disponibilidade. A página de IaaS menciona clusters Ceph triplamente redundantes e uma opção NVMe triplamente replicada.

A página Patron oferece contratos de operação e monitoramento, incluindo opções 24/7.

As lacunas são igualmente importantes. A visibilidade de roteamento público não divulga engenharia de tráfego. A porta DD-IX de 10 Gbps do PeeringDB não divulga utilização ou failover. A validade do RPKI não prova prontidão para mudança de rota. "Múltiplas zonas de disponibilidade" não define separação de raio de explosão. "Ceph triplamente redundante" não declara posicionamento de réplica. "Monitoramento 24/7" não revela pessoal de resposta, autoridade de escalonamento ou metas de restauração. Certificações ISO e status OpenStack Powered mostram postura de processo e tecnologia, mas não são registros de incidentes.

Um comprador não deve traduzir essas afirmações públicas em uma garantia geral de alta disponibilidade.

A prova prática de redundância mais forte que um comprador pode solicitar não é um folheto. É uma execução de recuperação testada: pegue uma VM representativa, volume, bucket de objeto, carga de trabalho Kubernetes e banco de dados; simule uma falha de zona; meça o tempo de restauração; teste a mudança de DNS; exporte imagens e volumes; reconstrua em um segundo provedor ou site do cliente; e verifique a consistência em nível de aplicação. Para Kubernetes, pergunte como etcd, volumes persistentes, controladores de ingress, balanceadores de carga e dependências de registro se recuperam.

Para OpenStack, pergunte como Nova, Neutron, Cinder, Glance, Keystone, Ceph e DNS externo se comportam quando um nó de armazenamento, hipervisor, roteador ou link de instalação falha.

A prova de migração também deve ser específica do produto. Um cliente de IaaS precisa de exportação de imagem, snapshot/exportação de volume, transferência de dados de objeto, planejamento de mudança de endereço e liberação de cota. Um cliente de Kubernetes precisa de manifestos, Helm charts, repositórios GitOps, tratamento de segredos, migração de volume persistente e backup externo. Um cliente de GPU precisa de disponibilidade de hardware alternativo e compatibilidade de driver. Um cliente Patron on-premises precisa de documentação, runbooks, caminhos de atualização e direitos de continuar operando se o suporte mudar.

Esses são testes diferentes, e as páginas públicas não respondem a todos eles.

A empresa é ajudada por suas escolhas de código aberto. OpenStack e Kubernetes reduzem algum lock-in em comparação com plataformas apenas proprietárias. A compatibilidade SCS é projetada para aumentar a interoperabilidade e portabilidade. Yaook e Tarook apontam para gerenciamento automatizado de ciclo de vida. Mas o valor dos padrões abertos aparece apenas se o cliente controlar sua configuração, backups, credenciais e instruções de construção. Código aberto não é um substituto para planejamento de saída. É a base para um melhor plano de saída.

A nota final de dependência

cnh-primary CLOUD & HEAT Technologies GmbH deve ser atualizado da suspeita inicial de "pegada fina". A evidência pública não é fina. AS203592 está ativo. O RIPE mostra anúncios atuais, origens válidas e recursos de número alemão. O PeeringDB mostra uma instalação em Dresden e conexão DD-IX. O site da empresa vende IaaS e Kubernetes gerenciado com detalhes técnicos significativos. Fontes OpenStack e OpenInfra corroboram o papel da empresa em infraestrutura de nuvem aberta. Fontes relacionadas ao SCS suportam a história de soberania e interoperabilidade. Referências de clientes são visíveis.

O rebaixamento não é sobre existência. É sobre prova de resiliência. A evidência pública não divulga computação total instalada, estoque de GPU, capacidade bruta de armazenamento, contagem de inquilinos, design por zona, contagem de racks, termos de contrato de instalação, topologia de energia, procedimentos de mão remota, localização de backup, histórico de restauração, histórico de incidentes, pessoal exato de suporte ou saídas de cliente testadas. A linguagem "dentro das capacidades disponíveis" na página de IaaS é um lembrete útil de que a capacidade utilizável é finita.

Um comprador deve tratar cada frase de capacidade pública como um convite para verificar estoque, cotas e caminhos de recuperação.

O grau mais útil é dividido. Identidade de rede e evidência de rota: Forte. Evidência de produto e cliente: Forte. Evidência de instalação e interconexão local: Médio-forte, porque Dresden e DD-IX são visíveis, mas toda a pegada de nuvem não está mapeada publicamente. Evidência de resiliência de capacidade hospedada: Médio, porque as páginas públicas fazem afirmações concretas de disponibilidade, suporte e armazenamento, mas param aquém de prova concreta. Evidência de migração: Médio, ajudado por OpenStack, Kubernetes e SCS, mas dependente de termos contratuais e preparação do cliente.

O teste prático é se um cliente pode transformar esses pontos fortes públicos em controle operacional. Um comprador que trata a Cloud&Heat como um provedor estratégico de nuvem alemão deve solicitar uma declaração de capacidade atual, não apenas um catálogo de serviços: CPU, memória, GPU, armazenamento em bloco, armazenamento de objeto, armazenamento de backup e cota de rede por site ou zona de disponibilidade.

Deve perguntar se uma nova máquina virtual pode ser provisionada durante um evento de armazenamento parcial, se um cluster Kubernetes pode ser reconstruído sem segredos retidos pelo provedor, se IPs flutuantes podem ser reatribuídos durante a manutenção do roteador, se dados de objeto podem ser exportados sem limitação e se o suporte pode executar mudanças de emergência quando o site público ou um caminho de peering está prejudicado. Essas são perguntas comuns para capacidade hospedada séria. Elas não enfraquecem a história da empresa; elas tornam a forte evidência pública utilizável.

Para monitoramento, acompanhe AS203592, 185.128.116.0/22, 94.198.185.0/24, 2a0c:2c0::/29, 2a0c:2c0:dd80::/44, a porta DD-IX, o site cloudandheat.com e caminhos públicos de status ou suporte. Para aquisição, solicite declarações de instalação, definições de zona de disponibilidade, evidência de diversidade de rota, termos de resposta de suporte, provas de backup e exportação e um plano de migração testado. A empresa tem infraestrutura crível.

O ponto de decisão é se o serviço específico que um cliente compra tem capacidade utilizável suficiente e recuperação ensaiada suficiente para sobreviver às falhas físicas que toda capacidade hospedada eventualmente enfrenta.