Working in a mission-critical environment, I've learned that the starting point of any architecture is never the tool — it's having a minimal vision of where I want to get to. Before drawing any topology, I think about how it will positively impact the environment we're operating in. Multi-cloud is no exception.
Thinking about multi-cloud network architecture means, in practice, intentionally connecting multiple cloud providers — and, most of the time, the local datacenter too — to optimize workloads. And "intentionally" is the right word: every decision carries a trade-off between latency across clouds, data egress cost, end-to-end security complexity, and standardized management and governance.
The pillars behind this architecture
Over time, I've learned to organize this complexity into five fronts. They aren't independent — a decision in one almost always pulls a thread in the other four — but they help structure the thinking when designing a project.
1. Cloud-to-cloud connectivity and traffic
- Avoid relying on the public internet for sensitive traffic — prioritize private, virtual connections (Direct Connect, ExpressRoute, Interconnect).
- Use PoPs or neutral datacenters as convergence points between clouds, cutting hops and latency.
2. Data egress costs
- Map the data flow and keep frequently-communicating services within the same region or provider.
- Place interdependent databases and applications geographically close, to avoid unexpected spikes on the bill.
3. Security and identity
- Adopt a Zero Trust model — "never trust, always verify" — with continuous validation and MFA on every access.
- Unify firewalls, IAM and compliance with cloud-native platforms (CNAPP), instead of managing each environment in isolation.
4. Visibility and monitoring
- Standardize logs and metrics. Every cloud has its own dashboard (CloudWatch, Azure Monitor, GCP Operations) — centralizing everything in one tool avoids diagnostic blind spots.
5. Governance and automation
- Automate provisioning with cloud-agnostic tools like Terraform, ensuring consistent configuration and cutting manual error.
- Standardize on Kubernetes and APIs to keep portability and avoid vendor lock-in.
Before I design, I ask
To help structure the projects I work on, I always start by writing down the prerequisites. Three questions guide nearly everything that follows in the design:
- 01Which cloud providers are already in use — AWS, Azure, GCP, OCI — or which ones will be part of the project?
- 02What's the main goal behind adopting multi-cloud: cost reduction, high availability, or redundancy?
- 03Is there a real need for integration with the physical environment, on-premises?
With those three answers in hand, I start research, put together the first sketches, and build decision matrices to visualize the main scenarios — and the main problems — that might come up during implementation. It's an iterative process: the first sketch almost never survives intact to the final version, and that's fine.
To go deeper
A few topics I'd recommend researching further, beyond what fits in one post:
- Alura — practical advantages and implementation challenges of multi-cloud architecture.
- Equinix — the role of connectivity and neutral datacenters in this kind of architecture.
I hope this post helped, at least a little, in understanding the process and steps that have always worked for me and my team. Next week, I'll follow this same line of thinking toward automation — my first steps with Infrastructure as Code.
Next post: my first steps with Infrastructure as Code.
See all posts