What is cloud infrastructure? A builder’s guide to components, architecture, and decisions

An engineering team joins a fast-growing fintech. Their first major technical decision is infrastructure: which cloud provider, which services, which deployment model. They pick the largest provider, use its proprietary managed services throughout (the database, the queue, the search layer, the secrets manager), and ship a product in 4 months. Three years later, new data residency regulations require them to move certain workloads out of the provider’s US region. The migration estimate comes back at 14 months and $2 million. Every proprietary integration needs to be rewritten. The infrastructure decision made on day 3 became a constraint they paid for at third year.

Cloud infrastructure is not a provisioning task. It is a set of architectural decisions that determine what you can and cannot build on top of them, and at what cost. Understanding what cloud infrastructure actually is, not just its textbook definition, is the starting point for avoiding decisions that are cheap to make and expensive to live with.

Gartner forecasts global end-user spending on public cloud to reach $723.4 billion in 2025, up 21.5% year on year. The cloud infrastructure market stands at $294.99 billion in 2025, projected to reach $923.05 billion by 2035. Every digital product built in the next decade runs on this layer. Getting it right matters.

Key takeaways

• You will understand what cloud infrastructure is and why the definition matters differently for builders than for end users.
• You will learn the 6 core components of cloud infrastructure and how they connect to form a production-grade environment.
• You will understand the 3 deployment models (public, private, and hybrid cloud infrastructure) and the criteria that determine which fits your workload.
• You will know what cloud infrastructure management and monitoring involve in a live environment, beyond initial setup.
• You will leave with a practical framework for evaluating cloud infrastructure architecture decisions before you commit to them.

What cloud infrastructure actually is

Cloud infrastructure is the combined layer of hardware (servers, storage, networking equipment), virtualisation software, and management tooling that underlies all cloud services. It is what turns physical data centre resources into on-demand, programmable compute, storage, and networking that applications and platforms are built on top of.

The distinction that matters most for builders is the difference between cloud infrastructure and cloud services. Infrastructure is the underlying layer: the virtualised compute, storage, and networking resources you provision and configure. Cloud services are what runs on top of that infrastructure: managed databases, serverless functions, message queues, content delivery networks (CDNs), and machine learning (ML) platforms. When you use Amazon S3, you are using a cloud service. The physical storage hardware, the virtualisation layer, and the networking that makes S3 globally available is the cloud infrastructure beneath it.

This distinction determines who is responsible for what. At the infrastructure layer, you are responsible for provisioning resources, configuring networking and security, managing capacity, and ensuring your architecture is resilient. At the managed service layer, the provider handles the underlying hardware, patching, and availability, and you are responsible for configuration, data management, and application integration. Understanding which layer you are operating at for each component of your system is the first architectural decision cloud infrastructure requires.

The 6 core components of cloud infrastructure

Cloud infrastructure has 6 core components: compute, storage, networking, virtualisation, management and orchestration, and security and identity. Understanding what each does and how it interacts with the others is what separates an infrastructure decision from a default choice.

Compute

The compute layer is where your application’s processing happens: where code executes, where requests are handled, and where data is transformed. In cloud infrastructure, compute is delivered in 3 forms. Virtual machines (VMs) are virtualised servers that behave like physical machines; you control the operating system, runtime, and configuration. Containers package application code and its dependencies into a portable, lightweight unit that runs consistently across environments, typically orchestrated at scale using Kubernetes. Serverless functions execute specific code in response to events without requiring you to manage any server configuration; you pay per execution rather than per hour of running infrastructure.

The compute model you choose has direct implications for cost, scalability, and operational overhead. VMs give you full control and are appropriate for workloads with specific OS requirements or legacy applications. Containers are the standard for modern microservices architectures, offering portability and density. Serverless is the right choice for event-driven, intermittent workloads where the cost of idle compute would otherwise be significant. Most production systems use all 3 in combination, matching the compute model to the specific workload.

Storage

The storage layer persists data across the system. Cloud infrastructure offers 3 distinct storage types. Object storage (the model used by Amazon S3, Google Cloud Storage, and Azure Blob Storage) stores unstructured data (files, images, backups, data lake files) as objects with metadata, accessible via an application programming interface (API). It is highly durable, inexpensive at scale, and globally accessible, but not designed for low-latency, transactional reads. Block storage presents storage as a raw disk attached to a compute instance, used for databases and applications that need fast, low-latency read/write access. File storage provides shared file system access across multiple compute instances, typically used for shared application assets and legacy workloads.

