Reading25 min read·Module 4

Aurora Serverless

Key concepts

  • Aurora Serverless v2

  • ACU scaling

  • Cost comparison scenarios

  • Pause compute capability

  • When to use serverless

Overview

Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora that automatically adjusts database capacity based on application demand. With Aurora Serverless v2, you pay only for the capacity you use, making it ideal for applications with variable, unpredictable, or intermittent workloads.

Core Concept

Aurora Serverless v2 provides instant, fine-grained scaling measured in Aurora Capacity Units (ACUs). Each ACU provides approximately 2 GB of memory and corresponding CPU/networking. Capacity scales automatically between your configured minimum and maximum ACUs, scaling in increments of 0.5 ACU in milliseconds. You pay per ACU-hour consumed, making it cost-effective for variable workloads while eliminating capacity planning.

Exam Tip

Exam questions often compare Aurora Serverless vs Provisioned. Key signals: 'unpredictable/variable workload' -> Serverless, 'infrequently used' -> Serverless with scale to 0 (v1), 'consistent 24/7 high load' -> Provisioned with Reserved Instances, 'development/test environments' -> Serverless for cost savings during idle periods.

Key Concepts

Aurora Serverless v2 Architecture

Aurora Serverless v2 Architecture
Figure 1: Aurora Serverless v2 Auto-Scaling Architecture

Aurora Serverless v2 Fundamentals

What is Aurora Serverless v2?

  • On-demand, auto-scaling database configuration
  • Compatible with Aurora MySQL and Aurora PostgreSQL
  • Scales capacity in seconds (not minutes)
  • Supports all Aurora features (Global Database, Multi-AZ, Read Replicas)

Key Improvements over v1: | Feature | v1 | v2 | |---------|----|----| | Scaling Granularity | Doubling (2, 4, 8, 16...) | 0.5 ACU increments | | Scaling Speed | 30 seconds - minutes | Milliseconds | | Scale to Zero | Yes | No (min 0.5 ACU) | | Read Replicas | No | Yes (up to 15) | | Multi-AZ | Limited | Full support | | Global Database | No | Yes |

Architecture Benefits:

  • Scales writer and readers independently
  • Maintains connections during scaling
  • No cold starts (unlike v1)
  • Seamless integration with provisioned instances

Aurora Capacity Units (ACUs)

What is an ACU?

  • Unit of measurement for Aurora Serverless capacity
  • 1 ACU = approximately 2 GB of memory
  • CPU, networking, and memory scale proportionally
  • Fractional ACUs supported (0.5, 1.5, 2.5, etc.)

ACU Specifications: | ACUs | Memory (approx.) | Use Case | |------|------------------|----------| | 0.5 | 1 GB | Minimal workloads | | 1 | 2 GB | Light development | | 2 | 4 GB | Small applications | | 4 | 8 GB | Medium workloads | | 8 | 16 GB | Production apps | | 16 | 32 GB | Large applications | | 128 | 256 GB | Maximum capacity |

ACU Range Configuration:

  • Minimum ACUs: 0.5 to 128
  • Maximum ACUs: 1 to 128
  • Maximum must be >= Minimum
  • Higher minimum = faster scaling response

Scaling Behavior:

  • Scales up instantly when needed
  • Scales down after cooldown period
  • Scaling is transparent to applications
  • No connection drops during scaling
SHAurora Serverless v2 Configuration
# Create Aurora Serverless v2 cluster
aws rds create-db-cluster \
  --db-cluster-identifier my-aurora-serverless \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username admin \
  --master-user-password MySecurePassword123! \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
  --vpc-security-group-ids sg-12345678

# Add Serverless v2 instance to cluster
aws rds create-db-instance \
  --db-instance-identifier my-aurora-serverless-instance \
  --db-instance-class db.serverless \
  --engine aurora-mysql \
  --db-cluster-identifier my-aurora-serverless

# Modify scaling configuration
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-serverless \
  --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=32

# Check current capacity
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=my-aurora-serverless \
  --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Average

ACU Scaling Behavior

ACU Scaling Behavior
Figure 2: How ACUs Scale Based on Workload

