I'm researching different Disaster Recovery & Availability option for AWS hosted databases, As part of this research - I've also been researching various methods on how an application will manage traffic - a key component of dealing with failover in the event of unavailability of the Primary Instance

I watched a useful introductory level video about Rds Proxy - which could assist in the solving the traffic redirect for RDS and Aurora databases

These are notes from the video , & if you want to watch the full video  "Deep dive into Amazon RDS Proxy for scaling applications" there's a link at the botom of this post

Main application demands

Scalability - dealing with large amounts of connections

Availability - identify transient issues

Security  - managing DB access controls 

Some  typical patterns applied by application owners could include : scaling increased resources but this could lead to overprovisioning , increased  cost  . An alternative is a self managed database Proxy , which can also lead to increased complexity. 

These patterns can lead to unnecessary increased costs and complexity.  An alternative method is to use AWS RDS Proxy - a fully managed db proxy focused on RDS & Aurora 

Main areas of focus are:

--Fully managed, compatible with MySQL & PostgresSQL

--Connection pooling with multiplexing. Traditionally multiplexing is a method used by networks to consolidate multiple signals into a single signal that is transported over a common medium. Applying this concept to the database traffic and connection pooling - via a funneling system . 

--Failover management - app connections preserved and transactions queued during failovers

detects failovers & connects to standby - when the standby becomes available

--Security - passwords stored in Secrets Manager & IAM authentication

RDS Proxy sits between app & database - dealing with connection pooling , security , failover. 

Best practises

--apps don't continiously use open connections

--transaction level db connection sharing improves scalability 

--minimises resource overhead 

--pinning on : various - such as set of variables, locking functions, table locks, temp tables 

--not pinning on : charset changes, TZ, collation, auto- commit 

RDS Proxy should be reviewed as part of an overall architecture for Disaster Recovery and Availability. This analysis should begin at the early stages alongside other considerations such as Amazon RDS for PostgreSQL versus Amazon Aurora PostgreSQL - which should I choose ? and then  developing a backup strategy 

Watch the full video ==> https://www.youtube.com/watch?v=VFsGJIeuR_Y