Cloud
The full domain, and the other capabilities within it.
Hybrid Cloud
Two estates are only a problem when they are governed as two.
What this is
Hybrid cloud is the deliberate operation of on-premises and cloud infrastructure as one platform: shared connectivity, one identity model, one policy baseline, and a stated rule for where a workload belongs. It is an architecture in its own right, not a transitional state.
Most hybrid estates were not designed; they accumulated. The symptom is two of everything — two identity stores, two patching processes, two sets of firewall rules — and a team that has to remember which one applies. The cost shows up as operational friction and as controls enforced in one place and assumed in the other.
When you need it
If more than one of these is true, this is usually the right place to start.
- Some systems cannot leave the data centre for regulatory or latency reasons, and the rest already left.
- Access to cloud and on-premises systems is granted in two different places, through two different processes.
- Traffic between the data centre and the cloud crosses the internet because the private link was never built.
- Nobody can say why a given workload runs where it runs.
What the scope covers
- Landing zone and account structure in which the on-premises estate is represented, not bolted on afterwards.
- Private connectivity design between sites and cloud regions, with DNS and routing that resolve consistently from both sides.
- Unified identity: one directory of record, federation, and conditional access applied on both sides of the boundary.
- Workload placement criteria covering data gravity, latency, licensing and exit cost, written down and applied per system.
- One policy baseline and one cost attribution model spanning both environments.
What you receive
| Deliverable | What it contains |
|---|---|
| Connectivity design | Private links, routing and DNS between sites and cloud regions, including the behaviour expected when a link degrades or is lost. |
| Identity model | Directory of record, federation and access policy applied identically to cloud and on-premises resources. |
| Placement criteria | The stated test for where a workload should run, with each current system assessed against it and the outliers named. |
| Policy baseline | Configuration, tagging and guardrail standards expressed once and enforced in both environments. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Share of workloads whose placement matches the documented criteria, reviewed on a set cadence.
- Access paths granted through the single identity model, measured against those still granted locally.
- Spend attributed to an owning service or team across both environments, measured as coverage of total cost.
Questions we are asked
Is hybrid a permanent architecture or a stage on the way to cloud?
For most organisations with regulated data or physical systems it is permanent, and treating it as temporary is exactly what leaves it ungoverned. Design it as an end state you are willing to operate. If a full move later becomes possible, a governed hybrid is a far easier starting point than an accidental one.
Do we need a private circuit, or is VPN enough?
It depends on bandwidth, latency sensitivity and how much you care about a predictable path. VPN over the internet is adequate for management traffic and modest volumes. Chatty application traffic and large transfers are where a dedicated circuit pays for itself. The useful test is what breaks when the link degrades rather than fails outright.
How do we decide where a workload should run?
Data gravity first: compute usually belongs near the data it reads most. After that, latency to dependent systems, licensing terms that change price by platform, regulatory constraints on data location, and the cost of moving it again later. Written criteria matter more than any single decision, because they make the next decision faster.
Can we use one set of tools across both environments?
For identity, monitoring, backup and policy the answer is usually yes and it is worth the effort, because two toolchains means two chances to miss something. For platform-specific capabilities it is often not worth forcing. An abstraction that hides what the platform actually does tends to become its own operational problem.
What about egress charges?
They are the line item most often missed in hybrid designs, and they are driven by architecture more than by usage discipline. Chatty traffic across the boundary is the expensive pattern. Placement and caching are the levers, and the modelling is worth doing before the design is fixed rather than after the first quarterly bill.
Does hybrid make security harder?
It makes security harder to reason about, which in practice is the same thing. The risk is a control enforced on one side and assumed on the other. Reducing the number of places a policy is defined is the highest-value move available, and it is why identity comes before connectivity in the sequence.
Continue reading
Cloud Optimization
Tagging, cost allocation, right-sizing and commitment planning for cloud spend you can attribute to a named owner and explain line by line.
Business Continuity
Impact analysis, RPO and RTO targets, failover design and tested runbooks, so recovery is something you have rehearsed rather than something you assume.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.