Caching and Read Replicas can reduce the capacity required for your database instance in read-intensive transactions/applications. For example, for read-intensive workloads in particular, using caching instead of PIOPs on a DB server can cut down your expenses, substantially (sometimes up to 80-90%). For caching the data, you can leverage the spare local RAM caches available in your application server instances or use Amazon ElastiCache (there is a cost involved but that may be lower than additional capacity allocation for your database instance for your application type).

The most common and the simplest optimization for databases is to cache as much data as you can because caching saves money. For example, if you are using DynamoDB, then as DynamoDB is charged by provisioned throughput, you can scale that down significantly using ElastiCache (which not only makes for faster responses but is also cheaper because it is charged per hour). In addition, use negative caching, if you are executing the same queries repeatedly that do not return results every time the query is executed. If there is no result returned for a specific query from the database, then save that information in the cache too. This way, you can achieve 80-95% cache hit ratio for queries that return no result most of the time.

You can also use Amazon SQS to buffer writes that exceed your provisioned capacity for the database instance. This approach allows you to provision for average capacity rather than the peak.

You can use dynamic DynamoDB, an open source tool (Python script) that automatically resizes read and write capacity by consuming CloudWatch metrics to decide the best capacity to be booked. It achieves a kind of auto scaling for DynamoDB. In addition, you will typically have hot spot tables in your databases—look to put these in NoSQL or cache storage. Replace hot spots in RDS with DynamoDB because in large TB-scale databases with Multi-AZ configurations, this can yield even more savings – 30 to 40%.

Try offloading your traffic for popular content to Amazon S3 and/or Amazon CloudFront (they are like proxy caches) to scale down your backend DB infrastructure.