Cloud computing glossary

How to use this cloud computing glossary

This cloud computing glossary explains the terms that matter when selecting platforms, designing systems, reviewing security controls, and managing infrastructure costs. For MyDiscussions readers, each definition connects vocabulary to a practical decision: what your team operates, what a provider guarantees, and what a service actually costs.

Cloud terminology often mixes technical concepts with marketing labels. “Serverless” does not mean servers disappear, and “managed” does not mean your operational responsibilities vanish. Use these definitions to clarify architecture proposals, procurement requirements, and conversations between engineering, finance, and security teams.

Cloud fundamentals and deployment models

Cloud computing

Cloud computing is on-demand access to shared computing resources that can be provisioned and released with limited manual intervention. Resources include processing, storage, networking, and higher-level application services.

The NIST definition of cloud computing identifies five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

For buyers, the practical test is whether teams can provision resources programmatically, measure consumption, and adjust capacity without procuring physical equipment.

Public cloud, private cloud, hybrid cloud, and multicloud

• Public cloud: Infrastructure offered for use by multiple customers, such as Amazon Web Services, Microsoft Azure, or Google Cloud. Tenants receive logical isolation, with dedicated infrastructure options available.
• Private cloud: Cloud infrastructure dedicated to one organization. It may run on premises or be hosted externally; OpenStack is one platform used to build it.
• Hybrid cloud: Distinct cloud environments connected to support coordinated operations or application and data portability. In industry usage, the term also commonly covers integrated on-premises and public-cloud systems.
• Multicloud: Use of services from more than one cloud provider, whether or not those environments are tightly integrated.

Trade-off: Multicloud can meet regulatory or service-selection needs, but increases identity, networking, observability, and staffing complexity. It does not automatically make workloads portable.

Region, availability zone, and edge location

A region is a provider-defined geographic area containing cloud infrastructure. An availability zone is an isolated infrastructure location within a region, designed as a separate failure domain.

An edge location places selected services closer to users, commonly for content delivery, traffic filtering, or edge execution.

Choose regions using concrete criteria: data-residency obligations, user latency, service availability, disaster-recovery requirements, and price. Multiple zones improve resilience to zone failures, but do not replace a regional recovery plan.

Cloud service models: who manages what?

The distinction between service models is the operational boundary, not simply how a product is billed.

Managed service

A managed service shifts specified operational tasks to a provider. Amazon RDS, for example, handles many database infrastructure and maintenance tasks, but customers still own schema design, query efficiency, access policies, and appropriate backup configuration.

Before selecting a managed product, check exactly who handles patching, version upgrades, failover, recovery testing, and incident response. Those boundaries vary by service and configuration.

Serverless computing

Serverless describes services where the provider manages server provisioning and much of capacity management, usually with consumption-oriented billing.

It includes functions and products such as Google Cloud Run and Amazon DynamoDB. Scaling behavior, minimum capacity, and billing rules differ.

Evaluate execution limits, startup latency, concurrency, networking requirements, and sustained-load pricing. Serverless is attractive for variable demand, but an always-busy workload may have different economics on reserved capacity.

Compute, containers, and application architecture

Virtual machine, container, and Kubernetes

A virtual machine, or VM, is a software-defined computer with its own guest operating system. It provides a familiar deployment boundary for legacy software, custom operating-system settings, and general-purpose applications.

A container packages an application and its dependencies into an isolated process environment. Containers generally share the host kernel, making their isolation model different from that of VMs.

Kubernetes orchestrates containers through declarative APIs, scheduling, service discovery, and reconciliation. Managed offerings include Amazon EKS, Azure Kubernetes Service, and Google Kubernetes Engine.

Kubernetes improves deployment consistency, but introduces cluster upgrades, policy management, networking choices, and workload configuration. A simpler application platform may suit a small team better.

Microservices and service mesh

Microservices divide an application into independently deployable services organized around capabilities. They enable separate release cycles and scaling, but add network dependencies and distributed failure modes.

A service mesh, such as Istio or Linkerd, provides service-to-service traffic management, identity, and telemetry through a networking layer.