Scaling Mechanics

How Scaling Works:

  1. Aurora continuously monitors database workload
  2. Metrics tracked: CPU utilization, connections, memory pressure
  3. When threshold exceeded, capacity scales up instantly
  4. Scale-down occurs after sustained low utilization

Scaling Triggers: | Metric | Scale Up When | Scale Down When | |--------|---------------|-----------------| | CPU Utilization | High sustained usage | Prolonged low usage | | Memory Pressure | Buffer pool pressure | Excess memory available | | Connections | Approaching limits | Far below capacity |

Scaling Speed:

  • Scale-up: Milliseconds to seconds
  • Scale-down: Minutes (after cooldown)
  • No connection interruption
  • No query timeout during scaling

Minimum ACU Strategy:

  • Higher minimum = faster scale-up response
  • Lower minimum = more cost savings at idle
  • Consider baseline workload when setting minimum
  • Trade-off: cost vs responsiveness

Scaling Configuration Strategies

Conservative Configuration (Cost-Optimized):

MinCapacity: 0.5
MaxCapacity: 16
  • Maximum cost savings during idle
  • Slower initial scale-up response
  • Best for dev/test environments

Balanced Configuration:

MinCapacity: 2
MaxCapacity: 32
  • Good baseline for production
  • Quick response to load spikes
  • Moderate idle costs

Performance-Optimized:

MinCapacity: 8
MaxCapacity: 64
  • Instant response to traffic
  • Higher baseline cost
  • Best for latency-sensitive apps

Setting Based on Workload: | Workload Pattern | Recommended Min | Recommended Max | |------------------|-----------------|-----------------| | Sporadic, unpredictable | 0.5-1 | 8-16 | | Business hours only | 2-4 | 16-32 | | Variable with peaks | 4-8 | 32-64 | | Constant high load | Consider Provisioned | - |

