Reserved Capacity for Databases

Definition: RDS Reserved Instances (RIs) provide a discount (up to 72%) compared to On-Demand pricing in exchange for a 1-year or 3-year commitment to a specific database instance configuration.

Commitment Parameters:

• DB Instance Class: Specific instance type (e.g., db.m5.large, db.r5.xlarge)
• Database Engine: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora
• License Model: License Included or Bring Your Own License (BYOL)
• Region: Reservation applies to a specific AWS Region
• Deployment Type: Single-AZ or Multi-AZ

Key Characteristics:

• Discount applies automatically to matching instances
• Cannot be moved between regions
• Can be modified within the same instance family (size flexibility for supported engines)
• Multi-AZ reservations cost approximately 2x Single-AZ
• Does NOT provide capacity guarantee (unlike EC2 Zonal RIs)
• Can be shared across accounts in AWS Organizations

Purpose: Apply a single reserved instance across multiple smaller instances or a larger instance within the same family

Supported Engines (size flexibility enabled):

• Aurora (MySQL and PostgreSQL)
• MySQL
• PostgreSQL
• MariaDB
• Oracle BYOL

NOT Supported (must match exactly):

• Oracle License Included
• SQL Server (all editions)

How It Works:

• RDS RIs use a normalization factor based on instance size
• Reservation applies across any size within the same instance family and region
• Automatically distributes discount across eligible instances

Normalization Factors (db.r5 family example): | Instance Size | Normalization Factor | |---------------|---------------------| | db.r5.large | 1 | | db.r5.xlarge | 2 | | db.r5.2xlarge | 4 | | db.r5.4xlarge | 8 | | db.r5.8xlarge | 16 | | db.r5.12xlarge | 24 | | db.r5.16xlarge | 32 | | db.r5.24xlarge | 48 |

Example: One db.r5.2xlarge RI (factor 4) can cover:

• 1x db.r5.2xlarge, OR
• 2x db.r5.xlarge, OR
• 4x db.r5.large, OR
• 1x db.r5.xlarge + 2x db.r5.large

Typical Discount Ranges (varies by instance type and engine):

| Term | Payment Option | Discount vs On-Demand | |------|----------------|----------------------| | 1 Year | No Upfront | ~18-31% | | 1 Year | Partial Upfront | ~31-37% | | 1 Year | All Upfront | ~33-42% | | 3 Year | No Upfront | ~40-44% | | 3 Year | Partial Upfront | ~58-64% | | 3 Year | All Upfront | ~60-72% |

Factors Affecting Discount:

• Instance family (newer families may have different discounts)
• Database engine (Oracle and SQL Server typically have different pricing)
• Region (pricing varies by region)
• Deployment type (Single-AZ vs Multi-AZ)

Multi-AZ Considerations:

• Multi-AZ RIs cost ~2x Single-AZ RIs
• Multi-AZ discount percentages are similar to Single-AZ
• Reserve Multi-AZ if running Multi-AZ deployments
• For size-flexible engines, Multi-AZ RIs can flex within Multi-AZ deployments

Definition: ElastiCache Reserved Nodes provide significant discounts (up to 55%) for Redis or Memcached clusters in exchange for a 1-year or 3-year commitment.

Commitment Parameters:

• Cache Node Type: Specific node type (e.g., cache.m5.large, cache.r5.xlarge)
• Cache Engine: Redis or Memcached
• Region: Reservation applies to a specific AWS Region
• Node Count: Number of nodes to reserve

Key Characteristics:

• Applies to matching nodes in any cluster within the region
• Does NOT support size flexibility (unlike RDS)
• Cannot be modified after purchase
• Must match engine type exactly
• Applies to both primary and replica nodes
• Applies automatically to matching On-Demand nodes

Typical Discount Ranges:

| Term | Payment Option | Discount vs On-Demand | |------|----------------|----------------------| | 1 Year | No Upfront | ~25-30% | | 1 Year | Partial Upfront | ~38-42% | | 1 Year | All Upfront | ~40-45% | | 3 Year | No Upfront | N/A (not available) | | 3 Year | Partial Upfront | ~50-53% | | 3 Year | All Upfront | ~53-55% |

Important Notes:

• 3-Year No Upfront is NOT available for ElastiCache
• Redis and Memcached have similar discount structures
• Reserved nodes apply automatically to matching on-demand nodes
• Must reserve nodes for BOTH primary and replica nodes

Cluster Mode Considerations (Redis):

• Cluster mode enabled: Reserve nodes for all shards and replicas
• Cluster mode disabled: Reserve primary + replica nodes
• Plan total node count carefully before purchasing

Strategy: Analyze cluster configuration and reserve for stable node count

Planning Steps:

1. Document all ElastiCache clusters and their configurations
2. Identify node types and counts (primary + replicas per cluster)
3. Analyze usage patterns - is node count stable?
4. Reserve for minimum consistent node configuration
5. Use On-Demand for scaling headroom or planned growth

Example Calculation:

• Redis cluster: 3 shards, 2 replicas per shard
• Total nodes: 3 (primary) + 6 (replica) = 9 nodes
• If using cache.r5.large across all nodes
• Reserve: 9x cache.r5.large reserved nodes

