Ask a finance team where the cloud money goes and you usually get a shrug. Compute is nearly always the biggest line on the invoice, and the biggest waste inside it is rarely anything exotic. It is ordinary virtual machines running two or three sizes larger than the work needs. What follows is the sequence we run on a HOUSE603 cost review, in order, with the commands we actually type. None of it is clever. That is the point.

Why over-provisioning is the default

It starts innocently. A service ships, nobody knows how much traffic it will take, so someone picks a comfortable size. Traffic grows. There is a scare one afternoon and an engineer bumps the instance to be safe. The size never comes back down. Do that across thirty services over a couple of years and you get a bill that tracks the team's anxiety rather than its traffic.

The reason it persists is that shrinking an instance feels risky and saving money is nobody's on-call page at 2 a.m. So the numbers only ever go up. Breaking that pattern does not take heroics. It takes two or three weeks of honest measurement and the nerve to act on what the graphs say instead of what the last incident felt like.

Step 1: Baseline with real metrics

Collect two to four weeks so you catch the weekly rhythm, month-end batch jobs and all. Average CPU will lie to you here, so pull the 95th percentile alongside it. A box that averages six percent but hits seventy every Monday morning is not the same box that sits flat at six all week, and only the p95 tells them apart. On AWS the CLI gives you both in one call:

# p95 CPU for one instance over 14 days (3600s periods)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --start-time "$(date -u -d '14 days ago' +%FT%TZ)" \
  --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --statistics Average --extended-statistics p95 \
  --query 'Datapoints[].{t:Timestamp,avg:Average,p95:ExtendedStatistics.p95}' \
  --output table

Azure gives you the same shape of data with az monitor metrics list, and GCP with the Monitoring API or gcloud monitoring. Wherever you look, the tell is identical. If p95 CPU sits under roughly ten percent for weeks with plenty of room above it, that instance is a candidate to shrink. Note the word candidate. You are not done, because CPU is only one dimension.

Step 2: Memory and I/O matter as much as CPU

This is where a quick win turns into an outage if you rush. A machine can idle on CPU while pinning memory or maxing out disk throughput, and CPU-only right-sizing walks straight into that. AWS makes the trap easy to fall into because the default EC2 metrics do not report memory at all; you have to install the CloudWatch agent to see it. Before you touch anything, confirm memory, network, and EBS throughput on every candidate. A memory-bound service quietly moved onto a CPU-optimized family is exactly how a tidy Friday saving becomes a Sunday-night page.

Step 3: Pick the right family, then the right size

• Spiky, mostly idle workloads suit burstable families (AWS T-series, Azure B-series) that bank credits during quiet periods.
• Steady, CPU-heavy services want compute-optimized families (C-series).
• Memory-heavy caches and databases want memory-optimized families (R-series).

Get the family right first, then step the size down one notch at a time and watch a full day before the next drop. Resist making one big move to feel efficient; small steps are what keep this boring. And where the workload allows it, prefer two smaller instances behind a load balancer over a single large one. It usually costs a little less, and it turns losing a node into a shrug rather than an outage.

Step 4: Prove it in staging, then apply with code

Do not resize by clicking around the console. A console change is invisible to the rest of the team, unreviewed, and awkward to undo. Put the size in infrastructure-as-code instead, so it gets a pull request, a second pair of eyes, and a one-line road back if the graphs turn ugly:

# variables.tf
variable "web_instance_type" {
  type        = string
  default     = "t3.small"   # was m5.large
  description = "Right-sized after 4 weeks of p95 < 8%"
}

# main.tf
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.web_instance_type
  tags = { Name = "web", RightSized = "2026-09" }
}

Push it through staging with a load test that looks like real traffic, watch the same metrics for a day, then promote during working hours when someone is actually looking at the dashboards. Because the size is a variable, backing out is one line and a re-apply, not an emergency.

Step 5: Automate the savings so they stay

Here is the part almost everyone skips. Right-sizing decays. Six months on, someone has quietly bumped three instances back up after a busy week and you are paying for slack again. Two habits keep it honest. Autoscale the tier that genuinely varies, so capacity follows demand instead of a human's nerves. And switch non-production off out of hours. Dev and staging that sleep at night and on weekends run for roughly a third of the hours of an always-on setup, which is close to a two-thirds cut on those environments for one line of cron:

