Resumo
- A Eternity Cloud Limited é uma nova empresa privada do Reino Unido com presença pública de hospedagem, um número AS ativo e uma rota IPv4 pequena, porém viável. Operfil oficial na Companies Houseregistra incorporação em 27 de outubro de 2025, status ativo, um endereço registrado em Londres e um código SIC de consultoria, em vez de uma classificação de instalações ou operadora.
- O site público da empresa direciona os usuários para as superfícies etyCloud, Whitewhale, identidade, checkout e documentos. Osite ety.onee osite etyClouddescrevem um serviço de nuvem ou hospedagem, enquanto aWhitewhaleanuncia planos VPS europeus, roteamento AS próprio, colocação em data center Tier-1, proteção DDoS e uma promessa de uptime de 99,9%.
- As evidências de rede são reais, mas limitadas. Oobjeto AS201830 da RIPEnomeia a Eternity Cloud Limited, oRIPEstatmostra um prefixo IPv4 /24 anunciado durante a janela de observação, e avalidaçã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 públicos de roteamento apontam para uma pegada de um prefixo, um único vizinho observado na visão AS atual, nenhum anúncio IPv6 visível, superfícies web e de conta protegidas pelo Cloudflare e nenhuma lista pública de instalações, histórico de manutenção ou registro de incidentes. Isso torna a Eternity um provedor de hospedagem pequeno plausível, não um operador de infraestrutura multisite comprovado.
Por que a Eternity é importante apesar de seu tamanho
Pequenas empresas de hospedagem podem parecer marginais visto de fora, porque seus registros legais são enxutos, seus sites são simples e suas tabelas de roteamento são pequenas. Isso não as torna irrelevantes. Um provedor VPS de baixo custo ainda pode estar no caminho 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 pode pagar para operar. A questão de infraestrutura não é se a Eternity Cloud Limited é grande o suficiente para se comparar com as maiores plataformas de nuvem.
É se um comprador pode entender o que realmente está sendo comprado quando a oferta diz nuvem, VPS, localizações europeias, ASN próprio, proteção DDoS e capacidade mensal barata.
O registro público dá uma resposta mista. A Eternity tem mais substância do que uma página de destino. A empresa do Reino Unido existe. O registro público da empresa nomeia aEternity Cloud Limitedcomo uma empresa privada limitada ativa. A RIPE conecta o nome da empresa e o endereço em Londres ao AS201830, e os dados públicos de roteamento mostram um prefixo IPv4 originado por esse AS. A superfície de serviço não é apenas uma página de logotipo: oetyCloudapresenta um ambiente de conta de hospedagem, e a páginaWhitewhalefornece nomes de planos, preços, tamanhos de recursos e alegações de rede.
O mesmo registro também mostra por que a empresa deve ser lida com cautela. A Eternity foi incorporada em 27 de outubro de 2025, portanto ainda não havia protocolado seu primeiro conjunto de contas no momento desta revisão. As primeiras contas vencem em 2027, de acordo com apágina de registros da Companies House. A declaração de capital visível no registro de incorporação é pequena. O escritório registrado é um endereço central de Londres frequentemente usado por muitas empresas, não uma evidência de um 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 endereço do escritório registrado. 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á localizado no substantivo de marketing. "Nuvem" é uma promessa comercial, mas o serviço ainda depende de racks específicos, upstreams, blocos de endereço, DNS, sistemas de identidade, sistemas de faturamento e mão de obra de suporte. Se um servidor falha, uma rota é retirada, um serviço de conta rejeita logins, um link de pagamento quebra, um evento DDoS aciona filtragem ou um bloco de endereço alugado precisa 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 provedor operando na borda 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 operadoras, propriedade de hardware, pessoal de reparo, prática de backup, transparência de incidentes ou garantias de migração. O resultado é uma empresa que pode ser significativa para demanda de hospedagem de baixo custo, enquanto ainda merece uma nota baixa de evidência de rede para garantia pública.
O registro da empresa diz: nova, ativa e estritamente controlada
O ponto de partida legal é direto. Operfil na Companies Houselista a Eternity Cloud Limited como número de empresa 16810688, uma empresa privada limitada ativa incorporada na Inglaterra e no País de Gales em 27 de outubro de 2025. Seu escritório registrado é 71-75 Shelton Street, Londres, WC2H 9JQ. O código SIC listado é 62020, "Atividades de consultoria em tecnologia da informação". O registro diz que as primeiras contas são para até 31 de outubro de 2026 e vencem em 27 de julho de 2027, com uma primeira declaração de confirmação vencendo em novembro de 2026.
Para um leitor de infraestrutura, essas entradas são menos sobre formalidade do que sobre maturidade. Um provedor pode começar a operar antes que suas primeiras contas sejam protocoladas, mas a ausência de contas significa que não há balanço público, faturamento registrado, passivos registrados ou visão auditada ou não auditada dos ativos por trás do serviço. Um cliente de capacidade hospedada, portanto, não pode usar o registro corporativo do Reino Unido para inferir o número de servidores, a escala de compromissos com fornecedores, o volume de receita, o nível de capital de giro ou a profundidade dos recursos de reparo.
O registro confirma a existência e o status. Não confirma a escala operacional.
O registro de controle é igualmente concentrado. Apágina de diretoreslista Mikhail Karlov como o diretor ativo, nomeado na data de incorporaçã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 remover diretores. A Companies House também registra uma data de verificação de identidade em novembro de 2026 para os registros de diretores e controladores.
O controle próximo é comum em empresas de hospedagem em estágio inicial. Pode tornar as decisões rápidas, manter os preços agressivos e reduzir a burocracia. Também pode criar risco de pessoa-chave. Se o roteamento, relacionamentos com fornecedores, disputas de faturamento, tratamento de abuso, recuperação de identidade e suporte ao cliente dependem de um pequeno grupo fundador, o serviço pode ser mais frágil do que a página de produto sugere. O registro público não mostra um conselho, uma equipe de gestão ou funcionários técnicos nomeados além da função NOC associada à empresa nos registros da RIPE.
Um comprador, portanto, tem que assumir que a continuidade depende fortemente de uma pequena camada humana, a menos que a Eternity publique divulgações operacionais mais fortes.
O escritório registrado também precisa de tratamento cuidadoso. A Shelton Street é um endereço de correspondência legal em Londres. Não deve ser lido como uma localização de hospedagem ou uma instalação de rede. Os registros da 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 de localizações europeias de data center, e os dados de roteamento apontam para relacionamentos upstream europeus, mas o endereço público da empresa em si não é evidência de servidores em Londres.
Esse é 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. A 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 o guarda-chuva Eternity/etyCloud/Whitewhale.
Nenhum desses registros, por si só, prova quanta capacidade física está implantada, como as janelas de reparo são tratadas, se há hardware sobressalente estocado ou como um cliente seria migrado durante uma disputa de fornecedor.
A superfície de serviço é um cluster, não uma página de produto única
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 registro. O texto da página pública e os ativos vinculam a marca ao 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 documentos em inglês e russo. Isso dá à marca mais estrutura do que uma página de placeholder, mas a estrutura ainda é compacta.
O siteetyCloudé a superfície direta de hospedagem em nuvem. Sua descrição na página pública diz em russo que o etyCloud fornece soluções de hospedagem confiáveis e rápidas para empresas e desenvolvedores. O título do site o enquadra como hospedagem acessível. Seu texto de aplicação mostra ações de conta de usuário, pedidos de servidor, faturas, tickets e detalhes do servidor, como processador, memória, armazenamento, localização, canal, tipo de armazenamento e preço. O site, portanto, é lido como um ambiente de controle de hospedagem em vez de um folheto corporativo geral.
Isso é importante porque um ambiente de controle é onde as promessas de nuvem se tornam promessas operacionais. Se um comprador pedir um servidor através do etyCloud, a experiência depende de identidade, criação de conta, geração de pagamento, manipulação 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 quanta automação há por trás, como as exceções são tratadas ou se a entrega do servidor é imediata, manual ou dependente de fornecedor.
A Whitewhale adiciona uma oferta comercial mais explícita. Suapágina em inglêschama a Whitewhale de provedor de nuvem em localizações europeias, descreve "ASN próprio AS201830", anuncia planos a partir de 1 EUR por mês e lista suporte em[email protected]e faturamento em[email protected]. Os cartões de plano incluem KRILL a 1 EUR mensais com 1 vCPU, 2 GB RAM e 10 GB NVMe, NARWHAL a 4 EUR mensais com 2 vCPU, 4 GB RAM e 40 GB NVMe, ORCA a 8 EUR mensais com 4 vCPU, 8 GB RAM e 80 GB NVMe, LEVIATHAN a 15 EUR mensais com 6 vCPU, 12 GB RAM e 160 GB NVMe, e um nível personalizado WHITEWHALE+ a partir de 25 EUR mensais. A página também anuncia tráfego ilimitado, uplinks compartilhados, proteção DDoS, localizações europeias e uptime de 99,9%.
A página da 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 de comparação da Whitewhale diz que os planos de entrada compartilham 500 Mbps, enquanto outro texto na página diz uplink de alta velocidade de 1-3 Gbps em todos os VPS.
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 cluster de produtos também separa várias funções que os clientes podem experimentar como um único serviço. A Eternity é a empresa do Reino Unido. ety.one é a marca e o 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á sob auth.ety.one, e a superfície de pagamento aparece sob checkout.ety.one. O centro de documentos está sob documents.ety.one. Na prática, uma interrupção do cliente pode surgir em qualquer uma dessas camadas. Um servidor pode continuar funcionando enquanto o portal da conta está indisponível.
O portal da conta pode estar acessível enquanto a faixa de IP roteada do cliente está degradada. 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, não como um sistema único.
É também onde o Cloudflare entra em cena. Os cabeçalhos HTTP para ety.one, cloud.ety.one, auth.ety.one, checkout.ety.one, documents.ety.one e Whitewhale mostram o Cloudflare na borda web, e o DNS público paraety.one,cloud.ety.oneewhitewhale.helpresolve para o espaço de endereço do Cloudflare. Essa é uma escolha normal e muitas vezes sensata para entrega web pública. Também significa que o caminho do site visível não é a mesma coisa que o caminho do servidor cliente AS201830. O Cloudflare pode mascarar a localização de origem, absorver alguns ataques de camada web e manter uma página de marketing ou conta acessível mesmo quando o prefixo roteado do provedor tem um problema diferente. A superfície web é evidência de apresentação de serviço, não prova de resiliência de computação back-end.
A rede roteada é real, mas limitada
A evidência mais forte de infraestrutura da Eternity está no registro de roteamento. Oobjeto aut-num da 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. Essas são redes substanciais de infraestrutura europeia, e sua aparição no registro de política se alinha com a afirmação da Whitewhale de hospedagem europeia e roteamento AS próprio.
Oregistro RDAP AS da RIPEtorna a conexão da empresa mais clara. Ele nomeia o handle AS201830, dá o nome ETERNITY-CLOUD-MNT, lista a Eternity Cloud Limited como a entidade registrante e mostra um contato NOC sob o nome Eternity Cloud. O endereço nesses objetos RIPE corresponde ao escritório registrado em Londres. O registro RDAP também lista um contato de abuso associado a[email protected]. Em conjunto, esses registros mostram uma identidade de rede registrada real, em vez de uma afirmação apenas de marketing.
A visibilidade de roteamento, no entanto, é menor do que a existência de um AS pode fazer parecer. Avisão geral do AS no RIPEstatrelata AS201830 como anunciado e nomeia o titular como Eternity Cloud Limited. Avisão de prefixos anunciados do RIPEstatmostra um prefixo IPv4 atual, 82.41.36.0/24, durante a janela de observação. Avisão de status de roteamento do RIPEstat para o ASmostra um prefixo IPv4 anunciado, 256 endereços IPv4, visibilidade total de IPv4 no conjunto de relatórios, nenhum espaço IPv6 anunciado nessa visão e um vizinho observado.
Isso é suficiente para dizer que a Eternity tem uma pegada roteada ativa. Não é suficiente para dizer que ela tem uma rede ampla. Um único /24 pode suportar serviço real ao cliente, especialmente para planos VPS pequenos, mas também cria concentração. Se o prefixo for filtrado, retirado, disputado, sequestrado, colocado na lista negra ou esgotado, há pouca evidência pública de pools de endereço alternativos. Se o número de vizinhos observados permanecer em um, a acessibilidade do cliente pode depender de um caminho upstream efetivo, mesmo que o registro de política liste mais de um provedor permitido.
Se nenhum IPv6 estiver visível, os clientes que precisam de serviço dual-stack têm que perguntar se o IPv6 está indisponível, não anunciado, fornecido através de outro caminho ou simplesmente não representado na visão pública atual.
O registro do prefixo adiciona outra camada. Avisão geral do prefixo do RIPEstat para 82.41.36.0/24identifica AS201830 como a origem anunciante. Oobjeto de rota da RIPEregistra a origem AS201830 para esse /24 e foi criado em 29 de janeiro de 2026. Avalidação RPKIrelata a origem como válida, com um ROA permitindo que AS201830 origine o /24 exato. Isso é 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 inválidos conflitantes.
A atribuição de endereço também carrega uma pista de dependência. Osdados whois da RIPE para 82.41.36.0/24e oregistro RDAP IPidentificam o netname NET-82-41-36-0-24, 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ço é público e roteado, mas o contexto de manutenção e geofeed aponta para uma cadeia de recursos de endereço além da própria Eternity. Isso é comum no mercado IPv4. Também é relevante para os clientes porque os acordos de recursos de endereço podem afetar a portabilidade, o tratamento de abuso, a geolocalização, a reputação e a continuidade se um relacionamento comercial mudar.
Os dados de caminho visível reforçam o quadro de dependência. Umaconsulta looking-glass do RIPEstat para 82.41.36.0/24mostra muitos coletores vendo caminhos que terminam através de AS16276 para AS201830. Isso se alinha com a política aut-num e sugere que OVH é um caminho upstream ativo importante para o prefixo anunciado. Não prova, por si só, a localização da instalação, capacidade upstream de reserva ou failover bem-sucedido para Hetzner. Um cliente deve tratar o caminho público como evidência de acessibilidade, não como prova de resiliência multioperadora.
Racks, trânsito e janelas de reparo são o produto oculto
A frase "capacidade hospedada" soa digital, mas é vendida a partir de camadas físicas e contratuais. Alguém tem que possuir ou alugar os servidores. Alguém tem que fornecer energia, refrigeração, cross-connects e mãos remotas. Alguém tem que transportar pacotes para o resto da internet. Alguém tem que manter registros de endereço, objetos de rota, RPKI e caixas de correio de abuso. Alguém tem que responder a tickets quando um servidor está inativo, mas o site ainda está no ar. As evidências públicas em torno da Eternity identificam algumas dessas camadas, mas deixam as partes mais operacionais sem nome.
A Whitewhale diz que sua infraestrutura funciona em localizações europeias e data centers de alto nível com energia e conectividade redundantes. Ela também anuncia proteção DDoS e um SLA de 99,9% de uptime. Essas são afirmações comercialmente significativas. Elas também precisam de detalhes antes de se tornarem garantia. Uma promessa de uptime de 99,9% pode significar muitas coisas dependendo se se aplica à disponibilidade de rede, energia do servidor, acesso ao painel de controle, uptime da 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 programada, ataques, configuração incorreta do cliente e falhas upstream.
As páginas públicas não nomeiam as instalações, provedores de rack ou cidades por trás da afirmação "localizações europeias". Elas não publicam uma página looking-glass sob a própria marca da Eternity, uma página de status de rede, um arquivo de incidentes, um calendário de manutenção, um route-map, uma lista de provedores de trânsito em produção, um guia de comunidades BGP, um parceiro de mitigação DDoS, uma meta de substituição de hardware ou uma promessa de retenção de backup. Alguns provedores pequenos 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 torna-se uma pergunta a fazer antes de confiar nele.
A primeira pergunta é onde a capacidade está fisicamente hospedada. Se os servidores estão em instalações da 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 provedor revende capacidade virtual de uma plataforma maior enquanto apresenta uma camada AS própria, 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 da RIPE lista entradas de política AS16276 e AS24940. A visão AS do RIPEstat mostra um vizinho observado. Os dados de looking-glass para o prefixo atual mostram fortemente caminhos AS16276. Isso não prova que AS24940 não está em uso, mas significa que a visão pública no momento da revisão não demonstra diversidade balanceada ativa.
Se um caminho voltado para OVH falhar, um comprador gostaria de saber se a rota pode se mover para Hetzner, se esse movimento é automático 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 se referem a netutils-mnt, informações de geofeed IPXO e uma organização de usuário final. Isso sugere um acordo de recurso de endereço onde os registros de mais de uma parte importam. Se a geolocalização estiver errada, relatórios de abuso forem maltratados, um prefixo desenvolver má reputação ou o contrato de endereço mudar, os clientes podem experimentar problemas que não são resolvidos simplesmente reiniciando um servidor.
Compradores de hospedagem de baixo custo 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 uma faixa de IP mal.
A quarta pergunta é o tempo de reparo. A interface etyCloud parece incluir tickets, faturas e detalhes do servidor. A Whitewhale publica endereços de e-mail de suporte e faturamento. O site raiz da Eternity publica informações de contato de suporte. Esses são canais de cliente necessários. Eles não são o mesmo que uma garantia de reparo publicada. Um provedor pequeno pode responder rapidamente, mas um comprador público não pode inferir equipe 24/7, pools de capacidade de reserva, direitos de escalonamento com upstreams ou comunicação pós-incidente apenas a partir de e-mails de contato.
A página da Whitewhale diz que o suporte é 24/7, mas os clientes ainda devem perguntar como as interrupções 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 IP alternativo ou migração de teste. As páginas públicas da Eternity não publicam portabilidade de backup, exportação de snapshot, 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 diga o contrário.
Cloudflare protege a porta da frente, não todos os servidores 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 do Cloudflare, e as respostas HTTP identificam o Cloudflare como o servidor na frente das páginas. O endpoint de autenticação sobauth.ety.oneretorna uma resposta protegida em vez de uma página de aplicação pública, enquantocheckout.ety.oneretorna uma resposta estilo aplicação na raiz. O centro de documentos sobdocuments.ety.onetambém é protegido pelo Cloudflare.
Esse arranjo é sensato para um provedor jovem. O Cloudflare pode absorver ataques web comuns, fornecer terminação TLS, armazenar em cache páginas públicas, melhorar a acessibilidade da página e reduzir a exposição de servidores de origem. Também pode fazer a marca parecer mais disponível do que a rede de computação subjacente durante alguns incidentes. Uma página de marketing pode estar acessível através do Cloudflare enquanto o VPS de um cliente em 82.41.36.0/24 está inacessível. Por outro lado, um servidor cliente ainda pode funcionar enquanto a superfície de autenticação ou checkout está degradada.
Para os clientes, essas são interrupções diferentes com remédios diferentes.
Essa distinção é frequentemente perdida na due diligence de provedores pequenos. 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 do Cloudflare. O caminho do servidor cliente, se atribuído a partir do prefixo roteado atual da Eternity, depende do AS201830, seu caminho upstream atual, o bloco de endereço, 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 de e-mail e manipulação de tickets. Essas camadas podem falhar independentemente.
O DNS público também mostra registros de roteamento de e-mail do Cloudflare para ety.one e Whitewhale. Isso é novamente normal, mas significa que o recebimento de e-mail para endereços de suporte e faturamento tem sua própria dependência de serviço. Se uma interrupção do cliente incluir incapacidade de receber ou enviar e-mail, a comunicação de suporte pode ser afetada por DNS, roteamento de e-mail, filtragem de spam, acesso à conta e resposta humana. Nada disso é único da Eternity. É a stack comum por trás de provedores de hospedagem pequenos. O risco é que o baixo preço mensal faça a stack parecer mais simples do que é.
Há também um ângulo de governança. As páginas públicas protegidas pelo 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ê marca, plano e checkout. O pesquisador de rede vê um AS, um prefixo IPv4 visível, RPKI válido e superfícies web Cloudflare. O meio ausente é a plataforma de produção: hypervisors, armazenamento, backups, contratos de instalação, failover de trânsito e prática de pessoal.
Um comprador sério não precisa de tudo isso publicado em uma página inicial, mas deve solicitar detalhes suficientes para corresponder ao 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 pretendido. Planos a partir de 1 EUR por mês não são ofertas de nuvem empresarial. São ofertas de VPS de baixo orçamento voltadas para desenvolvedores, pequenos projetos, experimentos e cargas de trabalho sensíveis a custos. Isso pode ser valioso. Muitos serviços de internet começam em máquinas virtuais baratas porque a alternativa não é um contrato de hiperescala; é não lançar.
A questão é o que um cliente abre mão nesse ponto de preço. Provedores de VPS de baixo custo geralmente dependem de alta utilização, uplinks compartilhados, controles de abuso rigorosos, fluxos de suporte simples e garantias personalizadas limitadas. A página da Whitewhale é aberta sobre largura de banda compartilhada nos cartões de plano, enquanto também anuncia tráfego ilimitado. "Ilimitado" neste contexto não deve ser lido como capacidade dedicada infinita.
Geralmente significa que não há limite fixo de transferência mensal 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 e-mail e o que acontece quando o tráfego afeta vizinhos.
A tabela de planos também aponta para a economia de hospedagem. O plano KRILL oferece 1 vCPU, 2 GB RAM e 10 GB NVMe por 1 EUR mensal. Mesmo em grande escala, esse preço deixa pouco espaço para intervenção manual cara. Um ticket de suporte que leva uma hora pode exceder muitos meses de receita bruta para esse cliente. Isso não significa que o suporte será ruim. Significa que o serviço deve ser padronizado, automatizado e rigoroso quanto ao escopo para ser sustentável. Clientes com necessidades incomuns não devem assumir que engenharia personalizada vem com um plano VPS de baixo orçamento, a menos que seja explicitamente vendida.
As superfícies de conta públicas da Eternity reforçam essa forma de autoatendimento. O etyCloud parece apresentar pedidos de servidor, tickets, faturas, status do servidor e campos de configuração. O endpoint de checkout é separado sob checkout.ety.one, e a superfície de identidade é separada sob auth.ety.one. Esse é um padrão comum para um provedor pequeno tentando reduzir o trabalho manual. Dá aos clientes uma maneira familiar de comprar e gerenciar servidores. Também significa que a própria superfície de controle se torna parte do serviço.
Se faturas, pagamentos ou acesso à conta falharem, as alterações e renovações do servidor podem ser afetadas mesmo quando a VM subjacente ainda está ligada.
Para usuários de produção, os preços devem levar à categorização. Um servidor de 1 EUR ou 4 EUR pode ser bom para um nó de monitoramento, ambiente de teste, projeto pessoal, relé pequeno, carga de trabalho de staging ou site de baixo risco. Não é automaticamente adequado para um aplicativo crítico 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 inatividade. As evidências públicas da Eternity não justificam tratar o serviço como uma plataforma de provedor único para cargas de trabalho de alto valor sem garantias adicionais.
Para usuários sensíveis à privacidade ou jurisdição, a linguagem "localizações europeias" é atraente, mas incompleta. A Whitewhale diz que as localizações são europeias e menciona GDPR/localização UE em seu texto de comparação. O registro de prefixo RIPE lista país UE. A própria empresa é registrada no Reino Unido, a residência do controlador na Companies House é Geórgia, o campo de nacionalidade do diretor diz russo e a borda web é Cloudflare. Nada disso é inerentemente desqualificante. Simplesmente significa que as perguntas sobre localização de dados e jurisdição devem ser precisas. Onde está o host VM? Onde estão os backups?
Qual entidade legal faz o contrato com o cliente? Qual lei rege o acordo? Quais subprocessadores lidam com identidade, pagamento, filtragem DDoS, e-mail e suporte? As páginas públicas não respondem totalmente a essas perguntas.
Abuso, confiança e o custo de ser barato
Qualquer provedor de VPS de baixo custo tem que gerenciar abuso. Servidores virtuais baratos e rápidos atraem desenvolvedores legítimos e tráfego indesejado igualmente. Spam, ataques de credenciais, varredura, revenda de proxy, reclamações de direitos autorais, fraude de pagamento e retaliação DDoS podem chegar mais rápido do que a receita. A página da Whitewhale enfatiza regras claras e uso legal. Os registros RIPE publicam contatos de abuso. Esses são bons sinais, mas o gerenciamento de abuso é outra área onde o registro público é enxuto.
O bloco de endereço é importante aqui. Um único /24 contém apenas 256 endereços IPv4. Se um pequeno número de clientes queimar a reputação através de spam, callbacks de malware ou abuso de proxy, vizinhos inocentes podem herdar as consequências através de lista negra, pontuação de risco de pagamento, CAPTCHAs, suspeita de geolocalização ou rejeição de e-mail. O RPKI protege a validade da origem da rota; não protege a reputação IP. O 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 a saída deve testar a reputação IP e perguntar se substitutos limpos estão disponíveis se um endereço já estiver danificado.
A estrutura de contato de abuso também é dividida. Os dados RDAP 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 sob abuseradar.com. Isso não é necessariamente um problema; provedores de recursos de endereço muitas vezes gerenciam contatos de abuso para blocos atribuídos. Mas significa que os relatórios podem passar pelas regras de manipulação de mais de uma organização.
Clientes que hospedam conteúdo gerado por usuário, e-mail, proxies, servidores de jogos ou outros serviços propensos a reclamações devem entender a decisão de quem pode suspender um servidor, null-route um IP ou exigir informações do cliente.
A confiança também é moldada pela documentação. Ocentro de documentosda Eternity fornece uma superfície de documentos legais públicos com opções de idioma, e o site raiz links para materiais de contrato de assinatura. A presença de documentos é positiva. O comprador público ainda precisa inspecionar o acordo exato usado no cadastro, porque os termos de provedores pequenos muitas vezes 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 amplos direitos de suspender o serviço durante disputas ou eventos de abuso.
Provedores de baixo custo 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 provedor pequeno pode precisar alterar preços, localizações, faixas de endereço ou termos rapidamente. Os clientes públicos devem ficar atentos a sinais de continuidade: avisos de renovação, postagens de status, explicações públicas de incidentes, canais de suporte estáveis, histórico de rota 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 provedor jovem e real que está montando uma oferta europeia de hospedagem em torno de uma empresa do Reino Unido, seu próprio AS registrado, um IPv4 /24, serviços públicos protegidos pelo Cloudflare, uma interface de hospedagem de autoatendimento e uma marca de VPS de baixo orçamento na 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 do plano. Isso é mais do que uma vaga página de empresa.
A leitura conservadora é que a superfície operacional visível permanece estreita. Um único /24 atual e um 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 registro de incidentes. A empresa é recém-incorporada e estritamente controlada, sem contas protocoladas ainda. As superfícies web são protegidas pelo Cloudflare, o que melhora a apresentação pública, mas separa a disponibilidade do site da disponibilidade dos servidores do cliente.
O bloco de endereço parece estar dentro de uma cadeia mais ampla de recursos de endereço, o que é normal, mas adiciona outra dependência.
Ambas as leituras podem ser verdadeiras. A Eternity pode ser um provedor pequeno real e ainda assim ser uma aposta de infraestrutura fracamente evidenciada. Essa é a categoria certa para os compradores terem em mente. O serviço pode atender a 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 sobre garantias formais empresariais. Não deve ser tratado como uma plataforma resiliente comprovada apenas porque usa linguagem de nuvem, anuncia um ASN próprio ou tem uma rota válida.
A atualização 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ô, uma página de rede curta nomeando upstreams ativos, um plano IPv6, uma página de looking-glass de rota, uma política de abuso, um documento SLA que define medição e créditos, uma política de backup e snapshot e um arquivo de incidentes. Ela também poderia esclarecer se a Whitewhale é um produto da Eternity Cloud Limited, como etyCloud e Whitewhale se relacionam 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 de avaliação antes de mover uma carga de trabalho, verificar latência e perda de pacotes de regiões relevantes, verificar o comportamento de e-mail de saída e risco de pagamento, confirmar a faixa de IP atribuída, 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 menor o preço mensal, mais esses controles do lado do cliente importam.
Conclusão
A Eternity Cloud Limited deve ser lida como um operador de hospedagem emergente com uma pegada de rede pública real, mas pequena. A empresa existe nos registros do Reino Unido, anuncia serviços de hospedagem e nuvem através de suas próprias propriedades web, conecta sua marca ao 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 ativo redundante, mantém hardware sobressalente, opera em múltiplas instalações ou pode restaurar o serviço do cliente rapidamente durante incidentes complexos. O produto vendido aos clientes não é apenas CPU, RAM e armazenamento NVMe. É uma cadeia de acesso a rack, contratos de fornecedores, política de trânsito, governança de endereço, tratamento DDoS, serviços de conta protegidos pelo 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 faz com que a nota atual de evidência seja fraca, em vez de negativa. O provedor é visível, roteado e comercialmente presente. A incerteza não é se há alguma pegada pública; a incerteza é se a pegada pública pode sustentar a resiliência implícita pela 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 de baixo orçamento que pode ser útil no nível certo, não como uma dependência de infraestrutura em que confiar sem backups, monitoramento e um caminho de saída claro.