Aurora launched in 2014 with MySQL compatibility, and PostgreSQL compatibility followed in 2017. The problem AWS set out to solve was specific: traditional relational databases, including standard MySQL and PostgreSQL running on RDS, replicate by shipping the entire write-ahead log (or binary log) to every replica and having each replica independently replay it against its own full copy of the data files. That model works, but it multiplies I/O across every node in the cluster and makes failover slow, because a newly-promoted replica has to finish replaying any log it hadn’t yet applied before it can safely accept writes.

Aurora’s founding insight was to separate compute from storage entirely and push replication down into a purpose-built, distributed storage layer that understands only redo log records — not full pages, not a serialized binary log stream. The database engine on top writes small, ordered log records to this storage layer, the storage layer handles replication, durability, and page reconstruction itself, and every reader in the cluster shares the same underlying storage rather than maintaining an independent copy. This one architectural decision is the root cause of nearly every characteristic that distinguishes Aurora from vanilla managed MySQL or PostgreSQL: sub-30-second failover, replicas with negligible lag, storage that grows automatically without a resize operation, and backups that are continuous rather than scheduled snapshots.

Running MySQL or PostgreSQL yourself, or even on RDS with traditional storage, means living with a specific set of operational costs: replication lag that grows under write pressure because each replica must independently replay every change; failover that takes tens of seconds to minutes because a promoted replica must first finish applying its log backlog and open its storage engine cleanly; manual storage provisioning that forces you to guess capacity ahead of time or suffer downtime resizing; and backup strategies that either impose I/O overhead during a snapshot window or leave a gap in recovery granularity between snapshots.

Aurora addresses each of these by construction rather than by tuning. Because storage is shared and log-based, a promoted replica doesn’t need to replay anything — it already has access to the same durable, up-to-date storage the old primary was writing to, so failover becomes a matter of redirecting connections and briefly reconstructing in-memory state, not replaying a log. Because storage capacity grows in 10 GB increments automatically, up to well beyond 128 TB per cluster, there is no forklift resize operation to plan for. And because the storage layer continuously streams redo log records rather than taking periodic full snapshots, Aurora backups are continuous and restore to any second within the retention window, not just to the last nightly snapshot.

This narrowing is easy to underrate until you’ve operated a self-managed alternative. A self-built distributed relational storage layer has to solve consensus across replicas, coordinate crash recovery without losing committed data, and keep read replicas current without imposing full replay cost on every one of them — problems that individually justify entire engineering teams at companies operating at scale. Aurora amortizes that engineering cost across every AWS customer simultaneously, which is precisely why a database this sophisticated can be provisioned in minutes rather than requiring a dedicated database infrastructure team to build from scratch.

Storage-Compute Separation and the Log-Structured Storage Layer

In Aurora, the database engine instance handles query parsing, execution planning, transaction management, and caching — but it does not own the data files the way traditional MySQL or PostgreSQL does. Instead, when a transaction commits, the engine ships only the redo log records describing what changed to a separate, purpose-built distributed storage service. That storage service is responsible for turning those log records into durable data pages, replicating them, and serving reads. This means the compute layer’s job shrinks dramatically compared to a traditional database — it never has to flush dirty pages to disk itself, because the storage layer does that reconstruction work independently and asynchronously.

Six Copies, Quorum Writes, Quorum Reads

Every piece of data in an Aurora cluster is stored as six copies, spread across three Availability Zones — two copies per AZ. Writes are considered durable once a quorum of 4 out of 6 copies acknowledge them; reads (when needed at the storage layer, which is rare since compute nodes cache aggressively) require a quorum of 3 out of 6. This 4-of-6 / 3-of-6 split is deliberate: it guarantees the cluster can tolerate the loss of an entire Availability Zone plus one additional storage node without losing write availability, and can tolerate an AZ failure plus one additional node without losing read availability — a stronger fault tolerance guarantee than a simple 2-of-3 or 3-of-3 replication scheme would provide.

The arithmetic here is worth sitting with, because it’s the answer to “why six copies and not three.” With three AZs each holding two copies, losing one full AZ removes exactly two copies, leaving four — still enough to satisfy a 4-of-6 write quorum, so the cluster keeps accepting writes without any manual intervention. A simpler three-copy, one-per-AZ scheme would only leave two copies after an AZ loss, which is not enough for most meaningful quorum thresholds without effectively requiring unanimous agreement from the survivors — a far more fragile position during exactly the kind of event durability guarantees exist to protect against.

