Zhivko Todorov
ALL CASE STUDIES

CASE 62 · FORTE · 2024

RDS PROXYAURORAREAD-REPLICACONNECTION POOLING

Read replicas the application actually uses.

A B2B analytics platform had four Aurora read replicas that the application sent zero traffic to. Every query went to the writer. The writer had been scaled up four times in two years. We introduced RDS Proxy with read-only endpoints and the application started using the replicas the next day.

INDUSTRY

B2B analytics

DOMAIN

RELIABILITY

DELIVERED

2024

STACK

RDS PROXY·AURORA POSTGRES·PGCAT (TRANSITIONAL)·CLOUDWATCH METRICS·PERFORMANCE INSIGHTS

RESULTS

What changed, by the numbers.

WRITER LOAD

−63%

CPU + IOPS

REPLICA USAGE

0% → 41%

OF QUERY VOLUME

WRITER INSTANCE CLASS

SCALED DOWN

r6g.8xl → r6g.4xl

MONTHLY DB COST

−32%

NET

HOW IT WENT

The application had been written when read replicas were "a problem for later." Later arrived. The team had read replicas provisioned but no clean way to route reads to them — the ORM didn’t differentiate, and surgically marking each query type was a months-long refactor nobody wanted to start.

RDS Proxy with a separate read-only endpoint solved the routing problem at the proxy layer. We added a thin SDK wrapper that the team adopted gradually — read-heavy endpoints first (reporting, dashboards), then the medium-traffic ones. The transactional writes stayed on the writer.

Within four weeks 41% of query volume was hitting replicas. The writer’s CPU dropped to a healthy 38% baseline. We scaled the writer down a class, which dropped the DB bill 32% net. The remaining read-heavy refactors continued in the background.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →