--- title: 'Why Stopped RDS Instances Restart After 7 Days (and How to Stop It)' description: 'AWS restarts any stopped RDS instance after 7 days, by design. Here is why it happens, what the silent restarts cost, and how to keep databases off.' date: '2026-06-10' readingTime: '6 min read' --- You stop a dev database on Friday to save money. Two weeks later it is running again, and nobody started it. Nothing is broken. This is AWS doing exactly what it was designed to do, and it is one of the more expensive surprises in non-production RDS, because the restart happens quietly while the charges do not. ## The 7-Day Rule, in One Line **AWS automatically starts any stopped RDS instance after 7 days.** It is not a bug, and it is not a setting you missed. You cannot turn it off either. AWS does this so that stopped databases still receive maintenance and security patches. When you stop an RDS instance, it stays stopped for up to 7 days. On day 8 at the latest, AWS starts it again. From that point you pay the full hourly rate until something stops it. ## What This Quietly Costs A single `db.m5.large` Multi-AZ instance in `eu-west-1` runs about **$240/month** doing nothing. Stop it for a long weekend and the maths works in your favour. Stop it for a frozen project or a holiday, and AWS restarts it on day 8 while everyone has forgotten the database exists. The restart is the trap, because it is invisible. There is no email and no alert. The instance simply rejoins your bill, and you find out four weeks later in Cost Explorer, assuming you look. Across a handful of parked dev and staging databases, one unnoticed restart can put **$1,000 to $3,000 a month** back onto a bill you thought you had cut. ## The Three Ways to Actually Keep RDS Off ### Re-stop It on a Schedule The standard fix is to run something on a schedule that stops the instance again shortly after AWS restarts it. A daily job, or at least one that runs every few days, catches the day-8 restart and parks the database again before it costs much. This is what proper scheduling does, whether it is [AWS Instance Scheduler](https://docs.aws.amazon.com/solutions/instance-scheduler-on-aws/), a DIY Lambda, or a managed tool. The requirement is that the schedule keeps running indefinitely, not that it stops the instance once. ### Snapshot and Delete For databases you genuinely will not touch for weeks, the cheapest path is to take a final snapshot and delete the instance. You stop paying for compute and for the provisioned instance, and you keep paying only for the snapshot storage, which is cheap. When you need it back, you restore from the snapshot. The trade-off is honest. A restore is slower and more disruptive than a start, the endpoint changes, and you have to script it carefully. It suits long-frozen environments and is overkill for a database you use every week. ### Use a Managed Scheduler Managed tools like [ParkMyAWS](https://parkmyaws.com) treat the 7-day restart as a solved problem. The schedule re-stops the instance automatically, and you can see that it happened. The restart that would otherwise be invisible shows up as an action in a dashboard instead of a line on next month's bill. The trade-off is the same as for any managed tool. It is a subscription, and you grant a cross-account IAM role. If that rules it out for you, the first two options work fine. They just leave the question of whether the re-stop actually ran for you to answer. ## The DIY Version, and Where It Bites A hand-rolled re-stop Lambda is easy to start and genuinely fiddly to finish: - `StopDBInstance` fails if the instance has read replicas, so you have to stop those first, in order. - Multi-AZ failovers can leave an instance in `modifying` for ten minutes or more, so you need retries and backoff. - Aurora uses a different API (`StopDBCluster`) with its own 7-day limit. - If the Lambda errors on the one run that mattered, the instance stays up, and nothing tells you. That last point is the pattern. Re-stopping is the easy part. Knowing it worked is the hard part. The full build is in [how to schedule RDS instances](/blog/schedule-rds-instances). ## Why the Silent Restart Is the Expensive Part The 7-day rule is annoying but predictable. The expensive part is that a restarted database looks identical to one you never stopped. Without something watching, "we scheduled our databases off" slowly turns into "we scheduled them off once, back in March." The savings decay and nobody notices, because no number on a screen shows the gap between what is parked and what quietly came back. That is the argument for treating RDS scheduling as something you can see, not just something you set up once. Build it or buy it, but make sure the answer to "are our databases off right now?" is one glance instead of an afternoon in Cost Explorer. ## See What Your Idle Databases Cost If you have parked, or supposedly parked, RDS instances, it is worth knowing the real number. The [free idle-cost calculator](/aws-idle-cost-calculator) gives you a quick estimate. When you want it handled, [ParkMyAWS](https://parkmyaws.com) schedules EC2 and RDS, including Aurora, handles the 7-day restart for you, and shows the savings as they add up. Connect an account with a read/write IAM role, pick your databases, set office hours, and the day-8 surprise stops being your problem. For the fuller picture, see [how much idle dev and staging environments really cost](/blog/cost-of-idle-dev-environments).