Aurora Replicas and Shared Storage

Because all instances in a cluster — the writer and up to 15 readers — attach to the same shared storage volume, adding a read replica does not create a second copy of the data. A new replica simply starts reading from the existing storage layer and begins serving queries almost immediately, without a lengthy data copy step. Replica lag in Aurora is typically measured in single-digit milliseconds under normal conditions, because replicas aren’t waiting on a serialized log stream to replay — they’re applying a continuous stream of already-durable log records to update their own in-memory cache, which is a fundamentally lighter operation than traditional replication.

It’s worth being precise about what a reader replica actually caches versus reads from storage on demand. Each reader maintains its own buffer pool — an in-memory cache of recently-accessed pages — separate from every other instance’s cache. When a query on a reader needs a page not currently in its buffer pool, it fetches that page from the shared storage layer directly, which is why a cold reader (one that just started, or one serving an unusual query pattern it hasn’t seen before) can show higher latency than a warm one, even though both are reading from identical, fully up-to-date underlying storage. This is a subtlety that matters when deciding whether to keep a reader running continuously versus scaling it up only during predictable traffic spikes — a reader spun up cold right as a spike begins will pay a cache-warming cost the continuously-running one wouldn’t.

Backtrack (Aurora MySQL)

Backtrack lets you rewind an Aurora MySQL cluster to an earlier point in time without restoring from a backup into a new cluster. Because the storage layer already retains a continuous log of changes, backtrack effectively replays storage backward to the target timestamp in place — turning what would traditionally be a lengthy point-in-time restore operation (spin up a new instance, replay logs, cut over) into an operation that completes in minutes on the same cluster. This is specifically useful for recovering from an application-level mistake, like an unintended bulk UPDATE without a WHERE clause, not for recovering from infrastructure failure.

A frequently missed detail is that backtrack rewinds the entire cluster, not a single table or a single schema — every database on that cluster moves backward together. This makes it a poor fit for a multi-tenant cluster where only one tenant’s data needs correcting, since fixing one tenant’s mistake would roll back every other tenant sharing that cluster along with it. Teams running multi-tenant workloads on a shared Aurora MySQL cluster typically plan around this by using targeted row-level restores from a snapshot into a scratch cluster instead, extracting only the affected rows, rather than relying on backtrack for tenant-scoped recovery.

Fast Database Cloning

Aurora cloning creates a new cluster that shares the same underlying storage pages as the source cluster at the moment of cloning, using copy-on-write — pages are only actually duplicated once either the clone or the source diverges by writing to them. This makes cloning a multi-terabyte production database for testing or analytics a near-instant, low-storage-overhead operation, in sharp contrast to a traditional restore-from-snapshot, which must fully copy all data before it’s usable.

The practical implication is that a clone’s storage cost stays close to zero until it actually diverges meaningfully from the source, which changes the economics of environments teams previously avoided creating for cost reasons — a full-scale, disposable copy of production for a single investigation, or a per-pull-request ephemeral test database, becomes cheap enough to be routine rather than something reserved for rare, carefully-justified occasions.

You may likeAmazon MemoryDB→

Aurora Global Database

Global Database extends a single Aurora cluster across multiple AWS regions, with one primary region handling writes and up to five secondary regions receiving replicated data with typical replication lag under one second — achieved by replicating at the storage layer directly, shipping log records across regions rather than relying on logical, engine-level replication. This is materially different from setting up cross-region read replicas on a traditional database, both in lag characteristics and in the managed failover tooling Global Database provides for promoting a secondary region during a regional disaster.

Aurora Serverless v2

Serverless v2 scales compute capacity in fine-grained Aurora Capacity Units (ACUs) automatically, in fractional increments, based on actual load, without the connection-dropping “scaling event” pause that characterized Serverless v1. Critically, Serverless v2 instances can participate in the same cluster alongside provisioned instances, and Global Database and most other Aurora features work with it — it’s best understood as an alternate compute sizing model for an Aurora cluster, not a separate product with a different storage engine underneath.

Aurora Limitless Database

For workloads that genuinely outgrow a single writer, Aurora Limitless Database introduces transparent horizontal sharding across many writer nodes, coordinated by a routing layer that presents applications with a single logical database endpoint despite data being distributed across shards underneath. This is a meaningfully different operating model from a standard Aurora cluster — it requires choosing shard keys thoughtfully, much like any distributed database, and trades some of the simplicity of a single-writer cluster for genuine horizontal write throughput beyond what any single instance class could sustain.

