Casi toda aplicación necesita guardar datos de forma organizada: usuarios, pedidos, productos… Para eso usamos bases de datos. AWS te permite ejecutar bases de datos sin tener que administrarlas tú, gracias a servicios gestionados. El más importante es RDS, y es donde empezamos este capítulo.

Montar y mantener una base de datos «a mano» es un trabajo duro y delicado:

• Instalar y configurar el software de base de datos.
• Aplicar parches de seguridad.
• Hacer copias de seguridad periódicas.
• Configurar la alta disponibilidad por si el servidor falla.
• Monitorizar el rendimiento.

Hacer todo esto bien requiere un especialista (un DBA, administrador de bases de datos) y mucho tiempo. RDS automatiza casi todo esto por ti.

RDS significa Relational Database Service. Es un servicio gestionado para ejecutar bases de datos relacionales sin ocuparte de la administración pesada.

Recuerda el Capítulo 1: RDS es un ejemplo de PaaS. AWS se encarga del sistema operativo, la instalación, los parches, las copias de seguridad y la infraestructura; tú solo te ocupas de tus datos y tus consultas.

«Base de datos relacional» significa que los datos se organizan en tablas con filas y columnas, relacionadas entre sí (como hojas de cálculo conectadas). Se consultan con el lenguaje SQL. Son las bases de datos «de toda la vida», ideales cuando los datos tienen una estructura clara y consistente.

Analogía: Usar RDS es como alquilar un coche con conductor y mantenimiento incluido en lugar de comprar el coche y encargarte tú de las revisiones, el seguro y las averías. Tú decides a dónde ir (tus datos); del resto se encarga AWS.

RDS no es una base de datos nueva: ejecuta los motores de bases de datos populares que ya existen. Eliges el que prefieras:

Ventaja clave: si tu aplicación ya usaba, por ejemplo, MySQL o PostgreSQL, puedes moverla a RDS sin cambiar el código. Es el mismo motor, pero gestionado por AWS.

Aquí RDS brilla en seguridad y resiliencia. Recuerda las zonas de disponibilidad del Capítulo 3. La opción Multi-AZ de RDS hace lo siguiente:

• Mantiene una copia exacta (réplica de reserva) de tu base de datos en OTRA zona de disponibilidad, sincronizada en tiempo real.
• Si la base de datos principal falla (por un problema de hardware o una caída de la AZ), RDS conmuta automáticamente a la copia de reserva, normalmente en uno o dos minutos, sin que tú hagas nada.

Analogía: Es como tener un conductor de repuesto sentado al lado en un viaje largo. Si el conductor principal se encuentra mal, el de repuesto toma el volante al instante y el viaje continúa casi sin interrupción.

Importante: La réplica de reserva de Multi-AZ no se usa para consultar; solo está «esperando» por si la principal falla. Su único propósito es la alta disponibilidad. Para repartir la carga de lectura se usan las réplicas de lectura (lo vemos ahora).

A veces el problema no es que la base de datos falle, sino que recibe demasiadas consultas de lectura y se satura. Para eso están las réplicas de lectura (read replicas).

Una réplica de lectura es una copia adicional de tu base de datos que sirve solo para leer (consultas), no para escribir. Repartes las lecturas entre la principal y las réplicas, aliviando la carga.

Analogía: Imagina una biblioteca con un único bibliotecario desbordado por la gente que viene a consultar libros. Contratas varios ayudantes (réplicas) que solo atienden consultas. Las modificaciones del catálogo (escrituras) las sigue haciendo solo el bibliotecario jefe (la principal), para evitar descontrol.

Ejemplo real: Una web de noticias tiene muchísima gente leyendo artículos y poca gente escribiéndolos. Crea varias réplicas de lectura: los millones de lectores consultan las réplicas, mientras que los pocos periodistas escriben en la base de datos principal. Así la web aguanta picos enormes de tráfico de lectura.

Es el error conceptual más típico de este tema:

Regla mental: Multi-AZ = disponibilidad (un repuesto en espera). Réplica de lectura = rendimiento (ayudantes que atienden lecturas). A menudo se usan las dos a la vez.

• Copias de seguridad automáticas y la posibilidad de restaurar a un momento concreto del pasado.
• Parches del motor y del sistema operativo.
• Alta disponibilidad con Multi-AZ.
• Escalado de lecturas con réplicas.
• Monitorización integrada.
• Cifrado de los datos en reposo y en tránsito.

• RDS es un servicio gestionado (PaaS) para bases de datos relacionales (tablas + SQL): AWS se ocupa de parches, copias y administración; tú, de tus datos.
• Soporta los motores populares (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server y Aurora); puedes migrar sin cambiar el código.
• Multi-AZ = alta disponibilidad: copia de reserva en otra AZ que toma el relevo automáticamente si la principal falla.
• Réplicas de lectura = rendimiento: copias que atienden consultas de lectura para aliviar la carga.
• No confundas ambas: una es para tolerar fallos, la otra para escalar lecturas. Suelen combinarse.

En el siguiente subcapítulo veremos Aurora, el motor de base de datos propio de AWS, y por qué a menudo supera al RDS «clásico».