Resumo

  • A Eternity Cloud Limited é uma nova empresa privada britânica com presença pública de hospedagem, um número AS ativo e uma rota IPv4 pequena, mas visível. Operfil oficial da Companies Houseregistra a constituição em 27 de outubro de 2025, status ativo, sede em Londres e um código SIC de consultoria, em vez de uma classificação de instalações ou transportadora.
  • O site público da empresa direciona os usuários para etyCloud, Whitewhale, identity, checkout e documents. Osite ety.onee osite etyClouddescrevem um serviço de nuvem ou hospedagem, enquantoWhitewhaleoferece planos VPS europeus, roteamento via seu próprio AS, hospedagem em data centers de nível 1, proteção DDoS e uma promessa de disponibilidade de 99,9%.
  • As evidências de rede são reais, mas limitadas. Oobjeto AS201830 do RIPEnomeia a Eternity Cloud Limited, oRIPEstatmostra um prefixo IPv4 /24 anunciado durante a janela de observação, ea validação RPKImarca a origem atual para 82.41.36.0/24 como válida.
  • O risco prático é a concentração de dependências. Os dados de roteamento públicos indicam uma pegada de um único prefixo, um único vizinho observado na visão AS atual, nenhum anúncio IPv6 visível, superfícies web e de conta via Cloudflare, e nenhuma lista pública de instalações, histórico de manutenção ou registro de incidentes. Isso torna a Eternity um pequeno provedor de hospedagem plausível, mas não um operador de infraestrutura multisite comprovado.

Por que a Eternity é importante apesar de seu tamanho

Pequenas empresas de hospedagem podem parecer marginais por fora porque suas declarações legais são enxutas, seus sites são simples e suas tabelas de roteamento são pequenas. Isso não as torna insignificantes. Um provedor VPS de baixo custo ainda pode estar entre um desenvolvedor e um aplicativo ativo, entre uma pequena empresa e seu painel de controle, ou entre um projeto regional e o único servidor que ele pode pagar para operar. A questão de infraestrutura não é se a Eternity Cloud Limited é grande o suficiente para competir com as maiores plataformas de nuvem.

Trata-se de saber se um comprador pode entender o que realmente está comprando quando a oferta menciona nuvem, VPS, locais europeus, próprio ASN, proteção DDoS e capacidade mensal barata.

O registro público dá uma resposta mista. A Eternity tem mais substância do que uma simples página inicial. A empresa britânica existe. O registro público nomeiaEternity Cloud Limitedcomo uma sociedade privada de responsabilidade limitada ativa. Os registros do RIPE vinculam o nome e o endereço londrino da empresa ao AS201830, e os dados de roteamento públicos mostram um prefixo IPv4 originado desse AS. A superfície de serviço não é apenas uma página de logotipo: o aplicativoetyCloudapresenta um ambiente de conta de hospedagem, e a páginaWhitewhalefornece nomes de planos, preços, tamanhos de recursos e afirmações de rede.

O mesmo registro também mostra por que a empresa deve ser lida com cautela. A Eternity foi constituída em 27 de outubro de 2025, portanto ainda não havia depositado um primeiro conjunto de contas no momento desta análise. As primeiras contas são esperadas em 2027, de acordo com apágina de arquivamento da Companies House. O capital visível na declaração de constituição é baixo. A sede é um endereço londrino central frequentemente usado por muitas empresas, não uma prova de data center. Os registros de diretores e controle identificam um único diretor ativo e controlador significativo,Mikhail Karlov, cujo endereço de correspondência na Companies House é o mesmo da sede. Nenhum desses fatos torna a empresa suspeita por si só. Eles simplesmente definem o ponto de partida: um operador jovem com pouco histórico financeiro público e uma pegada operacional pública estreita.

Essa distinção é importante para compradores de infraestrutura porque o risco na capacidade hospedada raramente está no nome de marketing. "Nuvem" é uma promessa comercial, mas o serviço sempre depende de racks específicos, provedores upstream, blocos de endereços, DNS, sistemas de identidade, sistemas de faturamento e mão de obra de suporte. Se um servidor falhar, uma rota for retirada, um serviço de conta recusar conexões, um link de pagamento quebrar, um evento DDoS desencadear filtragem ou um bloco de endereços alugado precisar ser movido, o cliente precisa de caminhos de recuperação práticos.

Os registros públicos não podem responder a todas as perguntas de suporte, mas podem mostrar quais dependências são visíveis e quais permanecem opacas.

A pegada pública da Eternity sugere um operador operando no limite dessa transição. É visível o suficiente para vender capacidade em seu próprio nome e número de rede. Ainda não é visível o suficiente para permitir que um comprador verifique independentemente a diversidade de instalações, diversidade de transportadoras, propriedade de hardware, pessoal de reparo, práticas de backup, transparência de incidentes ou garantias de migração. O resultado é uma empresa que pode ser significativa para uma necessidade de hospedagem de baixo custo, mas merece uma nota baixa para evidências de rede em termos de garantia pública.

