Cloud Cost Optimization Best Practices That Work

The Real Source of Cloud Waste

Most cloud bills do not spiral out of control because of one massive architectural mistake. They grow through hundreds of quiet, unmanaged decisions: an over-provisioned Kubernetes node pool left running over the weekend, an unattached EBS volume forgotten after a database migration, or a staging environment running 24/7 without a teardown schedule.

When I audit client infrastructures at techsolss, I rarely find that teams lack cloud knowledge. What they lack is an operational cadence for cost hygiene. Saving money in AWS, Azure, or GCP isn't a one-time project you check off; it requires built-in guardrails, automated scheduling, and architectural discipline.

Here are the hands-on cloud cost optimization best practices I rely on in production environments to slash monthly spend by 30% to 50% without risking uptime.

1. Tagging Enforcement via Infrastructure as Code

You cannot optimize what you cannot attribute. If your monthly AWS bill features $4,000 in untagged ec2:run-instances charges, finance cannot route those costs back to the product teams that generated them.

Stop relying on manual tagging policies. Enforce mandatory resource tagging at the Infrastructure as Code (IaC) level using Terraform or OpenTofu. Better yet, use Sentinel or OPA (Open Policy Agent) to fail CI/CD pipelines if required tags like Environment, Owner, and CostCenter are missing.

Here is a simple Terraform local variable pattern that injects standard tags across all resources:

locals:
  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
    CostCenter  = "Engineering-Core"
    Owner       = "[email protected]"
  }
}

resource "aws_instance" "app_server" {
  ami           = var.ami_id
  instance_type = "t3.medium"

  tags = merge(
    local.common_tags,
    {
      Name = "Production-API-Server"
    }
  )
}

If you are evaluating whether to migrate your workloads or shift them into containerized architectures to better manage resource utilization, reviewing how to migrate a SaaS to Kubernetes can help you weigh the long-term infrastructure savings against migration overhead.

2. Right-Sizing Compute Through Prometheus and Metrics

Developers naturally over-provision compute out of caution. If a microservice peaks at 1.8 cores under stress, the default reaction is to provision a 4-core instance "just in case."

Stop guessing instance sizes. Pull actual utilization metrics from Prometheus or AWS CloudWatch Container Insights over a rolling 14-day window. Look at P95 CPU and memory utilization, not averages.

• If CPU stays below 15% and memory below 40% for two weeks, step down the instance family (e.g., from c6i.xlarge to c6i.large).
• Evaluate Graviton (ARM) processors. Moving our standard Linux workloads from Intel/AMD to AWS Graviton3 instances often yields a 20% price-performance improvement with zero code changes, provided your dependencies have native ARM builds.

3. Automating Non-Production Shutdowns

Staging, QA, and development environments rarely need to run 168 hours a week. If your developers work 40 hours a week, running dev clusters 24/7 means you are paying for 128 hours of idle compute weekly—amounting to roughly 75% waste on non-prod bills.

Implement automated cron-based scaling or shutdowns using AWS Lambda or KEDA (Kubernetes Event-driven Autoscaling). For Kubernetes clusters, tools like kube-ops-runner or simple GitHub Actions can scale down deployments at 7:00 PM local time and scale them back up at 8:00 AM.

Here is a lightweight GitHub Actions workflow to stop non-prod EC2 instances on Friday evening:

name: Stop Staging Instances

on:
  schedule:
    - cron: '0 19 * * 5' # Every Friday at 19:00 UTC

jobs:
  stop-ec2:
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Stop Instances
        run: |
          aws ec2 stop-instances --instance-ids i-0123456789abcdef0

4. Aggressive Lifecycle Policies for Storage and Backups

Storage costs are insidious because they compound monthly. EBS snapshots, S3 object versions, and RDS backups accumulate silently.

