Optimized Reads | RDS/Aurora cost optimization

Optimized Reads moves temporary objects off EBS and onto local NVMe instance storage, reducing I/O bottlenecks and query latency.

By finishing work faster and more efficiently, you can often serve the same workload with fewer replicas or smaller instance classes, reducing overall RDS compute and storage costs.

Best for: MySQL/MariaDB workloads with many disk-based temporary tables and file sorts
You get: Lower query latency, higher throughput, and reduced EBS I/O pressure
You may save: Fewer read replicas, smaller instances, and less over-provisioning “just for performance headroom”

Why it matters

Complex queries in MySQL and MariaDB often create internal temporary tables and files to process operations like DISTINCT with ORDER BY, common table expressions (CTEs), grouping, and sorting.¹
Without Optimized Reads, all temporary objects are stored on Amazon EBS, which can create I/O bottlenecks for query-heavy workloads and force you to scale up or add replicas purely for performance.
With Optimized Reads, temporary objects are stored on local NVMe-based SSD instance store volumes, providing lower latency and higher I/O performance.²
When temporary I/O is no longer the bottleneck, you may be able to:
- Consolidate workloads onto fewer instances or replicas.
- Right-size instance families down instead of scaling up for performance headroom.
- Avoid overpaying for provisioned IOPS or larger EBS volumes that are mainly compensating for temp-table I/O.

Optimized Reads is available on RDS for MySQL 8.0.28+ and RDS for MariaDB 10.4.25+, 10.5.16+, 10.6.10+. Supported instance families include, but are not limited to, db.r5d, db.r6gd, db.m5d, db.m6gd, x2iedn, and x2idn.²

Note: Evaluate whether your workload benefits from Optimized Reads before purchasing Reserved Instances or Savings Plans for RDS. Switching to a different instance family later (for example, from db.m6g to db.m6gd) would require new reservations and can erode your savings.

How to enable

Launch or migrate to a supported instance class – Choose an instance from the db.r5d, db.r6gd, db.m5d, db.m6gd, x2iedn, or x2idn families running a supported engine version.
Optimized Reads is automatic – Once you’re on a supported instance class, temporary objects are automatically stored on instance store volumes with no configuration changes or application code changes required.
Test with a read replica first – Create a read replica using an Optimized Reads-compatible instance class to evaluate performance improvements and cost impact (e.g., potential to remove replicas or downsize instances) before migrating your primary instance.

Workloads that benefit most

Queries that create many internal temporary tables or sort files (check Created_tmp_disk_tables and Created_tmp_files status variables).¹ If these counters trend upward alongside high EBS ReadIOPS/WriteIOPS, your workload is a strong candidate.
Applications using user-created temporary tables to store intermediate results.
Complex queries with CTEs, derived tables, or subqueries that generate large temporary data sets.
Reporting and analytics workloads that process large result sets with grouping and sorting operations.
Environments where performance constraints are forcing you to use larger instance sizes or extra read replicas for MySQL or MariaDB.

When Optimized Reads may not be a fit

Your workload rarely creates disk-based temporary objects (most temporary work fits in memory), so EBS is not a bottleneck.
You’re running an older engine version that doesn’t support the feature and upgrading is not currently feasible.
Your team isn’t prepared to monitor and respond to local storage utilization (for example, alarms on FreeLocalStorage), and the operational risk outweighs the potential performance and cost benefits.

Monitoring and best practices

Monitor local storage usage – Set CloudWatch alarms on FreeLocalStorage to get notified before the instance store fills up. Additional CloudWatch metrics include ReadIOPSLocalStorage, WriteIOPSLocalStorage, ReadLatencyLocalStorage, WriteLatencyLocalStorage, ReadThroughputLocalStorage, and WriteThroughputLocalStorage.¹
Choose the right instance size – Instance store volume size depends on the instance class, so ensure you have sufficient local storage for your temporary workload. Under-sizing can lead to local storage exhaustion and instability.
Batch large imports – Operations like LOAD DATA LOCAL create cache files on instance store; run them in batches to avoid filling the volume and impacting other queries.
Split large transactions – If binary logging is enabled, large transactions can create temporary binlog cache files on instance store; consider breaking them into smaller transactions.
Watch MariaDB temporary tablespace growth – User-created temporary InnoDB tables use a common temporary (ibtmp1) tablespace that increases but won’t decrease in size when tables are dropped. The engine only deletes this tablespace on graceful shutdown. Pay close attention to FreeLocalStorage if you frequently create and drop many InnoDB temp tables.
Benchmark before migrating – Test your workload on Optimized Reads-enabled instances to measure actual performance gains. For write-heavy workloads, also evaluate the optimized writes feature. Use these measurements to validate that you can safely reduce instance size, replica count, or IOPS without impacting SLAs.

Rollout checklist

Identify candidates by monitoring Created_tmp_disk_tables and Created_tmp_files metrics or enabling slow query logs to find queries using temporary tables and file sorts.
Create a read replica using an Optimized Reads-compatible instance class (for example, upgrade from db.m6g to db.m6gd).
Run representative workload tests and compare query latency, throughput, and WriteIOPS/ReadIOPS metrics between the original and replica instances.
If results show meaningful improvement, look for opportunities to:
- Remove or downsize read replicas.
- Move to smaller or less expensive instance classes without violating performance SLOs.
Migrate the primary instance during a maintenance window once you’re confident in the performance and capacity plan.
Set up CloudWatch alarms for FreeLocalStorage to avoid running out of instance store space.
Document which queries and workloads benefit most, and revalidate after major schema or workload changes.