El contrato antes de la nube: la red visible de Ehost y sus especificaciones contradictorias

Resumen

• EHOST SOFTWARE COMPANY LIMITEDcuenta con identificadores legales, de contacto y de red consistentes: los nombres operativos del sitio Công ty TNHH Phần Mềm EHOST y el código fiscal 0312916711, mientras que los registros de enrutamiento públicos identifican AS135920 como EHOST-VN y muestran cinco prefijos IPv4/24originados.
• La huella de enrutamiento es real pero estrecha. Las fuentes BGP revisadas muestran 1.280 direcciones IPv4 originadas, ningún espacio IPv6 originado y una adyacencia upstream observada a través de AS135905. Eso no demuestra ni un servicio deficiente ni un homing único físico, pero hace que las preguntas sobre diversidad de rutas, conmutación por error y IPv6 específico del producto sean relevantes.
• Las superficies de venta públicas de Ehost no proporcionan una especificación de producto estable. La misma etiqueta Cloud 1G de 250.000 dong se describe de manera diferente en la página de marketing y en el portal de facturación, y las ofertas de coubicación pública y de pago también divergen. Por lo tanto, un formulario de pedido firmado debe definir los términos autorizados de CPU, memoria, almacenamiento, IOPS, ancho de banda, ubicación, copia de seguridad y soporte.
• Las afirmaciones sobre copias de seguridad, seguridad y soporte necesitan el mismo tratamiento. Ehost anuncia copias de seguridad diarias o semanales, cortafuegos físicos, AntiDDoS, soporte 24/7 y una respuesta de cinco minutos en algunos productos, pero no divulga públicamente un diseño de recuperación completo, una matriz de severidad, un calendario de créditos de servicio, un archivo de incidentes, un flujo de trabajo de abuso o un alcance de aseguramiento independiente.
• El proveedor puede adaptarse a clientes que valoran la facturación vietnamita, el soporte humano directo, la ayuda en la migración y un menú que abarca alojamiento compartido, nube, servidores dedicados, coubicación, copias de seguridad y protección DDoS. Los compradores con requisitos estrictos de continuidad, cumplimiento o portabilidad deben realizar una prueba de servicio y negociar una salida ejecutable antes de mover la producción.

Un servidor de 250.000 dong con dos respuestas

Comience con el paquete cloud más pequeño de Ehost. En lapágina de Servidor en la Nubepública, “EHOST 1G” cuesta 250.000 dongs vietnamitas al mes y se describe como dos núcleos de CPU, 2 GB de RAM, 30 GB de almacenamiento SSD y una conexión de red de 100 Mbps. La página dice que todos los planes cloud reciben al menos 2.000 IOPS de almacenamiento. En lapágina de pedido de SSD Cloud Serverde Ehost, “Cloud 1G” también comienza en 250.000 dongs al mes, pero la especificación mostrada es un núcleo de CPU, 2 GB de RAM, 20 GB de almacenamiento SSD, 200 Mbps de red y 10.000 IOPS.

Ninguna página es oscura. Una es la explicación del servicio orientada al cliente; la otra es el sistema a través del cual se invita a un comprador a realizar el pedido. Sin embargo, describen unidades informáticas materialmente diferentes. La discrepancia no se limita al plan más pequeño. La oferta pública Cloud 2G enumera dos núcleos, 4 GB de RAM y 40 GB de almacenamiento; la versión de pago enumera dos núcleos, 2 GB de RAM y 40 GB. Los paquetes superiores también difieren en memoria y disco. Una categoría de facturación separada,SSD Cloud Server C6, presenta otra generación de planes con nombres similares, incluido un Cloud 1G de 350.000 dongs con dos núcleos, 2 GB de RAM, 30 GB de almacenamiento, 200 Mbps y 50.000 IOPS.

Esto no demuestra que los clientes sean aprovisionados incorrectamente. Un catálogo puede contener una categoría heredada, un grupo de hardware más nuevo, una página de aterrizaje obsoleta o una configuración que se aclara durante las ventas. Sí demuestra que el registro público no puede responder la pregunta de adquisición más elemental: ¿qué especificación se convierte en la obligación cuando se realiza el pago?

Para un proveedor de infraestructura, eso no es un error editorial menor. La asignación de CPU afecta el rendimiento de la aplicación. La memoria puede determinar si una base de datos permanece residente o hace intercambio. El tamaño del disco afecta la viabilidad de la migración. Las IOPS pueden cambiar el comportamiento de las cargas de trabajo transaccionales en un orden de magnitud. Una tasa de red puede ser un límite de puerto, una tasa comprometida, un perfil compartido o un límite de ráfaga. Cada variación puede alterar el rendimiento y el costo total.

El primer control en una compra de Ehost debería ser, por tanto, documental. La cotización, el formulario de pedido o el contrato deben identificar la familia y generación exacta del producto; el recuento de vCPU y el modelo de programación; la memoria garantizada; el almacenamiento utilizable; el medio de almacenamiento; las IOPS mínimas y de ráfaga; el ancho de banda nacional e internacional; los límites de transferencia; la asignación de IP pública; la ubicación; la imagen del sistema operativo; el alcance de la gestión; la inclusión de copias de seguridad; la tarifa de restauración; los impuestos; y el plazo de renovación.

El comprador debe conservar ese documento junto con la factura y la evidencia de aprovisionamiento inicial.

La tesis central de esta revisión se sigue de esas dos tarjetas Cloud 1G. La infraestructura de Ehost no está adecuadamente descrita por el nombre de la marca, el precio mensual o la palabra “nube”. Su producto real comienza donde las partes reconcilian la página de ventas, el portal de facturación y el servicio que realmente se entrega.

La empresa exacta detrás de las pantallas

El límite de la entidad es inusualmente importante porque “Ehost” aparece como una marca, un dominio, un portal de soporte, un servicio AntiDDoS y una red registrada. La empresa examinada aquí esEHOST SOFTWARE COMPANY LIMITED, en vietnamitaCông ty TNHH Phần Mềm Ehost, con código fiscal0312916711. Lapágina de contactode Ehost proporciona el nombre legal, el número de registro, una dirección en la ciudad de Ho Chi Minh en 147/25 An Dương Vương en Bình Tân, el número de teléfono 0938-227-199 y una dirección de contacto@ehost.vn. El pie de página dice que el registro comercial se emitió el 9 de septiembre de 2014.

Unagregador externo de registros fiscales vietnamitasasocia independientemente el mismo código fiscal con EHOST SOFTWARE COMPANY LIMITED, la misma dirección, una fecha de operación del 9 de septiembre de 2014 y el representante Nguyễn Thanh Tâm. Ese registro es una corroboración útil, no un sustituto de un extracto actualizado del registro oficial de empresas de Vietnam. Su estado y clasificaciones industriales deben tratarse como la representación fechada del agregador de los registros públicos.

La identidad de red proporciona una verificación de continuidad separada.BGP.toolsreproduce los datos de registro originados por APNIC para AS135920:EHOST-VN, descrito como Ehost software company limited, país Vietnam, mantenido a través de VNNIC. El registro fue modificado en enero de 2026. Lapágina de AS135920 de IPinfotambién clasifica la red como hosting y la asocia con el mismo nombre de empresa.

