The Complete Guide to EC2 Instance Selection for Database Workloads

By the JusDB Team | Database Infrastructure Optimization Series

---

1. Introduction: Why Instance Selection Matters

Choosing the right EC2 instance type for your database is one of the most critical decisions you'll make in your cloud infrastructure strategy. At JusDB, we've analyzed thousands of database deployments and found that improper instance selection is responsible for 40-60% of wasted cloud spending and up to 80% of performance issues.

The stakes are high:

• Cost Impact: Choosing the wrong instance family can cost 3-5× more than necessary
• Performance Impact: Under-provisioned instances cause slow queries, timeouts, and poor user experience
• Scalability Impact: Wrong instance choices limit your ability to scale efficiently
• Operational Impact: Frequent instance changes disrupt operations and increase downtime risk

JusDB Case Study: We recently worked with a SaaS company running their MySQL database on m5.4xlarge instances ($560/month). After analysis, we moved them to r7g.2xlarge instances ($362/month) and saw 35% cost reduction with 40% better query performance. Over 12 months, this saved $2,376 per instance.

This guide will teach you how to make the right instance selection decisions for your database workloads, combining technical specifications with real-world experience from JusDB's database optimization practice.

2. Understanding EC2 Instance Families

AWS offers over 500 different EC2 instance types across multiple families. For database workloads, three families dominate: Memory-Optimized (R-series), General Purpose (M-series), and Storage-Optimized (I-series).

Instance Naming Convention

Before diving deep, let's understand how AWS names instances. An instance name like r7g.2xlarge breaks down as:

• r = Instance family (r = memory-optimized)
• 7 = Generation (higher is newer)
• g = Processor family (g = Graviton, i = Intel, a = AMD)
• 2xlarge = Size (ranges from nano to metal)

The Three Primary Database Instance Families

1. Memory-Optimized (R-Series)

Purpose: Designed for memory-intensive database workloads

Memory-to-vCPU Ratio: 8:1 (8 GB RAM per vCPU)

Best For: OLTP databases, in-memory databases, large caches

Current Generations: R7g (Graviton3), R7i (Intel 4th Gen), R6g (Graviton2), R6i (Intel 3rd Gen)

2. General Purpose (M-Series)

Purpose: Balanced compute, memory, and networking

Memory-to-vCPU Ratio: 4:1 (4 GB RAM per vCPU)

Best For: Small to medium databases, development/test environments

Current Generations: M7g (Graviton3), M7i (Intel 4th Gen), M6g (Graviton2), M6i (Intel 3rd Gen)

3. Storage-Optimized (I-Series)

Purpose: High IOPS and throughput with local NVMe storage

Key Feature: Local SSD storage attached directly to the instance

Best For: NoSQL databases, data warehouses, high-transaction workloads

Current Generations: I4i, I3, I3en

Quick Reference: When to Use Each Family

Instance Family	Use When	Avoid When
R-Series (Memory)	Database is memory-bound, heavy caching, large working set	Database is CPU-bound, small working set
M-Series (General)	Dev/test, small databases, balanced workload	Production, memory-intensive, high IOPS needs
I-Series (Storage)	Need ultra-high IOPS, local storage acceptable	Need data persistence beyond instance lifecycle

JusDB Rule of Thumb: When in doubt for production databases, start with R-series. Memory is almost always the bottleneck in database performance, and R-series provides the best performance-per-dollar for most database workloads.

3. Memory-Optimized Instances (R-Series): The Database Workhorse

Memory-optimized instances are purpose-built for database workloads. With an 8:1 memory-to-vCPU ratio, they provide ample RAM for database caching, query execution, and connection handling.

Why Databases Need Memory

Databases are fundamentally memory-intensive applications because:

• Buffer Pool/Cache: Databases cache frequently accessed data in RAM to avoid disk I/O
• Query Execution: Complex queries require memory for sorting, joining, and aggregation
• Connection Overhead: Each database connection consumes memory
• Index Storage: Keeping indexes in memory dramatically speeds up queries
• Temporary Tables: Many operations create temporary tables in memory

JusDB Insight: We've found that database query performance degrades exponentially when the working set (actively accessed data) exceeds available memory. A database that fits 80% of its working set in RAM will be 10-20× faster than one that fits only 50%.

R7g: Latest Graviton3-Based Instances

R7g instances powered by AWS Graviton3 processors represent the cutting edge of database infrastructure:

Key Specifications:

• Processor: AWS Graviton3 (ARM-based)
• Memory: DDR5 (50% higher bandwidth than DDR4)
• Performance: Up to 25% better than R6g
• Network: Up to 30 Gbps
• EBS Bandwidth: Up to 40 Gbps

Available Sizes and Pricing (US-East-1, On-Demand):

Instance Type	vCPUs	Memory (GB)	Network (Gbps)	Price/Hour	Price/Month
r7g.medium	1	8	Up to 12.5	$0.0504	$36.79
r7g.large	2	16	Up to 12.5	$0.1008	$73.58
r7g.xlarge	4	32	Up to 12.5	$0.2016	$147.17
r7g.2xlarge	8	64	Up to 15	$0.4032	$294.34
r7g.4xlarge	16	128	Up to 15	$0.8064	$588.67
r7g.8xlarge	32	256	15	$1.6128	$1,177.34
r7g.16xlarge	64	512	30	$3.2256	$2,354.69

JusDB Recommendation: R7g instances offer the best price-performance for most open-source database workloads. We've seen 15-25% better performance compared to R6g at the same cost, making them our default choice for new deployments.

R7i: Intel-Based Alternative

For workloads requiring x86 architecture or specific Intel features:

Key Specifications:

• Processor: 4th Gen Intel Xeon Scalable (Sapphire Rapids)
• Memory: DDR5
• Performance: Excellent single-threaded performance
• Compatibility: Best x86 compatibility

R7i Pricing Comparison (r7i.2xlarge vs r7g.2xlarge):

• r7g.2xlarge (Graviton): $0.4032/hour = $294.34/month
• r7i.2xlarge (Intel): $0.5040/hour = $367.92/month
• Price Difference: 25% premium for Intel

When to Choose R7i Over R7g:

• Database software not yet ARM-compatible
• Applications using x86-specific optimizations
• Need for Intel-specific features (AVX-512, etc.)
• Existing x86-optimized queries and stored procedures

R6g and R6i: Previous Generation

Still widely used and cost-effective:

• R6g (Graviton2): About 15% cheaper than R7g, still excellent for most workloads
• R6i (Intel 3rd Gen): Good balance of cost and performance
• Use Case: When you need to optimize costs and don't need the latest performance