O registro da empresa indica novo, ativo e estreitamente controlado

O ponto de partida legal é simples. Operfil da Companies Houselista a Eternity Cloud Limited sob o número 16810688, uma sociedade privada de responsabilidade limitada ativa constituída na Inglaterra e País de Gales em 27 de outubro de 2025. Sua sede é 71-75 Shelton Street, Londres, WC2H 9JQ. O código SIC informado é 62020, "Atividades de consultoria em tecnologia da informação." O registro indica que as primeiras contas são até 31 de outubro de 2026 e devem ser depositadas até 27 de julho de 2027, com uma primeira declaração de confirmação esperada em novembro de 2026.

Para um leitor de infraestrutura, essas entradas são menos sobre formalidade e mais sobre maturidade. Um provedor pode começar a negociar antes de depositar suas primeiras contas, mas a ausência de contas significa que não há balanço público, receita depositada, passivos depositados ou visão auditada ou não auditada dos ativos por trás do serviço. Um cliente de capacidade hospedada não pode usar o registro de empresas britânico para inferir o número de servidores, a extensão dos compromissos com fornecedores, o volume de receita, o nível de capital de giro ou a profundidade dos recursos de reparo. O registro confirma existência e status.

Não confirma escala operacional.

O registro de controle também é concentrado. Apágina de diretoreslista Mikhail Karlov como diretor ativo, nomeado na data de constituição. Apágina de pessoas com controle significativolista o Sr. Mikhail Karlov como detentor de 75% ou mais das ações, 75% ou mais dos direitos de voto e o direito de nomear ou destituir diretores. A Companies House também registra uma data de verificação de identidade em novembro de 2026 para os registros de diretores e controle.

Controle estreito é comum em jovens empresas de hospedagem. Pode permitir decisões rápidas, manter preços agressivos e reduzir burocracia. Também pode criar risco de pessoa-chave. Se o roteamento, relações com fornecedores, disputas de faturamento, tratamento de abusos, recuperação de identidade e suporte ao cliente dependem todos de um pequeno grupo fundador, o serviço pode ser mais frágil do que a página do produto sugere. O registro público não mostra conselho de administração, equipe de gestão ou equipe técnica nomeada além da função NOC associada à empresa nos registros RIPE.

Um comprador deve, portanto, assumir que a continuidade depende fortemente de uma pequena camada humana, a menos que a Eternity publique divulgações operacionais mais robustas.

A sede também deve ser tratada com cautela. Shelton Street é um endereço de correspondência legal em Londres. Não deve ser interpretado como um local de hospedagem ou instalação de rede. Os registros RIPE usam o mesmo endereço para a empresa e objetos de contato, mas esses registros estabelecem contato administrativo, não localização de rack. O site da Whitewhale fala sobre locais europeus de data centers, e os dados de roteamento apontam para relações upstream europeias, mas o endereço público da empresa em si não é prova de servidores em Londres.

Este é um tema recorrente no perfil público da Eternity. Os registros não estão vazios. Eles simplesmente não fazem mais trabalho do que foram projetados para fazer. A Companies House prova que a empresa existe, está ativa e é controlada por uma pessoa nomeada. O RIPE prova que um AS e objetos de rota foram registrados. As páginas de serviço provam que alguém está anunciando capacidade VPS e nuvem sob a bandeira Eternity/etyCloud/Whitewhale.

Nenhum desses registros, isoladamente, prova a quantidade de capacidade física implantada, o gerenciamento de janelas de manutenção, a disponibilidade de hardware sobressalente ou como um cliente seria migrado durante uma disputa com fornecedor.

A superfície de serviço é um conjunto, não uma única página de produto

O serviço público da Eternity está espalhado por vários domínios. O site raizety.oneapresenta a marca Eternity e links para produtos, suporte, login de conta e cadastro. O texto público e os ativos vinculam a marca à etyCloud e Whitewhale, e o rodapé usa o nome Eternity Cloud Limited. O site também expõe pontos de contato de suporte público, como[email protected]e links para um centro de documentação em inglês e russo. Isso dá à marca mais estrutura do que uma página de placeholder, mas a estrutura permanece compacta.

O siteetyCloudé a superfície direta de hospedagem em nuvem. Sua descrição pública em russo indica que a etyCloud fornece soluções de hospedagem confiáveis e rápidas para empresas e desenvolvedores. O título do site o apresenta como hospedagem acessível. Seu texto de aplicativo mostra ações de conta de usuário, comandos de servidor, faturas, tickets e detalhes do servidor, como CPU, memória, armazenamento, localização, canal, tipo de armazenamento e preço. O site se lê, portanto, como um ambiente de controle de hospedagem, em vez de um folheto geral da empresa.

