How to reduce AWS costs without disrupting operations

1. Orphaned resources: the easiest money to recover

Orphaned resources are AWS services that keep running and billing but no longer serve an active purpose. They are the natural result of months or years of operation without systematic cleanup.

The most common and costliest ones:

• Unused EBS snapshots: every disk snapshot you create for a backup sits there indefinitely without a retention policy. A mid-size company can accumulate hundreds of snapshots from months past. At $0.05/GB/month, 5 TB of old snapshots is $250/month that nobody notices.
• Unassociated Elastic IPs: AWS charges for elastic IPs you reserved but that are not attached to a running instance. It is $0.005/hour — $3.6 per IP a month, but 20 unused IPs is $72/month completely wasted.
• Detached EBS volumes: when you terminate an EC2 instance but forget to delete its disk volume, the volume keeps billing. At $0.10/GB/month for gp3, a detached 200 GB volume is $20/month.
• Load balancers with no targets: an Application Load Balancer costs roughly $16/month base plus $0.008 per LCU. If it stayed active after you deleted the instances or service it balanced, it keeps billing while doing nothing.
• Underused NAT Gateways: each NAT Gateway costs $0.045/hour ($32/month) plus $0.045 per GB processed. If you have one per subnet without needing high availability, you can reduce the count.

How to find them: AWS Trusted Advisor (free with Business Support or higher) has a “Cost Optimization” category that flags many of these resources automatically. You can also review them manually from the AWS console, filtering by region and state.

2. Rightsizing: pay for what you actually use

Rightsizing means matching EC2 instance and RDS database size to real consumption — not theoretical peak consumption. Most instances we see run at 10% to 30% average CPU. An instance averaging 15% CPU can usually move to an instance 50% smaller with no performance impact.

How to do it safely: use CloudWatch to review average and peak CPU, memory (via CloudWatch Agent), and IOPS over the last 2-4 weeks. If peak CPU in that window was 40%, dropping to the next instance size down is safe. If the peak was 80%, keep the current size or check whether inefficient code explains that spike.

The right process: changing instance type requires a restart (for EC2, in most cases). Plan it for a maintenance window, resize one instance at a time if several sit behind a load balancer, and monitor for 24 hours before moving to the next.

3. Savings Plans: the biggest saving with the least risk

Savings Plans are a minimum spend commitment on AWS (for example, “I commit to spending $200/hour on compute for 1 year”) in exchange for discounts of 20% to 66% off on-demand pricing. It is not a reservation of specific instances — it is a spend commitment that applies automatically to any eligible instance.

There are two main types:

• Compute Savings Plans: the most flexible. Applies to EC2 in any region, instance family, and operating system, plus Fargate and Lambda. Up to 66% off on-demand. Recommended if your architecture might evolve over the year.
• EC2 Instance Savings Plans: more restrictive (applies to a specific instance family in a specific region), but with a higher discount — up to 72% off on-demand. Useful for stable, predictable workloads that will not change instance family.

When to buy a Savings Plan: once you have at least 3 months on AWS and visibility into your stable baseline usage. The recommender in AWS Cost Explorer tells you exactly which plan to buy and how much you would save. Rule of thumb: buy Savings Plans to cover 70-80% of your baseline usage, and leave the rest on-demand to absorb variability.

4. S3: lifecycle rules and storage classes

S3 has multiple storage classes with very different prices depending on how often you access the data:

• S3 Standard: $0.023/GB/month — for frequently accessed data.
• S3 Standard-IA (Infrequent Access): $0.0125/GB/month — for data accessed less than once a month. 46% cheaper.
• S3 Glacier Instant Retrieval: $0.004/GB/month — for backups and files you rarely need. 83% cheaper than Standard.
• S3 Glacier Deep Archive: $0.00099/GB/month — for long-term retention. 96% cheaper than Standard.

The fix is configuring lifecycle rules: after 30 days, objects move to Standard-IA; after 90 days, to Glacier Instant Retrieval; after 365 days, to Deep Archive. This takes minutes to set up from the S3 console and requires no code changes.

Typical impact: a company with 10 TB in S3 Standard where 70% is old logs and backups can drop its S3 cost from $230/month to under $80/month with lifecycle rules alone.

5. Data transfer: the invisible cost that scales

Data transfer between AWS regions or out to the internet has a cost. The most common surprises:

• Inter-AZ transfer: moving data between Availability Zones within the same region costs $0.01/GB in each direction. If microservices that talk to each other frequently sit in different AZs, this scales fast. The fix can be private endpoints, or checking whether services that communicate often really need to be in different AZs.
• S3 to the internet without CloudFront: serving static files directly from S3 to the internet costs $0.09/GB out. With CloudFront (AWS's CDN), S3-to-CloudFront transfer is $0 within the same region, and CloudFront-to-user cost is lower at high volume.
• RDS Multi-AZ: synchronous replication between AZs in RDS Multi-AZ carries a transfer cost. This is inherent to the high-availability design and usually not optimizable — but worth knowing when you calculate the cost of HA.

The right order of attack

Not everything gets optimized at once. This is the order we use at CloudTing, from lowest to highest operational risk:

1. 1.Clean up orphaned resources — zero risk, immediate impact on the next bill
2. 2.Set up S3 lifecycle rules — configuration change, no impact on applications
3. 3.Buy Savings Plans — a financial commitment, but no technical changes
4. 4.Rightsize instances — requires a restart, do it in maintenance windows
5. 5.Optimize data transfer — may require architecture changes, plan it calmly