JusDB Migration Path: We typically recommend R6g for cost-sensitive workloads and R7g for performance-critical databases. The 15-20% cost difference between R6g and R7g is usually worth it for production databases where performance directly impacts revenue.

4. General Purpose Instances (M-Series): Balanced Database Performance

General Purpose instances provide a 4:1 memory-to-vCPU ratio, making them suitable for smaller databases or workloads where memory isn't the primary constraint.

When to Use M-Series for Databases

M-series instances make sense when:

• Small Databases: Database size under 50 GB with low concurrency
• Development/Test: Non-production environments where cost matters more than performance
• Read-Heavy Workloads: Simple queries with minimal memory requirements
• Microservices Databases: Each service has its own small database
• Budget Constraints: Need database functionality at lower cost

JusDB Warning: We see many teams start with M-series instances for production databases to save money, only to migrate to R-series later when performance issues arise. This migration costs more in engineering time and downtime than the initial savings. For production databases, start with R-series unless you have strong evidence M-series will suffice.

M7g: Latest General Purpose Graviton3

Specifications:

• Memory-to-vCPU: 4:1 ratio
• Processor: AWS Graviton3
• Best For: Application servers with embedded databases, development environments

Pricing Examples (US-East-1, On-Demand):

Instance Type	vCPUs	Memory (GB)	Price/Hour	Price/Month
m7g.large	2	8	$0.0816	$59.57
m7g.xlarge	4	16	$0.1632	$119.14
m7g.2xlarge	8	32	$0.3264	$238.27
m7g.4xlarge	16	64	$0.6528	$476.54

Cost Comparison: M-Series vs R-Series

Let's compare equivalent memory configurations:

To Get 64 GB RAM:

• m7g.4xlarge: 16 vCPUs, 64 GB RAM = $476.54/month
• r7g.2xlarge: 8 vCPUs, 64 GB RAM = $294.34/month
• Difference: R-series is 38% cheaper for the same memory

JusDB Analysis: This is why R-series is almost always better for databases. You get the same memory at lower cost, and you don't pay for excess CPU that databases rarely need. The 4:1 ratio in M-series means you're paying for CPU capacity that sits idle.

Burstable Instances (T-Series): Use with Caution

T-series instances (t3, t4g) offer burstable performance and are the cheapest option, but come with significant caveats for databases:

T-Series Characteristics:

• CPU Credits: Earn credits when idle, spend when busy
• Baseline Performance: Very low (10-40% of vCPU)
• Burst Performance: 100% of vCPU when credits available
• Unlimited Mode: Can burst indefinitely but at premium cost

JusDB Position on T-Series for Databases:

• Never for production: Credit exhaustion causes unpredictable performance
• Development only: Acceptable for personal dev environments
• Monitoring critical: Must watch CPU credit balance
• False economy: Unlimited mode often costs more than M-series

5. Storage-Optimized Instances (I-Series): High IOPS Databases

Storage-optimized instances feature local NVMe SSD storage directly attached to the instance, delivering exceptional IOPS and throughput.

Understanding Instance Store vs EBS

I-series instances come with instance store volumes, which differ fundamentally from EBS:

Feature	Instance Store (I-Series)	EBS (gp3/io2)
Performance	Very High (millions of IOPS)	High (up to 80,000 IOPS)
Latency	Sub-millisecond	Single-digit milliseconds
Persistence	Ephemeral (lost on stop/terminate)	Persistent
Snapshots	Not supported	Supported
Cost	Included with instance	Separate billing
Availability	Single instance only	Independent of instance

I4i: Latest Storage-Optimized Generation

Specifications:

• Storage: NVMe SSD (up to 30 TB per instance)
• IOPS: Up to 2 million random read IOPS
• Throughput: Up to 60 GB/s
• Processor: 3rd Gen Intel Xeon (Ice Lake)
• Memory-to-vCPU: 8:1 (same as R-series)

When to Use I4i Instances:

• NoSQL Databases: Cassandra, MongoDB with local replication
• Time-Series Databases: InfluxDB, TimescaleDB
• Cache Layers: Redis with persistence disabled
• Data Warehouses: Analytics databases where data can be rebuilt
• High-Transaction Systems: Need absolute minimum latency

JusDB Best Practice for I-Series: Always implement application-level replication. Since instance store is ephemeral, you must have multiple replicas across instances. We recommend minimum 3-node clusters with replication factor of 3 for production use.

I4i Pricing (US-East-1):

Instance Type	vCPUs	Memory	Storage	Price/Hour	Price/Month
i4i.large	2	16 GB	468 GB NVMe	$0.1953	$142.57
i4i.xlarge	4	32 GB	937 GB NVMe	$0.3906	$285.14
i4i.2xlarge	8	64 GB	1,875 GB NVMe	$0.7812	$570.28
i4i.4xlarge	16	128 GB	3,750 GB NVMe	$1.5624	$1,140.55

When NOT to Use I-Series

Avoid I-series instances when:

• You need persistent storage (use R-series with EBS instead)
• Your application doesn't support clustering/replication
• You require point-in-time snapshots
• Database size is small (under 500 GB)
• Cost is primary concern (R-series with gp3 is usually cheaper)

6. Key Factors in Database Instance Selection

Choosing the right instance requires analyzing multiple factors. JusDB uses a systematic approach to instance selection:

Factor 1: Working Set Size

The working set is the portion of your database that's actively accessed. This is THE most important factor.

How to Calculate Working Set:

1. Total database size: 500 GB
2. Actively accessed data (hot data): typically 20-40%
3. Working set: 100-200 GB
4. Required RAM: Working set + 30% for overhead = 130-260 GB

JusDB Formula:

Minimum RAM = (Working Set Size × 1.3) + (Max Connections × 10 MB)

Example Calculation:

• Working set: 150 GB
• Max connections: 500
• Minimum RAM = (150 × 1.3) + (500 × 0.01) = 195 + 5 = 200 GB
• Recommended Instance: r7g.8xlarge (256 GB RAM)

Factor 2: IOPS Requirements

Different database workloads have vastly different IOPS needs:

Workload Type	Typical IOPS	Recommended Storage
Development/Test	< 3,000	gp3 baseline
Small Production	3,000 - 10,000	gp3 with provisioned IOPS
Medium OLTP	10,000 - 30,000	gp3 or io2
High OLTP	30,000 - 80,000	io2 or I4i
Extreme OLTP	> 80,000	I4i with NVMe

JusDB Tip: Monitor actual IOPS usage for 1-2 weeks before provisioning. Many databases need far fewer IOPS than developers estimate. We've seen over-provisioned IOPS waste hundreds of dollars monthly.

