Resumo

  • O site público da Cloud9 a apresenta como um provedor georgiano de hospedagem, nuvem e data center com serviços que incluemcolocation e racks,VPS,VDS,servidores dedicados,hospedagem compartilhada Linux,e-mail Zimbra, domínios, SSL e serviços de portal do cliente.
  • As evidências de rede são significativas.RIPEstat mostra AS57814como anunciado para o titular Cloud9 Cloud 9 Ltd. em 12 de julho de 2026, enquantoAS49297está vinculado ao mesmo titular, mas não anunciado. As contas RIPE RIS para AS57814 mostram28 prefixos IPv4 de origem, 13 prefixos IPv4 em trânsito, três prefixos IPv6 de origem e dois prefixos IPv6 em trânsito.
  • O centro de gravidade físico é Tbilisi. Apágina do data centerda Cloud9 afirma que a maioria de seus serviços é fornecida a partir de seu próprio data center em Tbilisi, ePeeringDB listauma instalação Cloud9 Dinamo Arena na 2 A. Tsereteli Ave, Tbilisi, com presença em um exchange e contatos de suporte públicos.
  • O risco para o comprador não é que a Cloud9 seja invisível. É que as evidências públicas ainda não comprovam a capacidade de failover específica do cliente, a disponibilidade de hardware sobressalente, o desempenho da restauração de backup, a escalada de suporte ou os direitos de saída. Os clientes devem verificar essas condições antes de considerar a capacidade hospedada pela Cloud9 como um substituto para seu próprio design de continuidade.

A empresa é visível o suficiente para ser analisada

Cloud9 Cloud 9 Ltd. merece uma leitura mais concreta do que muitas pequenas entradas de hospedagem, pois vários arquivos públicos independentes concordam. O site da empresa usa a marca Cloud9 para um negócio georgiano de hospedagem e data center. Apágina inicialdescreve a Cloud9 como um provedor profissional de hospedagem web e um operador experiente de data center na Geórgia. O rodapé menciona um endereço operacional na 2 Akaki Tsereteli Ave., Dinamo Stadium, Gate 5, Tbilisi, Geórgia 0112, com número de telefone e e-mail de suporte. Ostermos de serviçoidentificam "Cloud 9 LLC", ID da empresa 405063755, com endereço legal em Tbilisi e e-mails de contato para questões contratuais e de suporte. A denominação não é perfeitamente uniforme em todas as superfícies públicas, mas o endereço, domínio e evidências de registro apontam para o mesmo operador georgiano de hospedagem.

Os registros RIR tornam essa identidade mais do que uma simples afirmação no site.O RDAP RIPE para AS57814lista a organização registrada como Cloud 9 Ltd., mostra o endereço como 2 Tsereteli ave, 0112, Tbilisi, Geórgia, e fornece contatos administrativos, técnicos e de abuso públicos.O RDAP RIPE para ORG-CL434-RIPEfornece a organização como Cloud 9 Ltd., o mesmo endereço em Tbilisi, um número de telefone e e-mail de contato.O RDAP RIPE para AS49297vincula outro sistema autônomo à mesma organização e ao mesmo conjunto de contatos.

Isso é importante porque os serviços visíveis da empresa são serviços de infraestrutura. A Cloud9 vende capacidade voltada para o cliente: hospedagem compartilhada, servidores virtuais, servidores dedicados, colocation, e-mail, domínios, certificados e serviços de data center. Um cliente que compra esses serviços não está comprando apenas uma marca; ele depende de espaço em rack, energia, roteamento, mão de obra de suporte e condições contratuais. As evidências públicas são fortes o suficiente para colocar a Cloud9 nesta categoria.

Elas não são fortes o suficiente para responder a todas as perguntas de continuidade dos clientes sem documentos contratuais e de design.

O mais importante, portanto, é ser prático. A Cloud9 é visível como um provedor georgiano operacional de hospedagem e rede. Ela também concentra grande parte da história do cliente em torno de uma instalação nomeada em Tbilisi. Essa combinação é útil para serviços regionais e localidade de dados. Isso também significa que um cliente deve perguntar onde cada serviço realmente é executado, como ele falha, como se recupera e o que acontece se o cliente precisar sair rapidamente.

O registro de rede inclui dois números AS, mas apenas um está visivelmente ativo

A tabela de roteamento pública tem um centro claro e uma ressalva importante.A visão geral AS do RIPEstat para AS57814mostra o titular como Cloud9 Cloud 9 Ltd. e marca o AS como anunciado na data de consulta de 12 de julho de 2026.A visão geral AS do RIPEstat para AS49297mostra a mesma cadeia de titular, mas marca este AS como não anunciado na mesma data de consulta.Os dados de prefixos anunciados do RIPEstat para AS57814listam um amplo conjunto de rotas visíveis, incluindo 185.229.110.0/24, 45.138.44.0/22 e 195.69.140.0/22, entre outros, enquantoo mesmo endpoint para AS49297não retorna nenhum prefixo anunciado.