SHMonitoring ACU Scaling
# Monitor current serverless capacity
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=my-aurora-serverless \
  --start-time $(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Average Maximum Minimum

# Monitor ACU utilization percentage
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ACUUtilization \
  --dimensions Name=DBClusterIdentifier,Value=my-aurora-serverless \
  --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Average Maximum

# Create CloudWatch alarm for high ACU utilization
aws cloudwatch put-metric-alarm \
  --alarm-name "Aurora-Serverless-High-ACU" \
  --alarm-description "ACU utilization above 80%" \
  --metric-name ACUUtilization \
  --namespace AWS/RDS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=DBClusterIdentifier,Value=my-aurora-serverless \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alerts

# Create alarm for approaching maximum capacity
aws cloudwatch put-metric-alarm \
  --alarm-name "Aurora-Serverless-Near-Max" \
  --alarm-description "Capacity approaching maximum ACUs" \
  --metric-name ServerlessDatabaseCapacity \
  --namespace AWS/RDS \
  --statistic Maximum \
  --period 300 \
  --threshold 14 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=DBClusterIdentifier,Value=my-aurora-serverless \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alerts

Cost Comparison Scenarios

Aurora Serverless vs Provisioned Cost Comparison
Figure 3: Cost Analysis for Different Workload Patterns

Aurora Serverless v2 Pricing

Pricing Model:

  • Pay per ACU-hour consumed
  • Billed per second (minimum 10 minutes)
  • Storage billed separately (same as provisioned Aurora)
  • I/O charges apply (same as provisioned)

Regional Pricing Example (us-east-1): | Component | Price | |-----------|-------| | ACU-hour | ~$0.12/ACU-hour | | Storage | $0.10/GB-month | | I/O Requests | $0.20 per million | | Backup Storage | $0.021/GB-month (beyond free) |

Monthly Cost Calculation:

Monthly Cost = (Average ACUs × Hours × $0.12) + Storage + I/O

Example - Variable Workload:

  • Average 4 ACUs during business hours (10 hrs × 22 days)
  • Average 1 ACU during off-hours (14 hrs × 22 days + weekends)
  • Business hours: 4 × 220 × $0.12 = $105.60
  • Off-hours: 1 × 308 × $0.12 = $36.96
  • Weekend: 1 × 192 × $0.12 = $23.04
  • Total compute: ~$165.60/month

Serverless vs Provisioned Cost Analysis

Cost Comparison Framework:

Scenario 1: Variable Workload (Serverless Wins) | Metric | Provisioned | Serverless v2 | |--------|-------------|---------------| | Instance | db.r6g.large | 0.5-8 ACUs | | Hours used | 730 (24/7) | 730 | | Avg utilization | 30% | Scales to demand | | Monthly compute | ~$175 | ~$88 | | Savings | - | ~50% |

Scenario 2: Consistent High Load (Provisioned Wins) | Metric | Provisioned | Serverless v2 | |--------|-------------|---------------| | Instance | db.r6g.xlarge | 8-16 ACUs | | Hours used | 730 (24/7) | 730 | | Avg utilization | 80% | Avg 8 ACUs | | Monthly compute | ~$350 | ~$700 | | Reserved (1yr) | ~$220 | N/A | | Winner | Provisioned + RI | - |

Scenario 3: Development Environment (Serverless Wins) | Metric | Provisioned | Serverless v2 | |--------|-------------|---------------| | Instance | db.r6g.medium | 0.5-4 ACUs | | Hours active | 200 (business hours) | 200 | | Avg ACUs needed | 2 equiv | 1.5 | | Monthly compute | ~$88 | ~$36 | | Savings | - | ~60% |

Aurora Serverless vs Provisioned Decision Guide

FactorServerless v2ProvisionedWinner
Variable/unpredictable workloadsScales automatically, pay for usePay for provisioned capacity 24/7Serverless
Consistent high utilization (70%+)Higher per-ACU costLower with Reserved InstancesProvisioned
Development/test environmentsScale down during idlePaying even when idleServerless
Infrequent usage (< 10 hrs/day)Pay only when activePay 24/7Serverless
Maximum performance/controlLimited by ACU scalingChoose exact instance typeProvisioned
Read replica scalingIndependent ACU scalingFixed instance sizesServerless
Global DatabaseFully supportedFully supportedTie
Reserved Instance savingsNot availableUp to 69% savingsProvisioned
SHCost Analysis Commands
# Get Aurora Serverless costs from Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --metrics BlendedCost UsageQuantity \
  --filter '{
    "And": [
      {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Relational Database Service"]}},
      {"Dimensions": {"Key": "USAGE_TYPE", "Values": ["Aurora:ServerlessV2Usage"]}}
    ]
  }' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

# Compare ACU usage over time
aws cloudwatch get-metric-data \
  --metric-data-queries '[
    {
      "Id": "capacity",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/RDS",
          "MetricName": "ServerlessDatabaseCapacity",
          "Dimensions": [{"Name": "DBClusterIdentifier", "Value": "my-aurora-serverless"}]
        },
        "Period": 3600,
        "Stat": "Average"
      }
    }
  ]' \
  --start-time $(date -u -v-7d +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

# Estimate monthly costs based on average ACU
# Formula: Average_ACUs × 730_hours × $0.12
echo "Estimated monthly cost for average 4 ACUs:"
echo "4 × 730 × 0.12 = \$350.40"

Pause Compute Capability

Aurora Serverless v1 Pause vs v2 Scaling

Aurora Serverless v1 - Pause Feature:

  • Can scale to 0 ACUs (fully pause)
  • No compute charges when paused
  • Storage charges continue
  • Resume time: 30 seconds to 1 minute

Aurora Serverless v2 - No Pause:

  • Minimum 0.5 ACU (cannot scale to 0)
  • Always incurs some compute cost
  • Instant scaling, no cold start
  • Better for production workloads

v1 Pause Configuration:

SecondsUntilAutoPause: 300-86400 (5 min to 24 hrs)
AutoPause: true/false

Cost Impact of v1 Pause:

  • Idle database: $0 compute (storage only)
  • Resume cost: ~$0.06 (1 ACU for 30 seconds)
  • Best for dev/test that sits idle for hours

Why v2 Doesn't Pause:

  • Designed for production workloads
  • Eliminates cold start latency
  • 0.5 ACU minimum keeps database "warm"
  • Trade-off: small cost vs no latency

