How to Reduce Cloud Costs: Practical Optimization Tips

The short answer

Cloud costs come down in a particular order — from simple and safe to things that require commitment:

1. Visibility: tags and reports so you know who spends what.
2. Cleanup: delete or stop what is not being used.
3. Rightsizing: size resources to real load.
4. Pricing model: reservations for steady load, spot for interruptible work.
5. Storage: lifecycle rules and log retention.

If you start with reservations, you may lock in payments for resources that later turn out to be unnecessary.

Visibility: tags

Without tags, a bill is a list of services, not an answer to "which project is getting more expensive". Agree on a minimal set:

• project — product or client;
• env — production, staging, dev;
• owner — team or responsible person.

In AWS, tags must be activated as cost allocation tags in Billing; after that you can group costs by them in Cost Explorer. Untagged resources are the first thing to check — they are often forgotten experiments. To keep the rules enforced, use tag policies and tag checks in your infrastructure code.

Cleaning up idle resources

Go through this checklist at least monthly:

• EBS volumes not attached to any instance;
• old snapshots and images nobody uses;
• unused public IP addresses;
• load balancers with no targets;
• stopped instances: you do not pay hourly for them, but their disks are still billed;
• test environments running at night and on weekends.

Dev and staging environments are easy to stop on a schedule — with the provider's scheduler or a simple cron job. If an environment is not needed for weeks, delete it and recreate it from code.

Rightsizing: size to load

Instances are often chosen "with headroom" and never revisited. Look at CPU, memory and network usage over several weeks, including peak days. If a resource is consistently underused, downsize it.

What helps:

• recommendations from AWS Compute Optimizer or its equivalents on other clouds;
• moving to newer instance generations and ARM, if your software supports it;
• autoscaling instead of keeping peak capacity running all the time.

Pricing model

Google Cloud and Azure have equivalents: committed use discounts, reservations and spot VMs. The rule is the same: reserve only the guaranteed minimum and cover peaks with on-demand or spot.

Storage and logs

Data accessed less and less often should move to cheaper storage classes and expire on schedule. In S3, a lifecycle rule does this:

{
  "Rules": [
    {
      "ID": "logs-archive",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration file://lifecycle.json

Adjust the periods to your requirements. Remember that "cold" classes have retrieval fees and minimum storage durations. And set retention on every log group: logs kept forever are a common hidden cost.

Common mistakes

• Buying reservations before resources are rightsized.
• Running workloads on spot that cannot survive a sudden stop.
• Deleting untagged resources without finding their owner.
• Optimizing once and never repeating the review.