Essa distinção deve ser preservada. Seria errado dizer que cada AS vinculado à Cloud9 transporta tráfego ativamente. Também seria errado dizer que a empresa não tem uma rede visível. AS57814 está claramente ativo na visão de roteamento público.As contagens de prefixos RIPE RISmostram 28 prefixos IPv4 de origem, 13 prefixos IPv4 em trânsito, três prefixos IPv6 de origem e dois prefixos IPv6 em trânsito para AS57814 na data de consulta de 12 de julho de 2026. Essas contagens não provam quantos clientes estão ativos, quão cheia a plataforma está ou quanta capacidade de reserva existe, mas mostram uma superfície de rede materialmente maior do que uma única rota dormente.

Os exemplos de rotas também mostram a visibilidade atual dos prefixos.A visão geral de prefixo do RIPEstat para 185.229.110.0/24indica que o prefixo é anunciado por AS57814 e o vincula a 185.229.108.0/22.A amostra de estado BGP do RIPEstat para 185.229.110.0/24retornou centenas de observações de rota, com caminhos alcançando AS57814 através de AS upstream ou peers, como AS20771 e AS35805 na amostra.BGP.tools para AS57814descreve Cloud 9 Ltd. como uma rede de longa data que estabelece peering com outras redes e tem transportadoras upstream, eBGP.tools para 185.229.110.0/24mostra que este prefixo é originado em AS57814.

A inferência operacional é equilibrada. Cloud9 não é um revendedor sem rede. A empresa tem um AS ativo, visibilidade IPv4 e IPv6, objetos de rota e dados de peering públicos. Mas a visibilidade de rota não é a mesma coisa que garantia ao cliente. Um cliente ainda precisa saber quais workloads dependem dos prefixos próprios da Cloud9, quais dependem de plataformas de provedores, quais rotas transportam serviços de backup e se um evento de failover tem margem suficiente após a carga normal do cliente.

O data center está no centro da oferta

Apágina do data centerda Cloud9 é incomumente direta sobre a dependência física. Ela afirma que a maioria dos serviços fornecidos pela Cloud9 é entregue a partir de seu próprio data center em Tbilisi. A página descreve um data center neutro em relação a operadoras, monitoramento 24/7 por engenheiros, controles de segurança, redundância de energia, detecção e supressão de incêndio, controle climático e interconexão. Afirma que a instalação é alimentada por três subestações elétricas independentes e um gerador diesel de reserva de 630 kVA; também afirma que a área de colocation tem energia redundante N+N com UPS. Para conectividade, a Cloud9 declara estar conectada às principais operadoras de telecomunicações e pequenos provedores de ISP através de fibras escuras dedicadas com várias rotas alternativas e capacidade total de interconexão de 250 Gbps.

PeeringDB apoia a afirmação da instalação de Tbilisi de uma maneira diferente.O registro de instalação do PeeringDB para Cloud9 Dinamo Arenalista a instalação na 2 A. Tsereteli Ave, Tbilisi, Geórgia 0112, com Cloud9 LTD como organização, uma nota de que a empresa fornece serviços de data center, hospedagem, nuvem e ISP na Geórgia, um net count de 7, um exchange count de 1 e um operador count de 1.A relação rede-instalação do PeeringDB para net_id 20057também vincula AS57814 a Cloud9 Dinamo Arena. Essa evidência pública do PeeringDB não certifica o design técnico, mas fornece uma âncora de instalação independente que corresponde ao padrão de endereço nas próprias páginas da Cloud9.

A questão chave é capacidade instalada versus capacidade utilizável. Uma página de data center pode nomear subestações, UPS e gerador, mas um cliente precisa saber como esses ativos se comportam em manutenção e falha. Quantos racks estão realmente construídos e energizados? Qual é a alocação de energia por rack? Quanta capacidade de UPS e gerador resta após a carga atual? Quanto combustível é contratado durante uma queda prolongada de energia? Os caminhos de energia são realmente independentes até o rack do cliente, ou são compartilhados antes de um ponto de falha? Como a partida do gerador é testada sob carga?

As páginas públicas não respondem a essas perguntas em profundidade para o cliente.

A mesma distinção se aplica à conectividade. Uma declaração de interconexão total de 250 Gbps é significativa, especialmente em um mercado regional, mas não é a mesma coisa que largura de banda disponível para o cliente durante uma falha. Um cliente precisa saber se seu serviço usa trânsito compartilhado, caminho de IXP, interconexão privada, rota de ISP local ou caminho de backbone da Cloud9; se o caminho de backup sai do mesmo edifício; e se as garantias de largura de banda sobrevivem a um corte de fibra ou manutenção de operadora. As páginas públicas da Cloud9 dão confiança suficiente para considerar o data center como real.

Elas não eliminam a necessidade de testar o que um cliente pode realmente consumir em momentos de estresse.

A hospedagem é um serviço de rack antes de ser um serviço de nuvem

O menu de varejo da Cloud9 é amplo. A empresa vendehospedagem compartilhada Linux,hospedagem compartilhada Windows,VPS,VDS,servidores dedicados,e-mail Zimbra,domínios, certificados e colocation. Ostermos de serviçodescrevem serviços de hospedagem, registro de domínio, locação de servidores virtuais, locação de servidores físicos, serviços de e-mail, serviços de data center, segurança e defesa DDoS, planejamento de infraestrutura de servidor, serviços DevOps e serviços em nuvem. Nem todos são a mesma dependência.