Neither is mandatory for cloud adoption. Consider them when independent deployment and communication controls justify the operational overhead.

Scalability, elasticity, and autoscaling

• Scalability: A system’s ability to handle more work by adding resources or improving capacity.
• Vertical scaling: Increasing the resources of one instance.
• Horizontal scaling: Adding instances or replicas.
• Elasticity: Adjusting capacity as demand changes, including reducing it.
• Autoscaling: Rules or control loops that automate capacity adjustments.

Select scaling signals that reflect the bottleneck. CPU utilization can suit compute-heavy services; queue depth or request concurrency may better represent asynchronous or request-driven workloads.

Networking and storage terms

VPC, subnet, route table, and security group

A virtual private cloud, or VPC, is a logically isolated virtual network. Azure uses the related term virtual network, or VNet.

A subnet divides a network’s address space. A route table determines where traffic goes. A security group, or a comparable provider control, filters traffic according to rules.

“Private subnet” usually describes routing and exposure, not an automatic security guarantee. Check public addresses, internet routes, firewall rules, and administrative access paths together.

Load balancer, CDN, and DNS

A load balancer distributes traffic across targets. Layer 4 balancing operates primarily on transport information; Layer 7 balancing understands application protocols such as HTTP.

A content delivery network, or CDN, caches and delivers content through distributed locations. Amazon CloudFront and Cloudflare are examples.

DNS, the Domain Name System, resolves names to records used to locate services. DNS caching means routing changes may not reach every client immediately.

Object, block, and file storage

• Object storage: Stores data as objects with metadata, typically accessed through APIs. Amazon S3 and Azure Blob Storage suit media, backups, and data lakes.
• Block storage: Exposes volumes to compute instances. Examples include Amazon EBS and Google Cloud Persistent Disk.
• File storage: Provides shared filesystem access, often through NFS or SMB. Examples include Amazon EFS and Azure Files.

Compare access semantics, latency, throughput, request charges, retrieval charges, and durability requirements. Object storage is not automatically a drop-in replacement for a filesystem.

Durability, replication, and consistency

Durability concerns preserving stored data. Replication copies data across locations or nodes. Consistency describes when clients observe writes and how concurrent operations behave.

Strong consistency simplifies some application logic, but its scope matters: a guarantee for individual objects is not necessarily a multi-record transaction guarantee.

Replication supports resilience, but is not a backup strategy by itself. Accidental deletions or corrupt writes can propagate to replicas.

Security, identity, and governance

Shared responsibility model

The shared responsibility model divides security obligations between provider and customer. Providers protect underlying infrastructure; customers retain responsibilities that depend on the service used.

With VMs, customers generally patch guest operating systems. With managed databases, responsibilities shift toward data access, configuration, and application security. The AWS shared responsibility documentation illustrates these changing boundaries.

Turn the model into an ownership checklist rather than assuming a cloud contract transfers all security work.

IAM, least privilege, and workload identity

Identity and access management, or IAM, controls which identities can perform which actions on which resources.

Least privilege means granting only the permissions necessary for a task. Workload identity gives applications an identity without relying on embedded, long-lived credentials.

Prefer short-lived credentials, role-based permissions, and separate production access. Review who can assume roles, not just which permissions those roles contain.

Encryption, KMS, and secrets management

Encryption at rest protects stored data; encryption in transit protects data moving between systems.

A key management service, or KMS, manages cryptographic keys and access to cryptographic operations. A secrets manager stores and distributes sensitive values such as API keys and database passwords.

AWS KMS, Azure Key Vault, and Google Secret Manager serve related but distinct needs. Encryption does not compensate for an identity that legitimately has permission to decrypt everything.

Data residency and sovereignty

Data residency concerns where data is stored or processed. Data sovereignty concerns the laws and jurisdictional controls applicable to it.

A selected region may not answer questions about support access, telemetry, backups, or subprocessors. Review contractual commitments and service-specific data flows.

Reliability, delivery, and operations

Availability, SLA, SLO, and SLI

Availability measures whether a service is usable over a defined period.

An SLI, or service-level indicator, is a measurement such as successful-request rate. An SLO, or service-level objective, sets a target for that indicator. An SLA, or service-level agreement, is a contractual commitment with defined conditions and remedies.