Parameter Groups and Engine Versioning

Aurora clusters are configured through cluster parameter groups (settings that apply cluster-wide, like character sets or replication behavior) and instance parameter groups (settings scoped to an individual instance, like buffer pool sizing on that specific node). Both are tied to a specific engine version family, which matters operationally because a major engine version upgrade typically requires creating a new parameter group compatible with the target version rather than simply reusing the old one — a detail that trips up teams planning their first major-version upgrade.

An Aurora cluster has three layers worth naming separately: the compute layer (writer and reader instances running the MySQL- or PostgreSQL-compatible engine), the distributed storage layer (the log-structured, quorum-replicated volume spanning three AZs), and the cluster endpoint layer (the DNS-based routing that directs application traffic to the right instance without the application needing to track instance identities itself).

flowchart TB
    App["Application"] --> WEndpoint["Cluster Endpoint (writer)"]
    App --> REndpoint["Reader Endpoint (load-balanced)"]
    WEndpoint --> Writer["Writer Instance"]
    REndpoint --> Replica1["Reader Replica 1"]
    REndpoint --> Replica2["Reader Replica 2"]
    Writer -->|"redo log records"| Storage["Distributed Storage Layer"]
    Replica1 -->|"read pages / apply log"| Storage
    Replica2 -->|"read pages / apply log"| Storage
    Storage --> AZ1["AZ A - 2 copies"]
    Storage --> AZ2["AZ B - 2 copies"]
    Storage --> AZ3["AZ C - 2 copies"]
    

The writer instance is the only instance that accepts write transactions; it generates redo log records and ships them to storage, and it maintains its own buffer pool cache for fast reads of recently-written data. Reader instances serve read-only queries, maintain their own independent buffer pool caches, and continuously apply the incoming log stream from storage to keep those caches current — they never accept writes, and application code connecting through the writer endpoint by mistake will simply receive an error rather than silently succeeding. The cluster endpoint always resolves to the current writer, even across a failover, so applications don’t need to track which specific instance is currently primary. The reader endpoint load-balances connections across all available reader instances automatically, which matters for spreading read traffic without the application implementing its own round-robin logic.

Two supplementary endpoint types round out the picture for specific use cases. Custom endpoints let you group a defined subset of instances — for example, isolating a set of larger readers for reporting workloads away from smaller readers serving latency-sensitive application traffic — under their own dedicated DNS name, so different classes of read traffic don’t compete for the same instances. And the instance endpoint, unique to each individual node, is mainly useful for administrative or monitoring tooling that genuinely needs to target one specific instance rather than for application traffic, which should almost always go through the cluster or reader endpoint instead.

When a transaction commits, the engine does not write full data pages to disk itself. It generates a set of ordered redo log records describing the change and sends them to the storage layer, fanning out to all six storage nodes in parallel. The transaction is considered committed as soon as 4 of the 6 nodes acknowledge durable receipt of the log records — the engine does not wait for all six, which is precisely what keeps commit latency low even though six physically separate copies exist. The storage nodes themselves are responsible for asynchronously turning accumulated log records into actual data pages in the background, a process decoupled entirely from the commit path, so the application never waits on page materialization.

Failover works differently from traditional MySQL precisely because of this separation. When the writer instance fails, Aurora doesn’t need to find a replica that has fully replayed the outstanding log — every reader already shares the same durable storage the writer was using, up to the last acknowledged commit. Promotion involves selecting a reader (by default, the one with the highest priority tier, configurable per instance), briefly warming its buffer pool if needed, updating the cluster endpoint’s DNS record to point at the newly-promoted instance, and opening it for writes. This is why Aurora failover typically completes in under 30 seconds, often faster, compared to the multi-minute failovers common with traditional replicated MySQL.

You may likeAWS Shield→

Because the storage layer already maintains a continuous, durable log of every change, Aurora backups work fundamentally differently from periodic snapshot-based backups on traditional databases. Continuous backup to S3 happens automatically and incrementally in the background with no measurable performance impact on the running cluster, and point-in-time recovery can restore to any second within the configured retention window (up to 35 days), not just to the moment of the last scheduled snapshot.

