Multi-Cloud Doesn't Have to Mean Multi-Chaos
A pragmatic reference architecture for security teams supporting workloads across two or more clouds without doubling the toil.
RAZR Architecture
Multi-cloud is rarely a strategic choice. It's usually the result of an acquisition, a big customer requirement, or a team that picked the tool closest to hand. Your security program still has to work across all of it.
Pick one control plane, not one cloud
You don't need to standardize on one cloud. You do need to standardize on where your security signal lands.
- One identity provider federating into every cloud (no per-cloud user directories).
- One SIEM or data lake receiving logs from every provider in a normalized schema.
- One policy-as-code layer expressing guardrails once and rendering per-cloud implementations.
Where per-cloud specialization is still worth it
Detection engineering benefits from cloud-native depth. Write generic rules in the SIEM, but keep provider-specific detections (GuardDuty, Defender for Cloud, Security Command Center) turned on and tuned.
The trap to avoid
Building an "abstraction layer" that hides cloud differences from engineers is a multi-year project that usually collapses under its own weight. Standardize the security signal, not the developer experience.