Hospedagem compartilhada depende de servidores web, painéis de controle, DNS, armazenamento e política de suporte. VPS depende do host físico, hypervisor, armazenamento, snapshots e controles de vizinho barulhento. VDS é anunciado como um produto de servidor virtual mais poderoso, mas ainda depende da alocação do servidor físico e do design de failover. Locação de servidor dedicado depende do hardware de propriedade da Cloud9, estoque de reposição, acesso a console remoto e disponibilidade de pessoal.

Colocation depende do equipamento do cliente, serviços de rack da Cloud9 e da capacidade do cliente de reparar ou autorizar intervenções remotas. E-mail depende da operação do servidor de correio, filtragem antispam, DNS, armazenamento, backups e ferramentas de migração.

As páginas de produtos públicas tornam a oferta de varejo compreensível, mas não podem comprovar a disponibilidade de recursos por si só. Um plano VPS pode listar CPU, memória e armazenamento, mas o desempenho real depende de contenção, disposição do armazenamento e capacidade de falha. Um servidor dedicado pode estar disponível para compra, mas uma placa-mãe, disco ou fonte de alimentação com defeito depende do estoque de peças de reposição e da capacidade de resposta da equipe.

Uma conta de hospedagem compartilhada pode ser barata, mas o tempo de restauração depende da frequência de backup, integridade do backup e se o sistema de backup é isolado do servidor com falha. Um domínio ou serviço de e-mail pode ser gerenciado através de um portal do cliente, mas a recuperação do cliente pode depender da rapidez com que o DNS e as exportações de caixa de correio podem ser movidos.

É por isso que a capacidade hospedada ainda precisa de uma auditoria física pelo cliente. A questão não é apenas se o serviço existe. É se o serviço permanece utilizável após a falha de um host, switch, sistema de armazenamento, unidade de resfriamento, caminho de energia, interconexão ou turno de suporte. As informações públicas da Cloud9 apoiam um provedor de serviços genuíno com uma instalação e rede. Elas não publicam detalhes suficientes para inferir a sobrevivência específica do cliente em cada um desses modos de falha.

A colocation desenha uma fronteira de propriedade clara

Apágina de colocationé uma das fontes públicas mais valiosas porque expõe a fronteira entre a capacidade de propriedade da Cloud9 e o equipamento de propriedade do cliente. A Cloud9 vende opções de colocation 1U, 2U e torre, meios racks, racks completos e gaiolas personalizadas. As ofertas 1U e 2U incluem alimentação dupla A/B, link de 1 Gb/s e link de gerenciamento; a oferta de servidor torre lista alimentação simples, link de 1 Gb/s e link de gerenciamento. A página afirma que a conectividade de 1 Gb/s não é medida para ISPs georgianos e inclui 30 Mb/s de conectividade mundial por cliente. Ela também afirma que o link de gerenciamento é para acesso IPMI, iLO, iDRAC ou BMC com IP interno e acesso VPN seguro.

Esses detalhes são comercialmente úteis e também revelam os limites. Colocation não é o mesmo que hospedagem dedicada gerenciada. O FAQ da Cloud9 afirma que, em colocation, o equipamento é responsabilidade do cliente, enquanto a Cloud9 oferecerá assistência para acelerar a correção. Afirma que a Cloud9 tem engenheiros disponíveis 24/7 para intervenções remotas e que a Cloud9 realizou migrações em grande escala, cada migração dependendo da workload.

Afirma também que o espaço e os endereços IP podem estar prontos em menos de 24 horas após orçamento e pagamento inicial, enquanto racks completos e gaiolas podem levar mais tempo devido a peças e mão de obra.

Para os clientes, essa fronteira é decisiva durante falhas. Se um servidor em colocation tiver uma falha de disco, energia ou firmware, a Cloud9 só pode fornecer intervenções remotas dentro do contrato do cliente e das peças de reposição ou plano de substituição disponíveis. Se o cliente não tiver discos sobressalentes, credenciais de console remoto, mídias de inicialização documentadas e alvo de migração, o rack pode permanecer energizado enquanto a aplicação permanece offline.

O mesmo se aplica a mudanças de rede: um link de gerenciamento só é útil se o cliente tiver os direitos de acesso, detalhes de VPN, credenciais conhecidas e um caminho de console testado.

A linguagem de preços e largura de banda também merece atenção. Um link local de 1 Gb/s e 30 Mb/s de conectividade mundial podem ser suficientes para muitos usos de hospedagem georgianos, mas não é a mesma coisa que largura de banda de nuvem mundial. Um cliente que atende usuários internacionais, backups fora do local ou exportações de dados volumosos precisa saber como o tráfego em rajada, faturamento, congestionamento e migração de emergência se comportam além do uso mensal normal. A página de colocation dá crédito à Cloud9 por tornar a fronteira pública.

Ela também fornece aos compradores as condições que eles devem verificar antes de colocar equipamentos críticos lá.

Peering e diversidade de rotas são melhores do que a suposição mais fraca

A suposição de risco inicial da atribuição alertava para uma pegada pública enxuta. As evidências reais de roteamento e peering são mais fortes do que isso.O registro de rede do PeeringDB para AS57814lista a Cloud9 como um perfil de serviços de rede com AS57814, sitehttps://www.cloud9.ge/, suporte IPv6, escopo regional, tráfego de saída significativo, 200-300 Gbps de tráfego auto-declarado, uma política de peering geral aberta, uma instalação e um exchange count de 1. Ele lista o conjunto IRR como AS-SET-CLOUD9. O perfil é automantido e não deve ser tratado como capacidade auditada, mas é um perfil de infraestrutura pública, não uma página em branco.

