Migraciones y costes cloud: pagar por lo que usáis y cambiar sin sustos
Saber en qué se va cada parte de la factura, recortar lo que sobra y, si compensa, cambiar de proveedor con pruebas y un plan para volver.
Herramientas habituales
- ClickHouse
- Elasticsearch
- Kafka
- Kubernetes
- Hetzner
- MongoDB
- MySQL
- Proxmox
En resumen
Una revisión de costes cloud es un análisis de lo que pagáis a vuestro proveedor para separar lo necesario de lo que sobra. Revisamos la factura de AWS, Google Cloud o Azure y os proponemos por escrito qué recortar y cuánto esfuerzo lleva. Si compensa cambiar de proveedor, por ejemplo a Hetzner, planificamos la migración con pruebas previas y un plan de vuelta atrás.
- Idiomas
- Español, catalán o inglés
- Respuesta
- El siguiente día hábil, en horario laboral
- Método
- En vuestra cuenta y vuestro repositorio, en código y documentado
Qué incluye
- Desglose de la factura por servicio, entorno y equipo, con etiquetas si no las hay.
- Lista de recursos sobredimensionados, olvidados o huérfanos.
- Propuesta de ahorro priorizada por impacto y esfuerzo, por escrito.
- Alertas de presupuesto para que la factura no sorprenda.
- Plan de migración por fases, con criterios para avanzar o volver atrás.
- Infraestructura de destino en código (Terraform).
- Migración de datos con verificación y ventana de corte pactada.
- Informe final con el antes y el después.
¿Por qué sube la factura cloud?
Casi nunca por un único motivo. Lo que encontramos con más frecuencia al revisar una cuenta:
- Máquinas y bases de datos con el tamaño que se eligió el primer día y nunca se revisó.
- Entornos de prueba o de demostración que siguen encendidos meses después.
- Discos, instantáneas e IP sin uso que se pagan cada mes.
- Tráfico de salida y transferencias entre zonas que nadie había calculado.
- Registros y métricas guardados más tiempo del necesario.
- Compromisos de uso o reservas que no se aprovechan.
¿Qué medida conviene primero?
No todas las medidas de ahorro cuestan lo mismo ni tienen el mismo riesgo. En la propuesta las ordenamos así:
| Medida | Esfuerzo | Riesgo | Cuándo tiene sentido |
|---|---|---|---|
| Apagar o borrar lo que no se usa | Bajo | Bajo, si se confirma antes | Siempre, es lo primero |
| Ajustar tamaños de máquinas y bases de datos | Bajo a medio | Medio, se prueba antes | Cuando el uso medio es muy inferior a lo contratado |
| Apagar entornos de prueba fuera de horario | Bajo | Bajo | Entornos que solo se usan en horario laboral |
| Reducir retención de logs y métricas | Bajo | Bajo, si se acuerda | Cuando se guarda más de lo que se consulta |
| Compromisos de uso o reservas | Bajo | Medio, por la permanencia | Cargas estables con al menos un año por delante |
| Cambiar de proveedor | Alto | Medio a alto | Cargas estables y equipo que asume más mantenimiento |
Cambiar de proveedor no siempre es pasar a otra nube: a veces es llevar las máquinas virtuales a servidores propios con Proxmox VE, o sustituir un servicio gestionado del proveedor por uno propio, como una caché con Valkey.
¿Cómo hacemos una migración entre proveedores?
Una migración no es copiar máquinas: es reconstruir el entorno en el destino, probarlo y cambiar el tráfico cuando todo cumple. Este es el orden:
Inventario y dependencias
Qué servicios hay, de qué servicios gestionados del proveedor dependen y qué alternativa tienen en el destino.
Destino en código
Red, máquinas, bases de datos y permisos en Terraform, para poder repetirlo y revisarlo.
Réplica de datos
Copia inicial y sincronización continua hasta el día del cambio.
Pruebas
Carga y funcionalidad en el destino, con criterios escritos de qué tiene que cumplirse.
Cambio y vuelta atrás
Ventana pactada, cambio de DNS o de balanceador y un plan probado para volver al origen.
¿Qué pasa con los datos personales?
Si movéis datos personales, el proveedor y la región importan. Elegimos con vosotros centros de datos en la Unión Europea cuando hace falta y dejamos por escrito dónde está cada dato. Si vamos a tratar esos datos durante la migración, firmamos antes el contrato de encargado del tratamiento.
¿Qué experiencia tenemos?
Desde la dirección técnica hemos gestionado el presupuesto de la nube de una plataforma con un 99,9 % de disponibilidad, y como DevOps en un SaaS B2B hemos trabajado con entornos en varios proveedores descritos en código. Conocemos AWS, Google Cloud, Azure, Hetzner y DigitalOcean, y lo que cuesta de verdad cada uno cuando se suma el mantenimiento.
Preguntas frecuentes
¿Cuánto se puede ahorrar?
Depende de cada cuenta y no damos una cifra antes de mirarla. La revisión os dice qué ahorro es posible, qué esfuerzo lleva cada medida y qué riesgo tiene, para que decidáis con datos.
¿Compensa irse de AWS a Hetzner?
A veces sí y a veces no. Compensa con cargas estables y equipos que pueden mantener más piezas; no compensa si dependéis de muchos servicios gestionados o necesitáis presencia en varias regiones. Lo comparamos con vuestros números.
¿Habrá corte de servicio durante la migración?
Se planifica para que sea mínimo: réplica de datos previa, pruebas en el destino y una ventana de corte pactada. Si algo no cumple los criterios, se vuelve al origen.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el