Estos vínculos respaldan una conclusión honesta: la empresa legal, la superficie de ventas activaehost.vn, la superficie de facturación y soportesecure.ehost.vny AS135920 pertenecen a una huella operativa coherente. No prueban que cada servicio anunciado en cada dominio relacionado sea propiedad, operado o garantizado por la empresa. IPinfo, por ejemplo, enumeraehost.com.vncomo dominio del ASN, mientras que el sitio operativo actual revisado aquí esehost.vn; el primero no produjo una página utilizable durante esta investigación. Eso es una cuestión de continuidad de dominio para la empresa, no motivo para dividir o fusionar entidades.

La misma precaución se aplica a AntiDDoS. Ehost enlaza directamente aAntiddos.vn, y su página cloud dice que los clientes pueden integrarse con ese servicio. El sitio de AntiDDoS se presenta como una red de mitigación vietnamita de múltiples nodos fundada en 2015. Las páginas públicas revisadas aquí no establecen una identidad corporativa separada o una cadena contractual suficiente para determinar si Antiddos.vn es una división, producto, filial o socio comercial de EHOST SOFTWARE COMPANY LIMITED. Un comprador debe hacer explícita la parte contratante en lugar de inferirla a partir de enlaces cruzados.

La identidad exacta importa en el momento del fallo. La entidad que recibe el pago debe ser la entidad obligada a proporcionar servicio, salvaguardar datos, notificar incidentes, devolver equipos o realizar exportaciones, y pagar cualquier reembolso o crédito de servicio. Si un operador de centro de datos, licenciante de software, servicio de mitigación o portador de red realiza parte del servicio, el cliente necesita saber si Ehost sigue siendo responsable de esa dependencia o simplemente la revende.

Lo que AS135920 demuestra — y lo que no

AS135920 es la evidencia independiente más sólida de que Ehost opera más que un folleto y una tienda de reventa. En la vista pública congelada de BGP, el sistema autónomo origina cinco prefijos IPv4/24:45.123.96.0/24,45.123.97.0/24,103.63.212.0/24,103.63.213.0/24y103.63.215.0/24. Eso son 1.280 direcciones IPv4. TantoBGP.toolscomoIPinfomuestran los prefijos como cubiertos por Autorizaciones de Origen de Ruta válidas. Latabla de validación de origen de ruta de Vietnamde APNIC Labs informa una cobertura 100% válida para la población de direcciones EHOST-VN medida.

Esa es una evidencia operativa significativa. Ehost tiene recursos numéricos visibles en el sistema de enrutamiento global. Múltiples direcciones responden a sondas independientes, e IPinfo informa cientos de dominios a través de direcciones en el ASN. La huella es consistente con la actividad de hosting en lugar de un cascarón legal que simplemente comercializa la plataforma de otro.

La validez de RPKI también es un control real. Permite a los validadores de ruta verificar criptográficamente que AS135920 está autorizado a originar los prefijos cubiertos. Elinforme de recursos de Internet 2024de VNNIC trata RPKI e IPv6 como partes importantes del desarrollo de recursos de Internet de Vietnam. Las autorizaciones de origen válidas de Ehost reducen una clase de error de origen de ruta o riesgo de secuestro.

La evidencia se detiene ahí. RPKI no muestra que Ehost filtre rutas inválidas recibidas de otros, proteja aplicaciones de clientes, mantenga enrutadores redundantes o pueda sobrevivir a una falla de portador. No dice nada sobre el volumen de tráfico, la capacidad del servidor, la energía, la refrigeración, la capacidad de depuración DDoS, la calidad de la copia de seguridad o el número de clientes. Un origen de cinco prefijos puede soportar un host especializado bien administrado o uno frágil; la tabla de rutas no decide entre ellos.

La conectividad visible es más cautelosa. BGP.tools enumera un upstream, AS135905, descrito como Vietnam P&T. Lavista del CIDR Reportindependiente también ve una adyacencia upstream y ningún espacio de direcciones downstream. IPinfo también enumera un upstream y un peer, ambos AS135905. Las etiquetas de relación varían según la fuente de datos, pero la observación consistente es una red adyacente visible externamente que transporta las rutas de AS135920 en las vistas revisadas.

Esto no debe traducirse en una afirmación de que cada rack de Ehost tiene un cable físico o que cada producto es de un solo homing. Ehost promociona coubicación en varias marcas de centros de datos, y puede usar direcciones asignadas por el proveedor, interconexiones privadas, servicios de Capa 2, mitigación DDoS remota o rutas no visibles como adyacencias AS separadas. Los recolectores públicos de BGP también pueden perder relaciones privadas o selectivas.

Sí crea una prueba de adquisición. Si un servicio se vende como multi-portador o multi-centro de datos, Ehost debe mostrar cómo el tráfico del cliente sobrevive a la pérdida de AS135905, el enrutador fronterizo relevante, el sitio de servicio y la ruta hacia la plataforma de mitigación. La evidencia podría incluir un diagrama de arquitectura, sesiones BGP actuales, política de rutas, resultados de looking-glass, registros de conmutación por error y una prueba controlada. “Varios centros de datos” es una declaración de instalaciones; “diversa alcanzabilidad de Internet” es una declaración de enrutamiento.

Una no entrega automáticamente la otra.

IPv6 es la otra brecha visible. Las fuentes de enrutamiento revisadas muestrancero prefijos IPv6 originadospara AS135920. Eso no demuestra que Ehost no ofrezca IPv6 en ningún lugar: un cliente podría recibir IPv6 desde una instalación o ASN upstream. Sí significa que un comprador no puede inferir un servicio nativo de doble pila a partir del propio sistema autónomo de Ehost. Las preguntas específicas del producto deben cubrir el tamaño de asignación de IPv6, enrutamiento, DNS inverso, cortafuegos, manejo de DDoS, monitoreo y paridad con el soporte IPv4. En 2026, “podemos agregarlo después” es un compromiso de ciclo de vida, no una respuesta técnica.

Un catálogo de diferentes modelos de responsabilidad

Ehost no vende un solo modelo de infraestructura. Su menú público abarca alojamiento compartido, alojamiento de correo electrónico, máquinas virtuales, servidores dedicados, servidores de juegos, coubicación, copias de seguridad, almacenamiento tipo objeto, almacenamiento en caché, intermediación de CDN, licencias de panel de control, certificados y protección DDoS. Cada uno mueve una parte diferente de la pila operativa entre el proveedor y el cliente.

En elalojamiento compartido personal, Ehost dice que la plataforma proporciona cPanel, SSL, almacenamiento SSD, una capa AntiDDoS básica y copias de seguridad semanales. El cliente gestiona principalmente el código del sitio web, el contenido, las cuentas y las actualizaciones de la aplicación, mientras depende de Ehost para el servidor compartido, el panel de control, la red y el aislamiento. Lapágina de alojamiento empresarialagrega una IP pública dedicada, almacenamiento en caché Redis y afirmaciones de separación de recursos. Ese es un servicio compartido de mayor control, no equivalente a un servidor virtual.

La nube traslada más responsabilidad al cliente. La página pública de Ehost dice que usa OpenStack, proporciona una máquina virtual, permite a los clientes agregar CPU, memoria y disco, y puede detener el servidor durante dos a cinco minutos durante una actualización. A menos que se aplique un término de servicio gestionado por separado, el comprador debe asumir que el endurecimiento del sistema operativo, la aplicación de parches, la operación de la base de datos, la gestión de identidades y la monitorización de cargas de trabajo siguen siendo responsabilidades del cliente.

