Por qué los equipos dejan AWS, DigitalOcean, Hetzner y Vultr
El tráfico de búsqueda de una alternativa a AWS sin KYC está dominado por personas que ya tienen algo en producción. Eso importa, porque cambia la pregunta de qué nube es más barata a qué se rompe si me muevo. Tres desencadenantes explican la mayor parte de los casos. El primero es una exigencia de identidad que llega a posteriori: una cuenta que llevaba un año facturando sin problemas queda de pronto limitada hasta que se sube un documento. El segundo es la factura: el cómputo se había previsto, el egress no. El tercero es más silencioso y suele llegar el último: la constatación de que una cuenta cloud corporativa es un registro duradero, con forma de citación judicial, de quién opera qué.
Los cuatro nombres del titular no son equivalentes. AWS, DigitalOcean y Vultr son empresas estadounidenses con estructuras corporativas estadounidenses; Hetzner es alemana y tiene precios lo bastante agresivos como para que se le tolere el papeleo. Lo que comparten no es una política concreta, sino una capacidad: cada una retiene un instrumento de pago verificado y se reserva el derecho de pedir más, a su discreción, sobre una cuenta sobre la que ya has construido. La alternativa no es una política más amable, sino un proveedor que directamente nunca recopila ese material, que es precisamente nuestra postura no-KYC.
SP·02Qué verifica cada hyperscaler antes de poder arrancar una instancia
Ayuda separar la superficie de verificación en capas, porque sin ID requerido suele ser cierto y suele ser irrelevante. La capa uno es la dirección de correo y, cada vez más, un número de teléfono que debe aceptar un SMS: ya son dos identificadores que la mayoría reutiliza en todas partes. La capa dos es la tarjeta de pago, y es la capa que hace el trabajo real: la tarjeta fue emitida por un banco que realizó una verificación de identidad completa, de modo que el proveedor hereda una identidad legal verificada sin pedirte nunca un documento. La capa tres, invocada de forma selectiva, es la solicitud de documentación —ID, un selfie, un extracto bancario— normalmente activada por una puntuación de riesgo que nunca ves.
Por eso pagar una nube estadounidense con una moneda de privacidad comprada en un exchange vinculado a una tarjeta casi no cambia nada: la identidad ya quedó establecida en la capa dos antes de que entrara en juego cualquier cripto. Eliminar el KYC del hosting significa eliminar la relación de crédito que lo exige, no cambiar el riel de pago acoplado encima de ella. La guía sobre un VPS sin verificación de identidad cubre en detalle el lado de la cuenta, y pagar el hosting de forma anónima cubre el lado de la financiación, incluidos los eslabones de la cadena que delatan a la gente. El glosario define los términos usados en todo el sitio.
SP·03Tarjetas pospago frente a un saldo prepago en cripto
La diferencia estructural entre ambos modelos es el crédito. Un hyperscaler te deja consumir primero y factura después, lo que te convierte en deudor durante un mes a la vez, y nadie concede crédito a una contraparte anónima. La verificación de identidad no es un añadido a la facturación pospago: es lo que la hace posible. Invierte el sentido y la exigencia se disuelve. Un saldo prepago no conlleva riesgo de crédito, así que no hay nada que suscribir ni motivo para saber quién eres. Ese es el mecanismo real detrás de un servidor cloud sin verificación de identidad, y merece la pena entenderlo antes de que empiece a sonar a marketing.
En la práctica: una cuenta es un nombre de usuario y una contraseña, con ocho códigos de recuperación emitidos en el registro y sin correo electrónico en ningún punto del proceso. Recargas entre $30.00 y $5,000.00 cada vez, en cualquiera de las 8 monedas y variantes de red disponibles en 7 divisas, con Monero y Bitcoin listados primero. Los despliegues y las renovaciones debitan después ese saldo internamente: sin factura, sin espera de confirmación, un VPS en línea en unos 15 min. El saldo no utilizado es reembolsable en cripto dentro de los 30 días posteriores a la recarga que lo generó, menos las comisiones de red. La mecánica completa, incluida la escala de bonificaciones en recargas mayores, está en la facturación por saldo prepago, explicada; el tutorial con Monero muestra una recarga de principio a fin.
SP·04Egress, ancho de banda y la factura que nadie prevé
El egress medido es la partida que con más frecuencia dispara la búsqueda que te ha traído aquí. El cómputo es fácil de modelar —horas de instancia por una tarifa—, mientras que el egress depende de lo popular que resulte ser tu proyecto, que es precisamente la cifra que no puedes prever. Alrededor conviven los medidores accesorios: transferencia entre zonas, unidades de capacidad del balanceador de carga, horas de gateway y cargos por gigabyte al recuperar tus propias copias de seguridad. Un mes de éxito inesperado llega en forma de factura y no de cuello de botella, y la arquitectura acaba moldeada por la hoja de precios.
Nuestra respuesta es plana. Cada plan de VPS incluye un puerto sin medición —1 Gbps en toda la gama, 2 Gbps en el mayor— y el precio mensual es el precio total. No hay una franquicia de transferencia que agotar ni cargo por gigabyte a la salida, por lo que los medios, los destinos de backup, los mirrors y las salidas VPN suelen ser los primeros en migrar. La mitigación L3/4 de 1.5 Tbps viene de serie y no como complemento medido. Sin medición no significa sin normas, y fingir lo contrario sería deshonesto: la política de uso aceptable sigue aplicándose, y el spam, el mando y control de malware y el CSAM se retiran en cuanto se detectan.
SP·05Jurisdicción: quién puede acceder a tus datos una vez dejas las nubes estadounidenses
Dejar una nube estadounidense cambia el sistema legal al que responde tu infraestructura, y eso suele ser un efecto mayor que el precio. Un proveedor constituido en EE. UU. es alcanzable por un requerimiento estadounidense sin importar qué bandera ondee sobre el centro de datos, porque la matriz corporativa es el punto de presión, no el rack. Elegir un proveedor fuera de esa estructura traslada la cuestión a otro conjunto de tribunales, con otros estándares sobre lo que debe contener una orden antes de que alguien actúe en consecuencia. Es un cambio real, no una escapatoria: siempre hay alguien con jurisdicción, y lo que eliges es de quién.
Hay 6 regiones entre las que elegir. Bucarest y Ámsterdam facturan a la tarifa base y ofrecen la conectividad europea más sólida; Zúrich, Reikiavik, Kuala Lumpur y Ciudad de Panamá aplican cada una un modificador regional que se muestra en vivo en el configurador, y cada una ofrece algo distinto: protección de datos reglada por ley, un marco de libertad de prensa, latencia en Asia-Pacífico fuera de los Five Eyes, o ninguna ley de retención de datos. Las contrapartidas se analizan región por región en qué ubicación offshore deberías elegir y desde el punto de vista legal en jurisdicciones de hosting offshore comparadas. Nuestra posición no cambia: los avisos DMCA no se procesan ni se responden —la DMCA es una ley estadounidense sin fuerza en nuestras jurisdicciones, y solo actuamos ante una orden vinculante de un tribunal con jurisdicción sobre el servidor concreto—. Lo que esa frase cubre y lo que no se explica en qué significa realmente el «hosting que ignora la DMCA».
SP·06Cómo equiparar una instancia de AWS o DigitalOcean a un plan sin KYC
La mayoría de las migraciones son más pequeñas de lo que parecen. Una instancia de propósito general es un número de vCPU, una cifra de memoria y un disco, y la escala de VPS sin KYC recorre Drift, Shelf, Slope, Abyss y Hadal desde $8.00/mes —las especificaciones exactas están en la página de planes, no aquí, donde quedarían desactualizadas. Vale la pena romper dos hábitos durante el traslado. El primero es dimensionar según el tipo de instancia en lugar de según la medición real: un vCPU dedicado en EPYC con NVMe se comporta de forma distinta a una instancia ráfaga (burstable) que lleva meses siendo limitada en silencio, y el reemplazo honesto suele estar un peldaño por debajo de lo que sugiere la etiqueta antigua.
El segundo es tratar el almacenamiento como infinito. El almacenamiento en bloque que añades por terabyte bajo demanda pasa a ser una cifra fija de NVMe por plan, así que una carga de trabajo a la que se le ha dejado crecer sin control necesita una cifra real antes de mudarse. Por encima de la escala de VPS, el hardware dedicado empieza en $66.00/mes y es donde encaja todo lo que corre sobre una instancia de gama metal grande; está disponible en Bucarest, Ámsterdam y Zúrich, y el aprovisionamiento tarda 2–12 h en lugar de minutos.
SP·07Lo que realmente pierdes al abandonar un hyperscaler
Esta es la sección que la mayoría de las guías de migración omiten. Estás cambiando una plataforma gestionada por root en un servidor, y la diferencia es trabajo real. No hay servicio de almacenamiento de objetos gestionado, ni base de datos relacional gestionada, ni runtime serverless, ni plano de control de Kubernetes gestionado, ni sistema de identidad y accesos con políticas por rol, ni grupo de autoescalado que añada instancias silenciosamente a las tres de la madrugada porque una cola se ha llenado. Todo lo que alquilabas como servicio pasa a ser algo que instalas, monitorizas, parcheas y respaldas tú mismo. Hay 6 regiones en lugar de decenas, así que una presencia edge verdaderamente global no está sobre la mesa. La facturación es mensual y prepago en lugar de por segundo, lo que conviene a las cargas estables y penaliza a las que tienen picos.
También hay un techo de cumplimiento normativo, y merece decirse sin rodeos: si el auditor de un cliente necesita un proveedor con nombre, un acuerdo de tratamiento de datos firmado y un informe de certificación, un proveedor que deliberadamente no conserva documentos de identidad no va a satisfacer ese cuestionario —este incluido. No es una carencia que pretendamos cerrar: es una consecuencia directa del modelo, no un descuido. Sopesa la contrapartida contra tu propio modelo de amenazas, no contra el nuestro. La tabla comparativa nos sitúa junto a otros diez proveedores de hosting privado bajo los mismos criterios, y las preguntas frecuentes responden a las cuestiones operativas que esta guía mantiene deliberadamente breves.
SP·08Qué cargas de trabajo migran limpiamente y cuáles deberían quedarse
Los que migran limpiamente son los que solo usaban un hyperscaler como una máquina Linux con buena red. Salidas VPN y túneles personales —consulta cómo montar tu propio WireGuard— junto con relés de Tor, correo autoalojado, sitios estáticos e instalaciones de CMS, backends de aplicaciones y videojuegos, runners de CI, scrapers, mirrors y cualquier cosa intensiva en egress. Ninguno de ellos conlleva una dependencia de servicios gestionados, y el puerto plano sin medición suele hacerlos más baratos y más simples al mismo tiempo.
Los que deberían quedarse donde están son igual de identificables. Todo lo que está soldado a un servicio gestionado propietario es una reescritura y no una migración, y una reescritura disfrazada de mudanza es la forma en que fracasan las migraciones. Todo lo genuinamente elástico —tráfico que varía en un orden de magnitud según un horario— es precisamente para lo que sirven la facturación por segundo y los grupos de autoescalado. Todo lo que está bajo un régimen de cumplimiento que exige proveedores nombrados se queda donde ya está el papeleo. Un parque dividido es un resultado legítimo, no una admisión de derrota: traslada las cargas de VPS offshore que se benefician de ello, y deja el resto exactamente donde está.
SP·09Paso a paso
-
01
Haz inventario de lo que el hyperscaler realmente hace por ti
Antes de calcular ningún precio, enumera todos los servicios de la cuenta, no solo las instancias. Las bases de datos gestionadas, los buckets de almacenamiento de objetos, las colas, los certificados, las zonas DNS, las tareas programadas y los roles IAM son la migración; el cómputo es la parte fácil. Todo lo que aparezca en esa lista sin un reemplazo autoalojado es una decisión que tomar, no una tarea que programar.
-
02
Abre una cuenta y recarga un saldo prepago
El registro consiste en un nombre de usuario y una contraseña: sin correo, sin teléfono, sin tarjeta. Guarda los ocho códigos de recuperación fuera de línea antes de continuar: si pierdes la contraseña y los ocho códigos, la cuenta es irrecuperable, porque no existe una vía de restablecimiento por correo a la que recurrir. Después, recarga desde $30.00 en la moneda que prefieras.
-
03
Dimensiona el reemplazo y elige la región
Toma las cifras de CPU y memoria que has medido, no las que aprovisionaste, y elige un peldaño en la escala. Elige la región primero por su perfil legal y en segundo lugar por su latencia, y después consulta el modificador regional en el configurador antes de confirmar. Un VPS está en línea en unos 15 min; el hardware dedicado tarda 2–12 h.
-
04
Reconstruye las piezas gestionadas antes de mover ningún dato
Levanta los reemplazos y demuestra que funcionan mientras la pila antigua sigue sirviendo tráfico: PostgreSQL o MariaDB en lugar de la base de datos gestionada, un servidor de almacenamiento de objetos o disco simple en lugar del bucket, un proxy inverso en lugar del balanceador de carga gestionado, y tu propia automatización de certificados. Endurece la máquina sobre la marcha: SSH solo con clave, un firewall de denegación por defecto, actualizaciones de seguridad desatendidas.
apt update && apt full-upgrade -y apt install -y ufw fail2ban unattended-upgrades ufw allow OpenSSH ufw enable
-
05
Sincroniza los datos y luego vuelve a sincronizarlos
Haz una primera copia masiva mientras el servicio antiguo sigue activo, y luego una segunda pasada breve en el momento del corte para capturar la diferencia. Las bases de datos se trasladan con un dump y una restauración, o con replicación si el margen de inactividad es ajustado. Ensaya la restauración en la máquina nueva antes de confiar en ella: una copia de seguridad sin probar no es una copia de seguridad.
rsync -aHAX --numeric-ids --info=progress2 /srv/ root@newhost:/srv/ pg_dump -Fc appdb | ssh root@newhost 'pg_restore -d appdb'
-
06
Baja el TTL del DNS y luego realiza el corte
Reduce a 300 segundos el TTL de cada registro que vayas a mover, con al menos un día de antelación, para que el valor antiguo haya caducado en las cachés de todas partes antes de conmutar. Cambia los registros, vigila los logs de ambos servidores hasta que el antiguo quede en silencio, y luego vuelve a subir el TTL.
dig +noall +answer example.com A dig +noall +answer +trace example.com A
-
07
Da de baja el servidor antiguo de forma deliberada, no inmediata
Dale a la migración un ciclo de facturación completo antes de borrar nada: la instancia antigua es tu plan de reversión, y cuesta como mucho un mes más. Cuando tengas confianza, exporta lo que estés obligado a conservar, borra los datos, elimina el método de pago y luego cierra la cuenta, en ese orden. Cerrar una cuenta no borra el registro de que existió, que es precisamente el argumento para no abrir la siguiente.


