Migración de AWS Lightsail/EC2 a un servidor dedicado: ahorre entre $500 y $2000 al mes

La migración de AWS a servidores dedicados (dedicated) permite reducir los gastos de infraestructura de 5 a 10 veces: un proyecto con un presupuesto de $1000/mes en instancias EC2 y base de datos RDS se traslada a un único servidor físico potente con un costo de $120–180 sin pérdida de rendimiento ni de tolerancia a fallos.

¿Por qué la migración de AWS a Dedicated ahorra hasta el 80% del presupuesto?

La razón principal del alto costo de AWS es el recargo por la abstracción y los pagos «ocultos» que son difíciles de predecir. Cuando un proyecto supera la etapa de MVP, los servicios en la nube comienzan a consumir el presupuesto de manera desproporcionada al crecimiento del tráfico. El Aws cost reduction al pasar a hardware dedicado se logra no solo por el precio del alquiler, sino también al eliminar el pago por cada gigabyte de tráfico, cada solicitud al disco (IOPS) y cada hora de funcionamiento del balanceador de carga.

Trampas ocultas en la facturación de AWS

En AWS, pagas por todo. Por ejemplo, un NAT Gateway cuesta alrededor de $32 al mes solo por existir, más $0.045 por cada gigabyte transferido. Si tu backend se comunica activamente con APIs externas o descarga actualizaciones, el NAT Gateway puede generar cientos de dólares en gastos innecesarios. En un servidor dedicado, el NAT se configura de forma gratuita mediante iptables o nftables.

Diferencia entre vCPU y núcleos físicos

Las instancias EC2 (excepto las series bare metal) utilizan vCPU, que son hilos (hyper-threading) en procesadores físicos compartidos. Si tu «vecino» en el hipervisor comienza a hacer ruido, el rendimiento de tu aplicación cae (CPU Steal). En un servidor dedicado, obtienes el 100% de los recursos del procesador. Un procesador AMD Ryzen 9 7950X en un servidor dedicado ofrece de 3 a 4 veces más rendimiento por hilo que una instancia estándar m5.xlarge, costando mucho menos.

Para aquellos que buscan opciones más económicas para backends pequeños, existe una AWS EC2 alternative para backend, donde se pueden reducir los gastos incluso en la etapa de uso de servidores virtuales.

Caso 1: Plataforma SaaS — de $800 en AWS a $120 en un servidor dedicado

Un proyecto SaaS típico en AWS a menudo consta de 3-4 instancias EC2 (t3.large), una base de datos RDS (db.t3.medium), Redis en ElastiCache y S3 para el almacenamiento de archivos. A esto se suma el Application Load Balancer (ALB) y los cargos por tráfico. En promedio, este stack cuesta entre $750 y $900 al mes.

Análisis de recursos del proyecto SaaS

• EC2 (App layer): 3 nodos de 2 vCPU / 8 GB RAM — $150/mes.
• RDS (Database): Multi-AZ, 2 vCPU / 4 GB RAM — $200/mes.
• ElastiCache (Redis): $60/mes.
• Tráfico (Egress): 5 TB — $450/mes.

Solución en Dedicated

En lugar de una dispersión de instancias débiles, utilizamos un solo servidor con un procesador Intel Xeon E-2388G, 64 GB de RAM y 2x960 GB NVMe. Todos los componentes (App, DB, Redis) se empaquetaron en contenedores Docker. Gracias al exceso de memoria RAM, la base de datos comenzó a funcionar más rápido, ya que la mayor parte de los índices ahora caben en la RAM (Buffer Pool).

Costo final: $120/mes. Ahorro: $680/mes o $8,160 al año. Al mismo tiempo, el margen de rendimiento aumentó 5 veces.

Caso 2: Proyecto de E-commerce — cómo reducir la factura de $2000 a $250

Las grandes tiendas online en AWS sufren por el costo del almacenamiento EBS y el tráfico durante las temporadas de rebajas. En nuestro caso, el proyecto utilizaba instancias de la serie C5 para alta potencia de cómputo y RDS Aurora. La Aws migration en este caso fue motivada no solo por el precio, sino también por las latencias del subsistema de discos.

Problemas de rendimiento en la nube

En AWS, EBS (Elastic Block Store) tiene límites de IOPS. Para obtener 10,000 IOPS, debes pagar por Provisioned IOPS, lo que aumenta drásticamente la factura. En un servidor dedicado con discos NVMe, obtienes más de 500,000 IOPS «out of the box» sin cargos adicionales. Para la base de datos de una tienda online, esto significa una generación instantánea de páginas de categorías y búsquedas rápidas.

Comparación de configuraciones para E-commerce

Parámetro	AWS (c5.4xlarge + Aurora)	Dedicated (AMD Ryzen 7950X)
Procesador	16 vCPU (Compartido)	16 Cores / 32 Threads (Dedicado)
Memoria RAM	32 GB	128 GB DDR5
Sistema de discos	EBS (IOPS limitados)	2x1.92 TB NVMe (Enterprise)
Tráfico	De pago ($0.09/GB)	Ilimitado (1 Gbps)
Precio final	~$2,100/mes	~$240/mes

Para proyectos que temen bloqueos o dificultades con el pago, es importante considerar una Hetzner alternative, ya que los low-costers europeos a menudo requieren verificaciones difíciles de superar.

Plan técnico: cómo se realiza la migración desde AWS paso a paso

Una migración de aws exitosa requiere preparación. No puedes simplemente transferir un Snapshot AMI a un servidor dedicado directamente, ya que AMI es un formato de imagen propietario para el hipervisor Xen/KVM en el entorno de AWS. El proceso se basa en la transferencia de datos y configuraciones.

