Nhà cung cấp Cloud (Cloud Providers)Cloud Providers

Part of the DevOps Roadmap knowledge base.

Overview

Cloud providers deliver computing resources — servers, storage, networking, databases, and higher-level managed services — over the internet on a pay-as-you-go basis. Instead of buying and racking physical hardware, teams provision infrastructure in minutes through an API or web console. The three dominant providers are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), with smaller players like DigitalOcean, Hetzner, and Alibaba Cloud serving specific niches (simplicity, price, or regional presence).

For DevOps engineers, the cloud is the default deployment target for most modern systems. Nearly every practice in the DevOps toolbox — infrastructure as code, autoscaling, immutable deployments, managed Kubernetes, serverless — is built on cloud primitives. Understanding how providers structure their services, how they charge, and where their responsibility ends and yours begins is foundational knowledge.

Because the big three offer largely equivalent core services under different names, the practical skill is less about memorizing one provider’s catalog and more about understanding the underlying concepts (compute, block/object storage, VPC networking, IAM) so you can map them across clouds. A useful mental model: every cloud is a warehouse of the same primitives — a machine that runs code, a disk, a bucket, a private network, an identity system, a queue, a database — dressed in different branding. Learn the primitives once and the console names become a translation exercise.

The economic shift the cloud represents

The deeper change the cloud introduced is financial, not technical. On-premises hardware is a capital expense (CapEx): you pay a large sum up front, depreciate it over years, and pay for peak capacity even when idle. Cloud is an operating expense (OpEx): you pay for what you use, when you use it, and you can turn it off. This turns infrastructure into a variable cost that scales with the business — powerful when growing, dangerous when unmanaged, because the same elasticity that lets you scale to a million users also lets a misconfigured loop scale your bill to five figures overnight. Cloud financial management (FinOps) exists precisely because the meter never stops.

Fundamentals

Service models: IaaS vs PaaS vs SaaS

The lower you go in the stack (IaaS), the more control and operational burden you have. The higher you go (PaaS/SaaS), the faster you move but the more you accept the provider’s constraints.

A common fourth category worth naming is CaaS (Containers as a Service) and FaaS (Functions as a Service), which sit between IaaS and PaaS: managed Kubernetes (EKS/AKS/GKE) and serverless functions (Lambda/Cloud Functions) let you ship containers or code without managing the underlying VMs. The boundaries are fuzzy — Cloud Run is simultaneously “serverless containers,” a CaaS, and a PaaS depending on who you ask. Don’t over-index on the taxonomy; use it to ask the real question: how much of this stack do I want to be responsible for at 3 a.m. during an incident?

“Managed” is a spectrum, not a switch. RDS manages the database engine, backups, and failover — but you still choose instance size, tune parameters, and design your schema. A fully serverless database like DynamoDB or Aurora Serverless removes even the sizing decision. Each rung up the ladder trades a knob you could turn for one less thing that can break.

Regions and Availability Zones

• A region is a geographic area (e.g., us-east-1, westeurope, asia-southeast1) containing multiple data centers.
• An Availability Zone (AZ) is one or more isolated data centers within a region, with independent power, cooling, and networking. AZs within a region are close enough for low-latency synchronous replication (single-digit milliseconds) but far enough apart that a fire, flood, or power failure in one does not take down another.
• Deploying across multiple AZs protects against data-center failure; deploying across multiple regions protects against regional outages and reduces latency for global users.
• Data transfer within an AZ is usually free; cross-AZ and cross-region traffic costs money — an often-overlooked cost driver.

Additional geographic concepts that matter in practice:

• Edge locations / PoPs (Points of Presence) — hundreds of small sites used by CDNs (CloudFront, Azure Front Door, Cloud CDN) and DNS to serve cached content close to users. They are not full regions; you cannot run a database there.
• Local Zones / Wavelength (AWS), Edge Zones (Azure) — extensions of a region placed in a metro area or telco network for ultra-low-latency use cases (gaming, live media, 5G).
• Region pairs (Azure) — Azure pairs regions for replication and staggered maintenance; some services replicate to the paired region by default.
• Region selection criteria — pick regions on four axes: (1) latency to your users, (2) data residency / sovereignty laws (GDPR, local data-protection rules), (3) service availability — not every service or instance type exists in every region, and new regions lag, and (4) price — the same VM can cost 20-50% more in one region than another (us-east-1 and us-west-2 are typically among the cheapest AWS regions).

