Cloud Strategy - Part I: Understanding the Cloud

Cloud adoption is not just moving infrastructure to a provider’s data centers. It is a shift in how IT is consumed, funded, secured, governed, and operated. This article explains why cloud requires new thinking around service consumption, OpEx, automation, elasticity, shared responsibility, security, governance, and FinOps.

This series provides an annotated review, summary and analysis of Gregor Hohpe’s book, Cloud Strategy, available at leanpub.com/cloudstrategy.

Executive Summary

Cloud adoption is not simply a migration from on-premises infrastructure to a provider’s data centers. It is a broader and complex shift in how IT is consumed, funded, secured, governed, and operated. Traditional on-premises IT is built around ownership: organizations acquire physical assets, plan capacity in advance, manage hardware and software stacks, and operate through procurement cycles, manual processes, and long-term commitments. The cloud model changes this logic by offering infrastructure, platforms, data, security, and analytics capabilities as on-demand services.

This transition moves IT from a CapEx-heavy model, based on upfront investment and depreciation, toward a more flexible OpEx model based on measured consumption. However, the cloud does not automatically reduce costs. Savings must be earned through architecture, automation, cost visibility, elasticity, managed services, and disciplined FinOps practices.

Operationally, the cloud replaces static planning with dynamic elasticity , manual provisioning with self-service, and configuration through tickets with Infrastructure as Code and automation-first operations. This enables faster delivery, experimentation, resilience, and global reach, but it also requires stronger governance, identity management, cost accountability, and security discipline.

Security and compliance also change significantly. In the public cloud, organizations no longer directly control the physical infrastructure. Instead, they rely on logical isolation, encryption, identity and access management, policies, logging, monitoring, and automated guardrails. The shared responsibility model becomes central: the provider secures the underlying cloud platform, while the customer remains responsible for workloads, data, identities, configurations, and service usage.

The main strategic message is that cloud should not be treated as a simple IT outsourcing contract or a cheaper hosting location. It is a new operating model. Organizations that benefit most from cloud are those that rethink procurement, operations, architecture, governance, security, and financial management around speed, automation, service consumption, and continuous improvement.

Cloud Computing: Cutting Through the Noise

The cloud landscape is crowded with confusing terminology, abbreviations, and trendy phrases. To establish a clear foundation, let's simplify these concepts.

The most cited official definition is from NIST SP 800-145, The NIST Definition of Cloud Computing :

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

NIST, which refers to the National Institute of Standards and Technology (a US federal body), identifies five fundamental pillars of the cloud model :

• On-demand self-service: A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
• Broad network access: Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
• Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).
• Rapid elasticity: Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
• Measured service: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

NIST also defines three service models (SaaS, PaaS, and IaaS), and four deployment models (private cloud, community cloud, public cloud, and hybrid cloud).

Service models: SaaS, PaaS, IaaS

Cloud service models are effectively a hierarchy of shared responsibility. As you move up the stack, the cloud provider assumes greater management of the underlying infrastructure.

IaaS: Infrastructure as a Service

With IaaS the cloud provider offers you low-level computing resources and building blocks: servers, storage, network, load balancers, and so on. Even if you do not buy physical servers, you are still managing the software stack, e.g. install Linux on an EC2 virtual machine, deploy the application, patch the OS, manage backups.

Good for: flexibility, migrations, custom architectures, legacy workloads.
Trade-off: you still have to operate a lot yourself.

PaaS: Platform as a Service

With PaaS , you deploy code or containers, and the platform handles the runtime, scaling, patching, load balancing, and infrastructure management. For example: Azure App Service, Google App Engine, Elastic Beanstalk.

Good for: faster application delivery, less operational burden, standard web/API workloads.
Trade-off: less low-level control and more dependency on the provider’s platform model.

SaaS: Software as a Service

With SaaS , you access a complete application over the network. You do not manage servers, operating systems, databases, runtimes, or application code. For example, Amazon Connect and QuickSight. AWS is best known as an infrastructure and platform cloud provider, although it also offers some SaaS-like business applications.

Good for: standard business capabilities where building or operating your own software adds little differentiation.
Trade-off: limited customization compared with building your own application.

Deployment models: private, community, public, hybrid

Deployment models describe who the cloud is for and how it is made available.

Private cloud

A private cloud is dedicated to one organization. It may run in the company’s own data center or be hosted by a third party, but it is not shared with unrelated customers.

Important nuance: a private cloud is not just “virtualization.” To be a real cloud, it should still provide the cloud characteristics: self-service, resource pooling, elasticity, measured usage, and automation.

For example, European providers such as OVHcloud, Aruba Cloud, and IONOS may offer alternatives to hyperscale public cloud or dedicated/hosted cloud options, depending on the service.

Community cloud

A community cloud is shared by several organizations with common needs, such as compliance, security, jurisdiction, or mission. Example: several government agencies sharing a cloud platform designed around public-sector requirements.

This model is less commonly discussed than public, private, and hybrid cloud, but it is part of the NIST definition. Adjacent examples include government cloud regions such as AWS GovCloud and Azure Government, and research cloud federations such as the European Open Science Cloud.

Public cloud