sequenceDiagram
    participant App as Application
    participant Writer as Writer Instance
    participant Storage as Storage Layer
    participant Backup as Continuous Backup (S3)
    participant Reader as Reader Replica

    App->>Writer: COMMIT transaction
    Writer->>Storage: Ship redo log records (parallel to 6 nodes)
    Storage-->>Writer: 4-of-6 quorum acknowledged
    Writer-->>App: Commit confirmed
    Storage->>Backup: Continuous incremental backup
    Storage->>Reader: Log stream applied to reader cache
    

Manual snapshots remain available for long-term retention beyond the automated backup window, and can be shared across accounts or copied cross-region — useful for compliance archival or for seeding a new environment. Restoring from a backup, whether automated point-in-time recovery or a manual snapshot, always creates a new cluster rather than mutating the existing one in place, which is a deliberate safety property: a botched restore never destroys the source data it was restoring from.

This “restore always creates a new cluster” behavior has a direct operational consequence worth planning for: a restored cluster gets a new endpoint address, not the original one. Any restore-based recovery procedure therefore needs an explicit cutover step — updating application configuration, DNS, or a connection-string secret to point at the new cluster’s endpoint — and that cutover step, not the restore operation itself, is usually the actual bottleneck in a real recovery timeline. Teams that only test the restore step in isolation, without rehearsing the full cutover, often discover this gap during an actual incident rather than during a drill.

The single biggest trade-off engineers underestimate is the single-writer constraint. Unlike some distributed SQL systems that accept writes on any node, a standard Aurora cluster has exactly one writer at a time — write scalability comes from making that one writer efficient and fast to fail over, not from spreading writes across nodes. Applications with genuinely write-heavy, horizontally-scalable requirements either need read/write splitting discipline at the application layer, or should evaluate Aurora Limitless Database, which introduces sharding specifically to address this constraint at significant added architectural complexity.

A second underestimated trade-off is compatibility depth versus compatibility breadth. Aurora tracks upstream MySQL and PostgreSQL closely enough that the overwhelming majority of applications migrate with no code changes, but “compatible” is not “identical” — certain storage-engine-specific extensions, some replication plugins built assuming access to raw binary log files, and a handful of niche PostgreSQL extensions either behave differently or aren’t supported at all, precisely because Aurora’s storage engine isn’t InnoDB or PostgreSQL’s native heap storage underneath. Teams with a deep dependency on such an extension should verify compatibility explicitly before committing to a migration, rather than assuming full parity from the “compatible” label alone.

Read scalability in Aurora comes primarily from adding reader instances, up to 15 per cluster, each with independent compute and memory but sharing the same storage — meaning read throughput scales roughly linearly with reader count for cache-friendly workloads, without the storage duplication cost traditional replication would impose. Write scalability, by contrast, is bounded by the single writer’s instance size; scaling writes means scaling that one instance vertically (a larger instance class) or, for genuinely write-bound workloads beyond a single instance’s ceiling, adopting Aurora Limitless Database’s distributed sharding model.

Aurora MySQL’s Parallel Query feature pushes filtering and aggregation work for certain analytical queries down into the distributed storage layer itself, executing across thousands of storage nodes in parallel rather than pulling all raw data up into the compute instance first — a meaningful speedup for large table scans mixed into an otherwise transactional workload, though it applies to a specific, documented subset of query patterns rather than every query. Serverless v2 handles a different kind of scaling problem — unpredictable or spiky load — by adjusting ACU allocation in fine increments within seconds, avoiding both the cost of permanently over-provisioning for peak load and the latency hit of a full instance resize.

It’s worth being precise about what “scales automatically” means for storage versus compute, because the two behave very differently. Storage genuinely requires no intervention — Aurora grows the underlying volume transparently as data is written, in the background, with no downtime and no explicit resize command ever issued. Compute scaling is not automatic on provisioned instances at all; scaling a provisioned writer or reader up or down is a manual instance-class change (or a scheduled one via automation you build yourself) that briefly interrupts connections to that instance during the modification. Only Serverless v2 compute scales automatically in the way storage does, which is the main reason many teams choose it for the writer instance specifically, even while keeping provisioned readers for cost-predictable steady-state read capacity.

