AWS Data Durability and Availability Strategies
Implementing strategies to ensure the durability and availability of data (for example, backups)
AWS Data Durability and Availability Strategies
This study guide focuses on the critical architectural patterns required to ensure that data remains intact (durability) and accessible (availability) within the AWS ecosystem, specifically covering the requirements for the SAA-C03 exam.
Learning Objectives
After studying this guide, you should be able to:
- Distinguish between data durability and data availability.
- Select appropriate storage classes and configurations for Amazon S3, EBS, and EFS to meet durability requirements.
- Implement backup and recovery strategies using Snapshots, AWS Backup, and Point-in-Time Recovery (PITR).
- Design highly available database architectures using RDS Multi-AZ and Aurora.
- Evaluate disaster recovery metrics (RPO and RTO) to choose the correct DR strategy.
Key Terms & Glossary
- Durability: The likelihood that data written to storage can be retrieved in the future (e.g., S3 provides 11 9's of durability).
- Availability: The percentage of time a system or service is online and accessible for use.
- RPO (Recovery Point Objective): The maximum acceptable amount of data loss measured in time (e.g., "We can lose up to 4 hours of data").
- RTO (Recovery Time Objective): The maximum acceptable time to restore the system after a failure.
- Snapshot: A point-in-time, incremental backup of a block storage volume (EBS) stored in Amazon S3.
- Synchronous Replication: Data is written to the primary and secondary locations simultaneously before the write is confirmed (e.g., RDS Multi-AZ).
The "Big Idea"
Data is often the most irreplaceable asset in a cloud architecture. While AWS manages the underlying hardware, the Shared Responsibility Model dictates that the customer is responsible for configuring replication, versioning, and backup schedules. Achieving high durability often involves spreading data across multiple physical locations (Availability Zones or Regions) to mitigate the risk of a single point of failure.
Formula / Concept Box
| Metric | Focus | Measurement |
|---|---|---|
| Durability | Data Integrity | "How likely is the data to be lost?" |
| Availability | System Uptime | "Is the service reachable right now?" |
| RPO | Data Loss | Time between last backup and disaster. |
| RTO | Downtime | Time from disaster to full restoration. |
Hierarchical Outline
- Object Storage (Amazon S3)
- Durability: 99.999999999% (11 9's) across multiple AZs.
- Versioning: Prevents accidental deletion/overwrites by keeping multiple object states.
- Replication: Same-Region (SRR) or Cross-Region (CRR) for geographic redundancy.
- Block Storage (Amazon EBS)
- Local Resilience: Replicated within a single AZ automatically.
- Snapshots: Incremental backups stored in S3 for inter-AZ durability.
- Data Lifecycle Manager (DLM): Automates snapshot creation/retention.
- Database Resilience
- RDS Multi-AZ: Synchronous replication to a standby instance for High Availability (HA).
- Amazon Aurora: Replicates data 6 times across 3 AZs by default.
- DynamoDB: Global Tables for multi-region active-active availability.
Visual Anchors
Disaster Recovery Metrics
RDS Multi-AZ Architecture
\begin{tikzpicture}[node distance=2cm, every node/.style={draw, rectangle, align=center, minimum height=1cm}] \node (app) {Application Server}; \node (primary) [below left of=app, xshift=-1cm] {Primary RDS$AZ-A)}; \node (standby) [below right of=app, xshift=1cm] {Standby RDS$AZ-B)}; \node (s3) [below of=primary, xshift=2cm] {S3 (Snapshots)};
\draw [->, thick] (app) -- (primary) node[midway, left] {Read/Write};
\draw [<->, dashed] (primary) -- (standby) node[midway, above] {Sync Replication};
\draw [->] (primary) -- (s3) node[midway, left] {Backup};
\draw [->, red] (standby) -- (app) node[midway, right] {Failover Path};\end{tikzpicture}
Definition-Example Pairs
- S3 Versioning
- Definition: A means of keeping multiple variants of an object in the same bucket.
- Example: A user accidentally deletes
config.json. With versioning, the admin simply removes the "Delete Marker" to restore the file.
- Point-in-Time Recovery (PITR)
- Definition: A feature allowing restoration of a database to any second within a retention period.
- Example: A bug in a deployment corrupts a DynamoDB table at 2:03 PM. The developer uses PITR to restore the table exactly as it was at 2:02:59 PM.
Worked Examples
Example 1: Selecting a Storage Tier
Scenario: A company needs to store financial records for 7 years. The data must survive the destruction of an entire data center but is rarely accessed.
- Strategy: Use Amazon S3 Glacier Deep Archive.
- Reasoning: It provides 11 9's of durability by storing data across at least 3 AZs (protecting against data center loss) at the lowest cost for long-term archival.
Example 2: Minimizing RTO for a Critical Database
Scenario: A production database must have a recovery time of less than 60 seconds in case of an AZ failure.
- Strategy: Implement RDS Multi-AZ Deployment.
- Reasoning: In Multi-AZ, AWS automatically detects a failure and flips the CNAME record to the standby instance. This failover typically completes in 60-120 seconds, meeting the high-availability requirement.
Checkpoint Questions
- What is the minimum number of Availability Zones S3 Standard uses to store data?
- Which AWS service can automate the creation of EBS snapshots based on a schedule?
- True/False: S3 One Zone-IA provides the same level of durability as S3 Standard.
- How many copies of data does Amazon Aurora maintain across how many AZs?
▶Click to see answers
- Three (3).
- Amazon Data Lifecycle Manager (DLM) or AWS Backup.
- False (It provides the same durability against bit-rot but lower resilience against physical AZ destruction).
- 6 copies across 3 AZs.
[!IMPORTANT] EBS Snapshots are stored in Amazon S3, meaning they benefit from S3's 99.999999999% durability even though the original EBS volume is tied to a single AZ.