Isso é importante porque um ambiente de controle é onde as promessas de nuvem se tornam promessas operacionais. Se um comprador encomendar um servidor via etyCloud, a experiência dependerá de identidade, criação de conta, geração de pagamento, processamento de faturas, provisionamento de servidor, atribuição de IP, roteamento de tickets e resposta de suporte. Os ativos do site público mostram que esses componentes existem como interfaces web. Eles não provam o grau de automação por trás deles, o tratamento de exceções, ou se a entrega do servidor é imediata, manual ou dependente do fornecedor.

Whitewhale adiciona uma oferta comercial mais explícita. Suapágina em inglêschama Whitewhale de provedor de nuvem em locais europeus, descreve "seu próprio ASN AS201830", oferece planos a partir de 1 EUR por mês e lista suporte em[email protected]e faturamento em[email protected]. Os cartões de planos incluem KRILL a 1 EUR por mês com 1 vCPU, 2 GB de RAM e 10 GB NVMe, NARWHAL a 4 EUR por mês com 2 vCPU, 4 GB de RAM e 40 GB NVMe, ORCA a 8 EUR por mês com 4 vCPU, 8 GB de RAM e 80 GB NVMe, LEVIATHAN a 15 EUR por mês com 6 vCPU, 12 GB de RAM e 160 GB NVMe, e um nível personalizado WHITEWHALE+ a partir de 25 EUR por mês. A página também anuncia tráfego ilimitado, uplinks compartilhados, proteção DDoS, locais europeus e disponibilidade de 99,9%.

A página Whitewhale é útil porque torna a oferta concreta. É também onde os compradores devem desacelerar. Preços muito baixos e linguagem de tráfego ilimitado podem ser legítimos quando a capacidade é compartilhada, a supercontratação é gerenciada e as regras de abuso são rigorosas. Eles também podem se tornar pontos de pressão quando eventos de rede, vizinhos barulhentos, filas de suporte ou custos de fornecedores aumentam. A própria tabela comparativa da Whitewhale indica que os planos de entrada compartilham 500 Mbps, enquanto outro texto na página menciona um uplink de alta velocidade de 1-3 Gbps em todos os VPS.

Isso pode ser uma inconsistência de apresentação em vez de uma contradição de serviço, mas mostra por que a taxa exata comprometida, os limites de uso justo e a prática de congestionamento devem ser confirmados antes de confiar nos planos para cargas de trabalho de produção.

O conjunto de produtos também separa várias funções que os clientes podem experimentar como um único serviço. Eternity é a empresa britânica. ety.one é a marca e gateway de conta. etyCloud é o aplicativo de hospedagem. Whitewhale é a oferta VPS/nuvem com as afirmações de rede pública mais fortes. A superfície de identidade está em auth.ety.one, e a superfície de pagamento aparece em checkout.ety.one. O centro de documentação está em documents.ety.one. Na prática, uma falha do cliente pode ocorrer em qualquer uma dessas camadas. Um servidor ainda pode estar funcionando enquanto o portal de conta está indisponível.

O portal de conta pode estar acessível enquanto o intervalo IP roteado do cliente está degradado. O faturamento pode falhar enquanto a computação está saudável. A pegada pública deve, portanto, ser lida como uma cadeia de serviços, e não como um sistema único.

É também aqui que a Cloudflare entra em jogo. Os cabeçalhos HTTP para ety.one, cloud.ety.one, auth.ety.one, checkout.ety.one, documents.ety.one e Whitewhale mostram Cloudflare na borda web, e o DNS público paraety.one,cloud.ety.oneewhitewhale.helpresolve para o espaço de endereçamento Cloudflare. Esta é uma escolha normal e muitas vezes sensata para entrega web pública. Também significa que o caminho visível do site não é o mesmo que o caminho servidor-cliente do AS201830. Cloudflare pode ocultar a localização de origem, absorver alguns ataques em nível web e manter uma página de marketing ou conta acessível mesmo quando o próprio prefixo roteado do provedor tem um problema diferente. A superfície web é evidência de apresentação de serviço, não evidência de resiliência de computação back-end.

A rede roteada é real, mas estreita

A evidência de infraestrutura mais forte da Eternity está no registro de roteamento. Oobjeto aut-num do RIPE para AS201830nomeia o AS como ETERNITY-CLOUD-MNT, associa-o a ORG-ECL85-RIPE e o registra como atribuído. O objeto foi criado em 29 de janeiro de 2026 e modificado pela última vez em 5 de fevereiro de 2026. Ele lista relações de importação e exportação com AS16276 e AS24940. AS16276 é OVH, e AS24940 é Hetzner. Estas são redes de infraestrutura europeias substanciais, e sua aparição no registro de política corresponde à afirmação da Whitewhale sobre hospedagem europeia e roteamento via próprio AS.

Oregistro RDAP do RIPE para o AStorna a conexão com a empresa mais clara. Ele nomeia o handle AS201830, fornece o nome ETERNITY-CLOUD-MNT, lista Eternity Cloud Limited como entidade registrada e mostra um contato NOC sob o nome Eternity Cloud. O endereço nesses objetos RIPE corresponde à sede londrina. O registro RDAP também lista um contato de abuso associado a[email protected]. Juntos, esses registros mostram uma identidade de rede registrada real, em vez de uma mera afirmação de marketing.