# stop dev fleet weeknights at 20:00 (cron on a control host)
0 20 * * 1-5  aws ec2 stop-instances --instance-ids \
  $(aws ec2 describe-instances \
     --filters "Name=tag:Env,Values=dev" "Name=instance-state-name,Values=running" \
     --query "Reservations[].Instances[].InstanceId" --output text)

Step 6: Lock in a discount on what is left

Discounts come last, and this is the mistake we see most often. A team buys three years of Reserved Instances against their current footprint, feels clever, and locks in every oversized box for the length of the contract. Right-size first. Once the running footprint is honest, cover the steady baseline with Savings Plans or Reserved Instances on AWS, Reservations on Azure, or Committed Use Discounts on GCP, and leave the spiky top of the curve on-demand or on spot. Buy commitment against reality, never against waste.

A realistic result

On the mixed fleets we assess, the monthly bill usually comes down somewhere between a third and a bit under a half. Roughly half of that is resizing and switching off idle non-production, and the rest is a sensible commitment on the baseline. None of it is anything a user can feel. Your numbers will not match ours, and that is the point: measure your own before and after, on your own account, and trust that over any headline percentage, including this one.

Most sites are dynamic out of habit rather than need. A page that changes a few times a day gets rebuilt from a database on every single request, which drags in an application server, a connection pool, and a scaling headache, all for content that could have been a plain file on disk. Static-first flips that default. Render the page once, cache it everywhere, and reach for a server only when the request truly cannot be answered ahead of time. We build this way on purpose: the main HOUSE603 site and this one are both single files served from the edge, which is most of why they load the instant you click.

The shape of a static-first stack

• Build step renders pages to HTML with hashed asset filenames.
• CDN edge serves those files from the location nearest each visitor.
• Thin dynamic layer, an edge function or a small API, handles the genuinely per-user parts such as search, forms, or a cart.

Knowing when not to do this matters just as much. If most of a page is unique to each logged-in user and changes on every view, you are fighting the model, and honest server rendering is the right call for that page. Static-first is for the large majority of pages that look the same for everyone, which is more of your site than you probably think: marketing, docs, blog, product listings, most of a dashboard's shell.

Cache-control is where the speed comes from

Caching is the whole reason static-first is fast, so it is worth getting exactly right, and it comes down to two classes of asset with two policies. Fingerprinted assets, the ones whose filename carries a content hash, cannot change without changing their name, so you cache them effectively forever. HTML does change, so you let the CDN revalidate it while it keeps handing back the last good copy the instant anyone asks:

# Immutable, hashed assets: app.9f2a1c.js, styles.4b8e.css
Cache-Control: public, max-age=31536000, immutable

# HTML: fast, but always fresh behind the scenes
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=86400

The s-maxage line tells the CDN to hold the page for ten minutes. The stale-while-revalidate line is the part people miss: for a full day after that, the edge is allowed to hand back the slightly stale page immediately while it fetches a fresh copy in the background. Readers never sit waiting on your origin, and your origin barely gets touched. The one tax you pay is cache invalidation, so when you need a change out now rather than in ten minutes, purge the specific paths through your CDN's API as the last step of the deploy.

A minimal edge-friendly origin

Whatever sits behind the CDN should be boring and correct. An nginx origin for a static bundle is a dozen lines:

server {
  listen 443 ssl http2;
  root /var/www/site;

  # hashed assets never change
  location ~* "\.[0-9a-f]{6,}\.(js|css|woff2|png|svg)$" {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }
  # html revalidated, SPA-style fallback
  location / {
    add_header Cache-Control "public, max-age=0, s-maxage=600, stale-while-revalidate=86400";
    try_files $uri $uri/ /index.html;
  }
}

Keep the dynamic parts honest

Put anything that truly runs per request behind its own path, say /api/, so it scales, fails, and gets rate-limited on its own without ever taking the cached site down with it. If the API has a bad day, the pages still load from the edge and the site degrades to read-only instead of going dark. On the client, show what you already have instantly and refresh it in place:

async function load(url) {
  const cached = sessionStorage.getItem(url);
  if (cached) render(JSON.parse(cached));   // show instantly
  const res = await fetch(url, { headers: { 'Accept': 'application/json' } });
  const data = await res.json();
  sessionStorage.setItem(url, JSON.stringify(data)); // refresh in place
  render(data);
}

Ship the security headers for free

A static origin makes a strict Content-Security-Policy genuinely achievable, because you control every script that loads and nothing injects markup at runtime. Set HSTS, a tight CSP, X-Content-Type-Options: nosniff, and a sensible frame policy at the edge, and you have closed off whole categories of attack that dynamic apps spend real effort fighting. There is no database in the request path to inject into and no server-side template to trick.

