Con el carrito y las sesiones fuera, mercadofresco-pedidos respira. Las 180.000 escrituras diarias han desaparecido, el VACUUM ya no compite por la E/S los viernes por la tarde y el 35 % de la capacidad de la instancia ha quedado libre. Pero la instancia sigue siendo la misma que creamos en 02-04: una db.t3.small con PostgreSQL 16, Multi-AZ, una réplica de lectura y un almacenamiento que crece 12 GB al mes.

Y sigue teniendo tres problemas que el módulo 5 dejó documentados. La conmutación por error de Multi-AZ tarda entre 60 y 120 segundos, que un viernes a las 19:00 son entre 900 y 1.800 pedidos en el aire. El retardo de la réplica de lectura sube a 8 segundos en el pico, lo suficiente para que un cliente confirme un pedido y no lo vea en su historial. Y la instancia se paga entera las 24 horas, también de madrugada, cuando hay tres pedidos por hora.

Amazon Aurora es la base de datos relacional que AWS diseñó específicamente para la nube, compatible con PostgreSQL y MySQL, pero con una arquitectura interna completamente distinta a la de RDS. En esta lección Marta entiende esa arquitectura, decide entre instancias provisionadas y Serverless v2 con el perfil de carga real de MercadoFresco, y migra mercadofresco-pedidos con un corte de servicio de menos de dos minutos.

Aviso de coste. Aurora es más caro por hora de cómputo que RDS y, según el modelo, cobra la E/S aparte. Un clúster de pruebas olvidado cuesta decenas de dólares al mes. Borra lo que crees para practicar. Todos los datos son ficticios y las cifras, estimaciones de eu-west-1.

Aviso de cumplimiento. mercadofresco-pedidos contiene datos personales de clientes (nombre, dirección de reparto, teléfono, historial de compra). Cualquier operación de este módulo —clonación, restauración de copia, réplica— crea una copia completa de esos datos y queda sujeta al RGPD. El cifrado con alias/mercadofresco-datos es obligatorio, y la anonimización antes de entregar datos a desarrollo debe estar revisada por el responsable de protección de datos.

1. Qué es Aurora y en qué se diferencia de RDS
2. La separación entre cómputo y almacenamiento
3. El volumen distribuido: seis copias sobre tres zonas
4. Por qué desaparecen los checkpoints
5. Componentes del clúster
6. Puntos de enlace: clúster, lectura y personalizados
7. Conmutación por error y tiempos reales
8. Réplicas de lectura con retardo de milisegundos
9. Compatibilidad con PostgreSQL y MySQL
10. Aurora Serverless v2 y las unidades ACU
11. Cuándo compensa Serverless v2 y cuándo no
12. Escalado automático de réplicas de lectura
13. Copias continuas, PITR y backtrack
14. Clonación rápida por copia en escritura
15. Global Database, Aurora ML y consultas paralelas
16. Migración de mercadofresco-pedidos a Aurora
17. Comprobaciones antes y después con las métricas del módulo 5
18. Blue/Green deployments para esquema y versiones
19. Costes y el modelo I/O-Optimized
20. Errores comunes y consejos
21. Ejercicios
22. Conclusión

RDS es PostgreSQL —el mismo software que se instalaría en un servidor propio— gestionado por AWS: AWS aplica los parches, hace las copias y gestiona la conmutación por error, pero el motor y su almacenamiento son los de siempre, con un volumen EBS conectado a una instancia.

Aurora reescribe la capa de almacenamiento. Conserva el motor de consultas de PostgreSQL —por eso los SELECT de MercadoFresco funcionan sin tocar una línea— pero sustituye todo lo que hay por debajo por un servicio de almacenamiento distribuido propio.

Esta es la idea central y de ella se derivan casi todas las ventajas. En una base de datos tradicional, la instancia es la base de datos: contiene el motor, la caché y los ficheros de datos. Si la instancia muere, hay que arrancar otra y recuperar los datos.

En Aurora, la instancia solo contiene el motor de consultas y la caché. Los datos viven en un servicio de almacenamiento independiente, compartido por todas las instancias del clúster.

Las consecuencias prácticas son directas:

