Contrato antes da nuvem: rede visível da Ehost e especificações

Resumo

A EHOST SOFTWARE COMPANY LIMITED é apoiada por identificadores legais, de contato e de rede consistentes: os nomes do site operacional Công ty TNHH Phần Mềm Ehost e código fiscal 0312916711, enquanto registros públicos de roteamento identificam AS135920 como EHOST-VN e mostram cinco prefixos IPv4/24originados.
A pegada de roteamento é real, mas estreita. As fontes BGP revisadas mostram 1.280 endereços IPv4 originados, nenhum espaço IPv6 originado e uma adjacência upstream observada através de AS135905. Isso não prova serviço pobre ou single-homing físico, mas torna as questões de diversidade de rota, failover e IPv6 específico do produto relevantes.
As superfícies de vendas públicas da Ehost não fornecem uma especificação de produto estável. O mesmo rótulo Cloud 1G de 250.000 dong é descrito de forma diferente na página de marketing e no portal de faturamento, e as ofertas de colocation pública e checkout também divergem. Um formulário de pedido assinado deve, portanto, definir os termos autoritativos de CPU, memória, armazenamento, IOPS, largura de banda, localização, backup e suporte.
As alegações de backup, segurança e suporte precisam do mesmo tratamento. A Ehost anuncia backups diários ou semanais, firewalls físicos, AntiDDoS, suporte 24/7 e uma resposta de cinco minutos em alguns produtos, mas não divulga publicamente um design de recuperação completo, matriz de gravidade, cronograma de créditos de serviço, arquivo de incidentes, fluxo de trabalho de abuso ou escopo de garantia independente.
O provedor pode atender clientes que valorizam faturamento em vietnamita, suporte humano direto, ajuda na migração e um cardápio que abrange hospedagem compartilhada, nuvem, servidores dedicados, colocation, backup e proteção DDoS. Compradores com requisitos rigorosos de continuidade, conformidade ou portabilidade devem realizar uma prova de serviço e negociar uma saída executável antes de mover a produção.

Um servidor de 250.000 dong com duas respostas

Comece com o menor pacote cloud da Ehost. Na página públicaCloud Server, “EHOST 1G” custa 250.000 dong vietnamitas por mês e é descrito como dois núcleos de CPU, 2 GB de RAM, 30 GB de armazenamento SSD e uma conexão de rede de 100 Mbps. A página diz que todos os planos cloud recebem pelo menos 2.000 IOPS de armazenamento. Na página de pedido ativaSSD Cloud Serverda Ehost, “Cloud 1G” também começa em 250.000 dong por mês, mas a especificação exibida é um núcleo de CPU, 2 GB de RAM, 20 GB de armazenamento SSD, 200 Mbps de rede e 10.000 IOPS.

Nenhuma das páginas é obscura. Uma é a explicação voltada para o cliente do serviço; a outra é o sistema através do qual um comprador é convidado a pedi-lo. No entanto, elas descrevem unidades de computação materialmente diferentes. A discrepância não se limita ao menor plano. A oferta pública Cloud 2G lista dois núcleos, 4 GB de RAM e 40 GB de armazenamento; a versão no checkout lista dois núcleos, 2 GB de RAM e 40 GB. Os pacotes mais altos também diferem em memória e disco. Uma categoria de faturamento separada,SSD Cloud Server C6, apresenta outra geração de planos com nomes semelhantes, incluindo um Cloud 1G de 350.000 dong com dois núcleos, 2 GB de RAM, 30 GB de armazenamento, 200 Mbps e 50.000 IOPS.

Isso não prova que os clientes são provisionados incorretamente. Um catálogo pode conter uma categoria legada, um pool de hardware mais novo, uma página de destino desatualizada ou uma configuração esclarecida durante as vendas. Isso prova que o registro público não pode responder à pergunta de aquisição mais elementar: qual especificação se torna a obrigação quando o pagamento é feito?

Para um fornecedor de infraestrutura, isso não é um pequeno erro de publicação. A alocação de CPU afeta a taxa de transferência do aplicativo. A memória pode determinar se um banco de dados permanece residente ou troca. O tamanho do disco afeta a viabilidade da migração. IOPS pode alterar o comportamento de cargas de trabalho transacionais por uma ordem de magnitude. Uma taxa de rede pode ser um teto de porta, uma taxa comprometida, um perfil compartilhado ou um limite de burst. Cada variação pode alterar o desempenho e o custo total.

O primeiro controle em uma compra da Ehost deve, portanto, ser documental. O orçamento, o formulário de pedido ou o contrato devem identificar a família de produtos e a geração exatas; a contagem de vCPUs e o modelo de escalonamento; a memória garantida; o armazenamento utilizável; o meio de armazenamento; os IOPS mínimo e de burst; a largura de banda doméstica e internacional; os limites de transferência; a alocação de IP público; a localização; a imagem do sistema operacional; o escopo de gerenciamento; a inclusão de backup; a taxa de restauração; os impostos; e o prazo de renovação.

O comprador deve preservar esse documento juntamente com a fatura e a evidência de provisionamento inicial.

A tese central desta revisão decorre desses dois cartões Cloud 1G. A infraestrutura da Ehost não é adequadamente descrita pelo nome da marca, pelo preço mensal ou pela palavra “cloud”. Seu produto real começa onde as partes reconciliam a página de vendas, o portal de faturamento e o serviço que é realmente entregue.

A empresa exata por trás das telas

A fronteira da entidade é excepcionalmente importante porque “Ehost” aparece como uma marca, um domínio, um portal de suporte, um serviço AntiDDoS e uma rede registrada. A empresa examinada aqui éEHOST SOFTWARE COMPANY LIMITED, em vietnamitaCông ty TNHH Phần Mềm Ehost, com código fiscal0312916711. A página decontatoda Ehost fornece o nome legal, número de registro, um endereço na Cidade de Ho Chi Minh em 147/25 An Dương Vương, Bình Tân, telefone 0938-227-199 e um endereço de contato@ehost.vn. O rodapé diz que o registro de negócios foi emitido em 9 de setembro de 2014.

Umagregador de registros fiscais vietnamita de terceirosassocia independentemente o mesmo código fiscal à EHOST SOFTWARE COMPANY LIMITED, o mesmo endereço, uma data de operação de 9 de setembro de 2014 e o representante Nguyễn Thanh Tâm. Esse registro é uma corroboração útil, não um substituto para uma extração recente do registro oficial de empresas do Vietnã. Seu status e classificações do setor devem ser tratados como a representação datada do agregador dos registros públicos.

A identidade de rede fornece uma verificação de continuidade separada. OBGP.toolsreproduz dados de registro originados pela APNIC para AS135920:EHOST-VN, descrito como Ehost software company limited, país Vietnã, mantido através de VNNIC. O registro foi modificado em janeiro de 2026. A página AS135920 doIPinfotambém classifica a rede como hospedagem e a associa ao mesmo nome da empresa.

