← Design High-Performing Architectures

▶ Play from here · 120 min

Starts this lesson and continues through 11 more to the end of certification prep.

Database performance — engines, replicas, proxies and caches

Why this lesson matters

Task statement 3.3 — "Determine high-performing database solutions" — has eight knowledge items and five skills, the most of any task in the domain. The item that organises all the others is "Data access patterns (for example, read-intensive compared with write-intensive)".

Every database performance fix helps one side of that split and does nothing for the other.

   READ-heavy                              WRITE-heavy
   ──────────                              ───────────
   read replicas / Aurora Replicas         bigger writer instance, Provisioned IOPS
   ElastiCache (lazy loading)              DynamoDB with enough WCUs / on-demand
   DAX (DynamoDB, eventually consistent)   shard / partition the keyspace
   CloudFront for cacheable responses      queue writes (SAA2 lesson 1)

A read replica does nothing for a write bottleneck. DAX is, in AWS's words, not ideal for "Applications that are write-intensive." Half the wrong answers in this area are right fixes for the other column.

Choosing the database type

The skill is "Determining an appropriate database type (for example, Amazon Aurora, Amazon DynamoDB)", and the knowledge item is "serverless, relational compared with non-relational, in-memory".

From What is Amazon DynamoDB?: "a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale" — and ⚠️ "Unlike relational databases, DynamoDB doesn't support a JOIN operator. We recommend that you denormalize your data model." A requirement for ad-hoc joins across entities rules DynamoDB out.

⚠️ The in-scope list also names Amazon Redshift, DocumentDB, Keyspaces and Neptune. I did not fetch their documentation for this lesson, so it makes no claim about them. Read each service's "What is" page before relying on specifics.

Relational: RDS and Aurora

Aurora

From What is Amazon Aurora?, verified 2026-09-25:

"a fully managed relational database engine that's compatible with MySQL and PostgreSQL. … Aurora delivers up to 6x the throughput of stock PostgreSQL and up to 6x the throughput of stock MySQL on similar hardware."

⚠️ Older prep material quotes different multiples. The page says 6x for both, as of 2026-09-25.

*"The underlying storage grows automatically as needed. An Aurora cluster volume can grow to a maximum size of 256 tebibytes (TiB)."*

Aurora Replicas

From Replication with Amazon Aurora:

• "An Aurora DB cluster can contain up to 15 Aurora Replicas."
• The writer and replicas share one cluster volume, so replica lag "is usually much less than 100 milliseconds".
• You read from them "by connecting to the reader endpoint of the cluster", which spreads read-only connections across the replicas.
• They double as failover targets: "if the primary instance fails, an Aurora Replica is promoted". And: "If your Aurora DB cluster doesn't include any Aurora Replicas, then your DB cluster isn't available while your DB instance is recovering from the failure."

⚠️ Aurora Replicas do both jobs; RDS does not. The RDS read-replica page says it directly: "Unlike a read replica, a standby replica can't serve read traffic." In Aurora, the same replicas scale reads and are the failover targets. That's a real design difference, and the exam tests it.

Cross-Region is engine-dependent, verbatim: Aurora MySQL can use an Aurora global database or binlog replicas ("up to five read replicas created this way, each in a different Region"). Aurora PostgreSQL "doesn't support cross-Region Aurora Replicas" — use a global database, "up to 10 read-only secondary DB clusters in different Regions."

Aurora Serverless

From Using Aurora serverless: "an on-demand, autoscaling configuration", "especially valuable for multitenant databases, distributed databases, development and test systems, and other environments with highly variable and unpredictable workloads." It scales in half-ACU steps — "It can add 0.5, 1, 1.5, 2, or additional half-ACUs" — and "Scaling can happen while SQL statements are running and transactions are open." Reader instances can also be serverless and "scale independently of the writer".

⚠️ The page I fetched does not state the ACU minimum and maximum or the memory per ACU. It links to "Scaling to Zero ACUs with automatic pause and resume", which implies a zero minimum is possible, but read docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html before quoting the range.

RDS read replicas

From Working with DB instance read replicas:

"you can elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads."

• Replication is asynchronous: "Amazon RDS copies them asynchronously to the read replica."
• AWS's use cases: read scaling, serving reads during source I/O suspension, "Business reporting or data warehousing scenarios", and DR by promotion.
• ⚠️ "You must manually create read replicas. RDS doesn't support autoscaling of read replicas." (Aurora Replicas can be scaled by AWS Auto Scaling — lesson 2.)
• No data-transfer charge for replication "within the same AWS Region".
• Cross-Region replicas are supported.
• A replica's storage type can differ from its source's.

⚠️ The pages I fetched do not state the maximum number of read replicas per source instance for each engine. Read the per-engine replica pages linked from USER_ReadRepl.html before relying on a number.

MySQL vs PostgreSQL — what the replica page actually distinguishes

The skill "Determining an appropriate database engine (for example, MySQL compared with PostgreSQL)" is thinly documented as a comparison. What I can state from Differences between read replicas for DB engines:

Plus the Aurora cross-Region difference above: Aurora MySQL has binlog cross-Region replicas; Aurora PostgreSQL uses global databases only.

⚠️ Beyond replication, no page I fetched compares the two engines' features. In practice the exam's engine-choice questions usually turn on compatibility with an existing application — keep the same engine to avoid a migration — which is the next section.

Heterogeneous vs homogeneous migrations

The knowledge item is "Database engines with appropriate use cases (for example, heterogeneous migrations, homogeneous migrations)". From What is AWS DMS?:

• Heterogeneous (engine changes): "To migrate to a different database engine, you can use DMS Schema Conversion. This service automatically assesses and converts your source schemas to a new target engine. Alternatively, you can download the AWS Schema Conversion Tool (AWS SCT)." Then DMS moves the data.
• Homogeneous (same engine): "if you want to migrate away from old infrastructure but continue to use the same database engine, AWS DMS also supports that process."
• Ongoing sync: "You can perform one-time migrations or replicate ongoing changes to keep sources and targets in sync."

→ Engine changes ⇒ schema conversion first (DMS Schema Conversion or SCT), then DMS. Same engine ⇒ no schema conversion. Minimal downtime ⇒ DMS with ongoing replication, cut over when in sync.

Capacity planning — instance, storage, capacity units

The knowledge item is "Database capacity planning (for example, capacity units, instance types, Provisioned IOPS)".

RDS storage and Provisioned IOPS

From Amazon RDS DB instance storage:

• "For production OLTP use cases, we recommend that you use Multi-AZ deployments for enhanced fault tolerance with Provisioned IOPS storage for fast and predictable performance."
• "you are charged for the provisioned resources whether or not you use them."
• Magnetic storage is deprecated: "You can no longer create new DB instances using magnetic storage."

⚠️ The instance caps the storage. "if the maximum IOPS for a particular DB instance class is 40,000, and you attach four 64,000 IOPS EBS volumes, the maximum IOPS is 40,000 rather than 256,000." And AWS says to "determine the maximum bandwidth, throughput and IOPS for the instance class before setting a Provisioned IOPS". The metric to watch: DiskQueueDepth — "I/O requests in the queue waiting to be serviced". If TotalIOPS "regularly approach the Provisioned IOPS value", raise it.

DynamoDB capacity units

From DynamoDB provisioned capacity mode:

"For an item up to 4 KB, one read capacity unit (RCU) represents one strongly consistent read operation per second, or two eventually consistent read operations per second."

"A write capacity unit (WCU) represents one write per second for an item up to 1 KB."

Round item sizes up. AWS's worked examples: 80 strongly consistent reads/s of 3 KB items → 3 ÷ 4 = 0.75 → 1 RCU each → 80 RCU. 100 writes/s of 512-byte items → 100 WCU. Eventually consistent reads halve the RCU requirement — and "Read operations in DynamoDB are eventually consistent, by default."

On-demand vs provisioned. On-demand "offers pay-as-you-go pricing", "instantly scales up or down" and "scales down to zero". Provisioned charges "based on the hourly read and write capacity you have provisioned, not how much of that provisioned capacity you actually consumed", and can use auto scaling — AWS recommends "setting target utilization to 70%". The default account table-level quota is 40,000 read and write throughput units, adjustable.

→ Unpredictable/spiky/new → on-demand. Steady and forecastable → provisioned (+ auto scaling).

Connections and proxies — RDS Proxy

SAA2 lesson 5 covered RDS Proxy for resilience. The performance angle, from Amazon RDS Proxy:

"RDS Proxy establishes a database connection pool and reuses connections in this pool. This approach avoids the memory and CPU overhead of opening a new database connection each time."

It handles "unpredictable surges in database traffic" that would otherwise cause "oversubscribing connections or new connections being created at a fast rate". Enable it "for most applications with no code changes."