Storage decisions are among the most consequential in cloud infrastructure because they are the hardest to reverse at scale. Migrating terabytes of data from a proprietary storage format to an open one is a major engineering project. Choosing S3-compatible object storage with open table formats (Apache Iceberg, Parquet) preserves portability. Choosing a provider’s proprietary data warehouse format trades portability for convenience. The right choice depends on the workload, the regulatory requirements, and the organisation’s tolerance for vendor dependency.

Networking

The networking layer controls how services communicate internally and how traffic reaches external users. In cloud infrastructure, networking is virtualised: you define virtual private clouds (VPCs) to isolate resources into private network segments, configure subnets, and set routing rules as code rather than physically cabling hardware. Load balancers distribute incoming traffic across multiple compute instances to prevent any single instance from becoming a bottleneck. CDNs cache content at edge locations physically closer to users, reducing latency for globally distributed applications. DNS (domain name system) resolves human-readable domain names to the IP addresses of your cloud resources.

Networking configuration is where many cloud deployments accumulate technical debt. A VPC that was designed for a small product and then extended ad hoc as the product grew often ends up with overlapping CIDR (Classless Inter-Domain Routing) blocks, inconsistent security group rules, and no clear network segmentation model. The cost of redesigning network architecture at scale is high. Designing it correctly from the start, with clear segmentation between environments (development, staging, production), consistent security group policies, and defined egress rules, takes a fraction of the time to do once that it takes to redo.

Virtualisation Layer

Virtualisation is the technology that abstracts physical hardware into software-defined resources. A hypervisor (the virtualisation software running on a physical server) creates and manages multiple VMs on a single physical machine, each believing it has its own dedicated hardware. Container runtimes (Docker) and orchestration platforms (Kubernetes) apply the same abstraction at the application layer: multiple containers share the same operating system kernel, with isolation at the process level rather than the hardware level. Without virtualisation, cloud infrastructure is simply rented servers. With it, a single physical machine can host dozens of isolated workloads, each provisioned and de-provisioned in seconds.

Management & Orchestration

The management and orchestration layer is what makes cloud infrastructure reproducible, auditable, and operable at scale. Infrastructure as code (IaC) tools (Terraform, Pulumi, AWS CloudFormation) define infrastructure resources as version-controlled configuration files: the same tool run twice produces the same environment, and changes are tracked in source control like application code. Auto-scaling policies define rules for adding or removing compute capacity in response to load, ensuring the system scales without manual intervention. Deployment pipelines (CI/CD: continuous integration and continuous delivery) automate the process of testing and releasing changes to infrastructure and application code.

Without an IaC-based management layer, cloud infrastructure is manually configured: individual engineers make changes through a console, those changes are not recorded, and the infrastructure state is effectively undocumented. At small scale this is manageable. At the scale of a production platform serving thousands of users, it produces incidents where no one knows what changed and a rollback requires rebuilding from memory.

Security & Identity

The security and identity layer governs who can access what within the cloud environment and how data is protected. Identity and access management (IAM) defines roles and policies that control which users, services, and applications can access which resources, and with what permissions. The principle of least privilege, each entity has access only to what it needs and nothing more, is the security model that prevents a compromised credential from having blast radius across the entire environment.

Encryption at rest (data stored in object storage, databases, and block volumes is encrypted using provider-managed or customer-managed keys) and encryption in transit (data moving between services uses TLS: Transport Layer Security) are baseline requirements, not optional features. Zero trust network access (ZTNA) treats every request to a service as untrusted by default, requiring authentication and authorisation for every interaction regardless of network location. In 2026, hybrid cloud security is built on zero trust principles because the old perimeter model (trust everything inside the network boundary) does not work when infrastructure spans multiple cloud regions and on-premises environments simultaneously.

Cloud infrastructure deployment models: public, private, and hybrid

Cloud infrastructure runs in 3 deployment models: public cloud, private cloud infrastructure, and hybrid cloud infrastructure. Most enterprise architectures in 2026 use a combination, and the criteria for choosing between them are workload-specific, not platform-wide.

Public Cloud Infrastructure

In the public cloud model, infrastructure is owned, operated, and maintained by a cloud provider (AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud, IBM Cloud) and shared across multiple customers, with logical isolation between tenants. Compute, storage, and networking are provisioned on demand, billed by consumption, and scaled elastically without capital expenditure. The IaaS (infrastructure as a service) market is expanding 25% year on year, exceeding $210 billion in 2025, driven primarily by public cloud adoption.