Choosing v1 vs v2 for Cost Optimization

Use Aurora Serverless v1 When:

  • Database sits completely idle for hours
  • Can tolerate 30+ second cold start
  • Cost savings outweigh resume latency
  • Simple workloads without read replicas

Use Aurora Serverless v2 When:

  • Need instant response to queries
  • Require read replicas
  • Using Multi-AZ or Global Database
  • Production workloads with variable traffic

Hybrid Strategy:

  • Development/Test: v1 with auto-pause
  • Staging: v2 with low minimum ACUs
  • Production: v2 with appropriate minimums

v1 Pause Best Practices:

  • Set appropriate pause timeout (5-15 minutes)
  • Understand resume latency impact
  • Not suitable for user-facing applications
  • Good for scheduled batch jobs
SHAurora Serverless v1 Auto-Pause Configuration
# Create Aurora Serverless v1 with auto-pause (note: v1 is legacy)
aws rds create-db-cluster \
  --db-cluster-identifier my-aurora-v1-pausable \
  --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.11.2 \
  --engine-mode serverless \
  --scaling-configuration MinCapacity=1,MaxCapacity=16,AutoPause=true,SecondsUntilAutoPause=300 \
  --master-username admin \
  --master-user-password MySecurePassword123!

# Modify auto-pause settings
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-v1-pausable \
  --scaling-configuration AutoPause=true,SecondsUntilAutoPause=600

# Disable auto-pause for production-like testing
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-v1-pausable \
  --scaling-configuration AutoPause=false

# Force resume a paused cluster by connecting
# Or use Data API to wake it up
aws rds-data execute-statement \
  --resource-arn arn:aws:rds:us-east-1:123456789012:cluster:my-aurora-v1-pausable \
  --secret-arn arn:aws:secretsmanager:us-east-1:123456789012:secret:my-db-secret \
  --database mydb \
  --sql "SELECT 1"

When to Use Serverless vs Provisioned

Decision Framework

Choose Aurora Serverless v2 When:

  1. Variable Workloads: Traffic spikes unpredictably
  2. New Applications: Unknown capacity requirements
  3. Multi-Tenant SaaS: Usage varies by tenant
  4. Development/Test: Environments with idle periods
  5. Periodic Reporting: Heavy queries at scheduled times
  6. Microservices: Many small databases with variable loads

Choose Provisioned Aurora When:

  1. Consistent High Load: 70%+ utilization sustained
  2. Predictable Workloads: Capacity needs are known
  3. Cost Optimization: Can leverage Reserved Instances
  4. Maximum Performance: Need specific instance types
  5. Compliance Requirements: Need fixed infrastructure
  6. Budget Predictability: Fixed monthly database costs

Hybrid Approach - Mixed Clusters:

  • Provisioned writer + Serverless v2 readers
  • Handles read scaling with Serverless
  • Fixed cost for write capacity
  • Best of both worlds

Workload Pattern Recommendations

Workload PatternRecommendationReasoning
Morning spike, quiet eveningsServerless v2Scales down during low usage periods
Consistent 24/7 API backendProvisioned + RIReserved Instances provide 40-69% savings
Quarterly financial reportingServerless v2Heavy load only during reports
E-commerce with flash salesServerless v2Handles unpredictable traffic spikes
IoT ingestion - steady streamProvisionedConsistent load benefits from RI
Multi-tenant SaaS platformServerless v2Each tenant database scales independently
Dev/test environmentsServerless v2 or v1v1 can pause, v2 scales to 0.5 ACU
Data warehouse queriesServerless v2Variable analytical query load
SHMixed Cluster Configuration
# Create Aurora cluster with provisioned writer
aws rds create-db-cluster \
  --db-cluster-identifier mixed-aurora-cluster \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username admin \
  --master-user-password MySecurePassword123!

# Add provisioned writer instance
aws rds create-db-instance \
  --db-instance-identifier mixed-cluster-writer \
  --db-instance-class db.r6g.large \
  --engine aurora-mysql \
  --db-cluster-identifier mixed-aurora-cluster

