Day 4 - Aurora: The Story of How AWS Rewrote the Storage Layer of an RDBMS

When Aurora was first unveiled at re:Invent 2014, it left many people puzzled. "MySQL-compatible, but not MySQL" was an awkward phrase. AWS's message was clear: the SQL engine code is nearly the same MySQL/PostgreSQL code, but the storage, replication, and transaction layers underneath were redesigned from scratch for the cloud environment. The result of that decision is numbers like "5x the performance of MySQL, 3x that of PostgreSQL + auto-scaling storage + sub-second cross-Region replication."

On DVA-C02, Aurora is asked about from a different angle than RDS. RDS asks about "the trade-offs of a managed DB," while Aurora asks "why is RDS not enough, and in which scenarios should you pick Aurora?" To understand the answer, you need to know Aurora's storage structure and quorum-based replication. Today we look inside.

The Birth of Aurora: "The Essence of a Database Is Storage"

Traditional MySQL/PostgreSQL was designed assuming a 1990s single-server environment. It writes the binlog/WAL to disk, backups copy that disk, and replication sends the binlog to another server. Moving this model to the cloud as is brings these limitations along: ① it depends on a single EBS volume, so it is vulnerable to a single-AZ failure; ② replication is asynchronous and binlog-based, so lag occurs; ③ storage expansion is manual; ④ backup/restore takes time proportional to instance size.

The core insight of the Aurora paper (SIGMOD 2017, "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases," Verbitski et al.) was simple: "The network is the new bottleneck. Therefore reducing network traffic is performance." A traditional DB, at commit time, writes the same data to disk in several forms: ① data pages, ② undo log, ③ redo log, ④ binlog, ⑤ double-write buffer, and so on. According to AWS measurements, MySQL performs about 7.4 disk I/Os per commit.

Aurora sends only the redo log to the distributed storage, and the storage nodes handle page reconstruction in the background. As a result, the I/O count dropped to about one-sixth and network traffic dropped by 7.7x.

Commit in ordinary MySQL:
  Application → MySQL
                  ↓
              Local disk writes (data page, redo log, undo log, binlog, double-write...)
                  ↓
              Binlog-based replica replication (asynchronous)

Commit in Aurora:
  Application → Aurora
                  ↓
              Send only the "redo log record" to 6 storage nodes
                  ↓
              Commit completes once 4 of 6 ack
              (storage nodes reconstruct data pages in the background)

An Aurora storage node is not a simple EBS volume. It is a small server that can receive redo logs and reconstruct pages. An Aurora storage node appends incoming log records to its own local disk and builds page versions with that log applied. When a read request asks for "this page's version as of a specific LSN," the storage node responds immediately.

Thanks to this structure: ① the binlog disappears; ② replicas have no storage of their own and reference the same storage as the primary; ③ backup is effectively free (continuous backup); ④ storage expansion is automatic (segments of 10 GB are added/removed). This is the source of Aurora's differentiation.

6 Copies × 3 AZs + Quorum: "Survives Any Combination of Failures"

The representative picture explaining Aurora storage is "6 copies across 3 AZs." This number was not chosen arbitrarily; it is a value derived from the mathematics of fault tolerance in distributed systems.

3 AZ × 2 copies = 6 copies

Write quorum: V_w = 4 (commit once 4 of 6 copies ack)
Read quorum: V_r = 3 (a read from 3 of 6 copies is valid)

V_w + V_r > N (4 + 3 > 6) → guarantees strong consistency
2 × V_w > N (8 > 6) → prevents concurrent write conflicts

What this configuration guarantees:

• Loss of 1 AZ + 1 additional node = reads still possible (the remaining 3 copies satisfy V_r)
• Loss of an entire AZ = writes still possible (the remaining 4 copies satisfy V_w)
• Loss of 2 AZs = no data loss (the remaining 2 copies can be used for recovery)

Aurora's (N=6, W=4, R=3) was chosen to withstand AZ-level failures and node-level failures together.

