Cloud Bills Don't Have to Surprise You

I built and ran a real cloud application with a mobile app, a backend service, a managed database, file storage, hosted login, and AI-powered image scoring. Its running cost stayed near zero. That was not the result of a clever trick. I decided what the project did not need yet, and I wrote down why.

TL;DR: Cloud bills stay predictable when always-on services are chosen deliberately, metered features have hard limits and billing alarms, and cost-saving decisions are documented so nobody quietly reverses them later.

What Is Cloud Cost Control?

Cloud cost control is the practice of deciding what a system should be allowed to spend, measuring what it actually spends, and making sure unexpected usage cannot run without a limit. It is less about chasing discounts and more about matching the infrastructure to the business as it exists today.

The Costs Are Almost Never The Compute

People often picture cloud cost as a server running by the hour. In a small application, that is rarely where the surprise begins. The expensive pieces are often the supporting services that stay on whether anyone uses the application or not.

A managed network gateway, a load balancer, and a standby database are all sensible choices for a business serving customers. They improve availability and reduce the effect of a failure. They also create a monthly floor before the first customer arrives.

For this side project of mine, I deliberately used a single-copy database with no standby. I left out the managed network gateway and the load balancer. That shape was less resilient, but it matched an early project with no customers and no revenue. If demand justified stronger availability later, I could add it with a reason and a budget behind it.

This is the same principle I use in routine operations: make the decision explicit so the system does not drift toward whatever happens to be easiest that day.

A Trade-Off Must Be A Decision

The most important part was not leaving those services out. It was recording each omission as deliberately accepted, with a clear instruction not to "fix" it by default.

Without that record, the next competent person reviewing the environment sees a missing standby database and opens a ticket. They see no load balancer and recommend one. They see a simpler network and replace it with the standard production pattern. Every recommendation is technically reasonable, and together they create a bill for resilience the project was never meant to buy yet.

That is why cost trade-offs need to be documented as decisions, not left looking like unfinished work. A good decision states what risk is being accepted, why it is appropriate now, and what change in the business would justify revisiting it.

There is a useful parallel in how I host this site. The right architecture is not the one with the most components. It is the one that meets the actual job without creating more system than the owner needs to operate.

The One Feature With No Ceiling

The application's image-scoring feature used a metered AI service. One scoring call cost about a penny, and the feature was switched off by default in development, so it cost nothing there. The per-use price looked harmless.

The problem was not the penny. The problem was that the public feature had no upper bound. There was no per-user usage limit and no billing alarm. Nobody was attacking it, but an abusive user, an automated request, or a simple software loop could have repeated that penny thousands of times.

I closed that gap in the same review session. The feature that spent money received a per-user cap, alerts at half and ninety percent of the expected budget, and a forecast alert for spending that was headed beyond it.

The general rule is simple: any metered service exposed to the internet needs a cap and an alarm before it needs anything else. A low unit price is not a spending control.

The Shutdown Scripts That Lied

I also had automated shutdowns intended to take the environment to zero when it was not in use. They appeared reassuring because they always finished with a success message.

They also ignored every error. If the cloud provider refused to stop something, the automation carried on and reported that it was done. The resource stayed running, and the bill kept moving while the operator believed the shutdown had worked.

I changed those shutdowns to fail loudly when the requested state does not take effect. That is a small example of why automation needs verification, not just activity. A button that says it saved money is not useful unless it confirms the spending resource actually stopped.

When A Cost Choice Becomes A Data-Loss Choice

The most dangerous setting in the environment was attached to database teardown. Deletion protection was off, no final snapshot would be taken, and automated backups would be removed with the database.

One mistaken teardown could therefore erase the database and every recoverable copy in the same action. What began as a way to avoid paying for unused infrastructure had crossed into a data-loss decision.

I changed the teardown behavior so retaining a final snapshot was part of the shutdown, not a manual hope. Cost controls should remove waste. They should not make the only copy of important data disposable.

For a business reviewing its own cloud account, I would start with three questions: Which costs are always-on and which are per-use? Does every metered feature have both a cap and an alarm? Are the trade-offs written down as deliberate decisions, or do they merely look like things nobody got around to? If you want help getting clear answers, I can help.