TEMPLE Cloud Temple SAS vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A TEMPLE Cloud Temple SAS mapeia para um negócio de nuvem soberana francês visível: as páginas públicas da Cloud Temple descrevem IaaS qualificado SecNumCloud, VMware IaaS, OpenSource IaaS, armazenamento de objetos, bare metal, VPC, backbone privado, hospedagem e serviços de suporte para setores regulados.
• As páginas oficiais de conformidade afirmam que o escopo do IaaS Secure Temple cobre VMware IaaS, OpenSource IaaS, S3 Object Storage, criptografia HSM-KMS e Bare Metal, com validade SecNumCloud v3.2 listada até 30 de maio de 2028; a mesma página lista PaaS OpenShift separadamente.
• O roteamento público é real e atual: o RIPEstat mostrou a AS33930 anunciada em 12 de julho de 2026, com seis prefixos IPv4 e dois prefixos IPv6, resultados completos de origem válida RPKI na visão verificada e ampla visibilidade RIS.
• O risco não é que o provedor falte evidências operacionais públicas; o risco é que a certificação, a visibilidade AS e os rótulos de produtos ainda não digam exatamente qual rack, zona de disponibilidade, caminho de recuperação, nível de suporte ou processo de saída protege uma carga de trabalho específica.
• Os compradores devem tratar as evidências públicas da Cloud Temple como um ponto de partida forte para due diligence e, em seguida, verificar o posicionamento da carga de trabalho, escalonamento de suporte, disponibilidade de hardware, testes de restauração, responsabilidade do circuito do cliente, efeitos de faturamento e limites de portabilidade de dados antes de mover sistemas críticos.

A TEMPLE Cloud Temple SAS é o tipo de empresa de nuvem que pode parecer simples a partir de um cartão de diretório e complicada assim que um cliente pergunta o que realmente precisa funcionar. O nome aponta para um provedor de nuvem soberana com escritórios franceses visíveis, alegações de conformidade, um sistema autônomo roteado, uma oferta de suporte público, uma página de status oficial e documentos técnicos que descrevem computação, armazenamento, rede, hospedagem física e limites de responsabilidade. Isso é suficiente para rejeitar uma leitura de status operacional fraco.

Não é suficiente para tratar todas as alegações de disponibilidade ou soberania como autoexecutáveis. A empresa vende capacidade hospedada, mas a capacidade ainda depende de espaço físico real, energia, cabeamento, seleção de rota, plataformas de fornecedores, mão de obra de suporte, configuração do cliente, teste de restauração e termos contratuais.

A própria página“Quem somos?”da empresa posiciona a Cloud Temple em torno de setores sensíveis, nomeando indústria, finanças, saúde e setor público como os mercados onde sua promessa é importante. Suapágina de localizaçõeslista escritórios em Paris / La Defense, Lyon, Tours, Caen e Nantes, com o endereço de Paris / La Defense no Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. Isso é uma evidência de identidade útil, mas o mapa de escritórios não é o mapa de infraestrutura. Um comprador não deve confundir um endereço de escritório com o local onde uma máquina virtual, blade bare metal, bucket S3, gateway VPC ou rack físico está em execução.

A evidência pública mais forte é a conformidade e o portfólio de produtos. Apágina de procedimentos de conformidadeda Cloud Temple diz que a empresa tem certificação ISO 27001 para infraestrutura desde 2018 e para serviços gerenciados desde 2022, certificação HDS para atividades de dados de saúde, qualificação SecNumCloud v3.2, relatórios ISAE 3402 e outras entradas de conformidade europeias. A mesma página fornece a declaração de escopo mais concreta: “IaaS Secure Temple” está listado sob SecNumCloud v3.2 com validade até 30 de maio de 2028, e a nota de rodapé diz que esse escopo inclui VMware IaaS, OpenSource IaaS, S3 Object Storage, criptografia HSM-KMS e Bare Metal. Isso não torna todos os produtos idênticos, mas coloca os principais produtos de infraestrutura dentro de um perímetro de qualificação pública.

Apágina de abordagem SecNumCloudda Cloud Temple faz a proposta estratégica: a nuvem deve proteger a confiança de empresas e órgãos públicos, e o design do produto deve estar alinhado com os exigentes padrões europeus de segurança. A página também diz que a qualificação significa conformidade com mais de 700 requisitos ANSSI e melhores práticas nas áreas técnicas, físicas, contratuais e operacionais. Essa declaração é importante para o risco de infraestrutura porque é explicitamente mais ampla do que controles cibernéticos. É sobre como um provedor é gerenciado. No entanto, mesmo uma qualificação ampla não é um documento de arquitetura por cliente. Ela não diz a um hospital, seguradora, agência pública ou cliente industrial se seu próprio inquilino tem dois hosts de computação, qual zona de disponibilidade mantém a cópia passiva, ou se sua alteração de firewall é coberta pelo nível de suporte em vigor.