Factor 3: Network Bandwidth

Database replication, backups, and client connections all consume network bandwidth:

Network Requirements by Use Case:

• Single Instance: 2-5 Gbps sufficient
• Primary-Replica Setup: 10 Gbps for replication lag prevention
• Multi-Region Replication: 15-25 Gbps for cross-region traffic
• High-Concurrency Applications: 25+ Gbps for thousands of connections
• Data Warehouse/Analytics: 50+ Gbps for large data transfers

JusDB Network Monitoring: We use CloudWatch NetworkIn/NetworkOut metrics. If network utilization exceeds 70% consistently, it's time to upgrade to an instance with higher network bandwidth.

Factor 4: CPU Requirements

CPUs matter less for databases than memory, but they're still important:

CPU-Intensive Database Operations:

• Complex query parsing and optimization
• Aggregations and GROUP BY operations
• Index building and maintenance
• Data compression/decompression
• Encryption operations
• JSON/XML parsing

General Guideline: Most databases utilize 30-50% of available CPU under normal load. If you're consistently above 70% CPU, you need more vCPUs or query optimization.

Factor 5: Connection Count

Each database connection consumes memory. High-concurrency applications need careful planning:

Database	Memory Per Connection	Max Connections for 64 GB RAM
PostgreSQL	~10 MB	~2,000
MySQL	~8 MB	~2,500
MongoDB	~1 MB	~20,000
Redis	~100 KB	~100,000

JusDB Best Practice: Always use connection pooling (PgBouncer for PostgreSQL, ProxySQL for MySQL). This reduces memory overhead and improves performance. We've seen 10× reduction in required instance size by implementing proper connection pooling.

7. Database-Specific Instance Recommendations

Different database systems have different resource requirements. Here are JusDB's battle-tested recommendations for popular databases:

PostgreSQL: The Versatile Relational Database

Characteristics:

• Memory Usage: Heavy (shared_buffers, work_mem, maintenance_work_mem)
• CPU Usage: Moderate (efficient query execution)
• I/O Pattern: Random reads/writes

JusDB PostgreSQL Instance Recommendations:

Small Database (< 50 GB):

• Development: m7g.large (2 vCPU, 8 GB) - $59.57/month
• Production: r7g.large (2 vCPU, 16 GB) - $73.58/month
• Rationale: Enough memory for entire database in RAM

Medium Database (50-500 GB):

• Production: r7g.2xlarge (8 vCPU, 64 GB) - $294.34/month
• High-Traffic: r7g.4xlarge (16 vCPU, 128 GB) - $588.67/month
• Configuration: shared_buffers = 25% of RAM, effective_cache_size = 75% of RAM

Large Database (500 GB - 2 TB):

• Production: r7g.8xlarge (32 vCPU, 256 GB) - $1,177.34/month
• Enterprise: r7g.16xlarge (64 vCPU, 512 GB) - $2,354.69/month
• Storage: gp3 with 10,000-20,000 IOPS

JusDB PostgreSQL Success Story: We migrated a SaaS company's 800 GB PostgreSQL database from r6i.8xlarge ($1,344/month) to r7g.8xlarge ($1,177/month). They saved $167/month (12%) while gaining 20% better query performance due to DDR5 memory and Graviton3 optimization.

MySQL: The Popular Web Database

Characteristics:

• Memory Usage: Moderate to High (InnoDB buffer pool dominant)
• CPU Usage: Low to Moderate
• I/O Pattern: Depends on workload (InnoDB vs MyISAM)

JusDB MySQL Instance Recommendations:

Small MySQL (< 100 GB):

• Web Application: r7g.xlarge (4 vCPU, 32 GB) - $147.17/month
• Configuration: innodb_buffer_pool_size = 20-24 GB (70-75% of RAM)

Medium MySQL (100 GB - 1 TB):

• E-commerce/SaaS: r7g.4xlarge (16 vCPU, 128 GB) - $588.67/month
• Configuration: innodb_buffer_pool_size = 96 GB (75% of RAM)
• Storage: gp3 with 15,000 IOPS for high-traffic sites

Large MySQL (1+ TB):

• Enterprise: r7g.8xlarge or r7g.16xlarge
• Alternative: Shard across multiple smaller instances

JusDB MySQL Optimization: MySQL's InnoDB buffer pool benefits enormously from memory. We typically see 2-3× performance improvement when the buffer pool can hold the working set. For a 300 GB database with 150 GB working set, r7g.8xlarge (256 GB RAM) delivers optimal performance.

MongoDB: Document Database for Modern Apps

Characteristics:

• Memory Usage: Very High (WiredTiger cache + connections)
• CPU Usage: Moderate to High (especially for aggregations)
• I/O Pattern: Heavy random I/O

JusDB MongoDB Instance Recommendations:

MongoDB Replica Set Member:

• Small (< 200 GB): r7g.xlarge (4 vCPU, 32 GB) - $147.17/month
• Medium (200 GB - 1 TB): r7g.4xlarge (16 vCPU, 128 GB) - $588.67/month
• Large (1+ TB): r7g.8xlarge (32 vCPU, 256 GB) - $1,177.34/month

High-IOPS MongoDB (NoSQL with heavy writes):

• Option 1: R-series with io2 volumes (30,000+ IOPS)
• Option 2: i4i instances with local NVMe storage
• i4i.4xlarge: 16 vCPU, 128 GB, 3.75 TB NVMe - $1,140.55/month

JusDB MongoDB Architecture: We always deploy MongoDB in 3-node replica sets. For a medium workload, we use 3× r7g.2xlarge instances ($883/month total) rather than 1 large instance. This provides redundancy and allows reads to scale across replicas.

Redis: In-Memory Cache and Database

Characteristics:

• Memory Usage: Extreme (entire dataset in RAM)
• CPU Usage: Low (single-threaded core engine)
• I/O Pattern: Minimal (except persistence operations)

JusDB Redis Instance Recommendations:

Redis Sizing Formula:

Required RAM = (Dataset Size × 1.3) + (Peak Connections × 0.1 MB) + 2 GB overhead

Redis Instance Selection:

• Small Cache (< 16 GB data): r7g.large (2 vCPU, 16 GB) - $73.58/month
• Medium Cache (16-48 GB data): r7g.2xlarge (8 vCPU, 64 GB) - $294.34/month
• Large Cache (48-192 GB data): r7g.8xlarge (32 vCPU, 256 GB) - $1,177.34/month
• Extreme Cache (192+ GB data): r7g.16xlarge (64 vCPU, 512 GB) - $2,354.69/month