Public cloud is the right infrastructure model for variable workloads where on-demand scaling matters, for teams that want to ship quickly without managing physical hardware, and for products that benefit from the provider’s global network of data centres. The trade-offs are real: cost at scale (public cloud is expensive at sustained high utilisation compared with reserved capacity), data residency constraints (not all regions are available for all data types under GDPR or sector-specific regulations), and the vendor dependency risk illustrated in the opening scenario.

Private Cloud Infrastructure

Private cloud infrastructure is a dedicated environment, on-premises or in a co-location facility, running virtualised compute, storage, and networking for a single organisation. It provides the programmable, on-demand characteristics of cloud infrastructure without the shared tenancy of public cloud. Private cloud is the right model for organisations with strict regulatory requirements (financial services, healthcare, government), sensitive workloads that cannot leave a specific geography, or high-volume, predictable compute where owning capacity is cheaper than the public cloud pay-per-use model.

The trade-offs: capital expenditure and lead time for hardware procurement, higher operational overhead (your team manages the hypervisor, hardware maintenance, and capacity planning), and slower provisioning compared with public cloud. Private cloud is not “on-premise is back” — it is on-premise with cloud operating model: software-defined networking, virtualised compute, and IaC-driven provisioning applied to dedicated hardware.

Hybrid Cloud Infrastructure

Hybrid cloud infrastructure integrates private and public cloud environments into a unified, governed architecture where workloads move or connect between environments based on requirements. Gartner named hybrid computing the number one infrastructure and operations trend for 2026, predicting that 90% of organisations will have hybrid deployments in place through 2027. The pattern is consistent across enterprise architectures: one governed private environment for identity management and mission-critical, compliance-sensitive workloads; connected to public cloud for elastic, modern application services.

The 89% of enterprises that have adopted multi-cloud as their primary public cloud model add further complexity: running workloads across AWS, Azure, and GCP simultaneously, using different providers for different capabilities while maintaining a consistent governance and identity layer across all of them. Hybrid cloud is the architecture; multi-cloud is the public cloud strategy within it.

Cloud infrastructure architecture: how the layers connect

Cloud infrastructure architecture describes how the compute, storage, networking, and management components are arranged and connected to serve a specific workload. The architecture determines reliability, performance, security posture, cost profile, and how much of the system can fail without the product going down.

The IaaS, PaaS (platform as a service), and SaaS (software as a service) hierarchy clarifies the division of responsibility. At IaaS, you manage the operating system upward: the hypervisor and hardware are the provider’s responsibility, everything running on the VM is yours. At PaaS, the provider manages the runtime and middleware as well: you deploy application code and data. At SaaS, the provider manages the full stack; you configure and use the application. Most product engineering teams use all 3: IaaS for core compute, PaaS for managed databases and message queues, and SaaS for tooling (monitoring, analytics, CI/CD platforms).

The architectural pattern that separates resilient cloud infrastructure from fragile cloud infrastructure is designing for failure as a baseline assumption. A single-region deployment with a single availability zone is a single point of failure: one data centre event takes the product down. Multi-region architectures distribute compute and data across geographically separated data centres, with active-active configurations serving traffic from multiple regions simultaneously or active-passive configurations failing over automatically to a standby region when the primary fails. The additional cost and complexity of multi-region is the cost of the uptime guarantee your users expect.

Cloud-native architecture, designing applications specifically to exploit cloud infrastructure capabilities (horizontal scaling, stateless services, managed data stores, event-driven communication) rather than lifting existing applications to the cloud unchanged, is what enables the elasticity and resilience cloud infrastructure promises. An application that stores session state in a single database cannot scale horizontally: adding more compute instances does not help if all requests depend on a shared stateful component. Cloud-native design removes those shared dependencies, enabling the infrastructure to scale by adding more instances rather than building a larger one.

In a pharma patient data analytics platform we architected on AWS, the infrastructure decision that most affected the platform’s commercial viability was treating data isolation as an infrastructure concern, not an application one. Each pharma client’s data was isolated at the AWS infrastructure layer: separate S3 partitions, separate DynamoDB tables, ECS (Elastic Container Service) and Fargate container isolation per client workload. That decision was made in the first week of architecture design. It is what allowed the platform to onboard regulated enterprise clients with auditable, demonstrable data separation, rather than relying on application-layer logic that would have required re-auditing with every new client.