• Añadir una réplica no copia datos. Se arranca una instancia que se conecta al volumen que ya existe. Tarda minutos, no horas, y no consume E/S del escritor.
• El almacenamiento crece solo. No hay que aprovisionar 500 GB «por si acaso» ni ampliar el volumen a las tres de la mañana. Se paga por lo que se usa, en incrementos de 10 GB.
• La conmutación por error no mueve datos. Se promueve una réplica que ya está conectada al mismo volumen; es un cambio de rol, no una recuperación.
• Cambiar el tamaño de la instancia es rápido, porque los datos no se mueven.

Aurora mantiene seis copias de cada bloque de datos, repartidas entre tres zonas de disponibilidad, dos por zona. El quórum de escritura es de 4 de 6 y el de lectura, de 3 de 6.

Esos números tienen una consecuencia concreta y verificable:

Es decir, Aurora tolera perder una zona de disponibilidad entera sin perder capacidad de escritura, y una zona más un disco adicional sin perder capacidad de lectura. Compárese con mercadofresco-pedidos en RDS Multi-AZ: dos copias, y la pérdida de la principal exige una conmutación de uno a dos minutos.

Además, la reparación es automática y por bloques: si un segmento se corrompe, Aurora lo reconstruye desde el quórum en segundo plano sin que nadie se entere.

PostgreSQL escribe primero en el registro de rehacer (WAL) y periódicamente vuelca las páginas modificadas de memoria al disco: eso es un checkpoint. Es una operación de E/S intensa y periódica que produce los picos de latencia que se ven en el panel mercadofresco-produccion cada pocos minutos.

Aurora solo envía el registro de rehacer al almacenamiento. No manda páginas de datos: son los nodos de almacenamiento los que aplican los registros y materializan las páginas, de forma continua y distribuida. Consecuencias:

• No hay checkpoints y desaparecen sus picos de latencia.
• El tráfico de escritura hacia el almacenamiento se reduce mucho —AWS habla de un orden de magnitud— porque se envía el registro, no las páginas completas.
• La recuperación tras un fallo es casi instantánea: no hay que reproducir un registro largo, porque el almacenamiento ya está al día.

Esta es la razón técnica de que Aurora rinda más que PostgreSQL sobre EBS con la misma clase de instancia, y de que la conmutación por error baje de minutos a segundos.

Detalle que confunde a mucha gente: hay dos grupos de parámetros. El de clúster contiene lo que afecta a todas las instancias y al volumen (rds.logical_replication, zona horaria); el de instancia contiene lo específico de cada una (work_mem, max_connections). Cambiar el parámetro en el sitio equivocado no da error: simplemente no hace nada.

Aurora ofrece varios nombres DNS, y usar el que no toca es un error habitual y caro.

El punto de enlace de clúster sigue a la conmutación por error: cuando se promueve una réplica, el DNS apunta a ella en segundos. Por eso la aplicación debe usarlo siempre, y por eso hay que asegurarse de que el cliente no cachea DNS más allá del TTL (Java, por defecto, cachea para siempre: hay que ajustar networkaddress.cache.ttl).

Los puntos de enlace personalizados resuelven un problema real que MercadoFresco tenía en 02-04: si Sara lanza una consulta pesada contra el punto de enlace de lectura, puede caerle a la misma réplica que sirve la tienda. Con un punto de enlace personalizado que agrupe solo aurora-mf-lector-informes, sus consultas quedan aisladas en una instancia que nadie más usa.

Cuando la instancia de escritura falla, Aurora promueve una réplica. Como todas comparten volumen, no hay datos que copiar ni registro que reproducir.

La prioridad de niveles (tiers) merece atención: Aurora promueve la réplica de nivel más bajo y, a igualdad, la de mayor tamaño. Si MercadoFresco pone la réplica de informes en el nivel 15, se garantiza que nunca acabe siendo el escritor de producción una instancia dimensionada para otra cosa.

Traducido al viernes a las 19:00: con RDS se pierden entre 900 y 1.800 pedidos de ventana; con Aurora, entre 150 y 450. No es cero —hay que reintentar igualmente— pero es la diferencia entre un incidente y un parpadeo.

En RDS, una réplica de lectura es otra base de datos que recibe el registro y lo aplica. Ese trabajo tarda, y en el pico del viernes mercadofresco-pedidos-lectura acumula 8 segundos de retardo.

En Aurora, la réplica lee del mismo volumen. No aplica registros para materializar datos: solo invalida las páginas que tenga cacheadas. El retardo típico es de 10 a 20 milisegundos.