A linha de produtos mostra por que esses detalhes são importantes. A oferta de computação da Cloud Temple abrange vários padrões de consumo. O site público descreveOpenSource IaaSpara infraestrutura virtualizada em uma plataforma soberana,VMware IaaSpara ambientes VMware em um ambiente de nuvem qualificado,Bare Metalpara servidores físicos dedicados e instâncias VM em preview para máquinas virtuais mais compartilhadas no estilo nuvem. Os documentos públicos da empresa para OpenSource IaaS descrevem computação Cisco UCS, armazenamento em bloco IBM Spectrum Virtualize e IBM FlashSystem, armazenamento de objetos Dell ECS, rede Juniper, blades de computação dedicados e volumes de armazenamento, precificação de consumo mensal, conceitos de região e zona de disponibilidade, backups, opções de replicação e operação via API ou Terraform. Isso não é um catálogo de hospedagem leve. É uma pilha física e operacional.

A pilha tem uma implicação específica: capacidade instalada e capacidade utilizável não são a mesma coisa. Uma página pode mostrar classes de blade, classes de armazenamento e números de conectividade, enquanto um cliente ainda tem que perguntar se a classe exata está disponível na região desejada, se adicionar outro host requer estoque de hardware, se um blade GPU tem um prazo de entrega, se a segunda zona de disponibilidade tem desempenho de armazenamento correspondente e se o licenciamento do cliente permite failover ao vivo.

Os conceitos do OpenSource IaaS da Cloud Temple listam classes de blade de ECO a PERFORMANCE 4, com memória, contagens de núcleo, conectividade de 10 Gbit/s ou 25 Gbit/s e, para a classe superior, GPUs NVIDIA L40S a partir de 1º de maio de 2024. Esse é um detalhe útil. Também diz a um comprador que a capacidade não é abstrata: é entregue por famílias de hardware específicas com inventário finito.

O Bare Metal reforça o ponto. Adocumentação do Bare Metaldescreve servidores físicos dedicados conectados a armazenamento em bloco distribuído, blades Cisco UCS, armazenamento IBM Spectrum Virtualize, posicionamento em zona de disponibilidade, acesso ao console no estilo KVM, mapeamento ISO, operações de energia, marcação VLAN e duas interfaces de rede cuja velocidade depende da classe do blade. O produto é atraente precisamente porque dá aos clientes mais controle sobre o ambiente operacional. Mas esse controle empurra parte do risco de volta para o cliente. Se um cliente instala seu próprio hipervisor ou sistema operacional, a Cloud Temple pode fornecer o blade, o armazenamento e o acesso à plataforma, mas o cliente ainda possui as escolhas que transformam hardware em um aplicativo resiliente.

O lado VMware tem uma tensão semelhante. O material do VMware IaaS da Cloud Temple descreve recursos dedicados de blade, armazenamento e rede, compatibilidade com vSphere, VLANs L2, propagação entre zonas de disponibilidade, latência intra-AZ abaixo de 3 ms e latência inter-AZ abaixo de 5 ms na visão documentada, e alta disponibilidade que só funciona se um cluster tiver o design de host necessário. Os documentos públicos observam que, se uma zona de disponibilidade contiver apenas um hipervisor, a reinicialização automática em outro hipervisor não é possível.

Esse é o tipo de frase que transforma uma promessa de nuvem em realidade de engenharia. Um cliente pode comprar infraestrutura de um provedor qualificado e ainda construir um ambiente de host único frágil se escolher a forma errada ou adiar o segundo nó.

O armazenamento também precisa de precisão. Apágina de armazenamento de objetospública da Cloud Temple diz que o serviço é baseado no Dell Elastic Cloud Storage, oferece alta compatibilidade com S3, é qualificado SecNumCloud, certificado HDS e ISO 27001, replica automaticamente em três zonas de disponibilidade, usa codificação de apagamento EC 12+4, suporta TLS 1.2/1.3 além de opções de criptografia no lado do servidor, lista disponibilidade de 99,99% e durabilidade de 99,999999999%, e anuncia sem taxas de saída. Essas são alegações sérias para compradores de backup, arquivo e armazenamento de aplicativos. Elas ainda precisam ser mapeadas para o dever do cliente de definir ciclo de vida, imutabilidade, chave e política de restauração. O armazenamento de objetos em três zonas ajuda na durabilidade da plataforma; não prova por si só que um cliente pode restaurar a versão correta do objeto após ransomware, exclusão acidental, design de retenção ruim ou comprometimento de chave de acesso.

A divisão de responsabilidades não está oculta. Apágina de responsabilidade compartilhadada Cloud Temple aponta os leitores para matrizes RACI para IaaS, instâncias VM, armazenamento de objetos, rede e outros serviços. Amatriz de responsabilidade IaaSdiz que a Cloud Temple é responsável e accountable por implementar data centers físicos, infraestrutura de computação, infraestrutura de armazenamento, conectividade de backbone, licenças de software de plataforma essenciais, configuração de inquilino de linha de base e configuração inicial de backup. Também diz que o cliente é responsável e accountable por definir a arquitetura geral, contagem de inquilinos, contagem de zonas de disponibilidade, estratégia de continuidade e recuperação, dimensionamento para computação, armazenamento, rede e backup, criação e manutenção de máquinas virtuais, associação de cada VM com planos de backup e recuperação coerentes, e realização de testes periódicos de backup e recuperação.

