Bases managées dans le cloud (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)

Symptôme

Objectif : connaître les principales différences entre les bases managées dans le cloud et les installations autogérées ; comprendre le fonctionnement de la sauvegarde, des paramètres, du failover, de la surveillance, des montées de version et de la connectivité dans le cloud.

1. Changement d'état d'esprit : vous accédez à un service, pas à un serveur

Avec les bases managées, vous n'avez AUCUN accès shell à l'OS, au système de fichiers ou au processus de la base ; vous ne pouvez pas vous connecter en SSH, modifier les fichiers de configuration à la main ni devenir superuser. Vous disposez uniquement de l'API/la console d'administration du fournisseur et d'une connexion SQL normale. AWS RDS/Aurora : l'administration se fait au niveau de la ressource (instance/cluster), le serveur est masqué. GCP Cloud SQL : API d'instance uniquement, pas d'OS. MongoDB Atlas : cluster entièrement managé, aucun accès à mongod. Azure SQL Database : PaaS, ni le serveur ni l'OS ne sont visibles (Managed Instance offre un peu plus de contrôle). La plupart des réflexes de l'autogéré, comme « regarder le fichier », « tuer le processus » ou « lancer un outil OS », ne s'appliquent donc pas.

2. Sauvegarde : snapshots automatiques + restauration à un instant donné (PITR)

Vous ne planifiez pas les sauvegardes ; le fournisseur les effectue automatiquement. La récupération consiste généralement à « restaurer à un instant précis » (PITR) ou à créer une nouvelle instance à partir d'un snapshot ; l'instance existante n'est pas écrasée. AWS RDS/Aurora : sauvegardes automatiques + fenêtre de rétention ; une restauration PITR à la seconde près s'ouvre comme une nouvelle instance/un nouveau cluster ; des snapshots manuels sont aussi possibles. GCP Cloud SQL : sauvegardes automatiques + PITR via les binary logs ; la restauration se fait vers une nouvelle instance. MongoDB Atlas : sauvegarde cloud continue + PITR (M10+) ; restauration depuis des snapshots. Azure SQL : sauvegardes automatiques intégrées, rétention de 1 à 35 jours, PITR à n'importe quel instant et restauration des bases supprimées. Règle commune : vérifiez la configuration des sauvegardes (fenêtre, durée de rétention) et effectuez des tests de restauration réguliers.

3. Paramètres : parameter groups / flags, pas de fichier de configuration

Au lieu de modifier postgresql.conf ou my.cnf à la main, vous utilisez l'abstraction de paramètres du fournisseur ; certains paramètres sont verrouillés et certains exigent un redémarrage (statiques). AWS RDS/Aurora : définis via un DB parameter group (et un cluster parameter group) ; les paramètres dynamiques s'appliquent immédiatement, les statiques au reboot. GCP Cloud SQL : les « database flags » se définissent depuis la console/gcloud. MongoDB Atlas : « Additional Settings » limités + taille de l'oplog etc. ; la plupart des paramètres internes sont managés. Azure SQL : la plupart des réglages au niveau serveur sont managés ; le comportement se modifie via SCOPED CONFIGURATION et le choix du niveau de service. Avant d'appliquer, vérifiez si le paramètre est dynamique ou statique.

4. Haute disponibilité / failover : Multi-AZ et réplicas managés

Vous ne construisez pas le failover vous-même ; vous cochez une case et laissez faire le fournisseur. Le standby et le failover automatique sont managés, et les connexions sont redirigées vers le nouveau primaire via un endpoint stable. AWS RDS : Multi-AZ (standby synchrone, failover automatique) ; Aurora : stockage multi-copies + failover automatique, le cluster endpoint pointe vers le writer. GCP Cloud SQL : configuration HA (régionale, standby dans une zone secondaire) en un clic ; les réplicas en lecture s'ajoutent séparément. MongoDB Atlas : replica set intégré, déploiement multirégion/multicloud disponible, failover automatique. Azure SQL : HA intégrée (réplicas locaux en Business Critical), option zone-redundant et active geo-replication / failover groups inter-régions. L'application doit toujours se connecter à l'endpoint, jamais à une IP fixe.

5. Surveillance : le service de métriques et de logs du fournisseur

Comme vous ne pouvez pas exécuter d'outils OS (top, iostat), vous surveillez via la plateforme de métriques du fournisseur ; les métriques CPU, nombre de connexions, IOPS, retard de réplication et stockage s'y trouvent. AWS : métriques CloudWatch + Enhanced Monitoring + Performance Insights (analyse au niveau requête). GCP Cloud SQL : Cloud Monitoring (anciennement Stackdriver) + Query Insights. MongoDB Atlas : métriques/graphiques Atlas intégrés + Performance Advisor + panneau temps réel. Azure SQL : Azure Monitor + SQL Analytics + Query Performance Insight. Configurez toujours des alarmes de seuil (utilisation du stockage, CPU, limite de connexions, retard des réplicas).

6. Montées de version et maintenance : depuis la console, dans une fenêtre de maintenance

Au lieu de mettre à jour les binaires à la main, vous choisissez une version cible ; les patchs de version mineure sont le plus souvent automatiques, tandis que les montées de version majeure sont planifiées et impliquent généralement une interruption/un failover HA. AWS RDS/Aurora : choix de la version du moteur + option de montée mineure automatique + montées majeures à faible risque avec Blue/Green Deployments. GCP Cloud SQL : fenêtre de maintenance + montée de version majeure en libre-service. MongoDB Atlas : montée de version en un clic, interruption quasi nulle en mode rolling. Azure SQL : patché automatiquement par la plateforme (la notion de version est largement abstraite) ; le comportement se contrôle avec le niveau de compatibilité. Essayez toujours d'abord sur une copie de test/préproduction et planifiez la fenêtre de maintenance hors des heures ouvrées.

7. Connectivité et sécurité : endpoint + IAM/TLS

Les connexions passent toujours par l'endpoint DNS fourni par le fournisseur et sont chiffrées (TLS) ; l'accès réseau et l'identité peuvent être liés au système d'identité du cloud. AWS RDS/Aurora : endpoint d'instance/de cluster + Security Group pour le réseau + authentification IAM à la base en option + TLS (certificat rds-ca). GCP Cloud SQL : IP publique + Authorized Networks ou IP privée/VPC, Cloud SQL Auth Proxy, authentification IAM à la base, TLS. MongoDB Atlas : chaîne de connexion SRV (mongodb+srv://), IP access list + private endpoint/peering, SCRAM ou IAM/X.509, TLS obligatoire. Azure SQL : endpoint FQDN du serveur + pare-feu/Private Link + authentification Microsoft Entra ID (anciennement Azure AD) + TLS obligatoire. Règle : utilisez l'endpoint, et non une IP fixe, dans la chaîne de connexion, imposez TLS et connectez-vous avec une identité IAM du cloud lorsque c'est possible.