Esses links apoiam uma conclusão honesta: a empresa legal, a superfície de vendas ativaehost.vn, a superfície de faturamento e suportesecure.ehost.vne AS135920 pertencem a uma pegada operacional coerente. Eles não provam que todo serviço anunciado em todo domínio relacionado é de propriedade, operado ou garantido pela empresa. O IPinfo, por exemplo, listaehost.com.vncomo o domínio do ASN, enquanto o site operacional atual revisado aqui éehost.vn; o primeiro não produziu uma página utilizável durante esta pesquisa. Isso é uma questão de continuidade de domínio para a empresa, não motivo para dividir ou mesclar entidades.

A mesma cautela se aplica ao AntiDDoS. A Ehost vincula diretamente aoAntiddos.vn, e sua página cloud diz que os clientes podem integrar esse serviço. O site AntiDDoS se apresenta como uma rede de mitigação vietnamita multinó fundada em 2015. As páginas públicas revisadas aqui não estabelecem uma identidade corporativa separada ou cadeia contratual suficiente para determinar se o Antiddos.vn é uma divisão, produto, afiliada ou parceiro comercial da EHOST SOFTWARE COMPANY LIMITED. Um comprador deve tornar a parte contratante explícita, em vez de inferi-la a partir de cross-linking.

A identidade exata importa no momento da falha. A entidade que recebe o pagamento deve ser a entidade obrigada a fornecer o serviço, proteger os dados, notificar incidentes, devolver equipamentos ou exportações e pagar qualquer reembolso ou crédito de serviço. Se um operador de data center, licenciante de software, serviço de mitigação ou operadora de rede executar parte do serviço, o cliente precisa saber se a Ehost permanece responsável por essa dependência ou apenas a revende.

O que o AS135920 prova — e o que não prova

O AS135920 é a evidência independente mais forte de que a Ehost opera mais do que um folheto e uma vitrine de revendedor. Na visão congelada do BGP público, o sistema autônomo origina cinco prefixos IPv4/24:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24e103.63.215.0/24. Isso é 1.280 endereços IPv4. Tanto oBGP.toolsquanto oIPinfomostram os prefixos como cobertos por autorizações de origem de rota válidas. A tabela de validação de origem de rota do Vietnã do APNIC Labsrelata 100% de cobertura válida para a população de endereços EHOST-VN medida.

Isso é evidência operacional significativa. A Ehost possui recursos numéricos visíveis no sistema de roteamento global. Múltiplos endereços respondem a sondas independentes, e o IPinfo relata centenas de domínios através de endereços no ASN. A pegada é consistente com atividade de hospedagem, em vez de um invólucro legal que apenas comercializa a plataforma de outra pessoa.

A validade RPKI também é um controle real. Permite que validadores de rota verifiquem criptograficamente que o AS135920 está autorizado a originar os prefixos cobertos. O relatório de recursos de internet de 2024 da VNNIC trata RPKI e IPv6 como partes importantes do desenvolvimento de recursos de internet do Vietnã. As autorizações de origem válidas da Ehost reduzem uma classe de erro de origem de rota ou risco de sequestro.

A evidência para por aí. O RPKI não mostra que a Ehost filtra rotas inválidas recebidas de outros, protege aplicativos do cliente, mantém roteadores redundantes ou pode sobreviver a uma falha de operadora. Não diz nada sobre volume de tráfego, capacidade do servidor, energia, refrigeração, capacidade de scrubbing DDoS, qualidade de backup ou número de clientes. Uma origem de cinco prefixos pode suportar um host especializado bem administrado ou um frágil; a tabela de roteamento não decide entre eles.

A conectividade visível é mais cautelosa. O BGP.tools lista um upstream, AS135905, descrito como Vietnam P&T. A visão independente doCIDR Reporttambém vê uma adjacência upstream e nenhum espaço de downstream. O IPinfo também lista um upstream e um peer, ambos AS135905. Os rótulos de relacionamento variam por fonte de dados, mas a observação consistente é uma rede adjacente externamente visível que carrega as rotas do AS135920 nas visualizações revisadas.

Isso não deve ser traduzido em uma alegação de que cada rack da Ehost tem um cabo físico ou que cada produto é single-homed. A Ehost anuncia colocation em várias marcas de data center, e pode usar endereços atribuídos pelo provedor, interconexões privadas, serviços de Camada 2, mitigação DDoS remota ou rotas não visíveis como adjacências AS separadas. Os coletores BGP públicos também podem perder relacionamentos privados ou seletivos.

Isso cria um teste de aquisição. Se um serviço é vendido como multi-operadora ou multi-data center, a Ehost deve mostrar como o tráfego do cliente sobrevive à perda do AS135905, do roteador de borda relevante, do site de serviço e do caminho para a plataforma de mitigação. A evidência pode incluir um diagrama de arquitetura, sessões BGP atuais, política de rota, resultados de looking-glass, registros de failover e um teste controlado. “Vários data centers” é uma declaração de instalação; “diversidade de alcance de internet” é uma declaração de roteamento. Um não entrega automaticamente o outro.

O IPv6 é a outra lacuna visível. As fontes de roteamento revisadas mostramzero prefixos IPv6 originadospara AS135920. Isso não prova que a Ehost não oferece IPv6 em lugar nenhum: um cliente pode receber IPv6 de uma instalação ou ASN upstream. Isso significa que um comprador não pode inferir serviço dual-stack nativo do próprio sistema autônomo da Ehost. Perguntas específicas do produto devem cobrir tamanho de alocação IPv6, roteamento, DNS reverso, firewall, tratamento DDoS, monitoramento e paridade com suporte IPv4. Em 2026, “podemos adicionar depois” é um compromisso de ciclo de vida, não uma resposta técnica.

Um catálogo de diferentes modelos de responsabilidade

A Ehost não está vendendo um modelo de infraestrutura. Seu menu público abrange hospedagem compartilhada, hospedagem de e-mail, máquinas virtuais, servidores dedicados, servidores de jogo, colocation, backup, armazenamento estilo objeto, cache, corretagem de CDN, licenças de painel de controle, certificados e proteção DDoS. Cada um move uma parte diferente da pilha operacional entre provedor e cliente.

Nahospedagem compartilhada pessoal, a Ehost diz que a plataforma fornece cPanel, SSL, armazenamento SSD, uma camada AntiDDoS básica e backups semanais. O cliente gerencia principalmente código do site, conteúdo, contas e atualizações de aplicativos, enquanto depende da Ehost para o servidor compartilhado, painel de controle, rede e isolamento. A página dehospedagem empresarialadiciona um IP público dedicado, cache Redis e alegações de separação de recursos. Esse é um serviço compartilhado de maior controle, não equivalente a um servidor virtual.

A cloud transfere mais responsabilidade para o cliente. A página pública da Ehost diz que usa OpenStack, fornece uma máquina virtual, permite que os clientes adicionem CPU, memória e disco, e pode parar o servidor por dois a cinco minutos durante uma atualização. A menos que um termo de serviço gerenciado separado se aplique, o comprador deve presumir que o hardening do sistema operacional, a aplicação de patches, a operação do banco de dados, o gerenciamento de identidade e o monitoramento da carga de trabalho permanecem deveres do cliente. As páginas públicas não rotulam claramente os planos cloud padrão como gerenciados ou não gerenciados.

