Cloud Cost Optimization: Cutting the Bill Without Cutting Corners

Cloud bills are rarely reviewed until they become a problem. A startup I worked with was paying $4,200 a month for infrastructure serving 800 monthly active users. Within six weeks, we had reduced that to $1,100 without touching the application code or degrading performance. The savings were entirely in how they were using the cloud, not what they were doing with it.

Cloud providers make money from complexity and inertia. The default choices are usually not the cost-optimized choices. Here is how I approach cost reduction systematically.

Start With a Cost Breakdown

Before optimizing anything, understand where the money is going. In AWS, open Cost Explorer and break down your bill by service and by resource. Most accounts have a Pareto distribution: 20% of resources account for 80% of cost. Find those resources first.

Common high-cost culprits:

EC2 instances that are oversized or running 24/7 unnecessarily
NAT Gateway data processing charges (frequently overlooked)
Data transfer between availability zones or regions
Unused Elastic IPs (charged when not attached to a running instance)
RDS instances oversized for their actual workload
S3 with no lifecycle policies accumulating data indefinitely
Elastic Load Balancers with no traffic

Enable AWS Cost Anomaly Detection. It uses machine learning to identify unusual spending patterns and sends you an alert before a surprise charge becomes a large surprise charge. Setup takes five minutes and has no cost.

Right-Sizing: The Most Impactful First Step

Right-sizing is matching your instance size to your actual workload. Most overprovisioned infrastructure got that way because someone guessed at requirements during initial setup, the application launched, and nobody revisited the sizing.

AWS Compute Optimizer analyzes your CloudWatch metrics and recommends optimal instance sizes. Enable it across your account. It costs nothing and produces savings recommendations within 14 days of activation.

Practically: an application server consistently running at 10% CPU utilization on a c5.xlarge is a candidate to move to a c5.large (half the cost). A database instance with 2GB of RAM usage on a db.r5.2xlarge (64GB RAM) is dramatically oversized.

Right-sizing requires monitoring your actual utilization. If you do not have CloudWatch metrics or application-level metrics showing CPU, memory, and I/O utilization over time, you are guessing. Set up basic monitoring first, then right-size after you have data.

Reserved Instances and Savings Plans

On-demand pricing — what you pay when you have not committed to anything — is the most expensive way to run EC2 instances. If you are running workloads that will be running in a year, Reserved Instances or Savings Plans save you 30-70% over on-demand pricing.

Reserved Instances lock you to a specific instance type and region for one or three years. The one-year commitment with no upfront payment saves roughly 30%. The three-year commitment with all upfront payment saves roughly 60%.

Savings Plans are more flexible — you commit to a dollar amount of compute spend per hour and AWS applies the discount across any instance type, OS, or region within the covered service. Compute Savings Plans cover EC2, Lambda, and Fargate. EC2 Savings Plans cover EC2 only but offer higher discounts.

I recommend Savings Plans over Reserved Instances for most teams because the flexibility means you are not locked to a specific instance type as your requirements evolve.

The key insight: identify your baseline compute spend — the floor of what you run every month regardless of traffic — and cover that baseline with Savings Plans. Keep on-demand capacity available for traffic spikes above the baseline.

Spot Instances for Non-Critical Workloads

Spot Instances are spare EC2 capacity sold at up to 90% discount. The catch: AWS can reclaim them with a two-minute warning. This makes them inappropriate for any workload that cannot tolerate interruption.

They are appropriate for: batch processing jobs, CI/CD build agents, data processing pipelines, development environments that stop at night, and application servers that are one of many in an auto-scaling group where losing one instance is handled gracefully.

Use spot instances for your CI runners. Your build times are identical, your cost is a fraction. In GitHub Actions, self-hosted runners on spot instances with auto-scaling can be cheaper than paying GitHub for compute minutes at any reasonable build volume.

NAT Gateway: The Hidden Cost

NAT Gateway charges are the most common surprise in AWS bills I review. The pricing model has two components: hourly charge per gateway ($0.045/hour) and per-GB data processing charge ($0.045/GB). In a busy account, NAT Gateway data processing charges can be substantial.

Common sources of high NAT Gateway costs:

Traffic between services in the same VPC routing through NAT Gateway unnecessarily. Use VPC endpoints for AWS services (S3, DynamoDB, SQS) — traffic to these services routes privately over the AWS backbone without going through the NAT Gateway. VPC endpoints have a flat hourly cost that is significantly cheaper than per-GB NAT Gateway processing for any meaningful data volume.

Resources in public subnets using NAT Gateway instead of their own public IP. If an EC2 instance in a public subnet has an Elastic IP, it routes through its public IP directly, not through NAT. Only private subnet resources need NAT Gateway.

Cross-AZ data transfer going through NAT Gateway. Route traffic between AZs directly over the internal VPC network where possible.

S3 Lifecycle Policies

S3 charges for storage ($0.023/GB/month for Standard), and many accounts accumulate data without any cleanup policy. If you keep logs, backups, or uploaded files indefinitely, your storage costs grow indefinitely.

Implement lifecycle policies on every S3 bucket:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_INSTANT_RETRIEVAL"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

Standard-IA (Infrequent Access) costs $0.0125/GB — about half of Standard. Glacier Instant Retrieval costs $0.004/GB. For data older than 30 days that you rarely access, the savings are immediate.

Application logs older than 90 days rarely need to be retrieved quickly. User-uploaded files that have not been accessed in a year may not need to exist at Standard tier. Review what each bucket contains and what retrieval time is acceptable for older objects.

Development Environment Cost Control

Development environments are frequently the source of unnecessary cloud spending. Developers provision resources for testing and forget about them. Resources run 24/7 when they are only needed for business hours.

Tag every resource with Environment: development (or similar). Create a scheduled AWS Lambda that stops all EC2 instances and RDS databases tagged as development at 7pm and starts them at 7am. Development resources running 10 hours a day instead of 24 reduces that cost by 58%.

Automate resource cleanup for development accounts. If a developer spins up an EC2 instance for testing and the instance is still running 14 days later, something is wrong. Create a Lambda that identifies and reports (or terminates) long-running untagged or development resources.

The Optimization Review Cycle

Cloud cost optimization is not a one-time project. Cloud bills change as your application evolves, traffic changes, and new resources are provisioned. Review your cost breakdown monthly. Run Compute Optimizer recommendations quarterly. Review and update Reserved Instance or Savings Plan coverage annually (or when your compute baseline changes significantly).

The goal is not the lowest possible bill — it is the most efficient use of cloud resources. Resources that are right-sized, properly committed, and actively managed are the output of a mature cloud operations practice.

If you want a cloud cost audit for your AWS account or help implementing a cost optimization strategy, book a session at https://calendly.com/jamesrossjr.