AWS SAA-C03 Drill: RDS Cost Optimization - The Stop vs. Snapshot Trade-off

While preparing for the AWS SAA-C03, many candidates confuse RDS cost optimization strategies with EC2 patterns. In the real world, this is fundamentally a decision about Compute Billing Models vs. Operational Overhead. Let’s drill into a simulated scenario.

The Scenario

#

BioGenix Labs runs monthly quality assurance validation tests on their pharmaceutical data processing pipeline. The tests execute against a General Purpose (db.m6g.2xlarge) Amazon RDS for MySQL database instance with Performance Insights enabled. Each test cycle runs for exactly 48 hours per month and represents the only workload using this database—the instance sits completely idle for the remaining 672 hours.

The DevOps team has been tasked with reducing testing infrastructure costs while maintaining the exact compute and memory specifications required by the validation scripts (the tests fail with smaller instance types due to memory-intensive stored procedures).

Key Requirements

#

Minimize monthly database costs without reducing compute/memory capacity or impacting the ability to run tests on-demand.

The Options

#

• A) Modify the database instance to a lower-capacity instance class after tests complete, then modify it back to the original size when tests are needed.
• B) Configure an auto-scaling policy for the database instance to scale down compute resources automatically after tests complete.
• C) Create a snapshot after tests complete, terminate the database instance, then restore from snapshot when tests are needed.
• D) Stop the database instance when tests complete, then restart the instance when needed for the next test cycle.

Correct Answer

#

D) Stop the database instance when tests complete, then restart the instance when needed for the next test cycle.

The Architect’s Analysis

#

Correct Answer

#

Option D - Stop the database instance when tests complete, then restart when needed.

Step-by-Step Winning Logic

#

This solution leverages RDS’s stopped instance billing model:

1. Cost Structure: RDS charges are split between:

   • Compute (instance hours) - ~$0.408/hour for db.m6g.2xlarge = ~$294/month if running 24/7
   • Storage (GB-month) - continues billing even when stopped (~$0.115/GB-month for gp3)
   • Performance Insights - continues billing for data retention

2. The Math:

   • Running 24/7: ~$294/month (compute) + storage + PI
   • Stopped 672 hours, running 48 hours: ~$19.60/month (compute) + storage + PI
   • Savings: ~$274/month (~93% reduction in compute costs)

3. Preserves Requirements:

   • ✅ No compute/memory reduction
   • ✅ Maintains endpoint (connection strings unchanged)
   • ✅ Retains Performance Insights history
   • ✅ Automatic patching windows preserved
   • ✅ Simple restart operation (<5 minutes)

4. Operational Simplicity: Single API call (aws rds stop-db-instance) with automatic 7-day restart safeguard.

The Traps (Distractor Analysis)

#

• Why not Option A (Modify Instance Class)?

  • Violates Core Requirement: The question explicitly states “without reducing compute and memory attributes”—modifying to a smaller instance directly contradicts this constraint.
  • Downtime: Instance modification requires reboot (5-10 minutes), similar to restart but with configuration drift risk.
  • Cost Inefficiency: You still pay for compute hours on the smaller instance; stopping eliminates compute costs entirely.

• Why not Option B (Auto-scaling)?

  • Technical Impossibility: RDS does not support auto-scaling of compute (instance class). Aurora Serverless v2 supports scaling ACUs, but standard RDS only supports storage auto-scaling. This is a complete distractor testing knowledge of RDS vs. Aurora capabilities.

• Why not Option C (Snapshot + Terminate)?

  • Operational Overhead: Requires restore operation (15-45 minutes depending on database size), temporary endpoint changes during restore, and manual reconfiguration of parameter groups.
  • Hidden Costs: Snapshot storage costs ($0.095/GB-month) are similar to stopped instance storage, but you lose Performance Insights history and add restore time delays.
  • Use Case Mismatch: Better suited for archival scenarios (months/years), not monthly 48-hour cycles.

The Architect Blueprint

#

Diagram Note: The stopped state eliminates compute billing while preserving database configuration, endpoint stability, and Performance Insights data—restarting requires only 3-5 minutes with no data migration.

Real-World Practitioner Insight

#

Exam Rule

#

“For the SAA-C03 exam, when you see intermittent workloads + preserve instance specifications + RDS cost optimization, always select Stop/Start over snapshot/restore or instance modification.”

Real World

#

In production environments, we would enhance this with:

1. EventBridge + Lambda Automation: Schedule automatic stop/start based on test calendar (avoid manual operations and the 7-day auto-restart limit).
2. CloudWatch Alarms: Alert if instance runs beyond 48-hour window (cost runaway protection).
3. Tagging Strategy: Tag stopped instances with AutoStop:True and MaxStoppedDays:30 for governance.
4. Aurora Serverless v2 Migration Path: For true variable workloads, Aurora Serverless v2 with min/max ACU configuration eliminates manual stop/start while providing sub-second scaling.

The Hidden Constraint: RDS stopped instances automatically restart after 7 days (AWS maintenance requirement). For monthly tests, this works perfectly, but quarterly/annual test cycles would require automation to re-stop instances or alternative architectures.