A public cloud is operated for broad use by many customers. The infrastructure is owned and operated by a cloud provider, and customers consume services over the network. Examples include AWS, Microsoft Azure, Google Cloud, Oracle Cloud, and Alibaba Cloud.

So, from now on, for “Cloud” I will only mean Public Cloud, like AWS, Azure, Google Cloud. Also, the main focus for technical details will be AWS, that is the cloud platform I know better. 

Market share 

This includes data from the Synergy/CRN breakdown for Q3 2025:

Hybrid cloud

A hybrid cloud combines two or more distinct cloud environments, such as private cloud plus public cloud, or multiple clouds connected together in a coordinated architecture.

Example: a company keeps some sensitive systems in a private cloud or on-premises environment while running customer-facing applications in AWS or Azure.

A key point: hybrid cloud is not simply “we have some servers on premises and some in AWS.” There must be some form of integration, such as identity, networking, data flows, governance, monitoring, or workload portability.

On-premises and the cloud

Overview

The following table will give you an overview of the main differences between on-premises (datacenter) and the cloud. 

Infrastructure Ownership versus Service Consumption

In a conventional on-premises setup, an organization typically manages the entirety of its physical assets . This includes leasing or owning data center facilities, servers, network hardware, storage arrays, and firewalls, along with the associated power, cooling, and security systems. Procurement in this model usually involves a cycle of product selection, contract negotiation, and integration into established operational workflows.

A significant drawback of this approach is the reliance on costly, long-term licenses that often lead to deep vendor lock-in.

The cloud model shifts this paradigm toward the consumption of infrastructure and platforms as services . Rather than the manual effort of installing and maintaining physical hardware, teams utilize APIs, automation frameworks, and service catalogs to provision resources like compute, storage, and databases.

This shift represents more than just a change in location; it is a fundamental transformation in how IT is consumed. The cloud serves as a comprehensive platform for data, analytics, and security, requiring organizations to move beyond treating it as a simple IT project. Embracing the cloud necessitates a "lifestyle change" where procurement and operational processes are entirely re-evaluated. This principle is often ignored or underestimated by business leaders, and the consequences are significant: slower migrations, higher costs, weaker governance, and missed opportunities to capture the real value of cloud adoption.

On-premises: Focusing on the acquisition and operation of physical assets.

Cloud: Focusing on the consumption of capabilities as on-demand services.

CapEx versus OpEx

The transition to cloud computing introduces a fundamental shift in how IT is funded. In a traditional on-premises environment, organizations typically rely on capital expenditure (CapEx) , where capacity is purchased upfront based on long-term demand forecasts. This infrastructure is then treated as a physical asset and depreciated over its lifecycle.

Conversely, the cloud operates primarily on an operational expenditure (OpEx) model. Here, services are consumed as needed, with costs tied to granular metrics such as hourly usage, storage volume, or transaction counts . While this pay-as-you-go approach alters the financial logic of IT, it does not guarantee immediate savings. According to Gregor Hohpe in Cloud Strategy , cloud savings must be "earned" through diligent cost management, automation, and the use of elastic architectures.

• Capital Expenditure (CapEx): Aligned with on-premises IT, this involves significant upfront costs for hardware and perpetual licenses, which are depreciated over time on the balance sheet.
• Operational Expenditure (OpEx): Aligned with the cloud model, this involves variable fees for ongoing service consumption. These expenses are typically deducted from taxable income during the period they occur.

On-premises : models favor large upfront investments and long depreciation cycles.

Cloud : models prioritize usage-based billing and dynamic scalability.

Static Planning versus Dynamic Elasticity

Traditional on-premises setups rely on rigorous capacity planning. This forecasting process inherently risks under-provisioning, which causes service disruptions, or over-provisioning, which leads to capital wasted on underutilized hardware.

Cloud computing addresses these challenges via elasticity , allowing for nearly instantaneous resource provisioning and release. Such flexibility is essential for digital products with fluctuating demand, including intensive batch jobs or seasonal retail surges. Nevertheless, realizing the full potential of elasticity necessitates an application architecture and operating framework capable of autonomous scaling.

On premises : cycles that span months or years

Cloud : facilitates dynamic capacity scaling to meet requirements in real time.

Procurement process versus self-service

Traditional infrastructure procurement can involve budgets, purchase orders, vendor negotiations, delivery lead times, installation, configuration, and approvals. Provisioning a server may take weeks or months.

Cloud introduces on-demand self-service. Teams can provision approved resources directly, often in minutes or seconds, without waiting for hardware procurement or manual installation.

This is one of the most important differences for business agility. The value is not only that infrastructure appears faster; the value is that teams can experiment, test, deploy, and learn faster.

On premises : request, approve, procure, install, configure.
Cloud : provision through self-service and automation.

Manual configuration versus Infrastructure as Code

In traditional environments, infrastructure is often configured manually by operations teams and documented across tickets, spreadsheets, diagrams, and runbooks. Automation is certainly possible with tools such as Chef, Puppet, or Ansible , but it is typically layered on top of the environment rather than being deeply integrated into the platform itself. 

In the cloud, by contrast, infrastructure is exposed through APIs from the start, making automation and Infrastructure as Code a more natural part of the operating model: infrastructure can be described as code . Networks, subnets, firewall rules, IAM roles, databases, compute instances, Kubernetes clusters, monitoring alarms, and storage buckets can be defined in templates and deployed automatically.

