How to Cut Cloud Costs on AWS Without Killing Performance

Most cloud cost cuts fail because teams reach for the blunt instruments first: shutting things down, downgrading instances, and deleting resources without understanding traffic patterns. The reliable way to cut cloud costs on AWS without hurting performance is to attack waste in a specific order. Start with visibility, then right-size against real utilization data, then commit to discounts for stable baseline usage, and finally re-architect the small number of workloads that dominate your bill. Done in that sequence, you can typically remove 20 to 40 percent of spend while keeping or improving latency and availability.

This post walks through that sequence with concrete commands, queries, and decision rules you can apply this week.

Start With Visibility, Not Cuts

You cannot optimize what you cannot attribute. Before touching a single instance, make sure every dollar maps to a team, service, and environment.

Enforce a tagging standard

Pick a small, mandatory tag set and enforce it. I recommend at least:

• Environment (prod, staging, dev)
• Team (owning group)
• Service (application or component)
• CostCenter (for chargeback)

Enforce tags at creation time with a tag policy or an SCP, and backfill existing resources. Untagged spend is where waste hides.

Turn on the right data sources

Enable the Cost and Usage Report (CUR) and query it with Athena. The CUR is the ground truth; Cost Explorer is convenient but summarized. A simple query to find your top cost drivers by service:

SELECT
  line_item_product_code AS service,
  ROUND(SUM(line_item_unblended_cost), 2) AS cost
FROM cur.my_cur_table
WHERE line_item_usage_start_date >= DATE '2024-01-01'
GROUP BY line_item_product_code
ORDER BY cost DESC
LIMIT 15;

Nine times out of ten, three or four services account for the majority of the bill: EC2, RDS, S3, data transfer, and increasingly EKS or Lambda. Focus your effort there.

The Order of Operations for Cloud Cost Cuts

Attack spend in this order. Each step is lower risk and higher leverage than re-architecting, so exhaust the cheap wins first.

1. Delete waste (unattached volumes, idle load balancers, old snapshots).
2. Right-size against real utilization.
3. Commit to Savings Plans and Reserved Instances for the stable baseline.
4. Re-architect the few workloads that still dominate.

Step 1: Delete the obvious waste

This is money you are paying for nothing. Look for:

• Unattached EBS volumes and their snapshots.
• Idle Elastic IPs (AWS charges for unassociated addresses).
• Old, superseded snapshots with no retention policy.
• Load balancers with zero targets.
• Dev and staging environments running nights and weekends.

Find unattached volumes quickly:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

For non-production environments, schedule shutdowns. A dev fleet that runs 12 hours a day on weekdays uses roughly 60 hours a week instead of 168, a 64 percent reduction on those resources with zero impact on anyone. Use Instance Scheduler or a simple EventBridge rule plus Lambda to stop and start on a cron.

Step 2: Right-size against real utilization

Right-sizing is where performance fears usually kill good decisions. The fix is data. Do not resize on a hunch; resize on p95 and p99 utilization over at least two weeks, including your peak business cycle.

AWS Compute Optimizer gives you a starting list of over-provisioned instances with projected savings. Treat its recommendations as candidates, not commands. Validate against your own metrics:

• CPU utilization p95 below 40 percent for two weeks is a strong downsizing candidate.
• Memory matters too. The default CloudWatch agent does not report memory, so install the agent and collect it, or you will downsize into swapping.
• For RDS, watch CPUUtilization, FreeableMemory, and ReadIOPS/WriteIOPS. A database pinned on IOPS will not tolerate a smaller instance even if CPU looks idle.

Prefer moving to newer instance families before dropping size. Graviton-based instances (the g suffix, for example m7g versus m6i) frequently deliver better price-performance for workloads that run on ARM-compatible runtimes. Test first: rebuild your container images for arm64 and run them under load before cutting over production.

# Example: check that your image supports arm64 before migrating
docker manifest inspect myregistry/myapp:latest | grep architecture

Step 3: Commit to your stable baseline

Once your fleet is clean and right-sized, buy discounts for the usage you know is permanent. This is the single largest lever for most organizations, and it does not touch performance at all.

• Compute Savings Plans are the most flexible: they apply across EC2, Fargate, and Lambda regardless of instance family or region. Start here.
• Reserved Instances still make sense for RDS, ElastiCache, and OpenSearch, which are not covered by Compute Savings Plans.
• Cover the baseline, not the peak. Analyze your minimum steady-state usage over the trailing 60 to 90 days and commit to that level. Leave headroom on-demand so you never pay for reserved capacity you do not use.

