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

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

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

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(
    retries={"max_attempts": 5, "mode": "adaptive"},  # adaptive = client-side rate limiting
    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.

Interview angle

• “SNS vs SQS vs EventBridge?” — SQS = queue/work distribution; SNS = pub/sub fan-out; EventBridge = routing many event types to many targets with filtering, archive/replay, and SaaS integration. Add Kinesis when you need ordered high-throughput streaming with replay.
• “Lambda vs Fargate vs EKS?” — Lambda for event-driven/spiky/short; Fargate for long-running services without node management; EKS when you’re already K8s or need the ecosystem. Cost and ops burden rise left to right.
• “How do you connect Lambda to RDS at scale?” — RDS Proxy (watch pinning), reserved concurrency as a cap, or DynamoDB if the data model fits. The connection-storm problem is the thing being tested.
• “How does your container/CI get AWS permissions?” — roles, never keys: task role for ECS, IRSA/Pod Identity for EKS, GitHub OIDC for CI. Long-lived access keys are a red flag.
• “What’s a surprising AWS bill?” — NAT Gateway data processing, CloudWatch Logs ingestion, custom-metric cardinality, cross-AZ traffic. Knowing these signals real operational experience.
• “boto3 best practices?” — reuse clients, paginate everything, adaptive retries, stream large objects, set timeouts via Config, aioboto3 for async.