Multi-Cloud Consulting · On-premises and hybrid
Hybrid cloud with one route in and one identity
Most estates keep some systems on-premises for good reasons. We design the private connectivity, cloud hub, DNS and identity boundary that let those systems and cloud workloads work together, with every route, rule and trust written down and owned.
The problem
Where this usually breaks down
Connectivity negotiated per project
Each migration or new service arranges its own VPN or circuit, so routes overlap, inspection is inconsistent and nobody holds a complete picture of what can reach the data centre.
Names that resolve two ways
Private endpoints and internal zones resolve one way from staff networks and another inside the cloud, and the failures surface as intermittent timeouts that are slow to trace.
Two directories, no boundary
Directory accounts on-premises and cloud identities drift apart, service accounts multiply on both sides, and nobody can say which identity is authoritative for a given system or person.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Private connectivity sized to the traffic
We design ExpressRoute, AWS Direct Connect or Cloud Interconnect circuits, or site-to-site VPN where that is enough. Each gets redundant paths, BGP routing and address ranges that do not collide with anything on-premises.
A cloud hub that owns inspection
Traffic between the data centre and cloud workloads passes through one hub, where firewalls inspect it in both directions. Route tables are part of the template rather than per-workload configuration.
DNS that resolves the same everywhere
We plan forwarding between on-premises DNS servers and cloud resolvers together with private endpoint zones. A name then resolves to the same address from a staff laptop, a data centre server and a cloud workload.
One identity boundary across both sides
We decide which directory is authoritative for people and which for workloads, and connect it to Microsoft Entra ID or your cloud identity provider. We also define how service accounts on each side are issued, rotated and retired.
Governance for servers that stay on-premises
Where it fits, Azure Arc brings on-premises servers and Kubernetes clusters under the same policy, inventory and monitoring as cloud resources. Azure Local runs Azure services in your own data centre.
Placement decisions you can defend
For each workload we set out whether it stays, moves or splits, based on latency to its dependencies, data residency, licensing and running cost. The reasoning is recorded so the decision can be revisited.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Connectivity and routing design
Circuit and VPN topology, BGP and route table design, the address plan and failover behaviour, written down with the reasoning behind each choice.
Hub and DNS modules in Terraform
The hub network, firewall rules, resolver configuration and private zones as Terraform in your repository, reviewed as a plan on every change.
An identity boundary document
Which directory is authoritative for what, how trust flows between them, and how accounts on each side are created and removed.
Runbooks for the hybrid seams
Runbooks for circuit failover, DNS changes, firewall rule requests and identity incidents, owned by the teams on each side who will use them.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Map dependencies and traffic
We map which on-premises systems each cloud workload depends on, over which protocols and with how much traffic, because connectivity and placement decisions both start from that picture.
02
Design connectivity and identity
We agree the circuits, the hub, the DNS forwarding and the identity boundary with your network and directory teams, and walk through failover paths on paper before anything is ordered.
03
Build and test the seams
The hub, routing and resolvers are written in Terraform and tested with real traffic from a pilot workload, including failover between paths, before production systems rely on them.
04
Hand over to both sides
Network, directory and cloud teams each take ownership of their part, with runbooks that describe the seams between them, so a failure at the boundary has an obvious first responder.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Offered, not in published work
- ExpressRoute
- AWS Direct Connect
- Cloud Interconnect
- Azure Arc
- Azure Local
- Microsoft Entra ID
- Azure Firewall
- Terraform
Questions
What teams ask before we start
Should we move everything to the cloud instead?
Not necessarily. Some systems stay on-premises for sound reasons of latency, data residency, licensing or cost. We help you decide workload by workload, and design the hybrid seams so that keeping one system where it is does not hold everything else back.
Which cloud providers does this cover?
Azure, AWS and Google Cloud. The circuits differ, with ExpressRoute, AWS Direct Connect and Cloud Interconnect respectively, but the design questions stay the same: redundant paths, routing, inspection, DNS and who owns each piece.
Do you work with our network and directory teams?
Yes, closely. They own the routers, firewalls and directories on their side, and the design only works if they agree it. We run joint design sessions and make changes through their existing change process.
What access do you need on-premises?
Usually none directly. We work from your network diagrams, routing tables and directory configuration, and your engineers make on-premises changes under your change control, with us reviewing and pairing where it helps.
Related services
What teams often need alongside this
Azure landing zones
Azure landing zones in Terraform: management groups, policy at scale and a hub-and-spoke network that every subscription inherits.
AWS foundations and governance
A multi-account AWS organisation with OUs, service control policies and account vending in Terraform, so new workloads start governed.
Google Cloud foundations
A Google Cloud hierarchy with folders, organisation policies and Shared VPC, plus Google Kubernetes Engine clusters your pipeline deploys to.
Next step
Plan your hybrid connectivity with us
Tell us which systems stay on-premises and what depends on them. We will help you work out the connectivity, DNS and identity decisions to settle first.