Contents

Course · 13

Which AWS service should hold your data, and which should carry your messages?

This page covers the AWS services that store data (RDS, Aurora, DynamoDB, ElastiCache, MemoryDB), move messages (SQS, SNS, EventBridge, Kinesis, MSK), glue serverless apps together (Step Functions, API Gateway) and watch them (CloudWatch, X-Ray). Every limit was checked on docs.aws.amazon.com on 2026-10-25. Several changed recently, so older notes may be wrong.

TL;DR

Pick the store by access pattern (SQL joins → RDS or Aurora; key lookups at any scale → DynamoDB), and pick the pipe by delivery style (one worker → SQS; many copies → SNS or EventBridge; ordered replayable stream → Kinesis or MSK).

RDS Multi-AZ is for surviving failure (standby you cannot read); read replicas are for scaling reads (async, readable). Different jobs.
Aurora keeps 6 copies of your data across 3 AZs and allows up to 15 replicas.
DynamoDB: item max 400 KB; 1 RCU = one strong read of up to 4 KB per second; 1 WCU = one write of up to 1 KB per second; one partition tops out at 3,000 RCU / 1,000 WCU.
New limits in 2025–2026: SQS messages up to 1 MiB, EventBridge events up to 1 MB, Kinesis records up to 10 MiB.
API Gateway REST integration timeout is 29 s by default, and can now be raised for Regional and private APIs.

400KB

DynamoDB max item size

6copies

Aurora storage copies, across 3 AZs

1MiB

SQS max message size (was 256 KiB)

29s

API Gateway REST default max integration timeout

—Words you need

Each jargon word once, in plain words glossary

RDS

AWS runs a normal SQL database (MySQL, PostgreSQL...) for you.

Multi-AZ

A hidden spare copy in another AZ, used only on failure.

Read replica

A readable copy that trails the main database slightly.

PITR

Point-in-time restore: rewind the database to a past second.

Partition key

The field DynamoDB hashes to decide where an item lives.

Sort key

Orders items that share a partition key.

GSI / LSI

Extra indexes with a different key, for other query patterns.

RCU / WCU

Units of read and write capacity in DynamoDB.

Hot partition

One key getting far more traffic than the rest.

Visibility timeout

How long a taken SQS message stays hidden from others.

Dead-letter queue

A side queue for messages that keep failing.

Fan-out

One message copied to many receivers.

Shard

One lane of a Kinesis stream with fixed throughput.

Idempotent

Safe to run twice; the second run changes nothing.

Databases

01RDS: managed SQL databases

Engines, Multi-AZ vs read replicas, backups and point-in-time restore interview favourite

RDS runs a normal relational database for you: AWS handles setup, backups, patching and failover. The RDS guide lists six engines: IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle and PostgreSQL. Aurora has its own guide (next section).

The classic interview trap: Multi-AZ and read replicas sound alike but solve different problems.

Standby = insurance. Read replica = extra readers. You can have both.

Question	Multi-AZ (DB instance)	Read replica
Purpose	High availability: survive an AZ or instance failure	Scale reads; also a reporting copy
Copy method	Synchronous	Asynchronous (may lag)
Can you read from it?	No	Yes
Failover	Automatic; typically 60–120 s	Manual promotion to a standalone DB
How many	One standby (a Multi-AZ DB cluster has two readable standbys)	Up to 15 per source (quota)

Backups: automated backups keep daily snapshots plus transaction logs, so you can restore to any second inside the retention window. That is PITR.

In everyday words

Multi-AZ is a spare tyre in the boot: you cannot drive on it until a tyre bursts. A read replica is a second car that follows the first a few seconds behind, which friends can ride in.

Actually

RDS docs (checked 2026-10-25): the Multi-AZ standby is a "synchronous standby replica" and "You can't use a standby replica to serve read traffic". A Multi-AZ DB cluster is "semisynchronous" with "two readable replica DB instances". "Failover times are typically 60–120 seconds." Read replicas: "Amazon RDS copies them asynchronously"; the quota is 15 per primary (Oracle: AWS recommends 5). Backup retention is 0–35 days; the default is 7 days in the console and 1 day from the API or CLI. PITR uses transaction logs that RDS uploads "every five minutes", so the latest restorable time is usually a few minutes back. Sources: Multi-AZ instance, Multi-AZ cluster, failover, read replicas, backup retention, PITR.

Say it plainly in interviews: Multi-AZ for availability, replicas for read scale, backups for "oops, I deleted a table".

Source: What is RDS · RDS quotas

02Aurora: storage built for the cloud

One shared volume, 6 copies over 3 AZs, up to 15 replicas, Serverless v2 deep dive

Aurora is AWS's MySQL- and PostgreSQL-compatible database. The big idea: compute and storage are split. The writer and all readers share one cluster volume. So a replica does not need its own full copy of the data.

Readers read the same volume the writer writes, so replica lag stays small.

Fact (checked 2026-10-25)	Value
Storage copies	6 copies across 3 AZs, written synchronously
Copies it can lose	Up to 2 without losing writes; up to 3 without losing reads (Aurora FAQ)
Replicas	Up to 15 Aurora Replicas; lag "usually much less than 100 milliseconds"
Max storage	256 TiB on newer engine versions; 128 TiB on older ones
Serverless v2 capacity	Measured in ACUs (about 2 GiB memory each); 0 to 256 ACU (MySQL), up to 384 ACU (newer PostgreSQL); steps of 0.5 ACU; 0 ACU means auto-pause

In everyday words

Plain RDS replicas each keep their own notebook and copy lines over. Aurora readers all look at one shared whiteboard, which is itself photographed six times in three rooms.