Essa divisão é provavelmente o fato mais importante de todo o registro. Significa que a empresa pode ser um provedor de infraestrutura qualificado enquanto ainda deixa decisões críticas de design com o cliente. Se o cliente subdimensionar um inquilino, omitir testes de backup, não distribuir cargas de trabalho entre zonas, manter uma regra de firewall quebrada, perder acesso de administrador ou manter um único nó de aplicativo dentro de uma plataforma resiliente, a falha não se comportará como uma simples interrupção do provedor. Será uma falha conjunta de arquitetura com apenas algumas camadas cobertas pelos compromissos do provedor.

A pergunta de risco do artigo não é, portanto, “A TEMPLE Cloud Temple SAS é uma empresa de nuvem real?” A resposta é sim. A pergunta é “Qual parte deste sistema do cliente está dentro do perímetro de responsabilidade da Cloud Temple e qual parte ainda é do design do próprio cliente?”

A mesma divisão aparece na rede. Adocumentação do Private Backboneda Cloud Temple diz que o produto fornece redes privadas L2 VPLS entre zonas de disponibilidade, componentes de acesso à Internet privados, endereçamento IP, proteção anti-DDoS nativa, portas para conectividade externa, circuitos 1G/10G e links privados em dois caminhos ópticos diversificados para produtos de circuito dedicado. Apágina de conceitos de Internetdiz que a Cloud Temple opera seu próprio AS, oferece dois caminhos de trânsito e dois pontos de troca em Paris, suporta BGP4, fornece IPv4 público por unidade e prefixos IPv6, reserva largura de banda de Internet em incrementos de 100 Mbit/s e cobra com base no percentil 95 em vez de volume de saída. Esses são fatos materiais de design de rede, não alegações decorativas.

Mas, novamente, o limite é importante. Amatriz de responsabilidade de redediz que o cliente é responsável e accountable por assinar a conectividade da operadora para acessar um data center físico da Cloud Temple e por gerenciar incidentes, problemas e capacidade nos links da própria operadora do cliente. A Cloud Temple assume a responsabilidade pelo backbone, pontos de coleta e pontos de interconexão do data center, e para hospedagem física, a responsabilidade começa no equipamento no topo do rack. Esse limite é exatamente onde muitos incidentes se tornam dolorosos. Uma carga de trabalho pode estar saudável dentro da Cloud Temple, mas um site cliente ainda pode falhar através de um link MPLS empresarial, um circuito de acesso da operadora, uma alteração IPsec ruim, um firewall local, um erro de DNS ou um limite de capacidade do lado do cliente.

As evidências públicas de roteamento apoiam a ideia de que a empresa opera uma rede real. O RDAP do RIPE paraAS33930nomeia CLOUD-TEMPLE e lista a Cloud Temple SAS como entidade registrante, com o endereço da organização no Le Belvedere, 1 Cours Valmy, 92800 Puteaux. Avisão geral do ASdo RIPEstat identificou o titular como CLOUD-TEMPLE Cloud Temple SAS e mostrou o AS como anunciado no momento da consulta em 12 de julho de 2026. Avisão de prefixos anunciadosdo RIPEstat mostrou oito anúncios ativos na janela que terminou em 12 de julho de 2026: 91.223.207.0/24, 45.15.212.0/22, 185.56.204.0/22, 194.6.240.0/24, 93.187.40.0/21, 80.75.152.0/21, 2a02:668::/36 e 2a02:668:9000::/36.

Esse registro de roteamento é mais forte do que uma pegada apenas de marketing. Avisão de status de roteamentodo RIPEstat mostrou seis prefixos IPv4, dois prefixos IPv6, 6.656 endereços IPv4 anunciados, 8.192 /48s IPv6, 54 vizinhos observados e visibilidade RIS quase completa no instantâneo verificado. A visão de consistência de roteamento do RIPEstat mostrou os prefixos anunciados AS33930 presentes tanto no BGP quanto nas fontes de política de rota do RIPE, sem lista de prefixos inconsistentes na saída verificada. A validação RPKI retornou “válido” para os oito pares de prefixo-origem AS33930 verificados. Esses fatos não dizem a um cliente quão redundante é um serviço específico, mas mostram que a camada de rede é visível, mantida e não meramente resíduo legado.

