Keystone

The Hidden Tax of "Just Spin It Up" Engineering

Every engineering team has said it. Probably this week.

“Let’s just spin one up and see.”

It is one of the great phrases of the cloud era. It captures everything that made AWS revolutionary in the first place — the ability to materialise a database, a Kubernetes cluster, an EC2 fleet, a SageMaker endpoint, in the time it used to take to file a ticket with IT.

It is also, quietly, one of the most expensive cultural habits in modern engineering organisations.

What “just spin it up” actually looks like

It looks like productivity. An engineer hits a blocker, needs to test something, fires up a resource, finishes their work, moves on.

The resource, of course, does not move on. It stays.

Multiply that pattern across 50 engineers, 200 working days a year, and four or five years of company history, and the result is fairly predictable:

  • Hundreds of EC2 instances tagged Name=test-something-2023
  • Dozens of RDS instances with the same database schema, owned by no team
  • Several redundant Kubernetes clusters, some running production-scale node pools to serve effectively no traffic
  • A long tail of “POC” SageMaker endpoints, each costing more per month than a senior engineer’s laptop

The shorthand for this in cloud cost circles is the POC tax — resources spun up for short-term experiments that were never decommissioned. For organisations with mature DevOps practices but no explicit lifecycle policy, it routinely accounts for a double-digit percentage of total monthly cloud spend.

Why it compounds

The economics of “just spin it up” are deceptively bad for three reasons.

1. The cost is invisible at the moment of creation

When an engineer creates a db.r6g.xlarge, no dollar figure flashes on the screen. There is no friction, no approval, no signal that this decision will cost $370/month indefinitely. The cost only materialises 30 days later, on a bill that is read by someone else entirely.

2. Deletion has a personal cost; creation does not

Spinning up a resource takes 30 seconds. Confidently deleting one takes considerably longer. You have to check: is anyone still using this? Is it referenced by anything? What if I’m wrong? The asymmetry guarantees that resources accumulate.

3. Ownership decays faster than resources do

The engineer who created the resource leaves the team. Then the company. Their Slack handle goes inactive. The resource keeps running. Six months later, nobody can answer “what is this for?” — and the safest action becomes “leave it alone”.

The cheapest resource is the one you didn’t spin up. The second cheapest is the one you remembered to tear down.

What good teams do differently

The engineering cultures that handle this best treat resource provisioning with the same seriousness as production deploys. Not bureaucracy — intentionality. Specifically:

  1. Every provisioned resource has an owner, a purpose, and an expiry, captured as tags at the moment of creation.
  2. Temporary resources actually expire. A “POC” tag means something — typically a 30-day TTL enforced by automation.
  3. Personal sandboxes are tiny by default. A t4g.small is enough for almost any experiment. If you need more, ask, and the conversation creates the ownership.
  4. There is a weekly “what’s running and why” review — even if it’s five minutes in a team standup.

None of this slows down the engineers. The point of all of it is to keep “just spin it up” feeling cheap and easy — by making sure the long tail doesn’t quietly bury you.

A simple starting point

If you do nothing else this quarter, do this:

# Find every EC2 instance that has been running for more than 30 days
# with low average CPU utilisation
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?LaunchTime<=`2026-04-18`].[InstanceId,Tags[?Key==`Name`]|[0].Value,LaunchTime]' \
  --output table

Then, for each one, ask the team: do we still need this?

You will be surprised how many “yes, definitely” answers turn into “…actually, no” after thirty seconds of thought.

“Just spin it up” is not a bad culture. It is the culture that built modern software. But every culture has a tax attached to it, and the tax of unmonitored provisioning is one of the largest and least-discussed line items in the entire industry.

The good news: it is also one of the easiest to fix. Let’s talk about what that could look like for your team.