Cloud & hybrid briefing

Cloud, hybrid architecture, resilience and workload placement

Where workloads belong, how cloud dependencies fit together and what keeps hybrid environments recoverable.

AzureHybrid cloudArchitectureSecurityResilienceNetworking

Cloud is not one architecture. A SaaS application, an Azure virtual machine, an on-premises cluster managed through cloud services and a serverless application all place very different responsibilities on the customer. What they share is a shift in where infrastructure lives and who owns each part of the operating model.

This pillar is about the practical side of cloud and hybrid infrastructure: deciding where workloads belong, designing the dependencies around them and avoiding the assumption that moving something off-premises automatically makes it simpler or more resilient.

Last reviewed: 4 September 2026. Supporting guides are refreshed as new relevant articles are published.

The workload-placement continuum

Start with the workload, not the destination

A cloud migration can fail long before any technical error occurs if the workload was poorly understood. Latency, data gravity, licensing, support boundaries, integration, recovery objectives, security requirements and application lifecycle all influence placement.

I prefer to start by documenting the service: users, dependencies, data, criticality, recovery targets, traffic patterns, administrative model and realistic growth. Only then does it make sense to compare destinations. That process often produces a mixed answer, and that is fine. Hybrid is not automatically a failure to finish a migration; it can be the most rational architecture.

Hybrid cloud is an operating model

The difficult part of hybrid architecture is rarely connecting two networks. It is operating consistently across them. Identity, naming, monitoring, patching, vulnerability management, backup, secrets, certificates and change control need clear ownership when systems cross platform boundaries.

Cloud control planes can help. Azure Arc, central monitoring, policy and security tooling can provide visibility across local and cloud estates. But the benefit disappears if the result is simply another management layer that nobody trusts enough to use during an incident.

More relevant guides will appear here as this part of the site grows.

Resilience: cloud is not the same thing as backup

Cloud providers engineer enormous resilience into their platforms, but that does not remove customer failure modes. Accounts can be compromised. Data can be deleted. Applications can be misconfigured. Regions and dependencies can fail. A SaaS provider can meet its infrastructure availability target while a customer still loses access to business data.

Resilience therefore needs explicit failure scenarios. What if Entra ID is unavailable? What if a subscription is compromised? What if a region is inaccessible? What if ransomware encrypts synchronised data? What if the organisation needs a historic version the production platform no longer holds?

Backup, replication and high availability solve different problems. A useful cloud design says which one addresses each failure mode and proves recovery rather than relying on the word “cloud” as shorthand for safety.

Identity and network paths become more important, not less

Moving applications away from a local server room often reduces physical dependencies while increasing logical ones. DNS, internet connectivity, identity providers, private links, VPNs, routing and certificate services can become shared points of failure across multiple cloud services.

This is why cloud networking should be designed around service paths. Which user or system needs to reach which workload, through which control, with which fallback? A diagram that cannot answer that question is decoration rather than architecture.

Cloud security is shared responsibility in practice

The phrase “shared responsibility” is familiar, but its operational consequence is easy to underestimate. As services become more managed, responsibilities do not vanish; they move upward. The customer may stop patching an operating system but become more responsible for identity permissions, data classification, application configuration, API access and supplier governance.

Cloud security therefore starts with asset and identity clarity. Teams need to know what exists, who can change it, which logs prove what happened, where secrets are held and how emergency access works. The control plane deserves the same protection once reserved for physical datacentre administration.

Cost: elasticity cuts both ways

Cloud can turn capital spending into variable consumption, but variable does not mean cheap. The ability to create resources instantly also creates the ability to forget them instantly. Data transfer, storage tiers, backup retention, premium services and always-on development environments can become material costs without looking dramatic individually.

Good cost management is architectural. Right-sizing helps, but so do lifecycle rules, scheduling, sensible retention, ownership tags, reserved capacity where appropriate and choosing managed services because they reduce operational effort rather than simply because they are available.

My cloud architecture checklist

• What user or business outcome improves by changing placement?
• What are the service’s identity, DNS, network and data dependencies?
• What are the RPO and RTO, and has the recovery path actually been tested?
• Which failures require availability, which require replication and which require backup?
• Who owns patching, platform updates, keys, certificates and security configuration?
• How is cost attributed, reviewed and bounded?
• How would the organisation operate the workload if the primary cloud control plane were degraded?
• How difficult would it be to move or replace the service later?

Cloud articles and architecture analysis

Where cloud meets infrastructure

Cloud does not replace infrastructure knowledge; it changes where that knowledge is applied. The Enterprise Infrastructure pillar covers the compute, storage, networking, backup and operational foundations that remain relevant across local and cloud estates. For Microsoft-specific cloud decisions, see the Microsoft Technology pillar.