Cloud Cost Optimization for Small Teams: Cleanup Before Commitments

What cloud cost optimization means for a small backend team

For a small backend team, cloud cost optimization is an ordered process, not a hunt for discounts. You find where the money goes, remove idle resources, right-size what remains, and only then commit to reserved capacity. This guide is for backend and platform engineers who own the bill but have no FinOps function behind them.

Why the order matters

A commitment discounts whatever you are running when you sign. If that footprint includes forgotten instances or oversized databases, the discount locks the waste in for the length of the term.

Illustrative estimate (assumed numbers, not a benchmark): Locked-in waste = monthly committed spend × fraction later found unnecessary × months in term. With $2,000/month committed, 25% unneeded, and a 12-month term: 2,000 × 0.25 × 12 = $6,000 paid for capacity you could have deleted.

Reading the bill

Start with the cost breakdown grouped by service. In most small accounts a handful of line items, typically compute, managed databases, storage, and data transfer, make up most of the spend. Work on those first and ignore the long tail.

Then group by tag (owner, environment, service). This shows which spend belongs to production and which to a test that ended months ago. Untagged resources are the problem. In a small account they often land in one unexplained bucket that nobody feels responsible for. Waste stays there because no one can say whether it is safe to delete.

Copy+-----------+    +-----------+    +-----------+    +-----------+
| 1. Find   |--->| 2. Remove |--->| 3. Right- |--->| 4. Commit |
|   spend   |    |   idle    |    |   size    |    |  (last)   |
+-----------+    +-----------+    +-----------+    +-----------+
      |      commit last: a reservation locks in waste still running
      v
+------------------------------------------------------------+
|                     Monthly cloud bill                     |
+------------------------------------------------------------+
            |                                   |
            v                                   v
+------------------------+          +------------------------+
| Group by service       |          | Group by tag           |
| compute, databases,    |          | owner / env / service  |
| storage, transfer      |          +------------------------+
+------------------------+            |          |          |
            |                         v          v          v
            v                     +--------+ +--------+ +--------+
+------------------------+        | prod   | | stale  | |untagged|
| few line items make    |        | (keep) | | test   | | no     |
| up most of the spend:  |        +--------+ +--------+ | owner, |
| work on these first    |                              | waste  |
+------------------------+                              | hides  |
                                                        +--------+

The steps go in order: find spend, remove idle resources, right-size, then commit. Group the bill by service to find the few line items that make up most of the spend, and by tag to show untagged waste with no owner.

How to sweep for idle resources without breaking anything

The sweep is how you answer that question for each resource. Go slowly enough that nothing important disappears before someone can claim it.

Run it as four steps. First, tag every candidate with the sweep date and a suspected owner, taken from creation metadata or audit logs. Second, quarantine it in a way you can undo: stop the instance, scale the database down, detach the IP from DNS, or snapshot a volume before you remove it. Third, confirm the owner by posting the list where the team will see it. The waiting period has to be longer than the longest job cycle you have. A 30-day window will flag the quarterly batch job's volume as idle and delete it a week before it runs. Fourth, delete only what nobody claimed, and keep the final snapshot for one more cycle.

Before you delete any snapshot, check whether a backup policy or retention rule created it. Disaster-recovery copies look like clutter because nobody reads them, and that is how they are supposed to work.

Copyfrom datetime import date, timedelta

# The confirmation window must be longer than the longest job cycle (quarterly batch) plus some margin.
CONFIRM_WINDOW = timedelta(days=100)

def next_step(resource, today):
    """Return the next sweep action for one candidate resource."""
    tags = resource["tags"]
    # Disaster-recovery copies look idle on purpose; leave policy-managed items alone.
    if tags.get("created-by") == "backup-policy":
        return "skip: managed by a retention policy"
    # Step 1: tag with sweep date and suspected owner (from creation metadata or audit logs).
    if "sweep-date" not in tags:
        return "tag: add sweep-date and suspected owner"
    # An owner claim at any point ends the sweep for this resource.
    if tags.get("claimed-by"):
        return "restore: undo quarantine, remove sweep tags"
    # Step 2: quarantine reversibly before anything is deleted.
    if tags.get("quarantined") != "true":
        return "quarantine: stop, scale down, detach, or snapshot first"
    # Step 3: wait out the full confirmation window after posting the list.
    if today - date.fromisoformat(tags["sweep-date"]) < CONFIRM_WINDOW:
        return "wait: owner confirmation window still open"
    # Step 4: delete only unclaimed items, and keep the final snapshot for one more cycle.
    return "delete: unclaimed; retain final snapshot one more cycle"

candidates = [
    {"id": "vol-batch-reports", "tags": {"sweep-date": "2026-09-01", "owner": "data-team", "quarantined": "true"}},
    {"id": "snap-db-nightly", "tags": {"created-by": "backup-policy"}},
    {"id": "lb-preview-1234", "tags": {"sweep-date": "2026-06-15", "owner": "web-team", "quarantined": "true"}},
    {"id": "ip-partner-allowlist", "tags": {"sweep-date": "2026-09-01", "claimed-by": "payments-team"}},
    {"id": "db-old-analytics", "tags": {}},
]