A visibilidade do roteamento, no entanto, é menor do que a existência de um AS sugere.A visão geral do AS do RIPEstatrelata AS201830 como anunciado e nomeia o titular como Eternity Cloud Limited.A visualização de prefixos anunciados do RIPEstatmostra um prefixo IPv4 atual, 82.41.36.0/24, durante a janela de observação.A visualização de status de roteamento para o ASmostra um prefixo IPv4 anunciado, 256 endereços IPv4, visibilidade IPv4 completa no conjunto de relatórios, nenhum espaço IPv6 anunciado nesta visualização e um único vizinho observado.

Isso é suficiente para dizer que a Eternity tem uma pegada roteada ao vivo. Não é suficiente para dizer que tem uma rede extensa. Um único /24 pode suportar um serviço real ao cliente, especialmente para pequenos planos VPS, mas também cria concentração. Se o prefixo for filtrado, retirado, contestado, sequestrado, colocado na lista negra ou esgotado, há pouca evidência pública de pools de endereços alternativos. Se o número de vizinhos observados permanecer em um, a acessibilidade do cliente pode depender de um único caminho upstream efetivo, mesmo que a política de registro liste mais de um provedor autorizado.

Se nenhum IPv6 estiver visível, os clientes que precisam de serviço dual-stack devem perguntar se o IPv6 está indisponível, não anunciado, fornecido por outro caminho ou simplesmente não representado na visualização pública atual.

O registro do prefixo adiciona outra camada.A visão geral do prefixo RIPEstat para 82.41.36.0/24identifica AS201830 como a origem anunciante.O objeto de rota RIPEregistra o AS de origem AS201830 para este /24 e foi criado em 29 de janeiro de 2026.A validação RPKIrelata a origem como válida, com um ROA permitindo que AS201830 origine o /24 exato. Esta é uma higiene positiva. Um ROA válido reduz uma classe de ambiguidade de origem de rota e ajuda as redes a rejeitar anúncios de origem conflitantes inválidos.

A atribuição de endereço também carrega uma dica de dependência. Osdados whois do RIPE para 82.41.36.0/24eo registro RDAP IPidentificam o netname NET-82-41-36-0-24, o país EU, uma organização de usuário final vinculada à Eternity Cloud Limited, um objeto de rota mantido por netutils-mnt e um geofeed associado à IPXO. O bloco de endereços é público e roteado, mas o contexto de manutenção e geofeed aponta para uma cadeia de recursos de endereços além da própria Eternity. Isso é comum no mercado IPv4. Também é relevante para os clientes, pois os arranjos de recursos de endereços podem afetar a portabilidade, o tratamento de abusos, a geolocalização, a reputação e a continuidade se uma relação comercial mudar.

Os dados de caminho visíveis reforçam o quadro de dependências. Umaconsulta looking-glass RIPEstat para 82.41.36.0/24mostra vários coletores vendo caminhos que terminam via AS16276 para AS201830. Isso corresponde à política aut-num e sugere que a OVH é um caminho upstream ao vivo importante para o prefixo anunciado. Isso não prova, por si só, a localização das instalações, a capacidade upstream de reserva ou um failover bem-sucedido para a Hetzner. Um cliente deve tratar o caminho público como evidência de acessibilidade, não como evidência de resiliência multi-transportadora.

Os racks, o trânsito e as janelas de manutenção são o produto oculto

A expressão "capacidade hospedada" parece numérica, mas é vendida a partir de camadas físicas e contratuais. Alguém deve possuir ou alugar os servidores. Alguém deve fornecer eletricidade, refrigeração, cross-connects e mãos remotas. Alguém deve transportar os pacotes para o resto da internet. Alguém deve manter os registros de endereços, objetos de rota, RPKI e caixas de correio de abuso. Alguém deve responder aos tickets quando um servidor está inativo, mas o site ainda está operacional. As evidências públicas em torno da Eternity identificam algumas dessas camadas, mas deixam as partes mais operacionais sem nome.

Whitewhale afirma que sua infraestrutura opera em locais europeus e data centers de primeira linha com energia e conectividade redundantes. Também anuncia proteção DDoS e um SLA de disponibilidade de 99,9%. Essas são afirmações comercialmente significativas. Também exigem detalhes antes de se tornarem garantia. Uma promessa de disponibilidade de 99,9% pode significar muitas coisas, dependendo se se aplica à disponibilidade de rede, energia do servidor, acesso ao painel de controle, disponibilidade de VM do cliente, serviços de pagamento, desempenho de armazenamento ou resposta de suporte.

Também pode ser medida em diferentes períodos, com diferentes exclusões para manutenção planejada, ataques, configuração incorreta do cliente e falhas upstream.

