Practical Cloud Cost Control: Insights and Strategies

When it comes to AWS, those tiny cents can quickly balloon into dollars — and if you’re not paying attention, you might end up burning through your cloud budget faster than you can say “re:Invent.” Below is a collection of practical (and occasionally quirky) techniques to keep your AWS bill in check and ensure you focus your resources on what truly matters: delivering awesome features.

The Problem

Hidden Costs

AWS pricing might look like nickels and dimes at first, but that’s exactly where the trouble starts. “Oh, it’s just a few cents per GB,” you think — until you find out you’ve got hundreds of GBs, or even TBs, adding up across services you barely remember setting up. Always keep a watchful eye on your actual usage and unit costs.

Feature Development vs. Cost Management

We all love rolling out new features, but cost management gets left behind all too often. It’s not nearly as fun to pour over usage metrics and billing dashboards, but ignoring it can quickly overshadow the excitement of your latest product release. Make cost consciousness a part of your development cycle from the start.

The Illusion of Cents Pricing

AWS loves to showcase low per-unit pricing. One penny, half a penny — heck, some services are even free for the first million requests. That’s great for prototyping, but once your application scales, these “pennies” can quietly become significant line items.

Product/Feature Adoption

Investing in features that no one is using is like renting extra storage for furniture you don’t even own. Before you pile on new features, ask whether your users really need them and evaluate their ongoing cost to maintain.

Most Common Ways to Save Money

Savings Plans / Reserved Instances

If you have consistent workloads — like production databases or always-on compute — Savings Plans or Reserved Instances can offer substantial discounts. Just be sure you’re comfortable with the commitment. Locking in a one- or three-year term is great if your workload is stable, but it’s painful if your usage changes drastically midway through.

Autoscaling

Use Autoscaling whenever possible to handle variable loads. If your traffic isn’t 24/7 flat, there’s no reason to keep capacity running at peak levels around the clock. Let your infrastructure breathe — scale up during busy times and scale down during quiet hours.

Tagging

AWS tags are the breadcrumbs that help you see exactly where your money is going. Without thorough tagging (by team, environment, application, etc.), you can easily lose track of spending across multiple accounts and services. Treat tags like required fields, not optional extras.

Rightsizing

Every so often, revisit your EC2 instance types, EBS volumes, and database sizing. Don’t just pick “m5.xlarge” or “db.t3.large” out of habit. Overprovisioned resources might feel safer, but they’re not so safe for your wallet.

Six Not-So-Common Ways to Save Money

Now let’s venture beyond the usual suspects. These six methods often fly under the radar but can deliver notable savings.

1. “Moving Out”

Amazon S3 might be the default choice for object storage, but consider what you’re really paying for:

• S3 General Purpose: ~$23/TB

• Glacier: ~$4/TB

• Hetzner Cloud (Hot Storage): ~$1.5/TB

Then there’s the outgoing traffic cost:

• AWS egress: ~$90/TB

• That means ~$300k/year for 1PB egress!

If your data is primarily static or archival, it might be worth looking into cheaper storage providers (though always weigh the hidden costs like migration, durability, and SLA differences). A really useful site for price comparison is https://www.s3compare.io/.

2. “Loose Ends”

Nothing kills your budget vibe quite like NAT Gateway charges. NAT Gateways typically cost around $30/month plus $0.045/GB of data processed. By contrast:

• Interface Endpoints: $7/month + $0.01/GB

• Gateway Load Balancer Endpoint: $7/month + $0.0034/GB

• Resource Endpoint: $14/month + $0.01/GB

Where appropriate, switch to these endpoints for traffic that stays within AWS. Keep your private traffic truly private.

3. “Clock-Out”

Do your non-production environments really need to run 24/7? If your dev environment sees only about 50% utilization on workdays and nearly 0% on weekends, it’s idle for 19 out of 30 days (a whopping 63%). Suspended or hibernated resources don’t cost you for compute. Schedule them to sleep when nobody’s coding.

4. “Sunset”

According to a 2024 study by Userpilot, 75% of software features go unused. That’s a lot of leftover code. Audit your features and deprecate those that no one’s using. By simply archiving a piece of code from your repository you get:

• Improved build times

• Faster tests

• Smaller Docker images

• Less maintenance

• Reduced attack surface

Less baggage also translates to lower hosting costs and a leaner pipeline.

5. “Less Is More, Unless It’s Server”

Lambda vs. EC2 is often framed as “serverless is cheaper,” but that’s not always true. For constant, high throughput workloads, a properly sized EC2 instance can be more cost-effective than paying for millions of Lambda invocations. For instance:

• ~5M requests/day with AWS Lambda (100 ms, 512MB) costs about $150/day