La consecuencia funcional es la que le importa a Luis: hoy, tras confirmar un pedido, la aplicación no puede leer de la réplica porque el pedido podría no estar. Con 15 ms de retardo, esa lectura pasa a ser segura en la práctica, y toda la carga de «mostrar el historial» puede irse al punto de enlace de lectura. Con una salvedad honesta: 15 ms no es cero. Para la lectura inmediatamente posterior a una escritura crítica —comprobar el stock antes de cobrar— se sigue usando el punto de enlace de clúster.

Aurora ofrece dos ediciones y hay que elegir la que coincide con el motor de origen. MercadoFresco usa PostgreSQL 16, así que va a Aurora PostgreSQL: la aplicación, el controlador, las consultas y las extensiones funcionan igual.

Lo que hay que revisar antes de dar la migración por trivial:

• Extensiones. Aurora admite un catálogo amplio, pero no idéntico al de PostgreSQL. Hay que comprobar con SELECT * FROM pg_available_extensions que las que usa MercadoFresco (pg_trgm, postgis para las zonas de reparto) están disponibles.
• Versiones. Aurora va por detrás de la versión más reciente de PostgreSQL. Si el origen es 16 y Aurora ofrece 16.x, no hay problema; si el origen fuera 17, habría que esperar.
• Parámetros. Algunos parámetros de PostgreSQL no existen en Aurora porque su almacenamiento los hace irrelevantes; los relacionados con checkpoints son el ejemplo evidente.
• Réplica lógica hacia fuera. Funciona, pero conviene verificarla si hay integraciones que la usen.

Aurora Serverless v2 sustituye la clase de instancia fija por una capacidad que escala de forma continua, medida en ACU (Aurora Capacity Units). Una ACU equivale aproximadamente a 2 GiB de memoria con la CPU y la red proporcionales.

Se configura un mínimo y un máximo —de 0 a 256 ACU, en incrementos de 0,5— y Aurora ajusta la capacidad en segundos, sin cortar conexiones. Es la diferencia esencial con la v1, que pausaba y reanudaba con cortes de decenas de segundos.

Tres decisiones del comando que conviene entender. --manage-master-user-password hace que Aurora cree y rote la contraseña en Secrets Manager, integrándose con lo que montamos en 04-03 en vez de duplicar el mecanismo. MinCapacity=0.5 no es cero: el clúster nunca se detiene del todo, así que la primera consulta del día no espera un arranque. Y MaxCapacity=8 es el techo que limita la factura si una consulta se descontrola: sin él, un Seq Scan accidental puede escalar mucho y cobrarlo.

La respuesta depende del perfil de carga. Este es el de MercadoFresco, medido en el módulo 5:

Media ponderada: ≈2,4 ACU. Con instancias provisionadas habría que dimensionar para el pico —una db.r6g.large, 2 vCPU y 16 GiB— y pagarla las 168 horas de la semana.

Serverless v2 compensa con carga variable con valles profundos (el caso de MercadoFresco), en entornos de desarrollo y preproducción que solo se usan en horario de oficina, y cuando el pico es difícil de predecir. No compensa con carga plana 24×7 —una instancia provisionada con Reserved Instances es más barata—, cuando se necesita una factura exactamente previsible, o cuando la carga sostenida es tan alta que el máximo se toca siempre.

Un matiz honesto: por ACU, Serverless v2 es más caro por unidad de capacidad que una instancia provisionada equivalente. Solo gana si de verdad se aprovecha el valle. Con la carga de MercadoFresco, el valle nocturno son 49 de 168 horas semanales: se aprovecha, y mucho.

Independientemente de Serverless v2, Aurora escala el número de réplicas con Application Auto Scaling, en función de la CPU media de las réplicas o del número de conexiones.

El enfriamiento de reducción (600 s) es mayor que el de aumento (300 s) por la misma razón que en el ASG de 02-01: es preferible escalar rápido y reducir despacio. Y con Serverless v2, cada réplica nueva escala también su capacidad, así que ambos mecanismos se combinan.

Las copias son continuas y hacia S3, sin ventana ni impacto en el rendimiento, porque las hace el almacenamiento y no la instancia. La retención se configura entre 1 y 35 días; MercadoFresco usa 14.

PITR permite restaurar a cualquier segundo dentro de la retención, siempre a un clúster nuevo. Esto es importante: no se «deshace» sobre el clúster existente. Restaurar y redirigir la aplicación lleva de 10 a 20 minutos.

