AWS Interview Essentials — Cross-Service Decision Matrices

The cross-cutting content interviewers ask about most. Individual service files (Compute/, Databases/, etc.) have the depth; this file is the “which one and why” layer plus the patterns that span services.

1. Messaging: SNS vs SQS vs EventBridge vs Kinesis vs MSK

The first split is message versus stream: a message is consumed and gone, a stream is a log you read at your own offset and can re-read.

Message-based — SQS, SNS, EventBridge:

Stream-based — Kinesis and MSK, both ordered with replay:

Latency is milliseconds for all five, so it is not the deciding factor. | Best for | work distribution, buffering | fan-out notifications | event routing across many types/targets, SaaS integration, replay | high-throughput streaming, multiple independent readers, ordered replay | Kafka-compatible streaming, existing Kafka tooling |

Decision shortcut:

• Two services, reliable handoff → SQS.
• Tell N services “this happened” → SNS.
• Route many event types to many targets with filtering / archive-replay / partner SaaS → EventBridge.
• High-throughput ordered stream, replay, multiple independent consumers → Kinesis (or MSK if you need Kafka APIs/tooling).
• “Exactly once across DB + queue” → none of these alone; use transactional outbox + idempotent consumers.

See Application_Integration/ for SQS/SNS/EventBridge depth.

2. Compute: Lambda vs Fargate vs ECS-on-EC2 vs EKS vs EC2 vs App Runner vs Batch

The axis that decides it is who manages the capacity.

You manage nothing — it scales to zero and you pay per use:

You manage nodes — cheaper at steady volume, more to run:

Batch sits outside both: queue-driven, scales to zero when the queue empties, and priced per job. Use it for scheduled or parallel work such as rendering and ETL rather than for anything serving requests.

Decision shortcut:

• Event-driven, short, spiky → Lambda.
• Long-running web service / worker, don’t want to manage nodes → Fargate.
• Steady high-volume where per-CPU cost matters, or GPU → ECS-on-EC2 (Spot + Reserved).
• Already K8s / multi-cloud / need the K8s ecosystem → EKS.
• Simple “deploy my container as a web app” → App Runner.
• Big parallel batch jobs → Batch.

See Compute/01_Compare_AWS_Compute_Services/README.md and individual files.

3. Datastore: RDS vs Aurora vs DynamoDB vs ElastiCache vs DocumentDB vs OpenSearch

Relational, when you need joins and transactions:

Everything else, chosen by access pattern rather than by data model:

DynamoDB scales horizontally and gives single-digit millisecond latency, but only for access patterns you designed the keys around — ad-hoc queries are the thing it is bad at. ElastiCache is for the hot path: sessions, rate limits, cached reads. OpenSearch also serves vector search, which is why it appears in RAG designs on AWS.

Decision shortcut:

• Relational, joins, transactions, moderate scale → RDS.
• Same but need faster failover, more read replicas, or storage > 64 TB → Aurora.
• Known access patterns, massive scale, predictable latency → DynamoDB.
• Sub-ms cache in front of any of the above → ElastiCache.
• You have MongoDB code → DocumentDB (or self-host / Atlas).
• Full-text search, log analytics, vector search → OpenSearch.

4. Request flow walkthrough

A typical production request, with the layers identified:

User
  │
  ▼
Route 53            DNS resolution; latency/failover routing
  │
  ▼
CloudFront          edge cache; static assets served here; TLS termination
  │  (cache miss / dynamic)
  ▼
AWS WAF             rate limiting, SQLi/XSS rules, geo / IP blocking
  │
  ▼
ALB  or  API Gateway
  │  ALB: L7 routing, ECS/EKS targets, OIDC auth
  │  API GW: REST/HTTP API, Cognito/Lambda authorizers, throttling, usage plans
  ▼
Compute             ECS/Fargate task  OR  Lambda
  │  - auth already validated at the edge / gateway
  │  - app reads secrets from Secrets Manager / SSM at cold start
  ▼
Data layer
  │  - RDS via RDS Proxy (Lambda) or direct pool (long-running)
  │  - DynamoDB direct
  │  - ElastiCache checked first (cache-aside)
  ▼
Async side-effects  → SQS / SNS / EventBridge → workers

Where caching lives: CloudFront (edge), ElastiCache (app data), API Gateway cache (rarely worth it). Where auth lives: WAF (coarse), gateway authorizer (token validation), app (fine-grained authz). Observability: CloudWatch Logs/Metrics + X-Ray traces threaded through every hop.

5. The “Lambda + RDS” problem

The single most-asked AWS+backend interview question.

The problem: Lambda scales by spawning concurrent execution environments. Each one opens its own DB connections. 1000 concurrent Lambdas → 1000 Postgres connections → RDS hits max_connections, refuses new connections, the whole service fails. Postgres connections are expensive (a process + memory each); a db.t3.medium caps around ~340 connections.

Three solutions:

In an interview, name all three and the pinning gotcha on RDS Proxy. The “right” answer is usually RDS Proxy, with reserved concurrency as a stopgap and DynamoDB as the answer if the data model allows it.

6. IAM patterns for containerized + serverless apps

How code gets AWS permissions without long-lived keys:

The unifying principle: every workload gets a role, not keys. Keys (AWS_ACCESS_KEY_ID/SECRET) are a smell — they don’t rotate, they leak, they can’t be scoped per-request. See Security_Identity_and_Compliance/02_.../02_advanced_role_patterns.md.

7. Cost gotchas reference

The bills that surprise teams:

8. boto3 idioms

Python-specific patterns interviewers expect:

import boto3
from botocore.config import Config

# Client/session reuse — create once, not per request.
# In Lambda: module-level, outside the handler.
session = boto3.Session()
config = Config(
    # adaptive = client-side rate limiting
    retries={"max_attempts": 5, "mode": "adaptive"},
    connect_timeout=3,
    read_timeout=10,
)
s3 = session.client("s3", config=config)

# Paginators — never assume one response has everything
paginator = s3.get_paginator("list_objects_v2")
for page in paginator.paginate(Bucket="my-bucket", Prefix="logs/"):
    for obj in page.get("Contents", []):
        process(obj)

# Streaming — don't load whole objects into memory
obj = s3.get_object(Bucket="b", Key="big.json")
for line in obj["Body"].iter_lines():
    process(line)

s3.upload_fileobj(file_like, "b", "key")      # streams the upload
s3.download_fileobj("b", "key", file_like)    # streams the download

# Async — for async apps, use aioboto3 / aiobotocore
# import aioboto3
# async with aioboto3.Session().client("s3") as s3:
#     await s3.put_object(...)

Key points:

• Reuse clients/sessions — client creation is expensive (loads service models). In Lambda, module-level.
• retries.mode="adaptive" — client-side rate limiting that backs off when AWS throttles; better than the default “legacy” mode.
• Always paginate — list_* APIs cap results; a paginator handles continuation tokens for you.
• Stream large payloads — upload_fileobj/download_fileobj/iter_lines instead of reading whole objects.
• Set timeouts via botocore.config.Config — defaults are generous; a hung AWS call shouldn’t hang your request.
• Async — aioboto3 (wraps aiobotocore) for asyncio apps; don’t call sync boto3 in an async handler without run_in_executor.