Tema 3 · 1 · Crear tu base de datos relacional (RDS MariaDB)

Presentación del Tema 3: «Configuración Security Group» y «Lanzamiento RDS» (Security Group BaseDeDatos y RDS MariaDB). Duración: unos 15 minutos, de los cuales unos 6 son de espera hasta que la RDS está Available (medido). Coste: la RDS factura por hora mientras exista, la uses o no, más el almacenamiento; es lo más caro del tema (céntimos por hora con db.t3.micro y 20 GiB; no se ha medido ninguna factura real).

Etiquetas de lo que creas. Todo recurso que crees a mano (máquina, volumen, bucket, base de datos, tabla, función...) ponle estas etiquetas, al crearlo (apartado Tags / Etiquetas) o después desde su pestaña de etiquetas: curso = G214, universidad = CUNEF y actividad = 03.01-RDSMariaDB. Si algún día hay que borrar recursos a mano, se localizan todos de golpe con aws resourcegroupstaggingapi get-resources --region eu-north-1 --tag-filters Key=actividad,Values=03.01-RDSMariaDB. Más detalle (cómo etiquetar con la CLI, cómo buscar y qué hacer en una emergencia): README principal, sección «Etiquetas».

Qué vas a hacer

Vas a crear en tu cuenta de AWS una base de datos relacional gestionada (Amazon RDS con MariaDB) y a comprobar que está lista para que el resto de actividades del tema se conecten a ella.

Consola AWS ──> Security Group BaseDeDatos (puerto 3306, origen "My IP")
            └─> RDS MariaDB 10.11 (admin / tu contraseña, acceso público)
                         ▲
        las actividades 03.02 (Adminer), 03.03 … 03.06, 03.09 se conectan a ella

Qué se crea en AWS: 1 Security Group BaseDeDatos y 1 instancia RDS MariaDB. Esta carpeta no tiene scripts: todo se hace en la consola de AWS y se comprueba con la AWS CLI desde CloudShell.

Qué contiene esta carpeta

No hay más ficheros: la RDS se crea en la consola siguiendo la presentación y los valores de esta guía.

Antes de empezar

• [ ] Cuenta de AWS propia con sesión iniciada en la consola.
• [ ] La región de la consola es Europa (Estocolmo) eu-north-1 (arriba a la derecha). Cámbiala ANTES de abrir CloudShell: CloudShell trabaja en la región que tenga la consola.
• [ ] Sabes abrir AWS CloudShell (el icono >_ de la barra superior de la consola). Es una terminal Linux en el navegador que ya trae la AWS CLI.
• [ ] Sabes que al terminar el tema hay que borrar todo (al final de esta guía). Recomendado: un presupuesto con alerta por correo en AWS Budgets.
• [ ] Una cuenta con el plan gratuito de AWS limita cuántas instancias RDS puedes tener a la vez y puede responder InstanceQuotaExceeded al crear otra (afecta al ejercicio 3B, en ../03.04-webappexportar/).

Esta es la primera actividad del tema: no depende de ninguna anterior.

Cómo llevar los ficheros a donde toque

No hay ficheros que llevar. Solo necesitas la consola de AWS (para crear la RDS) y CloudShell (para comprobarla).

Comprobación previa en CloudShell:

aws sts get-caller-identity
echo "$AWS_REGION"

Qué verás: la primera orden imprime un JSON con UserId, Account y Arn de tu cuenta; la segunda imprime eu-north-1. Si imprime otra región, cierra CloudShell, cambia la región de la consola a Estocolmo y ábrelo de nuevo: si no, lo que crees después quedaría en otra región y no vería tu RDS.

Paso a paso

Paso 1. Crear la RDS en la consola. Comprueba que cumple esta lista:

• [ ] Motor MariaDB versión 10.11.x (en Engine options > Engine version elige MariaDB 10.11.x, no la 11.x; ver el aviso de abajo). Elige el método Full configuration: el que sale por defecto, Easy create, no deja elegir la versión y crea la 11.x.
• [ ] Clase de instancia: la consola propone db.t4g.micro (plan gratuito); db.t3.micro solo aparece marcando Include previous generation classes, y las dos valen. Almacenamiento gp3 de 20 GiB y sin Multi-AZ.
• [ ] Usuario admin, Public access: yes y el Security Group BaseDeDatos (MySQL/Aurora, tcp/3306) en lugar del default.
• [ ] La contraseña la eliges tú: mínimo 12 caracteres, sin /, ', " ni @, y que no utilices en ningún otro sitio (la de las diapositivas, Cunef2025, es un ejemplo que conoce toda la clase). Apúntala: la necesitarás en todas las actividades siguientes.
• [ ] El puerto 3306 del Security Group BaseDeDatos tiene como origen My IP. La presentación muestra 0.0.0.0/0 (todo Internet): con una contraseña que conoce toda la clase, cualquiera podría entrar en tu base. Los scripts de Adminer (actividad 03.02) no necesitan esa regla (dan acceso por Security Group); solo si usas LOAD DATA (03.09) o CloudShell desde otra red, abre 0.0.0.0/0 el tiempo justo y ciérralo después.

Qué verás: la RDS aparece en la lista con estado Creating. Mientras se crea no tiene endpoint; tarda unos 6 minutos (medido) hasta Available.