Backtrack es distinto y solo existe en Aurora MySQL: rebobina el clúster en el sitio, en segundos, hasta 72 horas atrás. Es la herramienta ideal para deshacer un UPDATE sin WHERE. Como MercadoFresco usa PostgreSQL, no dispone de ella, y conviene decirlo claramente porque es un error frecuente contar con backtrack en un clúster PostgreSQL. La alternativa en PostgreSQL es la restauración PITR a un clúster nuevo, más lenta pero igual de efectiva.

La clonación crea un clúster nuevo que comparte el volumen del original y solo consume almacenamiento propio para los bloques que cambien: es copy-on-write. Un clon de una base de datos de 340 GB tarda minutos y arranca ocupando prácticamente cero.

Usos: probar una migración de esquema con volumen real, reproducir una incidencia con los datos exactos del momento, medir el impacto de un índice nuevo antes de crearlo en producción.

Advertencia de RGPD. Un clon contiene todos los datos personales de los clientes: nombres, direcciones, teléfonos e historial de compra. Entregárselo a desarrollo sin más es una cesión interna de datos personales que casi con seguridad no está amparada por la base legal con la que se recogieron. El procedimiento correcto en MercadoFresco es: clonar, ejecutar inmediatamente un guion de anonimización que sustituya los datos identificativos por valores sintéticos manteniendo la distribución estadística, y solo entonces dar acceso al clon; cifrarlo con la misma clave, y establecer un borrado automático a los 7 días. Este procedimiento debe estar documentado y revisado por el responsable de protección de datos antes de usarse, y su ejecución queda registrada en trail-mercadofresco. Un clon anonimizado es una herramienta excelente; un clon sin anonimizar en un portátil es una brecha de datos esperando a ocurrir.

Y una advertencia de coste: el clon empieza barato pero crece a medida que diverge. Si Luis ejecuta una migración que reescribe la mitad de las tablas, el clon acaba ocupando la mitad del original. Los clones son de usar y tirar; el borrado automático a los 7 días también es una medida de coste.

Aurora Global Database replica el clúster a otras regiones con un retardo típico inferior a un segundo, mediante replicación en la capa de almacenamiento que no consume capacidad del escritor. Permite lecturas locales de baja latencia y recuperación regional con RPO de aproximadamente un segundo y RTO de un minuto. MercadoFresco no lo necesita hoy —opera en España desde eu-west-1—, pero es la palanca del plan de expansión a Francia o Portugal: la lectura del catálogo y del historial se serviría localmente y las escrituras seguirían viajando a Irlanda.

Aurora Machine Learning permite llamar a SageMaker o Bedrock desde SQL, con funciones que reciben columnas y devuelven predicciones. Un caso plausible para MercadoFresco sería puntuar el riesgo de impago de un pedido dentro de la propia consulta. Se menciona para que se sepa que existe; su desarrollo queda fuera de este curso.

Consultas paralelas (solo en Aurora MySQL) empujan parte del filtrado y la agregación a la capa de almacenamiento, acelerando mucho las consultas analíticas. Es tentador para los informes de Sara, pero MercadoFresco usa PostgreSQL y, sobre todo, ese problema tiene una respuesta mejor: Redshift, en 06-04. Aurora no debe convertirse en el almacén analítico.

Hay dos caminos, y la elección depende de cuánto corte se tolera.

MercadoFresco usa la segunda: se crea una réplica de lectura de Aurora a partir de la instancia RDS, que se mantiene sincronizada mediante replicación; cuando el retardo es cero, se promueve.

La ventana de conmutación, minuto a minuto: se activa el modo mantenimiento de la tienda (una respuesta 503 servida desde CloudFront, que se prepara en 03-04); se comprueba que el retardo es 0; se promueve el clúster con promote-read-replica-db-cluster; se cambia el punto de enlace en el parámetro /mercadofresco/produccion/basedatos/endpoint de Parameter Store; se reinicia el ASG con una actualización continua; y se desactiva el modo mantenimiento. Tiempo objetivo: 90 segundos.

Y la regla que no se negocia: la instancia RDS original no se borra hasta pasados 7 días de funcionamiento estable. Cuesta 118 USD al mes; una reversión de emergencia sin ella cuesta muchísimo más.

Sin línea base no hay forma de demostrar que la migración mereció la pena. Se captura la semana anterior y se compara con la semana posterior:

Dos comprobaciones que no son métricas y son igual de obligatorias. Primera, provocar una conmutación por error a propósito con failover-db-cluster fuera de hora punta y medir cuánto tarda de verdad la aplicación en recuperarse: casi siempre el cuello no es Aurora sino el pool de conexiones del cliente, que sigue intentando la conexión antigua. Segunda, restaurar una copia y comprobar que los datos están completos, que es la lección que 05-05 dejó aprendida.

Un despliegue azul/verde de Aurora crea un clúster verde que es una copia sincronizada del clúster azul de producción. Se aplican los cambios en verde —una versión nueva del motor, un ALTER TABLE largo, un índice nuevo— mientras azul sigue sirviendo; se prueba; y el cambio de rol tarda menos de un minuto, con AWS verificando antes que la replicación está al día.

Ventajas frente a hacerlo en caliente: el ALTER TABLE sobre una tabla de 340 GB no bloquea nada en producción, se puede probar el rendimiento real con la carga replicada, y la reversión es cambiar de nuevo el rol.

Limitaciones que hay que conocer: el clúster verde cuesta dinero mientras existe (se duplica el cómputo), no se admite cualquier cambio de esquema —los que rompen la replicación lógica, como eliminar una columna usada en la clave primaria, no— y hay que revisar qué pasa con las secuencias tras el cambio de rol. Para MercadoFresco es la vía por defecto de las actualizaciones de versión y de las migraciones de esquema grandes, y se combina con lo que se verá en el módulo 8.

Aurora cobra cuatro conceptos: cómputo (por hora de instancia o por ACU-hora), almacenamiento (por GB-mes), E/S (por millón de operaciones de lectura y escritura contra el volumen) y copias de seguridad por encima del tamaño del clúster.

La E/S es la partida imprevisible, y por eso existen dos modelos:

Estimación mensual para MercadoFresco:

Hay que decirlo sin adornos: Aurora sale más caro. La justificación no es el ahorro, es lo que se compra con esos 162 USD adicionales: una conmutación por error de 20 segundos en vez de 96, un retardo de réplica de milisegundos en vez de 8 segundos, seis copias en tres AZ en vez de dos, clonación para desarrollo, blue/green para los cambios de esquema y capacidad que sigue a la demanda. Para una tienda que factura en el pico del viernes, 162 USD al mes es menos que un solo minuto de caída.

Y dos palancas para bajarlo: reducir MaxCapacity cuando 06-05 quite la carga del catálogo, y evaluar I/O-Optimized si la E/S crece —con 36 USD de 280, hoy no compensa.

Usar el punto de enlace de instancia en la aplicación. Funciona, hasta la conmutación por error: entonces la aplicación sigue apuntando a una instancia que ahora es réplica y todas las escrituras fallan. Usa siempre el punto de enlace de clúster.

No ajustar la caché de DNS del cliente. El punto de enlace cambia en segundos, pero si el cliente cachea el DNS indefinidamente —el comportamiento por defecto de la JVM— la aplicación tarda minutos u horas en enterarse. Es el motivo más frecuente de que una conmutación «rápida» no lo parezca.

Contar con backtrack en Aurora PostgreSQL. No existe: es exclusivo de Aurora MySQL. En PostgreSQL, el plan para deshacer un error humano es la restauración PITR a un clúster nuevo, y hay que haberlo ensayado antes de necesitarlo.

Poner MinCapacity demasiado bajo. Con 0,5 ACU, un clúster que lleva horas inactivo tiene la caché fría: la primera consulta del pico puede ser lenta mientras escala. Si el pico es predecible —el viernes lo es— conviene subir el mínimo en esa franja.

Poner MaxCapacity demasiado alto «por si acaso». Serverless v2 escala hasta donde le dejes, y una consulta descontrolada puede pasar semanas facturando 64 ACU sin que nadie lo note. El máximo es un límite de gasto, no una aspiración; acompáñalo de una alarma sobre ServerlessDatabaseCapacity.

Clonar producción y dárselo a desarrollo sin anonimizar. Es un incidente de protección de datos, no un atajo. Anonimizar es parte del procedimiento, no un extra.

Cambiar un parámetro en el grupo equivocado. Los parámetros de clúster y los de instancia son grupos distintos y no dan error al equivocarse: simplemente no surten efecto.

Tratar Aurora como si fuera un almacén analítico. Es tentador cuando se descubren las 15 réplicas y las consultas paralelas. Sigue siendo un motor orientado a filas: una agregación sobre 40 millones de filas será lenta y cara. Ese trabajo es de Redshift (06-04).

