Switching from RDS Proxy to Open-Source Maxscale

Aurora MySQL's Cluster Endpoint provides RW/RO endpoints, but the 5-second DNS TTL caused RO node distribution to break down when traffic surged momentarily. To solve this, we went through Hikari connection pool → Aurora Protocol → RDS Proxy, but RDS Proxy lacks a custom endpoint, making it difficult to utilize during scale-in, and endpoint change work also consumed operational resources.

The review had three main objectives.

• Resolving the load balancing breakdown phenomenon
• Preventing resource waste by minimizing endpoint change work
• Securing lower cost compared to RDS Proxy

In the existing environment, DB CPU usage was normally below 30%, but when traffic surged, AutoScaling and scale-in repeated in a cycle. During this process, traffic concentrated on only some RO nodes, causing a CPU difference of over 70% between nodes, and even with RDS Proxy, the constraints at the point of scale-in were not resolved. Combined with VCPU-based costs, this ultimately led to considering a switch to Maxscale.

Maxscale is a database proxy that provides Query Routing & Splitting, High Availability, Scalability, and Security. Testing proceeded in the order of separate test equipment → small module → full application, and was later expanded into a structure applicable not only to RDS but also to self-installed MySQL.

The review and testing confirmed the following.

• License: GPL conversion up to 2.2.21, Aurora support from 2.1
• TPS: Similar to the RDS Proxy guide, with about a 5% difference—no significant gap
• Load balancing performance: CPU and connection distribution improved stably
• Scale-in response: Balancing was maintained with Maxscale, but Cluster Endpoint is not supported
• Failover: Addressed by separately implementing automation features
• Port constraints: Unlike RDS Proxy's restriction to port 3306, other ports can also be used
• Availability specs: Initially reduced from m5.2xlarge → m5.xlarge → c5.xlarge, and finally applied c5n.xlarge after also considering network traffic

For Aurora support, monitoring was done using the auroramon module and aurora_server_id, information_schema.replica_host_status, supplemented by separately configuring an architecture that catches Autoscaling triggers and automation scripts. As a result, Maxscale absorbed the traffic coming into the DB, making CPU and connections more consistent, and annual cost savings from removing RDS Proxy were also achieved.

This approach was also applied to traffic skew and session delay issues in existing self-installed MySQL. By mitigating Active Session and CPU concentration on one side through traffic distribution, the potential for expansion in reducing bottlenecks in operating DBs was confirmed.

Finally, this transition became an opportunity to re-examine not just a simple proxy replacement, but also WAS configuration values, spec sizing, and POC considerations. For environments experiencing Aurora's load balancing breakdown, Maxscale is concluded to be a worthwhile open-source alternative to consider.