for r in candidates:
    print(f"{r['id']:<22} -> {next_step(r, date(2026, 10, 18))}")

A provider-agnostic state machine for the tag, quarantine, confirm-owner, then delete workflow. It skips policy-managed backups and won't delete anything until a confirmation window longer than the quarterly job cycle has passed.

Right-sizing from measured utilization

Once the idle resources are gone, what remains is running, but often on more capacity than it uses. Right-sizing means matching instance class to observed demand, and the evidence has to cover a representative period: at least one full business cycle, including month-end batch jobs, weekly reports and any known traffic peaks. Look at peak and high-percentile values alongside averages. A service that averages 15% CPU but hits 90% during a nightly import is not oversized. It is sized for the import.

Check CPU, memory and disk or network I/O together. The constraint is whichever one runs out first, and a downsized instance usually shrinks all of them at once, including throughput limits tied to instance size.

Memory deserves extra suspicion. Most cloud providers can see CPU from the hypervisor, but memory usage happens inside the guest OS, so it is often not collected unless you install a monitoring agent or enable it explicitly. When the memory graph is empty or missing, a CPU-only view makes a JVM service or cache node look like an easy downsize, until it starts swapping or gets OOM-killed. Treat missing memory data as "unknown," not "low."

Change one instance class at a time, starting with the least critical service. Before each change, write down the rollback step and the signal that triggers it, such as p99 latency, error rate or restart count. Then watch through a full cycle before moving on.

Be conservative with bursty workloads and with anything that deploys by running old and new versions side by side. Headroom absorbs bursts your measurement window may have missed. Without it, the first unusual spike can turn into latency spikes, OOM kills or a deploy that fails health checks.

Copy#!/usr/bin/env bash
# Pull 30 days of CPU and check for memory data before any right-sizing decision.
# Requires the AWS CLI and GNU date. Instance ID is a placeholder.
set -euo pipefail

INSTANCE_ID="i-0abc123def4567890"
START=$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)
END=$(date -u +%Y-%m-%dT%H:%M:%SZ)

# Hourly average and maximum. The maximum shows the batch and peak hours that an average hides.
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value="$INSTANCE_ID" \
  --start-time "$START" --end-time "$END" --period 3600 \
  --statistics Average Maximum \
  --query 'sort_by(Datapoints,&Maximum)[-5:].[Timestamp,Average,Maximum]' \
  --output table

# Memory is only visible if an agent inside the guest publishes it.
# The CWAgent namespace and metric name below are agent defaults; adjust if yours differ.
MEM=$(aws cloudwatch list-metrics \
  --namespace CWAgent --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value="$INSTANCE_ID" \
  --query 'length(Metrics)' --output text)

if [ "$MEM" = "0" ]; then
  # No memory data means the value is unknown, not low. Do not downsize on CPU alone.
  echo "Memory: UNKNOWN for $INSTANCE_ID. Install or configure the agent before deciding."
else
  echo "Memory metric found. Review its maximum over the same window before deciding."
fi

This shell script pulls 30 days of hourly CPU average and peak values for one EC2 instance with the AWS CLI, then treats a missing agent-reported memory metric as unknown instead of low.

Scheduling non-production environments and fixing storage defaults

Dev and staging environments usually run around the clock even though nobody uses them at night or on weekends. Scheduling them to stop outside working hours is one of the few changes that cuts cost without touching production.

Illustrative estimate: if a dev environment is needed 50 of the 168 hours in a week, running it only for those hours cuts its compute cost by about 70% (118 idle hours out of 168). Disks, snapshots and static IPs usually keep billing while instances are stopped, so the total environment cost falls by less than that.

The downsides are real. A fixed schedule slows developers in other time zones, who end up waiting for an environment to boot or keeping it running "just in case." Cold starts also fail in ways warm environments hide: expired credentials, migrations that ran while the environment was down, services that start in the wrong order. Each failure can cost an hour of debugging. Give engineers a self-service way to start an environment on demand, and run the startup path regularly so it doesn't rot.

Storage defaults

Object storage and logs grow quietly. Lifecycle policies that move objects to cheaper tiers by age and expire them after a set period stop that growth. Database backup retention deserves the same care. Choose it based on how far back you actually need to restore, not whatever the provider set by default.

Be careful when shortening retention. You can delete logs or backups that you later need for an incident investigation or an audit. Confirm compliance and forensic requirements before you expire anything.