Consejo: ensaya la conmutación por error el primer día. aws rds failover-db-cluster fuera de hora punta, cronómetro en mano y midiendo lo que tarda la aplicación, no el clúster. Es la única forma de descubrir el problema de la caché DNS antes de que lo descubra un viernes.

Consejo: pon una alarma sobre ServerlessDatabaseCapacity. Si el clúster lleva días pegado al máximo, o no está bien dimensionado o hay una consulta que se ha degradado. Ambas cosas conviene saberlas antes de que llegue la factura.

Diseña la topología completa de aurora-mercadofresco-pedidos sabiendo que debe atender: la tienda (escrituras y lecturas críticas), el historial de pedidos del cliente (lecturas tolerantes a 20 ms de retardo), las consultas de atención al cliente (exploratorias, ocasionalmente pesadas) y la exportación nocturna hacia el almacén analítico.

Especifica: cuántas instancias y en qué AZ, qué nivel de prioridad de promoción asignas a cada una, qué punto de enlace usa cada carga, y qué configuración de escalado automático de lectores pondrías. Justifica por qué la exportación nocturna no debe usar el punto de enlace de lectura general.

Una empresa de suscripción de comida preparada, con arquitectura similar a la de MercadoFresco, tiene este perfil: tráfico prácticamente constante las 24 horas (entre 400 y 600 pedidos/hora, sin valle nocturno porque opera en tres husos horarios), 1,2 TB de datos, y un pico de tres veces la carga normal el primer día de cada mes, cuando se renuevan las suscripciones. Su factura de E/S en Aurora sería aproximadamente el 34 % del total.

Responde: (a) ¿Serverless v2 o instancias provisionadas, y por qué?; (b) ¿Standard o I/O-Optimized?; (c) ¿cómo gestionarías el pico mensual con la opción elegida?; (d) ¿qué dos métricas vigilarías para saber si la decisión fue correcta a los tres meses?

MercadoFresco necesita añadir una columna franja_reparto a la tabla pedidos (340 GB, 48 millones de filas) con un valor calculado a partir de la dirección, y crear un índice sobre ella. En PostgreSQL, ALTER TABLE ... ADD COLUMN con valor por defecto no volátil es rápido, pero el UPDATE masivo posterior y el CREATE INDEX no lo son.

Escribe el plan completo: qué mecanismo de Aurora usas, los pasos ordenados, cómo compruebas que el resultado es correcto antes de exponerlo, cuál es el plan de reversión en cada punto, qué coste adicional tiene la operación y en qué franja horaria la programarías. Indica también qué habrías hecho distinto si la base de datos siguiera en RDS.

Solución 1

Topología: 4 instancias.

Puntos de enlace por carga: la tienda usa el punto de enlace de clúster para escrituras y para la lectura inmediatamente posterior a una escritura (comprobar stock antes de cobrar). El historial de pedidos usa el punto de enlace de lectura, porque 20 ms de retardo son aceptables. Atención al cliente y la exportación nocturna usan un punto de enlace personalizado que contiene solo aurora-mf-lector-lotes.

Escalado automático: mínimo 1 lector y máximo 3 en el grupo general, con seguimiento de objetivo sobre RDSReaderAverageCPUUtilization al 60 %, enfriamiento de 300 s al aumentar y 600 s al reducir. aurora-mf-lector-lotes queda fuera del grupo escalable porque su capacidad se decide por la ventana nocturna, no por la CPU media.

Por qué la exportación no usa el punto de enlace de lectura general: porque ese punto reparte entre todas las réplicas del grupo y no hay forma de excluir una consulta. Una exportación que lee 40 millones de filas llena la caché de la réplica con páginas históricas y expulsa las páginas calientes del catálogo —exactamente la interferencia de rendimiento que diagnosticamos en 06-01, reproducida dentro de Aurora—. El punto de enlace personalizado la aísla en una instancia que nadie más usa. Y el nivel 15 de esa instancia garantiza que, si el escritor cae, no se promueva la máquina configurada para lotes.

Solución 2

(a) Instancias provisionadas. No hay valle: la carga está entre 400 y 600 pedidos/hora las 24 horas, así que la ventaja estructural de Serverless v2 —dejar de pagar cuando no hay nadie— no se materializa nunca. Como por ACU es más caro que la capacidad provisionada equivalente, en carga plana sale perdiendo. Además, con carga constante se pueden contratar Reserved Instances a uno o tres años, con descuentos que Serverless v2 no ofrece de la misma forma. La decisión correcta es una instancia provisionada reservada, dimensionada para la carga normal.