JusDB Redis Insight: Redis is memory-bound, not CPU-bound. The single-threaded nature means excess vCPUs go unused. Choose instances based purely on memory requirements. We've run 100 GB Redis instances on r7g.4xlarge (128 GB) with only 15% CPU utilization.

Redis Cluster Considerations:

• For datasets > 200 GB, consider Redis Cluster
• Use multiple smaller instances instead of one large instance
• Example: 6× r7g.4xlarge (768 GB total) vs 1× r7g.metal (1024 GB)
• Benefit: Better fault isolation, horizontal scaling

Cassandra: Distributed NoSQL Database

Characteristics:

• Memory Usage: High (heap + off-heap cache)
• CPU Usage: Moderate to High
• I/O Pattern: Very high writes, sequential reads
• Architecture: Multi-node clusters (minimum 3 nodes)

JusDB Cassandra Instance Recommendations:

Cassandra Node Sizing:

• Small Cluster Node: i4i.xlarge (4 vCPU, 32 GB, 937 GB NVMe) - $285.14/month
• Medium Cluster Node: i4i.2xlarge (8 vCPU, 64 GB, 1.8 TB NVMe) - $570.28/month
• Large Cluster Node: i4i.4xlarge (16 vCPU, 128 GB, 3.75 TB NVMe) - $1,140.55/month

Why I-Series for Cassandra:

• Cassandra has built-in replication (RF=3 typical)
• Local NVMe delivers 10× better write performance than EBS
• SSTable writes benefit from ultra-low latency
• Cost-effective: Storage included with instance

JusDB Cassandra Cluster Example:

• Use Case: Time-series data, 10 TB total dataset
• Configuration: 6-node cluster, RF=3
• Instance: 6× i4i.4xlarge = $6,843.30/month
• Effective Storage: 22.5 TB raw (7.5 TB effective with RF=3)
• Performance: 6M+ IOPS aggregate, sub-millisecond latency

8. Graviton vs Intel: The Processor Decision

One of the most important decisions when selecting instances is choosing between AWS Graviton (ARM) and Intel (x86) processors.

Graviton Advantages

Performance:

• Price-Performance: 40% better than comparable Intel instances
• Memory Bandwidth: DDR5 on Graviton3 vs DDR4 on older Intel
• Energy Efficiency: 60% less power consumption
• Cache: Larger L2 cache improves database performance

Cost:

• 15-20% cheaper than equivalent Intel instances
• Example: r7g.4xlarge ($588.67) vs r7i.4xlarge ($735.84) = 20% savings

Intel Advantages

Compatibility:

• Some commercial databases only support x86
• Legacy applications with x86-specific optimizations
• Certain extensions/libraries only compiled for x86

Features:

• AVX-512 instructions for specific workloads
• Better single-threaded performance in some cases

JusDB Graviton Migration Experience

We've migrated over 5,000 database instances from Intel to Graviton. Here are our findings:

Database Compatibility (as of 2025):

Database	Graviton Support	JusDB Recommendation
PostgreSQL	Excellent (v10+)	Always use Graviton
MySQL	Excellent (v5.7+)	Always use Graviton
MariaDB	Excellent (v10.4+)	Always use Graviton
MongoDB	Excellent (v4.2+)	Always use Graviton
Redis	Excellent (v6.0+)	Always use Graviton
Cassandra	Good (v3.11+)	Use Graviton for new deployments
Elasticsearch	Excellent (v7.9+)	Always use Graviton

Performance Comparison: Real-World Results

PostgreSQL TPC-C Benchmark:

• r7g.4xlarge (Graviton3): 142,000 transactions/sec
• r7i.4xlarge (Intel): 118,000 transactions/sec
• Result: Graviton 20% faster at 20% lower cost

MongoDB YCSB Benchmark:

• r7g.2xlarge: 87,000 ops/sec
• r6i.2xlarge: 73,000 ops/sec
• Result: Graviton 19% faster

JusDB Recommendation: For all open-source databases (PostgreSQL, MySQL, MongoDB, Redis, Cassandra), use Graviton instances. The combination of better performance and lower cost makes this an easy decision. We've seen zero compatibility issues with properly maintained database versions.

Migration Path to Graviton

If you're currently on Intel instances, here's our proven migration approach:

1. Verify Compatibility: Ensure database version supports ARM
2. Test Non-Production First: Migrate dev/test environments
3. Performance Testing: Run benchmark tests comparing performance
4. Staged Migration: Migrate production gradually (replicas first, then primaries)
5. Monitor Closely: Watch performance metrics for 2-4 weeks

JusDB Migration Timeline: Typical timeline is 2-4 weeks for complete migration of a production database cluster. Zero-downtime migration is possible using replication.

9. Cost Analysis and Pricing Strategies

Instance selection isn't just about performance—it's about optimizing the cost-performance ratio.

Pricing Models Compared

On-Demand Pricing

• Cost: Highest (baseline pricing)
• Commitment: None
• Use For: Development, testing, short-term workloads
• Flexibility: Can change instance types anytime

Reserved Instances (1-Year)

• Savings: 30-40% vs On-Demand
• Commitment: 1 year
• Payment Options: All Upfront, Partial Upfront, No Upfront
• Best For: Production databases with predictable usage

Reserved Instances (3-Year)

• Savings: 50-60% vs On-Demand
• Commitment: 3 years
• Best For: Stable, long-term production workloads

Savings Plans

• Savings: Similar to Reserved Instances
• Flexibility: Can change instance families
• Commitment: Dollar amount per hour
• Best For: Organizations with diverse workloads

Real Cost Comparison Example

Let's compare the total cost of ownership for a typical production PostgreSQL database:

Scenario: Medium Production PostgreSQL

• Instance: r7g.4xlarge (16 vCPU, 128 GB)
• Storage: 1 TB gp3 with 10,000 IOPS
• Runtime: 24/7 for 12 months

Pricing Breakdown:

Cost Component	On-Demand	1-Year RI	3-Year RI
Instance (annual)	$7,064	$4,590	$3,531
Storage (1 TB gp3)	$960	$960	$960
Provisioned IOPS	$420	$420	$420
Snapshots (100 GB)	$60	$60	$60
Total Annual Cost	$8,504	$6,030	$4,971
Savings vs On-Demand	-	$2,474 (29%)	$3,533 (42%)

JusDB Recommendation: For production databases, always use Reserved Instances or Savings Plans. The 29-42% savings pay for themselves immediately. We typically recommend 1-year RIs for flexibility, upgrading to 3-year RIs once the workload is stable.

Cost Optimization Strategies

1. Right-Size Regularly

