En el examen SAA-C03, la optimizacion de costos de bases de datos se resume en dos principios: elige el modo de capacidad correcto para tu patron de carga de trabajo, y usa cache para reducir la carga en tu base de datos. Mantener una instancia funcionando a plena capacidad en todo momento no siempre es el mejor enfoque — adaptar tu modelo de facturacion a tus patrones de uso reales puede generar ahorros significativos.
Que es Aurora Serverless v2?
Por que existe? Las bases de datos tradicionales te cobran por la instancia tanto si alguien la usa como si no. Para servicios con trafico impredecible o intermitente, esto significa pagar por mucho tiempo inactivo.
Que es? Piensa en un medidor de electricidad. Cuando usas mucha energia, el medidor gira rapido. Cuando no hay nadie en casa, casi se detiene. Aurora Serverless v2 funciona igual. Cuando el trafico aumenta, la capacidad se escala automaticamente hacia arriba. Cuando las cosas se calman, la capacidad se reduce casi a cero. Solo pagas por la capacidad informatica que realmente consumes.
Como funciona? La capacidad se mide en ACUs (Aurora Capacity Units). Estableces un ACU minimo y maximo. Aurora ajusta automaticamente dentro de ese rango. Establece el minimo en 0.5 ACU y el tiempo inactivo cuesta casi nada.
Cuando usarlo: Entornos de desarrollo y prueba que estan inactivos por la noche y los fines de semana Aplicaciones SaaS pequenas con bajo numero de usuarios o variable Generacion de informes o servicios basados en eventos que ocasionalmente reciben grandes rafagas de trafico
Aurora Provisionado vs Aurora Serverless v2
| Elemento | Aurora Provisionado | Aurora Serverless v2 | |----------|--------------------|--------------------| | Facturacion | Tamano de instancia (por hora) | Uso de ACU (por segundo) | | Patron de trafico | Predecible y estable | Intermitente o impredecible | | Costo en inactividad | Siempre se genera | Casi cero | | Auto-escalado | Configuracion manual | Automatico |
Consejo: Si tu trafico es estable y predecible, Aurora Provisionado con Reserved Instances sera mas barato que Serverless.
!Aurora aprovisionado vs Aurora Serverless v2
Modos de capacidad de DynamoDB
Por que existen? Los costos de DynamoDB escalan directamente con el numero de solicitudes de lectura y escritura. Conocer tu patron de trafico te permite elegir el modelo de facturacion que minimiza tu factura.
Que son? DynamoDB ofrece dos modos de capacidad.
Capacidad Provisionada: Estableces el numero de Unidades de Capacidad de Lectura (RCU) y Unidades de Capacidad de Escritura (WCU) con anticipacion. Como elegir un plan de internet mensual: te comprometes a "100 GB al mes." Ideal para trafico estable y predecible. Combina con Auto Scaling para manejar variaciones de trafico automaticamente mientras mantienes los costos bajos. Compra Capacidad Reservada para hasta un 76% de descuento.
Capacidad Bajo Demanda: Pagas por solicitud, basado en el trafico real. Como un plan de datos de pago por uso: pagas exactamente por lo que usas. Ideal para trafico impredecible o nuevos servicios donde aun no has establecido patrones de uso. No requiere planificacion de capacidad, pero el precio por solicitud es mas alto que el Provisionado.
| Modo | Ideal Para | Precio Unitario | Previsibilidad del Costo | |------|-----------|----------------|--------------------------| | Provisionado + Reservado | Trafico estable y predecible | Bajo | Facil | | Provisionado + Auto Scaling | Trafico variable pero previsible | Bajo a medio | Medio | | Bajo Demanda | Trafico irregular e intermitente | Alto | Dificil |
Reducir costos de base de datos con cache
Por que existe? Los costos de la base de datos escalan con el numero de solicitudes de lectura y escritura. Recuperar los mismos datos de la base de datos repetidamente es un desperdicio. Almacenar datos de lectura frecuente en un cache rapido reduce las solicitudes a la base de datos y, por lo tanto, los costos.
Imagina una heladeria. Cada vez que un cliente pregunta "Cual es el sabor popular de hoy?", el personal del mostrador camina al almacen a revisar el inventario. Eso es lento y agotador. Pero si hay una pizarra en el mostrador que dice "Eleccion de hoy: chocolate," el personal puede responder inmediatamente sin ir al almacen. Esa pizarra es tu cache.
ElastiCache for Redis
Que es? Un almacen de datos en memoria de alto rendimiento. Los resultados de consultas frecuentes de la base de datos se almacenan en memoria. Cuando llega la misma solicitud de nuevo, Redis responde instantaneamente desde el cache en lugar de llegar a la base de datos.
Cuando usarlo: Gestion de sesiones (mantener a los usuarios conectados) Almacenamiento en cache de resultados de consultas complejas Tablas de clasificacion en tiempo real y contadores Entornos de alta disponibilidad que requieren replicacion y soporte de cluster
ElastiCache for Memcached
Que es? Un cache simple de clave-valor. Menos funciones que Redis, pero su arquitectura multihilo ofrece alto rendimiento para casos de uso de cache simples.
Cuando usarlo: Cache de objetos simples Entornos de alto rendimiento que necesitan procesamiento multihilo Cuando no se requiere replicacion ni persistencia de datos
DynamoDB DAX (DynamoDB Accelerator)
Por que existe? Cuando usas DynamoDB pero los costos de lectura son altos o los tiempos de respuesta son lentos, puedes agregar una capa de cache con cambios minimos en el codigo.
Que es? Un cache en memoria que se ubica de forma transparente frente a DynamoDB. Tu aplicacion llama al endpoint de DAX. En un acierto de cache, DAX responde inmediatamente. En un fallo de cache, DAX consulta DynamoDB, almacena el resultado en cache y lo devuelve al solicitante.
Caracteristicas clave: Solo para DynamoDB — no se puede usar con otras bases de datos Cambio de codigo minimo (solo cambiar la URL del endpoint) Tiempos de respuesta en microsegundos (vs milisegundos de DynamoDB)
Optimizacion de costos de RDS
Mas alla del cache, tambien puedes optimizar RDS en si mismo.
Ajuste de talla de instancia: Usa AWS Compute Optimizer para revisar la utilizacion real de CPU y memoria de tus instancias RDS Un db.r5.xlarge funcionando al 20% de CPU probablemente puede reducirse a db.r5.large
Reserved Instances: Plazo de 1 ano: hasta 40% de descuento Plazo de 3 anos: hasta 60% de descuento RDS suele ser una carga de trabajo estable de larga duracion, lo que hace que Reserved Instances sea muy efectivo
Revision de Multi-AZ: Multi-AZ mantiene una instancia de espera automatica en todo momento para alta disponibilidad, lo que aproximadamente duplica el costo Los entornos de desarrollo y prueba raramente necesitan alta disponibilidad, por lo que cambiar a Single-AZ reduce el costo a la mitad
Combinar Read Replicas con cache: En lugar de ejecutar multiples Read Replicas, introducir una capa de cache (ElastiCache) puede reducir el numero de Read Replicas necesarias — doble ahorro
Puntos clave para el examen
"Trafico de BD intermitente o impredecible, minimizar costo inactivo" -- Aurora Serverless v2
"Como un medidor de electricidad: paga solo por lo que consumes" -- Caracteristica central de Aurora Serverless
"Trafico DynamoDB estable, menor costo posible" -- Capacidad Provisionada + Capacidad Reservada
"Trafico DynamoDB irregular, sin necesidad de planificacion de capacidad" -- Modo Bajo Demanda
"Reducir carga de lectura de BD con capa de cache" -- ElastiCache (Redis o Memcached)
"Cache solo para DynamoDB, cambios minimos de codigo" -- DAX
"Redis vs Memcached: necesitas replicacion o sesiones" -- Redis / "clave-valor simple, multihilo" -- Memcached
"Reducir costos de BD en entornos de desarrollo" -- RDS Single-AZ (no se necesita Multi-AZ)
"Ajustar tamano de instancia RDS" -- AWS Compute Optimizer
Agregar un cache puede reducir el numero de Read Replicas, generando doble ahorro de costos