Infrastructure as Code changes the nature of operations , making infrastructure repeatable, version-controlled, peer-reviewed, reusable, auditable, easier to recreate after failure.

On premises : infrastructure often managed through manual processes and change tickets.
Cloud : infrastructure increasingly managed through code, pipelines, and policy automation.

Static environments versus disposable environments

In many on-premises environments, servers are treated as long-lived assets. They are named, maintained, patched, repaired, and preserved for years.

In cloud-native thinking, infrastructure should be more disposable. If a server or container fails, you replace it. If an environment is corrupted, you recreate it. If a deployment fails, you roll back or redeploy. This changes the mindset from “protect every server” to “design systems that survive component failure.”

On premises : infrastructure often treated as precious and long-lived.
Cloud : infrastructure can be treated as replaceable and disposable.

Hardware-centric view versus application-centric view

In traditional IT, conversations often start with servers, storage, networks, and data centers.

In the cloud, the more useful question is: what does the application need? Hohpe makes this point strongly: “no one wants a server.” The business wants applications, customer experiences, availability, insight, and speed. The server is only a means to an end.

On premises : infrastructure is often the starting point.
Cloud : the application and business outcome should be the starting point.

Infrastructure services versus managed services

In an on-premises environment, the company usually operates much of the stack itself : operating systems, databases, middleware, backup systems, monitoring platforms, message brokers, data warehouses, and security tools.

In the cloud, many of these capabilities are available as managed services. The provider operates the underlying infrastructure and some or most of the platform layer.

Managed services are one of the biggest differentiators of cloud. They allow teams to focus less on operating commodity platforms and more on building business value. The cloud is an ecosystem of services, not just a platform to run applications.

On premises : you operate more of the stack.
Cloud : the provider operates more of the stack.

Fixed infrastructure cost versus measured service

Cloud platforms provide detailed billing metering. Usage can be measured by account, team, application, environment, service, tag, region, time period, or resource type.

This enables a level of financial transparency that is often difficult in traditional IT.

This creates the need for FinOps: the discipline of connecting engineering, finance, and business teams to manage cloud value and cost continuously. In a data center, once infrastructure has been purchased, the marginal cost of waste may be invisible. In the cloud, unused resources show up on the bill.

On premises : cost is often allocated through budgets, depreciation, and internal chargeback models.
Cloud : cost can be metered and attributed with much more granularity.

Local data centers versus global presence

A traditional enterprise data center is usually located in a small number of physical locations. Expanding globally requires major investments, contracts, facilities, networking, compliance work, and operational capacity.

Large cloud providers offer global regions, availability zones , edge networks, and content delivery capabilities. This makes it easier to deploy applications closer to users, design for geographic resilience, meet some data residency requirements, and build disaster recovery across regions.

On premises : global expansion requires new facilities or hosting contracts.
Cloud : global infrastructure is already available as a platform capability.

Redundancy through spare capacity versus resilience through design

Traditional resilience often depends on redundant hardware : backup servers, secondary data centers, duplicated storage, and expensive standby capacity.

Cloud still uses redundancy, but it also encourages resilience through architecture : multiple availability zones, automated replacement, load balancing, autoscaling, managed databases, immutable deployments, queues, retries, and multi-region patterns.

The difference is that resilience becomes more software-defined and architecture-driven.

On premises : resilience often depends on pre-purchased redundant infrastructure.
Cloud : resilience can be designed through managed services, automation, and distributed architectures.

Perimeter security versus identity-centric security

Traditional environments often rely heavily on network perimeter security : firewalls, network segmentation, VPNs, and trusted internal networks.

Cloud environments require a stronger identity-centric model. Identity and access management becomes the new control plane. Every user, service, application, workload, and automation pipeline needs carefully managed permissions.

On premises : security often starts from the network perimeter.
Cloud : security starts from identity, policy, configuration, encryption, and continuous monitoring.

Manual governance versus guardrails and policy as code

Traditional governance often depends on approvals before work can proceed. A team submits a request, a committee reviews it, and another team implements it.

Cloud makes this model difficult because resources can be created quickly and at scale. The better model is automated governance : define what is allowed (e.g. AWS Service Control Policies), prevent dangerous configurations, detect violations, and remediate automatically.

On premises : governance often relies on manual control.
Cloud : governance should rely on automated guardrails.

Slow release cycles versus faster delivery pipelines

Cloud is closely connected to modern software delivery practices.

Because infrastructure can be automated, environments can be created quickly, and services are accessible through APIs, teams can build CI/CD pipelines that test, deploy, and release software more frequently. Arguably, you can reach similar results also on premises, but, generally speaking, the cloud environment is better suited for this. 

On premises : infrastructure constraints often slow delivery.
Cloud : delivery can be accelerated through automation and platform services.

Centralized operations versus shared responsibility

Cloud does not remove operational responsibility. It changes who is responsible for what.

The cloud provider is responsible for the security and operation of the underlying cloud platform. The customer remains responsible for how services are configured and used : identity, data, applications, access policies, network exposure, logging, compliance, and architecture. The more managed the service, the more the provider operates. But the customer never becomes responsibility-free.

