Cargando...
Cargando...
MySQL & PostgreSQL-compatible, enterprise-grade performance at one-tenth the cost — built for the cloud from the ground up.
Amazon Aurora is a fully managed, cloud-native relational database engine that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. It is compatible with MySQL and PostgreSQL, delivering up to 5x the throughput of standard MySQL and 3x the throughput of standard PostgreSQL. Aurora automatically handles replication, failover, backup, patching, and scaling — separating compute from storage for unprecedented flexibility.
Run high-throughput, highly available relational workloads (MySQL/PostgreSQL-compatible) with automatic failover, self-healing storage, and global reach — without managing database infrastructure.
Use When
Avoid When
MySQL 5.7 / 8.0 compatibility
Drop-in replacement for MySQL with higher performance
PostgreSQL 13 / 14 / 15 / 16 compatibility
Drop-in replacement for PostgreSQL
Aurora Serverless v2
Instant fine-grained auto-scaling; min 0.5 ACU, max 128 ACU
Aurora Serverless v1
Legacy; supports scale-to-zero; coarser scaling; being deprecated for new workloads
Aurora Global Database
Up to 5 secondary regions; sub-second replication; < 1 min RTO failover
Aurora Multi-Master
MySQL-compatible only; multiple write nodes; limited use cases; not recommended for most workloads
Aurora Backtrack
MySQL-compatible only; rewind cluster up to 72 hours without restore
Aurora Fast Clone
Copy-on-write clone; near-instant; ideal for dev/test
Aurora Parallel Query
MySQL-compatible; pushes query processing to storage layer
Aurora Machine Learning (SageMaker / Comprehend)
Call ML models directly from SQL queries
RDS Proxy integration
Connection pooling; reduces Lambda cold-start connection storms
IAM database authentication
Authenticate via IAM tokens instead of passwords; 20 connections/second limit per instance
AWS Secrets Manager integration
Automatic credential rotation without application downtime
Encryption at rest (KMS)
Must be enabled at cluster creation; cannot be enabled post-creation without snapshot restore
Encryption in transit (TLS/SSL)
Supported and recommended for all connections
VPC support
Aurora clusters always run inside a VPC; no public endpoint by default
Cross-region snapshots
Manual snapshots can be copied to other regions for DR
Performance Insights
Database performance monitoring; free tier available; up to 2 years retention with paid tier
Enhanced Monitoring
OS-level metrics at up to 1-second granularity via CloudWatch Logs
Auto-scaling read replicas
Aurora Auto Scaling adds/removes read replicas based on CPU or connections metrics
Zero-ETL integration with Redshift
Near-real-time replication from Aurora to Redshift without ETL pipelines
Babelfish for Aurora PostgreSQL
Allows SQL Server applications to run on Aurora PostgreSQL with minimal code changes
AWS Outposts support (Aurora Serverless)
Aurora Serverless CANNOT run on AWS Outposts — critical exam trap
AWS Outposts support (Aurora provisioned)
Aurora provisioned also does NOT support Outposts; use RDS on Outposts instead
Serverless API Backend with RDS Proxy
high freqLambda functions connect to Aurora via RDS Proxy to pool connections and prevent connection exhaustion. Without RDS Proxy, thousands of concurrent Lambda invocations can overwhelm Aurora's max_connections limit. RDS Proxy also reduces failover time visible to Lambda from minutes to seconds.
Automatic Credential Rotation
high freqSecrets Manager rotates Aurora database credentials automatically on a schedule without application downtime. Aurora integrates natively with Secrets Manager, allowing applications to retrieve current credentials at runtime via the Secrets Manager API rather than hardcoding passwords.
Read-Through / Write-Through Caching
high freqElastiCache (Redis or Memcached) sits in front of Aurora to cache frequently read data, reducing Aurora read replica load and query latency from milliseconds to microseconds. Common for leaderboards, session stores, and product catalog pages.
Polyglot Persistence Architecture
high freqAurora handles relational/transactional data (orders, accounts) while DynamoDB handles high-velocity, simple key-value or document data (sessions, preferences, IoT events). Applications choose the right database for each data access pattern.
Migration Source to Aurora
high freqAWS Database Migration Service (DMS) migrates data from RDS MySQL/PostgreSQL or on-premises databases to Aurora with minimal downtime. Aurora is often the target for lift-and-shift migrations seeking better performance and managed operations.
Application Tier to Managed Database
high freqEC2-based application servers connect to Aurora within the same VPC via the cluster endpoint (writes) and reader endpoint (reads). Security groups restrict database access to only the application tier. This is the classic three-tier web architecture pattern.
Zero-ETL for Operational Analytics
high freqAurora Zero-ETL integration replicates transactional data to Redshift in near-real-time without building ETL pipelines. Enables running analytics on fresh operational data without impacting Aurora performance.
Aurora Database Activity Streams + Event-Driven Processing
high freqAurora Database Activity Streams capture database events in near-real-time to a Kinesis Data Stream, which Lambda can consume to trigger downstream workflows, auditing, or compliance monitoring.
IAM Database Authentication
high freqApplications authenticate to Aurora using short-lived IAM authentication tokens (valid 15 minutes) instead of long-lived passwords. Eliminates credential management risk and integrates with IAM policies for fine-grained access control.
Monitoring and Alerting
high freqCloudWatch receives Aurora metrics (CPU, connections, replica lag, buffer cache hit ratio) and triggers alarms for operational events. Performance Insights provides deeper query-level analysis. Enhanced Monitoring provides OS-level metrics.
Aurora storage is ALWAYS replicated 6 ways across 3 AZs — this is automatic, not a configuration choice. You cannot turn this off or reduce it. This is fundamentally different from RDS Multi-AZ, which is a separate standby instance.
Aurora Serverless (both v1 and v2) CANNOT run on AWS Outposts. If an exam question mentions on-premises data residency requirements with a managed database, the answer is RDS on Outposts — NOT Aurora Serverless.
Aurora Serverless v2 does NOT scale to zero. Only v1 scales to zero ACUs (paused). If the requirement is zero cost when completely idle (dev/test), use Serverless v1 or schedule instance stops. Serverless v2 minimum is 0.5 ACUs.
Aurora Backtrack is MySQL-compatible ONLY — it does NOT work with Aurora PostgreSQL. Backtrack rewinds the cluster in-place (no new cluster created) up to 72 hours. PITR creates a new cluster. Know when to use each: Backtrack for fast recent rewinds; PITR for longer-term recovery.
The Aurora cluster endpoint always points to the current PRIMARY writer. The reader endpoint load-balances across all available read replicas. Use the cluster endpoint for writes, reader endpoint for reads — never hardcode individual instance endpoints in production.
Aurora Serverless CANNOT run on AWS Outposts — for on-premises managed relational databases, the answer is always RDS on Outposts.
Aurora's HA comes from 6-copy shared storage across 3 AZs — NOT a standby instance. Failover promotes a read replica in < 30 seconds because storage is already shared.
Serverless v2 does NOT scale to zero (min 0.5 ACU). Only Serverless v1 scales to zero. Use RDS Proxy with Lambda to prevent connection exhaustion.
Aurora Global Database uses storage-level replication (not binlog) to achieve sub-second cross-region lag. During a regional failover, the secondary can be promoted to primary in under 1 minute with near-zero data loss. This is the recommended pattern for global DR with RPO near zero.
RDS Proxy is the correct answer when exam questions describe Lambda functions causing 'too many connections' errors or database connection exhaustion. RDS Proxy pools connections and is free for Aurora Serverless v2.
Aurora I/O-Optimized pricing eliminates per-I/O charges and is cost-effective when I/O costs exceed ~25% of your total Aurora bill. For read-heavy or write-heavy workloads, this can significantly reduce costs. The trade-off is higher storage pricing.
Aurora Fast Clone uses copy-on-write semantics — the clone is created almost instantly and only diverges storage when data changes. This makes it ideal for spinning up staging/test environments from production without doubling storage costs.
Babelfish for Aurora PostgreSQL allows SQL Server applications (T-SQL, TDS protocol) to run on Aurora PostgreSQL with minimal code changes — it is the correct answer for migrating SQL Server workloads without a full rewrite.
Aurora Auto Scaling for read replicas is based on CloudWatch metrics (CPU utilization or connection count). It adds replicas when demand increases and removes them when demand drops. This is separate from Aurora Serverless compute scaling.
Encryption must be enabled at cluster creation time. You CANNOT enable encryption on an existing unencrypted Aurora cluster. The workaround is: take a snapshot → copy snapshot with encryption enabled → restore from encrypted snapshot.
Aurora Zero-ETL with Redshift is the modern answer for operational analytics without ETL pipelines. If a question asks for near-real-time analytics on transactional Aurora data with minimal operational overhead, Zero-ETL is the correct choice over DMS + S3 + Glue pipelines.
Common Mistake
Aurora Serverless can run on AWS Outposts to meet on-premises data residency requirements.
Correct
Aurora Serverless (both v1 and v2) is a cloud-only service and CANNOT be deployed on AWS Outposts. For on-premises data residency requirements with a managed relational database, the correct answer is RDS on Outposts (supports MySQL, PostgreSQL, SQL Server).
This is the #1 Aurora trap on certification exams. The word 'serverless' implies flexibility, and candidates assume it can run anywhere. Remember: Serverless = AWS-managed infrastructure = cloud-only. Outposts = on-premises AWS hardware = only supports RDS, not Aurora.
Common Mistake
Aurora Multi-AZ works the same way as RDS Multi-AZ — it maintains a synchronous standby instance in another AZ.
Correct
Aurora does NOT use the traditional Multi-AZ standby model. Aurora's high availability comes from its shared storage architecture — 6 copies of data across 3 AZs at all times. Failover promotes an existing read replica to primary (< 30 seconds). RDS Multi-AZ maintains a separate synchronous standby that takes 60-120 seconds to promote.
Candidates confuse the RDS Multi-AZ model with Aurora's architecture. Aurora's HA is fundamentally different — it's storage-level, not instance-level. This matters for failover time questions: Aurora is faster because storage is already shared. The 'Multi-AZ' terminology applies to Aurora's AZ-distributed storage, not a separate standby instance.
Common Mistake
Aurora Serverless v2 scales to zero when there is no traffic, making it the cheapest option for idle dev/test environments.
Correct
Aurora Serverless v2 does NOT scale to zero. Its minimum is 0.5 ACUs, which incurs ongoing cost. Only Aurora Serverless v1 can scale to zero (paused state) after a configurable inactivity period. For truly zero-cost idle environments, use Serverless v1 or schedule instance stops.
AWS heavily markets Serverless v2 as the preferred serverless option, so candidates assume it has all v1 benefits including scale-to-zero. The key difference: v2 trades scale-to-zero for instant, fine-grained scaling (0.5 ACU increments) without cold starts. Know which version to recommend based on requirements.
Common Mistake
EC2-hosted databases provide the same management benefits as Aurora/RDS when you use managed EC2 features like Auto Scaling and CloudWatch.
Correct
EC2-hosted databases require you to manage patching, backups, replication, failover, storage scaling, and engine upgrades yourself. Aurora/RDS handles all of these automatically. EC2 gives you control but at significant operational overhead. The managed benefits of Aurora (automated backups, multi-AZ storage, automatic failover, Performance Insights) are not replicated by EC2 automation alone.
Exam questions present EC2 databases as equivalent to managed services when combined with automation. The key differentiator is that Aurora/RDS provides managed database engine operations (not just infrastructure automation). Choose Aurora/RDS when the question mentions reducing operational overhead, DBA burden, or management complexity.
Common Mistake
Aurora automatically scales compute capacity up and down based on load for all cluster types.
Correct
Automatic compute scaling only applies to Aurora Serverless (v1 and v2). Provisioned Aurora clusters have fixed instance sizes — you must manually change instance class or use Aurora Auto Scaling to add/remove read replicas. Aurora Auto Scaling for replicas is NOT the same as compute scaling — it adds/removes replicas, not resizes them.
Candidates confuse Aurora's automatic storage scaling (which applies to all Aurora clusters) with automatic compute scaling (which only applies to Serverless). Storage always auto-scales; compute only auto-scales in Serverless mode. Aurora Auto Scaling adds replicas but does not resize the primary instance.
Common Mistake
Aurora Backtrack is the same as Point-in-Time Recovery (PITR) and works for both MySQL and PostgreSQL Aurora.
Correct
Backtrack is MySQL-compatible Aurora ONLY and rewinds the existing cluster in-place without creating a new cluster. PITR works for both MySQL and PostgreSQL Aurora but creates a NEW cluster restored to a point in time. Backtrack is faster for recent accidental changes; PITR is more flexible but slower.
Both features address 'oops' scenarios, so candidates conflate them. Remember: B for Backtrack = Back in time in-place (MySQL only). P for PITR = Points to a new cluster (both engines). The in-place vs. new-cluster distinction is critical — Backtrack has no data loss for the rewind period; PITR may lose transactions after the restore point.
Common Mistake
Aurora read replicas work the same as RDS read replicas — each replica has its own copy of the data.
Correct
Aurora read replicas share the SAME underlying storage volume as the primary instance. They do not replicate data — they simply provide additional read endpoints to the same shared storage. This means: replica lag is near-zero (milliseconds), replicas can be promoted to primary almost instantly, and you pay only for compute (not additional storage) for each replica.
This shared-storage architecture is Aurora's core innovation. RDS read replicas use asynchronous binlog replication and have their own storage — replica lag can be seconds to minutes. Aurora's architecture means reads are always consistent and failover is nearly instant. This explains why Aurora supports 15 replicas vs. RDS's 5.
Aurora '6-3-4-3 Rule': 6 copies, across 3 AZs, need 4/6 for WRITES, need 3/6 for READS. Never lose data even if 2 AZs go down.
Aurora endpoints: C=Cluster endpoint (Current primary, writes), R=Reader endpoint (Read replicas, load-balanced). 'C for Commands, R for Reports.'
Serverless versions: v1 = Vintage (old, scale-to-ZERO, coarse); v2 = Very fast (instant, fine-grained, minimum 0.5 ACU, no zero).
Backtrack vs PITR: 'Backtrack = Back in place (MySQL only)'; 'PITR = Produces an Identical Twin Replica (new cluster, both engines)'.
Aurora vs RDS Multi-AZ: Aurora = Always 6 copies in storage (no standby instance); RDS Multi-AZ = Makes a standby instance (synchronous, 1 copy).
Outposts rule: 'Serverless Stays in the Sky' — Aurora Serverless never goes on-premises. RDS on Outposts for on-prem managed databases.
CertAI Tutor · CLF-C02, SAA-C03, SAP-C02, DOP-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons