How to Make the Most of Cloud Computing (From Someone Who's Watched Both the Wins and the Bills)

Cloud computing is the most powerful and most misused tool in modern IT. Used well, it unlocks capabilities that would have been impossible a decade ago. Used badly, it generates bills that look like small lawsuits and architectures that nobody wants to take responsibility for. We have been running infrastructure for customers since 2003, which means we have seen both outcomes, usually inside the same company, sometimes inside the same quarter.

This is the playbook we'd hand a customer on day one if we could write it onto the back of their cloud contract.

Rule One: Know What You're Actually Buying

When you buy a VM from a hyperscaler, you are not buying a server. You are buying a contract for compute, a contract for storage, a contract for networking, a contract for backups, a contract for monitoring, a contract for identity, and a contract for support, bundled under a single interface. Every one of those is metered separately, and every one of them can be optimized or wasted separately.

The first thing we tell new cloud customers is: slow down and understand what each meter is counting. Compute bills are rarely the surprise. Egress, storage tier transitions, per-request API charges, load balancer hours, NAT gateway data processing, and cross-AZ traffic are the surprises. Draw the architecture, annotate every edge with "what's metered here," and the bill stops being mysterious.

Rule Two: Elasticity Is Your Only Real Economic Advantage

Cloud compute is not cheap per unit. It has never been cheap per unit. Its economic advantage is that you only pay for it when you use it — if, and only if, you actually turn it off when you don't.

Most of the waste we see in customer cloud accounts comes from workloads that were lifted from on-prem in 2019 and are still running 24/7 because nobody built the automation to scale them down. Dev/test environments running at night, QA boxes nobody touched in six months, oversized instances "just in case," snapshots from 2021, and load balancers for endpoints that don't exist anymore.

If you do nothing else this quarter, run a cost explorer report, sort by spend, and ask of every line: is this thing actually being used right now. You will find money.

Rule Three: Design for Failure, Not for Uptime

The hyperscalers all publish their SLAs. Read them. They are weaker than most customers assume, and they are not insurance against a regional outage. AWS, Azure, and GCP all have bad days, and when they do, the only workloads that keep running are the ones that were designed to survive a region failure.

That doesn't mean you need to go multi-region for everything. It means you need to know which workloads are critical enough to justify the cost, and which aren't. For the critical ones, design for failover, test the failover, and document who pushes the button. For the non-critical ones, accept the risk in writing and move on. The trap is the middle case — workloads that management assumes are highly available but engineering knows are single-region because nobody ever had the budget to fix it.

Rule Four: Identity Is the Control Plane

The old perimeter-based security model doesn't work in cloud, and if you try to simulate it with VPNs and private subnets, you end up with a brittle and expensive architecture that nobody can maintain.

In a cloud environment, identity is the control plane. Every access decision starts with "who is asking, from what device, in what context." This means:

• Single sign-on for every application, no exceptions. Apps that don't support SSO in 2025 are not enterprise software.
• MFA for every human, and FIDO2 security keys for administrators and developers.
• Managed identities for workloads (never long-lived static keys in environment variables).
• Just-in-time elevation for privileged operations, audited and time-bound.
• Conditional access policies based on device posture, location, and risk.

Every cloud security incident we've helped a customer recover from traced back to an identity gap — a reused service account, an over-permissioned role, an MFA exemption that never got removed, an access key checked into a repo. Close the identity gaps and most of the other security noise goes away.

Rule Five: Tag Everything From Day One

Tags are how you turn a cloud bill from a single scary number into a set of accountable line items. Every resource should be tagged with owner, environment, cost center, and workload. This sounds bureaucratic. It is. It's also the only way to run FinOps that works.

Put tag enforcement into the resource provisioning pipeline — no tag, no deploy. It is an order of magnitude easier to enforce tags at creation than to retrofit them on 4,000 existing resources six months in, and we have done both.

Rule Six: Automate or Regret

Cloud rewards automation and punishes clicking. Every environment we've seen with runaway costs or security gaps had one thing in common: provisioning was done manually through the console, and nobody could reconstruct why a given resource existed.

Infrastructure as code — Terraform, Bicep, Pulumi, whatever fits your team — is not a nice-to-have. It's the line between "we operate our cloud" and "our cloud operates us." It doesn't have to be elegant. It has to be reproducible. A messy Terraform repo is infinitely better than a beautiful diagram and manual deployments.

Rule Seven: Don't Ignore What's Free

Every hyperscaler gives you tools to look after your own environment for free, and most customers never enable them. AWS has Trusted Advisor, Security Hub, and Cost Anomaly Detection. Azure has Advisor, Defender for Cloud, and Cost Management alerts. GCP has Recommender and Security Command Center. These are not a substitute for real monitoring and real FinOps, but they are free, they run continuously, and they catch roughly 80 percent of the common mistakes before they become the 30 percent of your bill that's waste.

Turn them on. Read the reports. Actually act on the recommendations.

Rule Eight: Review the Architecture Annually

A cloud environment that doesn't get reviewed drifts. Instance sizes that made sense a year ago don't anymore. Services you didn't need then are available now. Reserved instances expire. Teams add things without subtracting things. A yearly architecture review — with the goal of simplifying, decommissioning, and re-sizing — is the cheapest performance and cost win available.

We do this review for customers and typically find savings of 20 to 40 percent with no capability loss, just by removing things that shouldn't still exist and re-sizing things that were sized for peak load that never materialized.

Where Cloud Is Worth the Premium

To close, a short list of where cloud really earns its price tag, from our direct experience:

• Bursty workloads (batch processing, reporting, periodic analytics).
• Global distribution of static assets and APIs.
• Managed databases with serious backup and replication (Aurora, Azure SQL, Cloud Spanner).
• Fully managed message and event infrastructure (SQS, Event Grid, Pub/Sub).
• ML and data platforms that are too expensive to replicate on-prem.
• DR targets backed by object storage with immutability.
• Short-lived environments for testing, demos, and experimentation.

For almost everything else — steady-state production, predictable workloads, internal line-of-business applications — private cloud in a well-run facility usually beats hyperscaler economics over a three-year horizon. That's not a cloud-skeptic position. It's what the math says.

Three Takeaways

1. The elasticity premium is real but only if you actually flex. Workloads that run 24/7 are not using the feature you are paying for.
2. Identity, tagging, and automation are not optional. Skip any of them and the cloud becomes a tax you don't control.
3. Review the architecture every year. The one you designed last year is not the one you'd design today. Close the gap on purpose.