(b) I/O-Optimized. La regla práctica es que compensa cuando la E/S supera aproximadamente el 25 % de la factura, y aquí es el 34 %. I/O-Optimized encarece el cómputo un 30 % y el almacenamiento bastante más, pero elimina por completo la partida de E/S; con 1,2 TB conviene hacer el cálculo concreto de almacenamiento, porque es la partida que más sube. Con un 34 % de E/S sale a favor, y como efecto secundario valioso, la factura pasa a ser predecible, que es justo lo que una empresa de suscripción necesita para presupuestar.

(c) El pico mensual. Con instancias provisionadas hay dos palancas. La principal es el escalado automático de réplicas de lectura, programado con antelación para el primer día del mes: se sube el mínimo de lectores la noche anterior y se baja 24 horas después. Si el pico afecta también a la escritura —la renovación de suscripciones genera escrituras—, la segunda palanca es cambiar la clase de la instancia de escritura, que en Aurora es rápido porque los datos no se mueven, aprovechando una ventana de bajo tráfico y aceptando una conmutación de unos 20 segundos. Lo que no hay que hacer es dimensionar la instancia para el pico del día 1 y pagarla los otros 30.

(d) Dos métricas a los tres meses. Primera, la utilización media de CPU y memoria de la instancia de escritura: si está por debajo del 30 % de forma sostenida, se sobredimensionó y hay dinero en la mesa; si supera el 70 % habitualmente, no queda margen para el día 1. Segunda, el coste de E/S que se habría pagado en Standard, calculable a partir de VolumeReadIOPs y VolumeWriteIOPs, para verificar que I/O-Optimized sigue siendo la opción correcta; si la aplicación cambia y la E/S baja, conviene revisar la decisión.

Solución 3

Mecanismo: blue/green deployment de Aurora. Es exactamente el caso de uso para el que existe: un cambio de esquema largo sobre una tabla enorme, que en caliente bloquearía escrituras durante mucho tiempo.

Pasos:

1. Clonar y ensayar primero. Antes de tocar producción, un clon por copia en escritura para medir cuánto tarda de verdad el UPDATE y el CREATE INDEX con 48 millones de filas. Sin ese dato, la ventana se planifica a ciegas. El clon se anonimiza y se borra al terminar.
2. Crear el entorno verde con create-blue-green-deployment. Aurora crea el clúster copia y lo mantiene sincronizado por replicación lógica.
3. En verde: ALTER TABLE pedidos ADD COLUMN franja_reparto text; (rápido, sin valor por defecto volátil), luego el UPDATE por lotes de 50.000 filas con pausas, para no generar una transacción gigante ni disparar el retardo de replicación, y por último CREATE INDEX CONCURRENTLY idx_pedidos_franja ON pedidos (franja_reparto);.
4. Verificar en verde: recuento de filas con la columna rellena igual al total, distribución de valores razonable, EXPLAIN de las consultas afectadas usando el índice nuevo, y la batería de pruebas de la aplicación apuntando a verde.
5. Comprobar el retardo de replicación a cero y ejecutar el cambio de rol. Menos de un minuto.
6. Vigilar 24 horas con las alarmas de 05-01, manteniendo el clúster antiguo disponible.
7. Borrar el entorno antiguo a los 7 días.

Reversión: hasta el paso 5, se elimina el entorno verde y no ha pasado nada —producción no se ha tocado en ningún momento—. Después del cambio de rol, el clúster antiguo sigue existiendo y se puede volver a él, con la salvedad importante de que las escrituras ocurridas después del cambio no están en él: por eso el paso 6 vigila de cerca y por eso la ventana se elige en baja actividad.

Coste adicional: el clúster verde duplica el cómputo mientras existe. Si la operación dura 8 horas y el clúster corre a 4 ACU, son unas 32 ACU-hora, menos de 4 USD, más el almacenamiento divergente. Es despreciable frente al riesgo que elimina.

Franja: martes o miércoles de madrugada, entre las 02:00 y las 05:00, que es el valle más profundo. Nunca un jueves o un viernes, por proximidad al pico; nunca un lunes, porque si algo sale mal hay que tener días laborables por delante.

