// competency

Cloud Infrastructure & FinOps for Enterprise

We design and operate cloud environments where budgets stay predictable and architectures withstand real workloads. No end-of-month surprises for the CFO.

// about the practice

What it is and who needs it

The cloud practice covers design, migration, operation and financial optimization of cloud environments (AWS, Azure, GCP, multi-cloud, hybrid). FinOps adds the discipline of cost governance: it moves infrastructure spend out of the "unpredictable opex" bucket into a managed budget line with transparent allocation across teams and products.

It is a distinct competency, not a "set up a dashboard" service. Without FinOps, cloud architecture works but quickly becomes expensive. Without architectural grounding, FinOps becomes nothing more than reports nobody reads.

You need this if

  • Cloud bills grow faster than business workloads.
  • The CFO keeps asking what exactly the $X monthly bill is for.
  • Engineering teams spin up resources without finance approval.
  • You are planning an on-prem to cloud migration but cannot trust the TCO model.
  • You run multi-cloud (≥2 providers) and lost visibility into aggregate spend.
// our position

Why we do this differently

01

The biggest cloud losses do not come from expensive services. They come from resources that everyone forgot about three to four months after launch.

Forgotten dev environments running on production tiers, test clusters with unbounded autoscaling, database snapshots without retention policy. Before buying optimization tools, we put the existing estate in order.

02

FinOps without a designated budget owner in IT is just reports nobody reads.

A purchased tool optimizes nothing on its own. Before recommending any tool, we help define the FinOps Lead role on the client side.

03

The most expensive Kubernetes clusters are not always the busiest — often they are simply the least governed.

In typical enterprise environments, a single forgotten cluster can cost more than the main production installation. The first step of any FinOps engagement is inventory and tagging audit, not a dashboard.

// honest filter

When you need this — and when you don't

It is more honest to say "you do not need this yet" than to sell an engagement that will not deliver ROI.

✓ Need it

  • ≥5 cloud services in production
  • Monthly cloud bill ≥$10k
  • Multi-cloud strategy (AWS + Azure / GCP)
  • CFO demands predictability of IT costs
  • Planning an on-prem → cloud migration
  • DevOps spends >10% of time on cost questions

✗ Not yet

  • 1–2 small AWS instances without production workload
  • Monthly budget <$5k
  • All infra on-prem, no migration plans
  • IT fully outsourced under a fixed-price managed contract
  • You need a one-time audit — cheaper options exist
// process

How we run the engagement

01

Assessment · 2–3 weeks

Inventory across all cloud providers, tagging audit, analysis of the top-20 cost lines over the last 3 months, orphan-resource discovery. Output: a report with prioritized recommendations.

02

Quick wins · 4–6 weeks

Purchasing Reserved Instances and Savings Plans, decommissioning orphans, configuring auto-shutdown for dev/test, rightsizing the most overprovisioned instance families. No structural architecture changes.

03

Governance · 2 months

Tagging policy (mandatory tags: project, team, environment), defining the FinOps Lead on the client side, setting up budget alerts, weekly review of the top-5 cost anomalies with engineering teams.

04

Architectural changes · 3–6 months

Step by step — where quick wins no longer help: migrating from lift-and-shift to cloud-native patterns, moving batch workloads to spot/preemptible nodes, redesigning storage tiering.

05

Continuous operation · ongoing

Anomaly detection, monthly business review with the CFO, 12-month budget forecast, retrospective analysis of architectural decisions. SLA on response time for cost anomalies.

Project lead: SL Global Service (cloud architecture, FinOps governance, DevOps).
Brought in when needed: Softline (cloud security & compliance) and Softengi (AI-driven cost forecasting for multi-cloud scenarios).

// anti-patterns

Typical mistakes we have seen projects fail on

Big bang lift-and-shift

The on-prem architecture is migrated 1:1, expecting savings. Three to four months later, cloud is twice as expensive as on-prem was.

What we do instead: before migration, we identify which workloads benefit from cloud-native patterns, which stay as-is, and which are refactoring candidates.

FinOps without an owner