On premises : the company is responsible for nearly everything outside the physical datacenter.
Cloud : responsibility is shared between provider and customer.

Technology ownership versus product/platform thinking

In an on-premises model, infrastructure teams are often organized around technologies: server team, network team, storage team, database team, security team.

Cloud encourages product and platform thinking. A central cloud or platform team should not simply become a ticket-based infrastructure team in a new environment. Its job should be to provide reusable capabilities, paved roads, self-service platforms, templates, security guardrails, cost visibility, and developer enablement.

On premises : teams often align around technical silos.
Cloud : teams increasingly align around platforms, products, and end-to-end value streams.

Fixed environments versus experimentation

In traditional IT, creating a new test environment, with new technologies and tools, can be expensive and slow. This discourages experimentation.

In the cloud, temporary environments can be created for development , testing, proof of concepts, training, analytics, or short-lived campaigns. When no longer needed, they can be deleted. This changes how teams innovate.

On premises : experimentation competes with scarce capacity.
Cloud : experimentation becomes easier, cheaper, and faster when properly governed.

Slow hardware refresh cycles versus continuous platform evolution

On premises, technology changes through refresh cycles. Hardware may be replaced every three to five years. Major platform upgrades may be planned months in advance.

Cloud providers continuously release new services, instance types, regions, database capabilities, AI services, security features, and operational tools. This creates an advantage but also a challenge: cloud strategy is never finished. Teams must continuously learn and reassess what should be built, bought, consumed, replaced, or retired.

On premises : innovation follows internal refresh and upgrade cycles.
Cloud : innovation arrives continuously from the provider ecosystem.

Full control versus less control but more leverage

On premises gives the company direct control over hardware , physical location, network appliances, storage systems, and low-level infrastructure choices.

Cloud reduces some forms of control. You do not control the provider’s physical data centers, hardware lifecycle, internal implementation, or service roadmap. But the cloud increases leverage. You gain access to global infrastructure, managed services, automation APIs, advanced security capabilities, high-scale platforms, and innovation that would be unrealistic for most companies to build alone.

On premises : more direct control, more operational burden.
Cloud : less physical control, more platform leverage.

Data center availability versus service-level architecture

In traditional environments, availability is often discussed in terms of data center uptime, hardware redundancy, and infrastructure SLAs.

In the cloud, application availability depends mostly on how the architecture uses cloud services. Running an application on one virtual machine in one availability zone is very different from designing it across multiple zones with managed databases, load balancing, autoscaling, and automated recovery. Cloud provides building blocks for high availability, but the architecture must use them correctly.

To be precise, application availability in the cloud is also affected by the availability of the cloud infrastructure itself. All the big players of the cloud periodically find their way into the news for major outages that can last hours or even days.

On premises : availability often maps to infrastructure redundancy.
Cloud : availability depends on service architecture and failure design.

Internal network access versus internet-native access

On-premises systems often assume internal corporate networks, private connectivity, VPNs, and trusted enterprise boundaries.

Cloud services are designed for broad network access through standard mechanisms. This does not mean everything should be public. It means access models are usually API-based, identity-aware, encrypted, and designed for distributed users, applications, and services.

On premises : access often assumes a corporate network.
Cloud : access is designed for distributed, internet-scale environments.

Backup as infrastructure versus backup as policy

In an on-premises environment, backup often requires dedicated systems, storage, schedules, tapes or appliances, replication tools, and operational teams.

In the cloud, backup can often be defined through service policies : snapshots, object versioning, lifecycle rules, cross-region replication, managed backup services (e.g. AWS Backup), and archival storage classes. This does not remove the need for backup strategy, restore testing, retention design, and compliance. But it changes the implementation model.

On premises : backup is often a separate infrastructure platform.
Cloud : backup can be policy-driven and service-integrated.

Disaster recovery as a major project versus disaster recovery as architecture

Traditional disaster recovery often requires a second site, duplicated hardware, replication contracts, periodic tests, and complex runbooks.

Cloud can reduce the barrier to disaster recovery by allowing infrastructure to be defined as code, environments to be recreated, and data to be replicated across regions or accounts. However, cloud disaster recovery is not automatic. Recovery time, recovery point, dependencies, DNS, identity, application state, and testing must still be designed and planned for.

On premises : disaster recovery often requires duplicate physical infrastructure.
Cloud : disaster recovery can be automated and architecture-driven.

IT as a cost center versus IT as a value engine

In traditional environments, IT is often seen as a cost center that must control spending and keep systems running.

In cloud-enabled organizations, IT can become a value engine : launching products faster, entering new markets, scaling digital services, improving customer experience, enabling analytics, and accelerating experimentation. This is one of the most important messages for business leaders. The cloud is not mainly about cheaper servers. It is about changing the speed and flexibility of the business.

On premises : IT often focuses on asset management and operational stability.
Cloud : IT can focus more on speed, value, experimentation, and business capability.

Traditional outsourcing versus cloud outsourcing

Cloud is a form of outsourcing because the provider operates the underlying infrastructure. But it is very different from traditional outsourcing. Traditional outsourcing often works through contracts, tickets, service requests, and long commitments. 

