Cargando...
Cargando...
Stop guessing which Aurora Serverless to use — here's every difference that matters for production and the exam
v1 = coarse cold-start scaling; v2 = fine-grained instant scaling built for production
| Feature | Aurora Serverless v1 Pause-and-resume dev/test workloads | Aurora Serverless v2 Instant fine-grained production scaling |
|---|---|---|
Scaling Granularity v2's fine-grained scaling is a primary exam differentiator. v1 can overshoot capacity dramatically. | Scales in fixed ACU doubling increments (e.g., 1 → 2 → 4 → 8 ACUs). Coarse-grained. | Scales in increments as small as 0.5 ACU. Near-continuous fine-grained scaling. |
Scaling Speed v1 scaling disrupts connections — a critical trap. v2 is transparent to the application. | Scaling takes tens of seconds; connections may be dropped during scale events. | Scales in a fraction of a second without dropping connections. |
Pause / Resume (Scale-to-Zero) CRITICAL TRAP: If the scenario requires scale-to-zero or zero-cost idle, you MUST use v1. v2 always incurs minimum ACU charges. | Supported. Cluster can pause after a configurable idle period and resume on next connection (cold start latency applies). | NOT supported. Minimum capacity is 0.5 ACU — cannot scale to zero. |
Minimum ACU Both share 0.5 ACU minimum, but only v1 can drop to 0 via pause. Do not confuse minimum ACU with actual idle cost. | 0.5 ACU (effectively 0 when paused) | 0.5 ACU (always running; cannot pause) |
Maximum ACU v2 can exceed v1's effective ceiling by adding multiple serverless reader instances — a key architectural advantage. | 256 ACUs (MySQL-compatible); 256 ACUs (PostgreSQL-compatible) | 256 ACUs per instance (and multiple reader instances can be added for higher aggregate capacity) |
Multi-AZ / High Availability v1 cannot have read replicas at all. v2 supports full Aurora HA topology including Global Databases. | Single writer only. No Multi-AZ reader instances. Failover is slower. | Supports Multi-AZ with serverless reader instances. Can mix serverless and provisioned instances in same cluster. |
Read Replicas If a scenario mentions read scaling or read replicas with serverless, the answer is always v2. | Not supported. No read replicas. | Supported. Can add serverless or provisioned read replicas. |
Aurora Global Database Support Cross-region disaster recovery with serverless = v2 only. | Not supported. | Supported. Can be used in Global Database clusters. |
Aurora Parallel Query | Not supported. | Supported (MySQL-compatible). |
RDS Proxy Support Connection pooling via RDS Proxy is v2-only. Important for Lambda-heavy architectures. | Not supported. | Supported. |
Data API (HTTP Endpoint) CRITICAL TRAP: Data API / HTTP endpoint is v1-ONLY. If a scenario uses Lambda without VPC and needs connectionless SQL access, the answer is v1. | Supported. Allows SQL queries over HTTPS without persistent connections — key for Lambda. | NOT supported (as of current documentation). Must use standard DB drivers. |
Supported Engine Versions v1 is on a path to deprecation with limited engine version support. New features land in v2 only. | Limited to older Aurora MySQL and Aurora PostgreSQL engine versions only. | Supports current and recent Aurora MySQL and PostgreSQL engine versions including latest minor versions. |
VPC Requirement Both require VPC. The Data API distinction is what matters for Lambda-without-VPC architectures. | Must be in a VPC. Data API provides an alternative for connectionless access. | Must be in a VPC. Standard VPC connectivity required. |
Pricing Model For truly intermittent workloads (hours of idle per day), v1 can be significantly cheaper due to pause capability. | Per-second billing for ACU consumption. No charge when paused (only storage charged). | Per-second billing for ACU consumption. Minimum 0.5 ACU always billed (no free idle state). |
ACU Definition ACU definition is the same for both versions. This is a common trick — the billing unit is identical. | 1 ACU ≈ 2 GiB memory + proportional CPU and network | 1 ACU ≈ 2 GiB memory + proportional CPU and network |
Workload Suitability The scenario description almost always tells you which to pick. 'Infrequent/idle' = v1; 'variable production' = v2. | Infrequent, intermittent, or unpredictable workloads. Dev/test. Apps that can tolerate cold starts. | Variable production workloads, multi-tenant SaaS, applications requiring instant scaling without disruption. |
Connection Behavior During Scaling Connection dropping in v1 is a frequent exam scenario. Any question about connection stability during scaling = v2. | Connections may be dropped during scaling events. Applications must handle reconnection. | Connections are maintained during scaling. Transparent to the application. |
Mixed Instance Cluster Mixed clusters allow gradual migration from provisioned to serverless — a real-world and exam architecture pattern. | Not supported. Entire cluster must be serverless. | Supported. Can mix serverless v2 instances with provisioned instances in the same cluster. |
Backtrack Support | Not supported. | Supported (MySQL-compatible). |
Performance Insights Observability and monitoring features are v2-only. Important for DOP-C02 operational excellence scenarios. | Not supported. | Supported. |
IAM Database Authentication Security-focused exam questions about passwordless IAM auth with Aurora Serverless = v2. | Not supported. | Supported. |
General Status / Roadmap AWS documentation explicitly positions v2 as the successor. New architecture questions will default to v2 unless pause/Data API is required. | Legacy. AWS recommends migrating to v2. Limited new feature development. | Current generation. Actively developed. AWS recommended path forward. |
Summary
Aurora Serverless v1 serves a narrow but important niche: workloads that are truly intermittent (hours of idle daily) and benefit from scale-to-zero pricing, or applications using the HTTP Data API for connectionless Lambda integration. Aurora Serverless v2 is the production-grade choice for virtually everything else — it offers instant fine-grained scaling, full Aurora HA topology, read replicas, RDS Proxy, and Performance Insights without connection disruption. For DOP-C02, default to v2 unless the scenario explicitly describes infrequent/idle workloads or requires the Data API.
🎯 Decision Tree
If workload is truly intermittent with long idle periods AND cost-at-zero matters → v1 | If Lambda needs connectionless HTTP SQL access (no VPC) → v1 (Data API) | If workload is variable but production-grade → v2 | If read replicas, Multi-AZ, Global Database, RDS Proxy, Performance Insights, or IAM DB auth required → v2 | If connections must not drop during scaling → v2 | If mixing serverless with provisioned instances in one cluster → v2 | If unsure and no idle/Data API signal in scenario → v2
Scale-to-zero / pause = v1 ONLY. If a DOP-C02 scenario describes an infrequent workload where cost during idle periods is a concern and the solution must scale to zero, Aurora Serverless v1 is the only correct answer. v2 always bills a minimum of 0.5 ACU and cannot pause.
Data API (HTTP endpoint) = v1 ONLY. If a scenario involves Lambda functions querying Aurora without a persistent VPC connection or without managing connection pools, the Data API is required — and it only exists in v1. Do not be tricked by answer choices suggesting v2 supports this feature.
Any production HA feature (read replicas, Multi-AZ readers, Global Database, RDS Proxy, Performance Insights, IAM DB auth, Backtrack) = v2 ONLY. v1 supports none of these. In DOP-C02 operational excellence and security scenarios, v2 is almost always the correct serverless Aurora choice.
Connection stability during scaling: v1 drops connections during scale events (applications must handle reconnection logic); v2 scales transparently without dropping connections. Exam scenarios about application resilience during database scaling events favor v2.
Mixed-instance clusters are v2-only. A common DOP-C02 migration scenario involves converting a provisioned Aurora cluster to serverless incrementally — this requires v2, which supports mixing serverless and provisioned instances in the same cluster. v1 requires the entire cluster to be serverless.
The #1 exam trap: Candidates assume Aurora Serverless v2 supports the Data API (HTTP endpoint) because it is the newer, more capable version. It does NOT. The Data API is exclusively a v1 feature. Simultaneously, candidates assume v1 can be used for production workloads requiring read replicas or Multi-AZ — it cannot. Know the two unique v1 advantages (pause/scale-to-zero + Data API) and everything else belongs to v2.
CertAI Tutor · DOP-C02 · 2026-02-22
Services
Comparisons