Cloud computing is renting capabilities (compute, storage, networking) with managed building blocks and pay-as-you-go economics. The engineering work is choosing the right abstraction level and designing for failure, cost, and scale. Example: using a managed database can eliminate ops toil, but you must understand limits, backups, and recovery.

Cross-Provider Comparison

The three major providers expose analogous capability categories under different names. The products are not equivalent: APIs, consistency, regional topology, failure modes, quotas, and prices differ. Use the table to translate a requirement into candidates, then follow the provider hub and current documentation for the actual contract.

These map capabilities, not guarantees. Spanner commits writes through synchronous Paxos quorum replication within the selected instance configuration; replication crosses regions only for dual-region and multi-region configurations. Aurora Global and Azure geo-replication instead use asynchronous primary + replica designs.

Data Pipeline Capability Map

A data pipeline is easier to reason about as stages than as a provider catalog. Pick a service only after fixing the stage’s contract: delivery semantics, replay window, schema evolution, latency, data volume, query shape, and ownership.

This is a capability map, not a claim of service equivalence. Cosmos DB, for example, is an operational distributed database rather than Azure’s data-warehouse stage. The original source visual is therefore not embedded.

Managed Database Capability Map

Choose the data model and access pattern before the provider product. A managed label removes some operational work; it does not make consistency, indexing, partitioning, backup, or portability decisions disappear.

The rejected source visual aligned managed products with open-source engines as if their APIs and guarantees were interchangeable. Validate the exact region, feature, consistency, and recovery contract in provider documentation.

Timestream for LiveAnalytics closed to new AWS customers on June 20, 2025. New workloads should evaluate Timestream for InfluxDB or a different time-series path against their query language, retention, scale, and operating requirements rather than treating LiveAnalytics as generally adoptable.

Cloud Cost Loop

Run cost work in dependency order: allocate and measure, eliminate idle resources, right-size from utilization and reliability data, schedule variable demand, then commit only the stable baseline. Buying a reservation before removing waste discounts the wrong architecture. Cloud Cost Management develops the loop into allocation rules, anomaly handling, and unit economics.

Cloud-Native Anti-Patterns

Non-normative source visual

The labels are prompts to inspect operational coupling, not universal anti-patterns. A modular monolith or stateful component can be the simpler correct design when its ownership, lifecycle, and failure boundary are explicit.

Cloud abstractions move complexity; they do not remove it. A small system split into many services replaces local calls with fallible network calls and distributed ownership. A managed service per feature adds another IAM model, meter, quota, failure mode, and portability boundary. Treating every process as stateless merely moves durable state into databases, queues, object stores, and idempotency protocols. Keep a modular monolith, shared database, or explicit colocated state while one ownership and failure boundary remains the simpler correct design; split only when independent scale, release, security, or recovery requirements justify the distributed work.

Questions

How do you choose a compute abstraction — VMs, containers, or serverless?

• Serverless functions minimize ops for spiky, event-driven work; billing usually combines request count with execution duration and allocated resources, while cold starts, duration limits, and runtime constraints reduce control
• Containers fit custom runtimes and long-lived services, but the operating cost depends on the platform: a managed serverless container service can own orchestration and scale-to-zero mechanics, while managed Kubernetes still leaves cluster policy, upgrades, capacity, and workload operations to the platform team
• VMs are the escape hatch for legacy workloads, specialized OS/kernel needs, or lift-and-shift: most control, most ops
• Decide by workload shape, runtime limits, scaling model, and which layer the team is prepared to operate; the container image alone does not imply Kubernetes or VM-level operations

References

• NIST definition of cloud computing (SP 800-145) — the standard vendor-neutral definition of cloud service and deployment models.
• AWS Well-Architected Framework — the reliability, cost, security, and operational-excellence pillars of cloud design (broadly applicable beyond AWS).
• Azure Architecture Center — Cloud design patterns — a catalog of provider-neutral cloud patterns (retry, circuit breaker, sharding, and more).
• AWS Prescriptive Guidance — Modern data architecture — current AWS stages and representative ingestion, storage, processing, search, and warehouse services.
• AWS — Timestream for LiveAnalytics availability change — documents the June 20, 2025 new-customer closure and the recommended evaluation of Timestream for InfluxDB.
• Azure Architecture Center — Technology choices — current capability-first decision guides for compute, data, messaging, analytics, networking, and integration.
• Google Cloud — Data lifecycle — provider guidance for ingesting, storing, processing, analyzing, and presenting data.
• Google Cloud — Cloud Run functions — current product documentation for Google Cloud’s function deployment surface.
• Google Cloud — Spanner replication — documents synchronous Paxos quorum commits and the regional, dual-region, and multi-region replica topologies.
• AWS — What is Amazon SageMaker AI? — documents the December 2024 rename from Amazon SageMaker to Amazon SageMaker AI.
• System Design 101 — Big Data Pipeline Cheatsheet — editorial stage model; its stale and incorrect provider mappings were rebuilt rather than embedded.
• System Design 101 — Cloud Database Cheat Sheet — editorial prompt for a capability map; its provider equivalences were not treated as guarantees.
• System Design 101 — Cloud Cost Reduction Techniques — visual checklist reorganized here into a measurable optimization loop.
• System Design 101 — Cloud Native Anti-Patterns — visual inventory used to connect each smell to its actual complexity cost.