How I Cut AWS Costs 70% for a DoD Contractor

Most cloud bills aren’t a pricing problem — they’re an architecture and governance problem. When I took over cloud strategy for a Department of Defense contractor, the AWS spend had grown faster than the workload. Here’s how we cut it 70% without a migration, a re-platform, or slowing the team down.

Start with the truth, not the dashboard

The first move is always the same: get an honest picture of where the money goes, not just how much. Cost Explorer and a tagging pass surfaced the usual suspects — idle and over-provisioned compute, forgotten environments, storage nobody owned, and data-transfer charges hiding in the architecture.

The single biggest lever is almost never the thing people expect. Here it was right-sizing plus killing waste, not a fancier reservation strategy.

The fixes that actually moved the number

Right-sized compute. Instances were provisioned for a peak that never came. Matching instance families and sizes to real utilization was the largest single win.
Killed zombie environments. Long-dead staging and one-off environments were still running 24/7. Automated teardown and schedules stopped paying for nights and weekends.
Fixed the data-transfer architecture. Cross-AZ and egress traffic was a silent tax. Re-homing chatty services and adding the right endpoints cut it sharply.
Storage lifecycle. Untiered S3 and orphaned EBS volumes got lifecycle policies and cleanup.
Commitment coverage last. Only after the workload was right-sized did Savings Plans / Reserved capacity make sense — buying commitments on a bloated baseline just locks in the waste.

Why cloud bills outgrow the workload

Before the fixes, it helps to understand why AWS spend drifts away from actual usage — because the same forces that inflated this contractor’s bill inflate almost every account I review. None of them are pricing problems. They’re organizational and architectural.

Provisioning is one-way by default. Engineers size for the worst case and rarely revisit it. An instance stood up for a launch that never spiked keeps billing at that size for years, because nobody is incentivized to walk it back.
Nobody owns the whole number. Spend is spread across teams and services, so no single person sees the total climbing. Cost becomes everyone’s background noise and no one’s responsibility.
The defaults are expensive. Log retention set to “forever,” on-demand everything, cross-AZ chatter, no lifecycle policies — the path of least resistance in AWS is also the pricier one.
Growth hides waste. When revenue is climbing, a rising cloud bill looks like a healthy cost of doing business. That’s exactly when the ratio of spend to value quietly rots.

Naming these forces matters because the durable fix isn’t a single cleanup — it’s changing the conditions that let the bill drift in the first place. That’s why governance, later in this piece, matters as much as the technical fixes.

How to reduce AWS costs: the order that works

The reason most cost-cutting efforts stall is that teams start with the lever that feels financial — buying Reserved Instances or Savings Plans — before they’ve fixed the workload underneath. That locks waste in for one to three years. The sequence that actually compounds is the opposite:

Measure honestly. Turn on Cost Explorer, enforce a tagging pass, and attribute spend to teams, environments, and services. You can’t cut what you can’t see, and unowned cost is where waste hides.
Delete what nobody uses. Idle instances, forgotten staging stacks, orphaned EBS volumes, unattached Elastic IPs, old snapshots. This is the fastest money and it carries almost no risk.
Right-size what remains. Match instance families and sizes to real utilization, not the peak someone imagined at provisioning time. Move bursty workloads to the instance types built for them.
Schedule non-production. Dev, test, and staging rarely need to run nights and weekends. Automated start/stop schedules routinely cut those environments by well over half.
Fix the data-transfer architecture. Cross-AZ chatter, NAT gateway egress, and inter-region traffic are silent taxes. Re-home chatty services and add VPC endpoints where they pay off.
Tier your storage. Lifecycle policies move cold S3 data to cheaper classes automatically; unattached and over-provisioned block storage gets cleaned up.
Commit last. Only once the baseline is lean do Savings Plans and Reserved Instances make sense — now you’re buying commitments on real steady-state usage instead of on bloat.

Follow that order and the early steps often fund themselves before you ever negotiate a commitment.

Where AWS waste actually hides

Across most accounts, the same categories account for the bulk of overspend. If you’re hunting for your own savings, start here:

