Cloud Availability: Designing for Production and Non-Production Workloads

This study guide explores the critical task of determining availability requirements for various workload classes, a core skill for the AWS Certified Solutions Architect - Associate (SAA-C03) exam. It focuses on balancing reliability, complexity, and cost.

Learning Objectives

After studying this guide, you should be able to:

• Define and calculate availability using "nines" terminology.
• Differentiate between hard and soft dependencies in a cloud architecture.
• Calculate total system availability for both serial (dependent) and parallel (redundant) components.
• Align availability targets (99% to 99.99%+) with specific workload classes like production, dev/test, and disaster recovery.
• Identify the trade-offs between cost, complexity, and uptime.

Key Terms & Glossary

• Availability: The percentage of time a workload is available for use. It is usually measured annually.
• SLA (Service Level Agreement): A contract from a provider (like AWS) defining the operational uptime goal and the compensation (credits) if that goal is missed.
• Hard Dependency: A component that must be operational for the entire workload to function. If it fails, the system fails.
• Soft Dependency: A component that, if it fails, allows the workload to continue operating, perhaps with degraded performance or reduced features (e.g., a read-replica).
• RTO (Recovery Time Objective): The maximum acceptable delay between the interruption of service and restoration of service.
• RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time (e.g., "we can lose 4 hours of data").

The "Big Idea"

Reliability is the most important requirement in cloud architecture, but it is not free. Every additional "nine" of availability exponentially increases both the cost and the complexity of the system. As an architect, your job is not to build every system to 99.999% availability, but to match the availability target to the business value of the workload. A production payroll system requires significantly more investment in redundancy than a developer's sandbox environment.

Formula / Concept Box

Hierarchical Outline

• I. Classes of Workloads
  • Production Workloads: High business impact; targets 99.9% to 99.99%+. Uses Multi-AZ and automated failover.
  • Non-Production (Dev/Test): Lower impact; targets ~99%. Often uses single instances to save costs.
• II. Dependency Management
  • Serial (Hard) Dependencies: Multiplying availability reduces the total (e.g., $0.99 \times 0.99 = 0.9801$).
  • Parallel (Redundant) Components: Using multiple AZs drastically increases availability.
• III. The Multi-AZ Strategy
  • Compute: Distributing EC2 instances across AZs behind an ALB.
  • Database: Synchronous replication between primary and standby instances in different AZs.
• IV. Measuring Success
  • SLA: AWS's promise of uptime.
  • RTO/RPO: Defining how fast and how much data is recovered during a disaster.

Visual Anchors

The Cost-Availability Trade-off

This diagram illustrates how costs and complexity rise as you move toward higher availability targets.

\begin{tikzpicture}[scale=1] \draw[thick,->] (0,0) -- (6,0) node[right] {Availability (Nines)}; \draw[thick,->] (0,0) -- (0,5) node[above] {Cost / Complexity}; \draw[red, ultra thick] (0.5,0.5) .. controls (4,0.8) and (5,2) .. (5.5,4.5); \node at (1,-0.5) {99% (2)}; \node at (3,-0.5) {99.9% (3)}; \node at (5,-0.5) {99.99% (4)}; \node[anchor=west] at (3.5,3) {\small Exponential Increase}; \end{tikzpicture}

Workload Dependency Logic

Definition-Example Pairs

• 99% Availability (Two Nines): A target where ~3.5 days of downtime per year is acceptable.
  • Example: A non-critical internal employee training portal that is only used during business hours.
• 99.9% Availability (Three Nines): A target where ~9 hours of downtime per year is acceptable.
  • Example: A production application using multiple EC2 instances but a single-instance database that requires manual recovery.
• 99.99% Availability (Four Nines): A target where ~52 minutes of downtime per year is acceptable.
  • Example: A high-traffic e-commerce site using an Application Load Balancer, Multi-AZ EC2 instances, and Multi-AZ Amazon RDS.

Worked Examples

Scenario 1: Calculating Hard Dependencies

Problem: You have a web application on a single EC2 instance (90% availability) connecting to an RDS instance (99.95% availability). What is the total application availability?

Solution:

1. Identify the availabilities: $0.90 and $0.9995.
2. Multiply them: $0.90 \times 0.9995 = 0.89955$.
3. Convert to percentage: 89.96%.
4. Result: This system is down for about 36 days a year—unacceptable for production!

Scenario 2: Calculating Redundancy

Problem: You move the EC2 instances to two separate Availability Zones. Each instance has a 10% failure rate (90% availability). What is the new availability of the compute layer?

Solution:

1. Identify failure rates: $0.10 for each.
2. Multiply failure rates: $0.10 \times 0.10 = 0.01$ (chance both fail simultaneously).
3. Subtract from 100%: $1.00 - 0.01 = 0.99$.
4. Result: 99% availability for the compute layer.

Checkpoint Questions

1. If a system has a "soft dependency" on a read-replica for reporting, does a failure of that replica take the main production site down?
2. Which is higher: the availability of a single EC2 instance or the availability of two EC2 instances in different AZs?
3. An organization requires an RTO of 15 minutes. Does this refer to the amount of data they can lose or the time it takes to get back online?
4. Why does AWS provide service credits instead of guaranteeing 100% uptime?

▶Click to see answers

1. No. Soft dependencies allow the workload to continue (perhaps without reporting features).
2. Two EC2 instances in different AZs (redundancy increases availability).
3. The time it takes to get back online.
4. Because failures are inevitable in distributed systems; SLAs define the financial consequences of those failures, not the impossibility of them.