Os servidores dedicados transferem a exclusividade de hardware para o comprador, mas não necessariamente a propriedade do hardware. A página deservidores dedicados 2026da Ehost lista configurações mensais de 5,5 milhões a 12 milhões de dong, com processadores Intel Xeon, 128 ou 256 GB de RAM, armazenamento SSD ou NVMe, um endereço IP e largura de banda de 100 ou 200 Mbps. O comprador evita contenção de computação de vizinho barulhento, mas permanece dependente da Ehost para a máquina, rack, energia, caminho de operadora, mão remota e processo de substituição.

A colocation é diferente novamente. O cliente possui ou controla o servidor físico e aluga espaço no rack, energia e conectividade. A Ehost diz que os clientes podem entrar no data center 24 horas por dia após pré-registro e podem usar KVM remoto. Neste modelo, a Ehost pode ter menos controle sobre o servidor e mais responsabilidade pela coordenação de acesso, energia, cross-connects, roteamento e assistência prática. Uma matriz de falhas deve separar hardware do cliente, infraestrutura da instalação, rede da Ehost e operadora upstream.

A páginaECDNdiz que a Ehost coopera com provedores de CDN vietnamitas e internacionais, em vez de descrever uma rede de entrega de propriedade integral. Isso pode ser comercialmente útil: a Ehost pode atuar como integradora local e contato de faturamento. Também significa que locais de cache, logs, comportamento de purga, tratamento de dados, responsabilidade por incidentes e saída dependem do provedor subjacente não nomeado e do design específico do pedido.

A páginaeStoragedescreve “vStorage” como uma tecnologia de armazenamento de objetos desenvolvida pela Ehost para mídia, documentos, logs e conteúdo estático, e diz que os dados são armazenados permanentemente e sempre com backup. A página não publica uma especificação de API, modelo de consistência, meta de durabilidade, esquema de erasure-coding ou replicação, comportamento de exclusão, mapa de região, preço de egresso ou nível de serviço. “Armazenamento de objetos” identifica uma classe de serviço, não arquitetura suficiente para uma decisão de dados duráveis.

A amplitude da Ehost é, portanto, tanto uma vantagem quanto um ônus de diligência. Um cliente pode comprar vários serviços adjacentes de um provedor local e reduzir a coordenação de fornecedores. Mas o limite de responsabilidade muda cada vez que o cliente passa de hospedagem compartilhada para cloud, cloud para hardware dedicado, ou de uma rede de origem Ehost para um CDN de terceiros ou caminho de data center.

OpenStack é uma lista de componentes, não um resultado de disponibilidade

A Ehost diz que suas máquinas virtuais rodam em OpenStack. Isso é tecnicamente específico o suficiente para ser útil, mas não específico o suficiente para estabelecer resiliência. O guia oficial dearquitetura lógica do OpenStackdescreve uma cloud como um conjunto de serviços independentes unidos por APIs e um serviço de identidade comum. Por trás das interfaces estão bancos de dados, filas de mensagens e processos de serviço para computação, rede, imagens e armazenamento. OpenStack é uma estrutura operacional cujo resultado depende de como essas partes são implantadas e mantidas.

Para um comprador, a primeira pergunta é qual versão do OpenStack e conjunto de serviços a Ehost opera. A resposta afeta o status de suporte, atualizações, drivers, correções de segurança e comportamento da API. A página pública do produto não identifica a versão, o hipervisor de computação, o backend de armazenamento, o design de rede, as zonas de disponibilidade, a política de migração ao vivo ou a API acessível ao cliente.

A segunda pergunta é o isolamento de falhas. O próprio guia de design dealta disponibilidade do OpenStackdistingue o plano de dados que mantém instâncias, redes e armazenamento em execução do plano de controle que realiza operações de gerenciamento. Ele enfatiza serviços redundantes, balanceadores de carga, bancos de dados, filas de mensagens, switches, rotas e energia. Simplesmente instalar o OpenStack não elimina pontos únicos de falha; os operadores precisam projetá-los para fora.

A Ehost diz que sua cloud usa alta disponibilidade e pode recuperar um servidor em outro sistema. Essa é uma afirmação da empresa sobre um resultado. Para avaliá-la, um comprador deve perguntar o que acontece em várias falhas separadas:

Se um host de computação falhar, a máquina virtual reinicia automaticamente, e quanto tempo leva a detecção e reinicialização?
Se o armazenamento compartilhado falhar, os volumes são replicados entre domínios de falha independentes ou apenas protegidos por RAID dentro de um sistema?
Se um controlador ou fila de mensagens falhar, as máquinas existentes continuam enquanto as operações de gerenciamento param?
Se um switch top-of-rack ou core falhar, existe um caminho fisicamente diverso?
Se um site falhar, um cliente pode ser restaurado em outro site a partir de uma cópia independente?
Se a própria atualização do OpenStack falhar, qual é o processo de rollback e notificação ao cliente?

Essas perguntas importam porque a reivindicação pública de uptime de 99,5% é relativamente permissiva. Se aplicada continuamente, 99,5% de disponibilidade permite cerca de 3 horas e 36 minutos de inatividade em um mês de 30 dias, ou aproximadamente 43 horas e 48 minutos em um ano de 365 dias. Esse cálculo não é uma declaração sobre o desempenho real da Ehost. Mostra por que o período de medição, exclusões, tratamento de manutenção, fonte de monitoramento e remédio importam tanto quanto a porcentagem.

Há também um sinal de atualização no texto do produto. A Ehost diz que alterar CPU, memória, disco ou rede pode exigir um desligamento de dois a cinco minutos. Isso sugere que pelo menos algum redimensionamento é uma interrupção, em vez de uma operação ao vivo transparente. Um cliente que planeja escalonamento vertical durante períodos de pico deve testá-lo e perguntar se a expansão de armazenamento, as alterações de tipo de instância e a manutenção do host seguem o mesmo caminho.

A conclusão útil não é nem “OpenStack não é confiável” nem “OpenStack garante cloud”. É que a Ehost nomeou uma base técnica plausível, enquanto deixou as escolhas de implantação que determinam o risco do cliente amplamente fora do registro público.

A jornada do cliente atravessa três planos de controle

Um cliente da Ehost passa por três planos de controle distintos: comercial, infraestrutura e aplicação. Os problemas geralmente ocorrem onde a responsabilidade passa entre eles.

A jornada comercial começa nosite principal da Ehost, onde as páginas de produto apresentam pacotes e preços mensais. A Ehost diz que após o registro envia uma confirmação e aviso de custo, e que o serviço é criado após o pagamento. O cliente então chega aosecure.ehost.vn, um sistema de faturamento e suporte com categorias de produto, opções de exibição em VND e dólar americano, uma conta, formulários de pedido, tickets, anúncios, downloads e um link de status do servidor.