Las páginas públicas no etiquetan claramente los planes cloud estándar como gestionados o no gestionados.

Los servidores dedicados trasladan la exclusividad del hardware al comprador, pero no necesariamente la propiedad del hardware. Lapágina de servidores dedicados 2026de Ehost enumera configuraciones mensuales desde 5,5 millones hasta 12 millones de dongs, con procesadores Intel Xeon, 128 o 256 GB de RAM, almacenamiento SSD o NVMe, una dirección IP y 100 o 200 Mbps de ancho de banda. El comprador evita la contención de cómputo de vecino ruidoso, pero sigue dependiendo de Ehost para la máquina, el rack, la energía, la ruta del portador, las manos remotas y el proceso de reemplazo.

La coubicación es diferente nuevamente. El cliente posee o controla el servidor físico y alquila espacio en rack, energía y conectividad. Ehost dice que los clientes pueden ingresar al centro de datos las 24 horas después del prerregistro y pueden usar KVM remoto. En este modelo, Ehost puede tener menos control sobre el servidor y más responsabilidad en la coordinación de acceso, energía, conexiones cruzadas, enrutamiento y asistencia práctica. Una matriz de fallos debe separar el hardware del cliente, la infraestructura de la instalación, la red de Ehost y el portador upstream.

Lapágina de ECDNdice que Ehost coopera con proveedores de CDN vietnamitas e internacionales en lugar de describir una red de entrega totalmente propia. Eso puede ser comercialmente útil: Ehost puede actuar como integrador local y contacto de facturación. También significa que las ubicaciones de caché, los registros, el comportamiento de purga, el manejo de datos, la responsabilidad de incidentes y la salida dependen del proveedor subyacente no nombrado y del diseño específico del pedido.

Lapágina de eStoragedescribe “vStorage” como una tecnología de almacenamiento de objetos desarrollada por Ehost para medios, documentos, registros y contenido estático, y dice que los datos se almacenan permanentemente y siempre se respaldan. La página no publica una especificación de API, modelo de consistencia, objetivo de durabilidad, esquema de codificación de borrado o replicación, comportamiento de eliminación, mapa de región, precio de salida o nivel de servicio. “Almacenamiento de objetos” identifica una clase de servicio, no suficiente arquitectura para una decisión de datos duraderos.

La amplitud de Ehost es, por tanto, tanto una ventaja como una carga de diligencia. Un cliente puede comprar varios servicios adyacentes de un proveedor local y reducir la coordinación de vendedores. Pero el límite de responsabilidad cambia cada vez que el cliente pasa de alojamiento compartido a nube, de nube a hardware dedicado, o de una red de origen Ehost a una CDN de terceros o una ruta de centro de datos.

OpenStack es una lista de componentes, no un resultado de disponibilidad

Ehost dice que sus máquinas virtuales se ejecutan en OpenStack. Eso es técnicamente lo suficientemente específico como para ser útil, pero no lo suficientemente específico como para establecer resistencia. Laguía oficial de arquitectura lógica de OpenStackdescribe una nube como un conjunto de servicios independientes unidos a través de APIs y un servicio de identidad común. Detrás de las interfaces se encuentran bases de datos, colas de mensajes y procesos de servicio para cómputo, redes, imágenes y almacenamiento. OpenStack es un marco operativo cuyo resultado depende de cómo se despliegan y mantienen esas partes.

Para un comprador, la primera pregunta es qué versión de OpenStack y conjunto de servicios opera Ehost. La respuesta afecta el estado del soporte, las actualizaciones, los controladores, las correcciones de seguridad y el comportamiento de la API. La página pública del producto no identifica la versión, el hipervisor de cómputo, el backend de almacenamiento, el diseño de red, las zonas de disponibilidad, la política de migración en vivo o la API accesible al cliente.

La segunda pregunta es el confinamiento de fallos. Laguía de diseño de alta disponibilidadde OpenStack distingue el plano de datos que mantiene instancias, redes y almacenamiento en funcionamiento del plano de control que realiza operaciones de gestión. Enfatiza servicios redundantes, balanceadores de carga, bases de datos, colas de mensajes, conmutadores, rutas y energía. Simplemente instalar OpenStack no elimina los puntos únicos de fallo; los operadores deben diseñarlos para eliminarlos.

Ehost dice que su nube usa alta disponibilidad y puede recuperar un servidor en otro sistema. Esa es una afirmación de la empresa sobre un resultado. Para evaluarla, un comprador debe preguntar qué sucede en varios fallos separados:

• Si falla un host de cómputo, ¿la máquina virtual se reinicia automáticamente, y cuánto tiempo lleva la detección y el reinicio?
• Si falla el almacenamiento compartido, ¿los volúmenes se replican en dominios de fallo independientes o simplemente están protegidos por RAID dentro de un sistema?
• Si falla un controlador o una cola de mensajes, ¿las máquinas existentes continúan mientras las operaciones de gestión se pausan?
• Si falla un conmutador de top-of-rack o núcleo, ¿existe una ruta físicamente diversa?
• Si falla un sitio, ¿puede restaurarse un cliente en otro sitio a partir de una copia independiente?
• Si falla la propia actualización de OpenStack, ¿cuál es el proceso de reversión y notificación al cliente?

Estas preguntas importan porque la afirmación pública de tiempo de actividad del 99,5% es relativamente permisiva. Si se aplica continuamente, una disponibilidad del 99,5% permite alrededor de 3 horas y 36 minutos de inactividad en un mes de 30 días, o aproximadamente 43 horas y 48 minutos en un año de 365 días. Ese cálculo no es una declaración sobre el rendimiento real de Ehost. Muestra por qué el período de medición, las exclusiones, el tratamiento de mantenimiento, la fuente de monitoreo y el remedio importan tanto como el porcentaje.

También hay una señal de actualización en el texto del producto. Ehost dice que cambiar CPU, memoria, disco o red puede requerir un apagado de dos a cinco minutos. Eso sugiere que al menos algunos redimensionamientos son una interrupción en lugar de una operación en vivo transparente. Un cliente que planifique escalado vertical durante períodos pico debe probarlo y preguntar si la expansión de almacenamiento, los cambios de sabor de instancia y el mantenimiento del host siguen el mismo camino.

La conclusión útil no es ni “OpenStack no es fiable” ni “OpenStack garantiza la nube”. Es que Ehost ha nombrado una base técnica plausible, mientras deja las decisiones de despliegue que determinan el riesgo del cliente en gran medida fuera del registro público.

El recorrido del cliente cruza tres planos de control

Un cliente de Ehost se mueve a través de tres planos de control distintos: comercial, infraestructura y aplicación. Los problemas a menudo ocurren donde la responsabilidad pasa entre ellos.

El recorrido comercial comienza en elsitio principal de Ehost, donde las páginas de productos presentan paquetes y precios mensuales. Ehost dice que después del registro envía una confirmación y aviso de costo, y que el servicio se crea después del pago. El cliente llega entonces asecure.ehost.vn, un sistema de facturación y soporte con categorías de productos, opciones de visualización en VND y dólares estadounidenses, una cuenta, formularios de pedido, tickets, anuncios, descargas y un enlace de estado del servidor.