⚠️ Limits that eliminate options: "you can associate a proxy only with the writer DB instance, not a read replica"; the proxy "must be in the same virtual private cloud (VPC) as the database" and "can't be publicly accessible"; 20 proxies per account.

→ Lambda (or any fast-scaling fleet) + connection errors on RDS = RDS Proxy. It doesn't make queries faster; it stops the connection count from being the bottleneck.

Caching — ElastiCache

The knowledge item is "Caching strategies and services (for example, Amazon ElastiCache)". From What is Amazon ElastiCache?: "a distributed in-memory data store or cache", working with Valkey, Memcached and Redis OSS, in two formats — serverless ("eliminates the need to provision instances or configure nodes", "a highly available cache in under a minute") or node-based (you choose node type, count and AZ placement).

Memcached vs Valkey/Redis OSS

From Comparing node-based Valkey, Memcached, and Redis OSS clusters:

AWS's "choose Memcached if": "You need the simplest model possible", "large nodes with multiple cores or threads", "scale out and in", "cache objects".

→ Leaderboard (sorted sets), pub/sub, replication or failover ⇒ Valkey/Redis OSS. Simplest multi-threaded object cache ⇒ Memcached.

The two strategies

From Caching strategies:

And the combination: "By adding a time to live (TTL) value to each write, you can have the advantages of each strategy."

→ "Stale reads are unacceptable" ⇒ write-through (+ TTL). "Cache only what's actually read" ⇒ lazy loading (+ TTL).

Caching — DAX, only for DynamoDB

From In-memory acceleration with DynamoDB Accelerator (DAX): DAX "reduces the response times of eventually consistent read workloads by an order of magnitude from single-digit milliseconds to microseconds", and it's "API-compatible with DynamoDB" so it needs "only minimal functional changes". The Introduction page puts it as "up to 10 times performance improvement – from milliseconds to microseconds".

DAX is not ideal for, verbatim:

• "Applications that require strongly consistent reads"
• "Applications that are write-intensive"
• "Applications without many repeated reads. DAX performs best when cache hit rates exceed 90%."

→ DynamoDB + microseconds + read-heavy + eventual consistency OK ⇒ DAX. Any of those three "not ideal" conditions ⇒ not DAX.

Global infrastructure

The knowledge item "AWS global infrastructure (for example, Availability Zones, AWS Regions)" is about placement. DynamoDB "automatically replicates your data across three Availability Zones" with a "99.99% availability SLA"; global tables give "multi-active replication" with a "99.999% availability SLA" and "local read and write performance" in each Region. Aurora global databases give read-only secondaries in other Regions. For performance, the point is locality: put the read copy in the Region where the users are. (The DR use of both is SAA2 lesson 6.)

Choosing, under exam conditions

Check yourself

1. A table reads 3 KB items at 100 strongly consistent reads per second. How many RCUs? And eventually consistent?
2. Why is DAX wrong for a banking ledger that requires strongly consistent reads?
3. Name two things Aurora Replicas do that an RDS Multi-AZ standby doesn't.
4. What do you migrate first when moving from SQL Server to Aurora MySQL?
5. Can you attach RDS Proxy to a read replica?

Answers

1. 3 KB rounds up to one 4 KB unit → 100 RCU strongly consistent; eventually consistent is two reads per RCU → 50 RCU.
2. DAX serves "eventually consistent data" and is not ideal for "Applications that require strongly consistent reads".
3. They serve reads (through the reader endpoint) and are failover targets; there can be up to 15 of them. For RDS Multi-AZ: "Unlike a read replica, a standby replica can't serve read traffic."
4. The schema — heterogeneous migration, so DMS Schema Conversion (or AWS SCT) first, then DMS for the data.
5. No. "you can associate a proxy only with the writer DB instance, not a read replica."

Teaching this section

• Open with the read/write split on the board. Every later fix gets placed in one column. It's the single most useful habit for this task statement.
• Do the RCU arithmetic live with three different item sizes and both consistency models.
• Demo: a lazy-loading cache in ten lines of pseudocode; then change the DB value and read the stale cache. Then add write-through and show the churn.
• Best discussion prompt: "Our Aurora readers are at 90% CPU. Add a cache or add a replica?" There's no single answer — it depends on repeat-read ratio — and that's the point.
• Watch for: learners attaching DAX or ElastiCache to write-bound problems.
• Timing: 34 min presented, 15 on the choosing table.