De RDS a Aurora: cuándo compensa y cómo moverse sin una parada larga

"¿Deberíamos pasar a Aurora?" se plantea como una pregunta de rendimiento y suele ser una pregunta de coste y de operación. La respuesta honesta depende de cuatro números que puedes medir esta semana.

Cuándo gana Aurora

Necesitas más de una réplica de lectura y las necesitas rápidas. Las réplicas de Aurora comparten la capa de almacenamiento, así que el retardo de réplica suele ser de milisegundos en lugar de los segundos de la replicación asíncrona de RDS, y añadir una no copia los datos. Si tu plan de escalado de lecturas pasa por cinco réplicas, Aurora es sencillamente mejor.

El tiempo de failover importa. Aurora conmuta en unos 30 segundos; RDS Multi-AZ tarda uno o dos minutos. Si esa diferencia tiene significado de negocio, es un argumento real.

Tu almacenamiento crece y no quieres gestionarlo. El almacenamiento de Aurora crece solo en incrementos de 10 GB hasta 128 TB, y pagas lo que usas en vez de lo que aprovisionaste. En RDS, los volúmenes gp3 sobredimensionados son un coste silencioso clásico.

Tienes una carga a ráfagas. Aurora Serverless v2 escala la capacidad en incrementos finos y es de verdad buena para entornos de staging, herramientas internas y cargas con noches tranquilas. Ten cuidado con usarla como primaria de producción con carga estable, donde las instancias aprovisionadas son más baratas.

Cuándo te quedas en RDS

Carga estable y predecible en una sola instancia. Aurora cobra la E/S en la configuración estándar, y una carga intensiva de escritura puede hacer esa línea mayor que la propia instancia. Aurora I/O-Optimized elimina el cargo de E/S a cambio de un precio de instancia mayor y merece la pena cotizarla si la E/S supera en torno al 25 por ciento de tu factura de Aurora — pero si hoy estás en RDS con carga predecible, el cambio puede salir más caro.

Necesitas una extensión o versión de Postgres o MySQL que Aurora no soporta. Comprueba tu lista de extensiones antes que nada. Esto mata más migraciones a Aurora que el coste.

Tu base de datos es pequeña. Por debajo de unos pocos cientos de GB con tráfico moderado, RDS Multi-AZ sobre gp3 es más simple y más barato, y las diferencias operativas apenas se notan.

La migración que deja la parada corta

Para Aurora MySQL y Aurora PostgreSQL desde el motor RDS equivalente, el camino es el mismo y es el que hay que usar:

1. Crea una réplica de lectura Aurora de la instancia RDS. AWS lo hace de forma nativa. Tarda horas en una base grande y no impacta al origen más allá de la carga de replicación.
2. Espera a que el retardo de réplica llegue a cero y se mantenga durante un pico. Vigila AuroraReplicaLag, no el resumen de la consola.
3. Prueba contra la réplica. Apunta una copia de tu aplicación en solo lectura y ejecuta tus consultas más lentas. El planificador de Aurora se parece al del motor original pero no es idéntico; las consultas que se degradan son casi siempre las de joins más complejos.
4. La ventana de corte. Para las escrituras en la capa de aplicación —una bandera de mantenimiento, no una regla de cortafuegos—, espera retardo cero, promociona la réplica Aurora, reapunta la aplicación por DNS o cadena de conexión y reanuda las escrituras. Hecho con cuidado son 30 a 60 segundos.
5. Deja la instancia vieja parada pero sin borrar una semana. El plan de vuelta atrás es "reapuntar", y solo existe si el origen sigue ahí.

Para saltos entre motores o versiones, la herramienta es Database Migration Service con replicación continua, y deberías presupuestar varias veces más de pruebas. DMS se ocupa de los datos; no se ocupa con elegancia de secuencias, tipos personalizados ni tus procedimientos almacenados.

Qué comprobar después

• Grupos de parámetros. Los valores por defecto de Aurora no son los de RDS. Compara tus parámetros afinados de forma explícita; max_connections en particular se calcula distinto.
• Copias y retención. Las copias de Aurora son continuas con restauración a un punto en el tiempo, pero backtrack (solo MySQL) es una función aparte que hay que activar, y es la forma más rápida de deshacer un script de migración malo.
• El endpoint de lectura. Manda tráfico de lectura ahí a propósito desde la aplicación, o habrás pagado réplicas que no hacen nada.
• El coste un mes después. Repite la comparación con cifras reales de E/S y cambia a I/O-Optimized si las cuentas lo dicen.

Los movimientos de base de datos son la parte de un proyecto cloud donde planificar la vuelta atrás se paga sola, y donde gastamos la mayor parte del presupuesto de pruebas.

Qué hacer esta semana

Saca cuatro números de CloudWatch para tu instancia RDS principal: IOPS de escritura, almacenamiento usado frente a aprovisionado, retardo de réplica y el p99 de tu consulta más lenta. Esos cuatro deciden la pregunta de Aurora antes de que nadie abra una calculadora de precios.