Cloud 7 min read

Cloud Costs Under Control: FinOps Strategies for SMEs

FinOps for mid-market companies: Reserved Instances, right-sizing and tagging cut cloud costs by 25 percent. Hands-on guide with code examples.

Cloud Costs Under Control: FinOps Strategies for SMEs

Cloud infrastructure saves time and money, in theory. In practice, we see the same pattern repeatedly: companies start small on AWS or Azure, scale successfully, and suddenly face bills that surprise them with three-digit monthly costs. Often, 30 to 40 percent of those costs are waste created by lack of visibility and missing optimization discipline.

FinOps (Financial Operations) is not a new technology but an organizational principle: engineering, finance, and operations work together to control cloud spending without stifling innovation. For SMEs, this means concretely: with the right tools and processes, you can achieve 20 to 30 percent cost savings, often without major architecture overhauls.

Common Pain Points in SMEs

The typical cost problems we encounter in customer projects follow a pattern:

Uncontrolled scaling: developers spin up test instances on large machines and forget about them. Six months later, an app runs on an m5.2xlarge that never exceeds 5 percent utilization. Multiply that across a dozen projects and you quickly hit five-figure waste.

Missing resource tagging: without clear tags, nobody knows which business unit, project, or customer owns which infrastructure. Finance can’t allocate costs, and engineering won’t optimize because costs aren’t visible at all.

Oversized standard instances: many teams choose the same size across the board, often “better safe than sorry,” even when actual load would justify a smaller instance type.

No use of reservations: Reserved Instances save massively at AWS and Azure, 30 to 70 percent, but teams avoid them due to “commitment anxiety.”

Sizing Reserved Instances Correctly

Reserved Instances are a strong lever but require thoughtful planning. Blindly committing for three years locks you into costs if requirements change.

The approach:

  1. Analyze average on-demand usage over the last 12 months (AWS Cost Explorer, Azure Cost Analysis)
  2. Account for volatility: only reserve resources used consistently over time (databases, baseline web tier instances)
  3. Start with a 1-year reservation, not a 3-year commitment
  4. Review regularly: are these instances still current? Have patterns shifted?

Real numbers from a customer project: a mid-market SaaS provider with an average of 8 m5.large EC2 instances paid roughly 800 euros monthly on-demand. With a 1-year reservation, the price dropped to 500 euros, saving 300 euros per month or 3,600 euros annually. Scaled across all similar workloads, this customer achieved total savings of about 25 percent.

AWS Cost Explorer shows RI coverage and offers a “Recommendations” section with reservation candidates:

aws ce describe-cost-and-usage \
  --time-period Start=2025-01-01,End=2026-01-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter file://filter.json \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE

Right-Sizing: Uncovering Wasted CPU and RAM

Right-sizing means reducing instances to their actual required size. A simple indicator to watch: CPU utilization. If an instance averages under 20 percent CPU utilization, it’s oversized.

Tools for analysis:

  • AWS Compute Optimizer: free, analyzes CloudWatch metrics over 14 days and suggests smaller instances. Enable it and review recommendations regularly.
  • Azure Advisor: similar for Azure, analyzes CPU, memory, and disk utilization.
  • CloudHealth (VMware): for multi-cloud environments if you work on AWS and Azure simultaneously.

A concrete example: a microservice ran on a t3.xlarge with 10 percent average CPU and 15 percent RAM. Switching to t3.small cut costs by 80 percent, from roughly 50 euros to 10 euros monthly, while performance and reliability stayed the same. Across a portfolio of 30 similar services, that’s 1,200 euros monthly in savings.

Tagging Strategy as Foundation

Without structured tagging, FinOps operates blind. Tags let you trace costs back to business units, projects, environments (dev/staging/prod), or cost centers.

Minimal tagging schema for SMEs:

Tags:
  - Name: Environment
    Values: [prod, staging, dev]
  - Name: Project
    Values: [customer-portal, internal-tools, data-pipeline]
  - Name: CostCenter
    Values: [engineering, marketing, ops]
  - Name: Owner
    Values: [team-name]
  - Name: CreatedBy
    Values: [automation-script, manual, terraform]

Enforcement: tags must be mandatory. AWS Service Control Policies (SCPs) can prevent resources from being created without specific tags. With Terraform or Pulumi, you can use code policy tools like OPA or Snyk.