As evidências de trânsito e peering também são úteis, embora devam ser lidas com cuidado. Os comentários do RDAP do RIPE para AS33930 mencionam solicitações de peering, detalhes de troca France-IX e Equinix Paris. Apágina da rede Cloud Templeno PeeringDB lista a rede como Cloud Temple, com o antigo nome aka Intrinsec da Cloud Temple, uma política de peering geral aberta e uma data de atualização em abril de 2025. A visão de troca pública do PeeringDB mostra entradas France-IX Paris e Equinix Paris IX a 10 Gbit/s, enquanto sua visão de instalações lista Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 e DATA4 Paris Marcoussis - PAR1 como instalações associadas ao perfil de rede. Isso corrobora a interconexão no mercado de Paris, mas ainda é um perfil público de peering, não um mapa vinculante do posicionamento da carga de trabalho do cliente.

A página de status pública adiciona outro ângulo. Apágina de statusda Cloud Temple expõe componentes sob FR1, incluindo rótulos de AZ como PA6, PAR7, TH3, PAR7S, TH3S e AZ07, junto com categorias para OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, serviços de borda e interfaces públicas. Uma página de status é valiosa porque dá aos clientes um local público para observar incidentes e manutenção. Ela não responde à pergunta mais profunda por si só: quais dessas zonas de disponibilidade, serviços e componentes o cliente realmente usa, e o aplicativo do próprio cliente sobrevive se um deles estiver degradado?

Os caminhos de falha ficam mais claros quando a linha de produtos é lida como um sistema. Uma falha de rack ou instalação afeta computação, armazenamento, rede e hospedagem de forma diferente, dependendo do posicionamento. Uma falha de upstream ou rota afeta serviços voltados para a Internet, prefixos do cliente, acesso VPN e visibilidade de suporte de forma diferente, dependendo do design BGP. Uma falha de estoque de hardware é importante para bare metal, blades GPU, expansão de armazenamento, appliances de firewall e hosts de reposição. Uma falha de suporte é diferente nos níveis Standard, Premium e Company.

Uma falha de faturamento ou pedido pode atrasar o provisionamento ou a expansão. Uma falha de migração pode deixar cargas de trabalho presas mesmo quando a plataforma está saudável. Nenhum desses riscos significa que o provedor é fraco. Eles significam que o contrato de nuvem precisa ser lido como infraestrutura, não como uma abstração mágica.

Os termos de suporte fazem parte dessa infraestrutura. Apágina de níveis de suporteda Cloud Temple lista suporte Standard, Premium e Company com taxas mensais de 5, 7 e 10% da fatura do serviço, níveis mínimos de faturamento mensal, diferentes acessos ao Technical Account Manager, metas de resposta P1 de 2 horas, 30 minutos e 15 minutos, e monitoramento e intervenção 24/7 para incidentes de nuvem. Também diz que os engenheiros estão disponíveis 24/7 para incidentes de nuvem, enquanto as solicitações de suporte têm canais de horário comercial, com suporte baseado na França em francês e inglês. A diferença é importante. Um incidente de produção pelo qual a Cloud Temple é responsável não é o mesmo que uma solicitação de assistência geral, uma alteração de configuração do lado do cliente, uma pergunta de planejamento de migração ou uma solicitação de tarefa fora do catálogo.

A página de suporte também aponta de volta para a matriz de responsabilidade para incidentes com impacto na produção pelos quais a Cloud Temple é responsável. Essa qualificação não é letra miúda na prática. Se a VM de um cliente está ativa na camada do hipervisor, mas o aplicativo está inativo porque o sistema operacional convidado está quebrado, o caminho de suporte muda. Se o VPC de um cliente está saudável, mas o circuito da operadora no local está inativo, o caminho de suporte muda. Se um backup existe, mas o cliente nunca executou testes de restauração, o caminho de suporte muda.

Um bom suporte pode ajudar em todos esses casos, mas o limite contratual e o nível pago decidem velocidade, canal e responsabilidade.

Os documentos de SLA publicados fazem o mesmo ponto com números. OSLA de instâncias VMdefine um compromisso de disponibilidade mensal de 99,95% para cada instância VM faturada ativa, equivalente a 21,9 minutos de indisponibilidade mensal permitida. Mas mede a indisponibilidade na camada de infraestrutura subjacente da Cloud Temple, exclui SO convidado, software do cliente, configuração de rede do cliente, falhas de aplicativo, manutenção programada, componentes de gerenciamento ausentes, comportamento abusivo e força maior, e requer um ticket de suporte dentro de 30 dias corridos para solicitar créditos de serviço. Essa é uma estrutura de nuvem normal. Também é um aviso: o SLA não é uma garantia de disponibilidade do aplicativo.

OSLA de VPCé igualmente específico. Ele dá disponibilidade mensal de 99,99% para o plano de dados do VPC e 99,9% para o plano de controle, com cinco minutos como limite de indisponibilidade contada. Ele cobre componentes do VPC gerenciados pela Cloud Temple, como roteador, redes privadas, gateway externo, NAT, DNAT e IPs flutuantes. Exclui regras de filtragem do cliente, endereçamento incorreto, falhas de computação conectada, conectividade externa com a Internet além da demarcação da Cloud Temple, manutenção programada, comportamento abusivo e força maior. Essas exclusões não são falhas no documento; elas são como o limite operacional real é desenhado.

