Articles

Cut AWS Costs: 12 Proven Strategies (2026)

April 16, 2026 7 min read

You’re probably thinking cutting AWS costs is all about deleting unused EBS volumes and stopping idle EC2 instances. That’s the low-hanging fruit, sure, but it’s like trying to save money on your electricity bill by turning off a single light switch in a mansion. The real savings come from understanding how AWS charges you and then systematically optimizing your architecture.

Let’s see it in action. Imagine you’re running a web application.

{
  "ResourceArn": "arn:aws:ec2:us-east-1:123456789012:instance/i-0abcdef1234567890",
  "ResourceType": "EC2:Instance",
  "Cost": "123.45",
  "UsageType": "BoxUsage:t3.medium",
  "Operation": "RunInstance",
  "StartDate": "2023-10-26T00:00:00Z",
  "EndDate": "2023-10-26T23:59:59Z",
  "Tags": [
    {"Key": "Environment", "Value": "Production"},
    {"Key": "Project", "Value": "WebApp"}
  ]
}

This single line from your AWS Cost and Usage Report (CUR) tells a story. It’s an EC2 instance, a t3.medium, running in us-east-1 for a full day, costing 123.45. But is it the right instance type? Is it running all day? Is it even needed?

Here are 12 strategies, from the obvious to the deeply impactful:

  1. Right-Size Your EC2 Instances: This is the foundational step. You’re likely over-provisioned. Monitor your instance utilization (CPU, memory, network, disk I/O) over a 2-4 week period. Tools like CloudWatch, or third-party tools, are your friends.

    • Diagnosis: Check CloudWatch metrics for CPUUtilization, MemoryUtilization (requires the CloudWatch agent), NetworkIn/Out, DiskRead/WriteOps. If average CPU is consistently below 20-30% and memory is also low, you’re likely over-provisioned.
    • Fix: Use the AWS Compute Optimizer or manually change the instance type. For example, if a m5.xlarge is consistently underutilized, downsize to a m5.large.
    • Why it works: You pay for the instance type, and larger instances have higher hourly rates. Matching instance size to actual workload demand directly reduces compute costs.

  2. Leverage Reserved Instances (RIs) and Savings Plans: For predictable, steady-state workloads, RIs and Savings Plans offer significant discounts (up to 72%) over On-Demand pricing.

    • Diagnosis: Identify EC2, RDS, ElastiCache, Redshift, or other instance-based services that have been running consistently for months. Look for high UsageType entries in your CUR like BoxUsage:t3.medium.
    • Fix: Purchase a 1-year or 3-year Standard or Convertible RI for EC2, or commit to a Savings Plan (Compute or EC2 Instance). For example, commit to $10/hour for compute usage for 3 years.
    • Why it works: You’re pre-paying for capacity or committing to a spending level, and AWS rewards that commitment with lower rates.

  3. Utilize Spot Instances: For fault-tolerant, flexible workloads (batch processing, big data analytics, CI/CD), Spot Instances can offer up to a 90% discount compared to On-Demand.

    • Diagnosis: Identify workloads that can tolerate interruptions. These are typically stateless applications or jobs that can be checkpointed and resumed.
    • Fix: Configure your Auto Scaling Groups or ECS/EKS services to use Spot instance pools. For example, in an Auto Scaling Group, set InstanceMarketOptions to Spot.
    • Why it works: You’re bidding on spare EC2 capacity. When AWS needs the capacity back, your instance is terminated (or hibernated/stopped if configured), but you only pay the Spot price.

  4. Optimize S3 Storage Classes: S3 has various storage classes, each with different pricing and access/retrieval fees. Don’t store infrequently accessed data in S3 Standard.

    • Diagnosis: Analyze S3 access patterns. Identify buckets or prefixes containing data that hasn’t been accessed in 30, 60, or 90 days.
    • Fix: Implement S3 Lifecycle policies. For example, transition objects older than 30 days to S3 Standard-IA (Infrequent Access), and objects older than 180 days to S3 Glacier Instant Retrieval or S3 Glacier Deep Archive.
    • Why it works: S3 Standard-IA and Glacier classes have lower storage costs per GB, though they may have higher retrieval fees or longer retrieval times. Lifecycle policies automate this transition.

  5. Delete Unused EBS Volumes and Snapshots: Orphaned EBS volumes and old snapshots are silent cost drains.

    • Diagnosis: Use the AWS CLI or console to list all EBS volumes and snapshots. Filter for volumes with a state of available and no Attachments. For snapshots, check their StartTime and look for snapshots not associated with any current volume or retention policy.
    • Fix: Detach and delete unused volumes. Delete old, unnecessary snapshots. aws ec2 delete-volume --volume-id vol-0123456789abcdef0 and aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0.
    • Why it works: You pay for provisioned EBS storage, whether it’s attached to an instance or not, and for every snapshot stored. Deleting them stops that charge.

  6. Use AWS Cost Explorer and Budgets: Proactive monitoring is key. Understand where your money is going and set alerts.

    • Diagnosis: Regularly review your AWS Cost Explorer reports, filtering by service, region, and tags.
    • Fix: Create AWS Budgets to track your spending. Set up alerts for when your actual or forecasted costs exceed a defined threshold (e.g., 80% of your monthly budget).
    • Why it works: Visibility allows you to identify cost anomalies early and take action before they become large. Budgets provide automated alerts.

  7. Optimize Data Transfer Costs: Egress traffic (data leaving AWS regions or going to the internet) is a significant cost.

    • Diagnosis: Review your CUR for high costs associated with DataTransfer-Out or NatGateway-BytesOutToInternet.
    • Fix: Use CloudFront for content delivery to cache data closer to users, reducing direct egress from EC2. Consider using VPC Endpoints for private communication between services within AWS, avoiding NAT Gateway charges. If transferring data between regions, use S3 Transfer Acceleration or specific region-to-region transfer optimizations.
    • Why it works: CloudFront charges are typically lower per GB than direct EC2 egress. VPC Endpoints use private IP addresses, bypassing NAT Gateways.

  8. Clean Up Idle RDS Instances and Snapshots: Similar to EC2, idle RDS instances and their automated snapshots incur costs.

    • Diagnosis: Identify RDS instances that are not being used or are in a stopped state (which still incurs storage costs for provisioned storage). Check for old, unneeded manual snapshots.
    • Fix: Delete unused RDS instances. If you need to stop an instance temporarily, consider taking a final manual snapshot and then deleting the instance. For automated snapshots, ensure retention policies are appropriate.
    • Why it works: You pay for provisioned RDS storage and instance uptime. Deleting unused resources stops these charges.

  9. Leverage Auto Scaling: Don’t keep your infrastructure sized for peak load 24/7. Scale out when demand is high and scale in when it’s low.

    • Diagnosis: Monitor average instance utilization during non-peak hours. If it’s significantly lower than peak hours, you can likely scale down.
    • Fix: Configure Auto Scaling Groups for EC2, ECS, or EKS based on metrics like CPU utilization, request count per target, or custom metrics. For example, scale out if average CPU > 70% and scale in if < 30%.
    • Why it works: You dynamically adjust your compute capacity to match demand, avoiding paying for idle resources during off-peak times.

  10. Choose the Right Region: Costs can vary significantly between AWS regions for the same service.

    • Diagnosis: Compare pricing for core services (EC2, S3, RDS) across different regions using the AWS Pricing Calculator.
    • Fix: If your application can tolerate it and latency isn’t a major concern, consider deploying resources in a lower-cost region. Be mindful of data transfer costs if users are geographically distant.
    • Why it works: AWS infrastructure costs (power, cooling, staffing) differ by location, leading to regional pricing variations.

  11. Optimize Lambda Function Performance and Configuration: While Lambda is pay-per-execution, inefficient functions can still rack up costs.

    • Diagnosis: Monitor Lambda function duration and memory usage. Identify functions that are consistently running longer than necessary or are allocated more memory than they need.
    • Fix: Optimize your code for faster execution. Adjust the memory allocation for your functions. For example, a function using 512MB of memory might perform identically to one using 256MB but cost twice as much.
    • Why it works: Lambda pricing is based on execution duration and memory allocated. Reducing either directly lowers costs.

  12. Review and Delete Unused Elastic IPs, Load Balancers, and NAT Gateways: These services incur charges even when not actively routing traffic.

    • Diagnosis: Use aws ec2 describe-addresses, aws elb describe-load-balancers, and aws ec2 describe-nat-gateways to find unattached or idle resources.
    • Fix: Release unassociated Elastic IPs. Delete unused Load Balancers and NAT Gateways.
    • Why it works: Elastic IPs have a small hourly charge when not associated with a running instance. Load balancers and NAT Gateways incur hourly charges and data processing fees.

The next thing you’ll likely run into is a surprise bill for egress traffic from CloudFront, or perhaps you’ll be wondering why your Savings Plans aren’t covering as much as you expected due to unpredictable bursts of usage.

Want structured learning?

Take the full Aws course →