Cloud works through APIs, self-service, transparency, metering, and rapid provisioning. This distinction matters. Cloud should not be treated as another outsourcing contract. It requires internal competence in architecture, security, automation, cost management, and governance.

On premises: request-driven and contract-heavy.
Cloud: API-driven, transparent, elastic, and service-oriented.

Standardization by restriction versus standardization by reusable patterns

On premises, standardization often means restricting choices: approved server types, approved databases, approved middleware, approved network patterns.

In the cloud, standardization can be achieved through reusable patterns : landing zones, account structures, network blueprints, reusable Terraform modules, approved container images, security baselines, policy-as-code libraries.

On premises : standardization often means limiting options manually.
Cloud : standardization can be embedded into reusable automated patterns.

Physical inventory versus digital inventory

Traditional infrastructure inventory is often stored in CMDBs, spreadsheets, monitoring tools, procurement systems, and network diagrams. It may be incomplete or outdated.

Cloud resources are created through APIs and can be discovered, tagged, queried, inventoried, and monitored continuously. This makes better asset visibility possible, but only if tagging, account structure, naming, ownership, and governance are designed properly.

On premises : inventory is often manually maintained, or requires third-party tools.
Cloud : inventory can be continuously discovered and governed.

Scarcity mindset versus abundance with responsibility

On premises, infrastructure is scarce. Teams compete for capacity, environments, and operations attention.

Cloud creates a (sometimes false) sense of abundance. Teams can create resources quickly. But abundance without responsibility leads to waste, security risk, and architectural sprawl. The mature cloud mindset is not “use whatever you want.” It is “use what you need, with visibility, ownership, and guardrails.”

Caveat : Cloud elasticity does not mean infinite guaranteed capacity. In AWS, on-demand EC2 capacity is usually available, but it is not guaranteed for every instance type, Availability Zone, or moment in time. For business-critical workloads that must scale rapidly to a specific capacity level, you may need to use EC2 Capacity Reservations, Capacity Blocks, diversified instance types, multiple Availability Zones, or other capacity-planning techniques.

On premises : scarcity limits speed.
Cloud : abundance increases speed but requires discipline.

Migration destination versus continuous journey

On premises often gives the impression of a stable target state: build the data center, deploy the platform, operate it for years.

The cloud is continuously evolving. New services, pricing models, security features, regions, architectures, and best practices appear constantly. This means cloud adoption is not a one-time migration project. It is a continuous capability.

On premises : relatively stable infrastructure lifecycle.
Cloud : continuous evolution and continuous decision-making.

Owned versus shared infrastructure

One of the deepest differences between an on-premises environment and the public cloud is the move from owned infrastructure to shared infrastructure.

In a traditional on-premises model, the company usually owns, leases, or directly controls the physical infrastructure : servers, storage systems, network devices, racks, data center rooms, physical access controls, backup systems, and sometimes even the building itself. Even when some operations are outsourced, the environment is typically dedicated to one organization.

In the public cloud, the underlying infrastructure is shared. The cloud provider operates massive pools of compute, storage, networking, and platform services used by many customers at the same time. Each customer is logically isolated, but the physical platform is common.

This is one of the foundations of cloud economics. Sharing infrastructure allows the provider to achieve economies of scale , higher utilization, global capacity, and lower unit costs. But it also changes the security, compliance, governance, and legal model.

In an on-premises environment, the organization trusts its own facilities, people, tools, and processes. In the public cloud, the organization also trusts the cloud provider’s isolation mechanisms, operational discipline, legal commitments, compliance controls, and service architecture.

This is not necessarily worse. In many cases, the cloud provider’s controls are stronger than what an individual company could build alone. But the responsibility model changes. Security, compliance, data governance, and legal risk must be redesigned around shared infrastructure, not simply copied from the on-premises world.

Noisy neighbours are a risk in shared cloud environments where multiple customers or workloads run on the same underlying physical infrastructure. If one workload suddenly consumes a lot of shared resources — such as CPU, disk I/O, memory bandwidth, or network capacity — it can degrade the performance of other workloads sharing the same platform.

On premises : dedicated infrastructure, no noisy neighbours.
Cloud : shared infrastructure, economy of scale.

Cloud works best in economies of speed 

Hohpe contrasts traditional “economies of scale” with modern “economies of speed.” 

Traditional IT assumes that change is exceptional: define a project, plan the target state, execute, and return to business as usual. Digital businesses operate differently. They assume continuous change. They learn through experimentation, adapt quickly, and measure progress through speed, feedback, and value delivered. Cloud fits this model because it prices and provisions resources dynamically. Instead of buying infrastructure upfront, companies consume capacity as needed. This is why the book says cloud “thinks in the first derivative”: it is concerned with rates of change, consumption, velocity, and burn rate rather than static assets and fixed budgets. 

On premises : change is the exception.
Cloud : continuous change and experimentation.

Procurement versus consumption

Two classic examples of existing processes that won’t mesh with the cloud model are procurement and operations.

Traditional IT budgets are set up at least a year in advance, making predictability a key consideration. IT procurement tends to negotiate multiyear license terms for the software they buy. They “lock in discounts” by signing up for a larger package to accommodate any increase in usage over time, despite not being able to fully utilize it right from the start.

