Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

How does Amazon Aurora (PostgreSQL) with RDS Proxy handle connections when adding a new reader or changing instance type?

0

I’m using Aurora PostgreSQL with one writer and one reader, fronted by an RDS Proxy (both write and read-only endpoints).

We’re planning to:

Add another reader (either provisioned or Aurora Serverless v2), and

Possibly change the instance type of an existing reader.

I’d like to clarify a few things for our team documentation:

When we add a new reader, do existing client sessions connected through the proxy’s read-only endpoint get rebalanced or moved to the new reader automatically, or do they remain pinned to their current backend connection?

During instance type updates or replacements, when do connections get reset (both for direct Aurora connections and through RDS Proxy)?

Which operations are considered “online” vs “offline” in terms of Aurora availability?

In what cases does the database cluster go offline or experience brief downtime?

Finally, why does the use of RDS Proxy limit support for features like Aurora Blue/Green deployments, and what are the recommended alternatives or workarounds?

If possible, please point to relevant AWS documentation or internal behavior details (especially around connection reuse and pinning) to help us include this in our internal knowledge base.

Topics
AnalyticsMigration & ModernizationDatabase
Tags
Aurora PostgreSQLAmazon Relational Database ServiceAmazon RDS ProxyAmazon Aurora
Language
English
asked a month ago46 views
1 Answer
0

When working with Amazon Aurora PostgreSQL with RDS Proxy, connection handling during scaling operations is an important consideration for availability planning.

Adding a New Reader

When you add a new reader to your Aurora cluster, existing client sessions connected through the RDS Proxy's read-only endpoint remain pinned to their current backend connections. RDS Proxy does not automatically rebalance existing connections to include the new reader. However, new connection requests to the read-only endpoint will be distributed across all available readers, including the newly added one.

Connection Handling During Instance Changes

For instance type changes or replacements:

  • Direct Aurora connections: When you modify an instance type, the DB instance becomes unavailable during the change and connections to that specific instance will be dropped. Applications using the cluster endpoint or reader endpoint will experience a brief interruption as connections are rerouted.

  • Through RDS Proxy: RDS Proxy helps minimize disruption during these changes. If a connection is pinned to an instance that becomes unavailable, the next query on that connection will return an error. However, your application can immediately reconnect to the same proxy endpoint, and RDS Proxy will route the connection to a different available instance.

Online vs. Offline Operations

Most Aurora operations are designed to be online with minimal disruption:

  • Adding a reader is an online operation that doesn't affect the writer or existing readers
  • Instance type changes require the specific instance to be temporarily unavailable
  • For Multi-AZ deployments, failovers can occur with minimal downtime as RDS Proxy automatically routes traffic to the new writer

Cluster Downtime Scenarios

The Aurora cluster may experience brief downtime in these scenarios:

  • During a failover event when the primary instance fails and a replica is promoted
  • When performing major version upgrades
  • When there are no available reader instances in the cluster and you're attempting to connect to a reader endpoint

RDS Proxy helps minimize this downtime. During a failover, it automatically routes traffic to the new writer DB instance and preserves existing connections where possible. The proxy tracks DB instance roles based on cluster metadata without relying on DNS, which helps quickly restore connections faster than waiting for DNS propagation.

If your cluster has no available reader instances but they exist in the cluster (they're just not in the 'Available' state), RDS Proxy will wait for a reader to become available. If no reader becomes available within the connection borrow timeout period, the connection attempt fails. If your cluster has no reader instances at all, RDS Proxy immediately returns an error when you try to connect to a reader endpoint.

Regarding Aurora Blue/Green deployments with RDS Proxy, the limitations exist because of the complex interaction between connection management in the proxy and the switchover mechanics of Blue/Green deployments. While specific workarounds aren't detailed in the provided information, using the cluster and reader endpoints directly during switchover periods might be necessary in some scenarios.
Sources
Resolve Aurora failover downtime and connection errors | AWS re:Post
Amazon Aurora endpoint connections - Amazon Aurora
Working with Amazon RDS Proxy endpoints - Amazon Relational Database Service
Working with Amazon RDS Proxy endpoints - Amazon Aurora

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content