Mental model for blast radius: a single instance can fail (deploy ≥2); an AZ can fail (spread across AZs); a region can fail (multi-region for tier-0 systems); and rarely, a global control plane can fail (e.g., a global IAM or DNS outage takes multiple regions with it — the reason true global redundancy sometimes means multi-cloud, not just multi-region).

Shared responsibility model

The provider secures the cloud; you secure what you put in it.

Most cloud breaches are caused by customer-side misconfiguration (public S3 buckets, over-privileged IAM roles), not provider failures.

The dividing line shifts with the service model. This is the single most important nuance: the more managed the service, the more the provider takes on, but data, identity, and access configuration are always yours.

• IaaS (EC2): you patch the OS, configure the firewall, encrypt the disk, manage the app. The provider only guarantees the hardware and hypervisor.
• PaaS (App Service, RDS): the provider patches the OS and runtime; you still own data classification, access control, and app-layer security.
• SaaS (Office 365): the provider runs almost everything; you still own who has access, how identities are governed, and what data you put in.

A one-line heuristic that survives every service model: “Of, In, and Access.” The provider secures the security of the cloud; you secure what you put in the cloud and who has access to it. Misconfiguration — a public bucket, an unrotated key, an over-broad role — is always on the customer side of the line.

Pricing models

Commitment options compared:

Spot/preemptible mechanics matter. Spot capacity can be reclaimed with a short warning (AWS gives a 2-minute notice; GCP Spot VMs a 30-second notice; Azure Spot varies). Architect for it: checkpoint work, drain gracefully, spread across instance types and AZs so a single capacity crunch doesn’t reclaim everything at once, and never put a stateful primary database on spot. Spot is ideal for CI runners, batch/ETL, rendering, ML training with checkpointing, and Kubernetes worker nodes behind a cluster autoscaler.

Egress is the pricing trap that surprises everyone. Ingress (data into the cloud) is almost always free. Egress (data out to the internet, and often cross-region and cross-AZ) is metered and can dominate a bill for data-heavy or media-heavy workloads. The mental model: it’s cheap to check in, expensive to check out. This is also a deliberate lock-in lever — moving terabytes to another cloud costs real money — which is why regulators (and the EU Data Act) have pushed providers toward waiving egress fees for customers leaving.

Key Concepts

Core service mapping: AWS vs Azure vs GCP

Treat this table as a Rosetta Stone, not gospel — services overlap and get renamed. The value is in recognizing that when someone says “we use Pub/Sub,” you immediately know its role (SQS/SNS + Kinesis territory) even if you’ve never touched GCP.

Compute options within a single provider

Even inside one cloud, “compute” is a ladder from most-control to least-management, and picking the wrong rung is a common mistake:

1. Bare metal / dedicated hosts — full physical isolation for licensing or compliance; rare.
2. Virtual machines (EC2, Azure VMs, Compute Engine) — the classic IaaS unit; you own the OS.
3. Managed Kubernetes (EKS/AKS/GKE) — orchestrated containers; you own workloads and (often) worker nodes.
4. Serverless containers (Fargate, Cloud Run, Container Apps) — bring a container image, forget the nodes.
5. Functions (Lambda, Cloud Functions, Azure Functions) — bring a function, forget the container.
6. PaaS app hosting (Elastic Beanstalk, App Service, App Engine) — bring code, forget almost everything.

The general rule: start as high on the ladder as your requirements allow, and drop down only when a concrete constraint (latency, cost at scale, special hardware, licensing) forces you to. Teams routinely reach for Kubernetes when Cloud Run would have done, paying for cluster complexity they don’t need.

Instance families and sizing

VMs come in families tuned for different workloads — the naming differs but the categories are universal:

Burstable instances (T-series, B-series) accumulate CPU credits while idle and spend them during spikes — cheap for bursty, low-average workloads like small web servers, but they throttle hard if you sustain high CPU and run out of credits. Never put a steadily-busy service on a burstable instance and then wonder why it’s slow.

Right-sizing is a continuous discipline, not a one-time choice: measure real CPU/memory/IO utilization and shrink over-provisioned instances. The most common waste in any cloud bill is oversized, under-utilized VMs bought “to be safe.”

Smaller providers worth knowing