# Add Serverless v2 reader for variable read traffic
aws rds create-db-instance \
  --db-instance-identifier mixed-cluster-reader-serverless \
  --db-instance-class db.serverless \
  --engine aurora-mysql \
  --db-cluster-identifier mixed-aurora-cluster

# Configure Serverless v2 scaling for the cluster
aws rds modify-db-cluster \
  --db-cluster-identifier mixed-aurora-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16

# Add custom endpoint for Serverless readers
aws rds create-db-cluster-endpoint \
  --db-cluster-identifier mixed-aurora-cluster \
  --db-cluster-endpoint-identifier serverless-reader-endpoint \
  --endpoint-type READER \
  --static-members mixed-cluster-reader-serverless

Best Practices

  1. Right-Size ACU Range: Set minimum based on baseline load, maximum based on peak requirements
  2. Monitor ACU Utilization: Track ServerlessDatabaseCapacity and ACUUtilization metrics
  3. Use Mixed Clusters: Combine provisioned writers with Serverless v2 readers for optimal cost/performance
  4. Set Appropriate Minimums: Higher minimum = faster scaling but higher baseline cost
  5. Leverage v1 for Dev/Test: Use auto-pause for truly idle development databases
  6. Configure Alarms: Alert when approaching maximum ACUs to avoid performance issues
  7. Analyze Usage Patterns: Use Cost Explorer to validate Serverless savings vs Provisioned
  8. Consider Reserved Instances: For consistent 70%+ utilization, Provisioned + RI is often cheaper

Common Exam Scenarios

Exam Scenario Decision Guide

ScenarioRecommended SolutionKey Reasoning
Startup with unpredictable traffic growthAurora Serverless v2Scales automatically, no capacity planning needed
Enterprise with known steady database loadProvisioned Aurora + Reserved InstancesUp to 69% savings with RI commitment
Development databases idle 16+ hours/dayAurora Serverless v1 with auto-pauseZero compute cost when paused
SaaS with per-tenant databasesAurora Serverless v2Each tenant scales independently
Read-heavy app with variable read trafficProvisioned writer + Serverless v2 readersFixed write cost, elastic read scaling
Need to minimize database latencyServerless v2 with higher minimum ACUsHigher min prevents scale-up latency
Budget requires predictable monthly costsProvisioned AuroraFixed instance pricing, no variability
Quarterly batch processing jobServerless v2 (or v1 with pause)Scale up for batch, scale down after

Common Pitfalls

Setting Minimum ACUs Too Low for Production

While 0.5 minimum ACUs save costs, production workloads may experience latency during scale-up events. For production systems requiring consistent response times, set minimum ACUs to your typical baseline load (e.g., 2-4 ACUs) rather than the absolute minimum.

Expecting Aurora Serverless v2 to Pause

Unlike v1, Aurora Serverless v2 cannot scale to zero or pause. The minimum is 0.5 ACU, which costs approximately $44/month continuously. If you need zero-cost idle periods, use Serverless v1 (with its limitations) or consider stopping the cluster entirely for extended idle periods.

Using Serverless for Consistent High Utilization

Aurora Serverless has a higher per-ACU cost than equivalent provisioned capacity. For databases running at 70%+ utilization consistently, Provisioned Aurora with Reserved Instances is typically 40-60% cheaper. Always analyze workload patterns before choosing Serverless.

Ignoring Maximum ACU Limits

If your workload exceeds the configured maximum ACUs, performance degrades and queries may timeout. Set maximum ACUs with headroom for unexpected spikes. Monitor the ACUUtilization metric and set alarms at 80% to proactively increase limits.

Forgetting Storage and I/O Costs

ACU costs are only part of Aurora Serverless pricing. Storage ($0.10/GB-month) and I/O requests ($0.20 per million) can add significant costs. A database with high I/O can see I/O costs exceed compute costs. Monitor all cost components, not just ACU hours.

Related Services

Database

Amazon Aurora

High-performance relational database with MySQL and PostgreSQL compatibility

Database

Amazon RDS

Managed relational database service for MySQL, PostgreSQL, SQL Server, Oracle, MariaDB

Cost Management

AWS Cost Explorer