• S3 Lifecycle Rules: Transition raw logs and analytical dumps from S3 Standard to S3 Standard-Infrequent Access (IA) after 30 days, and transition them to Glacier Flexible Retrieval after 90 days.
• Prune EBS Snapshots: Ensure automated backup tools do not retain daily snapshots indefinitely. Set a retention policy where daily backups expire after 7 days, weekly backups after 4 weeks, and monthly backups after 12 months.
• Delete Unattached Volumes: Write a weekly Lambda function that scans for EBS volumes in available (unattached) state and sends a Slack alert or auto-snapshots and terminates them after 7 days.

5. Spot Instances and Savings Plans Strategy

Commitments can lock you into savings, but they can also trap you if your architecture changes. Build a balanced commitment strategy:

1. Cover baseline load with 1-Year Savings Plans: Only commit to Compute Savings Plans for your absolute floor—the baseline resources that run 365 days a year regardless of business cycles.
2. Use Spot Instances for Stateless Workloads: CI/CD runners, batch data processing, rendering nodes, and stateless API pods behind a load balancer are prime candidates for AWS Spot or GCP Preemptible VMs. Spot instances offer up to 90% discount. Ensure your applications handle SIGTERM gracefully so they can drain connections when interrupted.

If your team is lean and you need senior guidance to implement these guardrails without slowing down feature delivery, exploring a fractional DevOps vs full-time hire model can give you enterprise-grade cost governance on a startup budget.

Build Cost Awareness into Engineering Culture

Cloud optimization fails when it is treated exclusively as a finance department problem. Engineers need to see the cost impact of their infrastructure pull requests. When developers understand that spinning up an unoptimized database cluster adds $300 a month to the burn rate, architectures naturally become more efficient.

If your cloud bill is growing faster than your revenue and you want an experienced set of eyes to review your architecture, contact techsolss to discuss your infrastructure.

***

Ready to get your cloud infrastructure under control? Book a 20-minute architecture and cost review call with me to identify your immediate low-hanging fruit for savings.

FAQ

What is the fastest way to reduce cloud costs in AWS?

The fastest wins usually come from identifying unattached EBS volumes, stopping non-production environments during nights and weekends, and right-sizing over-provisioned EC2 or Kubernetes node instances based on actual Prometheus metrics.

Should my team use 1-year or 3-year Savings Plans?

Stick to 1-year Compute Savings Plans. Technology stacks and architectural requirements change too rapidly in modern software development to justify locking your organization into a 3-year pricing contract.

How can I prevent developers from spinning up expensive instances?

Enforce Infrastructure as Code (IaC) via Terraform, implement automated policy checks using tools like OPA (Open Policy Agent) in your CI/CD pipeline, and mandate resource tagging so every cost can be traced back to a specific team.

Related reading

• techsolss
• migrate a SaaS to Kubernetes
• fractional DevOps vs full-time hire
• contact techsolss

[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Cloud Cost Optimization Best Practices That Work",
    "author": {
      "@type": "Person",
      "name": "Muhammad Ramzan"
    },
    "publisher": {
      "@type": "Organization",
      "name": "Techsolss"
    },
    "datePublished": "2026-08-10",
    "mainEntityOfPage": "https://techsolss.online/posts/cloud-cost-optimization-best-practices-that-work.html"
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "What is the fastest way to reduce cloud costs in AWS?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "The fastest wins usually come from identifying unattached EBS volumes, stopping non-production environments during nights and weekends, and right-sizing over-provisioned EC2 or Kubernetes node instances based on actual Prometheus metrics."
        }
      },
      {
        "@type": "Question",
        "name": "Should my team use 1-year or 3-year Savings Plans?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Stick to 1-year Compute Savings Plans. Technology stacks and architectural requirements change too rapidly in modern software development to justify locking your organization into a 3-year pricing contract."
        }
      },
      {
        "@type": "Question",
        "name": "How can I prevent developers from spinning up expensive instances?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Enforce Infrastructure as Code (IaC) via Terraform, implement automated policy checks using tools like OPA (Open Policy Agent) in your CI/CD pipeline, and mandate resource tagging so every cost can be traced back to a specific team."
        }
      }
    ]
  }
]