A entrada netixlan do PeeringDBlista a Cloud9 na IXP.ge com uma porta de 10.000 Mb/s, endereço IPv4 185.1.224.232, estado de peer de roteador servidor true e estado operacional true.O registro IXP.ge do PeeringDBdescreve o exchange como estando em Tbilisi e Kutaisi, com Cloud9 Dinamo Arena entre as entradas de instalação. A própriapágina do data centerda Cloud9 afirma que a empresa também é operadora de um ponto de troca de internet e fornece interconexões a operadoras. Tomadas em conjunto, essas fontes apoiam um papel de interconexão local significativo.

RIPEstat também mostra consistência de política de rota em um conjunto mais amplo de prefixos e peers.A consistência de roteamento AS para AS57814lista muitos prefixos como presentes tanto em BGP quanto nos dados de roteamento whois, incluindo 45.138.44.0/22, 185.229.108.0/24, 185.229.109.0/24, 185.229.110.0/24, 188.93.88.0/24 e 195.69.140.0/22. Também mostra vários peers de import e export em BGP e whois, incluindo AS49628, AS20771, AS35805, AS16010 e AS34797, bem como outros peers visíveis em BGP não presentes nos dados whois verificados.Os dados de comprimento de caminho AS do RIPEstatmostram AS57814 visível de muitos locais de coleta.

Este não é o perfil de um host de prefixo único com um único upstream observável. No entanto, a diversidade em nível de roteamento deve ser traduzida em resiliência de serviço. Uma rota pode ter vários caminhos enquanto um serviço de cliente ainda depende de um switch de topo de rack, array de armazenamento, caminho de distribuição de energia ou decisão de suporte.

Um cliente precisa perguntar quais provedores são usados para seu serviço, se as rotas são monitoradas ativamente, se a Cloud9 pode mover o tráfego durante um evento de manutenção e se a alcançabilidade internacional permanece aceitável quando um peer ou provedor de trânsito está degradado.

A higiene de roteamento é parcial, mas visível

A segurança de roteamento é uma área onde a Cloud9 tem evidências visíveis, embora devam ser avaliadas prefixo por prefixo.A validação RPKI do RIPEstat para AS57814 e 185.229.110.0/24retorna um status válido, incluindo ROAs de validação para origem 57814 cobrindo 185.229.110.0/24 e 185.229.108.0/22. Isso importa porque uma autorização de origem de rota válida ajuda as redes a rejeitar anúncios de origem errada para este prefixo. Isso não resolve o tempo de inatividade das aplicações, mas reduz uma classe de erro de roteamento ou sequestro.

Oendpoint de consistência de roteamento ASdá outro sinal positivo ao mostrar muitos prefixos da Cloud9 tanto em BGP quanto nos dados de roteamento whois. O conjunto AS do perfil PeeringDB também dá às redes um objeto público para usar na política de roteamento. Esses são bons sinais para um provedor regional, pois muitos incidentes operacionais começam com um filtro de rota, objeto desatualizado, ROA ausente ou incompatibilidade entre o que um provedor anuncia e o que um upstream está disposto a transportar.

A ressalva é que a evidência não é uma certificação universal. O link de validação RPKI acima valida um prefixo representativo, não todas as rotas. A saída de consistência de roteamento AS mostra rotas whois que não estão atualmente em BGP e peers em BGP que não estão na política whois verificada. Isso é normal para muitas redes, mas significa que as afirmações voltadas para o cliente devem ser medidas em relação ao prefixo ou serviço exato.

Um cliente usando um endereço de um bloco específico deve perguntar se esse bloco tem um ROA válido, um objeto de rota mantido, filtros upstream documentados e um contato de monitoramento que possa responder a vazamentos de rota ou perda de alcançabilidade.

A higiene de roteamento também deve estar ligada aos direitos de migração. Se o serviço de um cliente usa endereços IP fornecidos pela Cloud9, o cliente precisa saber se esses endereços podem ser movidos com a workload ou se DNS, certificados, listas de permissão e reputação de e-mail devem ser reconstruídos em outro lugar. As evidências de rede da Cloud9 são fortes o suficiente para que os serviços dos clientes possam estar profundamente integrados em seu espaço de endereçamento. Isso torna a documentação limpa mais importante, não menos.

As afirmações sobre energia e resfriamento precisam de evidências específicas do cliente

As afirmações públicas do data center da Cloud9 são detalhadas o suficiente para serem usadas, mas não o suficiente para substituir evidências de engenharia em um contrato. Apágina do data centerafirma que a instalação é alimentada por três subestações elétricas independentes e um gerador diesel de reserva de 630 kVA. Afirma que a área de colocation tem energia redundante N+N e sistema UPS. Descreve detecção precoce de temperatura, fumaça e incêndio, sistema de supressão de incêndio 3M Novec 1230, resfriamento DX, controle de temperatura e umidade, sem janelas ou paredes externas nas salas de servidores, e apenas encanamento de supressão de incêndio nas proximidades. Também afirma que todos os sistemas chave são monitorados 24/7 por engenheiros.

