Architecture · Aurora MySQL
How is your Aurora MySQL cluster put together?
The cluster grew with the product. Readers and endpoints were added one at a time, then bigger instances, maybe a second region, each for a good reason. I review the layout as a whole and write down what to keep and what to change, with a test for each change. I can also make the agreed changes with your team.
When this helps
These are the situations where a look at the whole layout tends to pay off:
- We added readers, but the load isn't spreading across them.
- Users notice every failover, even the planned ones.
- We're planning a second region and don't know what it changes for writes.
- Should we stay on provisioned instances or move to Serverless v2?
- The systems around the cluster, such as caches and data pipelines, misbehave when it fails over.
What the review covers
Five areas, looked at together rather than one by one:
Writer, readers and endpoints
Which traffic goes to which endpoint, and whether the readers are sized and placed for the reads they actually get.
Connections and failover from the application side
What users see during a failover is decided in the connection layer: pool settings, DNS caching, RDS Proxy and retries. I trace that path from the application to the new writer.
Capacity model
How your load changes over a day and over a month, compared with the instance classes or Serverless v2 range you run, and whether reader auto scaling helps.
Cross-region and recovery design
Global Database or cross-region replicas for a second region; backtrack and point-in-time restore for mistakes. Each protects against something different, and each leaves some steps to a runbook.
What sits around the cluster
Caches such as Redis or Valkey and search indexes in Elasticsearch or OpenSearch see Aurora's failovers and replication lag, and so do CDC consumers. I check how they behave when Aurora fails over or falls behind, because users can notice a problem there first.
What you receive
- The current layout, written down as it is, with the parts worth keeping marked.
- Recommended changes, each with its reason and a way to test it.
- Failover behaviour as the application sees it, with the settings that control it.
- Open questions that need a decision from your side.
- If you want the changes made: the agreed changes applied with your team and handed over with runbooks once tested.
How it runs
- We agree the cluster and the question, and set an effort limit.
- I review the configuration and metrics your team shares, along with how the application connects.
- I write up the review and go through it with your technical owner.
- If changes are agreed, I make them with your team and hand them over once they're tested.
Scope, deliverables, effort limit, fee and schedule are agreed in writing before work begins.
Fixed fee, agreed after a short scope review.
Not included
- Running the system after handover: managed operations, on-call cover or emergency response.
- AWS account or cost review beyond the database.
- Guarantees about availability or recovery time.
- Application code changes.
Related reading
- Aurora MySQL performance and cost diagnostic. Use this instead when the question is one slow or expensive workload.
- MySQL and Aurora MySQL upgrade review. For planning a version change and its risks.
- Availability & Recovery Review. For checking whether the failover and restore procedures you have would work.
Questions
Is this the same as the performance and cost diagnostic?
No. The diagnostic follows one slow or expensive workload to its cause. This review looks at how the cluster is laid out and how it fails over. If you're not sure which you need, describe the problem and I'll say.
Do you need access to our AWS account?
Not for the review. Exports and read-only views are usually enough. If you want me to make the changes, we agree the access as part of that scope.
Can you review a cluster we haven't built yet?
Yes. The same questions apply to a planned layout, and it's easier to change on paper than in production.
Can you make the changes?
Yes, as an agreed build scope after the review. I work with the access you grant and through your change approval, and your team sees each change tested before it's handed over.
Want a second look at your Aurora layout?
Tell me how the cluster looks today, what has changed recently and the decision in front of you. You don't need diagrams yet.