AWS RDS Proxy

• fully managed, highly available database proxy for RDS that makes applications more secure, scalable, more resilient to database failures.
• allows apps to pool and share DB connections established with the database
• improves database efficiency by reducing stress on the database resources (e.g. CPU, RAM) by minimizing open connections and creation of new connections.
• is serverless and scales automatically to accommodate your workload.
• is highly available and deployed across multiple Availability Zones.
• increases resiliency to database failures by automatically connecting to a standby DB instance while preserving application connections.
• reduces RDS and Aurora failover time by up to 66%.
• protects the database against oversubscription by providing control over the number of database connections that are created.
• queues or throttles application connections that can’t be served immediately from the pool of connections.
• supports RDS (MySQL, PostgreSQL, MariaDB, SQL Server) and Aurora (MySQL, PostgreSQL)
• does NOT support RDS for Oracle or RDS for Db2.
• is fully managed and there is no need to provision or manage any additional infrastructure.
• required no code changes for most apps, just need to point to the RDS proxy endpoint instead of the RDS endpoint
• enforce IAM Authentication for DB, and securely store credentials in AWS Secrets Manager
• is never publicly accessible (must be accessed from VPC)
• is priced per vCPU per hour of the underlying database instances (for provisioned) or per ACU per hour (for Aurora Serverless v2).

RDS Proxy Connection Pooling & Multiplexing

• RDS Proxy maintains a pool of established connections to the database and reuses connections in this pool.
• uses transaction-level multiplexing — by default, it can reuse a connection after each transaction in a session (called “borrowing” the connection).
• translates a large number of client connections into a much smaller number of back-end database connections.
• reduces the memory and CPU overhead for connection management on the database.
• Connection pinning occurs when session state changes (e.g., SET statements, prepared statements, temporary tables) that cannot be shared. Pinned connections cannot be reused until the session ends.
• to avoid pinning, move session configuration to the proxy’s initialization query or use session-state-compatible patterns.

RDS Proxy Endpoints

• RDS Proxy supports creating additional endpoints beyond the default read/write endpoint.
• Read-only endpoints route queries to Aurora Replicas or RDS read replicas, providing read scalability.
• Cross-VPC endpoints allow accessing the proxy from a different VPC than the one the proxy resides in.
• each endpoint has its own set of CloudWatch metrics for monitoring.
• endpoints support IPv4, IPv6, or dual-stack network types.

RDS Proxy High Availability & Failover

• reduces failover times for Aurora and RDS Multi-AZ databases by up to 66% by bypassing DNS cache propagation delays.
• automatically connects to the new primary instance during failover while preserving application connections.
• supports RDS Multi-AZ with two readable standbys for typically under 35-second failovers, 2x improved write latency, added read capacity, and reduced minor version upgrade downtime to typically under 1 second.
• supports Blue/Green Deployments (since April 2026) — RDS Proxy actively monitors database instances during a Blue/Green Deployment switchover and automatically redirects connections to the Green environment, eliminating DNS propagation delays. Supported for RDS for PostgreSQL, RDS for MySQL, and RDS for MariaDB.

RDS Proxy IPv6 Support

• RDS Proxy supports IPv6 (since September 2025), allowing applications to pool and share database connections using IPv6 addresses.
• existing IPv4 endpoints remain available for backwards compatibility.
• database must be configured for dual-stack mode to support IPv6 connections from the proxy.
• endpoint network type can be set to IPV4, IPV6, or DUAL.

RDS Proxy Security

• enforces IAM authentication for database access, eliminating hard-coded credentials in application code.
• integrates with AWS Secrets Manager for centralized database credential management.
• supports IAM authentication for both client-to-proxy and proxy-to-database connections (removing the need to store passwords in Secrets Manager).
• is never publicly accessible — all connections must originate from within the VPC.
• supports TLS/SSL connections between the application and the proxy.

RDS Proxy Use Cases