Actually

Aurora docs: Aurora "synchronously replicates the data across Availability Zones to six storage nodes". The Aurora FAQ: it handles "loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability". Replication docs: "up to 15 Aurora Replicas", lag "usually much less than 100 milliseconds". Serverless v2 now runs "0 ACUs to 256 ACUs for Aurora MySQL and to 384 ACUs for Aurora PostgreSQL" (384 needs recent PostgreSQL versions). The storage max is 256 TiB on recent versions, but the RDS quotas page still says 128 TiB: an AWS docs inconsistency. Sources: Aurora high availability, Aurora FAQ, Aurora replication, Serverless v2, Aurora quotas.

Need SQL with many fast replicas or spiky load? Aurora (Serverless v2 for spikes). Need the cheapest small SQL box? Plain RDS.

Source: Aurora User Guide pages linked above

03DynamoDB: keys, items and indexes

Design for your queries first; the table follows deep dive

DynamoDB is a key-value and document database with no servers to run. A table holds items (rows). Each item has a primary key:

Partition key only: DynamoDB hashes it to choose the partition (storage slice) where the item lives. Lookup is by exact key.
Partition key + sort key: items with the same partition key sit together, ordered by the sort key. You can ask for ranges, like "all orders of user 42 in March".

Limit (checked 2026-10-25)	Value
Max item size	400 KB
Partition key value	max 2,048 bytes
Sort key value	max 1,024 bytes
Global secondary indexes per table	20 (default quota)
Local secondary indexes per table	5
Item collection size with an LSI	10 GB per partition key

GSI vs LSI

Question	Global secondary index (GSI)	Local secondary index (LSI)
Keys	Any new partition key and sort key	Same partition key, different sort key
When created	Any time	Only when the table is created
Strongly consistent reads?	No, eventually consistent only	Yes, can be
Size limit	None per key	10 GB per partition key value
Capacity	Its own	Shares the table's

In everyday words

The partition key is which drawer a file goes in. The sort key is the order of files inside the drawer. A GSI is a second filing cabinet sorted a different way, updated a moment later.

Actually

DynamoDB docs: "The maximum item size in DynamoDB is 400 KB"; LSIs "are created when the table is created"; "All reads from GSIs and streams are eventually consistent"; the default quota is "20 global secondary indexes per table" and "up to 5 local secondary indexes". Sources: Constraints, Service quotas, LSI, read consistency.

List your queries before you pick keys. A query you did not plan for usually needs a new GSI or a full scan.

Source: DynamoDB constraints

04DynamoDB: capacity, consistency, hot partitions

RCU and WCU math, on-demand vs provisioned, adaptive capacity interview favourite

Unit	Buys you, per second
1 RCU	1 strongly consistent read of an item up to 4 KB, or 2 eventually consistent reads
Transactional read	2 RCUs per 4 KB
1 WCU	1 write of an item up to 1 KB
Transactional write	2 WCUs per 1 KB

Worked example

Items are 6 KB. You need 100 reads per second and 50 writes per second of 2.5 KB items.

// reads: round item size UP to the next 4 KB
6 KB / 4 KB = 1.5  → 2 RCU per strong read
100 strong reads/s × 2        = 200 RCU
100 eventual reads/s × 2 / 2  = 100 RCU
100 transactional reads/s × 2 × 2 = 400 RCU

// writes: round UP to the next 1 KB
2.5 KB → 3 WCU per write
50 writes/s × 3               = 150 WCU
50 transactional writes/s × 3 × 2 = 300 WCU

Read capacity for the same 100 reads/s of 6 KB items

RCU needed by read type. Hover for the formula.

Transactional

400

Strongly consistent

200

Eventually consistent

100

Show the full table

Read type	RCU per read	RCU for 100/s
Eventually consistent	1	100
Strongly consistent	2	200
Transactional	4	400

On-demand vs provisioned

Mode	How you pay	Scaling	Pick when
On-demand (default)	Per request	Instantly handles up to double the previous peak	New or spiky traffic
Provisioned	Per RCU/WCU per hour (with optional auto scaling)	You set or auto-scale capacity	Steady, predictable traffic

Consistency: reads are eventually consistent by default (may miss a write from the last moment). Ask for strongly consistent to always see the latest write; it costs double and is not possible on GSIs or Streams.