Over-provisioned compute. The most common single line item — instances sized for a peak that never arrives, or a load test from a year ago.
Zombie environments. Staging and one-off environments that outlived their purpose and still bill 24/7.
Idle and orphaned storage. Unattached EBS volumes, stale snapshots, and S3 buckets with no lifecycle policy quietly compounding.
Data transfer. Cross-AZ and egress charges that don’t map to any obvious resource, so nobody owns them.
Managed-service sprawl. Over-provisioned databases, oversized caches, and log retention set to “forever” by default.
Missing commitment coverage — after right-sizing. Steady-state workloads running fully on-demand once utilization is genuinely stable.

Reserved Instances vs Savings Plans: which to use?

Once your baseline is lean, the question becomes how to commit. The short version: Savings Plans are the better default for most teams because they apply flexibly across instance families, sizes, and (for the compute plan) even across EC2, Fargate, and Lambda. Reserved Instances lock you to a specific configuration in exchange for slightly deeper discounts and, for standard RIs, the ability to sell them on the marketplace.

A practical rule of thumb: cover your predictable, always-on baseline with a one-year commitment, keep some headroom on-demand for growth and experimentation, and only reach for three-year terms on workloads you’re genuinely confident will still exist. The exact discount varies by service and term, but the strategic point holds — commit to the floor, not the ceiling, and never commit before you’ve right-sized.

Governance so it stays cut

A one-time cleanup that isn’t defended creeps right back. We added the guardrails that keep it down: mandatory tagging, budgets and anomaly alerts, and a monthly cost review with an owner. The point isn’t to nag engineers — it’s to make cost visible at the moment decisions get made.

Cost optimization in regulated and DoD environments

Optimizing a defense contractor’s AWS bill adds a constraint most cost guides skip: you can’t cut anything that weakens compliance. In a regulated environment — GovCloud, CMMC, FedRAMP, or similar — a few rules kept the savings clean:

Right-sizing never touches the control boundary. You can shrink an instance or schedule a non-prod environment without changing what data lives where or who can reach it. Those are the safe levers, and they’re where most of the money is.
Audit logging is not a cost to trim. Log retention that satisfies a compliance requirement stays, even when it’s tempting on a cost dashboard. You optimize storage class and lifecycle, not the existence of the record.
Data residency shapes the data-transfer fix. Re-homing services to cut cross-AZ and egress charges has to respect region and boundary constraints. The architecture gets cleaner, but never at the expense of where regulated data is allowed to sit.
Change goes through governance. In a controlled environment, teardown and right-sizing run through documented, reviewable change — which, conveniently, is also what keeps the savings from silently creeping back.

The reassuring part: compliance and cost discipline pull in the same direction. Tagging, ownership, least-privilege access, and documented change management are exactly the guardrails a regulated program already wants — and exactly what makes cost visible and defensible at the same time.

The takeaway for founders

If your AWS bill is scaling faster than your revenue, you almost certainly have 30–60% of savings sitting in architecture and waste — before you ever touch pricing tricks. The order matters: right-size and fix the architecture first, then commit.

Frequently asked questions

How much can you realistically save on AWS? It varies by workload, but most accounts that have never been through a deliberate optimization pass have 30–60% of savings sitting in architecture and waste before any pricing tricks. Deeper cuts — like the 70% in this case — come from combining right-sizing, killing zombie environments, fixing data-transfer architecture, and only then layering on commitments.

What is the fastest way to cut an AWS bill? Delete what nobody uses. Idle instances, forgotten staging environments, orphaned EBS volumes, and untiered storage are near-zero-risk cuts you can make in days. Right-sizing over-provisioned compute is the next fastest lever and usually the single largest one.

Should I buy Reserved Instances or Savings Plans first? Neither — not until you’ve right-sized. Buying commitments on a bloated baseline locks in the waste for one to three years. Fix utilization and architecture first, then cover your stable, always-on baseline with a commitment, favoring Savings Plans for their flexibility across instance families and services.

Do I need to re-platform or migrate to cut cloud costs significantly? Usually not. In this case the 70% reduction came with no migration and no re-platform. Most large savings live in right-sizing, waste removal, data-transfer fixes, and governance — architecture and discipline changes that don’t require rebuilding your stack.

How do you keep AWS costs from creeping back up? Governance. Mandatory tagging, budgets and anomaly alerts, and a monthly cost review with a named owner make spend visible at the moment decisions get made. A one-time cleanup that isn’t defended always creeps back; the guardrails are what keep the number down.

If you want to know your number, I run a fixed-scope AWS Cost & Architecture Review — you see the savings before you commit to anything.