Essas são as categorias certas: energia, incêndio, resfriamento, segurança física e monitoramento. A questão restante é se o cliente recebe serviço redundante após manutenção ordinária e eventos de falha críveis. Se um cliente compra colocation 1U com alimentação dupla A/B, ambas as fontes são realmente roteadas para caminhos de alimentação upstream separados, ou um componente upstream ainda pode afetar ambas? Se um cliente compra colocation em torre com uma única fonte, o cliente avaliou o risco de uma única fonte?

Se um cliente aluga um servidor dedicado, o contrato inclui prazos de substituição de componentes e um caminho de substituição de hardware? Se um servidor virtual é executado em hardware da Cloud9, que nível de falha de host ou armazenamento a plataforma pode absorver sem tempo de inatividade?

O resfriamento tem restrições ocultas semelhantes. O resfriamento DX pode ser apropriado para a instalação, mas o cliente precisa conhecer os limites de densidade no nível do rack, o design de corredor quente e frio, o posicionamento dos sensores e o caminho de escalada quando um rack fica quente. Uma instalação pode ter design de resfriamento redundante enquanto um rack de cliente específico ainda é limitado pelo fluxo de ar ou densidade de energia. A supressão de incêndio também é diferente para colocation física e serviços virtuais.

Um evento de supressão de incêndio pode proteger o equipamento de danos mais graves, mas ainda pode resultar em verificações de acesso de emergência, janelas de inspeção e atrasos na recuperação.

O site público afirma que a instalação é de nível Tier 3 no sentido de que pode planejar manutenção sem interromper o serviço. O FAQ sobre colocation explica o Tier 3 como o sistema de classificação do Uptime Institute e afirma que o data center da Cloud9 é de nível Tier 3. Os clientes devem perguntar se a Cloud9 possui certificação de terceiros atual ou usa o termo para descrever a intenção de design. A distinção não é pedante. Um design alinhado com conceitos Tier III é útil, mas uma instalação certificada, um registro de manutenção auditado e uma carta de redundância específica do cliente têm peso probatório diferente.

O portal simplifica o serviço, mas faturamento e acesso se tornam dependências

Ostermos de serviçoda Cloud9 são importantes porque mostram como os clientes realmente tocam a infraestrutura. Os termos afirmam que um usuário se registra no cloud9.ge e recebe uma conta pessoal no portal Cloud9 em my.cloud9.ge, onde o usuário pode comprar novos produtos, gerenciar produtos existentes, cancelar produtos indesejados, controlar pagamentos e abrir tickets de suporte a qualquer momento. Os termos também afirmam que o usuário é responsável por manter a confidencialidade da conta e as ações realizadas com a conta.

Esse design de portal é útil. Ele permite que os clientes gerenciem a infraestrutura sem esperar por uma conversa comercial. Também torna o acesso à conta uma dependência de continuidade. Se o e-mail autorizado do cliente for perdido, se as credenciais forem comprometidas, se um membro da equipe sair ou se os contatos de faturamento não forem atualizados, a capacidade do cliente de abrir tickets, cancelar serviços, controlar pagamentos ou fazer alterações de emergência pode ser prejudicada. Os termos colocam a responsabilidade no usuário de manter contatos, dados de registro, e-mail e detalhes telefônicos atualizados.

Isso é linguagem jurídica comum, mas se torna operacional durante uma falha.

O faturamento é outra dependência de caminho de reparo. Se um problema de faturamento ou período de liquidação desativar um serviço, o cliente pode sofrer uma falha técnica cuja causa raiz é administrativa. O cliente precisa saber como a Cloud9 notifica os contatos da conta, quanta antecedência se aplica antes de uma suspensão ou rescisão, se a restauração de emergência está disponível após o pagamento e qual pessoa pode autorizar uma mudança em uma crise. Os termos públicos podem descrever o contrato geral.

Clientes críticos ainda precisam de governança de conta: propriedade compartilhada do portal, contatos documentados, regras de saída e escalada de suporte testada.

Retenção e exclusão de dados também importam. Os termos e a política de privacidade da Cloud9 afirmam que dados pessoais e dados de prestação de serviços podem ser armazenados para fins legais e de serviço definidos, e que os dados podem ser excluídos ou destruídos após o período de retenção relevante. Os clientes devem distinguir entre dados de conta, logs, backups, dados de caixa de correio, arquivos hospedados e imagens de máquinas virtuais. A capacidade de um cliente de sair da Cloud9 depende do formato de exportação, momento da exclusão, disponibilidade de backups e da capacidade do cliente de recuperar dados após o cancelamento.

A lição prática é simples: o portal faz parte da infraestrutura. Os clientes devem protegê-lo como acesso de produção, designar mais de um mantenedor autorizado, manter os dados de faturamento atualizados e verificar o procedimento de suporte de emergência antes do primeiro incidente.

Soberania de dados é um trunfo apenas se o posicionamento do serviço for explícito

A afirmação de localidade mais forte da Cloud9 é a presença georgiana. O site da empresa, os termos, os registros RIPE e PeeringDB apontam para Tbilisi.O RDAP RIPE para ORG-CL434-RIPElista Cloud 9 Ltd. em Tbilisi.O registro de instalação do PeeringDBlista Cloud9 Dinamo Arena em Tbilisi.A geolocalização do RIPEstat para 185.229.110.0/24coloca este prefixo representativo em Tbilisi na data do resultado de julho de 2026. A página do data center da Cloud9 afirma que a maioria dos serviços é fornecida a partir de seu próprio data center em Tbilisi.