O conflito de especificações torna o handoff importante. Antes do pagamento, o comprador deve capturar a configuração do pedido selecionado e obter confirmação por escrito de que ela substitui o texto web inconsistente. Após o provisionamento, o cliente deve registrar o que realmente chegou: contagem de CPU virtual, memória, disco, IP público, rota, velocidade da interface, sistema operacional, licença de painel de controle e status de backup. Um pequeno script de aceitação pode comparar a máquina entregue com o pedido.

A jornada de infraestrutura começa então. Para um servidor cloud, a Ehost provisiona computação, armazenamento e rede; o cliente instala ou recebe um sistema operacional, cria credenciais de administrador, aponta DNS e implanta um aplicativo. Para hospedagem compartilhada, a Ehost expõe um painel de controle e o cliente move arquivos do site, bancos de dados, certificados e configurações de e-mail. Para colocation, o cliente deve organizar o acesso à instalação, instalação do rack, energia, endereçamento IP e administração remota.

A migração não é uma tarefa única. O site principal da Ehost anuncia conselhos gratuitos e assistência na transferência de dados para clientes que usam seus serviços. Uma migração de produção ainda precisa de um inventário de origem, cópia de dados, estratégia de DNS, tratamento de certificados, teste de fluxo de e-mail, janela de congelamento de aplicativo, verificação de integridade e rollback. Se os endereços IP mudarem, listas de permissões, provedores de pagamento, APIs de terceiros e regras de segurança podem precisar de atualizações.

Se o e-mail mudar, a reputação do remetente e registros DNS como SPF, DKIM e DMARC tornam-se parte da aceitação.

O plano de controle da aplicação permanece em grande parte com o cliente. Uma máquina virtual pode estar saudável enquanto o aplicativo está inativo devido a uma implantação falha, disco cheio, certificado expirado ou bloqueio de banco de dados. A base de conhecimento da Ehost inclui artigos sobre discos cheios e erros de certificado, o que é um conteúdo de suporte útil, mas também ilustra o limite compartilhado: o provedor pode explicar um sintoma sem possuir todas as decisões de carga de trabalho.

As operações devem, portanto, atribuir responsabilidades nomeadas. A Ehost pode possuir o hardware físico, virtualização, rede de borda e backups da plataforma. O cliente pode possuir sistemas operacionais, aplicativos, contas e classificação de dados. Um terceiro pode possuir a licença do painel de controle, CDN, autoridade certificadora, registro de domínio ou scrubbing DDoS. Durante um incidente, o ticket deve alcançar a parte que pode realmente agir.

O passo comercial final é a renovação ou saída. As páginas públicas expõem preços mensais, mas alguns produtos exigem mínimos de vários meses. O portal de faturamento mostra períodos de três meses para algumas ofertas de hospedagem, enquanto as licenças DirectAdmin são exibidas com mínimos de seis meses. Os compradores não devem confundir um preço unitário mensal com um direito de rescisão mês a mês.

O preço é transparente somente após a especificação estar estável

A Ehost publica mais preços do que muitos fornecedores de infraestrutura. Isso é útil. Uma pequena empresa pode ver que a hospedagem compartilhada começa em 50.000 dong por mês, hospedagem empresarial em 300.000, cloud em 250.000, backup em 95.000, servidores dedicados em 5,5 milhões e colocation público em 1,8 milhões. Os complementos têm preços visíveis: CPU extra, memória, disco e IPv4; armazenamento extra de hospedagem, domínio ou IP; espaço em rack, energia e upgrades de rede.

Os números revelam o design econômico da Ehost. A hospedagem compartilhada distribui um servidor e operação de suporte por muitos clientes. Os pacotes cloud medem um pacote de capacidade de computação, memória, armazenamento e rede. Servidores dedicados cobram por hardware exclusivo. A colocation cobra por rack, energia e conectividade escassos. O backup cobra principalmente pela capacidade armazenada. Licenças e certificados adicionam software de terceiros ou serviços de confiança.

No entanto, o preço publicado não é o mesmo que preço confiável. Acategoria de pedido de hospedagem empresarialcontém uma anomalia impressionante: “Business-02” é exibido a 1,35 bilhão de dong por três meses, enquanto pacotes vizinhos estão na casa das centenas de milhares. A mesma página anuncia versões legadas de PHP e MariaDB. Seria irracional tratar o valor bilionário como a tarifa pretendida da Ehost sem confirmação; é melhor entendido como evidência de que a vitrine pode conter inconsistências de entrada de dados ou ciclo de vida.

A colocation mostra um problema de reconciliação mais amplo. A página públicacolocationlista pacotes 1U na VNPT Data, Viettel IDC e CMC por 3,2 milhões, 2,8 milhões e 1,8 milhões de dong por mês, geralmente com 200 Mbps de rede doméstica e 30 Mbps de largura de banda internacional compartilhada. Acategoria de colocation do portal de faturamentolista ODS, Viettel IDC e VNPT Tân Thuận a 1,3 milhão ou 1,4 milhão de dong, com portas de 100 Mbps e largura de banda internacional de quatro ou dez Mbps. As localizações, capacidades e preços não são equivalentes.

Pode haver uma explicação legítima: diferentes gerações de rack, promoções, subsídios de energia, períodos de compromisso, ofertas legadas ou rotas para o mercado. As páginas não a fornecem. Um comprador comparando apenas o número mensal principal pode, portanto, comprar uma classe de serviço diferente da assumida.

O custo total deve incluir pelo menos:

migração inicial, configuração do sistema operacional e validação do aplicativo;
VAT e quaisquer outros encargos aplicáveis;
compromisso mínimo e termos de renovação;
IPv4 público, largura de banda, tráfego internacional e opções DDoS;
painel de controle, Windows, banco de dados ou outras licenças de software;
capacidade de backup, retenção e encargos de restauração;
suporte gerenciado ou trabalho de mão remota;
substituição de hardware ou tempo de inatividade de upgrade;
domínio, certificado e dependências de e-mail;
exportação de dados, transferência e assistência de transição na saída.

“Largura de banda ilimitada” também precisa de uma definição. Várias páginas da Ehost usam o termo enquanto publicam separadamente taxas de porta ou largura de banda internacional. Ilimitado pode razoavelmente significar nenhum encargo de transferência baseado em uso, não rendimento infinito ou um circuito dedicado sem contenção. O contrato deve distinguir velocidade da porta, taxa de informação comprometida, comportamento de burst, política de uso justo e caminhos doméstico versus internacional.

A Ehost ainda pode ser competitiva em preço após cada termo ser esclarecido. O registro público não é suficiente para calcular margem, oversubscription ou custo comparável contra concorrentes. É suficiente para mostrar que a comparação de preços deve começar após a reconciliação do produto, não antes.

Backup é uma promessa com dois períodos de retenção

O backup é onde o material público da Ehost é mais útil e mais contraditório. A página cloud primeiro diz que toda a cloud é copiada diariamente e as cópias são retidas por pelo menos sete dias. Nas notas do plano, diz “Full Backup Daily” retém os quatorze dias mais recentes e cobra 500.000 dong por restauração. Ambas as declarações aparecem na mesma página.

