How Kilimo built a hybrid cloud network without splitting the platform

Why build hybrid instead of rebuild

‍

Many founders assume multi-cloud means redesigning the platform. It doesn't — and it shouldn't. Hybrid architectures are common in mature companies; they're rare in startups because it's easier to teach a Series A startup how to optimize for one cloud than to manage two. But when you've already optimized for one, and new capital (in credits) is contingent on using another, the math changes. You preserve what works, extend what you've built, and move forward. At Renaiss, we help founders make that call technically sound — and profitable.

‍

1. IP allocation

‍

Get this right before anything else; it's the cheapest mistake to avoid and the most expensive to fix later.

• No overlapping address space anywhere. Across both clouds, on-prem, and — critically — the Kubernetes pod and service ranges, every CIDR must be globally unique. Overlap forces you into NAT or renumbering, and both are miserable.
• Allocate in summarizable blocks. Carve a large supernet and hand out aggregatable ranges per cloud (e.g. a /12 for AWS, a separate /12 for Azure) so route tables and BGP advertisements stay compact. Govern it from real IPAM tooling, not a spreadsheet.
• Watch the Kubernetes IP appetite. EKS with the VPC CNI gives every pod a routable VPC IP and can consume tens of thousands of addresses; AKS forces an early CNI choice (Azure CNI puts pods on the VNet and is routable cross-cloud, while overlay/kubenet hides them and isn't).
• Make pod CIDRs routable and non-overlapping if pods talk across clouds. Direct pod-to-pod reachability is only possible when both sides use routable, conflict-free pod ranges.

‍

2. Connectivity fabric and appliances

‍

Two layered decisions: how the two clouds physically connect, and what sits in the path to route and inspect traffic.

• How the clouds connect. IPsec VPN over the internet is cheap and fast to stand up but has per-tunnel ceilings and public-internet variability; dedicated Direct Connect + ExpressRoute joined at a cloud exchange (Megaport, Equinix) buys predictable latency and throughput at higher cost and lead time.
• What sits in the path. Cloud-native fabric (Transit Gateway + Virtual WAN) auto-scales with minimal ops but is L3-only; managed firewalls (AWS Network Firewall, Azure Firewall) add inspection; third-party NVAs (Palo Alto, Fortinet) give consistent L7 inspection and one policy model across both clouds, at the cost of licensing and owning HA, scaling, and patching yourself.
• Route dynamically and symmetrically. Use BGP for failover rather than static routes, and design symmetric paths — asymmetric routing through a stateful appliance is the classic silent hybrid outage.

For Kilimo we stayed fully cloud-native: an IPsec VPN between AWS Transit Gateway and Azure Virtual WAN, with no third-party appliances. Their traffic volumes and inspection requirements didn't justify NVAs or a dedicated circuit, and keeping the interconnect on managed appliances meant no HA, patching, or licensing burden to carry — the cloud providers own that.

‍

‍

3. Hybrid DNS for private zones

‍

A workload in EKS must resolve an Azure private name (and vice versa) without leaking the query to public DNS.

• Conditional forwarding in both directions. Use Route 53 Private Zones with Resolver inbound/outbound endpoints on the AWS side and Azure Private DNS with the DNS Private Resolver on the other, each forwarding the peer cloud's subdomain to the peer's inbound endpoint.
• Give each cloud a distinct subdomain. Separate namespaces keep forwarding rules clean and avoid collisions.
• Make resolver endpoints HA across AZs. A single resolver endpoint is a single point of failure for all cross-cloud name resolution.
• Don't forget the cluster layer. CoreDNS in each cluster needs forward rules so workloads inside EKS and AKS actually reach the right resolver.

‍

4. Private PKI with a shared trust root

‍

In a cross-cloud microservices platform you'll often want mTLS or internal TLS — which means one coherent trust hierarchy, not a pile of self-signed certs.

• One root, per-cloud intermediates. Distribute the same root bundle to both clouds so an EKS workload trusts a certificate issued in AKS.
• Prefer a cloud-neutral issuer. HashiCorp Vault gives one consistent issuance and rotation model rather than stitching together ACM PCA and an Azure CA.
• Automate distribution and rotation. Point cert-manager at the shared issuer in each cluster so certificates are short-lived and self-renewing.

For Kilimo this didn't apply — their cross-cloud requirements didn't call for service-to-service mTLS, so we deliberately kept a private PKI out of scope rather than build something unused. We include it here because most cross-cloud platforms reach for it eventually, and it's far cheaper to plan the trust hierarchy early than to retrofit it.

‍

5. Cluster-to-cluster communication

‍

This is the question that ties the whole design together: how does a service in EKS actually reach a service in AKS? There are three broad answers, in ascending order of capability and operational weight.

• Direct pod-to-pod (routable pods) — the lowest-latency path and the most coupled. It demands routable, non-overlapping pod CIDRs on both sides and ties each cluster to the other's internal addressing, so a change on one side can ripple across the interconnect.
• Internal load balancers — each cluster fronts its cross-cloud services with an internal LB (an internal NLB in AWS, an internal Standard Load Balancer in Azure) reachable over the private interconnect. The calling cluster targets a stable LB endpoint rather than individual pods, so the two clusters stay decoupled from each other's pod-level details.
• Multi-cluster service mesh — Istio, Cilium Cluster Mesh, or Linkerd. The richest option (mTLS, traffic shifting, locality-aware routing) and the heaviest to run.

For Kilimo we chose internal load balancers. Only a handful of services needed to talk across clouds, and the internal-LB model gave us the cleanest balance of simplicity and control: the clusters stay decoupled, we don't need to make pod CIDRs mutually routable, and the LB endpoints pair naturally with the conditional DNS forwarding from point 3 — a service simply resolves the peer's private name and gets a stable address on the other cloud. The trade-offs are an extra network hop and owning LB health and endpoint configuration ourselves, both of which were easy prices to pay versus standing up and operating a cross-cloud mesh for a small set of flows.

‍

What we built for Kilimo

‍

The topology: a managed hub in each cloud, an IPsec interconnect between Transit Gateway and Virtual WAN carrying BGP, conditional DNS forwarding between the two resolvers, and internal load balancers as the cross-cloud service entry points. No third-party appliances, no private PKI.

A cross-cloud call follows the dotted and solid lines together: a pod in EKS resolves the Azure service name (conditional forwarding hands it the internal LB address), the traffic crosses the IPsec link via Transit Gateway and Virtual WAN, and lands on the Azure internal load balancer fronting AKS — and symmetrically in reverse.

‍

What Kilimo learned

‍

Kilimo now orchestrates water management intelligence across AWS and Azure without platform fragmentation. Latency is predictable, failure modes are understood, and the cost per byte of data moved across the interconnect is known and acceptable. The Azure credits, which arrived as an obligation, became a strategic asset.

The lesson is broader: hybrid doesn't mean compromise. It means deliberate choices made early. It means knowing your IP space before you need it, routing traffic symmetrically before you have an outage, and thinking about mTLS before you're in a compliance audit.

If you're building climate tech, fintech, or any infrastructure-heavy startup and you're facing the same decision — credits in one cloud, architecture in another, a mission that won't wait — let's talk about how to scale without splitting.

‍