El conflicto de especificaciones hace importante la transferencia. Antes del pago, el comprador debe capturar la configuración de pedido seleccionada y obtener confirmación por escrito de que reemplaza la copia web inconsistente. Después del aprovisionamiento, el cliente debe registrar lo que realmente llegó: recuento de CPU virtual, memoria, disco, IP pública, ruta, velocidad de interfaz, sistema operativo, licencia de panel de control y estado de copia de seguridad. Un script de aceptación corto puede comparar la máquina entregada con el pedido.

Entonces comienza el recorrido de infraestructura. Para un servidor cloud, Ehost aprovisiona cómputo, almacenamiento y redes; el cliente instala o recibe un sistema operativo, crea credenciales de administrador, apunta DNS y despliega una aplicación. Para el alojamiento compartido, Ehost expone un panel de control y el cliente mueve archivos del sitio, bases de datos, certificados y configuraciones de correo. Para la coubicación, el cliente debe organizar el acceso a las instalaciones, la instalación del rack, la energía, la asignación de IP y la administración remota.

La migración no es una tarea. El sitio principal de Ehost promociona asesoramiento gratuito y asistencia de transferencia de datos para clientes que usan sus servicios. Una migración de producción aún necesita un inventario de origen, copia de datos, estrategia de DNS, manejo de certificados, prueba de flujo de correo, ventana de congelación de aplicación, verificación de integridad y reversión. Si las direcciones IP cambian, las listas de permitidos, los proveedores de pago, las APIs de terceros y las reglas de seguridad pueden necesitar actualizaciones.

Si el correo electrónico se mueve, la reputación del remitente y los registros DNS como SPF, DKIM y DMARC pasan a formar parte de la aceptación.

El plano de control de la aplicación sigue siendo en gran medida del cliente. Una máquina virtual puede estar sana mientras la aplicación está caída debido a un despliegue fallido, disco lleno, certificado caducado o bloqueo de base de datos. La base de conocimiento de Ehost incluye artículos sobre discos llenos y errores de certificado, lo cual es contenido de soporte útil, pero también ilustra el límite compartido: el proveedor puede explicar un síntoma sin ser dueño de cada decisión de carga de trabajo.

Las operaciones deben, por tanto, asignar responsabilidades nombradas. Ehost puede poseer el hardware físico, la virtualización, las redes perimetrales y las copias de seguridad de la plataforma. El cliente puede poseer los sistemas operativos, las aplicaciones, las cuentas y la clasificación de datos. Un tercero puede poseer la licencia del panel de control, la CDN, la autoridad de certificación, el registro de dominio o la depuración DDoS. Durante un incidente, el ticket debe llegar a la parte que realmente puede actuar.

El paso comercial final es la renovación o la salida. Las páginas públicas muestran precios mensuales, pero algunos productos requieren mínimos de varios meses. El portal de facturación muestra períodos de tres meses para algunas ofertas de hosting, mientras que las licencias de DirectAdmin se muestran con mínimos de seis meses. Los compradores no deben confundir un precio unitario mensual con un derecho de terminación mes a mes.

El precio es transparente solo después de que la especificación es estable

Ehost publica más precios que muchos vendedores de infraestructura. Eso es útil. Una pequeña empresa puede ver que el alojamiento compartido comienza en 50.000 dongs al mes, el alojamiento empresarial en 300.000, la nube en 250.000, la copia de seguridad en 95.000, los servidores dedicados en 5,5 millones y la coubicación en la página pública en 1,8 millones. Los complementos tienen precios visibles: CPU cloud adicional, memoria, disco e IPv4; almacenamiento de hosting adicional, dominio o IP; espacio en rack, energía y actualizaciones de red.

Las cifras revelan el diseño económico de Ehost. El alojamiento compartido distribuye un servidor y la operación de soporte entre muchos clientes. Los paquetes cloud miden un paquete de recursos de cómputo, memoria, almacenamiento y capacidad de red. Los servidores dedicados cobran por hardware exclusivo. La coubicación cobra por espacio de rack, energía y conectividad escasos. Las copias de seguridad cobran principalmente por capacidad almacenada. Las licencias y los certificados agregan software de terceros o servicios de confianza.

Sin embargo, el precio publicado no es lo mismo que un precio fiable. Lacategoría de pedido de alojamiento empresarialcontiene una anomalía sorprendente: “Business-02” se muestra a 1.350 millones de dongs por tres meses, mientras que los paquetes cercanos están en cientos de miles. La misma página anuncia versiones heredadas de PHP y MariaDB. Sería irrazonable tratar la cifra de mil millones como la tarifa prevista de Ehost sin confirmación; se entiende mejor como evidencia de que el escaparate puede contener inconsistencias de entrada de datos o de ciclo de vida.

La coubicación muestra un problema de reconciliación más amplio. Lapágina pública de coubicaciónenumera paquetes 1U en VNPT Data, Viettel IDC y CMC por 3,2 millones, 2,8 millones y 1,8 millones de dongs al mes, generalmente con 200 Mbps de red nacional y 30 Mbps de ancho de banda internacional compartido. Lacategoría de coubicación del portal de facturaciónenumera ODS, Viettel IDC y VNPT Tân Thuận por 1,3 millones o 1,4 millones de dongs, con puertos de 100 Mbps y cuatro o diez Mbps de ancho de banda internacional. Las ubicaciones, capacidades y precios no son equivalentes.

Puede haber una explicación legítima: diferentes generaciones de rack, promociones, asignaciones de energía, períodos de compromiso, ofertas heredadas o rutas al mercado. Las páginas no la proporcionan. Un comprador que compare solo el número mensual destacado podría, por tanto, adquirir una clase de servicio diferente de la asumida.

El costo total debe incluir al menos:

• migración inicial, configuración del sistema operativo y validación de la aplicación;
• IVA y cualquier otro cargo aplicable;
• compromiso mínimo y términos de renovación;
• IPv4 pública, ancho de banda, tráfico internacional y opciones DDoS;
• panel de control, Windows, base de datos u otras licencias de software;
• capacidad de copia de seguridad, retención y cargos de restauración;
• soporte gestionado o trabajo remoto;
• reemplazo de hardware o tiempo de inactividad por actualización;
• dependencias de dominio, certificado y correo electrónico;
• asistencia para exportación, transferencia y transición de datos a la salida.

“Ancho de banda ilimitado” también necesita una definición. Varias páginas de Ehost usan el término mientras publican por separado tasas de puerto o ancho de banda internacional. Ilimitado puede significar razonablemente que no hay cargo por transferencia basado en uso, no rendimiento infinito o un circuito dedicado sin contención. El contrato debe distinguir la velocidad del puerto, la tasa de información comprometida, el comportamiento de ráfaga, la política de uso justo y las rutas nacionales frente a las internacionales.

Ehost puede seguir siendo competitivo en precio después de que se aclaren todos los términos. El registro público no es suficiente para calcular el margen, la sobresuscripción o el costo comparable frente a los rivales. Es suficiente para mostrar que la comparación de precios debe comenzar después de la reconciliación de productos, no antes.

La copia de seguridad es una promesa con dos períodos de retención

La copia de seguridad es donde el material público de Ehost es más útil y más contradictorio. La página cloud primero dice que toda la nube se respalda diariamente y las copias se conservan durante al menos siete días. En las notas del plan, dice que “Full Backup Daily” conserva los últimos catorce días y cobra 500.000 dongs por restauración. Ambas declaraciones aparecen en la misma página.