Reserved Node Application:

• ElastiCache automatically applies reservations
• Matches by region, engine, and node type (exact match)
• No action needed after purchase
• Reservations shared across accounts if enabled in Organizations

Definition: DynamoDB Reserved Capacity provides significant discounts (up to 77%) on provisioned throughput capacity in exchange for a 1-year or 3-year commitment.

Commitment Parameters:

• Read Capacity Units (RCUs): Minimum 100 RCUs per reservation
• Write Capacity Units (WCUs): Minimum 100 WCUs per reservation
• Region: Reservation applies to a specific AWS Region

Key Characteristics:

• Applies ONLY to Provisioned capacity mode (NOT On-Demand)
• Purchased separately for RCUs and WCUs
• Can purchase multiple reservations to increase coverage
• Applies automatically to provisioned capacity usage in region
• Does NOT apply to Global Secondary Index (GSI) capacity automatically
• No size flexibility - use-it-or-lose-it model

Important Limitations:

• Minimum purchase: 100 RCUs or 100 WCUs per reservation
• Cannot apply to On-Demand (PAY_PER_REQUEST) tables
• Cannot transfer between regions
• GSI capacity must be considered separately
• Does not cover storage costs

Discount Levels (approximate):

| Term | Payment Option | Discount vs Provisioned On-Demand | |------|----------------|----------------------------------| | 1 Year | No Upfront | ~25% | | 1 Year | Partial Upfront | ~42% | | 1 Year | All Upfront | ~54% | | 3 Year | No Upfront | ~53% | | 3 Year | Partial Upfront | ~75% | | 3 Year | All Upfront | ~77% |

Cost Comparison Example (1000 WCUs, us-east-1):

• Provisioned On-Demand: ~$470/month
• 1-Year All Upfront Reserved: ~$216/month effective
• 3-Year All Upfront Reserved: ~$108/month effective

GSI Considerations:

• GSI capacity is billed separately from base table
• Reserved capacity covers total provisioned capacity in region
• Applies across all tables and GSIs using provisioned mode
• Plan total regional capacity needs including GSIs

Hybrid Approach: Combine reserved capacity with auto-scaling

Planning Steps:

1. Analyze 30+ days of CloudWatch metrics for all tables
2. Sum baseline (minimum consistent) capacity across tables/GSIs
3. Reserve 70-80% of total baseline capacity
4. Configure auto-scaling for capacity above reserved
5. Review quarterly and adjust reservations

Example Architecture:

• Table 1: 300 WCUs baseline, peaks to 800
• Table 2: 200 WCUs baseline, peaks to 500
• Total baseline: 500 WCUs
• Reserved: 400 WCUs (80% of baseline)
• Auto-scaling handles peaks up to combined 1500 WCUs

When NOT to Use Reserved Capacity:

• Unpredictable or highly variable workloads
• New applications without usage history
• Tables using On-Demand capacity mode
• Short-term or temporary tables
• Workloads being migrated to serverless

Characteristics:

• Lower commitment risk
• Easier to adapt to changing needs
• Lower discount than 3-year (typically 15-25% less savings)
• Annual review opportunity to adjust

Best For:

• Growing or evolving workloads
• New applications (after initial 30+ day usage analysis)
• Organizations uncertain about long-term needs
• First-time reserved capacity users
• Workloads with potential technology changes

Discount Range Comparison: | Service | 1-Year All Upfront | 3-Year All Upfront | |---------|-------------------|-------------------| | RDS (open-source) | 33-42% | 60-72% | | RDS (commercial) | 27-37% | 40-60% | | ElastiCache | 40-45% | 53-55% | | DynamoDB | ~54% | ~77% |

Characteristics:

• Maximum discount potential
• Higher commitment risk
• Significant savings for stable workloads
• Less flexibility for changes

Best For:

• Production workloads with 3+ years projected lifespan
• Stable, predictable capacity requirements
• Organizations with strong forecasting capabilities
• Cost optimization as primary goal
• Workloads with low likelihood of technology change

Risk Considerations:

• Technology changes may make instance types obsolete
• Business needs may change significantly
• No ability to modify, cancel, or sell
• Unused capacity is fully paid regardless of utilization
• Database engine migrations not supported

All Upfront:

• Requires significant capital outlay
• Maximum discount (up to additional 10-15% over No Upfront)
• Best for: Organizations with available budget prioritizing lowest TCO
• Consider: Opportunity cost of capital

Partial Upfront:

• Balance of discount and cash flow
• Typically ~half the savings between No Upfront and All Upfront
• Best for: Organizations wanting savings without full upfront investment
• Most popular option for large enterprises

No Upfront:

• Minimal initial investment required
• Still provides meaningful discount (25-55% depending on service)
• Best for: Startups, organizations with cash flow constraints
• Lower risk if needs change unexpectedly

Decision Framework:

1. Calculate total cost over term for each option
2. Compare to available capital and budget cycles
3. Consider opportunity cost of upfront payment
4. Factor in risk of unused capacity
5. Evaluate finance team preferences