Review instance utilization quarterly:

• If CPU < 40% and Memory < 60% for 30 days → Downsize
• If CPU > 80% or Memory > 85% consistently → Upsize
• JusDB Tip: We've helped clients save 30-40% by right-sizing over-provisioned instances

2. Use Graviton Instances

• 15-20% lower cost than Intel equivalents
• Often better performance as well
• Annual Savings Example: Migrating 10× r6i.4xlarge to r7g.4xlarge saves $13,000/year

3. Leverage Reserved Instances for Stable Workloads

• Production databases almost always run 24/7
• 3-year RIs offer 50%+ savings
• Use Convertible RIs for flexibility to change instance types

4. Separate Dev/Test from Production

• Production: R-series with Reserved Instances
• Dev/Test: M-series or smaller R-series, On-Demand
• Automation: Stop dev/test instances outside business hours (save 65% on dev/test)

5. Optimize Storage Costs

• Use gp3 instead of gp2 (20% cheaper)
• Don't over-provision IOPS (start with baseline 3,000)
• Clean up old snapshots regularly
• Use lifecycle policies for backup retention

10. Real-World Sizing Examples

Let's walk through complete sizing exercises for real-world scenarios:

Example 1: E-Commerce PostgreSQL Database

Requirements:

• Database Size: 400 GB
• Active Data: ~30% (120 GB working set)
• Peak Connections: 500
• Query Pattern: 70% reads, 30% writes
• Peak Load: 5,000 queries/second

JusDB Sizing Calculation:

Memory Requirement:
- Working Set: 120 GB
- Overhead (30%): 36 GB
- Connections (500 × 10 MB): 5 GB
- Total: 161 GB
    
Recommended: r7g.8xlarge (256 GB RAM)
- Provides 60% headroom for growth
- 32 vCPUs handle peak query load
- Cost: $1,177/month On-Demand, $766/month with 1-yr RI
    

Storage Configuration:

• Volume Size: 600 GB (400 GB data + 50% growth)
• Type: gp3
• IOPS: 12,000 provisioned (for write-heavy peaks)
• Throughput: 250 MB/s
• Storage Cost: $48/month + $45/month IOPS = $93/month

Total Monthly Cost:

• Instance (1-yr RI): $766
• Storage: $93
• Snapshots (50 GB): $3
• Total: $862/month

Example 2: MongoDB Replica Set for SaaS Application

Requirements:

• Data Size: 1.2 TB
• Working Set: 300 GB
• Write-Heavy: 60% writes, 40% reads
• High Availability: 3-node replica set
• Peak Load: 10,000 ops/second

JusDB Sizing Calculation:

Per-Node Memory:
- Working Set / 3: 100 GB per node
- WiredTiger Cache (60%): 60 GB
- Overhead: 20 GB
- Connections: 10 GB
- Total per node: 90 GB
    
Recommended: r7g.4xlarge per node (128 GB RAM)
- 3 nodes for replica set
- 16 vCPUs per node handles ops load
- Cost per node: $589/month On-Demand, $383/month with 1-yr RI
    

Cluster Configuration:

• 3× r7g.4xlarge instances
• Storage per node: 600 GB gp3 with 15,000 IOPS
• Monthly cost per node: $383 (instance) + $96 (storage) = $479
• Total cluster cost: $1,437/month

Alternative High-IOPS Option:

• 3× i4i.2xlarge instances with local NVMe storage
• Cost: $570/month per node = $1,710/month total
• Benefit: 10× better IOPS, lower latency
• Trade-off: 19% more expensive, ephemeral storage

Example 3: Redis Cache Cluster

Requirements:

• Cache Size: 80 GB active data
• Peak Connections: 10,000
• Replication: Primary + 2 read replicas
• Eviction Policy: LRU (volatile keys)

JusDB Sizing Calculation:

Memory per Node:
- Dataset: 80 GB
- Overhead (30%): 24 GB
- Connections (10K × 0.1 MB): 1 GB
- System overhead: 2 GB
- Total: 107 GB
    
Recommended: r7g.4xlarge per node (128 GB RAM)
- Primary + 2 replicas = 3 nodes
- Cost per node: $589/month On-Demand, $383/month with 1-yr RI
    

Configuration:

• Primary: r7g.4xlarge - handles all writes
• Replica 1: r7g.4xlarge - read traffic
• Replica 2: r7g.4xlarge - read traffic + backup
• Total cost: 3 × $383 = $1,149/month with 1-yr RI

JusDB Optimization: For read-heavy workloads, consider using smaller instances for replicas. Example: 1× r7g.4xlarge primary + 2× r7g.2xlarge replicas saves $294/month while maintaining read capacity.

Example 4: Cassandra Cluster for Time-Series Data

Requirements:

• Data Volume: 15 TB (5 TB per node with RF=3)
• Write-Heavy: 80% writes (time-series ingestion)
• Retention: 90 days rolling
• Query Pattern: Recent data queries

JusDB Sizing Calculation:

Cluster Design:
- Replication Factor: 3
- Effective Storage: 15 TB / 3 = 5 TB per node
- Node Count: 6 (for even distribution)
- Storage per node: 2.5 TB (5 TB / 2 for growth)
    
Instance Selection:
- High IOPS critical for writes
- Local NVMe preferred
- Recommended: i4i.4xlarge (3.75 TB NVMe, 128 GB RAM)
    

Cluster Configuration:

• 6× i4i.4xlarge instances
• Raw storage: 22.5 TB total
• Effective storage: 7.5 TB with RF=3
• Memory: 768 GB total (128 GB per node)
• Cost per node: $1,141/month
• Total cluster cost: $6,846/month

Performance Expectations:

• Write throughput: 500,000+ writes/second
• Read latency: p99 < 10ms
• IOPS: 6M+ aggregate across cluster

11. Performance Optimization Strategies

Selecting the right instance is just the beginning. JusDB's performance optimization methodology ensures you get maximum value from your instances:

Database Configuration Optimization

PostgreSQL Configuration for R-Series:

# For r7g.4xlarge (128 GB RAM)
shared_buffers = 32GB                # 25% of RAM
effective_cache_size = 96GB          # 75% of RAM
work_mem = 64MB                      # Per operation
maintenance_work_mem = 2GB           # For VACUUM, indexes
max_connections = 500                # Application requirement
random_page_cost = 1.1               # For SSD storage
effective_io_concurrency = 200       # For gp3 SSD
    

MySQL Configuration for R-Series:

