Your AWS bill went up and nobody told you why

On August 1st, 2026, two of our clients woke up to a charge on their AWS account that hadn't existed the month before.

One at $86.40 a day. The other at $28.80.

Neither had changed a thing. No new servers, no new users, no extra traffic. The exact same system as on July 31st, running exactly the same way. It just cost more now.

They're businesses with nothing in common: a mobile app used by around 3,000 people in the field, and a cash-closing platform running across more than 130 locations. The only thing they shared was the date.

And neither of them picked that date. AWS did.

If you're watching your bill climb with no explanation, this is probably happening to you too.

Why it goes up when you do nothing

AWS puts an expiration date on the software it hosts for you. When your system's database reaches that date, nothing gets shut off — they keep providing the service, but they start billing you separately for it.

The charge is calculated per hour, per processor. Ten cents an hour. Sounds like nothing. But it runs 24 hours a day, every day, multiplied by every database you own:

And here's what almost nobody sees coming: the rate doubles in the third year. The charge doesn't just start on its own. It grows on its own too.

Why nobody told you

This is the important part, and it's worth saying plainly: you didn't do anything wrong.

AWS does send a notice. Months in advance. But it goes to the email address the account was opened with, and to the "alternate contacts" — two inboxes that at most companies nobody checks. Often the account was opened years ago, with the email of someone who no longer works there.

The notice arrived. It arrived in a mailbox nobody opens.

That's why a charge like this can run for weeks unnoticed. Nothing breaks. The system doesn't go down. No alert fires, because technically nothing is wrong: you're paying for a service you are genuinely receiving.

The only place it shows up is your bill, line by line. That's where you have to go looking for it.

What we did

In both cases the work was the same from end to end: we found it, we planned it, and we executed it. Neither client had to investigate anything, or find anyone, or understand the problem for it to get solved.

What did change between them was how long each business could afford to stop. And that changes everything.

The one that could pause a few minutes overnight

The field app has users with defined working hours. We measured their activity hour by hour across 28 days to find the real low-activity windows — not the ones we assumed, the ones the data showed.

Eighteen databases migrated between August 29th and September 1st. Each one with a tested backup before we touched it and a written rollback plan in case anything went wrong.

The one that can never stop

The 130-location chain processes cash closings continuously. An interruption mid-operation isn't an inconvenience: it's money left half-counted. The conventional route would have cost 15 to 40 minutes of downtime. Not an option.

We used a different method: stand up a full copy in parallel, upgrade it, keep it synchronized with the original second by second, and then swap the two. It's more expensive and considerably more delicate to operate, but it allows something the direct path doesn't.

We told them from the plan, before starting: absolute zero wasn't achievable. What was achievable were those two minutes. We'd rather promise what we can deliver.

What a clean result doesn't show

An uneventful night looks easy in hindsight. It rarely is. Two things explain why this doesn't get improvised — one is how we always work; the other happened that night.

We work around your operation, not the other way around

The hour isn't picked for our convenience. We measure the business's real operation —when it bills, when it closes, when it rests— and agree on the window with the client based on that data. And in the moment, before moving anything, we verify there's no operation in progress: if there is, it doesn't run. That condition isn't negotiable.

And knowing when NOT to press the button

Mid-operation, the new copy entered an error state. The obvious correction — the one anyone unfamiliar with the details of that account would have applied — would have shut down live production processes at eleven at night. We didn't apply it. The state resolved itself minutes later, and production never noticed a thing.

That decision not to act was the most delicate moment of the whole night, and it's exactly what you're paying for in this kind of work.

How to know if it's happening to you

Four questions. You don't need to be technical to ask them, and all four can be answered today.

1. 1

   Does “Extended Support” appear on your AWS bill?

   Open this month's breakdown and search for that term. If it's there, you're already paying for expired software. Start here: it's the one that gives you an immediate answer.

2. 2

   What email do AWS notices go to?

   Check which address the account was opened with and whether alternate contacts are configured. If it's an address nobody checks, or belongs to someone who's gone, the notices are getting lost before they reach anyone.

3. 3

   Does anyone on your team have the list of what version each system runs and when it expires?

   If you ask and nobody has it on hand, it doesn't exist. This is the question that catches the next charge before it starts.

4. 4

   Does anyone alert you when your bill changes pattern?

   The 130-location chain's daily spend jumped 60% overnight and nothing fired. Most alerts are set to a fixed amount — “tell me if I go over $5,000” — and that kind of alert says absolutely nothing until the increase hits the ceiling. What works is an alert on deviation from the previous month.

If all four come back clean, you don't have this problem. If any of them left you unsure, it's worth resolving before another month piles up.

This charge doesn't take your service down at three in the morning. It bills you every day, quietly, while everything looks fine. No alarm catches it, because there's nothing broken to catch.

At Wake Code this is what we do. We check whether the charge is already running in your account, how long you've been paying it, and what else in your infrastructure has an expiration date attached. If a migration is needed, we plan it and execute it ourselves — and the first question we'll ask you isn't technical: it's how long your business can afford to stop. Everything else follows from that answer.

You don't have to understand the problem. You have to stop paying for it.