Aurora Replicas: Millisecond-Level Replication from Shared Storage

With an RDS Read Replica, each replica has its own storage, receives the primary's binlog, and applies it to its own disk. The limitations of this model are: ① storage cost is incurred for each replica; ② lag depends on binlog transfer + apply speed (usually several seconds to tens of seconds); ③ adding a replica takes time for the initial sync.

An Aurora Replica has no storage of its own. It shares the same distributed storage as the primary. So:

• Replication lag is usually much less than 100 ms (the docs' wording; it grows under heavy write load)
• A new replica is usable immediately (no storage copy)
• Scales up to 15 (RDS MySQL/PG/MariaDB also allow up to 15 per source)
• You pay only for instances (no duplicated storage cost)

⚠️ Pitfall: The 30-second Aurora Replica failover time applies when the instance class is the same. If there is a replica with an instance class different from the primary, its failover priority drops, and performance can degrade after failover. The cause in an "Aurora performance degradation after failover" scenario can be a replica instance size mismatch. You can specify the failover order with Tier 0-15 priorities.

The 5 Aurora Endpoint Types: Tools for Deciding Where to Connect

Unlike RDS, Aurora defaults to cluster-level endpoints rather than instance-level endpoints. You must distinguish the 5 types.

Reader Endpoint load balancing happens at the DNS level. Resolving the same endpoint returns a different replica IP each time (TTL 5 seconds). This causes two problems.

• If a client keeps a connection open, that connection is pinned to one replica. If the connection pool is small, the load isn't distributed evenly.
• A stub resolver that caches DNS (the Java DNS default cache is infinite) doesn't refresh.

In practice you need one of: ① short connection lifetimes; ② Aurora client libraries (MariaDB Connector/J Aurora cluster aware, the Aurora Postgres JDBC wrapper); ③ delegating routing to RDS Proxy. The cause in a scenario such as "I used the Reader Endpoint but the load concentrates on one replica" is persistent connections + DNS caching.

# In practice: isolate analytics workloads with a custom endpoint
ANALYTICS_ENDPOINT = "myclu-analytics.cluster-custom-xxxx.region.rds.amazonaws.com"
OLTP_READER_ENDPOINT = "myclu.cluster-ro-xxxx.region.rds.amazonaws.com"
WRITER_ENDPOINT = "myclu.cluster-xxxx.region.rds.amazonaws.com"
 
def get_analytics_conn():
    return pymysql.connect(host=ANALYTICS_ENDPOINT, ...)
 
def get_oltp_read_conn():
    return pymysql.connect(host=OLTP_READER_ENDPOINT, ...)
 
def get_write_conn():
    return pymysql.connect(host=WRITER_ENDPOINT, ...)

Aurora Serverless v2: The Secret of ACUs

Aurora Serverless automatically scales compute capacity up and down with traffic. The unit is the ACU (Aurora Capacity Unit): 1 ACU ≈ 2 GB of memory plus the corresponding CPU/network. The differences between v1 and v2 appear on the exam.

The biggest difference between v1 and v2 is the scaling mechanism. v1 moves traffic to a new instance (scale-up), so the jumps are large and slow. v2 adjusts capacity in most scaling events while keeping the writer or reader on the same host, and it does not disrupt database operations that are underway. This is the basis of "fine-grained adjustment." v2 is closer to "a regular Aurora instance with usage-based billing."

The choice by usage scenario is as follows.

• Traffic is constant 24 hours a day → regular Aurora instances (cut costs with Reserved)
• Traffic is periodic but predictable → Aurora + Auto Scaling for replicas
• Traffic is intermittent and unpredictable → Aurora Serverless v2
• Development/staging environments (unused at night) → Aurora Serverless v2 (auto-pause enabled)
• Mainly Data API calls → Aurora Serverless v2

Aurora Global Database: The Secret to Sub-Second Cross-Region Replication

Aurora Global Database consists of 1 primary Region + up to 10 secondary Regions. How it differs from an RDS Cross-Region Read Replica: ① dedicated replication infrastructure (storage-level replication); ② lag is typically < 1 second; ③ a secondary can have up to 16 of its own read replicas; ④ managed-failover RTO is on the order of minutes (switchover is typically under 30 seconds on supported versions).

[Primary Region: ap-northeast-2 Seoul]
  Aurora Writer + Replicas
       │
       │ (storage-level replication, < 1 second)
       │
       ├──→ [Secondary: us-east-1 N. Virginia]
       │      Read-only Aurora cluster
       │      Own read replicas 0-16
       │
       └──→ [Secondary: eu-west-1 Ireland]
              Read-only Aurora cluster
              Own read replicas 0-16

Aurora Global Database replication is close to redo log shipping but is not the binlog. The primary's storage nodes additionally send the redo log directly to the storage nodes in the secondary Region. This channel uses the AWS backbone network (average RTT of 100-200 ms on the same backbone), and compression and deduplication are applied, making it more efficient than the public internet. As a result, cross-Region lag is typically under 1 second. The answer to a "global distribution + sub-second lag + RDBMS" scenario is Aurora Global Database.

⚠️ Pitfall: The secondary of an Aurora Global Database is read-only. Attempting a plain write gives a read-only error. Also, "managed failover" must be triggered explicitly and is not automatic: when the primary Region is completely down, the operator executes the promote. If you need automatic failover, build the automation yourself with Route 53 health checks + Lambda, or use RDS Proxy. An answer choice saying "Aurora Global Database fails over automatically" is a trap.

Aurora Backtrack vs PITR: In-Place Time Travel

Aurora MySQL has a feature RDS lacks: Backtrack. It rewinds data to a past point without creating a new instance, up to 72 hours back. PITR creates a new instance, but Backtrack rewinds the same instance in time.

As a hypothetical case, a developer at a game company ran DELETE FROM users with no WHERE clause on a production Aurora MySQL (confusing it with the dev DB). Backtrack was enabled, so a single "rewind to 5 minutes ago" in the console recovered it in about 3 minutes. With PITR, a complicated procedure would have been needed: ① create a new instance (30 minutes), ② export/import the data (hours), ③ switch the application endpoint. For "fast mistake recovery in Aurora," Backtrack is the answer.

Aurora Database Cloning: Instant Clones Built with COW

Aurora can clone a cluster in a few seconds. The clone shares the same storage and works by copy-on-write: only when data is modified in the clone is that page copied anew. The result: ① a clone can be created instantly; ② initial cost = 0; ③ you pay extra storage only for the amount modified.

[Primary Aurora] ────┬──── [Clone A] (development environment)
                     │
                     ├──── [Clone B] (test environment)
                     │
                     └──── [Clone C] (analytics workload)

At first, all share the same storage pages
When a modification occurs, only that page is copied for the clone (COW)

There is a pattern of making a clone of the production DB and testing with production-grade data. A regular mysqldump/export takes hours at TB scale, but an Aurora clone is created almost instantly. You can also use it in a CI/CD pipeline workflow that creates a clone for every build, tests against it, and deletes it afterward.

RDS vs Aurora Decision Table

Summary

Aurora's differentiation derives from one sentence: "the storage layer was redesigned."

• The 6-copy quorum guarantees availability.
• Shared storage makes replicas millisecond-level.
• Redo log shipping makes cross-Region replication sub-second.
• Copy-on-write makes clones instant.

The exam asks about these causal relationships in scenario form. You need to judge "which Aurora feature is the answer for which requirement."

RDS is the first-generation managed DB that "moved an existing DBMS to the cloud," and Aurora is the second generation that "redesigned the DBMS to be cloud-native." DynamoDB is yet another answer that "discarded the relational model itself." If you understand that there are three different answers to the same problem (data durability, scalability, availability), you can solve the exam scenarios.

In the next post, we tie together this whole week (RDS + ElastiCache + Aurora) in a scenario-centered way and wrap up the Week 7 comprehensive assessment.