A hospedagem compartilhada segue outra política. As páginas pessoal e empresarial dizem que os dados são triplicados em tempo real e copiados semanalmente, com backups retidos por dois meses. Um serviço separado deCloud Backupvende armazenamento de 10 GB a 100 GB e diz que pode fazer backup de um disco inteiro para que um sistema operacional e aplicativos possam ser movidos para hardware de substituição. Ele anuncia suporte técnico 24/7/365 e pagamento mensal.

Estes podem ser camadas distintas: replicação da plataforma, backup de serviço incluído e backup comprado pelo cliente. Eles devem ser distintos. A triplicação em tempo real pode proteger contra uma falha de disco enquanto reproduz instantaneamente a exclusão de um cliente ou dados criptografados por ransomware. Um snapshot da plataforma pode ajudar a Ehost a recuperar a infraestrutura, sendo inadequado para restauração granular do cliente. Um serviço de backup pago pode ter retenção e isolamento separados. As páginas atuais não fornecem um mapa único dessas camadas.

O próprio guia debackup e recuperação do OpenStacktorna claras as perguntas ausentes: a frequência do backup deve seguir a perda de dados aceitável; retenção e armazenamento externo importam; e o teste de recuperação é tão importante quanto a existência de cópias. As alegações públicas da Ehost não divulgam a localização do backup, imutabilidade, criptografia, separação administrativa, política de exclusão, meta de tempo de restauração ou resultados de teste.

Um comprador deve transformar “backup incluído” em um cronograma:

Escopo:volume de boot, volumes anexados, bancos de dados, armazenamento de objetos, configuração do painel de controle, caixas de correio e chaves gerenciadas pelo cliente.
Ponto de recuperação:o máximo de dados que podem ser perdidos em cada serviço.
Tempo de recuperação:quando a Ehost começa a trabalhar e quando uma carga de trabalho utilizável deve retornar.
Retenção:número exato de cópias recuperáveis e como a idade é calculada.
Isolamento:se as cópias sobrevivem ao comprometimento da conta de produção, cluster ou site.
Método de restauração:recuperação de máquina inteira, nível de arquivo, nível de banco de dados e localização alternativa.
Taxas:restaurações incluídas, encargos de emergência e custos de egresso de dados.
Evidência:testes de restauração programados pelo cliente com resultados registrados.

O conflito entre sete e quatorze dias deve ser resolvido no contrato, mas a questão mais profunda é a responsabilidade. Se o aplicativo de um cliente gera dados críticos, um backup da Ehost não deve ser a única cópia controlada pela mesma conta e provedor. O cliente precisa de um caminho de exportação ou replicação independente cujas credenciais e domínio de falha difiram da produção.

Resposta de cinco minutos não é recuperação de cinco minutos

A superfície de suporte da Ehost é visível. O site principal fornece contatos telefônicos e de e-mail; o portal de suporte oferece tickets, uma base de conhecimento, anúncios, downloads e status do servidor. A página degarantia de serviçodiz que o suporte funciona 24/7 e que os clientes serão notificados por e-mail, telefone ou contato direto quando a manutenção exigir tempo. As páginas de servidor dedicado e servidor de jogo afirmam uma resposta dentro de cinco minutos através de ticket, e-mail, hotline ou chat ao vivo.

Esses são compromissos úteis, mas descrevem acesso e resposta mais do que resolução. Um acuso de recebimento de cinco minutos pode confirmar que um incidente existe, enquanto a substituição de hardware, o failover de rota ou a restauração de dados leva horas. Um cronograma de serviço sério precisa de relógios separados para acuso de recebimento, engajamento técnico, solução alternativa, restauração e relatório de causa raiz.

A gravidade também importa. Um único site lento, um cluster de virtualização inteiro indisponível, suspeita de exposição de dados e uma pergunta de configuração de rotina não devem compartilhar uma fila. As páginas públicas não divulgam definições de gravidade, funções de escalação, cobertura de idioma, modelo de pessoal, autoridade após o expediente ou remédios de crédito de serviço.

O portal de suporte fornece uma observação intrigante, mas limitada. No momento do acesso, tanto suabase de conhecimentoquanto suaárea de downloadexibiam um aviso genérico de que a Ehost estava ciente de um problema que poderia afetar o serviço. O detalhe do status do servidor vinculado não estava publicamente recuperável no momento da revisão, portanto, o serviço afetado, hora de início, gravidade, impacto no cliente e resolução não puderam ser estabelecidos. Isso não é evidência de uma interrupção material. É evidência de que existe um mecanismo de status, mas não produziu um registro de incidente público utilizável.

Nenhum histórico de status público abrangente, arquivo pós-incidente ou série de uptime medida independentemente foi localizado. A ausência de um arquivo público não significa que a Ehost não tenha incidentes ou registros internos. Significa que um comprador deve solicitá-los. A diligência útil incluiria os doze meses anteriores de disponibilidade por produto e site, contagens de incidentes de gravidade um, tempos medianos de resposta e restauração, histórico de manutenção, amostras de relatórios de causa raiz e resultados de restauração de backup.

O aviso de manutenção também deve ser tornável mensurável. Quanto aviso é dado para trabalho planejado? Quais ações de emergência são isentas? A manutenção é excluída dos cálculos de uptime? O cliente pode reagendar? A Ehost migra máquinas virtuais ou as desliga? O que acontece com um sistema operacional não gerenciado que não se recupera limpo?

O provedor local mais forte pode ser valioso precisamente porque um comprador pode alcançar um humano que conhece a infraestrutura. Essa vantagem se torna contratual apenas quando a pessoa tem autoridade, a fila é monitorada, a escalação é testada e a obrigação de restauração é clara.

Segurança são vários produtos, não um único escudo

A linguagem de segurança da Ehost abrange firewalls físicos, isolamento de hospedagem compartilhada, AntiDDoS básico, mitigação DDoS paga, certificados SSL, backups e suporte. Esses controles abordam ameaças diferentes e não devem ser colapsados em uma alegação geral de que uma carga de trabalho é “segura”.

A página cloud diz que cada cluster tem um firewall físico e que as máquinas virtuais podem ser integradas ao Antiddos.vn. A página de hospedagem empresarial diz que o AntiDDoS básico pode ativar automaticamente a proteção de firewall contra botnets menores. O siteAntiDDoSdescreve vários nós de proxy e firewall em marcas de data center vietnamitas, filtrando solicitações maliciosas e fornecendo recursos de HTTP/2 e firewall de aplicação web. Acategoria de pedido AntiDDoSda Ehost publica rótulos de planos e alguns parâmetros de volume de solicitações.

Estas são alegações da empresa sobre o design do serviço, não validação independente da capacidade de mitigação. A aquisição deve perguntar se a proteção está sempre ativada ou ativada após detecção; se cobre inundações de Camada 3/4, solicitações de Camada 7 ou ambas; onde o tráfego é desviado; que largura de banda limpa é comprometida; se os IPs de origem são preservados; como as chaves TLS são tratadas; o que acontece com protocolos não web; se ataques geram encargos extras; e se a origem permanece alcançável diretamente.