El alojamiento compartido sigue otra política. Las páginas personales y empresariales dicen que los datos se triplican en tiempo real y se respaldan semanalmente, con copias de seguridad conservadas durante dos meses. Unservicio de Cloud Backupseparado vende almacenamiento de 10 GB a 100 GB y dice que puede respaldar un disco completo para que un sistema operativo y las aplicaciones puedan moverse a hardware de reemplazo. Anuncia soporte técnico 24/7/365 y pago mensual.

Estas pueden ser capas distintas: replicación de plataforma, copia de seguridad de servicio incluida y copia de seguridad comprada por el cliente. Deberían ser distintas. La triplicación en tiempo real puede proteger contra un fallo de disco mientras reproduce instantáneamente la eliminación de un cliente o los datos cifrados por ransomware. Una instantánea de plataforma puede ayudar a Ehost a recuperar la infraestructura mientras no es adecuada para la restauración granular del cliente. Un servicio de copia de seguridad pago puede tener retención y aislamiento separados. Las páginas actuales no proporcionan un mapa único de esas capas.

Laguía de copia de seguridad y recuperaciónde OpenStack aclara las preguntas faltantes: la frecuencia de la copia de seguridad debe seguir la pérdida de datos aceptable; la retención y el almacenamiento fuera del sitio importan; y la prueba de recuperación es tan importante como la existencia de copias. Las afirmaciones públicas de Ehost no divulgan la ubicación de la copia de seguridad, la inmutabilidad, el cifrado, la separación administrativa, la política de eliminación, el objetivo de tiempo de restauración o los resultados de las pruebas.

Un comprador debe convertir "copia de seguridad incluida" en un cronograma:

1. Alcance:volumen de arranque, volúmenes adjuntos, bases de datos, almacenamiento de objetos, configuración del panel de control, buzones de correo y claves gestionadas por el cliente.
2. Punto de recuperación:la cantidad máxima de datos que se pueden perder en cada servicio.
3. Tiempo de recuperación:cuándo comienza Ehost a trabajar y cuándo debe regresar una carga de trabajo utilizable.
4. Retención:número exacto de copias recuperables y cómo se calcula la antigüedad.
5. Aislamiento:si las copias sobreviven al compromiso de la cuenta de producción, clúster o sitio.
6. Método de restauración:recuperación de máquina completa, a nivel de archivo, a nivel de base de datos y en ubicación alternativa.
7. Tarifas:restauraciones incluidas, cargos de emergencia y costos de salida de datos.
8. Evidencia:pruebas de restauración programadas con resultados registrados.

El conflicto entre siete y catorce días debe resolverse en el contrato, pero el problema más profundo es la responsabilidad. Si la aplicación de un cliente genera datos críticos, una copia de seguridad de Ehost no debería ser la única copia controlada a través de la misma cuenta y proveedor. El cliente necesita una ruta de exportación o replicación independiente cuyas credenciales y dominio de fallo difieran de la producción.

Respuesta en cinco minutos no es recuperación en cinco minutos

La superficie de soporte de Ehost es visible. El sitio principal proporciona contactos telefónicos y de correo electrónico; el portal de soporte ofrece tickets, una base de conocimiento, anuncios, descargas y estado del servidor. Lapágina de garantía de serviciodice que el soporte funciona 24/7 y que los clientes serán notificados por correo electrónico, teléfono o contacto directo cuando el mantenimiento requiera tiempo. Las páginas de servidores dedicados y servidores de juegos afirman una respuesta en cinco minutos a través de ticket, correo electrónico, línea directa o chat en vivo.

Son compromisos útiles, pero describen el acceso y la respuesta más que la resolución. Un acuse de recibo de cinco minutos puede confirmar que existe un incidente mientras el reemplazo de hardware, la conmutación por error de ruta o la restauración de datos lleva horas. Un cronograma de servicio serio necesita relojes separados para el acuse de recibo, la participación técnica, la solución alternativa, la restauración y el informe de causa raíz.

La severidad también importa. Un solo sitio web lento, un clúster de virtualización completo no disponible, una sospecha de exposición de datos y una pregunta de configuración rutinaria no deberían compartir una sola cola. Las páginas públicas no divulgan definiciones de severidad, roles de escalado, cobertura de idiomas, modelo de personal, autoridad fuera del horario laboral o remedios de crédito de servicio.

El portal de soporte proporciona una observación intrigante pero limitada. En el momento del acceso, tanto subase de conocimientocomo suárea de descargasmostraban un aviso genérico de que Ehost estaba al tanto de un problema que podría afectar el servicio. El detalle del estado del servidor enlazado no era recuperable públicamente en el momento de la revisión, por lo que no se pudo establecer el servicio afectado, la hora de inicio, la severidad, el impacto en el cliente ni la resolución. Esto no es evidencia de una interrupción material. Es evidencia de que existe un mecanismo de estado pero no produjo un registro público de incidentes utilizable.

No se encontró un historial de estado público completo, archivo posterior a incidentes o serie de tiempo de actividad medida de forma independiente. La ausencia de un archivo público no significa que Ehost no tenga incidentes o no tenga registros internos. Significa que un comprador debe solicitarlos. La diligencia útil incluiría los doce meses anteriores de disponibilidad por producto y sitio, recuentos de incidentes de severidad uno, tiempos medios de respuesta y restauración, historial de mantenimiento, informes de causa raíz de muestra y resultados de restauración de copias de seguridad.

El aviso de mantenimiento también debe hacerse medible. ¿Cuánto aviso se da para el trabajo planificado? ¿Qué acciones de emergencia están exentas? ¿Se excluye el mantenimiento de los cálculos de tiempo de actividad? ¿Puede un cliente reprogramar? ¿Ehost migra máquinas virtuales o las apaga? ¿Qué sucede con un sistema operativo no gestionado que no se recupera limpiamente?

El proveedor local más fuerte puede ser valioso precisamente porque un comprador puede llegar a un humano que conoce la infraestructura. Esa ventaja se vuelve contractual solo cuando la persona tiene autoridad, la cola es monitoreada, el escalado se prueba y la obligación de restauración es clara.

La seguridad son varios productos, no un escudo

El lenguaje de seguridad de Ehost abarca cortafuegos físicos, aislamiento de alojamiento compartido, AntiDDoS básico, mitigación DDoS paga, certificados SSL, copias de seguridad y soporte. Estos controles abordan diferentes amenazas y no deben colapsarse en una afirmación general de que una carga de trabajo es “segura”.

La página cloud dice que cada clúster tiene un cortafuegos físico y que las máquinas virtuales pueden integrarse con Antiddos.vn. La página de alojamiento empresarial dice que AntiDDoS básico puede activar automáticamente la protección de cortafuegos contra botnets más pequeños. Elsitio de AntiDDoSdescribe múltiples nodos proxy y cortafuegos en marcas de centros de datos vietnamitas, filtrando solicitudes maliciosas y proporcionando funciones de HTTP/2 y cortafuegos de aplicaciones web. Lacategoría de pedido de AntiDDoSde Ehost publica etiquetas de planes y algunos parámetros de volumen de solicitudes.