Para clientes que precisam de hospedagem georgiana, suporte local ou acesso de baixa latência a redes georgianas, isso é valioso. Muitas empresas não querem que cada workload seja enviada para uma região hyperscale em outra jurisdição, especialmente quando suporte ao cliente, solicitações regulatórias, idioma e caminhos de internet locais importam. As ofertas de colocation e servidores virtuais da Cloud9 podem, portanto, ser vistas como um jogo de capacidade local: o cliente compra proximidade, uma empresa local, acesso a operadora local e uma instalação local.

A palavra "maioria" ainda conta. As páginas públicas da Cloud9 não provam que cada serviço, cópia de backup, registro de e-mail, função de portal, serviço DNS, serviço de segurança ou conjunto de dados de suporte é armazenado apenas na Geórgia. Apolítica de privacidadetrata do processamento de dados pessoais e da prestação de serviços, mas o texto público não mapeia cada produto para um local de armazenamento. Ostermos de serviçolistam um amplo portfólio de serviços, incluindo domínios, certificados, e-mail, segurança, defesa DDoS e serviços em nuvem, alguns dos quais podem envolver sistemas de terceiros. Isso é normal para empresas de hospedagem, mas significa que a localidade dos dados deve ser especificada por serviço.

Um cliente com requisitos de soberania deve, portanto, pedir à Cloud9 uma declaração de posicionamento de serviço. Onde está a workload principal? Onde estão os backups? Onde estão os logs? Onde estão os tickets de suporte? Quais registros externos, autoridades de certificação, sistemas de segurança de e-mail ou processadores de pagamento tocam os dados do cliente? Todos os dados podem ser exportados e excluídos em um cronograma definido? Se o cliente precisa de processamento apenas georgiano, quais produtos da Cloud9 são elegíveis e quais não são? As evidências públicas da Cloud9 apoiam Tbilisi como um forte centro de gravidade.

Elas não resolvem automaticamente cada questão de soberania de dados.

Serviços de DNS e domínio fazem da Cloud9 parte do plano de controle dos clientes

A Cloud9 venderegistro de domínio, hospedagem adjacente ao DNS e serviços de e-mail, portanto seu papel pode se estender além da computação. O painel de servidores de nomes do site lista os servidores de nomes cPanel para hospedagem Linux, Windows e VPS: ns1.cpanel.ge e ns2.cpanel.ge para hospedagem Linux, ns5.cpanel.ge e ns6.cpanel.ge para hospedagem Windows, e ns3.cpanel.ge e ns4.cpanel.ge para hospedagem VPS. Observações de DNS públicas mostram que cloud9.ge usa ns1.cpanel.ge e ns2.cpanel.ge como servidores de nomes autoritativos, cloud9.ge resolvendo para 188.93.90.171, e seu registro MX apontando para tbs01-mail02.cpanel.ge. Esses nomes vinculam o web de varejo, hospedagem e oferta de e-mail ao namespace de serviço do próprio provedor.

Isso é importante porque o DNS é um plano de controle, não uma decoração. Se um cliente hospeda um site, domínio de e-mail ou aplicação na Cloud9 e usa servidores de nomes gerenciados pela Cloud9, um incidente de DNS pode afetar a migração, failover e recuperação mesmo quando o servidor subjacente está saudável. Por outro lado, se o cliente mantém o DNS em um provedor independente e usa a Cloud9 apenas para computação ou colocation, o cliente pode ser capaz de redirecionar o tráfego mais rapidamente durante um problema de serviço da Cloud9. A escolha certa depende da tolerância ao risco e do nível de habilidade do cliente.

O registro de domínio adiciona outra camada. Um cliente que compra domínios através da Cloud9 deve saber como funciona o acesso ao registro, se o cliente pode obter códigos de transferência rapidamente, quem recebe os avisos de renovação, se bloqueios de domínio estão em vigor e o que acontece se um problema de faturamento coincidir com uma renovação. Um domínio pode sobreviver a qualquer provedor de hospedagem, mas apenas se o cliente mantiver o controle das credenciais, detalhes do titular e direitos de transferência.

O e-mail aumenta ainda mais as apostas. O e-mail Zimbra pode ser conveniente para empresas que desejam um produto de caixa de correio hospedada localmente, mas a recuperação de correio depende de DNS, backups de caixa de correio, formatos de exportação, reputação antispam, senhas de usuário e tempo de suporte. Os clientes devem perguntar como as caixas de correio podem ser exportadas, como os registros DNS são restaurados, por quanto tempo o e-mail excluído permanece recuperável e qual compromisso de suporte se aplica durante uma falha de correio. Os serviços de domínio e e-mail da Cloud9 são partes legítimas de sua oferta.

Eles também fazem da Cloud9 um provedor de plano de controle para clientes que, de outra forma, poderiam pensar que estão comprando apenas servidores.

Os principais caminhos de falha são comuns, não exóticos