The cloud’s critical innovation, and the reason it’s turned IT upside down, is its elastic pricing model: you don’t pay for resources up front but only for what you actually consume. Because traditional scoring doesn’t work well for clouds, a better approach is to compare your company’s vision with the provider’s product strategy and philosophy.

On premises : multiyear contracts and discounts.
Cloud : pay for consumption, discount plans available.

Security and legal aspects of the cloud

Logical isolation

In an on-premises environment, security often starts with physical and network control. The company controls who enters the data center, which hardware is installed, how networks are segmented, and which systems are physically connected.

In the public cloud, the customer no longer controls the physical infrastructure. Instead, security depends heavily on logical isolation and software-defined controls : identity and access management, encryption, virtual networks, security groups, policies, keys, logging, monitoring, and automated guardrails.

This does not mean the cloud is less secure. Large cloud providers usually have far stronger physical security, hardware security, monitoring, and operational discipline than most individual enterprises can build themselves. But the customer must understand that the security model has changed. The provider secures the underlying cloud infrastructure. The customer secures how cloud services are configured and used.

This is known as the shared responsibility model. AWS describes security and compliance as a shared responsibility: AWS manages and controls components from the host operating system and virtualization layer down to the physical facilities, while customers remain responsible for their workloads, data, identities, configurations, and service usage.

Multi-tenancy

A common misunderstanding is that “shared infrastructure” means customers’ data is mixed together. That is not how a public cloud is designed. Cloud platforms use isolation mechanisms between tenants , such as virtualization, container isolation, identity boundaries, network segmentation, encryption, and access control.

However, multi-tenancy still changes the risk model. The customer must trust that the provider’s isolation mechanisms work correctly. Vulnerabilities in hypervisors, container runtimes, managed services, firmware, identity systems, or control planes can become very important because many customers depend on the same underlying platform.

In on-premises environments, a hardware or virtualization flaw usually affects one organization. In the public cloud, a serious shared-platform flaw could theoretically affect many customers, even if providers invest heavily to prevent this.

Compliance

In an owned environment, the company can directly document, inspect, and audit much of the infrastructure . It can show where servers are located, who has physical access, how backups are stored, and how network devices are configured.

In the cloud, the company cannot personally inspect every data center or physical server. Instead, it relies on the provider’s certifications, audit reports, compliance programs, contractual commitments, and technical controls.

Cloud compliance therefore requires mapping responsibility. For each regulation or internal policy, the organization must identify whether the control is provider-managed, customer-managed, or shared.

Data governance

In an on-premises environment, data location may be easier to conceptualize: data is in the company’s data center, backup site, or storage platform.

In the cloud, data may exist across multiple services and forms: object storage, databases, snapshots, logs, metrics, queues, analytics platforms, machine learning datasets, backups, replicas, temporary caches, and metadata.

This makes data governance more important, not less.

A company must define:

• what data is allowed in the cloud;
• which regions may be used;
• which services may store regulated data;
• how data is classified;
• who owns each dataset;
• how encryption keys are managed;
• how long data is retained;
• how backups and replicas are handled;
• whether logs contain personal or sensitive data;
• whether metadata is also sensitive;
• how data is deleted or exported.

Cloud makes it easy to create copies of data. That is useful for analytics, resilience, and backup, but dangerous without governance.

Legal jurisdiction

With owned infrastructure, legal jurisdiction is often easier to reason about because the company knows where the data center is, which legal entity operates it, and which country’s law applies.

In a public cloud, the picture is more complex. The customer may choose a European region, but the provider may be headquartered in another country. Support, operations, billing, metadata, subcontractors, and legal obligations may involve multiple jurisdictions.

For European organizations, this is especially important because GDPR restricts transfers of personal data outside the EEA unless the transfer complies with Chapter V of the GDPR. The European Data Protection Board explains that personal data may only be transferred outside the EEA in compliance with those conditions, to ensure that the level of protection remains essentially equivalent.

This is why “data residency” and “data sovereignty” are not the same. A cloud region in Europe can help with residency, but sovereignty also depends on contracts, encryption, key management, support access, metadata handling, operational control, and legal jurisdiction.

Government access

In an owned data center, a government request or seizure is usually directed at the organization operating the environment.

In the public cloud, government access concerns can involve both the customer and the provider. A public authority may request data from the customer, but in some circumstances it may also issue legal requests to the cloud provider, depending on applicable law.

This does not mean governments can freely access cloud data. Major providers usually require valid legal process, publish transparency reports, and may challenge overbroad requests. But from a risk-management perspective, the customer must consider provider jurisdiction and legal exposure.

This is one of the reasons why sovereign cloud offerings exist. They try to reduce the risk by adding stronger controls around data location, operational access, local governance, encryption, and support personnel.

Encryption and key management

In a shared infrastructure model, encryption becomes more than a technical best practice. It becomes a governance and legal control. For highly sensitive workloads, the key question is not only “is the data encrypted?” but “ who controls the keys? ”.

If the customer controls the keys properly (outside the cloud itself), the risk of unauthorized provider-side access is reduced or removed completely. However, key management also introduces operational responsibility: losing keys may mean losing access to data.