As páginas públicas não nomeiam as instalações, fornecedores de rack ou cidades por trás da afirmação "locais europeus". Elas não publicam uma página looking-glass sob a própria marca da Eternity, página de status de rede, arquivo de incidentes, calendário de manutenção, route-map, lista de provedores de trânsito em produção, guia de comunidade BGP, parceiro de mitigação DDoS, meta de substituição de hardware ou promessa de retenção de backup. Alguns pequenos provedores escolhem não publicar esses detalhes por razões de segurança ou comerciais.

Mas para um cliente usando o serviço como infraestrutura, cada detalhe ausente se torna uma pergunta a ser feita antes de confiar.

A primeira pergunta é onde a capacidade está fisicamente hospedada. Se os servidores estão em instalações OVH ou Hetzner, ou em colocation conectado a essas redes, o perfil de confiabilidade refletirá as regras de energia, rede e mãos remotas desses fornecedores. Se os servidores são máquinas dedicadas alugadas em vez de hardware próprio, o reparo pode depender da fila de suporte do fornecedor. Se os servidores são próprios, mas colocados em racks de terceiros, o reparo depende de peças de reposição, direitos de acesso e resposta de mãos remotas.

Se o fornecedor revende capacidade virtual de uma plataforma maior enquanto apresenta uma camada própria de AS, os limites operacionais diferem novamente. Os registros públicos não resolvem essa questão.

A segunda pergunta é como a diversidade upstream realmente funciona. O objeto aut-num RIPE lista entradas de política AS16276 e AS24940. A visão do AS do RIPEstat mostra um único vizinho observado. Os dados looking-glass para o prefixo atual mostram fortemente caminhos AS16276. Isso não prova que AS24940 não está sendo usado, mas significa que a visão pública no momento da análise não demonstra diversidade equilibrada ativa.

Se um caminho para a OVH falhar, um comprador gostaria de saber se a rota pode ser movida para a Hetzner, se essa movimentação é automática ou manual, se os filtros de prefixo são pré-aprovados, se a limpeza DDoS permanece disponível e quanto tempo a convergência normalmente leva.

A terceira pergunta é como os endereços são governados. A rota 82.41.36.0/24 é válida sob RPKI, o que é bom. Os dados whois e RDAP do bloco também fazem referência a netutils-mnt, informações de geofeed IPXO e uma organização de usuário final. Isso sugere um arranjo de recursos de endereços onde os registros de mais de uma parte importam. Se a geolocalização estiver incorreta, os relatórios de abuso forem mal tratados, um prefixo desenvolver má reputação ou o contrato de endereço mudar, os clientes podem encontrar problemas que não são resolvidos simplesmente reiniciando um servidor.

Os compradores de hospedagem barata muitas vezes subestimam essa camada até que a entrega de e-mail, verificação de pagamento, regras de acesso regional ou pontuação de fraude comecem a tratar um intervalo de IP de forma desfavorável.

A quarta pergunta é o tempo de reparo. A interface etyCloud parece incluir tickets, faturas e detalhes do servidor. Whitewhale publica endereços de e-mail de suporte e faturamento. O site raiz da Eternity publica informações de contato de suporte. Estes são canais necessários para o cliente. Não é o mesmo que uma garantia de reparo publicada. Um pequeno provedor pode responder rapidamente, mas um comprador público não pode inferir equipe 24/7, pools de capacidade de reposição, direitos de escalonamento com fornecedores upstream ou comunicação pós-incidente apenas a partir de e-mails de contato.

A página Whitewhale afirma que o suporte é 24/7, mas os clientes devem sempre perguntar como as falhas urgentes são classificadas, se créditos são oferecidos e quais informações são fornecidas durante um evento de rede.

A quinta pergunta é a saída do cliente. A capacidade VPS barata é atraente porque o custo de entrada é baixo. O custo de saída pode ser alto se um cliente não tiver backups atuais, etapas de reconstrução documentadas, plano de DNS, caminho de IP alternativo ou migração testada. As páginas públicas da Eternity não publicam portabilidade de backup, exportação de snapshots, exclusão de dados, download de imagem ou garantias de migração de emergência. Isso não significa que esses recursos estejam ausentes. Significa que os compradores devem tratar a portabilidade como sua própria responsabilidade, a menos que o contrato indique o contrário.

Cloudflare protege a porta de entrada, não cada servidor do cliente

A borda web pública é uma dependência separada da rede de hospedagem roteada. As respostas DNS para ety.one, cloud.ety.one e whitewhale.help apontam para endereços anycast Cloudflare, e as respostas HTTP identificam Cloudflare como o servidor à frente das páginas. O ponto de autenticação emauth.ety.oneretorna uma resposta protegida em vez de uma página de aplicativo público, enquantocheckout.ety.oneretorna uma resposta em estilo de aplicativo na raiz. O centro de documentação emdocuments.ety.onetambém está atrás da Cloudflare.

