Cloud-verwaltete Datenbanken (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)

Symptom

Ziel: die wesentlichen Unterschiede zwischen Cloud-verwalteten Datenbanken und selbst verwalteten Installationen kennen; verstehen, wie Backup, Parameter, Failover, Monitoring, Upgrades und Konnektivität in der Cloud funktionieren.

1. Umdenken: Du greifst auf einen Dienst zu, nicht auf einen Server

Bei verwalteten Datenbanken hast du KEINEN Shell-Zugriff auf das OS, das Dateisystem oder den Datenbankprozess; du kannst dich nicht per SSH anmelden, Konfigurationsdateien nicht von Hand bearbeiten und nicht Superuser werden. Du erhältst nur die Verwaltungs-API/Konsole des Anbieters und eine normale SQL-Verbindung. AWS RDS/Aurora: Verwaltung auf Ressourcenebene (Instanz/Cluster), der Server ist verborgen. GCP Cloud SQL: nur Instanz-API, kein OS. MongoDB Atlas: vollständig verwalteter Cluster, kein Zugriff auf mongod. Azure SQL Database: PaaS, weder Server noch OS sind sichtbar (Managed Instance bietet etwas mehr Kontrolle). Die meisten Reflexe aus selbst verwalteten Umgebungen wie 'in die Datei schauen', 'den Prozess beenden' oder 'ein OS-Werkzeug ausführen' greifen also nicht.

2. Backup: automatische Snapshots + Point-in-Time-Recovery (PITR)

Du planst keine Backups; der Anbieter erstellt sie automatisch. Die Wiederherstellung bedeutet meist 'auf einen bestimmten Zeitpunkt zurücksetzen' (PITR) oder das Erstellen einer neuen Instanz aus einem Snapshot; die bestehende Instanz wird nicht überschrieben. AWS RDS/Aurora: automatische Backups + Aufbewahrungsfenster; eine sekundengenaue PITR-Wiederherstellung öffnet sich als neue Instanz bzw. neuer Cluster; manuelle Snapshots sind ebenfalls möglich. GCP Cloud SQL: automatische Backups + PITR über Binary Logs; die Wiederherstellung erfolgt in eine neue Instanz. MongoDB Atlas: kontinuierliches Cloud-Backup + PITR (M10+); Wiederherstellung aus Snapshots. Azure SQL: eingebaute automatische Backups, 1-35 Tage Aufbewahrung, PITR auf jeden Zeitpunkt und Wiederherstellung gelöschter DBs. Allgemeine Regel: Prüfe die Backup-Konfiguration (Fenster, Aufbewahrungsdauer) und führe regelmäßig Wiederherstellungstests durch.

3. Parameter: Parametergruppen / Flags statt Konfigurationsdatei

Statt postgresql.conf oder my.cnf von Hand zu bearbeiten, nutzt du die Parameter-Abstraktion des Anbieters; manche Parameter sind gesperrt, manche erfordern einen Neustart (statisch). AWS RDS/Aurora: Einstellung über eine DB Parameter Group (und eine Cluster Parameter Group); dynamische Parameter greifen sofort, statische beim Reboot. GCP Cloud SQL: 'Database Flags' werden über Konsole/gcloud gesetzt. MongoDB Atlas: begrenzte 'Additional Settings' + Oplog-Größe usw.; die meisten internen Parameter werden verwaltet. Azure SQL: Die meisten Einstellungen auf Serverebene werden verwaltet; das Verhalten ändert sich über SCOPED CONFIGURATION und die Wahl der Dienstebene. Prüfe vor dem Anwenden, ob der Parameter dynamisch oder statisch ist.

4. Hochverfügbarkeit / Failover: verwaltetes Multi-AZ und Replicas

