# 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](../README.md), 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

| Fichero | Para qué sirve | En qué paso se usa |
|---|---|---|
| `README.md` | Esta guía | Siempre |

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:

```bash
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:

```bash
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

| Síntoma | Causa | Solución |
|---|---|---|
| El `endpoint` sale como `None` | La RDS aún está en `creating` | Espera a `available` (unos 6 minutos) y repite el comando |
| `InstanceQuotaExceeded: You reached the maximum number of instances available with free plan accounts` al crear una RDS | Límite del plan gratuito de AWS: no deja tener más de un cierto número de instancias RDS a la vez | Si es la segunda RDS (ejercicio 3B), mira las dos salidas de `../03.04-webappexportar/` |
| Más adelante, `estudiantes.php` da `Access denied` o `Connections using insecure transport are prohibited` | Tu RDS es MariaDB 11.x y exige conexión cifrada | Crea la RDS con MariaDB 10.11 (paso 1) |
| `aws rds describe-db-instances` sale vacío | CloudShell está en otra región | `echo "$AWS_REGION"`; cierra CloudShell, cambia la región de la consola y ábrelo de nuevo, o añade `--region eu-north-1` (ya va en el comando) |

## 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`):

```bash
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):

```bash
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:

```bash
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](03.02-adminer/README.md)