• DigitalOcean — simple UX, predictable flat pricing, Droplets (VMs), managed Kubernetes and databases, App Platform (PaaS), Spaces (S3-compatible object storage). Great for startups, side projects, and developers who want to avoid the complexity of the big three. Its egress pricing is far more generous than hyperscalers.
• Hetzner — extremely price-competitive dedicated and cloud servers in Europe (and now the US); popular for self-hosted Kubernetes, homelab-grade production, and cost-sensitive workloads. You trade the vast managed-service catalog of the hyperscalers for dramatically lower per-core and per-TB prices.
• Alibaba Cloud — the dominant provider in China and much of Southeast Asia; essential if you serve mainland Chinese users (ICP licensing, local regions, integration with local payment and CDN ecosystems).
• Oracle Cloud (OCI) — aggressive free tier and competitive egress; strong for Oracle Database workloads.
• Cloudflare — not a full IaaS, but its edge platform (Workers, R2 object storage with zero egress fees, D1, KV) is increasingly a serverless-first alternative for the right workloads.

The pattern: hyperscalers win on breadth of managed services and enterprise compliance; specialists win on price, simplicity, or a specific region/ecosystem. A common architecture is “hyperscaler for the managed database and compliance, specialist for the CDN or object storage where egress dominates.”

CLI quick taste

# AWS: launch a VM
aws ec2 run-instances --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro --count 1

# Azure: create a VM
az vm create --resource-group myRG --name myVM \
  --image Ubuntu2204 --size Standard_B1s

# GCP: create a VM
gcloud compute instances create my-vm \
  --machine-type=e2-micro --zone=asia-southeast1-a

These one-liners are for learning only. In practice you never create production infrastructure imperatively — you declare it in Terraform/OpenTofu or the provider’s native IaC so it’s reviewable, version-controlled, and reproducible. The CLI is for inspection, break-glass fixes, and scripting, not for standing up your stack by hand.

Account and organization structure

Every provider offers a hierarchy for isolating environments and applying policy centrally:

The standard pattern is a landing zone: separate accounts/subscriptions/projects per environment (dev, staging, prod) and often per team, with a central “management” account for billing and logging and a “security” account for audit trails. This gives blast-radius isolation (a mistake in dev can’t touch prod), clean cost attribution, and a place to enforce org-wide guardrails. AWS Control Tower, Azure Landing Zones, and GCP’s landing zone blueprints automate the setup.

How to choose a provider

1. Existing ecosystem — heavy Microsoft shop (AD, Office 365)? Azure integrates naturally and often comes bundled in enterprise agreements. Data/ML focused? GCP’s BigQuery and Vertex AI are strong. Broadest catalog and market share (largest talent pool)? AWS.
2. Team expertise — hiring and existing knowledge often outweigh technical differences; a team fluent in one cloud ships faster than the same team fighting an unfamiliar “better” one.
3. Region availability — check latency and data-residency requirements for your users; confirm the specific services and instance types you need actually exist in your target region.
4. Pricing for your workload — model your actual usage; egress fees and managed-service premiums differ significantly. Use each provider’s pricing calculator with realistic numbers, not list prices.
5. Compliance — required certifications (PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001, local regulations) per region and per service.
6. Managed services you’ll actually lean on — the “best” cloud is often the one with the specific managed service that removes the most toil for your workload (BigQuery for analytics, DynamoDB for key-value at scale, Cosmos DB for global multi-model).

Multi-cloud considerations

• Pros: reduces vendor lock-in leverage, meets regulatory/data-residency demands, lets you pick best-of-breed services (e.g., BigQuery on GCP but everything else on AWS), and provides genuine resilience against a whole-provider outage for tier-0 systems.
• Cons: doubles operational surface (two IAM models, two networking stacks, two billing systems, two sets of on-call runbooks), complicates security posture, fractures your team’s depth of expertise, and cross-cloud egress is expensive and slow.
• Portability ≠ multi-cloud. Keeping workloads portable (containers, Kubernetes, Terraform, open-source data stores) is cheap insurance and worth doing. Actively running the same workload live on multiple clouds is expensive and rarely worth it for small teams.
• Pragmatic stance: most teams are best served going deep on one provider and keeping portability as a hedge, rather than diluting effort across two. Reserve true active/active multi-cloud for organizations with the scale, staff, and regulatory drivers to justify it. Multi-cloud “for redundancy” is usually a solution in search of a problem for teams under a few hundred engineers.
• Hybrid cloud (on-prem + cloud) is a distinct pattern, common in enterprises with existing data centers, sunk hardware costs, or data that legally cannot leave the premises; tools like AWS Outposts, Azure Arc/Stack, and Anthos extend cloud control planes on-prem.