Auditability and transparency

Cloud can improve auditability because many actions are API-driven and can be logged: who created a resource, who changed a policy, who accessed a secret, who modified a network rule, who copied data, and which service generated cost.

This can be better than many traditional environments, where changes may happen manually and documentation may be incomplete. However, the cloud also creates more things to audit. There are more services, more identities, more machine roles, more APIs, more logs, more regions, more accounts, more automation pipelines, and more temporary resources.

The audit model changes from periodic inspection to continuous monitoring.

Incident response

In an on-premises environment, the organization can inspect servers, storage, network devices, logs, and physical infrastructure directly.

In the cloud, the customer can only investigate what it controls: accounts, workloads, logs, IAM, network configuration, application behavior, data access, and service usage. The provider investigates the underlying cloud platform. This requires new incident response playbooks, written from scratch for the cloud environment.

Data deletion and lifecycle

In an owned environment, data deletion is still difficult, but the organization has more direct control over disks, tapes, backup systems, and retention policies.

In the cloud, data may exist in multiple layers: primary storage, replicas, snapshots, backups, logs, archives, managed service internals, and disaster recovery copies. Cloud providers usually offer documented deletion and retention mechanisms, but the customer must understand how each service handles data lifecycle.

The dark side of the cloud

Cloud is powerful, but it is not automatically cheaper, safer, simpler, or more resilient. It reduces some risks while introducing others: concentration risk, cost volatility, identity complexity, operational skill gaps, and provider dependency. Successful cloud adoption requires conscious architecture choices, strong governance, continuous cost management, security maturity, and a clear understanding that cloud is not a destination, but an ongoing operating model.

Outages: when it rains, it pours

Parametrix is an insurance and analytics company focused on digital business interruption risk, especially outages of cloud platforms, CDNs, ecommerce platforms, and other critical third-party digital services.

The 2025 Cloud Outage Risk Report by Parametrix highlights a significant shift in the cloud reliability landscape, driven by the rapid adoption of Artificial Intelligence (AI) and increasing compute demands. While overall cloud stability improved in 2025 compared to the previous three years , the impact of specific regional failures remained substantial.

Reliability of cloud providers:

• Reliability Trends: After a surge in downtime from 2022 to 2024, 2025 saw an 8.2% decrease in the number of "critical" downtime events (from 49 to 45). The duration reportedly fell from 244.8 hours in 2024 to 175.3 hours in 2025. This improvement was primarily due to a stable first half of the year.
• Service and Regional Impact: North America remains the most volatile region, accounting for over half of all cloud events in 2024 and 2025. Major disruptions occurred in key regions like AWS us-east-1 and GCP us-central1. Compute services continue to be the primary driver of downtime.
• Root Causes: Human error is the leading cause of all cloud events (51% of critical events). However, power outages (30% of critical events) have a disproportionately high impact, often triggering total service failures despite being relatively rare.

Major 2025 Incidents:

• Google Cloud (June 12): A faulty quota policy update caused a nearly three-hour outage, severely affecting the us-central1 region.
• AWS (October 20): A DNS and automation failure in us-east-1 resulted in over 14 hours of disruption, with estimated financial losses between $500 million and $650 million for US companies.
• Microsoft Azure (October 29): A configuration change in Azure Front Door led to global latency and connectivity issues lasting over 8 hours.

Vendor Lock-in

Operating your own facilities centers risk locally: you are responsible for the physical data center, networking stacks, hardware lifecycles, internal personnel, and vendor relationships.

While the cloud mitigates these local vulnerabilities, it introduces concentration risk. A single hyperscale provider, specific region, or foundational service like IAM or DNS can become a critical single point of failure for an entire application portfolio.

This isn’t to suggest the cloud is fragile—providers invest billions in resilience—but it necessitates that cloud architecture must account for systemic dependency risk.

The power of the public cloud lies in managed services where customers leverage a shared, provider-run platform. This allows organizations to consume databases, analytics, and AI capabilities as utility-grade services rather than building everything from scratch.

However, these capabilities create a trade-off. Deep utilization of provider-specific features can accelerate velocity, yet it simultaneously increases the complexity of any future migration . Resisting these services may minimize lock-in, but often at the cost of the cloud’s inherent value.

Lock-in is a commercial reality as much as a technical one. Regulatory bodies like Ofcom have noted that egress fees, committed-use discounts, and platform restrictions can make multi-cloud strategies or provider switching difficult for enterprises.

The cloud promises agility, yet financial structures often incentivize concentration. Once your data, automation pipelines, and technical expertise are tethered to one ecosystem, the notion of "choice" may become largely academic.

Managed services represent the cloud’s greatest paradox. They alleviate the "undifferentiated heavy lifting" of operations but deepen your reliance on proprietary APIs, IAM frameworks, and provider-specific operational logic. Aggressively avoiding proprietary services to escape lock-in can be counterproductive. Hohpe cautions that this often results in an "enterprise non-cloud"—a cloud environment that effectively functions like a legacy data center.

Many companies migrate while clinging to rigid approval cycles, manual governance, and siloed operating models. This approach doesn't achieve cloud transformation; it simply creates a more expensive, outsourced version of the existing data center. The goal of a mature strategy is not to eliminate all dependencies, but to select them with conscious intent.