# For r7g.4xlarge (128 GB RAM)
innodb_buffer_pool_size = 96G        # 75% of RAM
innodb_buffer_pool_instances = 16    # 1 per 6GB
innodb_log_file_size = 2G            # Larger for write-heavy
innodb_flush_log_at_trx_commit = 2   # Better performance
max_connections = 500
innodb_io_capacity = 2000            # For gp3 SSD
innodb_io_capacity_max = 4000
    

MongoDB Configuration for R-Series:

# For r7g.4xlarge (128 GB RAM)
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 64              # 50% of RAM
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy
net:
  maxIncomingConnections: 5000
  compression:
    compressors: snappy
    

Monitoring and Metrics

JusDB monitors these key metrics for instance health:

CPU Metrics:

• CPUUtilization: Should be 40-70% average
• Alert if: > 80% for 10+ minutes (need more vCPUs)
• Alert if: < 20% for 7 days (over-provisioned)

Memory Metrics:

• MemoryUtilization: Should be 70-85% for databases
• Alert if: > 90% (memory pressure, need upgrade)
• Alert if: < 50% consistently (over-provisioned)

Storage Metrics:

• VolumeReadOps/WriteOps: Actual IOPS usage
• VolumeThroughputPercentage: EBS throughput usage
• VolumeQueueLength: Should be < 1 (if > 5, need more IOPS)

Network Metrics:

• NetworkIn/NetworkOut: Bandwidth usage
• Alert if: Consistently > 70% of instance network capacity

Connection Pooling

Proper connection pooling can reduce instance size requirements by 50-70%:

PostgreSQL - PgBouncer:

• Pool Mode: Transaction mode for most applications
• Pool Size: 25-50 per database
• Max Client Connections: Unlimited (queued)
• Benefit: 500 app connections → 50 database connections
• Memory Savings: ~4.5 GB (450 connections × 10 MB)

MySQL - ProxySQL:

• Max Connections: Set based on backend capacity
• Connection Multiplexing: Enabled
• Query Caching: For read-heavy workloads
• Benefit: Reduces backend connections by 80-90%

JusDB Case Study: A fintech client was running PostgreSQL on r6i.8xlarge (32 vCPU, 256 GB, $1,344/month) with 2,000 direct connections. We implemented PgBouncer, reducing required connections to 200. This allowed downsizing to r7g.4xlarge (16 vCPU, 128 GB, $383/month with RI), saving $961/month (72%) while improving performance.

Query Optimization

Often, query optimization provides better ROI than instance upgrades:

JusDB Query Optimization Checklist:

1. Identify Slow Queries: Use pg_stat_statements (PostgreSQL) or slow query log (MySQL)
2. Add Indexes: 80% of query performance issues are missing indexes
3. Optimize JOINs: Reduce rows early in query execution
4. Use EXPLAIN ANALYZE: Understand query execution plans
5. Avoid SELECT *: Fetch only needed columns
6. Use Prepared Statements: Reduce parsing overhead

Real Example: A single missing index on a 200M row table required upgrading from r7g.2xlarge to r7g.8xlarge ($883/month increase). Adding the index eliminated the need for upgrade, with query time dropping from 45 seconds to 0.3 seconds.

12. Common Mistakes and How to Avoid Them

From JusDB's experience optimizing thousands of database instances, here are the most common mistakes:

Mistake 1: Starting with General Purpose Instances

The Problem: Teams choose M-series to save money, then face performance issues and migrate to R-series anyway.

Why It Happens: Underestimating database memory requirements

The Cost:

• Migration engineering time: 20-40 hours
• Downtime or performance degradation during migration
• Poor user experience in the interim
• Delayed product launches

JusDB Solution: Start with R-series for production. You can always downsize later (easier than upsizing). For a 100 GB database, start with r7g.xlarge ($147/month), not m7g.2xlarge ($238/month with less RAM).

Mistake 2: Over-Provisioning "Just to Be Safe"

The Problem: Running r7g.16xlarge (512 GB RAM) when r7g.8xlarge (256 GB RAM) would suffice, wasting $1,177/month.

Why It Happens: Fear of performance issues, lack of proper monitoring

JusDB Solution: Start conservatively, monitor closely for 2-4 weeks, then right-size. Use CloudWatch alarms for memory > 85% to trigger proactive upgrades.

Mistake 3: Ignoring Graviton Instances

The Problem: Staying on Intel instances out of habit, paying 15-20% more for equivalent or worse performance.

Why It Happens: Fear of ARM compatibility, unfamiliarity with Graviton

The Reality: All major open-source databases fully support Graviton with excellent performance.

JusDB Data: Of 3,000+ database migrations to Graviton, we've encountered zero compatibility issues with PostgreSQL, MySQL, MongoDB, or Redis on current versions.

Mistake 4: Not Using Reserved Instances

The Problem: Running production databases 24/7 on On-Demand pricing, paying 2-3× more than necessary.

Why It Happens: Concerns about commitment, forgetting to purchase RIs

The Math: A production r7g.4xlarge costs $7,064/year On-Demand vs $4,590/year with 1-year RI. That's $2,474 wasted annually per instance.

JusDB Recommendation: Set a calendar reminder to purchase RIs for any instance running > 90 days. Use Convertible RIs for flexibility.

Mistake 5: Using T-Series Burstable Instances for Databases

The Problem: CPU credit exhaustion causes unpredictable performance degradation.

Real Example: Client using t3.2xlarge for PostgreSQL experienced 10× slowdown when credits depleted during end-of-month processing. Emergency migration to r7g.xlarge solved the issue.

JusDB Rule: Never use T-series for production databases, period. The cost savings aren't worth the operational risk.

Mistake 6: Neglecting Connection Pooling

The Problem: Allowing direct connections from application to database, requiring oversized instances to handle connection overhead.

Impact Example:

• Without pooling: 1,000 connections × 10 MB = 10 GB memory wasted
• With pooling: 50 connections × 10 MB = 0.5 GB memory used
• Savings: 9.5 GB RAM = potentially one instance size smaller

JusDB Implementation: We always implement connection pooling. It's a 2-4 hour investment that often saves $200-500/month per database.

Mistake 7: Choosing I-Series Without Understanding Ephemeral Storage

The Problem: Using I-series for databases without proper replication, then losing data when instance stops.

Why It's Dangerous: Instance store is erased when instance stops (not just terminates)

JusDB Safety Requirements for I-Series:

• Minimum 3-node cluster with replication
• Application-level data replication configured
• Regular backups to S3 or EBS snapshots
• Tested disaster recovery procedures
• Never use for databases without native replication support

13. Migration and Testing Strategy

When changing instance types, proper testing prevents costly mistakes:

JusDB Migration Methodology

Phase 1: Assessment (Week 1)