Essa disposição é sensata para um jovem provedor. Cloudflare pode absorver ataques web comuns, fornecer terminação TLS, armazenar em cache páginas públicas, melhorar a acessibilidade das páginas e reduzir a exposição dos servidores de origem. Também pode tornar a marca mais disponível do que a rede de computação subjacente durante alguns incidentes. Uma página de marketing pode estar acessível via Cloudflare enquanto o VPS de um cliente em 82.41.36.0/24 está inacessível. Inversamente, um servidor cliente ainda pode estar funcionando enquanto a superfície de autenticação ou pagamento está degradada.

Para os clientes, estas são falhas diferentes com remédios diferentes.

Essa distinção é frequentemente negligenciada na due diligence de pequenos provedores. Um comprador carrega o site, vê que a página é rápida e assume que a plataforma de hospedagem é igualmente resiliente. Mas o caminho do site usa a rede Cloudflare. O caminho do servidor do cliente, se atribuído a partir do prefixo roteado atual da Eternity, depende de AS201830, seu caminho upstream atual, o bloco de endereços, a rede da instalação e o próprio servidor. O caminho da conta depende de auth.ety.one. O caminho de faturamento depende de checkout.ety.one. O caminho de documentação depende de documents.ety.one.

O caminho de suporte depende do processamento de e-mail e tickets. Essas camadas podem falhar independentemente.

O DNS público também mostra registros de roteamento de correio Cloudflare para ety.one e Whitewhale. Isso é normal novamente, mas significa que a recepção de e-mail para endereços de suporte e faturamento tem sua própria dependência de serviço. Se uma falha do cliente incluir a incapacidade de receber ou enviar e-mails, a comunicação de suporte pode ser afetada por DNS, roteamento de correio, filtragem antispam, acesso à conta e resposta humana. Nada disso é único da Eternity. É a pilha comum por trás de pequenos provedores de hospedagem. O risco é que o baixo preço mensal faça a pilha parecer mais simples do que é.

Há também um ângulo de governança. As páginas públicas atrás da Cloudflare podem ser atualizadas rapidamente e podem ocultar a topologia de origem. Isso é útil para segurança, mas reduz o que observadores externos podem verificar. O cliente vê a marca, o plano e o pagamento. O pesquisador de rede vê um AS, um prefixo IPv4 visível, RPKI válido e superfícies web Cloudflare. O elo perdido é a plataforma de produção: hipervisores, armazenamento, backups, contratos de instalação, failover de trânsito e práticas de pessoal.

Um comprador sério não precisa que tudo isso seja publicado em uma página inicial, mas deve perguntar detalhes suficientes para adequar o risco da carga de trabalho.

O que os clientes devem inferir dos preços

A escala de preços da Whitewhale é um dos sinais públicos mais claros sobre o mercado visado. Planos a partir de 1 EUR por mês não são ofertas de nuvem empresarial. São ofertas VPS econômicas destinadas a desenvolvedores, pequenos projetos, experimentos e cargas de trabalho sensíveis a custos. Isso pode ser valioso. Muitos serviços de internet começam em VMs baratas porque a alternativa não é um contrato de hiperescala; é não lançar nada.

A questão é o que um cliente abre mão a esse preço. Provedores VPS baratos geralmente dependem de alta utilização, uplinks compartilhados, regras de abuso rigorosas, fluxos de suporte simplificados e garantias sob medida limitadas. A página Whitewhale é aberta sobre largura de banda compartilhada nos cartões de planos, enquanto também anuncia tráfego ilimitado. "Ilimitado" neste contexto não deve ser interpretado como capacidade dedicada infinita. Geralmente significa que não há limite de transferência mensal fixo sob regras de uso aceitável, não que cada cliente possa saturar o uplink compartilhado continuamente sem consequências.

Um comprador deve perguntar sobre uso justo, limitação, limites de DDoS, restrições de porta, política de correio e o que acontece quando o tráfego afeta os vizinhos.

A tabela de planos também aponta para a economia da hospedagem. O plano KRILL oferece 1 vCPU, 2 GB de RAM e 10 GB NVMe por 1 EUR por mês. Mesmo em escala, esse preço deixa pouco espaço para intervenção manual cara. Um ticket de suporte que leva uma hora pode exceder vários meses de receita bruta desse cliente. Isso não significa que o suporte será ruim. Significa que o serviço deve ser padronizado, automatizado e rigoroso em seu escopo para ser sustentável. Clientes com necessidades incomuns não devem presumir que engenharia personalizada está incluída em um plano VPS econômico, a menos que seja explicitamente vendida.

As superfícies de conta públicas da Eternity reforçam essa forma de autoatendimento. etyCloud parece apresentar pedido de servidor, tickets, faturas, status do servidor e campos de configuração. O ponto de pagamento é separado em checkout.ety.one, e a superfície de identidade é separada em auth.ety.one. Este é um modelo padrão para um pequeno provedor tentando reduzir o trabalho manual. Dá aos clientes uma maneira familiar de comprar e gerenciar servidores. Também significa que a superfície de controle em si faz parte do serviço.