Hyperscalers are highly resilient, but they are also deeply embedded in thousands of companies, governments, banks, SaaS platforms, and supply chains. This creates concentration risk: a major provider outage, identity service issue, DNS failure, region-wide incident, or control-plane problem can have broad consequences.

Regulators increasingly treat the cloud as critical infrastructure. The CMA cloud investigation and Ofcom referral show that cloud concentration is no longer only an IT architecture issue; it is also a competition, resilience, and economic policy issue.

Moving to a hyperscaler may reduce your local infrastructure risk while increasing your dependence on a small number of global platforms.

Cost spikes

The dark side of cloud adoption is that organizations often treat it as merely a cheaper form of hosting. In reality, the cloud represents a fundamental shift in economic, operational, security, and organizational models. These systemic issues typically surface post-migration as usage scales, dependencies on proprietary managed services deepen, and finance departments begin to question why costs are not decreasing.

In Cloud Strategy , Gregor Hohpe emphasizes that financial benefits are not guaranteed; they “must be earned” through architectural discipline. Moving legacy enterprise baggage without transformation often results in an “enterprise non-cloud” —a setup that mimics a traditional data center but at a higher price point.

According to Flexera’s 2026 State of the Cloud report, 68% of respondents prioritize cost optimization as their primary initiative. The report further identifies critical migration hurdles, including the difficulty of comparing on-premises versus cloud expenditures, selecting appropriate instance types, and maintaining fiscal control after the initial move.

Conventional IT, hampered by limited transparency, often relies on restrictive governance: limiting developer access, blocking infrastructure changes, and requiring manual approvals. These legacy workflows create significant friction and are fundamentally at odds with modern DevOps and Continuous Delivery practices.

Modern architectures generate an immense quantity of telemetry , including application logs, performance metrics, distributed traces, and security audit trails. It is a striking irony that the very observability data required to govern the environment can transform into a substantial financial burden.

Simplistic business cases frequently overlook this operational reality. Nonetheless, lacking robust visibility prevents teams from effectively managing system reliability or fiscal health. Conversely, capturing excessive, unfiltered data can result in unexpectedly large provider invoices. Obtaining comprehensive visibility into your cloud operations is far from a zero-cost goal.

Security

Cloud providers secure the cloud platform, but customers still own many critical responsibilities : identity, data protection, access policies, application security, network configuration, logging, and service-specific controls.

A 2024 NSA cybersecurity information sheet warns that customers often incorrectly assume the cloud provider manages safeguards that remain the customer’s responsibility, and says misconfiguration and lack of security controls are significant risks in cloud environments.

In the cloud, identity and permissions are infrastructure. A bad IAM policy, leaked access key, over-privileged CI/CD role, or compromised admin account can expose far more than a single server. This is rarely explained to business leaders: the move from network-based security to identity-based security requires a much more mature approach to least privilege, key rotation, service accounts, temporary credentials, and continuous monitoring.

Instead of relying on manual restrictions, the cloud’s inherent transparency enables automated guardrails. This allows for the real-time detection of policy violations, strengthening compliance while simultaneously reducing the procedural burden on engineering teams.

IBM’s 2025 Cost of a Data Breach report puts the global average cost of a breach at $4.44 million, and highlights risks from rapid technology adoption without adequate governance.

Cloud security failures are often not caused by weak cloud providers, but by weak identity design and weak governance.

Cloud-native complexity and diminishing returns

Containers, Kubernetes, service meshes, serverless, event-driven architectures, IaC, GitOps, policy-as-code, and observability platforms can be powerful. They can also create a skill cliff.

The CNCF 2024 survey notes that cloud-native adoption continues to grow, with one-quarter of respondents reporting that nearly all their development and deployment uses cloud-native techniques. But increased adoption also means organizations need new operating skills, not just new tools.

Cloud is not a one-time migration. It creates a continuous need for platform engineering, FinOps, security engineering, cloud architecture, automation, SRE, vendor management, and compliance expertise.

The hidden problem is not only hiring cloud engineers. It is that every future project inherits the cloud operating model. Hohpe frames cloud as a “lifestyle change,” not a procurement exercise.

Cloud-native can reduce infrastructure friction while increasing architectural and operational complexity.

The business case often ignores organizational cost

Cloud business cases often compare infrastructure cost: servers versus cloud resources. They may undercount migration effort, training, landing zone design, security tooling, refactoring, dual-running during migration, FinOps, compliance, architecture governance, and operational redesign.

Flexera’s 2026 migration findings show that dependency understanding and technical feasibility are major migration challenges, which are exactly the areas simplistic business cases tend to underestimate.

The cheapest cloud migration plan is often the one that forgot the real work.

Conclusion

Cloud is not simply a different place to run servers. It is a different operating model built around service consumption, automation, elasticity, shared responsibility, and continuous change. Its real value comes from speed, leverage, and access to managed capabilities that would be difficult for most organizations to build alone. But those benefits are not automatic: they require architectural discipline, strong governance, cost awareness, security maturity, and new organizational habits. A successful cloud strategy therefore starts not with migration, but with understanding what must change in the way the business funds, builds, secures, operates, and evolves technology.