Aurora Storage, Replicas, and Global Database

Why Aurora shows up on SAP-C02

Amazon Aurora is the usual Professional-level answer when a stem wants a relational online transaction processing (OLTP) engine with MySQL or PostgreSQL compatibility, storage that already spans three Availability Zones (AZs), and optional multi-Region reads. Independent SAP-C02 study material by OpenExamPrep treats Aurora as a design tool you select from the AWS catalog. It does not claim AWS approval, partnership, or exact equivalence with AWS training.

Consider Northwind Payments, a card processor that already authorizes purchases in US East (N. Virginia). Dublin risk analysts and Singapore merchant portals must read ledger state with local latency. The ledger is relational: joins across merchant, card-on-file, and settlement tables, plus multi-statement transactions that either post an authorization or roll it back. That is not a shopping-cart Amazon DynamoDB problem, not a warehouse scan, and not a reason to install MySQL on a fleet of Amazon Elastic Compute Cloud (Amazon EC2) instances as the default. It is an Aurora cluster volume plus, when the footprint is worldwide, an Aurora global database.

Cluster volume: storage that is independent of compute

Aurora stores data in the cluster volume, a single virtual volume on solid-state drives. Aurora keeps copies of that data across three AZs in a single AWS Region. When the writer accepts a commit, Aurora synchronously replicates the data across AZs to six storage nodes associated with the cluster volume. That replication happens whether you attached one instance or sixteen. You do not buy durability by adding readers; readers add compute for reads and failover targets.

Because storage is shared, adding a reader does not copy tables. The new instance connects to the volume that already holds user data, schema objects, indexes, and internal metadata. Removing a reader does not delete data. Only deleting the cluster removes the volume.

You pay for space you use. Specific engine versions support a cluster volume up to 256 tebibytes (TiB). Storage grows as data grows. On current versions, dropping or truncating data can reduce allocated storage, which reduces storage charges. Temporary files for large sorts and index builds use local instance storage with instance-class limits; persistent tables live on the cluster volume.

Aurora offers two cluster storage configurations:

You can switch from I/O-Optimized to Standard at any time. You can switch from Standard to I/O-Optimized once every 30 days. For non-NVMe-based instances, including Aurora serverless instances, switching Standard to I/O-Optimized does not require downtime. NVMe-based instances require a database engine restart.

Trap: treating Aurora Standard versus I/O-Optimized as a Multi-AZ setting. It is a storage billing choice on the same cluster volume.

Writer, readers, endpoints, and Multi-AZ failover

After you create the primary (writer) instance, you can add up to 15 read-only Aurora Replicas (reader instances). Readers use asynchronous replication so they do not tax the writer the way a classic binary-log replica would. Day-to-day SELECT work should hit the reader endpoint. Writes, data definition language (DDL), and data manipulation language (DML) such as INSERT and UPDATE must use the cluster endpoint, which always represents the current writer after a failover.

If the writer fails and at least one replica exists, Aurora promotes a replica. AWS documents a brief interruption during which reads and writes fail, with service typically restored in less than 60 seconds, and often less than 30 seconds. If the cluster has no replicas, Aurora recreates the primary in the same AZ, typically in less than 10 minutes. Promoting a replica is much faster than creating a new primary, which is why a single-instance Aurora cluster is a reliability miss on a payments ledger.

You assign each replica a promotion priority from 0 (highest) to 15 (lowest). Changing priority does not by itself trigger failover. If two replicas share a priority, Aurora promotes the largest instance; if size also ties, promotion inside that tier is arbitrary. After five unsuccessful failover attempts, promotion tiers are no longer considered.

The cluster volume already spans multiple AZs. Multi-AZ for compute means placing the writer and at least one reader in different AZs. You can create that layout at launch or convert later by adding a reader in another AZ. If the writer’s AZ fails and a reader exists in another AZ, Aurora promotes that reader. If every instance sits in one AZ, you must manually create instances in another AZ after an AZ event.

On Aurora MySQL, when a failover happens, Aurora restarts the writer and the reader that is promoted; other readers can keep serving the reader endpoint. Use that fact when Northwind’s reporting queries must survive writer failover.

