Storage and Compute

With the RDS architecture, endpoints, parameter groups, and engine selection covered in the previous lesson, the focus now shifts to the infrastructure layer that sits beneath those abstractions. Every RDS database runs on two independent but interrelated foundations: the DB instance class, which determines compute capacity, and the storage configuration, which governs data persistence and I/O behavior. Misaligning either dimension with the workload creates bottlenecks that cannot be resolved by adjusting the other. A memory-starved instance will thrash regardless of how many IOPS the storage can deliver, and a compute-rich instance will idle while waiting on under-provisioned storage.

This lesson explains how to choose instance classes and generations; how gp3 and io2 compare in cost, baseline performance, provisioned IOPS, throughput, and workload fit; how storage autoscaling reduces the risk of running out of allocated storage; and why IOPS and throughput should be sized based on workload metrics rather than estimates. It also reflects AWS documentation that marks magnetic storage as legacy and not recommended: Amazon RDS is deprecating magnetic storage on April 30, 2026, and recommends upgrading magnetic volumes to gp3 or io2 before April 29, 2026.

The decisions made here directly shape what the next lesson covers, where multi-AZ deployments and read replicas build resilience and read scaling atop these compute and storage foundations.

DB instance classes and generations

A DB instance classThe combination of virtual CPU count, memory size, network bandwidth, and EBS throughput ceiling that defines the compute capacity of an RDS database instance. is the single configuration choice that determines how much processing power, memory, and network capacity an RDS database has available. When a request reaches the database engine, the instance class dictates whether the engine has enough CPU cycles to parse and execute the query, enough memory to cache working data, and enough network bandwidth to return results to the application.

RDS organizes instance classes into three broad families, each designed for a different workload profile.

• General purpose (db.m-series): These instances provide a balanced ratio of CPU to memory and serve as the default starting point for most OLTP and mixed workloads. A db.m7g instance, for example, pairs Graviton3 processors with proportional memory, making it suitable for mid-tier production databases that do not skew heavily toward compute or memory.

• Memory-optimized (db.r-series): These instances offer a higher memory-to-CPU ratio, which benefits workloads with large working sets, complex joins that spill to memory, or engines that rely on ...