A evidência de recurso de rede adiciona outro limite. Prefixos RPKI-válidos ajudam a prevenir origens de rota não autorizadas. Eles não filtram solicitações de aplicativos maliciosos, impedem roubo de credenciais, aplicam patches no sistema operacional do cliente ou protegem um banco de dados de uma conta com privilégios excessivos. Por outro lado, um proxy web pode absorver ataques HTTP enquanto deixa serviços de e-mail, VPN, jogo ou banco de dados expostos.

A segurança da conta também é subdocumentada. O registro público revisado aqui não estabelece se a autenticação multifator é obrigatória ou disponível para todas as superfícies de cliente e administrador. Os compradores devem testar MFA, separação de funções, credenciais de API, verificação de identidade de suporte, registro de acesso privilegiado e desligamento, em vez de inferir implementação a partir de linguagem de segurança geral.

O caminho de abuso é igualmente pouco claro. Registros derivados da APNIC identificam o mantenedor de resposta a incidentes da VNNIC em vez de uma mesa de abuso da Ehost claramente anunciada, e o site principal expõe contatos de vendas e suporte em vez de uma política de abuso dedicada. Isso não prova que a Ehost não possui um processo interno. Significa que um repórter externo ou cliente não pode verificar facilmente a rota para malware, spam, phishing, direitos autorais ou abuso de rede.

Um provedor de hospedagem deve ser capaz de mostrar triagem, autenticação, preservação de evidências, notificação ao cliente, padrões de suspensão e apelação.

O banco de dados legal oficial do Vietnã lista aLei de Proteção de Dados Pessoais 91/2025/QH15como efetiva a partir de 1º de janeiro de 2026. A aplicação dessa lei depende dos fatos e deve ser avaliada por um advogado qualificado. Para os compradores da Ehost, o requisito prático é simples: o contrato deve identificar papéis de processamento, acesso de suporte, localização de dados, subprocessadores, cooperação em incidentes, retenção, exclusão e exportação para o serviço real.

Nenhum pacote de garantia de segurança público e específico de produto foi localizado para a Ehost: nenhum certificado ISO escopo, relatório SOC, resumo de teste de penetração, política de divulgação de vulnerabilidade, lista de subprocessadores ou lista de materiais de software. Isso é uma lacuna de evidência, não prova de que esses controles não existem. Torna-se consequente quando o modelo de risco de um comprador exige mais do que alegações de primeira parte.

O aviso de ciclo de vida oculto na vitrine

O catálogo público contém sinais de que a informação do produto envelheceu de forma desigual. As páginas de hospedagem compartilhada descrevem suporte para versões PHP de 5.4 a 7.1 e MariaDB 10.1. O portal de faturamento lista separadamente MultiPHP 5.5, 5.6 e 7.0 para alguns pacotes e PHP 7.0 com MariaDB 10.1 para uma oferta de alto desempenho.

Essas versões não são atuais. A tabela deramos não suportados do PHPregistra o fim da vida para PHP 5.4 em setembro de 2015, PHP 7.0 em janeiro de 2019 e PHP 7.1 em dezembro de 2019. A tabela demanutenção de versões da MariaDB Foundationcoloca o fim da manutenção do MariaDB 10.1 em outubro de 2020.

A interpretação responsável não é que a Ehost definitivamente executa software de fim de vida exposto em produção. As páginas podem estar desatualizadas enquanto a plataforma foi atualizada. Essa distinção precisa ser testada. Especificações desatualizadas são por si mesmas um problema de controle porque os clientes as usam para julgar compatibilidade de aplicativos e segurança.

Um comprador da Ehost deve solicitar uma matriz de runtime atual para cada pool de hospedagem compartilhada: sistema operacional, servidor web, painel de controle, ramos PHP, versão do banco de dados, configuração TLS, cadência de patches e datas de depreciação planejadas. Deve confirmar se os clientes podem selecionar versões não suportadas para aplicativos legados e, em caso afirmativo, quais termos de isolamento e risco se aplicam.

Os painéis de controle adicionam dependência de ciclo de vida de terceiros. A Ehost vendelicenças DirectAdmine diz que algumas licenças “internas” estão disponíveis apenas para servidores hospedados na Ehost, com pagamento mínimo de vários meses. Um cliente que combina computação da Ehost, uma licença fornecida pela Ehost, DNS, certificados e backups pode receber suporte conveniente de balcão único. Também cria um pacote que deve ser desembaraçado durante a migração.

A referência da página cloud a processadores Intel Broadwell fornece outra pista datada, enquanto a página de servidor dedicado anuncia configurações mais novas Xeon Gold e Platinum e a categoria de faturamento C6 reivindica IOPS muito maiores. Isso parece ser múltiplas gerações de infraestrutura em vez de uma frota uniforme. Isso é normal para um host de longa execução, mas a política de colocação importa. O comprador deve saber se um plano mapeia para uma geração de CPU definida e classe de armazenamento ou para qualquer pool com capacidade.

A governança do ciclo de vida deve cobrir mais do que versões. Deve especificar aviso para migrações de host, mudanças de painel de controle, aposentadoria de imagem de sistema operacional, fim de vida de hardware, renumeração de IP, mudanças de marca de certificado e pacotes descontinuados. O portal de suporte até contém uma categoria rotulada “EOL”, embora seu conteúdo não estivesse disponível nas evidências congeladas. Uma política de ciclo de vida publicada permitiria que os clientes planejassem em vez de descobrirem a aposentadoria através de uma renovação ou incidente.

A concorrência testa a Ehost com evidências, não com escala

A Ehost compete em vários mercados ao mesmo tempo. Em hospedagem compartilhada, enfrenta hosts locais e plataformas de site. Em máquinas virtuais, enfrenta clouds de operadoras vietnamitas, provedores de VPS especializados e hiperescaladores globais. Em servidores dedicados e colocation, enfrenta operadores de data center, integradores de sistemas e contratos diretos de instalação. Para backup, CDN e DDoS, os clientes podem comprar um serviço especializado independentemente.

A vantagem mais credível da Ehost não é a escala global. É a possibilidade de um relacionamento operacional local: pacotes denominados em VND, contato telefônico e de ticket direto, ajuda na migração, instalações vietnamitas, pacotes simples e um fornecedor único em hospedagem, servidor, rack e serviços de proteção. Uma pequena empresa sem uma grande equipe de infraestrutura pode valorizar um provedor disposto a inspecionar um sistema e recomendar uma configuração prática.

O desafio é que alternativas domésticas maiores publicam um nível diferente de garantia. AVNPT Cloudanuncia um SLA de 99,99%, suporte IPv6, um catálogo de serviços gerenciados mais amplo e certificações de segurança nomeadas. Essas são as próprias alegações da VNPT, não prova independente de que toda carga de trabalho terá melhor desempenho. Elas ilustram a comparação de aquisição que a Ehost deve atender: qual nível de serviço, capacidade dual-stack, evidência de conformidade, arquitetura e escopo gerenciado o comprador recebe pelo preço?

