Cloud economics: how to optimize your IT infrastructure costs

Cloud cost optimization mostly comes down to three things: eliminating waste (unused resources), right-sizing, and picking the right purchasing model (on-demand vs. reservations vs. spot). In practice, these three steps often cut the bill by 10-30% with no changes to the application.

Why can the cloud end up more expensive than on-prem servers, even though it was supposed to “scale itself”?

Because the cloud is like a taxi with a meter running — it works great as long as you know where you’re going and who’s paying. Costs climb when:

• resources run 24/7, even though they’re only needed 8/5,
• instances are oversized “just in case,”
• storage grows with no retention policies,
• you’re paying for data transfer (egress) and cross-zone traffic,
• you have duplicated monitoring and logging tools,
• nobody owns the costs, so things just “run their course.”

Most often the problem isn’t technical — it’s organizational: no accountability, no rules, and no visibility.

What is FinOps, and why is cost optimization a one-off exercise without it?

FinOps is a collaborative practice between IT, finance, and the business that makes sure cloud costs are:

• measured and assigned to owners,
• controlled in real time (not after the fact),
• optimized on an ongoing cycle, not “in a burst.”

In companies where I roll out this model, the difference is simple: before, costs are “the cloud’s cost”; after, they’re “the cost of a product, a service, or a team” — and that makes them manageable.

Where do you start to find the biggest savings within a week?

If you want quick results, start with the 5 most common sources of waste:

1. Idle resources
   Old disks, snapshots, IP addresses, load balancers, test environments nobody uses anymore.
2. Oversized instances
   CPU at 5-15%, RAM at 20% for most of the day.
3. Dev and test environments running overnight and on weekends
   This is a classic “silent leak.”
4. Logs and metrics with no limits
   Excessive retention, overly granular logging, duplicated telemetry.
5. Data transfer and network architecture
   Traffic between zones and regions, and especially egress to the internet or another provider.

In practice, these five areas deliver the fastest, least invasive cuts.

How do you build cost visibility if today you only see one “cloud” invoice?

You start with a simple cost allocation model.

Tagging and ownership

Introduce a minimal set of tags/labels, nothing fancy:

• owner (a person or a team),
• service or product,
• env (prod, stage, dev),
• cost_center (if you have one).

Without this, you can’t have a conversation about “what we’re optimizing,” because nobody knows “whose it is.”

Budgets and alerts

Set budgets per:

• environment,
• product,
• team.

What matters most are “early warning” alerts, not just “we went over.”

A weekly report instead of a monthly one

In the cloud, a month is an eternity. A weekly rhythm lets you catch deviations before they grow.

Which architectural decisions affect costs the most?

Simply put: you pay for what’s running, what you’re storing, and what you’re transferring.

Compute

• autoscaling instead of a fixed instance count,
• matching instance types to the workload profile (CPU vs. RAM),
• shutdown schedules for non-prod.

Storage

• storage classes matched to usage (hot vs. archival),
• lifecycle policies, retention, cleaning up clutter,
• control over snapshots and backups.

Network

• minimizing cross-zone and cross-region traffic,
• caching and a CDN wherever it makes sense,
• keeping data and compute close together.

In my experience, the “most expensive clouds” are often the ones where the architecture was built like on-prem — it just shows up on the invoice faster.

How do you right-size resources without wrecking performance?

You do right-sizing methodically:

1. Collect load metrics (CPU, RAM, I/O, network) from the last 14-30 days.
2. Use percentiles, not averages (e.g., P95).
3. Reduce the resource gradually and watch the impact on latency and errors.
4. Add guardrails, i.e., minimum and maximum values in autoscaling.
5. Repeat on a cycle, because applications change over time.

The most common mistake is “cutting blind.” The best pattern is “shrink, observe, automate.”

When do reservations, Savings Plans, and contracts pay off, and when is it better to stay on-demand?

A practical rule:

• On-demand: when load is variable, short-lived, or experimental.
• Reservations or savings plans: when you have a stable production baseline.
• Spot/preemptible: when the workload can tolerate interruption (batch, rendering, ETL, part of CI).

In practice, I do it this way:

• first I cut waste,
• only then do I “lock in” costs with reservations, because otherwise you end up reserving the wrong size.

How do you cut Kubernetes and container costs that “were supposed to be cheaper”?

Kubernetes very easily turns expensive, because it hides real consumption.

The most effective moves:

• set requests and limits for CPU/RAM — without them, you burn through nodes,
• use autoscaling (HPA and cluster autoscaler) with sensible thresholds,
• shut down non-prod environments overnight,
• control the cost of cluster logs, since they can outstrip compute costs,
• split clusters, or at least namespaces, by product and environment, so it’s clear who’s “burning” the budget.

In my experience, the first K8s savings come from cleaning up requests and trimming logs — node pool tuning comes only after that.

How do you cut logging, metrics, and observability costs without losing security?

The rule here is: log smarter, not more.

• shorten retention wherever it isn’t required,
• separate logging levels for prod and non-prod,
• filter out noise (health checks, debug spam),
• keep full logs for a shorter period, and hold on to aggregates and alerts longer,
• standardize tools, because duplicated telemetry costs you twice.

In practice, observability costs can spiral out of control faster than the servers themselves.

Which KPIs are worth setting so optimization stays continuous instead of a one-off?

I recommend 8 KPIs that are simple and actually work:

• daily and weekly cost per product,
• cost per environment (prod vs. non-prod),
• share of “unassigned” (untagged) costs,
• resource utilization (CPU/RAM) vs. the size you’re paying for,
• logging and metrics cost per service,
• data transfer cost,
• cost per transaction or per user (if you can calculate it),
• number of “zombie resources” found and removed each month.

KPIs have to lead to a decision. If nobody acts on them, they’re just charts.

What does a sensible 90-day cloud cost optimization plan look like?

Days 1-14: quick savings

• tagging and ownership,
• removing unused resources,
• non-prod shutdown schedules,
• basic budget alerts.

Days 15-45: stabilization and automation

• right-sizing and autoscaling,
• storage and log retention policies,
• an initial cost allocation model per product.

Days 46-90: purchasing optimization and FinOps maturity

• reservations for the baseline,
• spot instances for batch and CI,
• a steady rhythm of cost reporting and reviews,
• a standards catalog for “how we provision services,” so the chaos doesn’t come back.

What mistakes most often destroy the savings?

1. Reservations made before cleaning up waste.
2. No cost owner — “everyone and no one.”
3. Cutting costs with no monitoring of performance and SLOs.
4. Savings only in compute, while logs and transfer costs get ignored.
5. No automation, so the cost creeps back within 2 months.

The cloud rewards discipline. Without it, it will always be more expensive, no matter how modern it is.