Cloud-managed databases (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)
Symptom
Goal: learn the key differences between cloud-managed databases and self-managed installations; understand how backup, parameters, failover, monitoring, upgrades and connectivity work in the cloud.
1. Mindset shift: you access a service, not a server
With managed databases you have NO shell access to the OS, the file system or the database process; you cannot SSH in, edit config files by hand or become superuser. You only get the provider's management API/console and a normal SQL connection. AWS RDS/Aurora: management is at the resource (instance/cluster) level, the server is hidden. GCP Cloud SQL: instance API only, no OS. MongoDB Atlas: fully managed cluster, no access to mongod. Azure SQL Database: PaaS, neither server nor OS is visible underneath (Managed Instance gives somewhat more control). So most self-managed reflexes such as 'look at the file', 'kill the process' or 'run an OS tool' do not apply.
2. Backup: automated snapshots + point-in-time recovery (PITR)
You do not schedule backups; the provider takes them automatically. Recovery is usually 'restore to a specific point in time' (PITR) or creating a new instance from a snapshot; the existing instance is not overwritten. AWS RDS/Aurora: automated backups + retention window; a PITR restore with per-second precision opens as a new instance/cluster; manual snapshots are also possible. GCP Cloud SQL: automated backups + PITR via binary logs; restore goes to a new instance. MongoDB Atlas: continuous cloud backup + PITR (M10+); restore from snapshots. Azure SQL: built-in automated backups, 1-35 day retention, PITR to any point and restore of deleted DBs. Common rule: verify the backup configuration (window, retention period) and run regular restore tests.
3. Parameters: parameter groups / flags, not a config file
Instead of editing postgresql.conf or my.cnf by hand, you use the provider's parameter abstraction; some parameters are locked and some require a restart (static). AWS RDS/Aurora: set via a DB parameter group (and a cluster parameter group); dynamic parameters apply immediately, static ones on reboot. GCP Cloud SQL: 'database flags' are set from the console/gcloud. MongoDB Atlas: limited 'Additional Settings' + oplog size etc.; most internal parameters are managed. Azure SQL: most server-level settings are managed; behavior changes through SCOPED CONFIGURATION and the service tier choice. Before applying, check whether the parameter is dynamic or static.
4. High availability / failover: managed Multi-AZ and replicas
You do not build failover yourself; you tick a box and leave it to the provider. The standby and automatic failover are managed, and connections are redirected to the new primary through a stable endpoint. AWS RDS: Multi-AZ (synchronous standby, automatic failover); Aurora: multi-copy storage + automatic failover, the cluster endpoint points to the writer. GCP Cloud SQL: HA configuration (regional, standby in a secondary zone) with one click; read replicas are added separately. MongoDB Atlas: replica set built in, multi-region/multi-cloud deployment available, failover automatic. Azure SQL: built-in HA (local replicas in Business Critical), a zone-redundant option and cross-region active geo-replication / failover groups. The application must always connect to the endpoint, never to a fixed IP.
5. Monitoring: the provider's metrics and log service
Because you cannot run OS tools (top, iostat), you monitor through the provider's metrics platform; CPU, connection count, IOPS, replication lag and storage metrics live there. AWS: CloudWatch metrics + Enhanced Monitoring + Performance Insights (query-level analysis). GCP Cloud SQL: Cloud Monitoring (formerly Stackdriver) + Query Insights. MongoDB Atlas: built-in Atlas metrics/charts + Performance Advisor + real-time panel. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. Always set up threshold alarms (storage usage, CPU, connection limit, replica lag).
6. Version upgrades and maintenance: from the console, in a maintenance window
Instead of updating binaries by hand you pick a target version; minor version patches are mostly automatic, while major version upgrades are planned and usually involve downtime/an HA failover. AWS RDS/Aurora: engine version selection + automatic minor upgrade option + low-risk major upgrades with Blue/Green Deployments. GCP Cloud SQL: maintenance window + self-service major version upgrade. MongoDB Atlas: one-click version upgrade, near-zero downtime in a rolling fashion. Azure SQL: patched automatically by the platform (the notion of a version is largely abstracted away); behavior is controlled with the compatibility level. Always try it on a test/staging copy first and schedule the maintenance window outside business hours.
7. Connectivity and security: endpoint + IAM/TLS
Connections always go through the DNS endpoint supplied by the provider and are encrypted (TLS); network access and identity can be tied to the cloud identity system. AWS RDS/Aurora: instance/cluster endpoint + Security Group for the network + optional IAM database authentication + TLS (rds-ca certificate). GCP Cloud SQL: public IP + Authorized Networks or private IP/VPC, Cloud SQL Auth Proxy, IAM database authentication, TLS. MongoDB Atlas: SRV connection string (mongodb+srv://), IP access list + private endpoint/peering, SCRAM or IAM/X.509, TLS mandatory. Azure SQL: server FQDN endpoint + firewall/Private Link + Microsoft Entra ID (formerly Azure AD) authentication + TLS mandatory. Rule: use the endpoint, not a fixed IP, in the connection string, enforce TLS and connect with a cloud IAM identity where possible.