Os hiperescaladores globais oferecem APIs, regiões e serviços gerenciados que o catálogo público da Ehost não iguala. Eles também podem introduzir exposição a moeda estrangeira, precificação complexa, suporte distante e arquitetura que um pequeno cliente luta para operar. Um servidor autogerenciado em colocation oferece controle máximo de hardware, mas transfere aplicação de patches, peças sobressalentes e recuperação para o cliente. Uma plataforma de software gerenciada pode eliminar a administração do servidor, mas aumentar o lock-in no nível do aplicativo.

O teste de concorrência correto é, portanto, específico da carga de trabalho:

Para um site de divulgação, a hospedagem compartilhada pode ser mais barata e simples do que qualquer cloud.
Para um aplicativo vietnamita que precisa de suporte local previsível, a cloud ou hardware dedicado da Ehost pode ser atraente se a especificação do serviço for verificada.
Para uma carga de trabalho regulada, o escopo de garantia, o processo de incidente e os termos de dados podem superar o preço principal.
Para um aplicativo distribuído globalmente, IPv6, caminhos internacionais, escalonamento automático e design multirregião podem dominar o suporte local.
Para um jogo sensível à latência, o clock da CPU, a resposta DDoS, o peering doméstico e a perda de pacotes durante o ataque importam mais do que a marca genérica “cloud”.

A única discussão antiga de cliente independente encontrada no registro público revisado, umfórum de hospedagem vietnamita, contém um relato favorável sobre o serviço e suporte da Ehost. Tem anos, é informal e não representativo. O próprio site da Ehost também publica testemunhos positivos sem detalhes suficientes para verificar identidade, produto ou data. Nenhum deve substituir referências atuais de clientes executando uma carga de trabalho comparável.

A Ehost não precisa provar que é o maior provedor. Ela precisa provar que seu modelo de serviço local dá a um cliente específico mais controle por dong do que as alternativas realistas.

Os custos de mudança aparecem uma dependência por vez

A infraestrutura é frequentemente descrita como portátil porque uma máquina virtual pode ser copiada. Na prática, o custo de mudança se acumula fora da imagem da máquina.

A primeira camada é oendereçamento. Uma carga de trabalho usando IPv4 atribuído pela Ehost pode precisar ser renumerada quando sair. O DNS pode esconder parte da mudança, mas listas de permissões, peers VPN, sistemas de pagamento, reputação de e-mail e APIs de terceiros podem conter o endereço antigo. O espaço de endereço portátil da Ehost é visível, mas os termos públicos não dizem se um cliente pode trazer ou transferir recursos IP.

A segunda camada é oarmazenamento e backup. Uma imagem de disco pode omitir snapshots, metadados de objetos, histórico de backup ou detalhes de criptografia do lado do provedor. A página eStorage não publica uma API de exportação ou cronograma de egresso. Uma restauração que funciona apenas dentro da Ehost é proteção de continuidade, não portabilidade.

A terceira camada é osoftware de controle. Configurações do cPanel ou DirectAdmin, contas de e-mail, hierarquias de revendedor, certificados e tarefas agendadas precisam ser reconstruídos ou convertidos. Uma licença interna vinculada à hospedagem da Ehost pode terminar quando o servidor se move, exigindo uma nova licença e talvez uma migração de painel de controle.

A quarta camada é aproteção de rede. Se um domínio aponta através de um proxy DDoS ou CDN vinculado à Ehost, a saída requer mudança de DNS, reconfiguração de certificado e origem, exportação de log e remoção cuidadosa do caminho antigo. A migração durante um ataque é especialmente difícil porque a origem pode ficar exposta durante a transição.

A quinta camada é oconhecimento operacional. O suporte da Ehost pode saber por que um servidor usa uma rota, kernel, exceção de firewall ou layout de armazenamento específico. Se esse conhecimento viver em tickets em vez de documentação do cliente, um relacionamento de sucesso de suporte cria dependência.

A colocation tem custos físicos de saída. O cliente precisa de acesso autorizado, uma janela de manutenção, embalagem, transporte, destruição de dados para mídia aposentada e uma nova rota. Se a Ehost fornece espaço IP ou mão remota, esses serviços terminam ao mesmo tempo que a máquina se move.

As evidências públicas não fornecem uma política completa de rescisão, exportação ou exclusão. A página inicial da Ehost diz que há uma política de reembolso quando um serviço não é usado, e o FAQ de hospedagem pessoal diz que valor não utilizado pode ser creditado ao fazer upgrade. A página de garantia trata de aviso de suporte e manutenção. Nenhuma dessas páginas estabelece elegibilidade de reembolso, aviso de rescisão, duração do acesso a dados, formato de exportação, evidência de exclusão ou assistência de transição em todos os serviços.

Um cronograma de saída deve ser acordado antes do go-live. Deve dar ao cliente exportações e snapshots atuais; acesso de leitura suficiente; procedimentos de transferência de DNS e domínio; suporte à migração de caixa de correio; histórico de logs e tickets quando relevante; um cronograma para remover o acesso do provedor; confirmação de exclusão; etapas de liberação de hardware para colocation; e encargos previsíveis. O cliente deve ensaiar pelo menos uma restauração ou migração para outro ambiente enquanto o relacionamento está saudável.

Um teste de aquisição que corresponde à superfície real da Ehost

A Ehost deve ser avaliada com evidências que correspondam às suas reivindicações e lacunas específicas, não a um questionário genérico de cloud.

1. Reconcilie o registro comercial

Peça à Ehost para identificar o catálogo de produtos autoritativo e explicar as diferenças entre a página pública Cloud Server, a loja SSD Cloud Server e a loja C6. Exija um cronograma de configuração assinado. Faça o mesmo para pacotes de colocation público e portal de faturamento. Confirme impostos, compromisso, renovação, reembolso, restauração e encargos de upgrade.

2. Prove a máquina entregue

Durante um teste, registre o modelo de CPU e tempo de steal, memória disponível, disco utilizável, IOPS sustentado e de burst, latência sob carga, taxa de interface e taxa de transferência doméstica e internacional. Execute testes em vários momentos, em vez de tratar um benchmark como garantia. Compare o resultado com o formulário de pedido.

3. Mapeie os domínios de falha do OpenStack

Solicite a versão do OpenStack, hipervisor, backend de armazenamento, design de zona de disponibilidade, redundância do plano de controle e processo de manutenção. Peça uma falha controlada de host de computação ou um teste recente documentado. Estabeleça se reinicialização de instância, recuperação de volume e restauração entre sites são capacidades separadas.

4. Teste a rota, não a lista de data centers

Confirme qual ASN e prefixos o produto usa, se os endereços são da Ehost ou espaço da instalação, e se IPv6 está disponível. Pergunte como o AS135920 sobrevive à perda do AS135905 e como as rotas mudam quando o AntiDDoS é ativado. Teste a partir das principais redes de acesso vietnamitas e de locais internacionais. Registre perda de pacotes e mudanças de caminho durante uma manutenção ou failover simulado.