Within a single region, Aurora’s availability comes from the 6-copy, 3-AZ storage quorum combined with automated failover to a reader instance. A cluster with at least one reader in a different AZ than the writer can survive a full AZ outage with a brief, automated failover; a cluster with zero readers can still survive storage-layer AZ loss without data loss (because the quorum design tolerates it), but must wait for Aurora to provision a new writer instance, which takes materially longer than promoting an existing warm reader — a strong operational reason to always run at least one reader in production, even a small one, purely for failover readiness rather than read scaling.

Failover priority tiers (0 through 15, lower promotes first) let you control which reader gets promoted first, useful when reader instances are intentionally sized differently — for example, keeping a large reader as the preferred failover target and a smaller one purely for lightweight reporting queries that shouldn’t become the primary under load.

It’s also worth distinguishing planned maintenance from unplanned failure in how Aurora handles availability. Engine patching and minor version upgrades are applied during a configurable maintenance window, and Aurora performs these with a brief, typically sub-second to low-second interruption on the writer by failing over to an already-patched reader rather than restarting the writer in place — meaning routine patching piggybacks on the same fast-failover mechanism that handles unplanned failure, rather than requiring a separate maintenance-specific downtime model. This is a meaningful operational simplification compared to databases where planned maintenance and unplanned failure require entirely different runbooks.

Aurora Global Database extends this reliability model across regions: a secondary region’s cluster can be manually or automatically promoted to become the new primary during a full regional outage, with typical recovery time objectives (RTO) in the low single-digit minutes and recovery point objectives (RPO) around one second, thanks to storage-level cross-region replication rather than logical replication that could fall further behind under load.

A subtlety worth flagging explicitly: promoting a Global Database secondary region during an actual regional outage is a managed but not fully automatic action by default — an operator (or an automation pipeline built specifically for this purpose) initiates the promotion, rather than Aurora silently failing over across regions the way it does across AZs within a region. This is a deliberate design choice, since cross-region promotion during a real disaster carries application-level implications — DNS cutover, connection string changes, and confirming the failed region is genuinely unreachable rather than experiencing a transient blip — that are risky to fully automate without human or carefully-tested automated judgment in the loop.

Disaster Recovery Pattern

A common architecture pairs a multi-AZ Aurora cluster with at least two readers in production, automated backups with a 35-day retention window, and a Global Database secondary region for regional-scale disaster recovery — giving protection against instance failure, AZ failure, and regional failure with three distinct, appropriately-scoped mechanisms.

You may likeAmazon Cognito→

Aurora security layers network isolation, identity-based access, and encryption, and — as with most managed AWS services — incidents usually trace to one layer being misconfigured while the others were correct. Network isolation starts with placing the cluster in private subnets within a VPC, reachable only from application security groups explicitly permitted to connect on the database port, never exposed directly to the public internet in a production configuration.

Identity and access split into two distinct concerns that are easy to conflate: IAM controls who can manage the cluster itself (create, modify, delete, take snapshots) via IAM policies evaluated by the RDS/Aurora control plane, while database-level users and privileges (GRANT statements, roles) control what an authenticated database session can actually do to the data once connected. IAM database authentication offers a bridge between the two, letting you authenticate a database connection using short-lived IAM-generated tokens instead of a long-lived database password, which removes password rotation as an operational burden and lets database access follow the same IAM policy and audit trail as everything else in the account.

Encryption at rest is enabled via AWS KMS at cluster creation time — critically, this cannot be added retroactively to an existing unencrypted cluster; enabling it later requires creating an encrypted snapshot and restoring into a new encrypted cluster, which is a migration teams frequently discover too late. Encryption in transit is enforced via TLS between the application and the cluster, and Aurora supports enforcing TLS-only connections at the parameter group level so an accidental unencrypted connection is rejected outright rather than silently allowed.

Secrets management deserves a specific mention because it’s a recurring source of avoidable risk: storing database credentials in application configuration files or environment variables long-term is a common but fragile pattern, and AWS Secrets Manager’s native Aurora integration supports automatic credential rotation on a schedule without any application code change, since the application retrieves the current credential at connection time rather than having it baked in statically. Combined with IAM database authentication for human and service access where practical, this significantly narrows the blast radius of a leaked credential, since a rotated or IAM-issued token has a short useful lifetime compared to a static password that might live in a config file indefinitely.

ADR-AUR-001Anti-Pattern

Context

A team launches a cluster without encryption at rest “to move fast,” planning to enable it later once the workload is confirmed production-worthy.

Consequence

Enabling encryption later requires a full snapshot-and-restore into a new cluster, with a cutover window and endpoint change — effectively a migration, not a setting toggle.

