Managed Services & Cloud Trade-offs

What this subtopic owns

Cloud primitives appear in context across Security (Secrets Manager), Databases (S3 multipart), Data Engineering (EMR, K8s executors), and Microservices Deep Cuts (multi-region). This subtopic assembles decision tables for system design — not AWS certification depth.

Staff loops assume you can name when managed beats self-hosted and which managed SKU fits an access pattern.

The default Staff posture

Start managed until cost, latency, compliance, or operational control forces self-hosted — and name the trigger that would flip the decision.

Interviewers want trade-off vocabulary, not "we use AWS because everyone does."

Compute

Option	Strengths	Weaknesses	Typical use
VMs / bare metal	Predictable, full control	You own patching, scaling	Legacy, GPU, special kernels
Containers on K8s	Portable, fine-grained scale, standard at FAANG	Ops complexity, YAML sprawl	Microservices default
Serverless (Lambda, Cloud Functions)	Zero idle cost, fast spin for sporadic work	Cold start, timeout limits, debug pain	Event handlers, low-QPS APIs, ETL triggers

K8s in one paragraph: scheduler places pods on nodes; Services provide stable DNS; Deployments roll out replicas; HPA scales on CPU/custom metrics. You don't need to draw the control plane — say stateless services in pods, state in managed DB/cache, ingress/gateway at edge.

Cross-reference: Platform Resilience for canary/blue-green on K8s.

Messaging & integration

Service	Ordering	Replay	Ops model	Pick when
SQS (standard)	Best-effort order	Delete on ack; no long replay	Fully managed	Task queues, decouple services
SNS / pub-sub	Fan-out only	No consumer offset	Managed	Notifications, fan-out to many
Kafka / Kinesis / Pulsar	Per-partition order	Log retention, replay	Higher ops (or managed MSK)	Event sourcing, stream processing, audit log
RabbitMQ (managed)	Queue semantics	Broker-dependent	Medium	RPC-style work queues, routing

Rule of thumb: need replay and multiple consumer groups → log (Kafka). Need simple work queue → SQS. Need push to HTTP endpoints → SNS + webhooks (Communication → Webhooks).

Distributed theory (at-least-once, idempotency) → Distributed Systems → Messaging.

Databases & storage

Store	Access pattern	Managed examples	Self-hosted analog
Relational OLTP	ACID, joins, ad-hoc SQL	RDS, Cloud SQL, Aurora	Postgres on VM
Wide-column / KV at scale	Partition key, high write QPS	DynamoDB, Bigtable	Cassandra
Globally consistent SQL	Serializable cross-region	Spanner, CockroachCloud	Cockroach self-hosted
Object blob	Large immutable files	S3, GCS	MinIO
Search	Full-text, facets	OpenSearch managed	Elasticsearch cluster
Cache	Sub-ms KV, TTL	ElastiCache Redis	Redis on K8s

RDS vs DynamoDB: complex queries and transactions → RDS. predictable partition-key access at huge scale, ops minimal → DynamoDB. Don't put relational reporting on Dynamo without accepting access-pattern rigidity.

S3 for images, exports, data lake bronze layer — multipart upload for large objects (Databases → Object & Lakes).

IAM & secrets (design-level)

• Workload identity — pod/service account → cloud IAM role (no long-lived keys in env)
• Secrets Manager / Parameter Store — rotation, audit; never commit secrets
• Least privilege — service A's role can only s3:GetObject on one prefix

Detail → Security → Distributed & Platform Security.

Regional & availability primitives

• Multi-AZ — synchronous replication within region; default for managed DB
• Multi-region — async replication, RPO/RTO trade-offs; Microservices Deep Cuts → Multi-Region
• Global load balancing — GeoDNS/anycast; stale DNS TTL risks

Decision flow (verbal)

1. What is the access pattern? (point read, scan, search, stream)
2. What consistency does the product need?
3. What QPS and data size at year 3?
4. Managed unless: cost at scale, custom kernel, regulatory data residency requiring self-host
5. What failure mode if the managed service throttles or region fails?

Anti-patterns in interviews

• "We'll use Kafka for everything" — overkill for 100 msg/s notifications
• "Lambda for the core API" — cold starts and 15-min limit bite at scale
• "One RDS forever" — no sharding story at 10 TB write-heavy
• Ignoring egress cost — cross-AZ and cross-region data transfer adds up

Senior signal

"We'd run stateless API on EKS, Postgres on Aurora multi-AZ for orders, Dynamo for session cart if we need single-digit-ms and key-based access, SQS for email jobs, and S3 for receipts — Kafka only if we need replayable order events for analytics."

Link forward

Service Discovery — how pods find each other. Secrets in Security track. Capacity estimation in Distributed Foundations → Assembly for sizing RDS vs cache.