RDS, Backups, and Storage

AWS Basics · Databases on AWS – RDS, Aurora, and ElastiCache · Lesson 1 of 5

Managed relational databases

Amazon RDS manages provisioning, OS and database patching, monitoring, backups, and failover for supported engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2, and Aurora. You manage schemas, queries, database users, and capacity choices; you cannot SSH to the underlying host.

flowchart LR
  DB["RDS instance<br/>db-prod"] --> AB["Automated backups<br/>daily snapshot + logs"]
  AB --> PITR["Point-in-time restore<br/>any second in the window"]
  DB --> MS["Manual snapshot<br/>kept until deleted"]
  PITR --> NEW["New DB instance<br/>new endpoint"]
  MS --> NEW
  %% step DB: The database runs on a managed instance; AWS handles the OS and engine patching.
  %% step AB: Each day RDS takes a storage snapshot and continuously saves transaction logs to S3.
  %% step PITR: Together they let you restore to any second within the retention window, up to about the last five minutes.
  %% step MS: Manual snapshots stay until you delete them, even after the database is gone.
  %% step NEW: Every restore creates a new instance; point the application at its new endpoint.

Who does what

AWS manages	You manage
Hardware, OS, engine installation and patches (in your maintenance window)	Choosing engine version and instance class
Automated backups and point-in-time restore	Backup retention and snapshot policy
Multi-AZ failover, storage replication	Schema, indexes, query tuning
Monitoring metrics in CloudWatch	Database users, privileges, parameter values

Backups

Automated backup retention (1–35 days; 0 disables backups) supports Point-in-Time Restore (PITR) within its window. PITR always creates a new DB instance; it does not overwrite the source. Automated backups are deleted with the instance unless you choose to retain them, so take a final snapshot when deleting.

A manual snapshot remains until deletion and fits longer retention, copies to another Region, or sharing with another account. AWS Backup can manage RDS snapshots alongside other services with central policies.

Storage and instances

RDS storage uses EBS: General Purpose SSD (gp3), Provisioned IOPS (io1/io2) for demanding workloads, or magnetic (legacy). Storage autoscaling increases allocated storage near exhaustion up to the configured maximum threshold; it does not shrink storage. Monitor FreeStorageSpace and leave enough maximum headroom.

Changing instance class (scale up) causes a short outage, or a failover if the instance is Multi-AZ. Parameter groups hold engine settings such as max_connections; some changes need a reboot (pending-reboot).

Windows

A maintenance window schedules AWS changes such as OS patches and minor version upgrades, while a backup window schedules the daily snapshot. Neither means “never interrupted” — design for availability with Multi-AZ, and make sure the application reconnects automatically.

Monitoring

Watch CPUUtilization, FreeableMemory, DatabaseConnections, ReadLatency/WriteLatency and FreeStorageSpace. Enhanced Monitoring adds OS-level metrics every few seconds, and Performance Insights shows which queries cause load.

Command	Purpose
`aws rds describe-db-instances --db-instance-identifier db-prod`	View storage and backups
`aws rds create-db-snapshot --db-instance-identifier db-prod --db-snapshot-identifier db-prod-before-upgrade`	Create a manual snapshot
`aws rds restore-db-instance-to-point-in-time --source-db-instance-identifier db-prod --target-db-instance-identifier db-restored --restore-time 2026-11-05T03:00:00Z`	Restore to a point in time
`aws rds modify-db-instance --db-instance-identifier db-prod --backup-retention-period 14`	Change retention

Traps: expecting PITR to overwrite the original database; deleting an instance without a final snapshot; thinking storage autoscaling also shrinks.