Son afirmaciones de la empresa sobre el diseño del servicio, no una validación independiente de la capacidad de mitigación. Las adquisiciones deben preguntar si la protección está siempre activada o se activa después de la detección; si cubre inundaciones de Capa 3/4, solicitudes de Capa 7 o ambas; a dónde se desvía el tráfico; qué ancho de banda limpio está comprometido; si las IP de origen se conservan; cómo se manejan las claves TLS; qué sucede con los protocolos no web; si los ataques desencadenan cargos adicionales; y si el origen sigue siendo accesible directamente.

La evidencia de recursos de red agrega otro límite. Los prefijos válidos de RPKI ayudan a prevenir orígenes de ruta no autorizados. No filtran solicitudes de aplicaciones maliciosas, detienen el robo de credenciales, parchean un sistema operativo del cliente o protegen una base de datos de una cuenta con demasiados privilegios. Por el contrario, un proxy web puede absorber ataques HTTP mientras deja expuestos los servicios de correo, VPN, juegos o bases de datos.

La seguridad de las cuentas también está subdocumentada. El registro público revisado aquí no establece si la autenticación multifactor es obligatoria o está disponible para cada superficie de cliente y administrador. Los compradores deben probar MFA, separación de roles, credenciales de API, verificación de identidad de soporte, registro de acceso privilegiado y desvinculación en lugar de inferir la implementación a partir de un lenguaje de seguridad general.

La ruta de abuso es igualmente poco clara. Los registros derivados de APNIC identifican al mantenedor de respuesta a incidentes de VNNIC en lugar de un escritorio de abuso de Ehost claramente anunciado, y el sitio principal expone contactos de ventas y soporte en lugar de una política de abuso dedicada. Eso no prueba que Ehost carezca de un proceso interno. Significa que un denunciante externo o cliente no puede verificar fácilmente la ruta para malware, spam, phishing, derechos de autor o abuso de red.

Un proveedor de hosting debería poder mostrar ingesta, autenticación, preservación de evidencia, notificación al cliente, estándares de suspensión y apelación.

La base de datos legal oficial de Vietnam enumera laLey de Protección de Datos Personales 91/2025/QH15como efectiva desde el 1 de enero de 2026. La aplicación de dicha ley depende de los hechos y debe ser evaluada por un asesor legal calificado. Para los compradores de Ehost, el requisito práctico es directo: el contrato debe identificar los roles de procesamiento, acceso de soporte, ubicación de datos, subprocesadores, cooperación en incidentes, retención, eliminación y exportación para el servicio real.

No se encontró un paquete de aseguramiento de seguridad público y específico del producto para Ehost: ningún certificado ISO con alcance, informe SOC, resumen de prueba de penetración, política de divulgación de vulnerabilidades, lista de subprocesadores o lista de materiales de software. Esta es una brecha de evidencia, no una prueba de que esos controles no existan. Se vuelve consecuente cuando el modelo de riesgo de un comprador requiere más que afirmaciones de primera parte.

La advertencia de ciclo de vida oculta en el escaparate

El catálogo público contiene señales de que la información del producto ha envejecido de manera desigual. Las páginas de alojamiento compartido describen soporte para versiones de PHP de 5.4 a 7.1 y MariaDB 10.1. El portal de facturación enumera por separado MultiPHP 5.5, 5.6 y 7.0 para algunos paquetes y PHP 7.0 con MariaDB 10.1 para una oferta de alto rendimiento.

Esas versiones no son actuales. Latabla de ramas no soportadasde PHP registra el fin de vida de PHP 5.4 en septiembre de 2015, PHP 7.0 en enero de 2019 y PHP 7.1 en diciembre de 2019. Latabla de mantenimiento de versionesde MariaDB Foundation sitúa el fin del mantenimiento de MariaDB 10.1 en octubre de 2020.

La interpretación responsable no es que Ehost definitivamente ejecute software expuesto al final de su vida útil en producción. Las páginas pueden estar obsoletas mientras la plataforma se ha actualizado. Esa distinción debe probarse. Las especificaciones obsoletas son en sí mismas un problema de control porque los clientes las usan para juzgar la compatibilidad y seguridad de las aplicaciones.

Un comprador de Ehost debería solicitar una matriz de tiempo de ejecución actual para cada grupo de alojamiento compartido: sistema operativo, servidor web, panel de control, ramas de PHP, versión de base de datos, configuración de TLS, cadencia de parches y fechas de desaprobación planificadas. Debería confirmar si los clientes pueden seleccionar versiones no soportadas para aplicaciones heredadas y, en tal caso, qué términos de aislamiento y riesgo se aplican.

Los paneles de control agregan dependencia del ciclo de vida de terceros. Ehost vendelicencias de DirectAdminy dice que algunas licencias “internas” están disponibles solo para servidores alojados en Ehost, con pago mínimo de varios meses. Un cliente que combina cómputo de Ehost, una licencia suministrada por Ehost, DNS, certificados y copias de seguridad puede recibir un soporte integral conveniente. También crea un paquete que debe desenredarse durante la migración.

La referencia de la página cloud a procesadores Intel Broadwell proporciona otra pista desactualizada, mientras que la página de servidores dedicados anuncia configuraciones más nuevas de Xeon Gold y Platinum y la categoría de facturación C6 afirma IOPS mucho más altas. Esto parece múltiples generaciones de infraestructura en lugar de una flota uniforme. Eso es normal para un host de larga duración, pero la política de ubicación importa. El comprador debe saber si un plan se asigna a una generación de CPU y clase de almacenamiento definidas o a cualquier grupo que tenga capacidad.

La gobernanza del ciclo de vida debería cubrir más que versiones. Debería especificar el aviso para migraciones de host, cambios de panel de control, retiro de imágenes de sistema operativo, fin de vida del hardware, renumeración de IP, cambios de marca de certificado y paquetes descontinuados. El portal de soporte incluso contiene una categoría etiquetada como “EOL”, aunque su contenido no estaba disponible en la evidencia congelada. Una política de ciclo de vida publicada permitiría a los clientes planificar en lugar de descubrir el retiro a través de una renovación o incidente.

La competencia prueba a Ehost en evidencia, no en escala

Ehost compite en varios mercados a la vez. En alojamiento compartido, se enfrenta a hosts locales y plataformas de sitios web. En máquinas virtuales, se enfrenta a nubes de telecomunicaciones vietnamitas, proveedores especializados de VPS e hiperescaladores globales. En servidores dedicados y coubicación, se enfrenta a operadores de centros de datos, integradores de sistemas y contratos directos de instalaciones. Para copias de seguridad, CDN y DDoS, los clientes pueden comprar un servicio especializado de forma independiente.

La ventaja más creíble de Ehost no es la escala global. Es la posibilidad de una relación operativa local: paquetes denominados en VND, contacto telefónico y por ticket directo, ayuda en la migración, instalaciones vietnamitas, paquetes simples y un solo proveedor para servicios de hosting, servidor, rack y protección. Una pequeña empresa sin un gran equipo de infraestructura puede valorar a un proveedor dispuesto a inspeccionar un sistema y recomendar una configuración práctica.

El desafío es que las alternativas nacionales más grandes publican un nivel diferente de aseguramiento.VNPT Cloudanuncia un SLA del 99,99%, soporte IPv6, un catálogo de servicios gestionados más amplio y certificaciones de seguridad nombradas. Esas son afirmaciones de VNPT, no una prueba independiente de que cada carga de trabajo funcionará mejor. Ilustran la comparación de adquisiciones que Ehost debe cumplir: ¿qué nivel de servicio, capacidad de doble pila, evidencia de cumplimiento, arquitectura y alcance gestionado recibe el comprador por el precio?