Copy# Stop the dev namespace at 19:00 on weekdays. Workloads scale to zero; the\n# cluster autoscaler must remove the empty nodes before compute billing stops.\napiVersion: batch/v1\nkind: CronJob\nmetadata:\n  name: dev-stop\n  namespace: dev\nspec:\n  schedule: \"0 19 * * 1-5\"\n  timeZone: \"Europe/Berlin\"   # pick the team's main zone; others can start it on demand\n  jobTemplate:\n    spec:\n      template:\n        spec:\n          serviceAccountName: env-scheduler  # needs RBAC to patch deployments/scale in dev\n          restartPolicy: Never\n          containers:\n            - name: stop\n              image: registry.example.com/tools/kubectl:stable\n              command: [\"kubectl\", \"scale\", \"deployment\", \"--all\", \"--replicas=0\", \"-n\", \"dev\"]\n---\n# Start it again at 08:00. Running this path every weekday keeps cold starts tested.\napiVersion: batch/v1\nkind: CronJob\nmetadata:\n  name: dev-start\n  namespace: dev\nspec:\n  schedule: \"0 8 * * 1-5\"\n  timeZone: \"Europe/Berlin\"\n  jobTemplate:\n    spec:\n      template:\n        spec:\n          serviceAccountName: env-scheduler\n          restartPolicy: Never\n          containers:\n            - name: start\n              image: registry.example.com/tools/kubectl:stable\n              command: [\"kubectl\", \"scale\", \"deployment\", \"--all\", \"--replicas=1\", \"-n\", \"dev\"]

Two Kubernetes CronJobs scale every deployment in a dev namespace to zero on weekday evenings and back to one replica each morning, using a time zone set explicitly in the CronJob spec.

Hidden cost drivers right-sizing misses

Some of the largest line items never show up on an instance dashboard. They grow with how much data moves and how many requests run, not with vCPUs or memory, so right-sizing has no effect on them. To find them, group the bill by usage type or charge type instead of by service. Then look for line items that mention transfer, bytes processed, ingestion, or requests.

Illustrative estimate (assumed numbers, not a benchmark). Use this formula:

NAT cost = GB processed × per-GB rate

Assume private workloads pull 3,000 GB per month from object storage through a NAT gateway, at an assumed rate of $0.045 per GB:

3,000 × 0.045 = $135 per month

A private endpoint could remove most of that cost. Before you add one, check your provider's actual rates, including any fee for the endpoint itself.

When to use reserved capacity, and the alternatives

Once the bill has been cleaned up, what remains is your steady baseline: the compute and database capacity that runs around the clock regardless of traffic. That baseline is the only part worth committing to. Reserved capacity and savings commitments give you a lower rate in exchange for agreeing to pay for a fixed amount of usage over a fixed term. The provider gets predictable demand, and you get a discount.

The risk is that you pay whether or not you use it. Commit before cleanup and right-sizing, and you lock in waste at a discount. Commit and then migrate to a different instance family, move regions, or rebuild a service around containers or functions, and you may keep paying for capacity nothing runs on. Commitment types differ in how much flexibility they allow, so check what yours covers before you buy. If a major architecture change is planned during the term, cover less of the baseline or wait.

Impact on cost and engineering time, and guardrails that keep savings

Engineer hours belong in the same calculation as the cloud bill. On a small bill, a cleanup task can cost more in salary than it ever saves.

Illustrative estimate (assumed numbers, not a benchmark)

Payback (months) = (hours of effort × loaded hourly cost) ÷ monthly savings

• Assume a loaded engineer cost of $100/hour and 8 hours of work per task.
• Removing an unused $40/month test cluster: (8 × 100) ÷ 40 = 20 months to pay back.
• Right-sizing a $600/month database tier that is billed far above what it uses: (8 × 100) ÷ 600 ≈ 1.3 months.

Sort the bill by line item and work from the top. Once the remaining candidates have payback periods measured in years, stop.

Guardrails that keep savings from eroding

Waste usually returns gradually: a forgotten experiment, an untagged volume, a staging environment nobody scaled back down. Lightweight guardrails catch these early, while they are still cheap to fix.

• Budget alerts on forecasted spend. Forecast-based alerts give a warning partway through the month, instead of a surprise on the invoice.
• Required tags enforced in infrastructure-as-code. Make the plan or validation step fail if a resource is missing owner, env, or service tags. This makes every future idle-resource sweep a filter query rather than an investigation.
• A 30-minute monthly cost review with a named owner. One engineer, rotated quarterly, compares spend against the previous month and opens tickets for anything new in the top line items. Without a named owner, the review stops happening.

With these in place, a cleanup project like the one described in this article only needs to be done once.

How OneEnv can help

Disclosure: OneEnv is the product behind this blog.

OneEnv (oneenv.io) is a workspace-based governance platform for the things services share — environment variables, database structure, API routes and validation rules. A change to a shared value is staged on a branch, reviewed once, and then every affected service explicitly approves or rejects it before it goes live, so you can see who a change touches before it ships instead of finding out in production.

Applied to cloud cost optimization, this is where it helps:

Saves time

• Every service that inherits a shared value is listed in one place, so nobody searches repos and chats to find out who is affected.
• One review per branch replaces coordinating each team separately; each service still keeps its own approve/reject.
• Changing a shared variable is one edit and one review instead of editing every service's .env by hand.

Saves cost

• Fewer production incidents and rollbacks caused by a shared value, route or column changing under a consumer unannounced.
• Less duplicated configuration to maintain: one shared definition inherited by many services.
• A wrong or stale value is caught at review time by the services it affects, not by a failed deploy.
• OneEnv has a free plan (1 workspace, unlimited services and members, full governance), so trying it costs nothing.

These are qualitative benefits, not measured results — how much you save depends on how many services share the value.

Want to try it? Start at oneenv.io.