Reflecting on lessons learned using a DB proxy managed by AWS
Complementing Amazon Web Services (AWS) Relational Database Service (RDS), Proxy became generally available in June 2020 in RDS for MySQL and PostgreSQL as well as their Aurora-compatible counterparts. Proxy facilitates pooling and sharing of database connections, which is valuable for serverless applications that need to query RDS databases at scale with managed failover. Since June 2020, Proxy has extended support to RDS for MariaDB and SQL Server.
RDS Proxy is already served by excellent documentation — Amazon’s own product documentation is one useful reading reference. This blog post builds on existing material by focusing on lessons learned setting up and monitoring a Proxy. These observations come from experience using Proxy with Aurora MySQL, but they apply irrespective of the DB engine target.
There are a few Proxy terms to explain before we dive into lessons learned. Firstly, database (DB) instances are called targets, and targets are associated with a Proxy target group. Each target group consists of an individual RDS DB instance or an RDS DB cluster, where a cluster has many DB instances. Proxy uses one or more endpoints to forward queries to target groups.