Os caminhos de falha mais críveis da Cloud9 não são eventos de ficção científica. São problemas de infraestrutura familiares: um problema de energia no rack, um incidente de resfriamento, uma falha de hardware, um vazamento de rota, uma falha de operadora upstream, um evento DDoS, uma suspensão de faturamento, um problema de acesso ao portal, um backup com falha, substituição lenta de peças de reposição, uma migração com falha ou uma fila de suporte que cresce mais rápido do que a equipe pode lidar. Como a Cloud9 oferece serviços hospedados e colocation, o impacto no cliente depende do que o cliente comprou.

Para um cliente de hospedagem compartilhada, a falha pode ser um site offline, banco de dados indisponível, erro de DNS, problema de conexão ao painel de controle ou atraso na restauração de backup. Para um cliente VPS ou VDS, a falha pode ser contenção de host, falha de armazenamento, manutenção de hypervisor, console de gerenciamento inalcançável ou perda de rede. Para um cliente de servidor dedicado, a falha pode ser um componente físico que requer inventário e substituição no local. Para um cliente de colocation, a falha pode ser hardware de propriedade do cliente ao qual a Cloud9 pode ajudar a acessar, mas não possui.

Para um cliente de domínio, a falha pode ser perda de controle sobre o nome, em vez do servidor. Para um cliente de e-mail, a falha pode ser acesso à caixa de correio, roteamento DNS, enfileiramento de correio ou reputação de spam.

A visão das rotas sugere que a Cloud9 tem mais diversidade de rede do que um pequeno provedor mono-hospedado, mas isso não elimina a concentração de serviços. Se muitos serviços de clientes estão em uma única instalação, um evento no nível da instalação ainda pode contar, mesmo com várias operadoras. Se os backups são armazenados no mesmo local, a recuperação pode ser atrasada pelo mesmo incidente que coloca a produção offline. Se os tickets de suporte e o acesso ao faturamento dependem do portal, um problema de conta ou portal pode complicar o reparo técnico.

Se um cliente tem hardware em colocation, mas não tem peças de reposição locais, a instalação pode funcionar normalmente enquanto a workload do cliente permanece inativa.

É por isso que as evidências públicas da Cloud9 devem ser consideradas como um ponto de partida para a devida diligência, não como um substituto. Os clientes devem perguntar o que falha junto. Os servidores hospedados, DNS, portal e alvos de backup compartilham o mesmo edifício? O serviço tem um segundo local? Os snapshots são armazenados fora do sistema de armazenamento principal? As mudanças de rota são testadas? Um cliente pode mover um domínio, caixa de correio ou imagem de servidor em caso de disputa ou emergência?

Cada resposta reduz a lacuna entre "hospedado em um data center" e "recuperável quando o data center, rede ou caminho de conta está sob estresse."

A migração é o custo oculto da capacidade barata

A página de colocation da Cloud9 afirma que a empresa realizou migrações em grande escala e ajudará os clientes a planejar e executar uma mudança para seu data center. Isso é um sinal positivo, pois a competência em migração conta na hospedagem regional. Mas cada migração tem dois lados: entrar no provedor e sair dele. Os clientes frequentemente negociam cuidadosamente o primeiro lado e ignoram o segundo até que uma falha, mudança de preço, exigência de conformidade ou venda da empresa force a questão.

O problema de saída é diferente para cada serviço da Cloud9. Clientes de hospedagem compartilhada precisam de arquivos de site, bancos de dados, zonas DNS, contas de e-mail e logs. Clientes VPS precisam de imagens de VM, snapshots ou builds de servidor reproduzíveis. Clientes VDS e servidor dedicado precisam de acesso ao sistema operacional, caminhos de cópia de dados, regras de firewall, imagens, licenças e planos de renumeração de IP. Clientes de colocation precisam de acesso físico, janelas de envio, coordenação remota, mapas de cabeamento e listas de equipamentos.

Clientes de domínio precisam de códigos de transferência e registros de titular desbloqueados. Clientes de e-mail precisam de exportações de caixa de correio, mudanças de DNS e reconfiguração de usuário. Um cliente que usa vários serviços ao mesmo tempo precisa do mapa completo.

A largura de banda pode se tornar o fator limitante. A página de colocation da Cloud9 afirma que a conectividade padrão do cliente inclui 1 Gb/s não medido para ISPs georgianos e 30 Mb/s de conectividade mundial por cliente. Isso pode ser perfeitamente adequado para workloads locais normais, mas uma exportação em massa para outro país pode se comportar de forma muito diferente. Se um cliente precisa mover terabytes de máquinas virtuais, backups ou caixas de correio, o cliente precisa saber se atualizações temporárias de largura de banda estão disponíveis, quanto custam e se o tráfego de migração compete com o tráfego de produção.

O endereçamento IP é outro custo oculto. Se os serviços de um cliente são construídos em torno de endereços IP fornecidos pela Cloud9, a migração exige mudanças de DNS, reemissões de certificados, atualizações de listas de permissão de firewall, reconstrução de reputação de e-mail e comunicação com o cliente. Se o cliente tem endereços independentes do provedor ou mantém um DNS de curta duração e independente, a migração pode ser mais fácil. A presença de rede da Cloud9 é útil, mas um cliente não deve presumir que o espaço de endereçamento usado hoje pode viajar com o serviço amanhã.

A postura de comprador mais segura é tratar o primeiro plano de migração e o plano de saída como um único documento. Se a Cloud9 é o provedor certo, ainda deve ser possível definir como o cliente recupera seus dados, domínios, caixas de correio, imagens de servidor e equipamento sob seu próprio controle.

O que os clientes devem verificar antes de colocar workloads críticas

As evidências públicas apoiam a Cloud9 como um provedor de infraestrutura georgiano genuíno. As perguntas dos clientes são, portanto, mais avançadas do que "ele existe?" A primeira série diz respeito à instalação e capacidade. Qual instalação exata hospeda o serviço? É Cloud9 Dinamo Arena, outra sala da Cloud9 ou uma plataforma de terceiros? Quantos racks, fontes de energia, caminhos de resfriamento e caminhos de rede estão envolvidos para o serviço específico do cliente? Qual é a densidade de energia, alocação de largura de banda e capacidade de failover do cliente?

Existe um segundo local, e ele está ativo, quente ou reservado para backups?

A segunda série diz respeito à operação de rede. Quais prefixos o serviço do cliente usará? Eles são cobertos por ROAs RPKI válidos e objetos de rota atualizados? Quais upstreams e peers transportam o tráfego do cliente? O cliente obtém uma garantia de diversidade de rota? O que acontece se IXP.ge, um upstream, uma rota de fibra ou um ponto de entrega do edifício falhar? Como vazamentos de rota, eventos DDoS e problemas de alcançabilidade internacional são tratados? Qual visibilidade o cliente pode ter durante um incidente?

A terceira série diz respeito à recuperação de dados. Com que frequência os backups são feitos? Onde eles são armazenados? Eles são imutáveis ou isolados das credenciais de produção? Com que frequência as restaurações são testadas? Quanto tempo leva para restaurar um servidor virtual completo, uma caixa de correio ou um banco de dados? Um cliente pode restaurar sem que o portal principal da Cloud9 esteja disponível? As exportações de backup estão incluídas no preço, e as exportações de emergência são limitadas pela largura de banda?

A quarta série diz respeito a suporte e controle. Quem atende fora do horário comercial? Quais problemas são cobertos por intervenções remotas e quais são cobráveis? Qual é o caminho de escalada de suporte para colocation, substituição de servidor dedicado, mudanças de rota, transferências de domínio e falhas de correio? Quantos contatos autorizados o cliente pode manter? O que acontece se o contato de faturamento sair? O cliente pode designar contatos de emergência separados dos contatos de faturamento?

A quinta série diz respeito à saída. O cliente pode receber uma lista de ativos atual, um arquivo de zona DNS, uma exportação de caixa de correio, uma imagem de VM, uma cópia de backup, um código de transferência de domínio e um registro de acesso mediante solicitação? Quanta antecedência é necessária? O que acontece em caso de disputa? Por quanto tempo os serviços excluídos ou cancelados são recuperáveis? Quais dados são destruídos e quando? Essas perguntas não são hostis. São as condições mínimas que transformam um serviço hospedado em uma dependência responsável.

Em resumo

Cloud9 Cloud 9 Ltd. deve ser considerada um provedor georgiano operacional de hospedagem e data center com evidências de infraestrutura pública críveis. Suas próprias páginas vendem os serviços relevantes. Os registros RIPE vinculam Cloud 9 Ltd. a AS57814 e AS49297, e RIPEstat mostra AS57814 como anunciado enquanto AS49297 não é visível em BGP. AS57814 tem uma superfície de rota significativa em IPv4 e IPv6, com visibilidade de origem e trânsito. PeeringDB coloca a Cloud9 no Cloud9 Dinamo Arena em Tbilisi e mostra presença na IXP.ge.

A página do data center da Cloud9 fornece afirmações concretas sobre energia, resfriamento, supressão de incêndio, monitoramento e interconexão de operadora.

Isso é suficiente para ir além da interpretação mais fraca. Cloud9 não é apenas um nome em um diretório. É um provedor de infraestrutura local com uma oferta centrada em instalação, presença de roteamento pública e produtos de varejo que podem ser importantes para empresas georgianas, desenvolvedores, órgãos públicos e provedores de serviços regionais. A proposta de valor é clara: compre capacidade hospedada ou em colocation próxima a redes georgianas, com suporte local e um operador de data center que se apresenta como neutro em relação a operadoras.

O risco restante é o mesmo risco que acompanha cada provedor regional de nuvem e hospedagem. O rótulo de nuvem não apaga racks, trânsito, energia, hardware, DNS, faturamento, acesso à conta ou migração. As páginas públicas não provam capacidade de reserva durante uma falha de componente, velocidade de restauração após um incidente de backup, direitos de exportação do cliente, escalada após horário comercial ou failover limpo de uma instalação para outra. Os clientes podem usar a Cloud9 corretamente se documentarem essas condições. Eles não devem usá-la como uma caixa preta.

Para workloads críticas, a capacidade da Cloud9 deve ser tratada como real, mas dependente do contrato. A empresa tem evidências de infraestrutura pública suficientes para ser levada a sério. A segurança do cliente depende de transformar essas evidências em respostas específicas: onde a workload é executada, o que falha com ela, como as rotas sobrevivem, como os backups são restaurados, quem repara o hardware, quem atende após o horário comercial, o que acontece quando uma fatura ou contato de conta dá errado e como o cliente sai sem perder dados ou controle.