1. Current State Analysis:
   • Document current instance types and sizes
   • Collect 30 days of performance metrics
   • Identify peak usage patterns
   • Calculate current costs
2. Requirements Gathering:
   • Database size and growth rate
   • Connection count requirements
   • Query patterns and complexity
   • Performance SLAs
3. Target Instance Selection:
   • Calculate required memory, CPU, IOPS
   • Select appropriate instance family and size
   • Estimate cost savings
   • Create migration plan

Phase 2: Testing (Week 2-3)

1. Non-Production Testing:
   • Migrate dev/test environment first
   • Run application test suites
   • Verify functionality and compatibility
   • Measure performance baseline
2. Performance Testing:
   • Load testing with production-like traffic
   • Stress testing to find limits
   • Benchmark queries and transactions
   • Compare against current production metrics
3. Validation:
   • Confirm performance meets or exceeds current
   • Verify cost savings match projections
   • Document any configuration changes needed
   • Get stakeholder approval to proceed

Phase 3: Production Migration (Week 4)

1. Preparation:
   • Schedule maintenance window
   • Create fresh backups
   • Prepare rollback plan
   • Alert stakeholders
2. Migration Options:
   • Option A - Stop and Change: Stop instance, change type, start (5-10 min downtime)
   • Option B - Replica Promotion: Create replica on new instance, promote to primary (zero downtime)
   • Option C - Blue-Green: Full parallel deployment, DNS switch (zero downtime)
3. Execution:
   • Execute migration during low-traffic period
   • Monitor all metrics closely
   • Run smoke tests immediately after
   • Keep old instance stopped for 24-48 hours (quick rollback)

Phase 4: Post-Migration (Week 5+)

1. Monitoring (48 hours intensive):
   • Watch CPU, memory, IOPS metrics
   • Monitor query performance
   • Check error logs
   • Verify application health
2. Optimization:
   • Tune database configuration for new instance
   • Adjust IOPS if needed
   • Fine-tune connection pools
3. Documentation:
   • Update architecture diagrams
   • Document configuration changes
   • Calculate actual cost savings
   • Share learnings with team

Zero-Downtime Migration: Replica Promotion Method

For PostgreSQL and MySQL, this is JusDB's preferred method:

1. Create Read Replica: Launch replica on target instance type
2. Wait for Sync: Ensure replica is in sync (lag < 1 second)
3. Enable Monitoring: Watch replication lag closely
4. Promote Replica: Stop writes, promote replica to primary
5. Update DNS/Connection Strings: Point applications to new primary
6. Downtime: Typically 30-60 seconds for DNS propagation

JusDB Success Rate: 99.8% of replica promotions complete successfully with < 2 minutes of disruption.

14. Conclusion

Key Takeaways

Selecting the right EC2 instance for your database workload is a critical decision that impacts performance, cost, and operational complexity. Based on JusDB's experience optimizing thousands of database deployments, here are the essential principles:

1. Default to Memory-Optimized (R-Series) for Production

Database performance is primarily memory-bound. The 8:1 memory-to-vCPU ratio in R-series instances provides the best value for database workloads. Don't try to save money with M-series only to migrate later.

2. Choose Graviton Whenever Possible

Graviton instances offer 15-20% cost savings with equal or better performance than Intel alternatives. With full support for PostgreSQL, MySQL, MongoDB, Redis, and other open-source databases, there's no reason to pay the Intel premium.

3. Right-Size Based on Working Set, Not Total Database Size

Use the JusDB formula: Required RAM = (Working Set × 1.3) + (Max Connections × 10 MB) + overhead. Monitor actual usage and adjust accordingly.

4. Always Use Reserved Instances or Savings Plans for Production

Production databases run 24/7. Pay for 1 or 3 years upfront and save 30-60%. The payback period is immediate.

5. Implement Connection Pooling

PgBouncer for PostgreSQL, ProxySQL for MySQL. This single optimization can reduce instance size requirements by 30-50%.

6. Storage-Optimized (I-Series) Requires Special Consideration

Only use I-series when you need ultra-high IOPS and your database supports clustering with replication. Always maintain at least 3 replicas.

7. Never Use T-Series Burstable Instances for Production Databases

The risk of CPU credit exhaustion and unpredictable performance isn't worth the modest cost savings.

8. Test Before Migrating Production

Always test new instance types in dev/test environments first. Measure performance, validate compatibility, and plan for rollback.

JusDB's Recommended Starting Points

Database Size	Database Type	Recommended Instance	Monthly Cost (1-yr RI)
< 50 GB	PostgreSQL/MySQL	r7g.large	$49
50-200 GB	PostgreSQL/MySQL	r7g.xlarge	$98
200-500 GB	PostgreSQL/MySQL	r7g.2xlarge	$196
500 GB - 2 TB	PostgreSQL/MySQL	r7g.4xlarge	$383
2-5 TB	PostgreSQL/MySQL	r7g.8xlarge	$766
Any size	MongoDB Replica Set	3× r7g.2xlarge	$588
Any size	Redis Cache	Based on data size × 1.3	Varies
High IOPS	Cassandra/NoSQL	i4i.2xlarge+	$570+

The Cost of Getting It Wrong

Poor instance selection has real business impact:

• Over-Provisioning: Wastes 30-60% of cloud budget
• Under-Provisioning: Slow queries, timeouts, poor user experience
• Wrong Instance Family: Pay for resources you don't need (CPU when you need RAM)
• No Reserved Instances: Pay 2-3× more than necessary for stable workloads

JusDB's Impact: Across our client base, proper instance selection typically results in:

• 30-50% cost reduction
• 20-40% performance improvement
• 90% reduction in database-related incidents
• Faster query response times
• Better scalability as traffic grows

Final Recommendations

For New Deployments:

1. Start with r7g instances (Graviton3)
2. Size based on working set, not total database size
3. Use gp3 storage with baseline 3,000 IOPS
4. Implement connection pooling from day one
5. Monitor for 2-4 weeks, then right-size
6. Purchase 1-year Reserved Instances once stable

For Existing Deployments:

1. Audit current instance utilization
2. Identify over-provisioned instances (< 40% CPU, < 60% memory)
3. Migrate to Graviton if still on Intel
4. Implement connection pooling if not already done
5. Purchase Reserved Instances for stable workloads
6. Set up automated monitoring and alerting

Getting Expert Help

EC2 instance selection for databases is complex, with hundreds of variables to consider. While this guide provides a solid foundation, every deployment is unique.

JusDB offers comprehensive database infrastructure optimization services:

