Downtime risk checker for RDS and Aurora changes

The moment a backend engineer opens a ticket to resize an RDS instance or change a subnet group, they have no reliable way to know whether it will cause downtime, how long it will last, or whether there's a sequencing trick that avoids it entirely. They find out after the fact — often in production. The gap persists because AWS and Aiven have every incentive to make changes feel easy to click, not to prominently warn you that clicking 'Apply Immediately' on an instance class change will bounce your database for 5-10 minutes on a Tuesday afternoon.

Engineers right now piece this together from forum posts, AWS documentation that's scattered across five pages, and tribal knowledge from whoever has been burned before. The console does surface some warnings, but users explicitly complain it's 'not always clear from the console if changes may create downtime' — meaning the warnings that exist are inconsistent and don't cover multi-step operations like changing a subnet group that also forces a VPC migration.

What's structurally awkward is that the buyer (an engineering team or DBA) and the person who gets paged at 2am (an on-call engineer) are different people. The buyer evaluates the managed DB service, accepts the trade-offs, and moves on. The on-call engineer inherits undocumented downtime risk they didn't agree to and has no tool to interrogate it before acting.

This is a recurring business need, not a one-time lookup. Every time a team changes instance type, applies a patch window, upgrades a major engine version, or modifies network config, someone needs to answer the same question: will this cause downtime, when, and for how long? Without a structured answer, teams either schedule unnecessary maintenance windows (costly, slow) or proceed blindly and eat the outage.

What to build

Build a web tool and CLI that takes a described RDS or Aurora change (instance class, engine version, subnet group, parameter group, storage type) and outputs a specific downtime risk assessment — estimated duration, conditions that trigger a reboot, safer sequencing if one exists — sourced from a continuously maintained knowledge base of AWS change behaviors.

Where to start

Start with the single most complained-about case: RDS instance class changes and the conditions that determine whether a reboot is triggered, covering Multi-AZ vs single-AZ differences and the 'apply immediately' vs 'next maintenance window' distinction, since this is the most Googled and least clearly documented scenario.

The hard part

The knowledge base of which changes cause downtime under which conditions needs to be kept current as AWS silently changes behavior across engine versions and instance families — building it once is doable, keeping it accurate at depth is an ongoing editorial and engineering burden.

How it makes money

Free for single one-off lookups; charge teams a monthly subscription for API access (so it integrates into their change management or internal tooling), alerting when AWS behavior changes for configurations they use, and audit logs of pre-change risk assessments.