Se faturas, pagamentos ou acesso à conta falharem, as alterações e renovações de servidor podem ser afetadas mesmo que a VM subjacente ainda esteja ligada.

Para usuários de produção, o preço deve levar a uma hierarquização. Um servidor de 1 ou 4 EUR pode ser adequado para um nó de monitoramento, ambiente de teste, projeto pessoal, relé pequeno, carga de trabalho de pré-produção ou site de baixo risco. Não é automaticamente adequado para uma aplicação crítica de receita, a menos que o cliente tenha backups, monitoramento, DNS secundário, um segundo provedor, etapas de restauração testadas e aceitação clara de tempo de inatividade.

As evidências públicas da Eternity não justificam tratar o serviço como uma plataforma de fornecedor único para cargas de trabalho de alto valor sem garantias adicionais.

Para usuários preocupados com privacidade ou jurisdição, a linguagem "locais europeus" é atraente, mas incompleta. Whitewhale afirma que os locais são europeus e menciona RGPD/local europeu em seu texto comparativo. O registro de prefixo RIPE lista o país como UE. A própria empresa está registrada no Reino Unido, a residência do controlador segundo a Companies House é Geórgia, o campo de nacionalidade do diretor indica russo, e a borda web é Cloudflare. Nada disso é desqualificante por si só. Simplesmente significa que as questões de localização de dados e jurisdição devem ser precisas. Onde está o host da VM? Onde estão os backups?

Qual entidade legal contrata com o cliente? Qual lei rege o acordo? Quais subcontratados lidam com identidade, pagamento, filtragem DDoS, e-mail e suporte? As páginas públicas não respondem completamente a essas perguntas.

Abuso, confiança e o custo de ser barato

Todo provedor VPS barato deve gerenciar abusos. Servidores virtuais rápidos e baratos atraem tanto desenvolvedores legítimos quanto tráfego indesejado. Spam, ataques de credenciais, varredura, revenda de proxy, queixas de direitos autorais, fraude de pagamento e retaliação DDoS podem chegar mais rápido que a receita. A página Whitewhale enfatiza regras claras e uso legal. Os registros RIPE publicam contatos de abuso. Estes são bons sinais, mas o gerenciamento de abuso é outra área onde o registro público é enxuto.

O bloco de endereços é importante aqui. Um único /24 contém apenas 256 endereços IPv4. Se um pequeno número de clientes queimar a reputação com spam, avisos de malware ou abuso de proxy, os vizinhos inocentes podem herdar as consequências através de listas negras, pontuação de risco de pagamento, CAPTCHAs, suspeitas de geolocalização ou rejeição de correio. RPKI protege a validade da origem da rota; não protege a reputação IP. Cloudflare protege páginas web públicas; não torna o tráfego de origem do cliente confiável.

Um cliente usando a Eternity para cargas de trabalho sensíveis à saída deve testar a reputação IP e perguntar se substituições limpas estão disponíveis se um endereço já estiver danificado.

A estrutura de contato de abuso também é dividida. Os dados RDAP do AS mostram um contato de abuso associado a ety.one. O registro RDAP do prefixo para 82.41.36.0/24 lista um e-mail de abuso em abuseradar.com. Isso não é necessariamente um problema; provedores de recursos de endereços geralmente gerenciam contatos de abuso para blocos atribuídos. Mas significa que os relatórios podem passar pelas regras de processamento de mais de uma organização.

Clientes que hospedam conteúdo gerado por usuários, e-mail, proxies, servidores de jogos ou outros serviços sujeitos a reclamações devem entender qual decisão pode suspender um servidor, null-roterar um IP ou exigir informações do cliente.

A confiança também é moldada pela documentação. Ocentro de documentaçãoda Eternity fornece uma superfície de documentos legais públicos com opções de idioma, e o site raiz remete a documentos de contrato de assinatura. A presença de documentos é positiva. O comprador público ainda deve inspecionar o acordo exato usado no registro, pois os termos de pequenos provedores geralmente controlam as partes mais importantes do serviço: elegibilidade de reembolso, prazos de renovação, cancelamento, suspensão, uso proibido, retenção de dados, limites de responsabilidade, créditos SLA, jurisdição e direitos de rescisão. O risco operacional não é apenas se o servidor é rápido; é se o contrato dá ao provedor direitos amplos de suspender o serviço durante disputas ou eventos de abuso.

Provedores baratos também vivem sob pressão de fornecedores. Se as taxas upstream aumentarem, um contrato de prefixo mudar, o tráfego DDoS aumentar, ou uma instalação impuser regras de abuso mais rigorosas, um pequeno provedor pode precisar alterar rapidamente preços, locais, intervalos de endereços ou termos. Os clientes públicos devem monitorar sinais de continuidade: avisos de renovação, publicações de status, explicações públicas de incidentes, canais de suporte estáveis, histórico de roteamento limpo e linguagem de preços consistente. A pegada pública atual da Eternity é muito jovem para mostrar um padrão longo.