The client buys a platform, expecting it to optimize on its own. The platform issues 200 recommendations a month — nobody approves them.

What we do instead: we define the FinOps Lead before buying a tool. Often this is not a new role — it is 20–30% of time of an existing DevOps Lead.

ROI is calculated on the pilot phase

AI project pilots usually go smoothly. Problems start in the second month of production, when the model first meets real-world noise.

What we do instead: we model production load during the pilot, with realistic data volumes. ROI is calculated on the stable production phase (3–6 months).

Tagging "later"

Engineering teams launch resources without mandatory tags. A year later, there are tens of thousands of "later"-resources; cost allocation becomes impossible.

What we do instead: we enforce tagging via IaC — a resource without mandatory tags simply does not get created by the Terraform plan.

// experience

Typical scenarios from our practice

No precise savings percentages — actual numbers depend on the client's starting point. Instead — concrete architectural decisions and organizational changes.

Tier-1 Ukrainian bank · multi-cloud (AWS + Azure)

Kubernetes rightsizing and scheduled autoscaling

Found overprovisioning in production clusters — nodes sized 3x the average load. Switched to scheduled autoscaling with distinct profiles for weekdays / weekends / holidays. Implementation: 4 months. FinOps Lead designated on day one.

Energy company · hybrid (on-prem + GCP)

FinOps governance and 12-month forecast

The client had a "wild" multi-cloud landscape after acquiring two regional subsidiaries with different cloud providers. We introduced a single tagging policy. Four months in, the CFO received the first 12-month cloud forecast.

Telecom operator · Kubernetes scaling

Cluster topology redesign and Savings Plans

Split dev/test/prod into separate clusters, bought 3-year Savings Plans for baseline workloads, moved batch jobs to spot nodes.

// deep dives

Articles on this topic

Nine recent expert articles — from thematic overviews to specific architectural decisions.

// stack

Technologies we work with

FinOps platforms

AWS Cost Explorer · Azure Cost Management · GCP Billing · CloudHealth · Flexera One · Apptio · Kubecost

IaC

Terraform · Pulumi · AWS CloudFormation · Azure Bicep · ArgoCD

Containers & orchestration

Kubernetes · EKS · AKS · GKE · OpenShift · Karpenter

Monitoring & observability

Prometheus · Grafana · Datadog · CloudWatch · OpenTelemetry

CI/CD

GitLab CI · GitHub Actions · Jenkins · Tekton · Spinnaker

Standards

ISO/IEC 27001 · FinOps Foundation Framework · CIS Benchmarks · NIST CSF

// frequently asked

Frequently asked questions

Is FinOps suitable for small companies?

Below roughly $5–10k of monthly cloud spend, the overhead of a FinOps practice usually exceeds the savings. Small businesses should stick to the basics: tagging, dev-environment auto-shutdown, regular manual review of the top-5 cost lines.

How to choose between AWS, Azure and GCP?

The choice is driven not by provider features (they overlap by 80%) but by the client's existing IT ecosystem. Microsoft 365 — Azure. Google ecosystem — GCP. Others — AWS, simply because the local engineer pool is larger.

How long does a FinOps assessment take?

2–3 weeks of calendar time. One week is the technical part (inventory, billing data); the rest is interviews with teams to understand who owns what.

Do we need to redesign the whole architecture upfront?

No. We start with quick wins — delivering 60–70% of potential savings within 4–6 weeks without structural changes. Architectural redesign is a separate decision based on each workload's ROI.

Who is the FinOps Lead and where do we find them?

A person in IT with authority to make cloud cost decisions. Often it is an Engineering Manager or DevOps Lead for whom FinOps is 20–30% of their time. A dedicated headcount is usually not needed.

Can we run FinOps in-house?

Yes — especially for small or single-provider environments. For multi-cloud, external expertise speeds up assessment by 2–3x.

// other competencies

Related competencies

Real projects rarely fit in one competency. See which other areas we work in.

Tell us about your cloud situation — we will suggest where to start

30-minute discovery call, no commitments. We will understand whether we have something to offer — and if so, agree on the assessment format.

All contacts