Aurora Global Database for worldwide reads and Regional recovery

An Aurora global database is one primary AWS Region where writes land and up to 10 read-only secondary Regions. After a write, Aurora replicates to secondaries on dedicated infrastructure, with latency typically under a second, and with little performance impact on the primary. Offices in other Regions read from a local secondary cluster. Each secondary can scale independently; a secondary cluster is read-only, so it can hold up to 16 read-only instances rather than the usual 15 on a single-Region cluster.

Configuration math that exam items use: the number of reader instances on the primary cluster plus the number of secondary clusters cannot exceed 15. If the primary already has 14 readers and one secondary, you cannot attach another secondary. Cluster names must be unique across all Regions. You cannot put two member clusters in the same Region.

Applications should issue writes to the Aurora Global Database writer endpoint, which continues to point at the primary cluster even after a switchover or failover to another Region.

Write forwarding lets a secondary accept write requests and send them to the primary so application tiers in Dublin do not all hard-code the primary endpoint. After a role change, Amazon RDS Proxy is Regional: redirect writes to the proxy (default or custom read/write endpoint) attached to the new primary. During the change, the old primary’s proxy still accepts writes until that cluster becomes secondary, after which those writes fail.

Limitations that change an answer:

• Backtracking is not supported on Aurora Global Database.
• Aurora Auto Scaling is not supported for secondary DB clusters (you add readers yourself; serverless readers still help with granular scale).
• You cannot stop or start member clusters individually.
• If the primary writer restarts or fails over, secondary readers can restart and the secondary is unavailable until they resync.
• AWS Secrets Manager integration is not supported on Global Database; turn it off before you add a Region.
• For a global database with Aurora serverless, AWS recommends a minimum of 8 ACUs on the primary cluster.
• Managed switchover/failover requires matching major and minor engine versions (patch-level rules vary by engine).

Northwind’s authorization writer stays in us-east-1. eu-west-1 and ap-southeast-1 secondaries serve local reads. That is Global Database, not three disconnected Multi-AZ clusters, and not nightly snapshot copies.

Serverless versus provisioned compute

Aurora serverless (the current serverless instance class on a cluster, historically called Serverless v2 in many exam conversations) measures compute in Aurora capacity units (ACUs). Each ACU is about 2 gibibytes (GiB) of memory plus corresponding CPU and networking. You set a minimum and maximum ACU range for the cluster. Depending on engine and platform version, the range can be 0.5–128, 0.5–256, or 0–256 ACUs. A minimum of 0 enables automatic pause and resume. Storage still holds terabytes while compute scales down; you are charged for ACU-hours actually used.

Provisioned instances use a DB instance class with fixed memory, CPU, and I/O. They fit steady ledgers where you can change class ahead of known peaks and accept a brief disruption when you resize the writer. Serverless fits variable load: promotions, overnight batch, new products with unknown traffic.

You can mix serverless and provisioned instances in one cluster: a large provisioned writer with serverless readers, or a serverless writer with provisioned readers. You can convert an instance between serverless and provisioned without creating a new cluster.

Readers in promotion tiers 0 and 1 keep minimum capacity tied to the writer so they are ready to take over. Readers in tiers 2–15 scale independently—useful for Northwind’s heavy fraud reports that should not inflate writer ACUs. You can add up to 15 serverless readers across three AZs. On a global database, secondaries can use serverless so they stay cheap until promotion, then scale up.

Trap: setting minimum ACUs to 0 on a payments writer that cannot tolerate pause/resume latency. Auto-pause is a cost control for idle or development clusters, not for a 24/7 authorization path unless the stem says the database may sleep.

Clone versus restoring a copy

Aurora cloning uses a copy-on-write protocol. The clone initially shares data pages with the source; extra storage appears only as either side mutates pages. Cloning is faster and more space-efficient than restoring a snapshot. Typical uses: try a schema change, run a heavy export, or give developers a copy of production data without an hours-long restore.

Limits: clones are same-Region only. You can create up to 15 copy-on-write clones; the next clone is a full copy, behaving like point-in-time recovery. Cross-VPC clones require subnets that map to the same AZs. Cross-account clones use AWS Resource Access Manager (AWS RAM). The cluster you clone must have at least one DB instance.

