FCJ Workshop for Resilient Architectures: The RDS Workshop (000005) covers Multi-AZ deployments, Read Replicas, and backup strategies essential for resilient database architectures.
This section covers the reliability pillar of the AWS Well-Architected Framework, ensuring workloads perform their intended function correctly and consistently when expected.
Reliability ensures a workload performs its intended function correctly and consistently, with the ability to operate and recover from failures.
| Metric | Definition | Example |
|---|---|---|
| RTO | Recovery Time Objective - Maximum acceptable downtime | 1 hour |
| RPO | Recovery Point Objective - Maximum acceptable data loss | 15 minutes |
| MTBF | Mean Time Between Failures - Average uptime between failures | 720 hours |
| MTTR | Mean Time To Recovery - Average time to restore service | 30 minutes |
| Availability | Percentage of uptime | 99.99% = 52.56 min downtime/year |
| SLA | Downtime per Year | Downtime per Month | Downtime per Week |
|---|---|---|---|
| 99% | 3.65 days | 7.2 hours | 1.68 hours |
| 99.9% | 8.76 hours | 43.8 minutes | 10.1 minutes |
| 99.95% | 4.38 hours | 21.9 minutes | 5.04 minutes |
| 99.99% | 52.56 minutes | 4.32 minutes | 1.01 minutes |
| 99.999% | 5.26 minutes | 25.9 seconds | 6.05 seconds |
This comprehensive section covers all aspects of designing resilient architectures for the FCJ Midterm:
Practice with RDS Workshop: The RDS Workshop (000005) includes hands-on labs for Multi-AZ configuration, failover testing, and Read Replica setup with synchronous vs asynchronous replication concepts.
Amazon RDS Multi-AZ provides high availability with automatic failover using synchronous replication to a standby instance in a different Availability Zone.
Architecture:
Primary AZ (us-east-1a) Standby AZ (us-east-1b)
┌─────────────────────┐ ┌─────────────────────┐
│ Primary RDS │ │ Standby RDS │
│ Read/Write │─────────>│ (Passive) │
│ 10.0.1.100 │Sync Rep │ 10.0.2.100 │
└─────────────────────┘ └─────────────────────┘
↑ ↑
│ │
DNS Endpoint (Automatic
mydb.xyz.rds.amazonaws.com Failover)
Replication:
Failover:
Triggers for Failover:
Important Facts:
| Feature | Multi-AZ | Read Replicas |
|---|---|---|
| Purpose | High Availability | Read Scalability |
| Replication | Synchronous | Asynchronous |
| Standby serves traffic | No | Yes (read-only) |
| Automatic failover | Yes | No (manual promotion) |
| RPO | Zero | Minutes (depends on lag) |
| RTO | 60-120 seconds | Manual promotion time |
| Use case | DR, HA | Read-heavy workloads |
| Cost | ~2x primary | Per replica |
You can use both together: Multi-AZ for HA + Read Replicas for scaling
AWS introduced Multi-AZ DB Clusters with different characteristics:
Replication: Semi-synchronous (not fully synchronous)
Standby Instances: 2 readable standby instances (not passive!)
Failover Time: 25-75 seconds (faster than Multi-AZ instance)
Use Case: Need both HA and read scaling in same deployment
Cost → Increasing →
RTO/RPO → Decreasing →
Complexity → Increasing →
┌────────────┬───────────┬──────────────┬────────────────┐
│ Backup & │ Pilot │ Warm │ Multi-Site │
│ Restore │ Light │ Standby │ Active-Active │
└────────────┴───────────┴──────────────┴────────────────┘
Cheapest Most Expensive
Slowest Fastest Recovery
Description: Back up data to recovery region, restore when needed
Characteristics:
Implementation:
When to Use: Non-critical workloads, cost-sensitive environments
Description: Core infrastructure always running in recovery region, scale up during disaster
Characteristics:
What’s Always Running:
Implementation:
Analogy: Like a pilot light in a furnace - ready to ignite quickly
When to Use: Business-critical apps with moderate RTO/RPO requirements
Description: Scaled-down, fully functional version always running
Characteristics:
What’s Running:
Implementation:
Difference from Pilot Light:
When to Use: Mission-critical apps, moderate budget, need fast recovery
Description: Full production environment in multiple regions, actively serving traffic
Characteristics:
Implementation:
Challenges:
When to Use: Zero-downtime requirements, global user base, highest SLA
| Strategy | RTO | RPO | Cost | When Running | Can Serve Traffic |
|---|---|---|---|---|---|
| Backup & Restore | 24h | Hours | $ | Nothing | No |
| Pilot Light | 10min | Minutes | $$ | Core only | No (needs scaling) |
| Warm Standby | Minutes | Seconds | $$$ | Full stack (scaled down) | Yes (limited) |
| Multi-Site | Near-zero | Near-zero | $$$$ | Full stack | Yes (full capacity) |
Auto Scaling Group (ASG) automatically adjusts EC2 capacity based on demand.
Key Configuration:
Description: Maintain a specific metric at target value
Example:
{
"TargetValue": 70.0,
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
Behavior: AWS automatically creates CloudWatch alarms and adjusts capacity
Predefined Metrics:
When to Use: Most common use case, simple configuration
Description: Scale in steps based on alarm thresholds
Example:
When to Use: Need fine-grained control over scaling behavior
Description: Single adjustment when alarm triggered
Example: CPU > 80% → Add 1 instance
Limitation: Cooldown period before next scaling action
When to Use: Simple, predictable workloads
Description: Scale based on time/date patterns
Example:
When to Use: Predictable traffic patterns
EC2 Metrics (default, 5-minute intervals):
Detailed Monitoring (1-minute intervals): Additional cost
Custom Metrics: Application-specific metrics (e.g., queue length, active users)
| Type | Layer | Use Case | Features |
|---|---|---|---|
| ALB | 7 (HTTP/HTTPS) | Web applications | Path/host routing, WebSocket |
| NLB | 4 (TCP/UDP) | High performance, static IP | Millions of requests/sec |
| GLB | 3 (IP) | Third-party appliances | Transparent network gateway |
| CLB | 4 + 7 (Legacy) | Old applications | Not recommended for new apps |
Features:
Pricing: $0.0225/hour + $0.008 per LCU-hour
Features:
When to Use: Real-time streaming, gaming, IoT, extreme performance
Description: Single resource, no health checks
Use Case: Single web server
Description: Distribute traffic by percentage
Example:
Use Case: A/B testing, gradual rollouts
Description: Route to lowest latency region
Example: Users in Asia → ap-southeast-1, Users in US → us-east-1
Use Case: Global applications, multi-region deployments
Description: Primary/secondary for disaster recovery
Implementation:
Use Case: Active-passive DR
Description: Route based on user’s geographic location
Example: Users in EU → eu-west-1, Users in US → us-east-1
Use Case: Compliance (data residency), localized content
Description: Route based on geographic distance (with bias)
Bias: Adjust routing to prefer certain regions
Use Case: Complex geographic routing requirements
Description: Return multiple IP addresses (with health checks)
Similar to: Simple routing with health checks
Use Case: Simple load distribution
Types:
Interval: 30 seconds (standard) or 10 seconds (fast)
Failover: Automatically remove unhealthy endpoints from DNS responses
AWS Backup provides centralized backup management across AWS services.
Supported Services:
Key Features:
Pricing: