RDS Aurora Autoscaling Reader Group

Remove Both Existing Readers and Let Autoscaling Manage Both: In the event of a writer failover, the autoscaling might be slow to react if both readers are scaled in (if the minimum is set to 0).

Failover Considerations:

Failover Scenario: If the writer fails, a reader will be promoted to the writer. Having at least one reader available at all times is crucial to avoid downtime.

Best Practices Recommendation:

Reader Availability: To ensure availability during failover, it's advisable to always have at least one reader running.

Autoscaling Group: Set up the autoscaling group with a minimum of 1 reader and a maximum of 2 readers. This way, you ensure that there’s always a reader available, and you can still benefit from scaling during peak business hours.

Scaling Metrics: Using CPU utilization as a metric is appropriate. However, you may want to monitor the actual CPU usage patterns to fine-tune the threshold percentages (e.g., you might find that 10% is too low and results in unnecessary scaling activities), and also do consider the Memory Usage, and number of connections.

Final Recommendation:

Go with Option - Keep one reader and let the autoscaling manage the second one. Set your autoscaling group with a minimum of 1 and a maximum of 2 readers. This setup provides a balance between availability and cost efficiency while ensuring that failover scenarios are adequately covered. If you feel cost is a concern, run the reader instance as a lower instance type.

See this blog for scaling strategies : Schedule scaling for Amazon Aurora replicas using AWS Application Auto Scaling

Keep One Reader and Use Auto Scaling for the Other:

Pros: Provides a balance between manual control and automation. The manually created reader can have a higher promotion tier for faster failover.

Cons: Slightly more complex to manage as you have a mix of manual and auto-scaled instances.

Aurora's "Auto Scaling" groups can provide a lot of flexibility as noted in the previous responses. Whether you decide to keep one or none of the readers outside of business hours will likely depend on your company's business requirements around "recovery time objective" (RTO) in a failure scenario where your writer instance is impacted. Without an available reader instance (we call these Single-AZ or SAZ clusters), failures effecting the writer require a "host replacement", which provisions a new instance for the writer. This operation takes on the order of several minutes, which may or may not meet your RTO requirements. This also means that sudden spikes in workload may cause auto-scaling to occur but if it takes several minutes to provision the auto-scaled reader, performance may not be ideal during that time. For more predictable spikes (e.g., the NY stock exchange opens and closes at the same times every trading day), many customers prefer to automate manually provisioning new readers in advance through some job scheduler rather than using Auto Scaling. Additionally, in the unlikely failure case where an entire AZ is unavailable, the host replacement model for SAZ clusters may not be possible because our provisioning algorithms require replacing the instance in the same AZ as it was originally placed. Please keep these scenarios in mind when considering how to best meet your company's resilience requirements while balancing costs.

Another option to consider for automatic scaling of Aurora instances is to use the Aurora Serverless v2 (ASv2) instance model. ASv2 automates vertical scaling between a MIN and MAX range of compute resources you define known as Aurora Compute Units (ACUs). This approach scales in-place by added and removing compute resource (vCPUs, memory, network bandwidth) dynamically based on workload. It scales up and down more quickly and in more granular units than the Auto Scaling instance model discussed above. This makes it more responsive to sudden spikes. Aurora supports a hybrid model of both fully-provisioned and ASv2 instances so it would be possible to make one or both of your readers ASv2 instances. Please be aware that the pricing model of provisioned and ASv2 is quite different so please consider this carefully before jumping to a conclusion. For more information on ASv2, please see our public documentation at https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html.