Practical guide

FinOps guide: reduce your cloud costs

FinOps quick wins: budget alerts, autoscaling sizing, sleeping environments. A concrete action plan to optimise spending.

Cloud costs can explode quickly if you don’t pay attention. Often you only notice at the end of the month when the bill arrives. This guide gives you concrete actions to reduce costs right now without sacrificing performance. We’ve tested all of these methods and they really work.

Quick win #1: Set up budgets and alerts

Why it matters

If you don’t monitor costs, they can explode without you noticing. A script stuck in a loop, a forgotten instance, a misconfigured database… and your bill blows up.

How to do it

AWS:

  • Create a budget in AWS Budgets (free)
  • Configure alerts at 50%, 80%, and 100% of your budget
  • Receive automatic emails as you approach limits

GCP:

  • Use budgets and alerts in the GCP console
  • Configure alerts per project or per service

Azure:

  • Configure budgets in Cost Management
  • Create alerts per resource or per resource group

Tip: Start with a monthly budget based on your current spend, then adjust over time.

Quick win #2: Right-size instances

The problem

We often oversize instances “just in case.” Result? You pay for resources you don’t use. And it’s expensive.

How to identify oversized instances

AWS:

  • Use AWS Cost Explorer to view CPU/memory usage
  • AWS Compute Optimizer automatically suggests optimal sizes

GCP:

  • Use Recommender for right‑sizing suggestions
  • Check usage in Cloud Monitoring

Concrete actions

  • If CPU < 20%: Move to a smaller instance
  • If memory < 30%: Reduce RAM
  • If usage < 10%: Move to spot/reserved instances (up to 70% savings)

Concrete example: A t3.large (2 vCPU, 8GB RAM) using 15% CPU and 20% RAM can be replaced by a t3.small (2 vCPU, 2GB RAM). Savings: ~€50/month.

Quick win #3: Smart autoscaling

The problem

Many applications run with a fixed number of instances, even when load is low. Result? You pay for unused resources at night, on weekends, etc.

The solution: load‑based autoscaling

Configure autoscaling to:

  • Scale up: When CPU > 70% or memory > 80%
  • Scale down: When CPU < 30% and memory < 40% for 10 minutes
  • Min instances: 1 (or 2 for high availability)
  • Max instances: Based on your peak load

Example savings

Before: 4 instances 24/7 = 4 × €50 = €200/month

With autoscaling:

  • 1 instance at night/weekend (50% of the time) = 1 × €50 × 0.5 = €25
  • 2 instances during the day (30% of the time) = 2 × €50 × 0.3 = €30
  • 4 instances at peak (20% of the time) = 4 × €50 × 0.2 = €40

Total: €95/month instead of €200. Savings: €105/month (52%).

Quick win #4: Put environments to sleep

The problem

Dev/staging environments often run 24/7 even when nobody uses them. That’s money going up in smoke.

The solution

Option 1: Automatic shutdown

  • Stop dev/staging instances outside office hours (6pm–9am, weekends)
  • Use cron scripts or Lambda functions to automate
  • Savings: ~65% (if stopped 16h/day + weekends)

Option 2: Spot/reserved instances

  • Use spot instances for non‑critical environments
  • Savings: up to 70% vs on‑demand instances
  • Note: Spot instances can be interrupted, so not for prod

Quick win #5: Optimise storage

Quick actions

  • Delete old snapshots: Keep only the last 7 days
  • Archive old data: Move data > 30 days to cold storage (S3 Glacier, etc.)
  • Compress logs: Use compression to reduce storage space
  • Clean unused volumes: Delete EBS/Disks that are no longer attached

Example savings

Before: 500GB of logs at €0.10/GB = €50/month

After compression: 100GB at €0.10/GB = €10/month

Savings: €40/month (80%)

Quick win #6: Reserve instances (if you’re sure)

When to use Reserved Instances?

If you’re sure you’ll use an instance for at least 1 year, Reserved Instances can save up to 70%.

Options

  • 1 year, partial upfront: ~40% savings
  • 1 year, full upfront: ~50% savings
  • 3 years, full upfront: ~70% savings

Warning: Only reserve if you’re sure of the instance size and type. Otherwise, you risk paying for something you don’t use.

Action plan: where to start?

Week 1: Visibility

  • ✅ Set up budgets and alerts
  • ✅ Analyse current costs (per service, per project)
  • ✅ Identify biggest spend areas

Week 2: Quick wins

  • ✅ Sleep dev/staging environments
  • ✅ Clean snapshots and unused volumes
  • ✅ Compress logs

Week 3: Optimisation

  • ✅ Right-size instances
  • ✅ Configure autoscaling
  • ✅ Archive old data

Week 4: Advanced optimisation

  • ✅ Evaluate Reserved Instances (if relevant)
  • ✅ Optimise database queries
  • ✅ Review architecture (CDN, cache, etc.)

Recommended tools

  • AWS Cost Explorer: To analyse AWS costs
  • GCP Cost Management: To analyse GCP costs
  • Azure Cost Management: To analyse Azure costs
  • CloudHealth / CloudCheckr: Third‑party multi‑cloud solutions (paid but comprehensive)

In summary

Reducing cloud costs is possible and doesn’t necessarily take much time. Start with quick wins (budgets, sleeping environments, cleaning), then optimise progressively. The key is to start and measure impact.

Need help? If you want us to support you in optimising cloud costs, don’t hesitate to contact us. We’ll be happy to help!

Need help optimising your cloud costs?

We can support you with a cost audit and an optimisation plan.

Let's discuss your project