Hot partitions: each partition can serve at most 3,000 RCU and 1,000 WCU per second. If one key (say a celebrity's user ID) gets most traffic, that partition throttles even when the table has spare capacity. Adaptive capacity helps: DynamoDB raises throughput for busy partitions and can move hot items to their own partitions. But one single item still cannot pass the per-partition limit.

In everyday words

A supermarket with 50 tills still jams if everyone queues at till 7. Adaptive capacity opens extra tills near the busy one, but one shopper can only be served so fast.

Actually

DynamoDB docs: partitions have a "maximum capacity of 3,000 read units per second and 1,000 write units per second". Adaptive capacity "works by automatically and instantly increasing throughput capacity for partitions that receive more traffic" and can "isolate frequently accessed items". It will not split item collections on tables with an LSI. On-demand "instantly accommodates up to double the previous peak traffic" and is "the default and recommended" mode. On-demand prices dropped 50% from 1 Nov 2024. Fixes for a hot key: write sharding (add a random suffix 0–N to the key, then read all N), caching with DAX, or a better key. Sources: partition key design, adaptive capacity, on-demand mode, Nov 2024 price cut.

Round up item sizes, halve for eventual reads, double for transactions, and pick a key with many distinct values.

Source: capacity unit rules · read consistency

05DynamoDB: single-table design, Streams, TTL, transactions, DAX

The features that turn a key-value store into an app backbone deep dive

Feature	What it does	Key fact (checked 2026-10-25)
Single-table design	Store many entity types (user, order, address) in one table; the sort key says which type	One query can fetch related items together, at lower cost. Downsides: steep learning curve, shared backups and encryption
DynamoDB Streams	An ordered log of item changes	Each record appears exactly once, in order per item; kept for 24 hours
TTL	Auto-deletes items after an expiry timestamp	Usually within a few days of expiry; does not use write capacity
Transactions	All-or-nothing writes or reads across items and tables	Up to 100 unique items and 4 MB per transaction; costs double capacity
DAX	An in-memory cache in front of DynamoDB	Microsecond reads; same API, so few code changes

Single-table example · one user's item collection

PK            SK                  data
USER#42       PROFILE             name=Asha, plan=pro
USER#42       ORDER#2026-10-01    total=499
USER#42       ORDER#2026-10-20    total=1299
USER#42       ADDRESS#home        city=Pune
// Query PK = USER#42 AND begins_with(SK, "ORDER#") → all orders, sorted by date

In everyday words

Single-table design is one folder per customer holding their profile, orders and addresses, so the clerk grabs one folder instead of visiting four cabinets.

Actually

DynamoDB docs: single-table design works "because DynamoDB stores items with the same partition key (known as an item collection) on the same partition(s)". A single query for two items under 4 KB costs 0.5 RCU eventually consistent, versus 1 RCU for two separate queries. Streams: "Each stream record appears exactly once", in "the same sequence as the actual modifications", 24-hour lifetime. TTL "deletes expired items within a few days of their expiration time, without consuming write throughput". Transactions: no more than 100 unique items and 4 MB. DAX goes "from single-digit milliseconds to microseconds" (the docs do not use the popular "10x" claim). Sources: data modeling foundations, Streams, TTL, constraints, DAX.

Streams + Lambda turn every write into an event; TTL cleans up sessions for free. Never rely on TTL for exact-second expiry.

Source: DynamoDB Developer Guide pages linked above

Caches

06ElastiCache and MemoryDB

A cache in front of your database, or an in-memory database of record core

ElastiCache runs in-memory caches for you. It supports three engines: Valkey (the open-source fork of Redis), Redis OSS, and Memcached. MemoryDB is different: it is a durable, Redis-compatible database, not just a cache.

Question	ElastiCache Valkey / Redis OSS	ElastiCache Memcached	MemoryDB
Data types	Rich: lists, sets, sorted sets, hashes, streams	Simple strings	Same as Valkey / Redis
Replication / high availability	Yes	No	Yes, Multi-AZ
Multi-threaded (per AWS comparison)	See page 05 for engine internals	Yes	Redis-compatible
Durability	Cache: data can be lost (Valkey 9.0 adds an optional Multi-AZ log)	None	Every write stored in a Multi-AZ transaction log
Latency	Sub-millisecond reads	Sub-millisecond reads	Microsecond reads, single-digit ms writes
Use as	Cache, sessions, leaderboards, rate limits	Plain, large, simple cache	Primary database for fast data

In everyday words

ElastiCache is a sticky note on your monitor: fast, but you can lose it. MemoryDB is a sticky note that is also photocopied into a safe every time you write on it.

Actually

ElastiCache docs: it "supports the Valkey, Memcached, and Redis OSS cache engines"; in the engine comparison Memcached is "Multi-threaded: Yes" and "High availability (replication): No". MemoryDB docs: "microsecond read and single-digit millisecond write latency" with a "Multi-AZ transactional log"; "primary nodes are strongly consistent", replica nodes "eventually consistent". Sources: ElastiCache engine comparison, What is MemoryDB, MemoryDB consistency.

Cache that can be rebuilt from the database → ElastiCache. Data that must survive and still be in memory → MemoryDB.

Source: ElastiCache: choosing an engine · MemoryDB · Course page 05: Redis

Messaging

07SQS and SNS: queues and fan-out

Standard vs FIFO, visibility timeout, long polling, dead-letter queues, SNS fan-out interview favourite

SQS is a queue: a producer puts a message in, one consumer takes it out and deletes it when done. It lets a slow worker absorb a fast producer.

Question	Standard queue	FIFO queue
Throughput	"Nearly unlimited"	300 API calls/s per action per partition; 3,000 msg/s with batches of 10; high-throughput mode up to 70,000 calls/s in the biggest Regions
Delivery	At least once (duplicates possible)	Exactly-once processing (5-minute dedup window)
Order	Best effort	Strict, per message group ID

Setting (checked 2026-10-25)	Value	Why it matters
Max message size	1 MiB (was 256 KiB)	Bigger: put it in S3 and send a pointer
Retention	Default 4 days, 60 s to 14 days	Unread messages vanish after this
Visibility timeout	Default 30 s, max 12 h	Must be longer than your processing time
Long polling wait	Up to 20 s	Fewer empty responses, lower cost
Delay	0 to 15 min	Hold messages back before delivery
Batch	Up to 10 messages per call	10× fewer API calls

The visibility timeout is the key idea. When a consumer receives a message, SQS hides it. If the consumer deletes it in time, it is gone. If the consumer crashes, the timer runs out and the message reappears for someone else. After maxReceiveCount failed tries, SQS moves it to a dead-letter queue (DLQ) so one bad message does not loop forever.

SNS fan-out

SNS is publish/subscribe: one message to a topic is copied to every subscriber. Subscribers can be SQS queues, Lambda, HTTP(S), email, SMS, mobile push or Firehose. The classic pattern: SNS in front of several SQS queues, so each team gets its own durable copy.

One publish, three independent copies. A slow billing worker never delays email.

In everyday words

SQS is a ticket rail in a kitchen: one cook takes a ticket; if the cook faints, the ticket goes back on the rail. SNS is the restaurant's group chat: every member gets the same message.

Actually

SQS docs: max message size "1,048,576 bytes (1 MiB)"; retention default 4 days, "maximum is 1,209,600 seconds (14 days)"; visibility timeout default 30 s, "maximum is 12 hours"; FIFO: "Each partition in a FIFO queue is limited to 300 transactions per second, per API action", 3,000 messages/s with batching; high-throughput mode "Up to 70,000 transactions per second" in N. Virginia, Oregon and Ireland. Standard queues: "at-least-once" delivery with "best-effort" ordering. FIFO dedup interval: 5 minutes. maxReceiveCount is "the number of times a consumer can receive a message… before it is moved to a dead-letter queue". Sources: SQS message quotas, standard queues, FIFO exactly-once, DLQs, What is SNS.

Standard SQS can deliver twice, so make consumers idempotent (for example, store processed message IDs).

Source: SQS queue quotas · SNS FIFO topics · SNS message filtering

08EventBridge, Kinesis and MSK

Event routing vs ordered, replayable streams core

EventBridge is an event router. Services put events on an event bus; rules match events by content and send them to targets (up to 5 targets per rule on the classic bus). EventBridge Scheduler runs one-off or cron-style jobs that call a target at a time you set.

Kinesis Data Streams is an ordered log split into shards. Records with the same partition key go to the same shard, in order. Many readers can read the same data, and they can re-read it until it expires. Amazon MSK is managed Apache Kafka (see page 09): provisioned clusters with Standard or Express brokers, or MSK Serverless.

Kinesis limit (checked 2026-10-25)	Value
Write per shard (provisioned)	1 MB/s or 1,000 records/s
Read per shard	2 MB/s, up to 5 `GetRecords` calls/s (shared by all classic readers)
Enhanced fan-out	2 MB/s per shard per registered consumer; up to 20 consumers (50 in On-demand Advantage)
Retention	24 h default, up to 365 days
Max record size	10 MiB (was 1 MB); large records use burst capacity
On-demand mode	Starts at 4 MB/s write; scales up to 10 GB/s in the largest Regions

SQS vs SNS vs EventBridge vs Kinesis vs MSK

Question	SQS	SNS	EventBridge	Kinesis Data Streams	MSK (Kafka)
Model	Queue: one consumer per message	Pub/sub push to subscribers	Event bus with content rules	Ordered log in shards	Ordered log in partitions
Message kept after read?	No, deleted	No, pushed then gone	No	Yes, until retention ends	Yes, until retention ends
Replay?	No	No	From an archive (not checked here)	Yes	Yes
Ordering	FIFO queues only	FIFO topics only	Not checked here	Per shard	Per partition
Max message	1 MiB	Not checked here	1 MB per request	10 MiB	Kafka config (not checked here)
Scaling unit	None to manage	None to manage	None to manage	Shards, or on-demand	Brokers, or Serverless
Best for	Work queues, buffering, retries	Fan-out, notifications	Routing AWS and SaaS events, schedules	Clickstreams, logs, real-time analytics	Teams already on Kafka, its ecosystem

In everyday words

EventBridge is a post office that reads each letter's label and forwards it. Kinesis and Kafka are a CCTV recording: many people can watch it, rewind it, and watch again, until the tape is reused.

Actually

Kinesis docs: "Each shard can support up to 1 MB/sec or 1,000 records/sec write throughput or up to 2 MB/sec or 2,000 records/sec read throughput"; "the data payload of a record before base64-encoding is up to 10 MiB"; retention "24 hours by default, up to 8760 hours (365 days)". EventBridge: the PutEvents request "must be less than 1 MB (1,048,576 bytes)" and one event can use the full 1 MB; "Targets per rule: 5". EventBridge now has two bus types (classic with rules, and a newer one with subscribers); the 5-target limit is a classic quota. Rows marked "not checked" were not verified for this page. Sources: Kinesis quotas, Kinesis retention, enhanced fan-out, EventBridge PutEvents, EventBridge quotas, What is MSK.

Need replay or several independent readers of the same ordered data? A stream (Kinesis or MSK). Otherwise a queue or bus is simpler.

Source: pages linked above · Course page 09: Kafka

Serverless and operations

09Step Functions and API Gateway

Workflows with retries, and a managed front door for APIs core

Step Functions runs a workflow (a state machine): call service A, wait, branch, retry B on failure, run steps in parallel. You draw the flow; it keeps the state and the history.

Question	Standard workflow	Express workflow
Max duration	Up to 1 year	Up to 5 minutes
Execution guarantee	Exactly once	At least once (async), at most once (sync)
Good for	Long business processes, human approval steps	High-volume short event processing

API Gateway puts a managed HTTP front door in front of Lambda, HTTP backends or AWS services. It handles auth, throttling and stages.

Question	REST API	HTTP API
Price and features	More features, higher price	Fewer features, lower price
Only here	API keys, usage plans, per-client throttling, caching, request validation, AWS WAF, private endpoints, edge-optimized endpoints	JWT authorizers built in, automatic deployments
Integration timeout	50 ms – 29 s; can be raised for Regional and private APIs (may lower your throttle quota)	Max 30 s
Payload	10 MB	10 MB

In everyday words

Step Functions is a recipe card that remembers which step you are on, even if you leave the kitchen for a week. API Gateway is the receptionist who checks ID and turns people away when the waiting room is full.

Actually

Step Functions docs: Standard runs up to one year with exactly-once execution; Express runs up to five minutes, at-least-once when async and at-most-once when sync. API Gateway REST quotas: integration timeout "50 milliseconds - 29 seconds"; "You can raise the integration timeout to greater than 29 seconds, but this might require a reduction in your Region-level throttle quota" (Regional and private APIs only; edge-optimized cannot). HTTP API: "Maximum integration timeout 30 seconds". Account throttle: 10,000 requests per second with a burst bucket of 5,000 (some newer Regions: 2,500 and 1,250). Docs: "Choose REST APIs if you need features such as API keys, per-client throttling, request validation, AWS WAF integration, or private API endpoints." Sources: workflow types, REST API quotas, HTTP API quotas, account quotas, REST vs HTTP.

Anything longer than ~29 s should not sit behind a synchronous API call: return 202, do the work async, let the client poll or get a callback.

Source: pages linked above

10Serverless patterns

A sync API path and an async event path design

Top: the user waits for the answer. Bottom: nobody waits; each step hands off to the next.

Path	Who waits	Limits to respect	Failure handling
API Gateway → Lambda → DynamoDB	The user	29–30 s API timeout; Lambda 6 MB sync payload; 1,000 default concurrency vs 10,000 rps API throttle	Return an error; client retries with an idempotency key
S3 event → Lambda → SQS	Nobody	Lambda 15 min; SQS 1 MiB message	Async retries, then a DLQ or failure destination

In everyday words

The top path is a phone call: you hold until you get the answer. The bottom path is leaving a parcel at a depot: each van takes it one stage further.

Actually

The Lambda docs warn about this exact mismatch: "API Gateway has a default throttle limit of 10,000 requests per second, whereas Lambda has a default concurrency limit of 1,000", so more requests can arrive than Lambda can handle; raise the Lambda quota or throttle the API. Lambda async payload is 1 MB. Sources: Lambda quotas, page 12, section 05.

Match the limits end to end: API throttle, Lambda concurrency and DynamoDB capacity must agree, or the weakest one throttles.

Source: Lambda quotas (other services section)

11CloudWatch, X-Ray, and cost awareness

See what is happening, and avoid surprise bills core

Tool	What it gives you	Key fact (checked 2026-10-25)
CloudWatch metrics	Numbers over time (CPU, latency, queue depth)	Standard resolution 1 minute; high resolution 1 second
CloudWatch alarms	Watch a metric, act when it crosses a line	States: `OK`, `ALARM`, `INSUFFICIENT_DATA`
CloudWatch Logs	Log storage and search	Kept forever by default; set a retention per log group
X-Ray	Distributed tracing: one request across many services, shown as a service map	X-Ray SDKs and daemon in maintenance mode since 25 Feb 2026; AWS recommends OpenTelemetry

Cost tips (only verified claims)

Cost trap	Fact	Fix
NAT gateway data	us-east-1: $0.045 per hour plus $0.045 per GB processed (pricing page)	Gateway endpoints for S3 and DynamoDB (free); cache big downloads
Cross-AZ traffic	About $0.01 per GB in each direction (AWS architecture blog; the pricing table did not load for this check)	Keep chatty services and their caches in the same AZ where safe
Logs kept forever	Default retention is indefinite	Set retention (for example 30 days) on every log group
Provisioned concurrency	Billed even when idle	Use only where cold starts hurt users
DynamoDB on-demand	Price cut 50% on 1 Nov 2024	Re-check old "provisioned is always cheaper" advice

In everyday words

Metrics are the car's dashboard, logs are the trip diary, and traces are a GPS track of one journey. The NAT gateway is a toll road: cheap per trip, huge if every truck uses it.

Actually

CloudWatch docs: "Standard resolution… one-minute granularity", "High resolution… granularity of one second"; "By default, log data is stored in CloudWatch Logs indefinitely". X-Ray docs list the SDKs and daemon as entering "Maintenance mode" on "February 25th, 2026". VPC pricing page: NAT gateway $0.045 per hour and $0.045 per GB in us-east-1; a regional NAT gateway is billed per AZ it spans. The cross-AZ figure comes from an AWS blog, not a docs page, so treat it as approximate. Sources: CloudWatch concepts, alarm evaluation, log groups, X-Ray SDK timeline, VPC pricing, data transfer costs blog.

Alarm on what users feel (errors, p99 latency, queue age), not only CPU. And set log retention on day one.

Source: pages linked above · Course page 14: observability

Practice

—When to use what

Situation → pick → why decision table

Situation	Pick	Why
Joins, reports, strict schema, moderate scale	RDS PostgreSQL or MySQL	SQL and transactions; simplest
SQL with many readers or fast failover	Aurora	Up to 15 replicas on shared storage
SQL with unpredictable spikes	Aurora Serverless v2	Scales in 0.5 ACU steps; can pause at 0
Key lookups at huge scale, known queries	DynamoDB	Key lookups scale by adding partitions; no servers
Same item read thousands of times a second	DAX or ElastiCache	Takes load off one hot partition
Session store, leaderboard, rate limiter	ElastiCache (Valkey/Redis OSS)	Rich data types, sub-ms
In-memory but must not lose data	MemoryDB	Multi-AZ transaction log
Background jobs, smooth out spikes	SQS standard + DLQ	Buffers, retries, near-unlimited throughput
Strict order per customer	SQS FIFO with message group = customer ID	Order per group, exactly-once processing
One event, many independent consumers	SNS → SQS fan-out, or EventBridge	Each consumer gets its own copy
Route events by content from AWS or SaaS	EventBridge	Rules match on event fields
Run a job every night at 2 a.m.	EventBridge Scheduler	Managed cron with targets
Clickstream, replay, several readers	Kinesis Data Streams	Ordered per shard, kept up to 365 days
Team already runs Kafka	MSK	Same APIs and tools
Multi-step process with retries and waits	Step Functions Standard	Durable state up to a year
Public API with keys, quotas, WAF	API Gateway REST API	Usage plans and WAF only here
Simple, cheap Lambda-backed API	API Gateway HTTP API	Lower price, JWT auth built in

—Common traps

Mistakes that show up in interviews and in production traps

Trap

"Multi-AZ will scale my reads"

Wrong because: the standby cannot serve reads.

Fix: add read replicas (or Aurora readers).

Trap

Reading your write from a replica

If missed: async lag shows stale data right after a save.

Fix: read-your-writes from the primary.

Trap

Low-cardinality partition key

If missed: keys like status create hot partitions.

Fix: high-cardinality keys, or write sharding.

Trap

Scan instead of Query

If missed: a scan reads (and bills) the whole table.

Fix: design keys or a GSI for each query.

Trap

Strong reads on a GSI

If missed: not supported; GSIs are eventually consistent.

Fix: read the base table, or use an LSI planned at creation.

Trap

Visibility timeout shorter than work

If missed: a second worker grabs the same message.

Fix: timeout above max processing time; extend it while working.

Trap

No dead-letter queue

If missed: one poison message retries forever.

Fix: DLQ with maxReceiveCount and an alarm on its depth.

Trap

Using TTL as an exact timer

If missed: items linger up to a few days.

Fix: filter expired items in reads; use Scheduler for exact times.

Trap

Old limits from memory

If missed: quoting 256 KB SQS or 1 MB Kinesis records.

Fix: now 1 MiB and 10 MiB; check the quotas page.

Trap

Long work behind a sync API

If missed: 29–30 s timeout returns 504 to users.

Fix: accept, queue, return 202 and a job ID.

—Interview questions

20 questions, easy to design-level. Try first, then open the answer practice

RDS Multi-AZ vs read replica: what is each for? easy

Show answer

Multi-AZ is for availability. RDS keeps a synchronous standby in another AZ; you cannot read from it; if the primary or its AZ fails, RDS fails over automatically, typically in 60–120 seconds, and the endpoint name stays the same. A read replica is for read scaling: changes are copied asynchronously, so it may lag, but you can read from it; up to 15 per source. Promoting a replica is manual and may lose the last un-copied writes. They combine well: Multi-AZ for safety, replicas for reports and read-heavy pages. (A newer Multi-AZ DB cluster has two readable standbys, semisynchronous.)

How does point-in-time restore work in RDS? easy

Show answer

Automated backups take a daily snapshot and keep transaction logs, which RDS uploads every five minutes. To restore to a moment, RDS starts from the snapshot before it and replays logs up to that second. Retention is 0–35 days (default 7 in the console, 1 via API). Restore creates a new DB instance "without modifying the source", so the app must be pointed at the new one. Use it for "someone ran DELETE without WHERE at 14:03": restore to 14:02. It does not replace Multi-AZ, because a restore takes minutes to hours.

Why is Aurora storage more durable than a single RDS volume? medium

Show answer

Aurora writes every change synchronously to six storage nodes spread over three AZs, two per AZ. Per the Aurora FAQ, it can lose two copies and still accept writes, or three and still serve reads. So a whole AZ plus one more node can fail without data loss. Readers share the same volume instead of keeping their own copies, so adding a replica does not copy the data again, and replica lag is usually well under 100 ms. Up to 15 replicas. Trade-off: more moving parts and usually more cost than a single small RDS instance (pricing not checked here).

Partition key vs sort key in DynamoDB? easy

Show answer

The partition key is hashed to decide which partition stores the item; you look items up by its exact value. The sort key orders items that share a partition key, and lets you query ranges and prefixes, like begins_with(SK, "ORDER#2026-10"). Together they form the primary key and must be unique. Choose a partition key with many distinct values and even traffic (user ID, not country). Limits: partition key value 2,048 bytes, sort key 1,024 bytes, whole item 400 KB.

GSI vs LSI? medium

Show answer

A GSI can use a completely different partition and sort key, can be added any time, has its own capacity, and supports only eventually consistent reads. An LSI keeps the table's partition key with a different sort key, must be created with the table, can be read strongly consistent, but limits each partition key's item collection to 10 GB. Defaults: 20 GSIs, 5 LSIs per table. In practice most designs use GSIs; LSIs only when you need strong reads on an alternate sort order and know the size stays small.

Compute RCUs: 200 strongly consistent reads per second of 9 KB items. And eventually consistent? medium

Show answer

Round 9 KB up to the next 4 KB: 12 KB = 3 units. Strong: 200 × 3 = 600 RCU. Eventually consistent costs half: 300 RCU. Transactional reads cost double strong: 1,200 RCU. For writes the step is 1 KB: a 9 KB write is 9 WCU each. Then check partition limits: one partition serves at most 3,000 RCU and 1,000 WCU, so 600 RCU is fine if spread over keys, but if all 200 reads hit one key, consider DAX. Follow-up: on-demand mode removes this planning but you still pay per request unit with the same rounding.

What is a hot partition and how do you fix it? medium

Show answer

When one partition key gets a large share of traffic, its partition hits the per-partition ceiling (3,000 RCU / 1,000 WCU) and throttles, even though the table total has room. Adaptive capacity raises throughput for busy partitions and can isolate hot items, but one item still cannot exceed the partition limit. Fixes: pick a high-cardinality key; for write-hot keys use write sharding (append a random suffix 0–9, read all 10 and merge); for read-hot keys put DAX or ElastiCache in front; precompute aggregates instead of counting on one item. Example: a global "likes" counter becomes 10 sharded counters summed on read.

Eventually vs strongly consistent reads in DynamoDB: when do you need strong? easy

Show answer

Eventually consistent is the default and costs half; it may miss a write made just before. Strongly consistent always returns the latest committed write, costs double, and is not available on GSIs or Streams. Use strong reads when the user must see their own change immediately (a balance after a payment, a "save" followed by a reload) or for check-then-act logic. Better still for check-then-act: use conditional writes or transactions, which enforce the rule at write time instead of trusting a read.

What is single-table design, and when would you avoid it? hard

Show answer

You store several entity types in one table, grouped under the same partition key, with the sort key naming the type: USER#42 / PROFILE, USER#42 / ORDER#…. Because an item collection lives together, one Query fetches a user and their orders, cheaper and faster than several calls (AWS's example: one query for two small items costs 0.5 RCU vs 1 RCU for two). Avoid it when entities need different backups, encryption keys or table classes, when access patterns are unknown or ad hoc, when the team uses GraphQL resolvers per entity, or when a stream consumer should see only one entity type.

ElastiCache Valkey/Redis vs Memcached vs MemoryDB? medium

Show answer

Valkey or Redis OSS on ElastiCache: rich data types (sorted sets for leaderboards, hashes, streams), replication and failover; it is a cache, so you can lose recent writes. Memcached: simple strings, multi-threaded, no replication, so a node loss empties that part of the cache; good for a big plain cache. MemoryDB: Redis-compatible but durable, writing every change to a Multi-AZ transaction log; microsecond reads, single-digit millisecond writes; strongly consistent on the primary. Rule: if the data can be rebuilt from the database, a cache; if it is the only copy, MemoryDB.

Explain the SQS visibility timeout. What goes wrong if it is too short? medium

Show answer

When a consumer receives a message, SQS hides it for the visibility timeout (default 30 s, max 12 h). If the consumer deletes it in time, done. If not (crash, slow), it reappears for another consumer. Too short: a slow but healthy worker is still processing when the message reappears, so a second worker does the same job; duplicate charges or emails. Too long: after a real crash, the message waits a long time before retry. Fix: set it above your p99 processing time, and extend it with ChangeMessageVisibility for long jobs. And make handlers idempotent, because standard queues are at-least-once anyway.

SQS standard vs FIFO? easy

Show answer

Standard: nearly unlimited throughput, at-least-once delivery (duplicates possible), best-effort ordering. FIFO: strict order within a message group ID, exactly-once processing with a 5-minute deduplication window, but limited throughput: 300 API calls per second per action per partition, 3,000 messages per second with batches of 10, and high-throughput mode up to 70,000 calls/s in the largest Regions. Use FIFO when order matters per entity (all events for one bank account), using the account ID as the group ID so different accounts still run in parallel.

SQS vs SNS vs EventBridge vs Kinesis: how do you choose? hard

Show answer

Ask three questions. One receiver or many? One worker pool → SQS; many independent receivers → SNS (simple fan-out) or EventBridge (routing by event content, AWS and SaaS sources, schedules). Need to replay or keep data after reading? → Kinesis or MSK, which keep records (Kinesis 24 h by default, up to 365 days) and let each reader track its own position. Need strict order? SQS FIFO per group, Kinesis per shard, Kafka per partition. Common combo: SNS or EventBridge → one SQS queue per consumer, giving fan-out plus buffering and DLQs. Throughput: Kinesis is planned in shards (1 MB/s or 1,000 records/s write each); SQS and SNS need no capacity planning.

How many Kinesis shards for 5 MB/s of writes from 3,000 events per second, read by 4 apps? hard

Show answer

Writes: each shard takes 1 MB/s or 1,000 records/s. 5 MB/s needs 5 shards; 3,000 records/s needs 3; take the larger: 5 shards, plus headroom (say 6–7) for spikes and uneven keys. Reads: classic readers share 2 MB/s and 5 GetRecords calls per second per shard. Four apps each reading 5 MB/s need 20 MB/s total, far over 6 shards × 2 MB/s = 12 MB/s. So use enhanced fan-out, which gives each registered consumer its own 2 MB/s per shard. Or use on-demand mode and let Kinesis scale. Check the partition key spreads evenly, or one shard runs hot.

Step Functions Standard vs Express? medium

Show answer

Standard: runs up to one year, exactly-once execution, full history kept; good for order processing, approvals, anything with waits or long steps. Express: up to five minutes, at-least-once when started async and at-most-once when sync, built for high-volume short event processing such as transforming IoT or stream records. Because Express can run a step twice, its tasks must be idempotent. Both give retries with backoff and catch blocks, which removes a lot of hand-written retry code.

API Gateway REST vs HTTP API, and the timeout problem? medium

Show answer

HTTP APIs are cheaper with fewer features and built-in JWT authorizers. REST APIs add API keys, usage plans, per-client throttling, caching, request validation, AWS WAF and private endpoints. Timeouts: REST integration timeout is 50 ms to 29 s by default; for Regional and private REST APIs you can now raise it above 29 s, possibly with a lower throttle quota. HTTP APIs max out at 30 s. Either way, long work should not be synchronous: accept the request, put a job on SQS or start a Step Functions run, return 202 with a job ID, and let the client poll or receive a webhook.

Design a serverless image-thumbnail pipeline. medium

Show answer

Client gets a pre-signed PUT URL from an API (API Gateway → Lambda) and uploads to uploads/ in S3. The S3 event triggers a Lambda that makes thumbnails and writes them to thumbs/, then writes metadata to DynamoDB. For load spikes put SQS between S3 and the worker Lambda, so bursts queue instead of throttling, with a DLQ for corrupt images. Make the worker idempotent (same input key → same output key), since events can repeat. Serve images through CloudFront. Watch: Lambda 15-minute cap and memory up to 10,240 MB for big images; never write output into the same prefix that triggers the function, or it loops.

What breaks first when traffic jumps 10× on API Gateway → Lambda → DynamoDB? hard

Show answer

Check each limit. API Gateway: 10,000 rps account default with a 5,000 burst, so it may throttle the excess. Lambda: default 1,000 concurrency per Region, shared by all functions; at 10,000 rps with 200 ms per call you need 2,000, so Lambda throttles first; AWS docs call out this exact mismatch. DynamoDB: on-demand instantly handles up to 2× the previous peak, so a sudden 10× can throttle until it adapts; provisioned may throttle unless auto scaling or headroom is set; and a hot key caps at 1,000 WCU. Fixes: raise Lambda quotas ahead, reserved concurrency for critical functions, pre-warm DynamoDB, client retries with backoff and jitter.

How would you make a consumer idempotent? medium

Show answer

Give each message a unique ID (from the producer, or an idempotency key from the client). Before doing the side effect, do a conditional write to a DynamoDB "processed" table: put the ID only if it does not exist (attribute_not_exists). If the put fails, the message was handled; skip it. Do the side effect and mark it done in one transaction where possible, or make the side effect itself keyed (payment provider idempotency key). Add a TTL to the processed table so it cleans itself after the retry window. This makes at-least-once queues (SQS standard, Express workflows) safe.

Your AWS bill doubled after launching a feature. Where do you look? hard

Show answer

Group Cost Explorer by service and usage type to find the line that grew. Usual suspects: (1) NAT gateway per-GB processing ($0.045/GB in us-east-1) from new traffic to S3 or external APIs; add gateway endpoints for S3 and DynamoDB. (2) Cross-AZ data between chatty services. (3) CloudWatch Logs with no retention, or debug logging left on. (4) DynamoDB scans or a new GSI doubling writes. (5) Provisioned concurrency or over-sized Lambda memory. (6) Lambda retries in a loop, such as an S3 trigger writing to its own prefix. Fix the top item, set a budget alarm, and check again after a week.

—Cheat sheet

Numbers to memorise, all checked 2026-10-25 on the linked pages memorise

Fact	Value	Source
RDS Multi-AZ failover	typically 60–120 s	Failover
RDS read replicas	up to 15 per source	RDS quotas
RDS backup retention	0–35 days	Retention
Aurora storage	6 copies, 3 AZs	Aurora HA
Aurora replicas	up to 15, lag < 100 ms usually	Replication
Aurora Serverless v2	0–256 ACU (PostgreSQL up to 384)	Serverless v2
DynamoDB item	max 400 KB	Constraints
RCU / WCU	4 KB strong read / 1 KB write	Constraints
Partition ceiling	3,000 RCU, 1,000 WCU	Key design
Indexes	20 GSI (default), 5 LSI	Quotas
Transactions	100 items, 4 MB	Constraints
Streams retention	24 h	Streams
SQS message	1 MiB	SQS quotas
SQS retention	default 4 days, max 14 days	SQS quotas
SQS visibility timeout	default 30 s, max 12 h	SQS quotas
SQS long poll	max 20 s	Queue quotas
SQS FIFO	300 calls/s, 3,000 msg/s batched	SQS quotas
EventBridge event	1 MB per request; 5 targets per rule	PutEvents
Kinesis shard write	1 MB/s or 1,000 records/s	Kinesis quotas
Kinesis shard read	2 MB/s, 5 GetRecords/s	Kinesis quotas
Kinesis retention	24 h to 365 days	Retention
Step Functions	Standard 1 year, Express 5 min	Workflow types
API Gateway REST timeout	29 s default max (raisable, Regional/private)	REST quotas
API Gateway throttle	10,000 rps, burst 5,000	Account quotas
CloudWatch resolution	1 min standard, 1 s high	Concepts
NAT gateway (us-east-1)	$0.045/h + $0.045/GB	VPC pricing

—Sources

All pages read on 2026-10-25 sources

What	Where
RDS	What is RDS, Multi-AZ instance, Multi-AZ cluster, failover, read replicas, quotas, backup retention, PITR
Aurora	high availability, FAQ, replication, Serverless v2, quotas
DynamoDB	constraints, quotas, LSI, read consistency, key design, adaptive capacity, on-demand, data modeling, Streams, TTL, DAX, Nov 2024 price cut
ElastiCache, MemoryDB	engine comparison, MemoryDB, MemoryDB consistency
SQS, SNS	message quotas, queue quotas, standard, FIFO, DLQ, SNS, SNS FIFO, SNS filtering
EventBridge, Kinesis, MSK	PutEvents, EventBridge quotas, Kinesis quotas, Kinesis retention, enhanced fan-out, MSK
Step Functions, API Gateway	workflow types, REST quotas, HTTP API quotas, account quotas, REST vs HTTP
Lambda limits referenced	Lambda quotas
CloudWatch, X-Ray	concepts, alarms, log groups, X-Ray concepts, X-Ray SDK timeline
Cost	VPC pricing, data transfer costs (AWS blog), gateway endpoints