Los hiperescaladores globales ofrecen APIs, regiones y servicios gestionados que el catálogo público de Ehost no iguala. También pueden introducir exposición a moneda extranjera, precios complejos, soporte distante y una arquitectura que un cliente pequeño tiene dificultades para operar. Un servidor autogestionado en coubicación ofrece el máximo control del hardware pero transfiere el parcheo, los repuestos y la recuperación al cliente. Una plataforma de software gestionada puede eliminar la administración del servidor pero aumentar el bloqueo a nivel de aplicación.

La prueba de competencia correcta es, por tanto, específica del flujo de trabajo:

• Para un sitio web tipo folleto, el alojamiento compartido puede ser más barato y simple que cualquier nube.
• Para una aplicación vietnamita que necesita soporte local predecible, la nube de Ehost o el hardware dedicado pueden ser atractivos si la especificación del servicio está verificada.
• Para una carga de trabajo regulada, el alcance del aseguramiento, el proceso de incidentes y los términos de datos pueden superar el precio destacado.
• Para una aplicación distribuida globalmente, IPv6, rutas internacionales, escalado automático y diseño multirregión pueden dominar el soporte local.
• Para un juego sensible a la latencia, el reloj de CPU, la respuesta DDoS, el peering nacional y la pérdida de paquetes en tiempo de ataque importan más que la marca genérica de “nube”.

La única discusión antigua de clientes independientes encontrada en el registro público revisado, unhilo de foro de hosting vietnamita, contiene una anécdota favorable sobre el servicio y soporte de Ehost. Tiene años de antigüedad, es informal y no representativa. El propio sitio de Ehost también publica testimonios positivos sin suficiente detalle para verificar identidad, producto o fecha. Ninguno debe sustituir las referencias actuales de clientes que ejecuten una carga de trabajo comparable.

Ehost no necesita demostrar que es el proveedor más grande. Necesita demostrar que su modelo de servicio local le da a un cliente particular más control por dong que las alternativas realistas.

Los costos de cambio aparecen una dependencia a la vez

La infraestructura a menudo se describe como portátil porque una máquina virtual puede copiarse. En la práctica, el costo de cambio se acumula fuera de la imagen de la máquina.

La primera capa es eldireccionamiento. Una carga de trabajo que use IPv4 asignado por Ehost puede necesitar renumerarse cuando salga. El DNS puede ocultar parte del cambio, pero las listas de permitidos, los pares VPN, los sistemas de pago, la reputación del correo y las APIs de terceros pueden contener la dirección antigua. El propio espacio de direcciones portátil de Ehost es visible, pero los términos públicos no dicen si un cliente puede traer o transferir recursos IP.

La segunda capa es elalmacenamiento y las copias de seguridad. Una imagen de disco puede omitir instantáneas, metadatos de objetos, historial de copias de seguridad o detalles de cifrado del lado del proveedor. La página de eStorage no publica una API de exportación ni un cronograma de salida. Una restauración que funciona solo dentro de Ehost es protección de continuidad, no portabilidad.

La tercera capa es elsoftware de control. Las configuraciones de cPanel o DirectAdmin, cuentas de correo, jerarquías de revendedor, certificados y trabajos programados deben ser reconstruidos o convertidos. Una licencia interna vinculada al hosting de Ehost puede terminar cuando el servidor se mueva, requiriendo una nueva licencia y quizás una migración del panel de control.

La cuarta capa es laprotección de red. Si un dominio apunta a través de un proxy DDoS o CDN vinculado a Ehost, la salida requiere un cambio de DNS, reconfiguración de certificado y origen, exportación de registros y eliminación cuidadosa de la ruta antigua. La migración en tiempo de ataque es especialmente difícil porque el origen puede quedar expuesto durante la transición.

La quinta capa es elconocimiento operativo. El soporte de Ehost puede saber por qué un servidor usa una ruta, kernel, excepción de cortafuegos o diseño de almacenamiento particulares. Si ese conocimiento reside en tickets en lugar de documentación del cliente, una relación de soporte exitosa crea dependencia.

La coubicación tiene costos de salida físicos. El cliente necesita acceso autorizado, una ventana de mantenimiento, embalaje, transporte, destrucción de datos para medios retirados y una nueva ruta. Si Ehost suministra espacio IP o manos remotas, esos servicios terminan al mismo tiempo que la máquina se mueve.

La evidencia pública no proporciona una política completa de terminación, exportación o eliminación. La página de inicio de Ehost dice que hay una política de reembolso cuando un servicio no se usa, y las FAQ de alojamiento personal dicen que el valor no utilizado puede acreditarse al actualizar. La página de garantía aborda el aviso de soporte y mantenimiento. Ninguna de esas páginas establece la elegibilidad de reembolso, el aviso de terminación, la duración del acceso a datos, el formato de exportación, la evidencia de eliminación o la asistencia de transición para todos los servicios.

Se debe acordar un cronograma de salida antes de la puesta en marcha. Debe proporcionar al cliente exportaciones e instantáneas actuales; suficiente acceso de lectura; procedimientos de transferencia de DNS y dominio; soporte de migración de buzones; historial de registros y tickets cuando sea relevante; un cronograma para eliminar el acceso del proveedor; confirmación de eliminación; pasos de liberación de hardware para coubicación; y cargos predecibles. El cliente debe ensayar al menos una restauración o migración a otro entorno mientras la relación es saludable.

Una prueba de adquisición que coincida con la superficie real de Ehost

Ehost debe evaluarse con evidencia que corresponda a sus afirmaciones y brechas específicas, no un cuestionario genérico de nube.

1. Reconciliar el registro comercial

Pídale a Ehost que identifique el catálogo de productos autorizado y explique las diferencias entre la página pública de Servidor en la Nube, la tienda SSD Cloud Server y la tienda C6. Exija un cronograma de configuración firmado. Haga lo mismo para los paquetes de coubicación públicos y del portal de facturación. Confirme los impuestos, el compromiso, la renovación, el reembolso, la restauración y los cargos de actualización.

2. Probar la máquina entregada

Durante una prueba, registre el modelo de CPU y el tiempo de robo, la memoria disponible, el disco utilizable, las IOPS sostenidas y de ráfaga, la latencia bajo carga, la tasa de interfaz y el rendimiento nacional e internacional. Realice pruebas en varios momentos en lugar de tratar un punto de referencia como una garantía. Compare el resultado con el formulario de pedido.

3. Mapear los dominios de fallo de OpenStack

Solicite la versión de OpenStack, el hipervisor, el backend de almacenamiento, el diseño de zonas de disponibilidad, la redundancia del plano de control y el proceso de mantenimiento. Pida un fallo controlado de host de cómputo o una prueba reciente documentada. Establezca si el reinicio de instancias, la recuperación de volúmenes y la restauración entre sitios son capacidades separadas.

4. Probar la ruta, no la lista de centros de datos

Confirme qué ASN y prefijos usa el producto, si las direcciones son de Ehost o espacio de instalaciones, y si IPv6 está disponible. Pregunte cómo AS135920 sobrevive a la pérdida de AS135905 y cómo cambian las rutas cuando se activa AntiDDoS. Pruebe desde las principales redes de acceso vietnamitas y desde ubicaciones internacionales. Registre la pérdida de paquetes y los cambios de ruta durante un mantenimiento o conmutación por error simulada.