A provider SLA does not equal your application’s availability. Dependencies, deployment failures, and database bottlenecks still affect users.

RTO, RPO, and disaster recovery

Recovery time objective, or RTO, is the target time to restore service after disruption. Recovery point objective, or RPO, defines the acceptable amount of data loss expressed in time.

These targets guide disaster recovery design. Tight objectives may require replication, preprovisioned capacity, and automated failover; looser objectives may allow restoration from backups.

Test recovery procedures. An untested backup cannot establish that recovery objectives are achievable.

Infrastructure as code and observability

Infrastructure as code, or IaC, defines infrastructure through version-controlled configuration. Terraform, OpenTofu, AWS CloudFormation, and Pulumi support repeatable provisioning and reviewable changes.

Observability is the ability to understand system behavior using signals such as logs, metrics, and traces. OpenTelemetry provides instrumentation and telemetry collection standards and components.

IaC does not eliminate configuration drift automatically. Observability does not mean collecting everything: retention, sensitive data, and high-cardinality metrics need controls.

Cloud economics and vendor selection

FinOps, egress, and commitment discounts

FinOps is a collaborative operating practice for managing technology spending and business value. It connects engineering decisions with financial accountability.

Egress means outbound data transfer, which may incur charges depending on destination and service. Cross-zone, cross-region, and internet traffic can have different prices.

Commitment discounts, such as AWS Savings Plans or Google Cloud committed use discounts, exchange spending or resource commitments for lower eligible rates. Spot capacity offers discounted, interruptible resources for suitable workloads.

Compare total costs, not instance prices alone. Include storage operations, idle capacity, network transfer, logging, support, and engineering effort. Check the Azure pricing calculator or the equivalent tool for your chosen provider against realistic workload assumptions.

A step-by-step process for applying cloud terminology

1. Define the workload. Record traffic patterns, data volume, latency targets, dependencies, and regulatory constraints.
2. Set reliability objectives. Specify measurable SLOs, RTO, and RPO before choosing redundancy or backup products.
3. Choose an operational boundary. Compare IaaS, managed platforms, and serverless against staffing, customization, and release requirements.
4. Map data and identity flows. Identify regions, trust boundaries, administrative access, encryption ownership, and transfer paths.
5. Model costs under different loads. Estimate normal demand, peak demand, and recovery scenarios, including egress and observability.
6. Validate through a pilot. Test scaling, permissions, restore procedures, and deployment rollback. Document assumptions that proved false.

Common mistakes when interpreting cloud terms

• Equating managed with maintenance-free: Your team still needs configuration, monitoring, and incident ownership.
• Treating multicloud as disaster recovery: Independent providers do not create tested failover or synchronized data automatically.
• Confusing durability with availability: Data can remain intact while temporarily inaccessible.
• Assuming containers guarantee portability: Provider APIs, identity systems, networking, and databases can remain dependencies.
• Buying commitments before measuring usage: Discounts may not compensate for unused commitments.
• Using “secure” without criteria: Specify access controls, auditability, encryption, recovery, and jurisdictional requirements.

Frequently asked questions

What is the difference between cloud computing and traditional hosting?

Cloud computing emphasizes self-service provisioning, pooled resources, elasticity, and measured consumption. Traditional hosting may provide a fixed server or environment with more manual provisioning. A hosted service can also implement cloud characteristics.

Is serverless cheaper than virtual machines?

Not necessarily. Serverless can reduce idle-resource costs for intermittent workloads, but sustained demand, memory allocation, requests, and connected services affect the comparison. Include operational labor and performance requirements, not just compute charges.

Does using Kubernetes prevent vendor lock-in?

Kubernetes standardizes many deployment interfaces, but does not remove dependencies on proprietary databases, identity services, storage, or networking. Assess portability by testing what must change to move a working application.

Which cloud terms should decision-makers learn first?

Start with shared responsibility, service models, regions, availability zones, SLA, SLO, RTO, RPO, and egress. These terms frame ownership, resilience, compliance, and cost. For adjacent software and infrastructure concepts, browse more Glossary topics.