O armazenamento de objetos tem um perfil de saída e recuperação diferente. A página pública do produto diz que os clientes podem recuperar objetos por meio de acesso compatível com S3 e que a Cloud Temple não cobra taxas de saída. Amatriz de responsabilidade S3diz que a Cloud Temple é responsável por manter e proteger a plataforma S3, acesso ao serviço, logs, monitoramento, incidentes, problemas, capacidade e mudanças de serviço. Diz que o cliente é responsável por criar objetos, criar chaves de acesso, gerenciar o ciclo de vida dos objetos, gerenciar direitos dos objetos, gerenciar segurança lógica, backups dos dados, testes periódicos de restauração, planos de continuidade do aplicativo e execução de reversibilidade. Isso significa que nenhuma taxa de saída é útil, mas a portabilidade ainda requer planejamento do cliente, credenciais, largura de banda, lógica de retenção e um destino testado.

A migração é onde a capacidade hospedada frequentemente revela seu verdadeiro custo. Os produtos da Cloud Temple são explicitamente compatíveis com ecossistemas familiares: ambientes VMware, acesso S3, OpenSource IaaS no estilo OpenStack, operação baseada em API, provisionamento baseado em Terraform e BGP para prefixos do cliente. Esses são sinais de interoperabilidade. Eles reduzem o lock-in em comparação com uma pilha proprietária fechada.

No entanto, uma saída da plataforma ainda é um projeto: imagens de servidor, volumes de armazenamento, buckets de objetos, regras de firewall, direitos de acesso, roteamento, chaves, DNS, monitoramento, acordos de suporte e janelas de reversão precisam estar alinhados. O RACI de IaaS diz que o cliente é responsável por planejar a reversibilidade, escolher a infraestrutura de destino, executar operações de transição e gerenciar os efeitos na qualidade do serviço durante a transferência, enquanto a Cloud Temple lida com a desmontagem de configurações e apagamento seguro após o término do contrato.

Faturamento e pedidos não são questões secundárias. A página de suporte diz que o faturamento mínimo de suporte começa quando os recursos são provisionados. Os documentos de rede dizem que os endereços IPv4 públicos são entregues dentro do estoque disponível, a largura de banda da Internet é reservada em incrementos de 100 Mbit/s, circuitos privados podem ter compromissos de 36 meses, e serviços de hospedagem dedicada ou mãos e olhos podem ter prazos de 12 ou 36 meses, dependendo do item. O preço do armazenamento de objetos é orientado ao uso, enquanto o bare metal e a hospedagem estão vinculados a unidades físicas.

Essa mistura afeta a resiliência. Em uma emergência, um cliente pode descobrir que a ação de emergência não é apenas um comando técnico; pode ser um novo pedido, uma solicitação de suporte, um orçamento de circuito, uma entrega dependente de estoque ou uma alteração contratual.

Os canais de aquisição adicionam outra camada operacional. As páginas de IaaS e Bare Metal da Cloud Temple apontam compradores do setor público e de saúde para rotas de compra pública como UGAP e CAIH. Isso é importante porque pode tornar o provedor mais fácil de adotar para organizações que não podem comprar infraestrutura por meio de negociação ad hoc. Também significa que o planejamento de resiliência pode ser moldado por termos de estrutura, entradas de catálogo pré-aprovadas, formulários de pedido, compromissos mínimos e prazos de aquisição pública.

Um comprador público pode conseguir pedir um serviço qualificado de forma mais limpa, mas ainda precisa saber se uma expansão de capacidade posterior, circuito urgente, alteração de suporte premium ou solicitação de assistência à migração se encaixa no mesmo caminho de compra.

Esta é uma razão pela qual a economia da capacidade hospedada não deve ser reduzida a um preço unitário mensal. Um cliente que se muda de sua própria sala de servidores para a TEMPLE Cloud Temple SAS está transferindo custo de capital, ônus de pessoal e risco de instalação para um provedor com infraestrutura especializada. Isso pode ser racional, especialmente para clientes regulados que não podem construir controles de nível SecNumCloud sozinhos.

Mas o cliente também está aceitando uma nova forma de custo: largura de banda reservada, percentuais de nível de suporte, consumo de armazenamento, endereços IP, circuitos privados, tempo de mãos e olhos, assistência profissional, termos de hospedagem física e largura de banda de saída. A conta de nuvem não é apenas computação e armazenamento. É também o preço das escolhas feitas antes de uma falha.

A alegação de sem taxa de saída no armazenamento de objetos é um bom exemplo de um termo amigável ao comprador cujo significado operacional depende do contexto. Se um cliente pode recuperar todos os objetos por meio de acesso compatível com S3 sem cobranças de saída, a barreira comercial para saída é menor do que em muitos arranjos de hiperescala. Mas mover muitos terabytes ou petabytes ainda consome tempo, largura de banda, controle de chave de acesso, capacidade de destino, disciplina de nomenclatura de objetos e consciência de política de retenção.

