Cloud and on-premises architecture, compared by where the risk lands

Objective 3.1 asks you to compare and contrast architecture models by their security implications. That verb matters: you are rarely asked to define a cloud model in isolation, and often asked which one fits a stated requirement. This lesson takes on-premises and cloud, and the technical and business trade-offs used to choose between them. Operational technology, air gaps, segmentation and infrastructure as code are the next lesson.

Why this matters

Domain 3 is 19% of the exam, and it is the domain people find hardest to revise because it is not a list of terms -- it is a set of trade-offs. A question gives you a requirement and four architectures, and the right answer depends on which property the requirement cares about.

The most useful habit for this whole domain is to ask where the risk lands: who owns it, who can see it, and who is accountable when it fails. On-premises infrastructure is the baseline for that question, because there the answer is always "you" -- you own the building, the hardware, the hypervisor and every layer above. Every cloud model moves part of that answer to someone else, and none of them moves all of it.

The lesson

Public, private, hybrid and community clouds, and the responsibility line each draws

The four deployment models describe who shares the infrastructure.

• Public cloud -- a provider's infrastructure shared by many unrelated customers, isolated logically. Fast, elastic and cheap to start; you depend on the provider's isolation and you configure everything through their tools.
• Private cloud -- cloud-style infrastructure dedicated to one organisation, on its own premises or hosted. More control and easier compliance arguments, at a higher cost and with the operations work back on you.
• Hybrid cloud -- some workloads on-premises or private, some in public cloud, connected. The commonest real architecture, and its problems live at the connection, covered in the next section.
• Community cloud -- infrastructure shared by organisations with common requirements, such as government bodies or institutions in one regulated sector. Cost is shared and so is exposure: a neighbour's weakness is closer than it would be on a public platform.

Whichever deployment model you choose, the shared responsibility model states which tasks belong to the provider and which to the customer. The provider secures of the cloud -- facilities, hardware, hypervisor, its own services. The customer secures in the cloud, and how much that covers depends on the service bought:

The last row never moves. Your data and your access configuration are always yours, which is why most cloud incidents are customer-side -- an open storage bucket, an over-permissive role, a leaked key -- and why "the provider will handle it" is never the right answer to a data exposure question. A responsibility matrix records this for a specific provider, including the shared items such as logging, where the provider offers the capability and the customer must enable, retain and read it.

Multicloud, and the seam between two providers

Multicloud means using more than one public cloud provider. It is chosen to avoid dependence on one provider, to use each provider's strengths, or to survive one provider's outage. Hybrid and multicloud share a weakness: the security problems collect at the seam.

• Connectivity. The link between environments makes each reachable from the other, so a compromise on either side can cross.
• Identity. Directories synchronised or federated across environments make the synchronisation or federation trust one of the most privileged objects in the organisation.
• Inconsistent controls. Each provider has its own identity model, logging format, policy language and terminology. If one estate is hardened and logged and the other is not, your real posture is the weaker of the two.
• Monitoring gaps. Each side is watched by a different tool, and nothing correlates an event that crosses between them.
• Skills. Every additional platform needs people who know it well enough to configure it safely.

The exam's framing: multicloud buys resilience and flexibility and costs complexity, and complexity is itself a security risk because it produces misconfiguration. Lesson 27 returns to multicloud as a resilience control.

Serverless and microservices: the architecture with no host to harden

Serverless runs your code in response to events, with the provider managing everything beneath it. There is no server for you to patch, harden or log into. That is a real security gain -- a whole class of vulnerabilities stops being yours -- and it relocates the risk rather than removing it:

• the attack surface becomes the function's permissions and its event triggers. An over-permissive execution role is the serverless equivalent of an over-privileged server, and it is the commonest finding;
• dependencies packaged with the function are still yours to keep patched;
• monitoring must be built in deliberately, because there is no host agent;
• cost becomes an availability concern: a function triggered in a loop bills continuously, sometimes called denial of wallet.

Microservices split an application into many small services talking over APIs. The consequences: many more network interactions, each needing service-to-service authentication and authorisation; a much larger API surface; and harder tracing of a single transaction, which is why distributed tracing matters for investigation. The benefit is blast radius -- one compromised service is not the whole application, provided the services do not all trust each other implicitly.

Technical trade-offs: availability, resilience, recovery, compute, power and open versus proprietary

When a question asks which architecture to choose, the technical properties are weighed against each other:

• Availability and resilience. Cloud providers offer multiple zones and regions that an on-premises estate would struggle to match, but only if you design for them. A workload deployed into one zone is no more resilient than one rack.
• Ease of recovery. Infrastructure defined as code and data replicated across regions can be rebuilt quickly. A hand-built on-premises server is recovered only as fast as someone can rebuild it from memory and backups.
• Compute. Cloud scales on demand; on-premises capacity is what you bought. Specialised or very steady workloads can still favour owned hardware.
• Power requirements. On-premises means you supply power, cooling and backup power. In cloud the provider does, and you inherit their resilience choices.
• Proprietary versus open source. Proprietary services can be quicker to adopt and come with a vendor accountable for support, at the price of lock-in and limited visibility into the code. Open source can be inspected, forked and moved between providers, and you depend on its community or your own staff for fixes.
• Usability. A control people cannot operate correctly will be misconfigured or bypassed. Simpler often beats more capable.
• Responsibility. The line from the first section is itself a technical consideration: choose a model whose share of the work you can actually staff.

Business trade-offs: sovereignty, classification, cost, ownership, scale and risk

The business side often decides before the technical side gets a vote.

• Data sovereignty. Data is subject to the laws of where it is stored and of who holds it. Some data must stay in a country, so region choice is a compliance decision. Lesson 26 takes the jurisdiction question in full.
• Data classification. The most sensitive data may be confined to private infrastructure or to specific services by policy or regulation.
• Cost. Cloud turns capital spending into operating spending; it is cheaper to start and can be dearer at steady scale. Security tooling and skills are part of the cost on both sides.
• Ownership. Who owns the infrastructure, the data and the keys, and what happens to all three when a contract ends.
• Environmental requirements. Physical conditions, energy use or sustainability targets can rule a site or a provider in or out.
• Scalability. How quickly capacity must grow, and whether the architecture can follow without a redesign.
• Risk. The organisation's appetite for depending on a third party, weighed against the risk of running everything itself.

What to take into the exam

• On-premises means every layer is yours; every cloud model moves some of that and never your data or access configuration.
• Public is shared by strangers, private is dedicated, community is shared by organisations with common needs, and hybrid mixes them.
• Hybrid and multicloud problems live at the seam: connectivity, identity, inconsistent controls and monitoring gaps.
• Serverless removes host hardening and moves risk to function permissions and triggers; microservices shrink blast radius only if services do not trust each other implicitly.
• Choose architecture by the stated requirement: availability, recovery, sovereignty, classification, cost or ownership.