Visualize and analyze Aurora Serverless costs and usage patterns

Monitoring

Amazon CloudWatch

Monitor ACU utilization, capacity, and database performance metrics

Security

AWS Secrets Manager

Rotate database credentials automatically for Aurora Serverless

Migration

AWS Database Migration Service

Migrate existing databases to Aurora Serverless with minimal downtime

Quick Reference

Aurora Serverless v2 Key Numbers

MetricValue
Minimum ACUs0.5
Maximum ACUs128
ACU Increment0.5 ACU
Memory per ACU~2 GB
Scale-up SpeedMilliseconds
Scale-down CooldownMinutes
Max Read Replicas15

Pricing Quick Reference

ComponentApproximate Price
ACU-hour (v2)~$0.12
Storage$0.10/GB-month
I/O Requests$0.20/million
Backup (beyond free)$0.021/GB-month
0.5 ACU running 24/7~$44/month
4 ACU running 24/7~$350/month

v1 vs v2 Feature Comparison

Featurev1v2
Scale to ZeroYesNo (min 0.5)
Scaling Speed30+ secondsMilliseconds
Read ReplicasNoYes (up to 15)
Multi-AZLimitedFull support
Global DatabaseNoYes
Scaling GranularityDoubling0.5 ACU steps

CLI Quick Reference

# Create Serverless v2 cluster
aws rds create-db-cluster \
  --db-cluster-identifier my-cluster \
  --engine aurora-mysql \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16

# Add Serverless v2 instance
aws rds create-db-instance \
  --db-instance-identifier my-instance \
  --db-instance-class db.serverless \
  --engine aurora-mysql \
  --db-cluster-identifier my-cluster

# Modify scaling configuration
aws rds modify-db-cluster \
  --db-cluster-identifier my-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=32

# Check current capacity
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=my-cluster \
  --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 \
  --statistics Average

Cost Optimization Decision Tree

Is utilization > 70% consistently?
├── Yes → Use Provisioned + Reserved Instances
└── No → Is the database idle for hours daily?
    ├── Yes → Can you tolerate 30+ sec cold start?
    │   ├── Yes → Use Serverless v1 with auto-pause
    │   └── No → Use Serverless v2 with low minimum
    └── No → Use Serverless v2 with appropriate ACU range

Test Your Knowledge

Q

A startup is launching a new application with unpredictable traffic patterns. They expect occasional traffic spikes during marketing campaigns but normal usage of only a few hundred concurrent users. The database must respond quickly at all times. Which Aurora configuration is MOST cost-effective?

AAurora Provisioned with db.r6g.xlarge instance
BAurora Serverless v1 with auto-pause enabled
CAurora Serverless v2 with 0.5 minimum and 16 maximum ACUs
DAurora Provisioned with 1-year Reserved Instance commitment
Q

A company has an Aurora database that handles financial reporting. The database sees heavy usage for 2 weeks each quarter during report generation but sits mostly idle the rest of the time. Cold start latency is acceptable. Which configuration provides the LOWEST cost?

AAurora Serverless v2 with 0.5 minimum ACUs
BAurora Serverless v1 with auto-pause enabled
CAurora Provisioned with On-Demand pricing
DAurora Provisioned with 3-year Reserved Instance
Q

An e-commerce company uses Aurora Serverless v2 configured with 1 minimum and 32 maximum ACUs. During a flash sale, the database maxed out at 32 ACUs and queries started timing out. What should the solutions architect recommend?

ASwitch to Aurora Provisioned for better performance
BIncrease the maximum ACUs to 64 or higher
CAdd read replicas to distribute the load
DEnable Multi-AZ for failover capability
Q

A solutions architect is comparing costs for a database that runs at 80% average utilization 24/7. Current usage is equivalent to 8 ACUs sustained. Which option is MOST cost-effective over 3 years?

AAurora Serverless v2 with 8 minimum ACUs
BAurora Provisioned db.r6g.large with On-Demand pricing
CAurora Provisioned db.r6g.large with 3-year Reserved Instance
DAurora Serverless v1 to leverage auto-pause

Further Reading

Related services

Aurora