Cloud infrastructure services: what providers actually offer

Cloud infrastructure services are the catalogue of managed resources a provider makes available: compute instances, managed databases, object storage, load balancers, CDNs, ML training infrastructure, and serverless execution environments. The major providers (AWS, Azure, GCP, Oracle Cloud, IBM Cloud) offer comparable core services with meaningful differences in ecosystem depth, regional availability, managed service breadth, and commercial model.

AWS leads in ecosystem maturity and service breadth, with the widest range of managed services and the largest global footprint. Azure leads in enterprise integration, particularly for organisations already running Microsoft workloads (Active Directory, Office 365, SQL Server). GCP leads in data analytics and ML infrastructure, reflecting Google’s internal expertise in those domains. Oracle Cloud Infrastructure (OCI) is the strongest option for organisations running Oracle databases and enterprise applications. IBM Cloud focuses on regulated industries, particularly financial services and government.

The most important choice at the managed services layer is between proprietary managed services and open-standard equivalents. A managed database like Amazon RDS (Relational Database Service) running PostgreSQL gives you a service-managed PostgreSQL instance: portable, open-standard, and runnable on any provider or on-premises. Amazon DynamoDB gives you a fully managed NoSQL database with proprietary APIs: faster to adopt, operationally simpler, and architecturally locked to AWS. Both are legitimate choices; the trade-off is portability versus operational convenience, and it is a trade-off worth making explicitly rather than by default.

One area where cloud infrastructure services have changed materially in 2025 and 2026 is AI-specific infrastructure. GPU compute for ML model training and inference, vector databases for embedding storage and retrieval, and LLM (large language model) serving infrastructure are now standard offerings across major providers. For teams building AI-augmented products, the cloud infrastructure provider selection now includes these capabilities as meaningful differentiators alongside the traditional compute, storage, and networking comparison.

Cloud infrastructure management: running this in production

Cloud infrastructure management is the ongoing work of ensuring a cloud environment is performant, cost-effective, secure, and compliant. It covers provisioning, configuration, auto-scaling, cost governance, security posture, and change management. Infrastructure that is well-designed but poorly managed degrades over time: uncleaned snapshots inflate storage costs, unused resources accumulate, security group rules expand beyond their original intent, and drift between the infrastructure state and the IaC definition makes auditing difficult.

FinOps (cloud financial operations) is the practice of bringing engineering, finance, and operations teams together around cloud cost accountability. Cloud billing grows non-linearly with usage if not actively governed: auto-scaling without cost guardrails, untagged resources that cannot be attributed to a team or product, and data egress charges that were not modelled in the original architecture are the most common sources of surprise cloud bills. FinOps is not a quarterly finance review; it is a continuous engineering practice, with cost visibility built into the deployment pipeline and anomaly alerts firing before spend exceeds budget.

Security posture management is the continuous process of identifying and remediating misconfigurations in the cloud environment. A misconfigured S3 bucket is publicly accessible; a misconfigured security group allows unrestricted inbound traffic; a VM running an end-of-life operating system is unpatched. CSPM (cloud security posture management) tools (AWS Security Hub, Azure Defender for Cloud, third-party tools like Wiz or Lacework) continuously scan cloud resources against defined security policies and surface violations before they become incidents. In a complex cloud infrastructure environment, manual configuration review does not scale: automated posture management is the operational model.

The infrastructure management maturity curve runs from manual provisioning (individuals make changes through the cloud console) to IaC (changes are defined in code and applied through pipelines) to GitOps (the desired infrastructure state is declared in a git repository and a reconciliation controller applies changes automatically when the state diverges). Each step on this curve reduces the risk of configuration drift, improves auditability, and enables teams to manage larger infrastructure footprints with smaller operational overhead.

Cloud infrastructure monitoring: why visibility is non-negotiable

Cloud infrastructure monitoring is the continuous tracking of the health, performance, and security of cloud resources. Without monitoring, a cloud environment is a black box: problems are discovered when users report them, not when they begin. By the time a user notices degraded performance or unavailability, the incident has usually been in progress for minutes or hours.

Effective cloud infrastructure monitoring covers 5 domains. Compute metrics: CPU and memory utilisation, instance health checks, container restart counts, and serverless function error rates and duration. Storage metrics: read/write latency, IOPS (input/output operations per second) utilisation, capacity usage, and replication lag. Network metrics: throughput, packet loss, load balancer request rates, and CDN cache hit rates. Security events: IAM policy changes, unusual API call patterns, failed authentication attempts, and resource creation in unexpected regions. Cost metrics: daily and weekly spend against budget, anomalous cost spikes, and unused resource identification.