• Serverless applications (Lambda) — Lambda functions create many short-lived connections; RDS Proxy pools them efficiently, preventing “too many connections” errors.
• Unpredictable workloads — connection governance gracefully scales applications dealing with burst connection patterns.
• Applications with idle connections — SaaS/eCommerce apps keep connections open for responsiveness; RDS Proxy holds idle connections without overprovisioning the database.
• Applications requiring high availability — transparently tolerates database failures and routes traffic to new instances.
• Multi-tenant SaaS — connection pooling supports multiple tenants efficiently with separate proxy endpoints per tenant or workload.

RDS Proxy Availability

• available in most AWS Regions including AWS GovCloud (US-East and US-West) regions (since April 2025).
• expanded to Asia Pacific (Malaysia), Asia Pacific (Thailand), and Mexico (Central) regions (April 2025).

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company migrated one of its business-critical database workloads to an Amazon Aurora Multi-AZ DB cluster. The company requires a very low RTO and needs to improve the application recovery time after database failover. Which approach meets these requirements?
   1. Set the max_connections parameter to 16,000 in the instance-level parameter group.
   2. Modify the client connection timeout to 300 seconds.
   3. Create an Amazon RDS Proxy database proxy and update client connections to point to the proxy endpoint.
   4. Enable the query cache at the instance level.
2. A company is running a serverless application on AWS Lambda that stores data in an Amazon RDS for MySQL DB instance. Usage has steadily increased, and recently there have been numerous “too many connections” errors when the Lambda function attempts to connect to the database. The company already has configured the database to use the maximum max_connections value that is possible. What should a SysOps administrator do to resolve these errors?
   1. Create a read replica of the database. Use Amazon Route 53 to create a weighted DNS record that contains both databases.
   2. Use Amazon RDS Proxy to create a proxy. Update the connection string in the Lambda function.
   3. Increase the value in the max_connect_errors parameter in the parameter group that the database uses.
   4. Update the Lambda function’s reserved concurrency to a higher value.
3. A company needs to perform a major version upgrade on an Amazon Aurora MySQL cluster with minimal downtime. The cluster uses Amazon RDS Proxy for connection management. Which approach minimizes application disruption during the upgrade?
   1. Perform a direct in-place major version upgrade during the maintenance window.
   2. Create a new Aurora cluster, manually migrate data, and switch DNS records.
   3. Use Amazon RDS Blue/Green Deployments with RDS Proxy to perform the upgrade and switchover with minimal downtime.
   4. Take a snapshot, restore to a new cluster with the target version, and update the proxy target.
4. A development team is building a multi-tenant SaaS application using AWS Lambda and Amazon Aurora PostgreSQL. Different tenants have different query patterns — some tenants perform heavy reads while others perform heavy writes. How should the team configure RDS Proxy to optimize performance?
   1. Create a single proxy with a large connection pool and use Lambda reserved concurrency to limit connections.
   2. Create separate Aurora clusters for each tenant with their own RDS Proxy.
   3. Create a single proxy with both a read/write default endpoint and additional read-only endpoints to route read traffic to Aurora Replicas.
   4. Disable connection multiplexing in RDS Proxy to ensure session affinity for each tenant.
5. A company has an application using Amazon RDS Proxy with an Aurora PostgreSQL cluster. After deploying a new application version, they notice increased latency and CloudWatch shows high DatabaseConnectionsCurrentlySessionPinned metrics. What is the most likely cause and solution?
   1. The database is undersized; scale up the instance.
   2. The proxy has too few connections in the pool; increase MaxConnectionsPercent.
   3. The new application code uses session-level settings (SET statements or prepared statements) that cause connection pinning, reducing multiplexing efficiency. Move session configuration to the proxy’s initialization query.
   4. The proxy endpoint is misconfigured; recreate the proxy.

References

• Amazon RDS Proxy
• RDS Proxy User Guide
• Using RDS Proxy with Blue/Green Deployments