Reliability pillar principles in AWS - Time & Space Complexity
We want to understand how the time to keep a system reliable changes as the system grows.
How does adding more parts affect the work to keep everything running smoothly?
Analyze the time complexity of monitoring and recovering multiple AWS resources.
// Pseudocode for monitoring and recovery
for each resource in resources:
check health status
if unhealthy:
trigger recovery action
log status
This sequence checks each resource's health and recovers it if needed.
Look at what repeats as the system grows.
- Primary operation: Health check API call for each resource
- How many times: Once per resource
- Secondary operation: Recovery action if needed, also per resource but only when unhealthy
As you add more resources, the number of health checks grows directly with the number of resources.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 health checks |
| 100 | 100 health checks |
| 1000 | 1000 health checks |
Pattern observation: The work grows in a straight line as you add more resources.
Time Complexity: O(n)
This means the time to monitor and recover grows directly with the number of resources.
[X] Wrong: "Adding more resources won't affect monitoring time much because checks are fast."
[OK] Correct: Each resource adds a check, so total time adds up linearly, not staying the same.
Understanding how monitoring scales helps you design systems that stay reliable as they grow, a key skill in cloud roles.
"What if we grouped resources and checked groups instead of individual resources? How would the time complexity change?"
Practice
Solution
Step 1: Understand the purpose of the Reliability pillar
The Reliability pillar focuses on system uptime and fast recovery from issues.Step 2: Compare options with the pillar's goal
Only To keep systems working well and recover quickly from failures matches the goal of keeping systems working well and recovering quickly.Final Answer:
To keep systems working well and recover quickly from failures -> Option BQuick Check:
Reliability = keep systems working and recover fast [OK]
- Confusing reliability with cost savings
- Thinking reliability is about design or speed only
- Ignoring recovery after failure
Solution
Step 1: Identify monitoring services in AWS
Amazon CloudWatch is designed to monitor resources and send alerts.Step 2: Eliminate unrelated services
Amazon S3 is for storage, Lambda for running code, EC2 for servers, so they don't primarily monitor health.Final Answer:
Amazon CloudWatch -> Option CQuick Check:
Monitoring and alerts = CloudWatch [OK]
- Choosing storage or compute services instead of monitoring
- Confusing Lambda with monitoring
- Not knowing CloudWatch's role
Solution
Step 1: Understand multi-AZ and failover
Using multiple AZs with failover means if one AZ fails, traffic moves to others automatically.Step 2: Analyze each option
The application stops working until the failed AZ is restored is false because failover prevents downtime. The application data is lost permanently is false because data is replicated. The application performance improves in the failed AZ is illogical as failed AZ cannot improve performance.Final Answer:
Traffic automatically shifts to healthy AZs to keep the app running -> Option DQuick Check:
Multi-AZ failover = automatic traffic shift [OK]
- Assuming app stops during AZ failure
- Thinking data is lost without backups
- Believing failed AZ improves performance
Solution
Step 1: Identify the problem with backup reliability
Missed backups reduce reliability and risk data loss.Step 2: Choose a solution that improves detection and response
Adding monitoring and alerts helps detect failures quickly and fix them, improving reliability.Final Answer:
Add monitoring and alerts to detect backup failures immediately -> Option AQuick Check:
Detect failures fast = add monitoring and alerts [OK]
- Ignoring backup failures
- Reducing backup frequency which lowers reliability
- Deleting backups without ensuring new ones exist
Solution
Step 1: Identify key reliability strategies
Reliability requires redundancy (multi-AZ), automated backups, and monitoring with alerts.Step 2: Evaluate each option
Deploy across multiple Availability Zones, automate backups, and enable CloudWatch alarms includes all key strategies. Options A, C, and D lack redundancy, automation, or monitoring, reducing reliability.Final Answer:
Deploy across multiple Availability Zones, automate backups, and enable CloudWatch alarms -> Option AQuick Check:
Multi-AZ + backups + monitoring = high reliability [OK]
- Choosing single AZ or no monitoring
- Ignoring automation and failover
- Relying only on on-premises servers
Ready to prove it?
Pass the test and this pattern moves unknown