Du baust das Failover nicht selbst; du setzt ein Häkchen und überlässt es dem Anbieter. Standby und automatisches Failover werden verwaltet, und Verbindungen werden über einen stabilen Endpoint zur neuen Primary umgeleitet. AWS RDS: Multi-AZ (synchrone Standby, automatisches Failover); Aurora: mehrfach kopierter Storage + automatisches Failover, der Cluster-Endpoint zeigt auf den Writer. GCP Cloud SQL: HA-Konfiguration (regional, Standby in einer zweiten Zone) per Klick; Read Replicas werden separat hinzugefügt. MongoDB Atlas: Replica Set integriert, Multi-Region-/Multi-Cloud-Bereitstellung verfügbar, Failover automatisch. Azure SQL: eingebaute HA (lokale Replicas in Business Critical), eine zonenredundante Option und regionsübergreifende Active Geo-Replication / Failover Groups. Die Anwendung muss sich immer mit dem Endpoint verbinden, nie mit einer festen IP.

5. Monitoring: Metrik- und Log-Dienst des Anbieters

Da du keine OS-Werkzeuge (top, iostat) ausführen kannst, überwachst du über die Metrikplattform des Anbieters; dort liegen Metriken zu CPU, Verbindungsanzahl, IOPS, Replikations-Lag und Storage. AWS: CloudWatch-Metriken + Enhanced Monitoring + Performance Insights (Analyse auf Abfrageebene). GCP Cloud SQL: Cloud Monitoring (früher Stackdriver) + Query Insights. MongoDB Atlas: integrierte Atlas-Metriken/-Diagramme + Performance Advisor + Echtzeit-Panel. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. Richte immer Schwellenwert-Alarme ein (Storage-Belegung, CPU, Verbindungslimit, Replica-Lag).

6. Versions-Upgrades und Wartung: über die Konsole, im Wartungsfenster

Statt Binaries von Hand zu aktualisieren, wählst du eine Zielversion; Minor-Patches laufen meist automatisch, während Major-Upgrades geplant werden und in der Regel Ausfallzeit bzw. ein HA-Failover mit sich bringen. AWS RDS/Aurora: Wahl der Engine-Version + Option für automatisches Minor-Upgrade + risikoarme Major-Upgrades mit Blue/Green Deployments. GCP Cloud SQL: Wartungsfenster + Major-Upgrade per Self-Service. MongoDB Atlas: Versions-Upgrade per Klick, rollierend mit nahezu null Ausfallzeit. Azure SQL: wird von der Plattform automatisch gepatcht (der Versionsbegriff ist weitgehend abstrahiert); das Verhalten wird über den Kompatibilitätsgrad gesteuert. Teste es immer zuerst auf einer Test-/Staging-Kopie und lege das Wartungsfenster außerhalb der Geschäftszeiten.

7. Konnektivität und Sicherheit: Endpoint + IAM/TLS

Verbindungen laufen immer über den vom Anbieter bereitgestellten DNS-Endpoint und sind verschlüsselt (TLS); Netzwerkzugriff und Identität lassen sich an das Identitätssystem der Cloud koppeln. AWS RDS/Aurora: Instanz-/Cluster-Endpoint + Security Group für das Netzwerk + optionale IAM-Datenbankauthentifizierung + TLS (rds-ca-Zertifikat). GCP Cloud SQL: öffentliche IP + Authorized Networks oder private IP/VPC, Cloud SQL Auth Proxy, IAM-Datenbankauthentifizierung, TLS. MongoDB Atlas: SRV-Connection-String (mongodb+srv://), IP-Zugriffsliste + Private Endpoint/Peering, SCRAM oder IAM/X.509, TLS verpflichtend. Azure SQL: Server-FQDN-Endpoint + Firewall/Private Link + Authentifizierung über Microsoft Entra ID (früher Azure AD) + TLS verpflichtend. Regel: Verwende im Connection String den Endpoint statt einer festen IP, erzwinge TLS und verbinde dich nach Möglichkeit mit einer Cloud-IAM-Identität.