A melhor leitura das evidências

A leitura generosa é que a Eternity Cloud Limited é um jovem provedor real montando uma oferta de hospedagem europeia em torno de uma empresa britânica, seu próprio AS registrado, um IPv4 /24, serviços públicos atrás da Cloudflare, uma interface de hospedagem de autoatendimento e uma marca VPS econômica sob Whitewhale. A empresa registrou os objetos de rede pública necessários, originou uma rota válida, publicou contatos de suporte e faturamento e apresentou detalhes concretos de planos. Isso é mais do que uma página corporativa vaga.

A leitura conservadora é que a superfície operacional visível permanece estreita. Um único /24 atual e um único vizinho observado não mostram ampla resiliência de rede. As páginas públicas não identificam instalações, propriedade de hardware, diversidade upstream ativa, compromissos de reparo, garantias de backup ou um longo histórico de incidentes. A empresa é recém-constituída e estreitamente controlada, sem contas depositadas ainda. As superfícies web estão atrás da Cloudflare, o que melhora a apresentação pública, mas separa a disponibilidade do site da disponibilidade dos servidores dos clientes.

O bloco de endereços parece estar em uma cadeia mais ampla de recursos de endereços, o que é normal, mas adiciona outra dependência.

Ambas as leituras podem ser verdadeiras. A Eternity pode ser um pequeno provedor real e ainda assim permanecer uma aposta de infraestrutura mal documentada. Esta é a categoria certa para os compradores terem em mente. O serviço pode ser adequado para cargas de trabalho de baixo risco e sensíveis a custos. Pode ser útil como nó secundário, servidor de teste, pequeno host web, ambiente de laboratório, relé regional ou projeto que valoriza baixo custo mensal em vez de garantias formais empresariais.

Não deve ser tratado como uma plataforma resiliente comprovada simplesmente porque usa linguagem de nuvem, anuncia seu próprio ASN ou tem uma rota válida.

A melhoria mais importante seria a transparência operacional. A Eternity poderia melhorar materialmente sua garantia pública publicando uma página de status, uma lista de instalações ou metrôs, uma breve página de rede nomeando provedores upstream ativos, um plano IPv6, uma página looking-glass de rota, uma política de abuso, um documento SLA definindo medição e créditos, uma política de backup e snapshots e um arquivo de incidentes.

Também poderia esclarecer se Whitewhale é um produto da Eternity Cloud Limited, como etyCloud e Whitewhale estão relacionados contratualmente, qual entidade legal fatura os clientes e quais termos regem cada serviço. Nenhuma dessas divulgações requer revelar topologia sensível. Elas simplesmente reduziriam a ambiguidade.

Os clientes podem reduzir seu próprio risco sem esperar. Eles devem testar um servidor experimental antes de mover uma carga de trabalho, verificar latência e perda de pacotes das regiões relevantes, verificar o comportamento de e-mail de saída e risco de pagamento, confirmar o intervalo de IP atribuído, ler o acordo, testar a resposta de suporte, perguntar sobre backups, manter cópias fora do provedor, usar DNS independente, monitorar de fora da rede e manter um segundo provedor para sistemas críticos. Quanto mais baixo o preço mensal, mais importantes são essas verificações do lado do cliente.

Conclusão

A Eternity Cloud Limited deve ser considerada um operador de hospedagem emergente com uma pegada de rede pública real, mas pequena. A empresa existe em registros britânicos, anuncia serviços de hospedagem e nuvem através de suas próprias propriedades web, vincula sua marca à etyCloud e Whitewhale, possui AS201830 nos registros RIPE, origina 82.41.36.0/24 e tem RPKI válido para essa rota. Esses são fatos significativos.

Os mesmos fatos não provam que a Eternity controla capacidade física profunda, tem trânsito ao vivo redundante, mantém hardware sobressalente, opera em múltiplas instalações ou pode restaurar rapidamente o serviço ao cliente durante incidentes complexos. O produto vendido aos clientes não é apenas CPU, RAM e armazenamento NVMe. É uma cadeia de acesso a racks, contratos de fornecedores, política de trânsito, governança de endereços, gerenciamento DDoS, serviços de conta atrás da Cloudflare, caminhos de pagamento, documentação, tickets e mão de obra de reparo.

As evidências públicas mostram partes dessa cadeia e deixam outras partes não verificadas.

Isso torna a nota atual de evidências baixa, em vez de negativa. O provedor é visível, roteado e comercialmente presente. A incerteza não é se há uma pegada pública; a incerteza é se a pegada pública pode sustentar a resiliência implícita da palavra nuvem. Até que a Eternity publique mais detalhes operacionais ou construa um histórico público mais longo, os compradores devem tratá-la como uma opção de hospedagem econômica que pode ser útil no nível certo, e não como uma dependência de infraestrutura para confiar sem backups, monitoramento e um caminho de saída claro.