• Free Assessment: We analyze your current deployment and identify optimization opportunities
• Cost Savings Guarantee: We typically find 30-50% in cost reductions
• Performance Improvements: 20-40% faster query execution on average
• Zero-Downtime Migrations: We handle the entire migration process
• Ongoing Optimization: Quarterly reviews to ensure continued optimal performance

About JusDB

JusDB is a specialized database performance optimization consultancy focused exclusively on cloud database infrastructure. Our team has:

• Optimized over 15,000 database instances across AWS, Azure, and GCP
• Achieved cumulative client savings exceeding $8 million annually
• Maintained 99.8% success rate on zero-downtime migrations
• Expertise across PostgreSQL, MySQL, MongoDB, Redis, Cassandra, and more
• Partnerships with AWS, database vendors, and monitoring tool providers

Our Services Include:

• Instance Right-Sizing: Comprehensive analysis and optimization of EC2 instance types
• Database Performance Tuning: Query optimization, indexing strategy, configuration tuning
• Architecture Review: High-availability design, scaling strategies, disaster recovery
• Cost Optimization: Reserved Instance planning, storage optimization, waste elimination
• Migration Services: Platform migrations, version upgrades, zero-downtime transitions
• 24/7 Monitoring: Proactive alerting, performance tracking, capacity planning
• Training and Enablement: Knowledge transfer to your team

Success Stories

Case Study 1: E-Commerce Platform - 72% Cost Reduction

Challenge: Running 12 PostgreSQL databases on oversized r6i instances with direct connections

Solution:

• Migrated to r7g instances (Graviton3)
• Implemented PgBouncer connection pooling
• Right-sized based on actual working set
• Purchased 3-year Reserved Instances

Results:

• Monthly cost: $16,128 → $4,596 (72% reduction)
• Query performance: 35% improvement
• Annual savings: $138,384
• ROI: Paid for optimization within 2 weeks

Case Study 2: SaaS Platform - MongoDB Performance Breakthrough

Challenge: MongoDB cluster on m5 instances experiencing slow queries and scaling issues

Solution:

• Migrated from 6× m5.4xlarge to 6× r7g.2xlarge
• Optimized WiredTiger cache configuration
• Implemented read preference optimization
• Added connection pooling

Results:

• Monthly cost: $4,032 → $2,352 (42% reduction)
• Query latency: p95 reduced from 450ms to 85ms
• Throughput: 3× increase in operations per second
• Eliminated scaling bottleneck

Case Study 3: Analytics Company - Cassandra on I-Series

Challenge: High-volume time-series data with write bottlenecks on EBS-backed instances

Solution:

• Migrated from 9× r6i.4xlarge with io2 to 9× i4i.2xlarge
• Leveraged local NVMe storage
• Optimized compaction strategy
• Tuned replication settings

Results:

• Write throughput: 5× improvement
• Write latency: p99 from 25ms to 3ms
• Monthly cost: $8,568 → $5,133 (40% reduction)
• Eliminated need for over-provisioned IOPS

Contact JusDB

Ready to optimize your database infrastructure? JusDB offers a free initial assessment where we:

1. Analyze your current EC2 instance usage
2. Review performance metrics and identify bottlenecks
3. Calculate potential cost savings
4. Provide specific instance recommendations
5. Create a risk-free migration plan

Get Started:

• Website: www.jusdb.com
• Email: contact@jusdb.com
• Phone: Schedule a consultation call
• Free Assessment: No obligation, no credit card required

Additional Resources

For more information on database optimization and AWS best practices, check out these resources:

• AWS Documentation: Amazon EC2 Instance Types
• AWS Instance Comparison: EC2 Instance Comparison Tool
• AWS Pricing: Amazon EC2 Pricing
• Graviton Information: AWS Graviton Processors
• Database Best Practices: AWS Well-Architected Framework

Related JusDB Blog Posts

• Amazon EBS gp2 vs gp3: The Complete Cost Analysis
• PostgreSQL Performance Tuning on AWS
• MySQL Configuration Best Practices for EC2
• MongoDB Replica Set Optimization Guide
• Redis Memory Optimization Strategies
• Cassandra on AWS: Architecture and Best Practices

---

Appendix: Quick Reference Tables

Instance Family Quick Reference

Family	Ratio	Best For	Avoid For	Typical Use
R-Series	8:1	Production databases	CPU-intensive apps	OLTP, in-memory DBs
M-Series	4:1	Small DBs, dev/test	Large production DBs	Mixed workloads
I-Series	8:1	High IOPS NoSQL	Single-instance DBs	Cassandra, time-series
T-Series	2:1	Personal dev only	Production (never)	Learning, testing

Database Type to Instance Family Mapping

Database	Primary Choice	Alternative	Avoid
PostgreSQL	R-Series (r7g)	M-Series (small DBs)	T-Series
MySQL	R-Series (r7g)	M-Series (small DBs)	T-Series
MongoDB	R-Series (r7g)	I-Series (high IOPS)	M-Series, T-Series
Redis	R-Series (r7g)	-	M-Series, T-Series
Cassandra	I-Series (i4i)	R-Series (with EBS)	M-Series, T-Series
Elasticsearch	R-Series (r7g)	I-Series (hot nodes)	T-Series

Cost Savings Comparison (r7g vs r7i)

Instance Size	r7g (Graviton)	r7i (Intel)	Monthly Savings	Annual Savings
xlarge	$147	$184	$37 (20%)	$444
2xlarge	$294	$368	$74 (20%)	$888
4xlarge	$589	$736	$147 (20%)	$1,764
8xlarge	$1,177	$1,472	$295 (20%)	$3,540
16xlarge	$2,355	$2,944	$589 (20%)	$7,068

Note: Prices shown are US-East-1 On-Demand rates. 1-year Reserved Instances save additional 30-40%.

Memory Sizing Quick Calculator

Working Set Size	Minimum RAM	Recommended Instance	Cost (1-yr RI)
10 GB	16 GB	r7g.large	$49/month
20 GB	32 GB	r7g.xlarge	$98/month
40 GB	64 GB	r7g.2xlarge	$196/month
80 GB	128 GB	r7g.4xlarge	$383/month
160 GB	256 GB	r7g.8xlarge	$766/month
320 GB	512 GB	r7g.16xlarge	$1,532/month

Formula: Minimum RAM = Working Set × 1.3 + (Max Connections × 10 MB)

---

Author: JusDB Database Optimization Team

Disclaimer: Prices and specifications mentioned in this guide are based on AWS US East (N. Virginia) region as of October 2025. Always refer to official AWS documentation for the most current pricing and specifications in your region. Instance availability and pricing may vary by region.

---