5. Transforme backup em um exercício de recuperação

Resolva o conflito de retenção de sete versus quatorze dias na cloud. Selecione um arquivo, banco de dados e recuperação de máquina completa. Exclua ou corrompa dados de teste, depois meça o ponto de recuperação, resposta do operador, tempo de restauração, consistência resultante e taxa. Verifique se existe uma cópia em site separado ou offline.

6. Defina suporte por gravidade

Abra tickets através de cada canal prometido. Confirme que 24/7 significa um respondente qualificado, não apenas triagem. Contrate metas separadas de acuso de recebimento e restauração, contatos de escalação, aviso de manutenção e entrega de causa raiz. Obtenha desempenho histórico para o produto e site que está sendo comprado.

7. Inspecione controles de segurança e abuso

Teste MFA, separação de funções, recuperação de conta e verificações de identidade de suporte. Revise propriedade de patches, isolamento de inquilino, registro, gerenciamento de vulnerabilidades, arquitetura DDoS e acesso privilegiado. Obtenha as políticas reais de privacidade e serviço que o portal de suporte lista, mas que não estavam publicamente recuperáveis nesta pesquisa. Confirme uma rota de abuso dedicada e processo de tratamento de evidências.

8. Verifique ciclo de vida e portabilidade

Peça versões de software suportadas atuais e datas de depreciação. Exporte uma VM, banco de dados, conjunto de caixas de correio, conta de painel de controle e backup. Confirme quais licenças terminam na saída. Se a colocation estiver envolvida, ensaie acesso físico autorizado e liberação de equipamento.

Este teste não exige documentação de hiperescalador de um pequeno operador. Pede à Ehost que suporte as promessas que já faz: recursos definidos, alta disponibilidade, backups, suporte rápido, várias instalações, segurança e cuidado operacional local.

As perguntas não respondidas fazem parte do produto

O registro público revisado estabelece mais do que geralmente é visível para um host local. Há uma empresa exata, preços ao vivo, sistemas ativos de suporte e faturamento, um catálogo de serviços amplo, um sistema autônomo, cinco prefixos IPv4 roteados, cobertura RPKI e endereços responsivos na Cidade de Ho Chi Minh. Também revela um provedor que continua a publicar novo conteúdo de 2026 e ofertas mais novas de servidor dedicado ou C6.

Não estabelece receita auditada, participação de mercado, número de clientes, escala de pessoal, propriedade de instalações, volume de tráfego, contagem de servidores, capacidade de rota ou uptime real. A estimativa de domínios hospedados do IPinfo não pode ser convertida em clientes porque um cliente pode operar muitos domínios e um domínio pode usar apenas parte do serviço da Ehost. Uma contagem de prefixos públicos não pode ser convertida em capacidade de computação.

Não estabelece que as instalações “Tier 3” nomeadas no marketing da Ehost são certificadas para os racks e serviços exatos vendidos, ou que a Ehost possui as instalações. Não estabelece diversidade física ou de operadora a partir de uma lista de vários sites. Não estabelece que todo endereço coberto por RPKI recebe proteção DDoS.

Não estabelece um SLA completo. O número público de 99,5% carece de uma estrutura de medição e remédio visível, enquanto o termo “uptime absoluto” em servidores dedicados não é um substituto credível para termos limitados. Nenhum cronograma de reembolso completo estava acessível.

Não estabelece versões de runtime atuais. As referências antigas a PHP e MariaDB podem ser cópia desatualizada ou compatibilidade ao vivo; apenas um inventário de plataforma atual pode distingui-las. Não estabelece uma versão ou topologia do OpenStack.

Não estabelece isolamento de backup, desempenho de recuperação ou um período de retenção autoritativo. Não estabelece um histórico de incidentes, embora o portal de suporte exponha um mecanismo de status e tenha exibido um aviso de problema genérico. Não estabelece certificação de segurança independente, escopo de teste ou tratamento de abuso.

Essas não são razões para declarar a empresa inadequada. São dimensões do serviço que permanecem privadas, específicas do contrato ou não resolvidas. Para um site de baixo risco, um cliente pode razoavelmente aceitar menos profundidade documental e confiar em uma migração testada mais backups independentes. Para um sistema crítico para receita, regulado ou propenso a ataques, as mesmas lacunas se tornam bloqueadores de aquisição até que a Ehost forneça evidências.

O que observar a seguir

Cinco sinais melhorariam materialmente a confiança na superfície de controle da Ehost.

Primeiro,convergência do catálogo. As páginas públicas de produto e o portal de faturamento devem descrever os mesmos pacotes, ou marcar claramente gerações e datas. Remover preços plausíveis e referências de runtime não suportadas tornaria a vitrine uma parte confiável do serviço.

Segundo,desenvolvimento de rede. A validade contínua do RPKI é positiva. A origem pública de IPv6 e um design de upstream ou peering demonstravelmente diverso reduziriam perguntas não respondidas sobre alcance e ciclo de vida. Se a Ehost mantém intencionalmente um upstream público, deve explicar o mecanismo de resiliência por trás dessa escolha.

Terceiro,transparência operacional. Uma página de status utilizável com timestamps de incidentes, produtos afetados, atualizações e resolução transformaria o link de status existente em evidência. Métricas periódicas de disponibilidade e restauração tornariam as alegações de uptime e backup testáveis.

Quarto,fechamento de políticas. O site da Ehost vincula páginas de privacidade, uso de serviço, envio e garantia, e seu portal de suporte lista um download da política de serviços da EHOST. Publicar termos atuais e acessíveis para reembolsos, uso aceitável, abuso, processamento de dados, suporte, SLA, backup, rescisão e exclusão reduziria o custo de negociação para ambos os lados.

Quinto,disciplina de ciclo de vida. Uma matriz de software atual, política de versão do OpenStack e cronograma de aviso para pools de hardware, painéis de controle e produtos de fim de vida mostrariam que a Ehost gerencia a longa cauda criada por um catálogo amplo.

A rede pública da Ehost não é imaginária. Cinco prefixos roteados e uma pegada de hospedagem ativa são mais persuasivos do que uma parede de logotipos de infraestrutura não verificados. Mas um anúncio de rota é apenas a borda externa do serviço. O cliente depende do banco de dados de pedidos, sistema de provisionamento, hipervisor, armazenamento, instalação, operadora, backup, fila de suporte e contrato que estão por trás dele.

É por isso que as duas descrições do Cloud 1G de 250.000 dong importam. Elas expõem o lugar exato onde um relacionamento de hospedagem pode se tornar controlável ou ambíguo. Se a Ehost e o comprador puderem reconciliar a especificação, provar o caminho de rota e recuperação, atribuir responsabilidade no momento da falha e preservar uma saída, a amplitude local da empresa pode ser uma vantagem. Se essas perguntas permanecerem dentro de páginas web inconsistentes, o servidor mais barato ainda não adquiriu um preço confiável.