A Hybrid Cloud Strategy That Survives Real Workloads

TL;DR: Run steady-state, data-heavy workloads where storage and bandwidth are cheap, and rent compute for anything bursty or disposable. If you can't explain in one page why each workload lives where it does, you don't have a hybrid cloud strategy — you have two data centers with different login screens.

A CFO asks why the on-prem VMware cluster still costs more than the entire AWS bill. Nobody in the room can answer. That silence is where most hybrid plans die — not in the technology, in the bookkeeping.

What a hybrid cloud strategy actually means in practice

Strip away the vendor slides. Hybrid cloud means some workloads run in your building, some run in someone else's, and both are managed deliberately. Not "we have a rack and also an AWS account." That's just two estates with separate invoices.

Three traits keep a workload at home: predictable demand, enormous data volume, and a compliance officer who won't sign off. A steady-state Postgres cluster sitting on 20TB is a terrible fit for metered compute and per-gigabyte egress. A Black Friday spike is a great fit.

• Keep it home: steady databases, big file stores, anything with a fixed latency budget and no burst.
• Send it out: batch jobs, CI runners, dev/test environments, anything torn down on Friday.
• Leave it alone: the legacy app nobody understands. Migration risk usually beats the savings.

The hybrid cloud cost math people get wrong

Compute gets the attention. Egress gets the invoice. AWS charges roughly nine cents per gigabyte to move data out for the first 10TB a month, and a 40TB cross-region sync quietly becomes a line item nobody budgeted for. Azure and Google have their own versions of this. Read the egress table before you open the pricing calculator.

Cloud repatriation is real, and it isn't embarrassing. 37signals documented moving a chunk of its estate off public cloud onto owned hardware in 2023 and projected multi-million-dollar savings over five years. Dropbox did a version of this years earlier. Both kept plenty in the cloud — that's the point. It's a portfolio, not a religion.

Here's the honest test: if a workload's cost is dominated by storage and network, run it where storage and network are cheap. If it's dominated by idle capacity you'd otherwise over-provision, rent it.

Design for two estates, not two snowflakes

The classic failure is building a unique special flower on each side. You want one deployment path, one identity, one observability stack, whether a container lands in Frankfurt or Ashburn.

• Kubernetes as the portability layer — but only where it pays. EKS, AKS and GKE share an API surface, so your manifests survive. Managed control planes buy you upgrades you'd otherwise skip.
• Identity first. Make Microsoft Entra ID the directory and federate AWS IAM Identity Center to it. Do not build a second account system.
• Networking with a real budget. Direct Connect or ExpressRoute at 1Gbps is a monthly commitment, not a magic link. Sketch the topology before procurement asks.
• One observability backend. Prometheus plus hosted Grafana, or Datadog if you can stomach the bill. Two dashboards means two truths.

Where the hybrid cloud architecture usually breaks

Not in production. In disaster recovery. Teams rehearse failing over from on-prem to cloud, then discover replication lag is four hours and DNS TTL is 3600 seconds. Test the actual failover — on a weekday, with the on-call engineer awake.

Write down what runs where and why. One page saying "billing DB stays on-prem because 30TB a month of egress costs more than the hardware refresh" will save you six arguments a year.

Key Takeaways

• Hybrid works when you can justify each workload's location in one sentence.
• Egress and storage fees, not compute rates, decide most placements.
• Repatriation is a legitimate move, not an admission of failure.
• Standardize identity, deployment and monitoring across both estates — or you'll maintain two companies.

Frequently Asked Questions