Bases de datos gestionadas en la nube (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)

Síntoma

Objetivo: conocer las diferencias clave entre las bases de datos gestionadas en la nube y las instalaciones autogestionadas; entender cómo funcionan en la nube el backup, los parámetros, el failover, el monitoreo, las actualizaciones y la conectividad.

1. Cambio de mentalidad: accede a un servicio, no a un servidor

Con las bases de datos gestionadas NO tiene acceso de shell al SO, al sistema de archivos ni al proceso de la base de datos; no puede entrar por SSH, editar archivos de configuración a mano ni convertirse en superusuario. Solo dispone de la API/consola de gestión del proveedor y de una conexión SQL normal. AWS RDS/Aurora: la gestión es a nivel de recurso (instancia/clúster), el servidor está oculto. GCP Cloud SQL: solo API de instancia, sin SO. MongoDB Atlas: clúster totalmente gestionado, sin acceso a mongod. Azure SQL Database: PaaS, no se ve ni el servidor ni el SO subyacente (Managed Instance da algo más de control). Por eso, la mayoría de los reflejos autogestionados como 'mirar el archivo', 'matar el proceso' o 'ejecutar una herramienta del SO' no aplican.

2. Backup: snapshots automáticos + recuperación a un punto en el tiempo (PITR)

Usted no programa los backups; el proveedor los toma automáticamente. La recuperación suele ser 'restaurar a un punto concreto en el tiempo' (PITR) o crear una nueva instancia a partir de un snapshot; la instancia existente no se sobrescribe. AWS RDS/Aurora: backups automáticos + ventana de retención; una restauración PITR con precisión de segundos se abre como una nueva instancia/clúster; también se pueden tomar snapshots manuales. GCP Cloud SQL: backups automáticos + PITR mediante binary logs; la restauración va a una nueva instancia. MongoDB Atlas: backup continuo en la nube + PITR (M10+); restauración desde snapshots. Azure SQL: backups automáticos integrados, retención de 1-35 días, PITR a cualquier punto y restauración de BD eliminadas. Regla común: verifique la configuración de backup (ventana, período de retención) y realice pruebas de restauración periódicas.

3. Parámetros: parameter groups / flags, no un archivo de configuración

En lugar de editar postgresql.conf o my.cnf a mano, se usa la abstracción de parámetros del proveedor; algunos parámetros están bloqueados y otros requieren reinicio (estáticos). AWS RDS/Aurora: se definen mediante un DB parameter group (y un cluster parameter group); los parámetros dinámicos se aplican de inmediato, los estáticos al reiniciar. GCP Cloud SQL: los 'database flags' se definen desde la consola/gcloud. MongoDB Atlas: 'Additional Settings' limitados + tamaño del oplog, etc.; la mayoría de los parámetros internos están gestionados. Azure SQL: la mayoría de los ajustes a nivel de servidor están gestionados; el comportamiento se cambia mediante SCOPED CONFIGURATION y la elección del nivel de servicio. Antes de aplicar, compruebe si el parámetro es dinámico o estático.

4. Alta disponibilidad / failover: Multi-AZ y réplicas gestionados

Usted no construye el failover; marca una casilla y lo deja en manos del proveedor. El standby y el failover automático están gestionados, y las conexiones se redirigen al nuevo primario a través de un endpoint estable. AWS RDS: Multi-AZ (standby síncrono, failover automático); Aurora: almacenamiento con múltiples copias + failover automático, el cluster endpoint apunta al writer. GCP Cloud SQL: configuración de HA (regional, standby en una zona secundaria) con un clic; las réplicas de lectura se agregan por separado. MongoDB Atlas: replica set integrado, despliegue multirregión/multinube disponible, failover automático. Azure SQL: HA integrada (réplicas locales en Business Critical), una opción con redundancia de zona y geo-replicación activa entre regiones / failover groups. La aplicación siempre debe conectarse al endpoint, nunca a una IP fija.

5. Monitoreo: el servicio de métricas y logs del proveedor

Como no puede ejecutar herramientas del SO (top, iostat), monitoree a través de la plataforma de métricas del proveedor; allí están las métricas de CPU, número de conexiones, IOPS, lag de replicación y almacenamiento. AWS: métricas de CloudWatch + Enhanced Monitoring + Performance Insights (análisis a nivel de consulta). GCP Cloud SQL: Cloud Monitoring (antes Stackdriver) + Query Insights. MongoDB Atlas: métricas/gráficos integrados de Atlas + Performance Advisor + panel en tiempo real. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. Configure siempre alarmas por umbral (uso de almacenamiento, CPU, límite de conexiones, lag de réplica).

6. Actualizaciones de versión y mantenimiento: desde la consola, en una ventana de mantenimiento

En lugar de actualizar los binarios a mano, elige una versión de destino; los parches de versión minor son mayormente automáticos, mientras que las actualizaciones de versión major se planifican y suelen implicar tiempo de inactividad o un failover de HA. AWS RDS/Aurora: selección de la versión del motor + opción de actualización minor automática + actualizaciones major de bajo riesgo con Blue/Green Deployments. GCP Cloud SQL: ventana de mantenimiento + actualización de versión major en autoservicio. MongoDB Atlas: actualización de versión con un clic, de forma rolling con tiempo de inactividad casi nulo. Azure SQL: la plataforma aplica los parches automáticamente (el concepto de versión está en gran parte abstraído); el comportamiento se controla con el nivel de compatibilidad. Pruebe siempre primero en una copia de test/staging y programe la ventana de mantenimiento fuera del horario laboral.

7. Conectividad y seguridad: endpoint + IAM/TLS

Las conexiones siempre pasan por el endpoint DNS proporcionado por el proveedor y van cifradas (TLS); el acceso de red y la identidad pueden vincularse al sistema de identidades de la nube. AWS RDS/Aurora: endpoint de instancia/clúster + Security Group para la red + autenticación de base de datos IAM opcional + TLS (certificado rds-ca). GCP Cloud SQL: IP pública + Authorized Networks o IP privada/VPC, Cloud SQL Auth Proxy, autenticación de base de datos IAM, TLS. MongoDB Atlas: cadena de conexión SRV (mongodb+srv://), lista de acceso IP + private endpoint/peering, SCRAM o IAM/X.509, TLS obligatorio. Azure SQL: endpoint FQDN del servidor + firewall/Private Link + autenticación con Microsoft Entra ID (antes Azure AD) + TLS obligatorio. Regla: use el endpoint, no una IP fija, en la cadena de conexión, exija TLS y conéctese con una identidad IAM de la nube cuando sea posible.