• A t3.xlarge EC2 instance might run closer to $121/day (24/7)

For infrequent or bursty workloads, Lambda is probably your friend. But if you’re constantly busy, an EC2 instance might be the better deal. Either way, factor in high availability and load balancing to maintain reliability. There’s no break-even point between the two. You can’t (or better yet shouldn’t) go all-in on serverless or all-in on on-demand. Identify which parts of your software are suitable for serverless runners and which ones require EC2s.

6. “Clean-Up”

Spinning up resources is easy; cleaning up is often forgotten. Make a habit of housekeeping:

• EBS Snapshots: Old snapshots can clutter up your bill.

• Elastic IPs: Release unused IPs.

• RDS Snapshots: Automated backups can stack up quickly.

• CloudWatch:

• Metrics: $0.30/mo

• Alarms: $0.10/mo

• Logs: $0.50/mo

• Dashboards: $3/mo

Keep in mind that every instance/task/resource you create comes with predefined alarms to facilitate autoscaling. So, over time, these small figures accumulate. Stay on top of them.

Real-World Use Cases from Our Company

Cutting down your AWS bill looks great on paper, but what happens when you put these strategies into action? Here are three real-world scenarios — spanning from small startups to full-scale enterprise — where targeted optimizations made a big difference.

Use Case 1: Startup

Project Overview:

• Type: Greenfield project (started 3 years ago)

• Purpose: A scalable marketplace platform for staffing solutions

• Environments: Dev, Stg, Prod

• MRR: < $5k

Tech Stack:

• Compute: 1 ECS cluster × 4 services × 3 tasks

• Serverless: Lambdas

• Storage: S3

• Databases: RDS (PostgreSQL & SQL Server)

• Data Migration: DMS

Cost Saving Strategies Applied:

• Revising lifecycle policies: Optimized ECR and S3 storage by implementing strict cold archiving rules, reducing the amount of data stored on higher-cost tiers.

• Cleaning up resources: Removed orphaned EBS/RDS snapshots and decommissioned unused EC2 and RDS instances.

• Eliminating waste: Turned off extended support for AWS services that weren’t being actively used (like certain analytics add-ons).

Result:

• 50% reduction in AWS costs. Not too shabby for a small but growing team!

Use Case 2: Scaleup

Project Overview:

• Founded 9 years ago

• Logistics/last-mile delivery services

• MRR: < $100k

• 5 environments

• 3 for software development lifecycle (with 2 “subenvironments” used for sandbox and testing)

• 2 for production

Tech Stack:

• 7 Kubernetes (EKS) clusters

• Ruby on Rails monolith backend

• Golang microservices

• Helm charts, GitHub Actions, and ArgoCD for deployments

• RDS, Neon (Postgres), Elasticsearch, Elasticache, and Kafka for data storage

• Prometheus, Thanos, OpenTelemetry, Tempo, and Grafana for observability

Cost Saving Strategies Applied:

• Problem: Ephemeral sandbox environments were active 24/7, incurring costs even when no one was using them.

• Challenges: Different time zones and unpredictability meant environments could not be easily scheduled to shut down.

• Solution: Leveraged Keda, Prometheus, Istio, and Karpenter to detect traffic within a certain time window. If a subenvironment idles past that window, it “sleeps.” This approach merges the best of autoscaling with usage-based triggers.

Result:

• 55% reduction in non-prod environment costs, freeing up budget for actual production needs.

Use Case 3: Enterprise

Project Overview:

• MRR: < $1.5M

• Ad-tech company

• 4 AWS regions

• ~60M requests/min

• 3 environments (dev, stage, prod)

Tech Stack:

• Fargate, EC2, Spot

• Lambdas

• S3

• RDS (PostgreSQL)

Cost Saving Strategies Applied:

• Switch from ALB to NLB

• Switch from NLB to self-managed LB (on EC2)

• Remove NAT gateways

• Adaptive and aggressive auto-scaling

• Strict IaC control

Result:

• **10%**increase in AWS costs while DOUBLING traffic and project scale over 2 years.

Why is this still a win? Because cost increases aren’t always bad if your usage is growing even faster. In this case, they handled massive traffic growth effectively, and the spend relative to the increased demand actually went down in cost-per-request terms. That’s still a mark of success.

Wrapping Up

AWS cost management isn’t a one-and-done activity — it’s a continuous process. By adopting a tagging strategy, scaling intelligently, and always challenging your default assumptions about storage and compute, you can maintain a lean, mean cloud environment without sacrificing performance.

Stay curious, keep an eye on the details, and remember: while AWS’s “pay as you go” model is incredibly powerful, it’s just as easy to pay for things you never actually use. Embrace a culture of cost awareness, and your balance sheet will thank you in the long run.