Introducción
Durante años, la arquitectura sin servidor para bases de datos relacionales enfrentó una limitación estructural crítica: el techo de capacidad de cómputo y memoria. Los equipos de ingeniería que necesitaban escalar verticalmente más allá de ciertos umbrales para manejar consultas complejas o grandes conjuntos de datos en memoria se veían forzados a migrar hacia instancias provisionadas tradicionales, sacrificando la elasticidad del modelo serverless por la estabilidad del aprovisionamiento fijo. Esta brecha técnica obligaba a decisiones arquitectónicas binarias: optimizar agresivamente para encajar dentro de los límites de ACU (Aurora Capacity Units) disponibles, o abandonar el modelo de pago por uso.
La actualización reciente de Amazon Aurora Serverless para PostgreSQL-Compatible Edition cambia este paradigma al elevar el límite máximo de capacidad a 384 ACUs. Este incremento del 50% respecto al tope anterior de 256 ACUs no es solo un ajuste numérico; representa la habilitación de casos de uso que antes eran técnicamente inviables bajo el modelo sin servidor. Al permitir que una sola instancia escale hasta 768 GiB de memoria, AWS posiciona a Aurora Serverless como una opción viable para cargas de trabajo intensivas en memoria, particularmente aquellas asociadas con la nueva ola de aplicaciones de IA agéntica que exhiben patrones de tráfico erráticos y ventanas de inactividad prolongadas.
Qué ocurrió
AWS anunció la disponibilidad general de soporte para 384 ACUs en Aurora Serverless para la edición compatible con PostgreSQL. Cada ACU representa aproximadamente 2 GiB de memoria, junto con los recursos proporcionales de CPU y ancho de banda de red. Con el nuevo límite, una base de datos individual puede ahora aprovisionar dinámicamente hasta 768 GiB de RAM, manteniendo la capacidad de escalar hacia cero cuando no existe carga de trabajo.
El anuncio enfatiza la adecuación de este cambio para «aplicaciones de IA agéntica». Estos sistemas suelen operar con ráfagas de actividad muy intensas seguidas de largos periodos de inactividad mientras los agentes procesan o esperan respuestas. Tradicionalmente, soportar estas ráfagas requería mantener capacidad de pico permanentemente activa (y pagada), o diseñar arquitecturas complejas de colas y worker que añadían latencia y costo de gestión. Con 384 ACUs, la base de datos puede absorber el pico de demanda automáticamente, sin intervención humana, y devolver los recursos al pool compartido inmediatamente después, cobrando solo por el tiempo de uso efectivo.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de SRE y DevOps, esta actualización reduce significativamente la fricción operativa asociada con el dimensionamiento de bases de datos. La capacidad de escalar hasta 768 GiB de memoria elimina la necesidad de preaprovisionar instancias grandes para picos de carga previstos, lo que simplifica la gestión de costos variables. En entornos de desarrollo, staging o aplicaciones con tráfico esporádico, esto se traduce en ahorros directos, ya que el sistema no cobra por capacidad ociosa.
Desde la perspectiva de seguridad y cumplimiento, la reducción de la superficie de ataque se mantiene consistente con el modelo serverless: al no existir una instancia EC2 o un sistema operativo visible que parchear manualmente, la responsabilidad del mantenimiento del SO y el motor de base de datos recae en AWS. Sin embargo, el aumento en la capacidad de procesamiento puede incentivar a los desarrolladores a ejecutar consultas más complejas o cargas de trabajo analíticas dentro de la misma instancia transaccional, lo que requiere una mayor disciplina en la revisión de consultas para evitar bloqueos o degradación del rendimiento durante las fases de escalado. Además, la disponibilidad de esta capacidad en versiones específicas de PostgreSQL exige una gestión activa de las ventanas de mantenimiento para asegurar que los clústeres se encuentren en las versiones compatibles para aprovechar la nueva escalabilidad.
Detalles técnicos
La expansión a 384 ACUs no aplica universalmente a todas las versiones de Aurora PostgreSQL. AWS ha restringido esta capacidad a motores específicos que corren sobre la Plataforma Version 4. Las versiones compatibles son: PostgreSQL 18.4, 17.10, 16.14, 15.18 y 14.23. Cualquier intento de configurar un máximo superior a 256 ACUs en una versión anterior o en una plataforma distinta resultará en un error de configuración o en la ignorancia del parámetro, dependiendo de la interfaz utilizada.
El mecanismo de escalado sigue siendo automático y basado en la demanda. Cuando la carga aumenta, el sistema añade ACUs en incrementos pequeños hasta alcanzar el máximo configurado (ahora 384). Cuando la carga disminuye, el sistema reduce la capacidad en pasos más conservadores para evitar el «flapping» o inestabilidad del rendimiento. La métrica clave para monitorear sigue siendo la utilización de memoria y CPU, pero ahora el techo de «memoria disponible» se ha elevado considerablemente, lo que debe ajustarse en las alertas de CloudWatch para reflejar el nuevo umbral de saturación.
Para los usuarios existentes, el proceso de habilitación varía según el estado actual del clúster:
- Nuevos clústeres: Se debe seleccionar una versión de motor soportada (ej. 17.10) y configurar el
max_capacitya 384 durante la creación. - Clústeres existentes en Plataforma V4: El cambio es inmediato y sin tiempo de inactividad. Se modifica la configuración del clúster para ajustar el límite superior de ACUs.
- Clústeres en versiones de plataforma anteriores: Requieren una actualización de plataforma a la V4. Esta operación puede implicar una ventana de mantenimiento y, dependiendo de la versión actual, podría requerir una migración de datos o un reinicio, por lo que se debe planificar cuidadosamente.
Qué deberían hacer los administradores y equipos técnicos
Los administradores de bases de datos y arquitectos de nube deben auditar sus instancias actuales de Aurora PostgreSQL para determinar la elegibilidad para el nuevo límite de capacidad. El primer paso es identificar qué versiones de motor y plataforma están corriendo.
Para verificar la versión y modificar la capacidad máxima mediante la CLI de AWS, utilicen el siguiente comando. Asegúrense de tener permisos de escritura en el servicio de RDS:
aws rds modify-db-cluster \
--db-cluster-identifier mi-cluster-aurora-serverless \
--serverless-v2-scaling-configuration '{"MaxCapacity":384}' \
--apply-immediatelySi el clúster no está en la Plataforma Version 4, no ejecuten el comando de modificación de capacidad directamente. Primero, verifiquen la necesidad de actualización de plataforma:
aws rds describe-db-clusters \
--db-cluster-identifier mi-cluster-aurora-serverless \
--query 'DBClusters[*].{Engine:Engine,EngineVersion:EngineVersion,PlatformVersion:PlatformVersion}'Si el PlatformVersion no es «4», deben programar una actualización. Para crear un nuevo clúster optimizado para cargas de IA agéntica con el nuevo techo, la configuración inicial debería verse así:
{
"ServerlessV2ScalingConfiguration": {
"MinCapacity": 0.5,
"MaxCapacity": 384
}
}Es crucial recalibrar las alarmas de CloudWatch. Las alertas anteriores, probablemente configuradas para disparar al 80% de 256 ACUs (aprox. 205 ACUs), deben ajustarse para monitorear el nuevo techo o, mejor aún, configurar alertas basadas en la latencia de consulta y la utilización de CPU, ya que el escalado automático puede tardar unos minutos en alcanzar los 384 ACUs durante picos extremadamente súbitos.
Conclusión
La ampliación de Aurora Serverless a 384 ACUs elimina una de las principales barreras arquitectónicas para la adopción completa de bases de datos sin servidor en cargas de trabajo intensivas. Al permitir 768 GiB de memoria y un escalado automático hasta cero, AWS ofrece una solución económica y elástica para aplicaciones modernas, especialmente aquellas impulsadas por IA que no siguen patrones de tráfico predecibles. Para los equipos técnicos, el beneficio principal es la simplificación operativa y la reducción de costos por capacidad ociosa, siempre que se gestione correctamente la versión del motor y se ajusten las estrategias de monitoreo para reflejar el nuevo rango de capacidad.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/10/aurora-serverless-supports-384-acu/