The distinction between monitoring and observability matters operationally. Monitoring tells you that something is wrong: an alert fires because CPU utilisation exceeded 90% or error rates exceeded 1%. Observability, the combination of structured logs, metrics, and distributed traces, tells you why it is wrong: which service failed, which request pattern caused the spike, which line of code produced the error. Cloud-native monitoring tools (AWS CloudWatch, Azure Monitor, Google Cloud Monitoring) provide baseline metrics for their respective platforms. Third-party observability platforms (Datadog, Grafana, New Relic) provide a unified view across multi-cloud and hybrid environments, with correlation between infrastructure metrics and application performance data. For production platforms, the investment in full observability (not just infrastructure metrics) pays for itself the first time an incident is resolved in minutes instead of hours.

How to choose cloud infrastructure for your product

Choosing cloud infrastructure involves 5 criteria: workload type and scale requirements, regulatory and data residency obligations, team expertise, cost model, and vendor lock-in tolerance. No single provider or deployment model is universally correct; the right infrastructure is the one that fits the specific workload and the organisational constraints around it.

Workload type and scale determine the compute, storage, and networking model. A stateless API with variable traffic needs elastic horizontal scaling (containers on Kubernetes or serverless functions). A data-intensive batch pipeline needs high-throughput object storage and scalable compute (Spark on EMR or Dataflow). An ML training workload needs GPU compute and high-bandwidth storage. A real-time streaming system needs a message broker (Kafka or a managed equivalent) and stateful stream processing. Mapping workload type to infrastructure model before choosing a provider avoids the common mistake of choosing a provider based on brand familiarity and then discovering that its managed services do not fit the workload.

Regulatory and data residency obligations are architecture constraints, not compliance checkboxes. GDPR requires that EU personal data is processed in the EU or in jurisdictions with equivalent data protection; this rules out certain AWS and Azure regions for specific data types. HIPAA (Health Insurance Portability and Accountability Act) in the US requires a Business Associate Agreement (BAA) with every cloud provider that processes protected health information (PHI). Financial services regulations in multiple jurisdictions require data to remain within national boundaries. These requirements must be mapped to specific cloud regions and documented before any infrastructure is provisioned; retrofitting data residency constraints into an existing multi-region architecture is a significant and disruptive engineering project.

Team expertise is a practical constraint that is frequently underweighted in infrastructure selection decisions. The best cloud infrastructure for a team with 5 years of AWS expertise is usually AWS, even if a different provider might be theoretically better optimised for the specific workload. The operational knowledge required to manage production infrastructure reliably (incident response, capacity planning, security configuration, cost management) takes time to develop. Switching infrastructure platforms is not just a provisioning decision; it is a retraining and re-documentation exercise for every person who operates the environment.

Lock-in tolerance is the trade-off between operational convenience and architectural portability. Proprietary managed services (provider-specific databases, serverless platforms, ML services) are faster to adopt, operationally simpler, and often better integrated with the provider’s other services. They are also harder to migrate away from. Open-standard services (PostgreSQL-compatible databases, S3-compatible object storage, Kubernetes for container orchestration) take slightly more effort to configure but preserve the ability to move workloads between providers or to on-premises infrastructure when requirements change. The decision is not binary; most production systems use a mix of proprietary and open-standard services, with the proprietary ones chosen deliberately for workloads where migration cost is low or lock-in risk is acceptable.

Conclusion: cloud infrastructure is where product leverage is set

The most important insight about cloud infrastructure is this: every constraint you design out at the infrastructure layer is a degree of freedom you preserve for the product above it. The teams that build resilient, scalable platforms are not the ones with the largest infrastructure budget or the most sophisticated tooling. They are the ones that made 3 or 4 correct architectural decisions early, before the cost of changing them became prohibitive.

Cloud infrastructure will continue to evolve, and fast: AI-specific compute, sovereign cloud deployments, edge infrastructure extending cloud-native capabilities beyond centralised data centres, and the increasing convergence of public and private cloud models through open standards like Apache Iceberg. The specific tools will change. The underlying discipline, treating infrastructure as an architectural input to product design, not a provisioning consequence of it, will not.

If you are making cloud infrastructure decisions for a product you are building or scaling, reach out at coffee@sparkeighteen.com.