Best Practices

1. Use Infrastructure as Code from day one (Terraform/OpenTofu, Pulumi, CloudFormation, Bicep) — clicking in the console creates undocumented, unreproducible, un-reviewable “snowflake” infrastructure that nobody can rebuild after an outage.
2. Enable MFA and never use the root/owner account for daily work — create scoped IAM users/roles; lock away the root/global-admin account, put it behind MFA, and use it only for break-glass tasks that genuinely require it.
3. Apply least privilege in IAM — start with narrow permissions and widen as needed; prefer roles and short-lived credentials over long-lived access keys; audit with tools like AWS IAM Access Analyzer, Azure PIM, and GCP Policy Analyzer.
4. Set billing alerts and budgets immediately — surprise bills are the most common newcomer pain; alert at 50/80/100% of expected spend, and enable anomaly detection so a runaway loop pages you in hours, not at month-end.
5. Deploy across at least two AZs for anything production — single-AZ deployments turn routine data-center maintenance into your outage; multi-AZ is the cheapest resilience you will ever buy.
6. Tag every resource (team, environment, service, cost-center, owner) — tags power cost allocation, cleanup automation, ownership tracking, and security policy; enforce tagging with policy-as-code so untagged resources are blocked or flagged.
7. Prefer managed services for undifferentiated heavy lifting — running your own PostgreSQL, Kafka, or Redis on VMs rarely beats the managed equivalent once you factor in backups, patching, failover, and the on-call burden. Reserve self-management for cases with a concrete cost or control justification.
8. Watch egress and cross-AZ costs — data into the cloud is free, data out is not; keep chatty traffic within one AZ/region, use private endpoints instead of routing through the public internet, and put a CDN in front of static content.
9. Use spot/preemptible instances for interruptible workloads — 60–90% savings for CI, batch, ETL, and stateless fault-tolerant services; design them to checkpoint and drain gracefully on the reclamation warning.
10. Buy reservations/savings plans only after usage stabilizes — measure 2–3 months of steady-state usage first, then commit to your baseline; leave the spiky top of the curve on on-demand or spot.
11. Right-size continuously — the biggest line item in most bills is oversized, under-utilized compute bought “to be safe”; review utilization and shrink monthly.
12. Keep an organization/landing-zone structure — separate accounts/projects/subscriptions per environment for blast-radius isolation, clean cost attribution, and centralized guardrails (SCPs/Azure Policy/Org Policies).
13. Encrypt by default and manage keys deliberately — enable encryption at rest and in transit everywhere (it’s usually free and on by default); use the provider KMS, and use customer-managed keys where compliance requires control over the key lifecycle.
14. Centralize logging and audit trails — turn on CloudTrail / Azure Activity Log / Cloud Audit Logs in a dedicated, write-once account so you have an immutable record of who did what when — indispensable during incidents and audits.
15. Automate cleanup of ephemeral resources — dev/test environments, orphaned volumes, unattached IPs, and old snapshots quietly accrue cost; schedule teardown and run a “cost janitor” (e.g., cloud-nuke, provider recommendations) regularly.
16. Learn concepts, not consoles — VPCs, IAM, object storage, load balancing, and identity federation transfer across all providers; console layouts and exact button names do not, and they change constantly.

References

• roadmap.sh — DevOps Roadmap
• AWS Documentation
• Azure Documentation
• Google Cloud Documentation
• AWS Well-Architected Framework
• Google Cloud Architecture Framework
• Azure Well-Architected Framework
• AWS Shared Responsibility Model
• Microsoft — Shared responsibility in the cloud
• Google Cloud — Shared responsibilities and shared fate
• Compare AWS and Azure services (Microsoft)
• GCP for AWS professionals — service comparison (Google)
• AWS Global Infrastructure — Regions and AZs
• AWS Pricing Calculator
• Azure Pricing Calculator
• Google Cloud Pricing Calculator
• FinOps Foundation
• DigitalOcean Documentation
• Hetzner Cloud Documentation
• Book: Cloud Strategy — Gregor Hohpe
• Book: The Cloud Adoption Playbook — Moe Abdula et al.