Etapa 1: Preparación del servidor de destino

Instala un SO limpio (Ubuntu 22.04/24.04). Configura la seguridad básica: SSH por llaves, UFW, fail2ban. Si utilizabas AWS RDS, necesitarás instalar MySQL/PostgreSQL localmente o en Docker.

# Ejemplo de configuración básica de firewall
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Etapa 2: Sincronización de archivos

Utiliza rsync para transferir archivos estáticos y de usuario. Es más eficiente que descargar archivos comprimidos.

rsync -avz -e "ssh -i key.pem" --progress /var/www/html/ ubuntu@new-server-ip:/var/www/html/

Etapa 3: Transferencia de la base de datos

Para bases de datos pequeñas (hasta 50 GB), basta con mysqldump o pg_dump. Para bases de datos grandes, es mejor configurar una replicación (Master-Slave), donde AWS RDS sea el maestro (a través de External Master) y tu nuevo servidor sea el esclavo.

Si utilizabas AWS Lightsail, el proceso será similar, pero con menos configuraciones de red. Puedes leer más sobre el traslado desde nubes simples en el artículo cómo mudarse de DigitalOcean: snapshots, DNS, cutover fluido.

A qué renunciar al mudarse: RDS, ALB y CloudWatch

El proceso de leaving aws consiste en renunciar a los servicios «cómodos» en favor de sus alternativas open-source. Muchos temen perder la Managed Database (RDS), pero en el hardware moderno, la administración de bases de datos se ha vuelto más sencilla gracias a las herramientas de automatización.

Reemplazo de AWS RDS

RDS ofrece copias de seguridad automáticas y parches. En un servidor dedicado, esto se reemplaza con la combinación de cron + restic (para backups en almacenamiento compatible con S3) y unattended-upgrades para la seguridad del SO. El rendimiento de un PostgreSQL instalado manualmente en NVMe será superior al de RDS con los mismos recursos, debido a la ausencia de latencias de red de EBS.

Reemplazo de Application Load Balancer (ALB)

El ALB en AWS es costoso y tiene limitaciones de configuración. Nginx o HAProxy en un servidor dedicado cumplen esta tarea mejor. Obtienes control total sobre los encabezados, el almacenamiento en caché y las reglas de enrutamiento.

# Ejemplo de proxy simple en Nginx
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Reemplazo de S3 y CloudWatch

• S3: Si necesitas almacenamiento de objetos, utiliza Minio en tu propio servidor o cámbiate a servicios compatibles con S3 más económicos (Backblaze B2, Wasabi).
• CloudWatch: Se reemplaza por el stack Prometheus + Grafana. Esto ofrece un monitoreo más detallado con una frecuencia de muestreo de 1 segundo, mientras que el CloudWatch gratuito ofrece 1 o 5 minutos.

Al elegir un nuevo proveedor, vale la pena comparar ofertas. Por ejemplo, OVH Eco vs Valebyte es una excelente comparativa para quienes buscan un equilibrio entre precio y confiabilidad en Europa.

Cutover seguro: minimizamos el tiempo de inactividad durante el traslado

El momento más crítico de la migración aws to dedicated es el cambio de DNS. Para evitar la pérdida de datos y minimizar el downtime, sigue una estrategia de cambio gradual.

Algoritmo de cambio

1. Reduce el TTL en los registros DNS a 300 segundos (5 minutos) un día antes del traslado.
2. Pon la aplicación en AWS en modo "Mantenimiento" (Read-only).
3. Realiza el volcado final de la base de datos y la sincronización de archivos.
4. Despliega los datos en el nuevo servidor.
5. Verifica el funcionamiento del sitio por IP o dominio temporal.
6. Cambia los registros A en el DNS a la IP del nuevo servidor dedicado.

Para proyectos que requieren máxima disponibilidad, se puede usar Nginx en el servidor antiguo como un reverse proxy que redirija el tráfico a la nueva IP mientras se actualizan las cachés de DNS en todo el mundo.

Alternativas y estrategia a largo plazo después de dejar AWS

Una vez finalizada la aws migration, notarás que el costo fijo del servidor permite planificar mejor el presupuesto. No más sorpresas al final del mes debido a picos de tráfico o ataques de bots.

Elección de ubicación y proveedor

Al elegir un servidor dedicado, es importante considerar la conectividad con tu audiencia. Si tus usuarios están en Europa, los servidores en los Países Bajos o Alemania garantizarán un ping mínimo. A diferencia de AWS, donde el tráfico entre regiones es costoso, muchos proveedores de servidores dedicados ofrecen 100 TB o tráfico ilimitado.

Escalamiento en Dedicated

Si un servidor se queda corto, puedes alquilar un segundo y configurar una red privada (Private Network) entre ellos. Esto permitirá mover la base de datos a una máquina separada, imitando la estructura de AWS, pero por una fracción de su costo. Para tareas auxiliares pequeñas, puedes usar una AWS Lightsail alternative para no pagar de más por la infraestructura de gestión.

Conclusiones

Para ahorrar entre $500 y $2000 al mes, lo óptimo es trasladar la carga de AWS a servidores dedicados con discos NVMe y procesadores modernos (Ryzen 9 o Xeon serie E). El ahorro principal se logra al dejar de pagar por el tráfico y pasar de vCPUs virtuales a núcleos físicos reales, lo que permite que un solo servidor de $150 reemplace una infraestructura en la nube de $1000.