Qué habría cambiado en RDS: no existe blue/green con cambio de rol en un minuto para este caso, así que el plan habría sido crear una réplica de lectura, aplicar los cambios ahí, promoverla y redirigir —más manual, más lento y con más corte—, o bien ejecutar el UPDATE por lotes directamente en producción durante varias noches, vigilando bloqueos y el retardo de la réplica. Además, el ensayo del paso 1 habría exigido restaurar un snapshot completo de 340 GB, con horas de espera y coste de almacenamiento completo, en vez de un clon que arranca en minutos y casi sin ocupar espacio. Esa diferencia —poder ensayar barato— es una de las razones menos citadas y más útiles de Aurora.

mercadofresco-pedidos ya no es una instancia de PostgreSQL sobre EBS: es aurora-mercadofresco-pedidos, un clúster con el mismo motor y una capa de almacenamiento completamente distinta. Entiendes esa diferencia y de dónde salen sus ventajas: la separación entre cómputo y almacenamiento, que convierte añadir una réplica en arrancar una instancia sobre datos que ya existen; el volumen distribuido en seis copias sobre tres AZ, con quórum de 4 de 6 para escribir y 3 de 6 para leer, que tolera perder una zona entera sin dejar de aceptar pedidos; y la desaparición de los checkpoints, porque Aurora solo envía el registro de rehacer y son los nodos de almacenamiento los que materializan las páginas.

Conoces los componentes del clúster y —lo que más incidentes evita— los puntos de enlace: el de clúster que sigue a la conmutación por error y que la aplicación debe usar siempre, el de lectura para lo que tolera 15 ms de retardo, el de instancia que nunca debe aparecer en la aplicación, y los personalizados que aíslan los informes y la exportación nocturna para que no envenenen la caché de la réplica que sirve a la tienda. Con la conmutación por error de 10 a 30 segundos en vez de 96, la prioridad por niveles para que nunca se promueva la instancia de lotes, y el retardo de réplica en milisegundos que por fin permite servir el historial del cliente desde una réplica.

Sabes decidir entre Serverless v2 y provisionada con el perfil de carga real: 2,4 ACU de media frente a un pico de 8, con 49 de 168 horas semanales en valle nocturno, es el caso en que Serverless v2 gana; carga plana 24×7 es el caso en que pierde, porque por ACU es más caro. Y sabes que MinCapacity demasiado bajo deja la caché fría y MaxCapacity demasiado alto es una factura sin freno. Dominas las copias continuas hacia S3 sin impacto, el PITR que siempre restaura a un clúster nuevo, que backtrack no existe en PostgreSQL por mucho que se cuente lo contrario, y la clonación por copia en escritura que permite a Luis ensayar una migración con 340 GB reales en minutos —con el procedimiento de anonimización, cifrado y borrado a 7 días que el RGPD exige y que debe revisar el responsable de protección de datos—.

La migración se hizo con réplica de lectura promovida y 90 segundos de corte, no con snapshot y cuatro horas, y se midió: TiempoConfirmacionPedido p99 de 1.900 ms a menos de 900, ReplicaLag de 8 segundos a menos de 100 ms, conmutación de 96 s a menos de 30. Con la instancia RDS original intacta durante siete días, un simulacro de conmutación ejecutado a propósito y una restauración verificada. Y con la cuenta puesta sobre la mesa sin adornos: de 118 a 280 USD al mes, porque Aurora no se elige para ahorrar sino para comprar disponibilidad, y 162 USD es menos que un minuto de caída un viernes. Más blue/green como vía por defecto para los cambios de esquema grandes y las versiones del motor.

Queda una carga que Aurora no va a resolver por muchas réplicas que le pongamos. Los informes de Sara siguen agregando entre 6 y 40 millones de filas para usar 4 columnas de 40, y siguen leyendo filas completas, sin comprimir y sin paralelizar, porque Aurora —como PostgreSQL— es un motor orientado a filas y a transacciones. Aislarlos en un punto de enlace personalizado evita que envenenen la tienda, pero no los hace rápidos: siguen tardando minutos, y Sara sigue esperando. En 06-04, «Amazon Redshift», esos informes salen definitivamente de la base de datos transaccional: veremos el almacenamiento columnar y la ejecución masivamente paralela, el modelo en estrella con hechos_pedidos y sus dimensiones, las claves de distribución y de ordenación, la carga con COPY desde mercadofresco-informes-analitica, Redshift Serverless, y la comparación honesta con Athena para saber cuándo hace falta un almacén de datos y cuándo no.