Cloud Computing · Glossary · Beginners
Cloud Computing Glossary — Key Terms Explained
Quick summary — cloud computing glossary
Cloud computing is full of overlapping terms that sound similar but mean very different things. IaaS, PaaS, and SaaS describe who manages the stack. VMs, containers, and serverless describe how compute is packaged. Regions, AZs, and VPCs describe network topology. IAM, SLAs, and cost optimization describe governance. This glossary explains the key terms you'll encounter in cloud job listings, certifications, and interviews — with real product examples (AWS, Azure, GCP) and one-line explanations you can actually remember.
In this guide you will learn:
- Service models — IaaS, PaaS, SaaS, FaaS, CaaS.
- Compute types — VMs, containers, serverless, Kubernetes.
- Storage categories — object, block, file, managed databases.
- Networking and architecture — regions, VPCs, load balancers, CDNs.
- Security and cost terms — IAM, RBAC, SLAs, reserved instances.
SECTION 01Service models — IaaS, PaaS, SaaS, FaaS, CaaS
The most common source of confusion in cloud computing is the service-model acronyms. Here's the mental model: the higher the letter in the alphabet, the more the provider manages for you.
| Term | Meaning | What the Provider Manages | Real Examples |
|---|---|---|---|
| IaaS | Infrastructure as a Service | Physical servers, storage, networking — you manage OS upward | AWS EC2, Azure VMs, GCP Compute Engine |
| PaaS | Platform as a Service | OS, runtime, scaling — you deploy only code | Heroku, App Engine, Azure App Service |
| SaaS | Software as a Service | Everything — you just use the app | Gmail, Slack, Notion, Salesforce |
| FaaS | Function as a Service (serverless) | Runtime, scaling, request handling — you write single functions | AWS Lambda, Azure Functions, GCP Cloud Functions |
| CaaS | Container as a Service | Container runtime, orchestration — you ship containers | AWS ECS, Azure Container Apps, GKE |
SECTION 02Compute — VMs, containers, serverless, Kubernetes
Compute terms describe how your code runs. Each choice has different trade-offs around isolation, startup time, and operational complexity:
| Term | Meaning | Best For | Trade-off |
|---|---|---|---|
| Virtual Machine (VM) | A full OS running on virtualized hardware | Legacy apps, strong isolation needs | Slow to start; heavy resource footprint |
| Container | Isolated userland sharing the host kernel | Microservices, CI/CD, dev-prod parity | Weaker isolation than VMs |
| Serverless (FaaS) | Run single functions on demand; provider handles infra | Event-driven work, spiky traffic | Cold starts; per-request cost; limited runtime |
| Kubernetes | Open-source container orchestration platform | Multi-service apps at scale | Steep learning curve; operational overhead |
| Managed Kubernetes | Kubernetes hosted by the cloud provider | Teams that want K8s without ops burden | Less control over the control plane |
SECTION 03Storage — object, block, file, managed databases
Storage terms are often misused. Each type is optimized for a specific access pattern — using the wrong one is expensive and slow:
| Term | Meaning | Best For | AWS Example |
|---|---|---|---|
| Object Storage | Flat namespace of files accessible over HTTP | Images, backups, static assets, data lakes | Amazon S3, Azure Blob, GCS |
| Block Storage | Raw storage volumes attached to VMs | Databases, boot volumes, filesystems | EBS (AWS), Azure Disks, Persistent Disk |
| File Storage | Shared filesystem over NFS or SMB | Shared configs, legacy apps, media workflows | EFS (AWS), Azure Files, Filestore |
| Managed Database | Provider-managed DB (backups, patching handled) | Standard relational or NoSQL workloads | RDS, DynamoDB, Aurora |
| Data Warehouse | Columnar analytics database | BI, dashboards, large aggregations | Redshift, BigQuery, Snowflake |
SECTION 04Networking and architecture — regions, AZs, VPCs, load balancers
Cloud architecture terms describe where resources live and how they talk to each other. These are the ones interviewers expect you to know cold:
| Term | Meaning | Why It Matters |
|---|---|---|
| Region | Geographic area where cloud resources are hosted | Latency, data residency, compliance |
| Availability Zone (AZ) | Isolated datacenters within a region | High availability — replicate across ≥2 AZs |
| Edge Location | CDN point of presence close to users | Lower latency for static content |
| VPC | Virtual Private Cloud — isolated network | All resources live inside a VPC |
| Subnet | Range of IPs inside a VPC | Public vs private separation |
| Security Group | Instance-level firewall rules | Controls inbound/outbound traffic |
| Load Balancer | Distributes traffic across multiple targets | Horizontal scaling + health checks |
| CDN | Content Delivery Network — caches content globally | Faster delivery, reduced origin load |
| Multi-cloud | Using 2+ cloud providers simultaneously | Avoids lock-in; adds operational complexity |
| Hybrid cloud | Mixing on-prem and public cloud | Compliance, data gravity, gradual migration |
SECTION 05Security and access — IAM, RBAC, secrets, encryption
Cloud security has its own vocabulary. These terms appear in every security review and audit:
| Term | Meaning | Common Misuse |
|---|---|---|
| IAM | Identity and Access Management | "IAM" means identity; "RBAC" means role-based permissions |
| RBAC | Role-Based Access Control | Roles ≠ users; permissions attached to roles |
| Least Privilege | Give only the minimum permissions needed | Often ignored — but the #1 audit finding |
| Secrets Manager | Store API keys, DB passwords securely | NOT the same as environment variables |
| Encryption at Rest | Data encrypted when stored on disk | Different from encryption in transit |
| Encryption in Transit | Data encrypted while moving over network | TLS/HTTPS — not the same as at-rest |
| KMS | Key Management Service | Manages encryption keys — not the data itself |
| Compliance | Meeting standards (HIPAA, PCI, SOC 2, GDPR) | Compliance ≠ security — both are needed |
SECTION 06Reliability and cost — SLAs, auto-scaling, reserved instances
Cloud economics has its own language. These are the terms you'll see in cost reviews and contracts:
| Term | Meaning | Why It Matters |
|---|---|---|
| SLA | Service Level Agreement — provider's uptime guarantee | 99.9% = ~8.7 hrs downtime/yr; 99.99% = ~52 min |
| SLO | Service Level Objective — internal target | Usually stricter than the SLA |
| Auto-scaling | Automatically add/remove capacity based on load | Cost + performance balance |
| Reserved Instance | Commit to 1–3 years for a discount (30–70%) | Best for steady-state workloads |
| Spot Instance | Bid on spare capacity at 70–90% discount | Great for batch; risky for prod |
| On-Demand | Pay as you go, no commitment | Flexible but most expensive per hour |
| TCO | Total Cost of Ownership | Includes migration + operations + training |
| FinOps | Discipline of cloud financial management | Cross-functional: finance + engineering |
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyAppBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-app-bucket",
"arn:aws:s3:::my-app-bucket/*"
]
}
]
}
// This is an IAM policy. It follows the least-privilege
// principle — only read access is allowed.
// Terms used:
// - IAM policy → JSON rules attached to a role/user
// - Action → the API operations allowed
// - Resource → which AWS objects the policy applies to
// - Effect → Allow or Deny
// - ARN → Amazon Resource Name (unique identifier)
// Common mistake:
// Using "Action": "s3:*" and "Resource": "*"
// — this grants full access to every bucket, everywhere.
// That's the #1 audit finding in cloud security.
# Terraform — a cloud VPC that demonstrates several
# glossary terms in one file.
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = { Name = "main-vpc" }
}
# Two subnets in different AZs — high availability
resource "aws_subnet" "public" {
count = 2
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index)
availability_zone = data.aws_availability_zones.available.names[count.index]
tags = { Name = "public-${count.index}" }
}
# Load balancer across both subnets
resource "aws_lb" "app" {
load_balancer_type = "application"
subnets = aws_subnet.public[*].id
}
# Auto-scaling group — matches demand automatically
resource "aws_autoscaling_group" "app" {
vpc_zone_identifier = aws_subnet.public[*].id
min_size = 2
max_size = 10
desired_capacity = 2
}
# Glossary terms used in this file:
# - VPC → isolated network
# - Subnet → IP range within VPC
# - AZ → physical datacenter
# - Load Balancer → distributes traffic
# - Auto-scaling → dynamic capacity
# - Terraform → Infrastructure as Code (IaC)
Cloud cost glossary — the terms that decide your bill
Pricing models:
On-Demand → pay per hour/second, no commitment
Reserved Instance → 1–3 year commitment, 30–70% discount
Savings Plan → flexible RI variant, discounts by $/hour
Spot Instance → 70–90% cheaper, can be interrupted
Free Tier → limited free usage per month
Data transfer:
Egress → data leaving the cloud (charged)
Ingress → data entering the cloud (usually free)
Inter-AZ transfer → cross-AZ traffic is charged
CDN egress → cheaper than direct egress
Monitoring/cost tools:
Cost Explorer → AWS dashboard for spend
Budgets → alerts when approaching thresholds
Cost Allocation Tags → tag resources to attribute cost
Common cost mistakes:
1. Forgotten idle resources (unattached EBS, old snapshots)
2. Cross-AZ data transfer for high-traffic apps
3. Over-provisioned instances ("just in case")
4. NAT Gateway charges for outbound traffic
5. Non-optimized storage class (S3 Standard for cold data)
Rule of thumb:
Steady state → Reserved Instances
Spiky traffic → On-Demand + Auto-scaling
Batch jobs → Spot
Archival → Glacier / Coldline / Archive tier
SECTION 07DevOps in the cloud — CI/CD, IaC, observability
Cloud computing and DevOps are intertwined. These terms are essential when discussing modern cloud architecture:
| Term | Meaning | Common Tool |
|---|---|---|
| CI | Continuous Integration — automated testing on every commit | GitHub Actions, GitLab CI |
| CD | Continuous Delivery / Deployment | ArgoCD, Jenkins, GitHub Actions |
| IaC | Infrastructure as Code — provision infra via code | Terraform, CloudFormation, Pulumi |
| GitOps | Git as the source of truth for infra and deploys | ArgoCD, Flux |
| Observability | Understanding system state from outputs | Datadog, New Relic, Grafana |
| Metrics | Numeric time-series (CPU, latency, errors) | Prometheus, CloudWatch |
| Logs | Timestamped event records | ELK, CloudWatch Logs, Loki |
| Traces | Request paths across services | Jaeger, OpenTelemetry, X-Ray |
SECTION 08Test yourself — cloud computing glossary quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 09Frequently asked questions
What's the difference between a region and an availability zone?
A region is a geographic area (e.g., Mumbai, Singapore). Each region contains multiple availability zones (AZs) — physically isolated datacenters with independent power, cooling, and networking. To achieve high availability, you deploy across at least two AZs so a failure in one doesn't bring down your app.
Is serverless really serverless?
No — there are still servers, they're just not your concern. "Serverless" means you write code and the provider handles provisioning, scaling, and maintenance. You're still billed for the compute time used, and cold starts still exist. Serverless is a productivity trade-off, not a magical absence of infrastructure.
What's the difference between IaaS, PaaS, and SaaS?
IaaS gives you raw infrastructure (VMs, storage, network) — you manage everything above the OS. PaaS gives you a platform (runtime, scaling) — you deploy only your code. SaaS gives you the full application — you just use it. Higher letters = more managed by the provider.
What does an SLA actually guarantee?
An SLA (Service Level Agreement) guarantees uptime — e.g., 99.9% means ~8.7 hours of allowed downtime per year. It's usually backed by service credits, not refunds or damages. Read the SLA carefully: the difference between 99.9% and 99.99% is enormous for mission-critical workloads.
What is the "least privilege" principle?
Give every user, service account, and role only the minimum permissions needed to do its job — nothing more. Overly broad permissions are the root cause of many cloud breaches. In practice, this means using IAM roles (not root keys), scoping policies to specific resources, and auditing periodically.
SECTION 10Related reads
Classroom & online · Noida
Master cloud computing from first principles
Our Cloud Computing Course covers AWS, Azure, GCP fundamentals, compute models, storage, networking, security, IaC with Terraform, and certification prep (AWS SAA, Azure AZ-104) — with real projects and interview preparation.
₹28,000 · full programme- AWS + Azure + GCP
- Terraform + IaC projects
- Certification prep
- Weekday & weekend batches