Se o Entidade Lock estiver habilitado, um cliente também precisa respeitar suas próprias escolhas de imutabilidade. A ausência de uma taxa de saída não elimina a necessidade de uma janela de migração, um design de destino e um processo de cópia verificado.

A página de status pública deve ser usada da mesma forma prática. Ela é valiosa porque nomeia componentes que os clientes podem monitorar durante um incidente e sinaliza que a Cloud Temple tornou parte de seu estado operacional visível. No entanto, um componente de status só é útil se o cliente souber como ele mapeia para seu serviço. Se um cliente vir um item para FR1 Object Storage ou um rótulo específico de zona de disponibilidade, ele pode dizer se seu bucket, inquilino, gateway VPC ou blade bare metal está afetado? A ponte de incidentes do próprio cliente inclui alguém que entende esses rótulos?

O nível de suporte prometeu um canal de comunicação para a gravidade em questão? A visibilidade ajuda apenas quando está conectada ao runbook e aos registros de propriedade do cliente.

Há também uma dependência silenciosa na própria borda pública do provedor. Uma consulta DNS pontual observou cloud-temple.com no espaço de endereços da Cloud Temple, servidores de nomes Gandi, proteção de e-mail Microsoft, o console em outro endereço da Cloud Temple e o hostname de status por meio do Atlassian Statuspage e CloudFront. Essas são escolhas normais e não enfraquecem as evidências centrais da plataforma. Elas mostram, no entanto, que a comunicação com o cliente pode depender de camadas além da AS33930.

Em um incidente grave, o site do provedor, console, página de status, caminho de e-mail, suporte telefônico e inquilino do cliente podem falhar ou sobreviver em combinações diferentes. Os clientes devem manter mais de um canal de escalonamento e não devem esperar até uma interrupção para testá-los.

A categoria global atribuída a este artigo também precisa de nuance. Os serviços em nuvem podem ser comprados e alcançados globalmente, e a AS33930 tem visibilidade de roteamento mundial. Mas a história de soberania pública da Cloud Temple é principalmente francesa e europeia, com linguagem de produto FR1, escritórios franceses, equipes de suporte francesas, qualificação ANSSI, relevância HDS, peering em Paris e sinais de mercado de instalações francesas. Para um cliente fora da França, a dependência ainda pode ser atraente se o objetivo for a localidade de dados francesa ou europeia.

Também significa que latência, circuitos de acesso do cliente, expectativas legais e horas de suporte operacional devem ser avaliados em relação à base real de usuários. Uma população global de usuários atendida por uma nuvem soberana francesa pode precisar de cache adicional, design de acesso regional ou tolerância em nível de aplicativo.

A soberania também pode criar uma falsa sensação de completude se o cliente a tratar como um substituto para a arquitetura. Um provedor francês qualificado pode reduzir a exposição a certas preocupações legais, operacionais e de segurança, mas não pode decidir a classificação de dados do cliente, failover de rota, clustering de aplicativos, direitos de inquilino, rotação de chaves, frequência de restauração ou prioridade de saída. A documentação pública da Cloud Temple é excepcionalmente clara de que muitos desses itens permanecem com o cliente. Essa clareza é uma boa notícia.

Dá aos compradores a chance de tornar a divisão explícita antes da produção. O risco é que um comprador leia o título do certificado e ignore a tabela de responsabilidades.

A pergunta de aquisição mais limpa é, portanto, uma tabela de demarcações, não uma pergunta de confiança sim ou não. Para cada carga de trabalho, o cliente deve anotar o serviço de computação, serviço de armazenamento, serviço de rede, zonas de disponibilidade, destino de backup, proprietário da restauração, nível de suporte, circuito do cliente, prefixo público, administrador de identidade, proprietário da chave, proprietário do faturamento, contato de manutenção e destino de saída.

Em seguida, deve perguntar à TEMPLE Cloud Temple SAS quais itens são operados pelo provedor, quais são operados pelo cliente, quais estão no escopo SecNumCloud, quais são relevantes para HDS, quais estão fora das áreas qualificadas, quais estão em preview e quais precisam de assistência profissional separada. Esse exercício é mundano, mas é onde a resiliência da nuvem se torna visível.

A hospedagem física é o lembrete mais concreto de que a nuvem tem bordas. Adocumentação de Hospedagemda Cloud Temple descreve hospedagem física por unidade de rack em racks compartilhados ou por rack dedicado de 42U, duas cadeias elétricas para racks compartilhados, limites de energia por U, unidades de 2U orientadas a servidor com energia C19, racks dedicados com 3 kW em duas cadeias elétricas de 16A, incrementos extras de 2 kW, uma massa máxima de equipamento de 1.000 kg, PDUs monitorados, portas de rede de cobre ou fibra, conectividade de sala de meet-me e serviços de mãos e olhos. Também diz que os racks dedicados estão em espaço de hospedagem compartilhado fora da área SecNumCloud. Essa última distinção é importante: “hospedagem Cloud Temple” e “IaaS Secure Temple qualificado” não são frases intercambiáveis.

