Using Amazon RDS Proxy for Aurora - Amazon Aurora
Region and version availabilityQuotas and limitations
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Using Amazon RDS Proxy for Aurora

By using Amazon RDS Proxy, you can allow your applications to pool and share database connections to improve their ability to scale. RDS Proxy makes applications more resilient to database failures by automatically connecting to a standby DB instance while preserving application connections. By using RDS Proxy, you can also enforce Amazon Identity and Access Management (IAM) authentication for databases, and securely store credentials in Amazon Secrets Manager.

Using RDS Proxy, you can handle unpredictable surges in database traffic. Otherwise, these surges might cause issues due to oversubscribing connections or new connections being created at a fast rate. RDS Proxy establishes a database connection pool and reuses connections in this pool. This approach avoids the memory and CPU overhead of opening a new database connection each time. To protect a database against oversubscription, you can control the number of database connections that are created.

RDS Proxy queues or throttles application connections that can't be served immediately from the connection pool. Although latencies might increase, your application can continue to scale without abruptly failing or overwhelming the database. If connection requests exceed the limits you specify, RDS Proxy rejects application connections (that is, it sheds load). At the same time, it maintains predictable performance for the load that RDS can serve with the available capacity.

You can reduce the overhead to process credentials and establish a secure connection for each new connection. RDS Proxy can handle some of that work on behalf of the database.

RDS Proxy is fully compatible with the engine versions that it supports. You can enable RDS Proxy for most applications with no code changes. For a list of supported engine versions, see Amazon RDS Proxy.

Topics

Region and version availability

For information about database engine version support and availability of RDS Proxy in a given Amazon Web Services Region, see Amazon RDS Proxy.

Quotas and limitations for RDS Proxy

The following quotas and limitations apply to RDS Proxy:

  • You can have up to 20 proxies for each Amazon account ID. If your application requires more proxies, you can request additional proxies by opening a ticket with the Amazon Support organization.

  • Each proxy can have up to 200 associated Secrets Manager secrets. Thus, each proxy can connect to with up to 200 different user accounts at any given time.

  • Each proxy has a default endpoint. You can also add up to 20 proxy endpoints for each proxy. You can create, view, modify, and delete these endpoints.

  • In an Aurora cluster, all of the connections using the default proxy endpoint are handled by the Aurora writer instance. To perform load balancing for read-intensive workloads, you can create a read-only endpoint for a proxy. That endpoint passes connections to the reader endpoint of the cluster. That way, your proxy connections can take advantage of Aurora read scalability. For more information, see Overview of proxy endpoints.

  • You can use RDS Proxy with Aurora Serverless v2 clusters, but not with Aurora Serverless v1 clusters.

  • Your RDS Proxy must be in the same virtual private cloud (VPC) as the database. The proxy can't be publicly accessible, although the database can be. For example, if you're prototyping your database on a local host, you can't connect to your proxy unless you set up the necessary network requirements to allow connection to the proxy. This is because your local host is outside of the proxy’s VPC.

    Note

    For Aurora DB clusters, you can turn on cross-VPC access. To do this, create an additional endpoint for a proxy and specify a different VPC, subnets, and security groups with that endpoint. For more information, see Accessing Aurora databases across VPCs.

  • You can't use RDS Proxy with a VPC that has its tenancy set to dedicated.

  • If you use RDS Proxy with an Aurora DB cluster that has IAM authentication enabled, check user authentication. Users who connect through a proxy must authenticate through sign-in credentials. For details about Secrets Manager and IAM support in RDS Proxy, see Setting up database credentials in Amazon Secrets Manager and Setting up Amazon Identity and Access Management (IAM) policies.

  • You can't use RDS Proxy with custom DNS when using SSL hostname validation.

  • Each proxy can be associated with a single target DB cluster. However, you can associate multiple proxies with the same DB cluster.

  • Any statement with a text size greater than 16 KB causes the proxy to pin the session to the current connection.

  • Certain Regions have Availability-Zone (AZ) restrictions to consider while creating your proxy. US East (N. Virginia) Region does not support RDS Proxy in the use1-az3 Availability Zone. US West (N. California) Region does not support RDS Proxy in the usw1-az2 Availability Zone. When selecting subnets while creating your proxy, make sure that you don't select subnets in the Availability Zones mentioned above.

  • Currently, RDS Proxy does't support any global condition context keys.

    For more information about global condition context keys, see Amazon global condition context keys in the IAM User Guide.

For additional limitations for each DB engine, see the following sections:

Additional limitations for Aurora MySQL

The following additional limitations apply to RDS Proxy with Aurora MySQL databases:

  • RDS Proxy doesn't support the MySQL sha256_password and caching_sha2_password authentication plugins. These plugins implement SHA-256 hashing for user account passwords.

  • Currently, all proxies listen on port 3306 for MySQL. The proxies still connect to your database using the port that you specified in the database settings.

  • You can't use RDS Proxy with self-managed MySQL databases in EC2 instances.

  • You can't use RDS Proxy with an RDS for MySQL DB instance that has the read_only parameter in its DB parameter group set to 1.

  • RDS Proxy doesn't support MySQL compressed mode. For example, it doesn't support the compression used by the --compress or -C options of the mysql command.

  • Database connections processing a GET DIAGNOSTIC command might return inaccurate information when RDS Proxy reuses the same database connection to run another query. This can happen when RDS Proxy multiplexes database connections.

  • Some SQL statements and functions such as SET LOCAL can change the connection state without causing pinning. For the most current pinning behavior, see Avoiding pinning.

Important

For proxies associated with MySQL databases, don't set the configuration parameter sql_auto_is_null to true or a nonzero value in the initialization query. Doing so might cause incorrect application behavior.

Additional limitations for Aurora PostgreSQL

The following additional limitations apply to RDS Proxy with Aurora PostgreSQL databases:

  • RDS Proxy doesn't support session pinning filters for PostgreSQL.

  • Currently, all proxies listen on port 5432 for PostgreSQL.

  • For PostgreSQL, RDS Proxy doesn't currently support canceling a query from a client by issuing a CancelRequest. This is the case, for example, when you cancel a long-running query in an interactive psql session by using Ctrl+C.

  • The results of the PostgreSQL function lastval aren't always accurate. As a work-around, use the INSERT statement with the RETURNING clause.

  • RDS Proxy currently doesn't support streaming replication mode.

Important

For existing proxies with PostgreSQL databases, if you modify the database authentication to use SCRAM only, the proxy becomes unavailable for up to 60 seconds. To avoid the issue, do one of the following:

  • Ensure that the database allows both SCRAM and MD5 authentication.

  • To use only SCRAM authentication, create a new proxy, migrate your application traffic to the new proxy, then delete the proxy previously associated with the database.