Preferred Approach

Enable KMS encryption at cluster creation unconditionally; the performance overhead is negligible, and it avoids a forced migration later.

You may likeAWS Elastic Beanstalk→

CloudWatch provides the baseline instance and cluster metrics — CPU, connections, replica lag (specifically AuroraReplicaLag, the metric worth alarming on for read-scaling health), storage growth, and buffer cache hit ratio. Performance Insights goes deeper, giving a query-level view of database load, breaking down exactly which SQL statements, wait events, or users are consuming the most database time at any given moment — invaluable for diagnosing a sudden performance regression without guessing which query changed behavior.

Enhanced Monitoring supplies OS-level metrics (down to per-process CPU and memory) at up to 1-second granularity, which is finer-grained than the host-level metrics CloudWatch exposes by default and useful for correlating database-level symptoms with underlying instance resource pressure. Database Activity Streams provide a near-real-time, tamper-resistant audit feed of database activity, piped to Kinesis, specifically built for compliance and security monitoring use cases where a general-purpose query log isn’t a sufficiently trustworthy audit trail.

Infrastructure as Code (CloudFormation, Terraform, CDK) is the standard way to define clusters, parameter groups, and instance topology reproducibly — particularly important for Aurora given how many settings (encryption at creation, parameter group families tied to engine version, subnet groups) are difficult or impossible to change after the fact without a migration. Aurora integrates natively with several AWS data services beyond the obvious application connection: Aurora Machine Learning lets SQL queries invoke SageMaker or Comprehend models directly from within a query for inline inference, and zero-ETL integrations with Redshift let near-real-time analytics run against Aurora data without a separately maintained extract-transform-load pipeline.

For applications already using RDS MySQL or PostgreSQL, AWS Database Migration Service (DMS) combined with the Aurora-specific migration tooling supports both one-time and continuous-replication migration paths, which matters because a “just point your app at a new endpoint” migration is rarely realistic for a live production database with an uptime requirement.

Connection management is another integration detail worth planning for explicitly. Aurora instances, like most relational databases, have a finite maximum connection count that scales with instance size, and a naive application deployment that opens a new connection per request rather than pooling them will exhaust that ceiling well before the instance’s CPU or memory becomes the bottleneck. RDS Proxy sits between the application and the cluster, pooling and multiplexing connections, and — specifically relevant to Aurora — it also keeps application connections alive transparently across a failover, reducing the number of connections applications see reset when the writer changes, which is often a bigger practical win than the pooling itself for latency-sensitive applications.

Aurora’s compute cost is billed per instance-hour by instance class, separately from storage (billed per GB-month actually consumed, which grows automatically) and I/O (billed per million requests, unless using the I/O-Optimized configuration, which folds I/O cost into a flat higher instance rate — a better deal for I/O-heavy workloads and a worse one for lightly-loaded clusters). Choosing between standard and I/O-Optimized pricing is a genuine cost-modeling exercise, not a default choice, and AWS’s own cost calculator comparing actual I/O volume against the two pricing models is worth running before committing either way.

Serverless v2 is the natural cost lever for genuinely unpredictable or intermittent workloads — development and staging environments, low-traffic internal tools, or applications with sharp daily traffic cycles — since it scales compute down to a configurable minimum ACU floor during quiet periods rather than paying for a fixed instance size around the clock. For steady, predictable production load, provisioned instances with Reserved Instance or Savings Plans pricing commitments typically cost less than running the equivalent steady load on Serverless v2, so the two are complementary tools rather than one simply replacing the other.

Reader instances are a frequent, quiet cost creep — teams add read replicas during a capacity crunch and rarely revisit whether all of them are still needed once traffic normalizes. Reviewing reader utilization via Performance Insights periodically, and right-sizing or removing replicas that are no longer contributing meaningfully to read throughput, is a simple recurring cost discipline many teams skip.

Storage cost is worth a specific note because it behaves differently from most AWS storage pricing: Aurora storage cost is driven by the high-water mark of data actually written, and space freed by deletes is not always immediately reflected in billed storage the way it might be on a traditional filesystem, since the underlying log-structured layer reclaims space through its own background compaction process rather than an instant in-place free. For workloads with heavy delete-and-rewrite churn, this is worth factoring into capacity cost projections rather than assuming storage cost tracks the current logical data size one-to-one at every moment.