Skip to main content
This lesson covers Amazon Aurora — a cloud-native, fully managed relational database engine compatible with MySQL and PostgreSQL. Aurora combines commercial-grade database features with the cost-efficiency and operational simplicity of a managed cloud service. It’s designed for high performance, durability, and seamless scaling while remaining a drop-in replacement for MySQL/PostgreSQL in most applications. Why choose Aurora? Traditional database designs couple compute and storage on a single instance with attached storage. That coupling creates operational challenges:
  • Snapshots and backups get slower as data grows because attached storage must be copied.
  • Scaling storage independently of compute often requires downtime or complex migration.
  • Backup and restore times for very large databases increase.
  • To meet peak demands, you may overprovision storage, increasing cost.
Aurora decouples compute and storage to solve these problems. Its storage layer is purpose-built to deliver high throughput, fault tolerance, and durability while simplifying administration.
A slide diagram titled "Amazon Aurora?" showing applications performing writes and reads to an Aurora storage volume spread across three availability zones, illustrated by grids of colored storage blocks. Text annotations describe the quorum model (4/6 for writes, 3/6 for reads), AZ fault tolerance, and use of a gossip protocol for node repair.

​
Aurora storage architecture (high level)

Aurora stores data in a distributed, log-structured system that stripes segments across many storage nodes. The design enables continuous backups, AZ-level replication, and fast recovery using quorum rules and node repair protocols. Key storage details: These components give Aurora highly available, durable storage with continuous backups to Amazon S3 and rapid failover behavior.

​
Architecture components and cluster model

An Aurora DB cluster includes:
  • A cluster volume — a virtual storage layer that spans multiple Availability Zones.
  • One primary instance — the read/write endpoint that applies data modifications to the cluster volume.
  • Up to 15 Aurora Replicas — read-only instances attached to the same cluster volume for read scaling and failover.
Replicas are distributed across AZs to provide read scalability and high availability. Only one instance accepts writes at a time; if the primary fails, Aurora promotes a replica based on configured failover priorities.
A diagram of an Amazon Aurora DB cluster spanning three availability zones, showing a primary instance (master) and multiple Aurora replicas connected to a shared cluster volume with data copies. Arrows indicate that reads are served by replicas while writes go to the primary and the cluster volume.

​
Provisioned vs Serverless

When you create an Aurora cluster you choose between two provisioning models. Pick the model that best fits workload predictability, scaling needs, and operational constraints.
If you need strict, pre-provisioned performance guarantees or specific instance-level configuration (e.g., specific CPU/memory combinations), use provisioned clusters. For flexible, demand-driven workloads with simpler operations, prefer Aurora Serverless v2.
A presentation slide titled "AWS Aurora – Types" showing two options: "Provisioned" (orange) with notes like fixed capacity and useful for planned capacity, and "Serverless" (purple) with notes like on‑demand scaling and useful for variable/unpredictable workloads.

​
Aurora Global Database

Aurora Global Database enables a single logical database to span multiple AWS Regions for low-latency reads and cross-region disaster recovery.
  • One primary DB cluster in the primary region accepts writes.
  • Up to five secondary DB clusters in other regions are read-only.
  • Data replication from primary to secondary clusters is asynchronous using a high-throughput replication channel, providing low-latency global reads and regional resilience.
Each cluster maintains its own cluster volume; secondaries receive replicated changes asynchronously to minimize write latency on the primary region.
A slide titled "Aurora Global Database" shows a faint world map with colored cylinder icons representing a central master database labeled "M" connected by dashed lines to three replica databases labeled "R" in different regions.

​
Aurora Serverless v2 — ACUs explained

Aurora Serverless v2 measures capacity in Aurora Capacity Units (ACUs):
  • 1 ACU ≈ 2 GiB memory (plus proportional CPU and networking).
  • Minimum ACU: 0.5
  • Maximum ACU: 128
When creating a serverless cluster, you provide minimum and maximum ACU limits; Aurora scales the cluster’s capacity automatically within those bounds to match demand.
A presentation slide titled "Aurora Serverless V2" with three colored info boxes about ACU. The boxes state that ACU is the Aurora Capacity Unit, one ACU = 2 GiB of memory (with corresponding CPU and networking), and Min ACU = 0.5 / Max ACU = 128.
Aurora Serverless v1 used a different scaling model and could pause when idle. Serverless v2 is the recommended option for new deployments — it provides faster, fine-grained scaling and broader feature parity with provisioned Aurora.

​
Integrations and ecosystem

Aurora integrates across the AWS ecosystem to support monitoring, security, compute, and analytics:
  • Backups and snapshots — integrated with Amazon S3 for durable storage.
  • Observability — Amazon CloudWatch for metrics and alarms.
  • Secrets and credentials — AWS Secrets Manager for secure credential rotation and retrieval.
  • Compute integrations — AWS Lambda, Amazon ECS, Amazon EKS for application hosting and serverless compute.
  • Analytics & ML — Amazon Redshift, Amazon SageMaker for analytics and machine learning workflows.
A presentation slide titled "Aurora Integration" showing Amazon Aurora (MySQL- and PostgreSQL-compatible) with its key features and benefits. To the right is a column of AWS service icons (e.g., S3, CloudWatch, SageMaker, Lambda, Redshift, EKS) illustrating services Aurora integrates with.

​
Common use cases

  • Modernizing enterprise applications (CRM, ERP, billing) requiring high throughput and reliability.
  • Building SaaS and multi-tenant applications that need flexible scaling and isolation.
  • Serverless-first architectures where hands-off capacity management reduces operational overhead.
  • Globally distributed applications (mobile games, social platforms, global services) that require low-latency local reads and regional resilience.
A presentation slide titled "Aurora – Use Cases" showing four colorful panels labeled: Modernize Enterprise Applications, Build SAAS Applications, Go Serverless, and Globally Distributed Applications, each with a simple icon. The slide appears to be from KodeKloud.

​
Summary — key takeaways

  • Aurora is a fully managed relational database service that handles provisioning, patching, backups, and failover.
  • Its distributed, fault-tolerant storage automatically scales (up to 128 TiB per cluster) and provides high performance and durability.
  • Aurora Global Database spans Regions to enable low-latency global reads and cross‑Region disaster recovery.
  • Aurora Serverless v2 scales capacity automatically using ACUs and is the recommended serverless option for new deployments.
  • Performance: Aurora commonly delivers significantly higher throughput than standard MySQL or PostgreSQL (case-dependent — often cited up to ~5x for MySQL and ~3x for PostgreSQL).
  • High availability and read scaling: up to 15 Aurora Replicas across AZs with fast failover and quick replica attachment to the shared cluster volume.
  • Fast cloning enables rapid creation of database copies for development and testing without duplicating all data.
A presentation slide titled "Summary Aurora" listing three numbered points about Amazon Aurora: improved throughput and sub-10ms read latency versus MySQL/PostgreSQL, support for up to 15 replicas and fast failover, and fast database cloning for testing.
Use these links for deeper dives into architecture, best practices, pricing, and configuration examples.

Watch Video