With the AWS Command Line Interface, cloning is restore-db-cluster-to-point-in-time with --restore-type copy-on-write and --use-latest-restorable-time. Without copy-on-write, that same API performs a restore rather than a clone. The command creates a cluster without instances; you then create-db-instance for the writer and optional readers. You can pass --serverless-v2-scaling-configuration so the clone can use serverless instances even if the source was provisioned.

Backtrack versus point-in-time recovery

Backtrack (Aurora MySQL only—not Aurora PostgreSQL) rewinds the existing cluster to a consistent time. It is not a substitute for backups. Advantages versus restore: undo a DELETE without a WHERE clause in minutes, stay on the same cluster, and move back and forth inside the window to find when corruption started.

You set a target backtrack window (maximum 72 hours). The actual window can be shorter under heavy change volume because Aurora stores change records. You pay an hourly rate for those records. You cannot enable backtrack later on an existing cluster; enable it at create time or when restoring a snapshot. Backtrack affects the entire cluster, causes a brief disruption (Aurora pauses the database, closes connections, and drops uncommitted work), and cannot rewind a clone to a time before the clone existed. Global Database does not support backtrack. Binary logging plus a forced backtrack can break downstream replicas.

Point-in-time recovery (PITR) always creates a new DB cluster from automated backups, to any second before LatestRestorableTime within BackupRetentionPeriod. Restore can take hours for a large volume. The console creates the writer for you; the CLI/API restore creates the cluster only, so you must CreateDBInstance yourself. You can also use AWS Backup plans to drive PITR when the cluster is in a backup plan. Cloning’s copy-on-write restore type is a fast sibling of this API, not a rewind of the source cluster.

For Northwind, a bad migration script on a non-global Aurora MySQL lab cluster is a backtrack candidate if backtrack was enabled at create. The same mistake on a global payments cluster is PITR (new cluster) plus careful cutover—not backtrack.

RDS Proxy on the authorization path

Amazon RDS Proxy sits between application pools (often AWS Lambda or bursty containers) and Aurora. It multiplexes many application connections onto fewer database connections, queues bursts, and can store credentials in Secrets Manager or enforce AWS Identity and Access Management (IAM) authentication so passwords are not baked into code.

For availability, the proxy preserves application connections across failover and bypasses Domain Name System (DNS) caches, which AWS documents as reducing failover time by up to 66 percent for Aurora Multi-AZ databases. The default proxy endpoint is read/write and always goes to the writer, counting against max_connections. Create additional read-only proxy endpoints so reporting does not pile onto the writer; those endpoints require at least one reader. If every reader dies, read-only proxy connections fail immediately rather than waiting on DNS.

On Global Database, deploy a proxy per Region. If write forwarding is on, reduce the proxy MaxConnectionsPercent by the cluster’s write-forwarding quota (aurora_fwd_writer_max_connections_pct on Aurora MySQL). Do not set session-level replica-read-consistency parameters that AWS lists as unsupported with Proxy on forwarded secondaries.

Scenario: Northwind’s global authorization stack

Priya places the writer and two readers in three AZs in us-east-1, I/O-Optimized because authorization I/O dominates the bill, and RDS Proxy in front of Lambda. She adds Global Database secondaries in Europe and Asia-Pacific for local reads, serverless readers on the secondaries, and a planned switchover runbook that retargets Proxy write endpoints. She does not enable backtrack on the global cluster. She clones the primary in-Region for a schema experiment. She keeps PITR retention for true restore. That design is what SAP-C02 is testing: storage already Multi-AZ, compute Multi-AZ, global reads, and the right undo tool.

Aurora traps

1. Equating a single-AZ writer with Multi-AZ storage (the volume is already three AZs; compute may not be).
2. Using snapshot copy as if it were Global Database replication.
3. Expecting backtrack on Aurora PostgreSQL or on Global Database.
4. Treating PITR as an in-place rewind.
5. Cloning across Regions.
6. Pointing Lambda straight at the writer until too many connections appears, instead of Proxy.
7. Auto-pausing the payments writer to 0 ACUs because “serverless means idle is free.”