A practical rule: commit to roughly 70 to 80 percent of your stable baseline on a one-year, no-upfront term first. That captures most of the discount while limiting your exposure while you keep optimizing. Move to three-year terms only for workloads you are certain will persist.

Step 4: Re-architect the workloads that dominate

After the first three steps, a small number of workloads usually still drive most of the bill. These deserve engineering time.

• Data transfer is a silent killer. Cross-AZ traffic, NAT Gateway processing charges, and inter-region replication add up. Use VPC endpoints for S3 and DynamoDB to avoid routing that traffic through NAT Gateways, and keep chatty services in the same AZ where availability requirements allow.
• S3 storage classes. Apply lifecycle policies to move infrequently accessed objects to S3 Infrequent Access or Glacier tiers. S3 Intelligent-Tiering automates this for unpredictable access patterns.
• Over-provisioned Kubernetes. On EKS, tune requests and limits to real usage, enable the Cluster Autoscaler or Karpenter, and use Spot capacity for fault-tolerant workloads.

# Right-sized resource requests prevent both waste and throttling
resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Spot Instances deserve special mention. For stateless, interruptible, or batch workloads, Spot can cut compute cost dramatically. The trade-off is possible reclamation, so design for it: handle the two-minute interruption notice, spread across instance types, and never put a stateful primary on Spot.

Protect Performance While You Cut

Cost work goes wrong when it degrades the customer experience quietly. Guard against that:

• Define SLOs before you cut. If your latency SLO is p99 under 300 ms, that number is your veto on any change.
• Change one variable at a time. Right-size or migrate families, then observe for a full business cycle before the next change.
• Load test in staging with production-shaped traffic before shrinking anything customer-facing.
• Set budget alerts and anomaly detection so a regression or a runaway job surfaces in hours, not at month-end.

This discipline is the difference between sustainable cloud cost savings and a rollback under pressure. If you want help operationalizing this as an ongoing practice rather than a one-off cleanup, our cloud and infrastructure capabilities cover FinOps tooling, tagging governance, and workload right-sizing. Cost profiles also differ sharply by sector, and our work across regulated and high-scale industries informs how aggressively you can use Spot, tiered storage, and multi-AZ trade-offs given your compliance and availability constraints.

Make FinOps a Habit, Not an Event

The organizations that keep their bills low do not do an annual cleanup. They build a lightweight FinOps loop:

• Weekly: review anomaly alerts and the top movers in the CUR.
• Monthly: review right-sizing candidates and Savings Plan coverage and utilization.
• Quarterly: revisit commitments as usage shifts, and reassess architecture on the biggest spenders.

Cost, like reliability, is a property you maintain, not a task you finish. Wire it into your existing engineering rituals and the savings compound instead of eroding.

FAQ

How much can I realistically save on my AWS bill?

Most teams that have not done structured optimization can remove 20 to 40 percent of spend through waste cleanup, right-sizing, and commitment discounts, without touching architecture. The exact figure depends on how much idle capacity and uncommitted on-demand usage you currently carry. Re-architecting high-cost workloads can add more, but requires engineering investment.

Will Savings Plans lock me into instance types that become outdated?

Compute Savings Plans do not. They apply your discount across EC2, Fargate, and Lambda regardless of instance family, size, or region, so you remain free to migrate to newer families like Graviton. Reserved Instances for services such as RDS are more specific, which is why shorter one-year terms are safer while your fleet is still changing.

Is right-sizing safe for production databases?

It can be, but only with data. Base decisions on p95 and p99 utilization across a full business cycle, and watch memory and IOPS, not just CPU. Databases are frequently constrained by IOPS or memory even when CPU looks idle, so validate all three metrics and test under production-shaped load before cutting over.

Should I use Spot Instances to reduce my AWS bill?

Use Spot for stateless, batch, or fault-tolerant workloads where interruption is acceptable. The savings are substantial, but you must design for reclamation by handling the interruption notice and diversifying across instance types. Do not run stateful primaries or latency-critical singletons on Spot.

What is the first thing I should do to start cutting costs?

Enable the Cost and Usage Report and enforce a mandatory tagging standard. Without attribution you cannot tell useful spend from waste, and every later decision becomes guesswork. Visibility first, then delete waste, then right-size, then commit, then re-architect.

Production-grade cloud, software, and engineering teams for scaling companies.