1. Introducción
Las bases de datos son una pieza fundamental en casi cualquier aplicación moderna. Una web educativa, una tienda online, una aplicación móvil, un sistema de gestión académica o una plataforma de análisis necesitan almacenar, consultar y proteger datos.
En un modelo tradicional, una empresa podía instalar una base de datos manualmente en un servidor propio o en una máquina virtual. Esto implicaba instalar el motor de base de datos, configurarlo, aplicar parches, gestionar usuarios, hacer copias de seguridad, monitorizar el rendimiento, ampliar almacenamiento y diseñar estrategias de recuperación ante fallos.
En la nube, existe una alternativa mucho más cómoda y profesional: usar bases de datos administradas.
Una base de datos administrada es un servicio en el que el proveedor cloud se encarga de gran parte de la infraestructura y mantenimiento. El usuario no tiene que instalar manualmente MySQL, PostgreSQL, SQL Server o un sistema NoSQL desde cero. En su lugar, elige el tipo de base de datos, configura parámetros básicos y empieza a trabajar con sus datos.
Esto no significa que el usuario se desentienda completamente. Sigue siendo responsable de diseñar bien el modelo de datos, configurar accesos, proteger credenciales, elegir correctamente la red, controlar costes y decidir qué tipo de base de datos necesita.
La clave de este tema es entender que no todas las bases de datos sirven para lo mismo.
No es igual una base de datos para una aplicación web tradicional que una base de datos para millones de eventos de sensores IoT. No es igual almacenar usuarios y pedidos que analizar grandes volúmenes de datos históricos. No es igual una base de datos transaccional que una base de datos analítica.
En AWS, algunos de los servicios principales son:
- Amazon RDS, para bases de datos relacionales administradas.
- Amazon DynamoDB, para bases de datos NoSQL administradas.
- Amazon Redshift, para análisis de grandes volúmenes de datos.
La pregunta importante no es solo “qué base de datos conozco”, sino qué tipo de datos tengo, cómo los voy a consultar, qué rendimiento necesito y qué responsabilidades quiero delegar en el proveedor.
2. Concepto clave
El concepto clave de este tema es la diferencia entre gestionar una base de datos manualmente y utilizar una base de datos administrada.
En una instalación manual, el usuario controla casi todo, pero también debe mantener casi todo.
En una base de datos administrada, el proveedor asume muchas tareas operativas:
- Gestión del servidor.
- Instalación del motor.
- Parches y actualizaciones.
- Copias de seguridad automáticas.
- Alta disponibilidad.
- Monitorización básica.
- Escalado.
- Replicación.
- Recuperación ante fallos.
El usuario, en cambio, se centra más en:
- Diseñar los datos.
- Crear tablas o colecciones.
- Gestionar usuarios y permisos.
- Configurar seguridad.
- Consultar información.
- Optimizar consultas.
- Controlar costes.
- Elegir correctamente el tipo de servicio.
Esquema general
Servicios de bases de datos en la nube │ ├── Bases de datos relacionales │ └── Amazon RDS │ ├── MySQL │ ├── PostgreSQL │ ├── MariaDB │ ├── Oracle │ └── SQL Server │ ├── Bases de datos NoSQL │ └── Amazon DynamoDB │ ├── Clave-valor │ └── Documento │ └── Bases de datos analíticas └── Amazon Redshift ├── Data warehouse ├── BI └── Análisis masivo
Base de datos instalada manualmente frente a base de datos administrada
Opción A: Base de datos en EC2 EC2 ├── Sistema operativo ├── Motor MySQL/PostgreSQL ├── Configuración manual ├── Backups manuales ├── Parches manuales └── Monitorización manual
Opción B: Base de datos administrada Amazon RDS ├── Motor gestionado ├── Backups automáticos ├── Parches gestionados ├── Alta disponibilidad opcional ├── Monitorización integrada └── Menor mantenimiento operativo
La base de datos administrada no elimina todas las decisiones técnicas, pero reduce muchísimo la carga de administración.
Comparativa inicial
| Aspecto | MySQL en EC2 | Amazon RDS |
|---|---|---|
| Instalación del motor | Manual | Gestionada |
| Parches | Manuales | Gestionados |
| Backups | Manuales | Automáticos |
| Alta disponibilidad | Hay que diseñarla | Multi-AZ opcional |
| Acceso al sistema operativo | Sí | No |
| Mantenimiento | Mayor | Menor |
| Control interno | Alto | Medio |
| Simplicidad operativa | Menor | Mayor |
La elección depende del caso. Si se necesita control extremo sobre el sistema operativo, EC2 puede tener sentido. Pero para la mayoría de aplicaciones web habituales, una base de datos administrada suele ser una opción más segura, mantenible y profesional.
Bases de datos relacionales
Las bases de datos relacionales son las más clásicas y siguen siendo muy utilizadas.
Organizan la información en tablas, con filas y columnas. Permiten definir relaciones entre entidades y utilizar SQL para consultar y modificar los datos.
Ejemplos de motores relacionales: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
Características principales: tablas, columnas, filas, claves primarias, claves foráneas, relaciones, restricciones, transacciones, integridad referencial, consultas SQL.
Tabla: alumnos │ ├── id ├── nombre ├── email └── grupo_id
Tabla: grupos │ ├── id ├── nombre └── curso
Cuándo usar una base de datos relacional: datos con estructura clara, relaciones entre entidades, necesidad de transacciones, reglas de integridad, uso de SQL, consistencia fuerte, operaciones CRUD habituales. Ejemplos: gestión de alumnos, aplicaciones web tradicionales, sistemas académicos, comercio electrónico, facturación.
Amazon RDS
Amazon RDS (Relational Database Service) es el servicio de AWS para bases de datos relacionales administradas. Permite crear bases de datos usando motores conocidos como MySQL, PostgreSQL, MariaDB, Oracle o SQL Server. La ventaja es que el usuario no tiene que instalar el motor desde cero ni administrar directamente el servidor.
Aplicación web │ ▼ Endpoint de RDS │ ▼ Amazon RDS │ ├── Motor MySQL/PostgreSQL ├── Backups automáticos ├── Monitorización ├── Almacenamiento gestionado └── Alta disponibilidad opcional
Backups automáticos: RDS permite configurar copias de seguridad automáticas para recuperación ante borrado accidental, error de aplicación, fallo de actualización, corrupción de datos o necesidad de restaurar un punto anterior.
Multi-AZ: permite desplegar una réplica automática en otra zona de disponibilidad. Si la instancia principal falla, RDS puede hacer una conmutación por error hacia la réplica.
Región AWS │ ├── Zona de disponibilidad A │ └── RDS principal │ └── Zona de disponibilidad B └── RDS réplica standby
Réplicas de lectura: permiten crear copias de la base de datos para descargar consultas de solo lectura.
Aplicación │ ├── Escrituras → RDS principal └── Lecturas pesadas → Réplica de lectura
Escalado vertical: RDS permite aumentar el tamaño de la instancia, pasando de una instancia pequeña a otra con más CPU o memoria.
Monitorización integrada: RDS se integra con herramientas para revisar CPU, memoria, conexiones, latencia, almacenamiento, IOPS, errores y estado de backups.
Caso de uso: una aplicación educativa con usuarios, cursos, módulos, entregas, calificaciones, profesores y grupos encaja naturalmente en un modelo relacional.
Bases de datos NoSQL
Las bases de datos NoSQL no siguen el modelo relacional tradicional. Pueden usar modelos como: clave-valor, documentos, grafos o columnas anchas.
Características: esquema flexible, alta escalabilidad horizontal, baja latencia, gran volumen de datos, buen rendimiento con patrones de acceso concretos.
Esto no significa que NoSQL sea “mejor” que SQL. Significa que está pensado para otros escenarios.
Amazon DynamoDB
Amazon DynamoDB es una base de datos NoSQL administrada por AWS. Permite trabajar con modelos de clave-valor y documento.
Características: totalmente gestionada, escalado automático, baja latencia, alta disponibilidad, integración con Lambda, sin administración de servidores.
Aplicación serverless │ ▼ API Gateway │ ▼ Lambda │ ▼ DynamoDB │ ├── Clave primaria ├── Atributos flexibles └── Lecturas/escrituras escalables
Ejemplo de documento en NoSQL:
{
"usuarioId": "u123",
"nombre": "Laura",
"email": "laura@example.com",
"preferencias": {
"tema": "oscuro",
"notificaciones": true
},
"ultimoAcceso": "2026-05-27T10:30:00"
}Casos de uso: aplicaciones móviles, juegos online, IoT, sistemas con muchas peticiones, arquitecturas serverless, datos de sesión, carritos de compra, preferencias de usuario, eventos de actividad.
Bases de datos analíticas
Las bases de datos analíticas están diseñadas para analizar grandes volúmenes de datos: informes, Business Intelligence, análisis histórico, consultas complejas, agregaciones, tendencias y cuadros de mando.
Amazon Redshift
Amazon Redshift es un servicio de data warehouse administrado, optimizado para consultas analíticas sobre grandes cantidades de datos.
Características: almacenamiento columnar, procesamiento paralelo, escalado de clúster, integración con S3 y herramientas de BI.
Transaccional frente a analítica
| Aspecto | Base transaccional | Base analítica |
|---|---|---|
| Ejemplo AWS | RDS | Redshift |
| Uso principal | Operaciones diarias | Análisis masivo |
| Operaciones | CRUD frecuente | Consultas complejas |
| Datos | Actualizados constantemente | Históricos y agregados |
| Caso típico | Aplicación web | BI e informes |
RDS / S3 │ ▼ Redshift │ ▼ Informes y dashboards
Relacional frente a NoSQL
| Aspecto | Relacional | NoSQL |
|---|---|---|
| Organización | Tablas | Documentos, clave-valor |
| Esquema | Más rígido | Más flexible |
| Consultas | SQL | APIs específicas |
| Relaciones | Muy buenas | Menos naturales |
| Transacciones complejas | Muy adecuadas | Depende del servicio |
| Escalabilidad masiva | Posible, más compleja | Muy orientada a ello |
| Caso típico | Aplicación empresarial | App móvil, IoT, serverless |
Despliegue de una base de datos administrada
Proceso conceptual para crear una RDS
- Elegir motor
- Elegir tamaño de instancia
- Configurar almacenamiento
- Configurar red (VPC, subred privada)
- Configurar seguridad (Security Group, cifrado)
- Configurar disponibilidad (backups, Multi-AZ)
- Activar monitorización
Internet │ ▼ Balanceador / aplicación web │ ▼ EC2 / Backend en subred pública o privada │ ▼ RDS en subred privada │ ├── Sin IP pública ├── Security Group restrictivo ├── Cifrado activado ├── Backups automáticos └── Acceso solo desde la aplicación
Costes en bases de datos administradas
| Factor | Explicación |
|---|---|
| Tipo de instancia | Más CPU y RAM implican mayor coste |
| Almacenamiento | Más GB almacenados, mayor coste |
| IOPS/rendimiento | Opciones de alto rendimiento encarecen |
| Multi-AZ | Alta disponibilidad aumenta coste |
| Réplicas de lectura | Cada réplica suma recursos |
| Transferencia de datos | Puede haber coste según tráfico |
| Backups adicionales | Más retención puede aumentar almacenamiento |
| Motor elegido | Algunos motores implican licencias |
3. Ejemplo mínimo
Imaginemos una aplicación web sencilla para gestionar cursos, que necesita guardar usuarios, cursos, matrículas, entregas y calificaciones.
Usuario │ ▼ Aplicación web │ ▼ Amazon RDS MySQL/PostgreSQL
VPC │ ├── Subred pública │ └── Servidor web / API │ └── Subred privada └── Amazon RDS
| Decisión | Opción razonable |
|---|---|
| Tipo de base de datos | Relacional |
| Servicio | Amazon RDS |
| Motor | MySQL o PostgreSQL |
| Red | Subred privada |
| Acceso público | No |
| Backups | Activados |
| Cifrado | Activado |
| Seguridad | Solo acceso desde la aplicación |
¿Por qué no DynamoDB? Si la aplicación tiene relaciones claras entre usuarios, cursos, matrículas y calificaciones, una base relacional suele ser más natural. NoSQL no es “más moderno y por tanto mejor”. Es mejor cuando el problema encaja con su modelo.
4. Ejemplo completo
Supongamos que un centro educativo quiere crear una plataforma llamada DataAula Cloud con: gestión de usuarios, grupos, entrega de tareas, calificaciones, registro de actividad, notificaciones, informes de uso y análisis histórico.
DataAula Cloud │ ├── Aplicación principal │ └── Amazon RDS PostgreSQL │ ├── usuarios │ ├── grupos │ ├── módulos │ ├── tareas │ ├── entregas │ └── calificaciones │ ├── Eventos de actividad │ └── Amazon DynamoDB │ ├── usuarioId │ ├── evento │ ├── fecha │ └── metadatos │ ├── Datos históricos │ └── Amazon S3 │ ├── exportaciones │ └── logs procesados │ └── Análisis e informes └── Amazon Redshift ├── tendencias ├── estadísticas └── dashboards
Por qué RDS: hay entidades claramente relacionadas (alumno ↔ matrícula ↔ módulo ↔ entrega ↔ calificación). Necesitamos integridad, relaciones y consultas estructuradas.
Por qué DynamoDB: los eventos de actividad son numerosos, no siempre tienen la misma estructura y el acceso es por clave (usuarioId).
Por qué Redshift: el análisis histórico (tendencias, uso de materiales, evolución de calificaciones) no debe ejecutarse sobre la base transaccional principal.
Cómo elegir la base de datos adecuada
¿Qué necesito hacer con los datos? │ ├── Aplicación web tradicional con relaciones │ └── RDS │ ├── Acceso muy rápido por clave y escala masiva │ └── DynamoDB │ ├── Informes, BI y análisis histórico │ └── Redshift │ └── Archivos, exportaciones o datasets └── S3
| Necesidad | Servicio recomendado | Justificación |
|---|---|---|
| Usuarios, pedidos, matrículas | RDS | Datos estructurados y relacionados |
| Eventos de actividad | DynamoDB | Alta escala y esquema flexible |
| Informes históricos | Redshift | Consultas analíticas masivas |
| Exportaciones CSV | S3 | Almacenamiento de objetos |
| Aplicación serverless sencilla | DynamoDB | Integración con Lambda |
| Aplicación empresarial clásica | RDS | SQL, transacciones e integridad |
5. Errores frecuentes
- Instalar una base de datos en EC2 sin necesidad: obliga a gestionar parches, backups, monitorización, alta disponibilidad, seguridad y replicación manualmente.
- Hacer pública la base de datos: uno de los errores más graves. Debe estar en subred privada y aceptar conexiones solo desde la aplicación.
- No activar backups: una base de datos sin backups es una bomba de relojería.
- No probar la restauración: un backup que nunca se ha probado es una promesa, no una garantía.
- Elegir NoSQL porque “es más moderno”: si los datos son relacionales, una base relacional puede ser mucho más adecuada.
- Usar RDS para analítica pesada: los informes pesados pueden afectar a la aplicación principal.
- No controlar costes: instancias grandes, Multi-AZ, réplicas y almacenamiento sobredimensionado pueden encarecer el servicio.
- No configurar bien los Security Groups: permitir acceso desde cualquier IP es un error grave (p. ej. puerto 3306 abierto a
0.0.0.0/0). - Guardar credenciales en el código: usar variables de entorno seguras, Secret Managers o roles.
- No monitorizar rendimiento: CPU, memoria, conexiones, consultas lentas, bloqueos, latencia y almacenamiento deben revisarse.
6. Buenas prácticas
- Usar bases de datos administradas cuando tenga sentido: reducen mantenimiento y mejoran la operación.
- Elegir el modelo según el caso de uso: no hay una base de datos universal.
- Mantener la base de datos en subred privada, protegida de Internet.
- Aplicar mínimo privilegio: usuarios y aplicaciones deben tener solo los permisos necesarios.
- Activar cifrado en reposo y en tránsito (TLS, KMS).
- Activar backups automáticos desde el inicio, con frecuencia, retención y pruebas periódicas definidas.
- Usar Multi-AZ para producción crítica, valorando el aumento de coste.
- Separar entornos: desarrollo, pruebas y producción con bases de datos independientes.
- Monitorizar y revisar consultas: consultas lentas, índices, CPU, conexiones, bloqueos, espacio disponible.
- Gestionar credenciales con seguridad: Secret Manager, rotación periódica, sin contraseñas en código.
- Documentar la decisión: por qué se eligió ese servicio, qué motor, región, subred, backups, cifrado, coste y estrategia de recuperación.
7. Ejercicio propuesto
Caso práctico: elección de bases de datos para una plataforma educativa
Un centro educativo quiere crear una plataforma llamada DataCloud Aula con: usuarios, profesores, alumnos, grupos, módulos, tareas, entregas, calificaciones, registro de actividad, informes estadísticos y cuadros de mando.
Tareas (responde de forma razonada):
- Base de datos administrada: explica qué es, qué tareas asume el proveedor y cuáles mantiene el usuario.
- RDS: explica qué es, qué motores permite, para qué datos de DataCloud Aula lo usarías y qué ventajas tiene frente a instalar MySQL en EC2.
- Diseño relacional básico: propón tablas (usuarios, alumnos, profesores, grupos, módulos, tareas, entregas, calificaciones) y explica sus relaciones.
- DynamoDB: explica qué es, para qué parte de la plataforma podría utilizarse (registro de actividad, preferencias) y por qué.
- Redshift: explica qué es y para qué informes o análisis (evolución de calificaciones, tasa de entrega, actividad por grupo).
- Comparativa SQL vs NoSQL: completa la tabla con organización, esquema, consultas, relaciones, escalabilidad y caso de uso.
- Transaccional frente a analítica: diferencia. ¿Usarías RDS o Redshift para cada necesidad?
- Despliegue seguro de RDS: propón esquema con VPC, subred privada, Security Group, sin acceso público, cifrado y backups.
- Multi-AZ: explica qué es, cuándo activarlo y qué ventaja aporta.
- Costes: indica los factores que influyen en el coste.
- Errores a evitar: indica al menos cinco errores frecuentes.
Solución orientativa: DataCloud Aula │ ├── Amazon RDS PostgreSQL → usuarios, alumnos, grupos, módulos, tareas, entregas, calificaciones ├── Amazon DynamoDB → eventos de actividad, preferencias, notificaciones rápidas ├── Amazon S3 → exportaciones CSV, datasets, logs procesados └── Amazon Redshift → informes históricos, análisis de resultados, cuadros de mando
VPC ├── Subred de aplicación → Backend/API └── Subred privada de datos └── RDS PostgreSQL ├── Sin acceso público ├── Security Group solo desde backend ├── Backups automáticos ├── Cifrado activado └── Multi-AZ en producción
Conclusión
Los servicios de bases de datos en la nube permiten almacenar, consultar y analizar información sin tener que administrar manualmente toda la infraestructura. Las bases de datos administradas reducen mantenimiento, mejoran la disponibilidad y simplifican tareas como backups, monitorización, parches y escalado.
- Amazon RDS es adecuado para aplicaciones relacionales tradicionales, con datos estructurados, SQL, relaciones e integridad.
- Amazon DynamoDB encaja en escenarios NoSQL, serverless, de alta escala y con acceso rápido por clave.
- Amazon Redshift está pensado para análisis masivo, informes, BI y consultas sobre grandes volúmenes de datos históricos.
La decisión correcta depende del tipo de dato, la forma de acceso, la necesidad de relaciones, el volumen, la disponibilidad, el rendimiento y el coste. Elegir una base de datos cloud no consiste en usar la más famosa ni la más moderna. Consiste en usar la que mejor se adapta al problema.