Example of an AWS SCP that prevents launching instances without a “Project” tag:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["ec2:RunInstances"],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Project": "true"
        }
      }
    }
  ]
}

With meaningful tags, you get automatically generated cost breakdowns by project, team, and environment each month. This creates visibility and motivates ownership.

Automated Cost Analysis with Infracost

Infracost brings FinOps into the developer pipeline: before merge requests are approved, you’re informed about the estimated cost impact of your infrastructure changes.

Infracost is optimized for Terraform and shows how a new EC2 instance, additional RDS database, or expanded load balancer affects monthly costs.

Setup for a small Terraform environment:

# Installation
brew install infracost

# Generate API key at app.infracost.io (free)
infracost auth login

# Before a planned change
terraform plan -out=tfplan

# Output the cost impact
infracost breakdown --path tfplan --format table

Output looks something like:

Project: myapp/prod

Name                           Monthly Qty  Unit  Monthly Cost
aws_instance.app_server        730          hours $72.00
aws_rds_instance.database      730          hours $180.00
Total                                               $252.00

In GitLab CI, Infracost comments can be written directly into merge requests to alert teams to cost implications in real time.

Continuous Optimization in Operations

FinOps is not a one-time project but an ongoing process. Establish monthly review cycles:

  1. Cost reporting: prepare cloud spending by project, team, and environment. This should be automated, using a Lambda function that queries Cost Explorer daily and sends reports to Slack or email.
  2. Anomaly detection: if costs spike 50 percent in a project, it should be flagged automatically. CloudWatch alarms with custom metrics help.
  3. Quarterly reviews: engineering leads and finance meet to assess which services are still relevant and where optimization opportunities exist.

A proven KPI: cost per transaction, cost per user, or cost per request depending on your business model. This makes cost efficiency not just a compliance concern but a real business objective.

From Strategy to Practice

FinOps for SMEs works best when three roles work together:

  • Engineering: implement right-sizing, tagging, code optimization
  • Finance: tracking, budgeting, setting incentives (for example, if a team cuts costs, it gets a portion of savings back for innovation)
  • Operations: set up tools, ensure compliance, run alerting

The technical levers are often straightforward. The effort lies in organization and maintenance. With regular reviews, clear policies, and automation, you can establish a cost discipline model that grows and sustains itself.

Our experience: teams that take FinOps seriously don’t just save in the short term. They build a cost culture where engineering is more thoughtful about cloud resources, which benefits innovation and scalability long-term.

Frequently Asked Questions

How often should right-sizing reviews happen?

At least quarterly or when significant workload changes occur. Teams with dynamic requirements benefit from monthly cycles. AWS Compute Optimizer supplies the data automatically, so the manual effort is just evaluating the recommendations.

Is Infracost really free?

The command-line tool is open source and free. For CI/CD integration, policy enforcement, and team dashboards, there’s a paid SaaS offering. For getting started, the CLI version is sufficient.

Do reserved instances reduce flexibility?

1-year reservations leave room to adapt. With 3-year commitments, only reserve true baseline loads like databases or persistent API servers. Volatile workloads stay better on-demand or use spot instances.

What cost savings are realistic?

With a structured approach, 20 to 30 percent in the first year. Many teams see quick wins of 10 to 15 percent just from right-sizing and shutting down unused resources. Reserved instances bring the second wave of savings.


Want to optimize your company’s cloud infrastructure for cost-efficiency while gaining transparency? Our FinOps consulting supports you with strategy, tooling, and implementation. Check out our cloud optimization services or contact us for a free consultation.

For deeper technical foundations, see our articles on Infrastructure-as-Code with Terraform and Pulumi, DevOps for SMEs: A Pragmatic Start, and Cloud Cost Optimization.

#finops #cloud-costs #aws #azure #cost-optimization
Share:
Martin-Jan Sklorz

Martin-Jan Sklorz

CTO – Software Architecture, Cloud & AI Engineering

Designs scalable software architectures and integrates AI into modern cloud environments. Focus on maintainable systems that hold up in daily operations.

Software ArchitectureAPI DesignBackend DevelopmentMicroservicesCloud-nativeKubernetesLLM IntegrationAgent Engineering