Para alguns clientes, a hospedagem é uma ponte. Um appliance legado, sistema adjunto ao mainframe, caixa de armazenamento proprietária, HSM, firewall ou servidor de preparação de migração pode precisar ficar perto dos recursos da nuvem enquanto uma carga de trabalho regulada se move. Isso pode ser sensato. Também pode criar uma arquitetura de dois perímetros: parte nuvem qualificada, parte hospedagem física não qualificada, parte equipamento de propriedade do cliente, parte rede gerenciada pela Cloud Temple, parte circuito da operadora.

Se o cliente assumir que tudo tem a mesma qualificação, resposta de suporte e mecânica de recuperação, o design pode se tornar enganoso. Os documentos de hospedagem são úteis precisamente porque forçam o comprador a falar sobre unidades de rack, watts, portas, caminhos ópticos, resposta de mãos e olhos e escalonamento de suporte.

O argumento de soberania de dados é, portanto, mais forte quando mantido concreto. As páginas da Cloud Temple fazem uma alegação de soberania credível em torno da operação francesa, qualificação SecNumCloud, HDS, ISO 27001, equipes de suporte na França e produtos projetados para setores regulados. A página de armazenamento de objetos enfatiza as necessidades regulatórias francesas e europeias. A página de suporte diz que as equipes de suporte estão baseadas na França e operam a partir da França. A página de conformidade lista datas oficiais de validade e escopos. Mas a soberania não é apenas um rótulo nacional.

É também posicionamento, acesso ao suporte, evidências de subcontratados, custódia de chaves, comunicação de incidentes, rota de exportação, prova de exclusão e divulgação de risco residual. Um cliente deve perguntar onde cada cópia de dados, backup, fluxo de log, artefato de suporte e intervenção de suporte está localizada.

A pegada de rede pública dá uma lição semelhante. A AS33930 tem prefixos visíveis, autorização de origem de rota válida na visão verificada, participação em exchanges e listagens de instalações. Isso é melhor do que ver apenas um front-end de revendedor na rede de outra pessoa. Significa que a Cloud Temple tem superfície de roteamento direta e uma história de interconexão pública.

Ainda assim, as evidências de roteamento não revelam qual inquilino do cliente usa qual prefixo, como a mitigação de DDoS é direcionada durante um ataque, se todos os caminhos estão igualmente disponíveis durante a manutenção, quais preferências de rota se aplicam a prefixos de propriedade do cliente ou quão rapidamente um cliente pode mover a identidade IP para fora da plataforma. Um registro BGP forte é necessário para algumas cargas de trabalho, não suficiente para todas.

Os clientes mais afetados são aqueles que a própria Cloud Temple visa: órgãos do setor público, provedores de saúde, empresas financeiras, operadores industriais, editores de software e outras organizações que precisam de garantia de conformidade e continuidade operacional. Nesses ambientes, uma interrupção de nuvem raramente é apenas um inconveniente. Pode atrasar o atendimento, congelar relatórios regulados, paralisar sistemas adjacentes à fábrica, bloquear serviços ao cidadão, interromper o acesso à identidade ou impedir um editor de software de atender clientes downstream.

A pergunta certa de due diligence não é “A Cloud Temple pode hospedar uma VM?” Claramente pode. A pergunta é “O design do serviço escolhido corresponde ao dano operacional se este aplicativo parar?”

Para uma agência pública, a resposta pode envolver escopo SecNumCloud, segregação de inquilinos, nível de suporte, comunicação de incidentes e reversibilidade. Para um provedor de saúde, pode envolver escopo HDS, testes de restauração de backup, acesso a suporte, retenção de entidade lock e se as evidências do subcontratado cobrem todos os caminhos. Para uma equipe financeira, pode envolver evidências de auditoria, diversidade de rotas, arquivo imutável, criptografia, custódia de chaves e planejamento de saída no estilo DORA.

Para uma empresa industrial, pode envolver links de baixa latência, proximidade de instalações, design de backbone privado, janelas de manutenção e fallback operacional local. Um único rótulo de produto não pode responder a essas perguntas. O cliente tem que transformar as evidências públicas em uma revisão de design específica da carga de trabalho.

O caminho de falha que mais vale a pena testar é o composto: um incidente que cruza infraestrutura do provedor, configuração do cliente e processo de suporte. Imagine um cliente executando VMware IaaS em duas zonas de disponibilidade com um par de firewalls, cópias de backup S3, um prefixo de propriedade do cliente, um caminho de fibra no local e um nível de suporte Premium. Se uma zona degradar, o aplicativo pode depender da configuração de HA, replicação de armazenamento, estado do firewall, comportamento do DNS, convergência de rota, disponibilidade S3 e um ticket que é classificado corretamente.

Se o próprio circuito da operadora do cliente também tiver problemas, o backbone da Cloud Temple pode não ser o gargalo. Se a política de backup do cliente foi mal projetada, o armazenamento de objetos em três zonas pode preservar os dados errados. É por isso que a responsabilidade compartilhada tem que ser exercida antes da interrupção, não meramente citada durante ela.

