Topic originally sourced from searchcloudcomputing.techtarget.com. This article provides an independent, expanded explanation of the core characteristics of cloud computing.
Why Cloud Characteristics Matter
Cloud computing has an ever-expanding catalogue of tools, services and deployment models, but its foundational characteristics have stayed remarkably consistent since AWS began selling compute and storage instances in 2006. Google and Microsoft followed shortly after, and today the cloud spans IaaS, PaaS and SaaS — encompassing AI, containers, serverless compute, managed databases, IoT, analytics and much more.
Each service category carries its own trade-offs, but seven core characteristics underpin all of them. Understanding these traits helps DevOps and platform engineering teams make informed architectural decisions, negotiate contracts and set realistic expectations with stakeholders.
1. On-Demand Computing
AWS, Microsoft Azure, Google Cloud and other public cloud platforms make compute and storage resources available at the click of a button or a single API call. Providers maintain massive pools of capacity across globally distributed data centres, ready to serve requests in seconds.
This is a fundamental departure from traditional IT procurement, where acquiring a new server could require months of approval cycles, purchasing, shipping and rack-and-stack work. On-demand access collapses that timeline to minutes, enabling rapid experimentation and faster time-to-market.
2. Self-Service Provisioning
On-demand computing is only useful if teams can access resources without raising a ticket and waiting for an operations team to act. Self-service provisioning — typically delivered through a cloud provider’s web console, CLI or infrastructure-as-code tooling — gives developers the ability to select the resources they need and start building immediately.
In practice, a platform or cloud-ops team sets guardrails through IAM policies, service quotas and organisational policies. Within those boundaries, development teams have the autonomy to build, test and deploy without bottlenecks. This self-service model is a cornerstone of modern DevOps culture, enabling teams to own the full lifecycle of their services.
3. Resource Pooling
Public cloud providers use multi-tenant architectures to serve many customers simultaneously from the same physical hardware. Customer workloads are abstracted from the underlying infrastructure through hypervisors, container runtimes and software-defined networking, so that multiple tenants share a host without visibility into each other’s data or operations.
Providers increasingly design custom silicon and abstraction layers — such as AWS Nitro, Google Titanium or Azure’s FPGA-based offloads — to improve both performance and the security boundaries between tenants. Resource pooling is what makes cloud economics work: providers achieve high hardware utilisation while offering individually elastic allocations to each customer.
4. Scalability and Elasticity
Because resources are pooled, they can also be reallocated dynamically. Compute, storage and networking capacity can be added or removed in response to real workload demand rather than forecast estimates. Cloud platforms support two primary scaling axes:
- Vertical scaling (scaling up/down): Increasing or decreasing the CPU, memory or disk of an existing instance.
- Horizontal scaling (scaling out/in): Adding or removing instances behind a load balancer, often managed by an autoscaling group or Kubernetes horizontal pod autoscaler.
By contrast, traditional on-premises architectures force teams to provision for peak capacity. Resources sit idle during quiet periods, wasting capital and operational spend. Elasticity removes this requirement — you pay for what you use and scale back when demand drops.
5. Pay-Per-Use Pricing
Cloud pricing shifts IT expenditure from capital expenditure (Capex) — buying hardware up front — to operational expenditure (Opex), paying only for resources consumed. Most providers offer per-second or per-hour billing for compute, with similar granularity for storage, data transfer and managed services.
While pay-as-you-go is an advantage, it introduces a new risk: uncontrolled spend. DevOps teams need to practise FinOps disciplines to manage costs effectively:
- Right-size instances to avoid over-provisioning.
- Shut down or scale down resources when not in use (e.g., development environments overnight).
- Use reserved instances, savings plans or committed-use discounts for predictable baseline workloads.
- Set budget alerts and cost anomaly detection to catch runaway spend early.
Providers now offer a range of pricing models beyond pure on-demand billing — including reserved capacity, spot or preemptible instances and sustained-use discounts — giving teams flexibility to optimise cost for their specific usage patterns.
6. Resiliency and High Availability
Cloud providers architect their platforms to minimise single points of failure. Key resilience constructs include:
- Availability Zones (AZs): Physically separate data centres within a geographic region, connected by redundant low-latency networks. Distributing workloads across multiple AZs protects against a single facility failure.
- Regions: Geographically isolated deployments that can be used for disaster recovery or data residency requirements.
- Managed service redundancy: Many higher-level services (managed databases, object storage, load balancers) automatically replicate data or distribute traffic across AZs without user configuration.
That said, no platform is immune to outages. Major providers have experienced significant incidents that affected entire regions or service categories. Teams should design for failure by:
- Implementing multi-AZ deployments for critical workloads.
- Testing failover procedures regularly (chaos engineering).
- Considering multi-region or even multi-cloud strategies for the highest availability requirements, accepting the added complexity and cost that entails.
7. Security and the Shared Responsibility Model
Security in the cloud operates under a shared responsibility model. The cloud provider secures the underlying infrastructure — physical data centres, hypervisors, global network fabric and managed service platforms. The customer is responsible for everything they build and configure on top: operating system hardening, application security, identity and access management, data encryption and network controls.
Major cloud providers invest heavily in security expertise, compliance certifications and threat intelligence — often beyond what individual enterprises can replicate on-premises. However, the most common cloud security incidents are not provider-side breaches; they are misconfigurations by customers, such as publicly exposed storage buckets, overly permissive IAM roles or unpatched application code.
To operate securely in the cloud, DevOps teams should:
- Understand clearly where provider responsibility ends and customer responsibility begins for each service used.
- Apply the principle of least privilege to all IAM policies and service roles.
- Enable cloud-native security tooling (e.g., AWS Security Hub, Azure Defender, Google Security Command Center).
- Integrate security scanning into CI/CD pipelines to catch misconfigurations before they reach production.
- Encrypt data at rest and in transit using provider-managed or customer-managed keys as appropriate.
Putting the Characteristics Together
These seven characteristics — on-demand access, self-service provisioning, resource pooling, scalability, pay-per-use pricing, resiliency and shared security — are not independent features. They are interdependent properties that, together, define what cloud computing is and why it has become the default platform for modern application development and operations.
For DevOps teams, internalising these characteristics shapes architectural decisions: designing stateless, horizontally scalable services; automating infrastructure provisioning through code; implementing FinOps practices to control spend; building for failure; and treating security as a shared, ongoing engineering discipline rather than a one-time checkbox.