5. Convertir la copia de seguridad en un ejercicio de recuperación

Resuelva el conflicto de retención cloud de siete contra catorce días. Seleccione un archivo, una base de datos y una recuperación de máquina completa. Elimine o corrompa datos de prueba, luego mida el punto de recuperación, la respuesta del operador, el tiempo de restauración, la consistencia resultante y la tarifa. Verifique si existe una copia en un sitio separado o fuera de línea.

6. Definir soporte por severidad

Abra tickets a través de cada canal prometido. Confirme que 24/7 significa un respondedor calificado, no solo recepción. Contrate objetivos separados de acuse de recibo y restauración, contactos de escalado, aviso de mantenimiento y entrega de causa raíz. Obtenga el rendimiento histórico para el producto y sitio que se está adquiriendo.

7. Inspeccionar los controles de seguridad y abuso

Pruebe MFA, separación de roles, recuperación de cuentas y verificaciones de identidad de soporte. Revise la propiedad de parches, el aislamiento de inquilinos, el registro, la gestión de vulnerabilidades, la arquitectura DDoS y el acceso privilegiado. Obtenga las políticas de privacidad y servicio reales que el portal de soporte enumera pero que no fueron recuperables públicamente en esta investigación. Confirme una ruta de abuso dedicada y un proceso de manejo de evidencia.

8. Verificar el ciclo de vida y la portabilidad

Solicite las versiones de software compatibles actuales y las fechas de desaprobación. Exporte una VM, base de datos, conjunto de buzones, cuenta de panel de control y copia de seguridad. Confirme qué licencias terminan al salir. Si la coubicación está involucrada, ensaye el acceso físico autorizado y la liberación de equipos.

Esta prueba no exige documentación de hiperescalador a un operador pequeño. Le pide a Ehost que respalde las promesas que ya hace: recursos definidos, alta disponibilidad, copias de seguridad, soporte rápido, varias instalaciones, seguridad y cuidado operativo local.

Las preguntas sin respuesta son parte del producto

El registro público revisado establece más de lo que a menudo es visible para un host local. Hay una empresa exacta, precios en vivo, sistemas activos de soporte y facturación, un amplio catálogo de servicios, un sistema autónomo, cinco prefijos IPv4 enrutados, cobertura RPKI y direcciones receptivas en la ciudad de Ho Chi Minh. También revela un proveedor que continúa publicando nuevo contenido de 2026 y ofertas más nuevas de servidores dedicados o C6.

No establece ingresos auditados, participación de mercado, número de clientes, escala de personal, propiedad de instalaciones, volumen de tráfico, número de servidores, capacidad de ruta o tiempo de actividad real. La estimación de dominios alojados de IPinfo no puede convertirse en clientes porque un cliente puede operar muchos dominios y un dominio puede usar solo una parte del servicio de Ehost. Un recuento público de prefijos no puede convertirse en capacidad de cómputo.

No establece que las instalaciones “Tier 3” nombradas en el marketing de Ehost estén certificadas para los racks y servicios exactos vendidos, o que Ehost posea las instalaciones. No establece diversidad física o de portador a partir de una lista de múltiples sitios. No establece que cada dirección cubierta por RPKI reciba protección DDoS.

No establece un SLA completo. La cifra pública del 99,5% carece de un marco de medición y remedio visible, mientras que la redacción de “tiempo de actividad absoluto” en servidores dedicados no es un sustituto creíble de términos acotados. No se pudo acceder a un cronograma de reembolso completo.

No establece versiones de tiempo de ejecución actuales. Las referencias antiguas de PHP y MariaDB pueden ser copia obsoleta o compatibilidad en vivo; solo un inventario de plataforma actual puede distinguirlas. No establece una versión o topología de OpenStack.

No establece aislamiento de copias de seguridad, rendimiento de recuperación o un período de retención autorizado. No establece un historial de incidentes, aunque el portal de soporte expone un mecanismo de estado y mostró un aviso de problema genérico. No establece certificación de seguridad independiente, alcance de prueba o manejo de abuso.

Estas no son razones para declarar la empresa no adecuada. Son dimensiones del servicio que permanecen privadas, específicas del contrato o no resueltas. Para un sitio web de bajo riesgo, un cliente puede aceptar razonablemente menos profundidad documental y confiar en una migración probada más copias de seguridad independientes. Para un sistema crítico para los ingresos, regulado o propenso a ataques, las mismas brechas se convierten en bloqueadores de adquisición hasta que Ehost proporcione evidencia.

Qué observar a continuación

Cinco señales mejorarían materialmente la confianza en la superficie de control de Ehost.

Primero,convergencia del catálogo. Las páginas públicas de productos y el portal de facturación deberían describir los mismos paquetes, o marcar claramente generaciones y fechas. Eliminar precios inverosímiles y referencias de tiempo de ejecución no soportadas haría del escaparate una parte fiable del servicio.

Segundo,desarrollo de red. La validez continua de RPKI es positiva. La originación pública de IPv6 y un diseño de upstream o peering demostrablemente diverso reducirían las preguntas sin respuesta sobre accesibilidad y ciclo de vida. Si Ehost mantiene intencionalmente un upstream público, debería explicar el mecanismo de resiliencia detrás de esa elección.

Tercero,transparencia operativa. Una página de estado utilizable con marcas de tiempo de incidentes, productos afectados, actualizaciones y resolución convertiría el enlace de estado existente en evidencia. Las métricas periódicas de disponibilidad y restauración harían verificables las afirmaciones de tiempo de actividad y copias de seguridad.

Cuarto,cierre de políticas. El sitio de Ehost enlaza páginas de privacidad, uso del servicio, envío y garantía, y su portal de soporte enumera una descarga de la política de servicios de EHOST. Publicar términos actuales y accesibles para reembolsos, uso aceptable, abuso, procesamiento de datos, soporte, SLA, copias de seguridad, terminación y eliminación reduciría el costo de negociación para ambas partes.

Quinto,disciplina de ciclo de vida. Una matriz de software actual, política de versiones de OpenStack y cronograma de avisos para grupos de hardware, paneles de control y productos al final de su vida útil mostraría que Ehost gestiona la larga cola creada por un catálogo amplio.

La red pública de Ehost no es imaginaria. Cinco prefijos enrutados y una huella de hosting activa son más persuasivos que un muro de logotipos de infraestructura no verificados. Pero un anuncio de ruta es solo el borde exterior del servicio. El cliente depende de la base de datos de pedidos, el sistema de aprovisionamiento, el hipervisor, el almacenamiento, las instalaciones, el portador, las copias de seguridad, la cola de soporte y el contrato que están detrás.

Por eso importan las dos descripciones de Cloud 1G de 250.000 dongs. Exponen el lugar exacto donde una relación de hosting puede volverse controlable o ambigua. Si Ehost y el comprador pueden reconciliar la especificación, probar la ruta y la ruta de recuperación, asignar la responsabilidad en caso de fallo y preservar una salida, la amplitud local de la empresa puede ser una ventaja. Si esas preguntas permanecen dentro de páginas web inconsistentes, el servidor más barato aún no ha adquirido un precio fiable.