As janelas de manutenção merecem a mesma atenção. A linguagem do SLA exclui a manutenção programada notificada sob o contrato de suporte do cliente. Isso é normal, mas desloca o planejamento prático para o cliente. Quem recebe os avisos de manutenção? Eles são roteados para a equipe que possui o aplicativo? O cliente sabe se uma atualização de hipervisor pode acionar uma reinicialização? Ele entende que algumas atualizações de SO do hipervisor podem ser uma decisão do cliente porque a Cloud Temple não está ciente de cada restrição específica da carga de trabalho? As equipes de backup, monitoramento e firewall estão presentes durante a janela?

Um evento de manutenção é rotina para o provedor apenas se também for rotina para o cliente.

As janelas de reparo e estoque de hardware são mais difíceis de verificar a partir de fontes públicas. Os documentos revelam classes de blades, limites de armazenamento, portas de rede e unidades de hospedagem física, mas não publicam contagens de blades de reposição, controladores de armazenamento sobressalentes, inventário de GPU, prazos de entrega por classe ou prática exata de substituição por zona de disponibilidade. Isso não significa que o estoque esteja ausente. Significa que a pesquisa pública não pode prová-lo.

O pedido certo do cliente é simples: mostre o processo de reserva de capacidade, expansão e substituição para o serviço escolhido. Se o aplicativo precisar de mais quatro blades GPU durante uma emergência, ou um host de reposição após uma falha de blade, ou throughput extra de armazenamento de objetos durante uma recuperação, o cliente deve saber se a resposta é imediata, programada, dependente de pedido ou dependente de orçamento.

O mesmo se aplica à prova de restauração. A plataforma qualificada, redundância S3 e arquitetura de backup da Cloud Temple criam um ponto de partida mais forte do que um host genérico. Mas as matrizes de responsabilidade IaaS e S3 colocam repetidamente a coerência do plano de backup e os testes periódicos de restauração com o cliente, às vezes com a Cloud Temple consultada. Isso deve mudar a linguagem de aquisição.

Os compradores devem perguntar não apenas “O backup está incluído?” mas “Quem escreve o plano de restauração, quem executa o teste, quem registra o resultado, o que acontece se a restauração perder o alvo e qual nível de suporte se aplica durante uma recuperação real?” Uma restauração não testada continua sendo uma aspiração, mesmo quando o armazenamento subjacente é bem construído.

O grau de evidência para a TEMPLE Cloud Temple SAS deve, portanto, ser melhor do que a cautela de pegada fina da atribuição, mas ainda não absoluto. O registro público é amplo, atual e específico: páginas oficiais identificam posicionamento para setores regulados, escritórios franceses, escopo SecNumCloud e HDS, famílias de produtos, níveis de suporte, arquitetura de armazenamento de objetos, design de backbone privado, termos de SLA de VPC e VM, limites físicos de hospedagem, roteamento AS33930, validade RPKI, pontos de troca e componentes de status público. Essa é uma pegada substancial.

A evidência ausente é mais estreita, mas decisiva: posicionamento específico do cliente, designação exata da operadora da instalação para cada carga de trabalho, estoque de reposição, histórico de desempenho de suporte, resultados de testes de restauração, concentração de clientes, comunicações de manutenção e execução real de saída.

Para os compradores, a conclusão prática é tratar a TEMPLE Cloud Temple SAS como uma dependência de nuvem soberana credível que ainda precisa de prova no nível da carga de trabalho. Peça um diagrama que nomeie a região, zonas de disponibilidade, hosts ou classes de computação, classes de armazenamento, buckets S3, políticas de backup, gateways VPC, saídas de Internet, circuitos do cliente, contatos de suporte e caminhos de escalonamento. Pergunte quais compromissos são cobertos pelo escopo SecNumCloud, quais são HDS, quais são hospedagem comum, quais estão em preview e quais são de propriedade do cliente.

Pergunte como os créditos de serviço são solicitados e o que eles não cobrem. Pergunte como uma carga de trabalho sai, como os dados são apagados, como as chaves são tratadas e como o suporte se comporta fora do horário comercial.

Para leitores de infraestrutura, a lição é mais ampla. Um provedor de nuvem soberana pode ser genuinamente operacional e ainda depender da física mundana da capacidade. A TEMPLE Cloud Temple SAS vende uma combinação atraente: infraestrutura francesa qualificada, plataformas empresariais reconhecíveis, roteamento visível, armazenamento de objetos em três zonas de disponibilidade, suporte na França e matrizes de responsabilidade explícitas. Mas o cliente não compra “soberania” no abstrato. Ele compra um inquilino específico, classe de blade, camada de armazenamento, caminho de rede, nível de ticket, calendário de manutenção e acordo de saída.

Essas são as peças que decidirão se a capacidade hospedada sobrevive a um evento de rack, evento upstream, escassez de hardware, fila de suporte, atrito de faturamento, pressão de migração ou falha de contrato do provedor.