Bases de datos serverless - Gestión de datos escalable con DynamoDB
Construya bases de datos que escalan automáticamente según el tráfico, con el modo bajo demanda de DynamoDB como eje. Incluyendo la comparación con Aurora Serverless, explicamos los criterios de selección de bases de datos serverless según las características de la carga de trabajo.
Concepto de base de datos serverless y posicionamiento de DynamoDB
Las bases de datos serverless son servicios que eliminan la necesidad de planificación de capacidad y gestión de servidores, permitiendo concentrarse en el desarrollo de aplicaciones. Amazon DynamoDB, desde su lanzamiento en 2012, ha sido el núcleo de las bases de datos serverless de AWS, siendo una base de datos NoSQL completamente administrada capaz de procesar millones de solicitudes por segundo con latencia de un solo dígito de milisegundos. Al operar bases de datos NoSQL equivalentes on-premises (MongoDB, Cassandra, etc.), surgen enormes tareas operativas como la construcción de clústeres, el diseño de sharding, la gestión de replicación y la aplicación de parches. DynamoDB delega toda esta gestión a AWS, permitiendo a los desarrolladores concentrarse en el diseño de tablas y la optimización de consultas. Al seleccionar el modo de capacidad bajo demanda, ni siquiera se necesita configuración previa de capacidad, escalando automáticamente según el tráfico.
Funciones principales de DynamoDB
DynamoDB ofrece dos modos de capacidad: bajo demanda y provisionado. El modo bajo demanda cobra por solicitud, siendo ideal para cargas de trabajo donde es difícil predecir el tráfico. El modo provisionado, combinado con Auto Scaling, permite una operación con buena relación costo-eficiencia. Con DynamoDB Streams se pueden activar funciones Lambda en tiempo real ante cambios en la tabla, implementando patrones de captura de datos de cambio (CDC) con pocas líneas de código. Las tablas globales proporcionan replicación multi-región, y en las configuraciones de tablas globales se aplica un SLA de disponibilidad del 99.999%. De forma predeterminada, la replicación entre regiones tiene consistencia eventual, y cuando necesite consistencia fuerte entre regiones, elija el modo de consistencia fuerte multi-región (MRSC). La documentación oficial (a fecha de agosto de 2026) establece que MRSC requiere una configuración de exactamente 3 regiones (3 réplicas, o 2 réplicas + 1 witness). Solo se puede configurar dentro de cada conjunto de regiones de US, EU y AP, y no puede abarcar varios conjuntos. A continuación se muestra un ejemplo de comando CLI para crear una tabla DynamoDB en modo bajo demanda. aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=CustomerId,AttributeType=S AttributeName=OrderId,AttributeType=S \ --key-schema AttributeName=CustomerId,KeyType=HASH AttributeName=OrderId,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST
Arquitectura serverless con integración de Lambda
La combinación de DynamoDB y Lambda es el patrón dorado de la arquitectura serverless de AWS. La configuración que procesa solicitudes de API Gateway con Lambda y persiste datos en DynamoDB permite construir aplicaciones para millones de usuarios sin aprovisionar servidores. La integración de DynamoDB Streams con Lambda permite el procesamiento asíncrono activado por cambios en los datos. Se pueden construir pipelines de datos orientados a eventos que ejecutan automáticamente actualizaciones de inventario o envío de notificaciones al insertar datos de pedidos. Con PartiQL se puede operar DynamoDB con sintaxis similar a SQL, reduciendo la curva de aprendizaje para desarrolladores familiarizados con bases de datos relacionales. DAX (DynamoDB Accelerator) es una caché en memoria que reduce la latencia de lectura a nivel de microsegundos. Para construir una capa de caché equivalente on-premises se necesitaría operar Redis o Memcached por separado, pero DAX es un servicio administrado completamente integrado con DynamoDB.
Ventajas en eficiencia de costos y escalabilidad
El modo bajo demanda de DynamoDB cobra por solicitud, y en las franjas horarias sin tráfico solo se generan cargos de almacenamiento (a fecha de agosto de 2026, Norte de Virginia / Tokio). Las lecturas cuestan 0.125 USD en Norte de Virginia y 0.1425 USD en Tokio por cada 1 millón de unidades de solicitud, y las escrituras, también por cada 1 millón de unidades de solicitud, cuestan 0.625 USD en Norte de Virginia y 0.715 USD en Tokio. La capa gratuita permanente consta de 25 GB de almacenamiento, 25 WCU provisionadas y 25 RCU provisionadas, y la documentación oficial la presenta como una escala capaz de procesar 200 millones de solicitudes al mes. Sin embargo, esta asignación corresponde a la capacidad provisionada, por lo que no se aplica a los cargos por solicitud del modo bajo demanda. Si quiere operar una aplicación pequeña dentro de la capa gratuita, lo habitual es elegir la combinación del modo provisionado y Auto Scaling. En el modo provisionado, solo para la clase de tabla Standard se puede comprar capacidad reservada, con descuentos sobre la tarifa estándar de hasta el 54% con un contrato de 1 año y de hasta el 77% con un contrato de 3 años. (El contrato de 3 años solo está disponible en algunas regiones, la unidad de compra es de 100 RCU o 100 WCU, y el modo bajo demanda y la clase de tabla Standard-IA quedan excluidos.) Respecto a la escalabilidad, la cuota predeterminada por tabla es de 40,000 unidades de solicitud de lectura y 40,000 unidades de solicitud de escritura por segundo, y si necesita una escala superior, solicite un aumento desde Service Quotas. (El modo provisionado también tiene, por separado, un límite predeterminado de 80,000 RCU / 80,000 WCU por cuenta.) El almacenamiento no requiere reservar capacidad de antemano y mantiene un rendimiento consistente incluso cuando el tamaño de la tabla alcanza cientos de TB.
Modelado de datos y diseño de patrones de acceso
La clave para usar DynamoDB de forma efectiva es comprender un enfoque de diseño distinto al de las bases de datos relacionales. Comience por identificar los patrones de acceso de la aplicación, es decir, con qué condiciones se leen y escriben los datos, y diseñe las tablas y las claves de acuerdo con ellos. Es importante elegir la clave de partición, que determina la distribución y la obtención de los datos, de modo que el acceso no se concentre. Si diseña para poder obtener de forma eficiente los datos relacionados en conjunto, puede lograr un rendimiento rápido y estable. Como DynamoDB no es adecuado para búsquedas posteriores con condiciones libres, conocer de antemano los patrones de búsqueda necesarios es la premisa de un diseño de datos escalable.
Comparación con Aurora Serverless y criterios de selección
Las opciones de bases de datos serverless no se limitan a DynamoDB. Cuando se necesita un modelo relacional, la configuración serverless de Aurora es la opción complementaria (en la documentación oficial se denomina Aurora Serverless. AWS informa de que en abril de 2026 cambió el nombre desde Aurora Serverless v2). Aurora Serverless ajusta automáticamente la capacidad en unidades llamadas ACU (Aurora Capacity Unit), y 1 ACU equivale a unos 2 GiB de memoria con el rendimiento de CPU y de red correspondiente. El rango de capacidad se puede especificar desde un mínimo de 0.5 ACU hasta un máximo de 256 ACU, y sigue a la carga de trabajo con aumentos y reducciones finos en pasos de 0.5 ACU. A octubre de 2026, las versiones compatibles del motor Aurora PostgreSQL permiten fijar el máximo en 384 ACU. Si quiere que se detenga automáticamente cuando no haya conexiones por operaciones de usuarios durante un tiempo determinado, puede establecer la capacidad mínima en 0 ACU. El precio se compone del uso de ACU más el almacenamiento y la I/O, y el precio unitario varía según la región y la configuración, por lo que compruebe el importe real en la tabla de precios oficial de Aurora. Los criterios de selección se pueden organizar en dos ejes: «si los patrones de acceso se pueden fijar en el diseño» y «si se necesita la flexibilidad de SQL». Si el uso se centra en lecturas y escrituras rápidas especificando la clave y puede identificar los patrones de acceso necesarios en el diseño, DynamoDB tiene ventaja. Se aprovechan la latencia de milisegundos de un solo dígito y la facturación por solicitud, y el costo en inactividad se reduce a las tarifas de almacenamiento. Por el contrario, si los requisitos del negocio incluyen agregaciones, uniones o búsquedas ad hoc que cambian las condiciones a posteriori, o si migra activos existentes de PostgreSQL y MySQL, elija Aurora Serverless. Como se reserva el ACU mínimo, la facturación continúa incluso en inactividad (salvo si se usa la detención automática con 0 ACU), pero se obtienen la expresividad del modelo relacional y la facilidad para manejar transacciones que abarcan varias tablas. Una opción no excluye a la otra. También es una opción de diseño combinarlas: colocar en Aurora Serverless los datos que son la fuente de verdad de las transacciones del negocio y atender con DynamoDB la parte de consultas de alto throughput.
Resumen - Criterios de selección de bases de datos serverless
DynamoDB es la opción principal para la persistencia de datos en arquitecturas serverless. El escalado desde cero y el pago por uso del modo bajo demanda se adaptan a una amplia gama de casos de uso, desde startups hasta grandes empresas. El procesamiento orientado a eventos con DynamoDB Streams, el despliegue multi-región con tablas globales (SLA de disponibilidad del 99.999% en configuraciones de tablas globales) y la caché a nivel de microsegundos con DAX, entre otros, proporcionan de forma integral las funciones necesarias para la gestión de datos. Respecto al orden de selección, si puede fijar los patrones de acceso en el diseño, considere antes DynamoDB, y si los requisitos incluyen agregaciones, búsquedas ad hoc o la migración de activos relacionales existentes, elija Aurora Serverless. Organizarlo de este modo evita que el criterio vacile.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.