Aviso: elige MariaDB 10.11, no la 11.x. AWS propone por defecto una versión nueva (hoy, la 11.8), y las 11.x exigen conexiones cifradas (require_secure_transport=ON). Adminer ya se conecta cifrado (los dos scripts de la actividad 03.02 lo dejan configurado) y el visor Streamlit del Euribor (03.05) también, pero la web PHP estudiantes.php (03.04) no: con una 11.x muestra Connections using insecure transport are prohibited while --require_secure_transport=ON o, según el caso, Access denied aunque la contraseña sea correcta (en una prueba con la 10.11 y require_secure_transport=1 el síntoma fue Access denied). Con la 10.11 funcionan las tres cosas. Si ya creaste la RDS con la 11.x no hace falta rehacerla para Adminer ni para el visor del Euribor; solo falla estudiantes.php. Una diferencia más de la 10.11: sus bases nuevas usan por defecto la codificación latin1, suficiente para las tildes y la ñ de los datos del curso; si algún día guardas emojis o alfabetos no latinos, crea la base con CREATE DATABASE nombre CHARACTER SET utf8mb4;.

Paso 2. Esperar a Available y localizar el endpoint. Desde CloudShell:

aws rds describe-db-instances --region eu-north-1 \
  --query "DBInstances[].[DBInstanceIdentifier,DBInstanceStatus,Endpoint.Address]" \
  --output table

Qué verás: una fila por cada RDS con su identificador (por ejemplo nombre-base-datos), el estado (available) y el endpoint, que tiene esta forma: <identificador>.<código>.eu-north-1.rds.amazonaws.com. Si el estado es creating, el endpoint aparece como None: espera. También lo tienes en la consola: RDS > Databases > tu instancia > pestaña Connectivity & security > Endpoint.

Paso 3. Apunta tres datos. El endpoint, el usuario admin y tu contraseña. Los vas a escribir en Adminer (03.02) y en la web y la app del Euribor (03.04 y 03.05).

Cómo llegará Adminer a tu RDS: el script de la actividad 03.02 añade una regla al Security Group de la RDS que tú indiques (te la pregunta y pide confirmación; no toca las demás RDS de la cuenta) que permite el puerto de la base de datos (3306) desde el Security Group de Adminer (por referencia al grupo, no por IP). Para que funcione, Adminer y tu RDS tienen que estar en la misma región y en la misma VPC: Adminer se crea en la VPC por defecto de la región, que es donde queda tu RDS si la creaste como en las diapositivas. Crea la RDS antes de desplegar Adminer: el script solo ve las RDS que existen en ese momento (si la creas después, hay un comando para dar acceso a posteriori, en 03.02). Esa regla sirve solo para Adminer; la web de 03.04 y la app del Euribor (que corren en la máquina webapp) se conectan con --rds, que añade su propia regla.

Errores frecuentes

Limpieza

Esta es la actividad que borra la RDS, pero no la borres todavía: las actividades 03.02, 03.03, 03.04, 03.05, 03.06 y 03.09 la necesitan. Haz esta limpieza al terminar la última actividad que use tu RDS (la 03.09), y solo después de borrar Adminer (limpieza de ../03.02-adminer/): Adminer va antes que la RDS porque quita sus reglas de tu Security Group. Antes de borrar la RDS, asegúrate de que tienes en tu PC lo que tengas que entregar (por ejemplo, el estudiantes.sql del ejercicio 3): borrarla elimina sus datos sin vuelta atrás.

1. RDS (la de MariaDB y, si hiciste el ejercicio 3B, la de MySQL)

Consola: RDS > Databases > marca la instancia > Actions > Delete; desmarca la copia final (Create final snapshot) y la retención de copias automáticas, marca el reconocimiento y confirma. Por CLI, con el identificador de tu instancia (nombre-base-datos):

aws rds delete-db-instance --db-instance-identifier nombre-base-datos \
  --skip-final-snapshot --delete-automated-backups --region eu-north-1

Qué verás: la instancia pasa a deleting y desaparece en unos minutos (medido: ~1,5 minutos). Comprueba que no queda nada, ni instancias ni copias (un snapshot final sigue facturando por GB-mes aunque la RDS ya no exista):

aws rds describe-db-instances --region eu-north-1 --query "DBInstances[].DBInstanceIdentifier"
aws rds describe-db-snapshots --region eu-north-1 --query "DBSnapshots[].DBSnapshotIdentifier"

Ambos deben imprimir []. Si aparece un snapshot tuyo que no necesitas: aws rds delete-db-snapshot --db-snapshot-identifier <id> --region eu-north-1. Si lo que aparece es un snapshot automático (rds:nombre-base-datos-...), delete-db-snapshot lo rechaza (automated snapshots cannot be deleted): no se puede borrar a mano y desaparece solo al acabar su periodo de retención. Si creaste un parameter group propio para la RDS, bórralo después de borrar la RDS: aws rds delete-db-parameter-group --db-parameter-group-name <nombre> --region eu-north-1.

2. Security Group BaseDeDatos (solo cuando ya no quede ninguna RDS que lo use; no se puede borrar mientras una RDS lo use)

Consola: EC2 > Security Groups > BaseDeDatos > Actions > Delete security groups. Por CLI:

aws ec2 delete-security-group --group-name BaseDeDatos --region eu-north-1

Cómo sabes que has terminado

• [ ] La RDS MariaDB 10.11 está en estado available y sabes su endpoint.
• [ ] Tu contraseña es propia (no Cunef2025) y el puerto 3306 del Security Group BaseDeDatos tiene como origen My IP (o lo has abierto a propósito, solo el tiempo justo).
• [ ] (Al final del tema) Has hecho la limpieza: describe-db-instances y describe-db-snapshots salen en [] (salvo un snapshot automático residual, que se borra solo).

Anterior: (ninguna, es la primera) · Siguiente: 03.02 · Adminer