What you get

What you end up with is pages that render in well under a second on a mid-range phone, an origin that shrugs off a traffic spike because the edge soaks it up, and a bill that barely moves as you grow. There is no trick to it. The discipline is just to make yourself justify every dynamic endpoint instead of assuming one, and most of the time you will find you did not need it.

Plenty of small teams deploy at midnight and hope. The late hour is not caution, it is a tell: the process is not safe, so it gets scheduled for when the fewest people will notice if it breaks. Fix the process and the timing stops mattering, and you can deploy at 11 a.m. with a colleague watching a graph. Below is the checklist we hand HOUSE603 clients and the mechanics under each line. If you would rather generate a version tailored to your setup, there is a live tool for exactly this in the Tools section.

1. Build an immutable, versioned artifact

Tag every build with the commit SHA and never rebuild what you call the same release. If app-9f2a1c.tar.gz is the file that passed CI, that exact file is what goes to production and, if it comes to it, that exact file is what you roll back to. Rebuilding from source on the way out the door is how a green pipeline still ships a surprise. Everything else here rests on this one habit.

2. Make database migrations backward compatible

For a few seconds during every switch, the old code and the new code are both live and hitting the same database, so the schema has to keep both happy. The pattern that makes this safe is expand then contract. The first release adds the new columns or tables and nothing else. The code that reads and writes the new shape ships next, while still tolerating the old one. Only once nothing touches the old shape does a later release remove it. Burn this failure mode into your memory: never rename or drop a column in the same deploy that ships the code depending on that change, because that is a guaranteed few seconds of 500s.

3. Release beside the running version

Bring the new version up on a new port while the current one keeps serving every request. A reverse proxy turns the eventual switch into a one-line change. With nginx you point an upstream at whichever release should be live:

# /etc/nginx/conf.d/app.conf
upstream app {
  server 127.0.0.1:8081;   # flip to 8082 for the new release, then reload
}
server {
  listen 80;
  location / {
    proxy_pass http://app;
    proxy_next_upstream error timeout http_502 http_503;
  }
}

4. Pass a health check before receiving traffic

The new version has to earn its traffic. A health endpoint that returns 200 no matter what is worse than none because it lies, so make it check the things the app genuinely needs: the database connection, a cache ping, whatever it cannot run without. Then have the deploy script wait on it instead of guessing with a fixed sleep:

#!/usr/bin/env bash
set -euo pipefail
NEW_PORT=8082
systemctl start app@"$NEW_PORT"

# wait up to 30s for the new release to report healthy
for i in $(seq 1 30); do
  if curl -fsS "http://127.0.0.1:$NEW_PORT/healthz" >/dev/null; then
    echo "healthy"; break
  fi
  sleep 1
  if [ "$i" -eq 30 ]; then echo "unhealthy, aborting"; exit 1; fi
done

5. Drain and switch

Point the proxy at the healthy new release and reload. This is the actual moment of the deploy, and the reason it is safe is that nginx does not slam the door. It finishes the requests already in flight on the old workers before retiring them, so nothing in progress gets cut off:

sed -i "s/:8081/:$NEW_PORT/" /etc/nginx/conf.d/app.conf
nginx -t && systemctl reload nginx   # graceful, connection-draining reload

6. Smoke test in production

The second the switch lands, run a few read-only checks against the live URL. Load the homepage, hit one core API route, fetch a static asset. It takes ten seconds, and it means you learn the release is bad from your own terminal rather than from a customer email forty minutes later.

7. Watch, then keep rollback one command away

Stay on the error rate and p95 latency for about ten minutes; most bad deploys announce themselves inside the first five. If one does, rollback is not a scramble, because the previous artifact is still sitting on disk and the proxy switch was a single edit, so undoing it is the same move backwards. Wire the whole sequence into CI so a deploy, and a rollback, is one button:

# .github/workflows/deploy.yml (excerpt)
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: ./scripts/build.sh "$GITHUB_SHA"
      - name: Ship (health-checked, draining switch)
        run: ./scripts/deploy.sh "$GITHUB_SHA"

The mindset shift

Once every deploy is reversible and every deploy is observable, the fear quietly drains out of shipping. You start pushing small changes often, in daylight, with someone watching the dashboard next to you, because a bad release is a ten-second rollback instead of a ruined evening. That shift in how the team feels about deploying is worth more than any single tool in the pipeline.