Why I Assigned Each Cloud a Job
Multi-cloud done wrong is just paying three bills for the same thing.
Every few years, somebody announces that multi-cloud is the future.
Then six months later, they’re running the same workloads in AWS, Azure, and GCP while paying three cloud bills instead of one.
That’s not really multi-cloud. That’s duplication.
The question isn’t whether you’re using multiple clouds. The question is whether each one is doing something different.
When I built Meridian, I tried to treat each platform like a specialist instead of a backup copy.
AWS got the security plane
AWS has the deepest security ecosystem I’ve worked with. It’s not really close.
Vault lives there because KMS auto-unseal solves a real operational problem. If Vault restarts, I don’t want to be hunting down unseal keys or waiting for someone to log in and fix it. KMS handles that automatically, and IAM gives me a clean way to control access.
The alerting pipeline starts there too. GuardDuty findings flow through EventBridge into a service that normalizes them alongside Falco runtime alerts. Whether the signal came from cloud infrastructure or Kubernetes runtime activity, it ends up looking the same downstream.
The goal isn’t collecting alerts. The goal is reducing the number of places I need to look during an incident.
GCP got the observability plane
One of my favorite architecture questions is: where does your monitoring live?
A surprising number of environments answer that question with: “Next to the thing it’s monitoring.”
That works right up until it doesn’t.
If AWS has a bad day and your dashboards, metrics, logs, and alerting all live in AWS too, you’ve lost visibility at the exact moment you need it most.
Putting the observability stack somewhere else creates a degree of separation. If production is having problems, I want the monitoring system to be outside that blast radius.
That’s why the metrics and logging systems live in GCP. The fact that some of those services can run cheaply there is a bonus. The isolation is the reason.
Azure got identity
Most enterprise environments eventually become identity problems. Authentication. Authorization. Federation. Service-to-service trust.
Azure has become difficult to ignore in that space because so many organizations already run Entra ID. What I wanted to explore was Workload Identity Federation.
Instead of storing client secrets inside Kubernetes, workloads authenticate using OIDC and receive temporary credentials when they need them. No secret rotation. No forgotten credentials. No spreadsheet containing production access keys that somebody created three years ago and nobody wants to admit still exists.
Every time I can remove a long-lived credential from a system, I consider that a win.
On-prem got reality
Cloud environments are comfortable. Managed DNS. Managed load balancers. Managed identity. Managed certificate distribution.
The problem is that a lot of real infrastructure doesn’t look like that.
Running k3s locally forces me to test assumptions I didn’t know I was making. Certificate distribution was the first thing that reminded me how much cloud providers quietly handle. In AWS or GCP, you’re a few API calls away from a signed certificate. On-prem, you’re figuring out your own distribution mechanism, your own trust chain, and your own renewal story.
None of it is magic anymore. That’s actually the point.
If something only works because a managed service is solving half the problem behind the scenes, I’d rather find that out in a lab than during an outage at a site that doesn’t have those managed services available.
The architecture question that matters
Whenever I look at an environment, I try to ask a simple question: why is this here?
Not what does it do. Not what technology does it use. Why is it here?
If a workload lives in AWS, there should be a reason. If it lives in Azure, there should be a reason. If it lives in GCP, there should be a reason. Sometimes the answer is cost. Sometimes it’s reliability. Sometimes it’s security. Sometimes it’s because that’s where the service genuinely fits best.
But “that’s where we originally put it” probably isn’t an architecture decision. It’s just history.
And the longer a platform exists, the more expensive history becomes.