Wednesday, January 28, 2026

What is Geographic Resiliency ?

Geographic Resiliency

Geographic resiliency (also called geographic redundancy) refers to the practice of deploying applications, databases, and services across multiple geographic locations (regions) to ensure continuous service availability, business continuity, and disaster recovery readiness.

Unlike Multi‑AZ—where resiliency is confined within a single region—geographic resiliency protects against entire region‑level failures, large‑scale disasters, and regulatory boundaries.

What Geographic Redundancy Involves

A foundational geographic redundancy setup typically includes:

Applications, services, or databases deployed in multiple regions
Infrastructure instantiated under multiple subaccounts/subscriptions/projects
Cross‑region replication of:
- Artifacts
- Data
- Events
- State
- Infrastructure definitions
Failover mechanisms at DNS, application, and/or database layers
Monitoring, automation, and governance across dispersed geographic zones

While basic deployments may work with simple cross‑region backups or passive DR sites, true geographic resiliency requires advanced synchronization, failover orchestration, and application‑level design changes.

Benefits of Geographic Resiliency

1. Protection Against Region‑Level Disasters

Region‑wide failures—caused by natural disasters, power grid collapse, or cloud platform outages—cannot be mitigated with Multi‑AZ setups.
Geographic redundancy ensures services remain operational even if an entire region is down.

2. Zero or Near‑Zero Downtime (Depending on Architecture)

Active-active or active‑passive models allow:

Seamless traffic redirection
Automatic database failover (with async/sync replication patterns)
Minimal interruption during failover events

3. Regulatory & Geo‑Local Compliance

Many industries require:

Data to reside within specific countries
Processing to occur in‑region
Disaster recovery to include geographically distant sites

Geo‑redundancy aligns with these mandates.

4. Reduced Latency for Global Users

Serving traffic from the region closest to each user:

Minimizes round‑trip time
Improves performance and responsiveness
Creates globally consistent UX

5. Business Continuity During Major Outages

By eliminating the “region as a single point of failure,” organizations maintain:

SLA commitments
Customer trust
Operational continuity
Disaster survivability

Challenges and Considerations

1. Cross‑Region Database Synchronization Latency

Due to physical distance between regions:

Synchronous replication is rare or impossible
Asynchronous replication introduces RPO > 0
Conflict resolution logic may be required (multi‑write systems)

2. Increased Architectural & Operational Complexity

You must manage:

Two or more parallel deployments
Cross‑region orchestration
Multi‑region CI/CD
Configuration drift prevention
Monitoring/logging across geographies

3. Cost of Duplicate Deployments

Multi‑region often requires:

Multiple active clusters
Extra storage
Additional bandwidth
Redundant monitoring and networking components

Cost optimization becomes a continuous exercise.

4. Application Redesign to Support Statelessness

To function in multiple regions, applications must:

Be stateless, or rely on distributed caching
Avoid local file writes
Handle eventual consistency
Support idempotent operations
Use region‑aware routing and retries

5. Holistic Monitoring Across Regions

Visibility challenges include:

Disparate logs
Distributed traces
Cross‑region health checks
Coordinated alerting
Multi‑region SLO enforcement

A central monitoring strategy is mandatory.

Summary: When to Choose Geographic Resiliency

You should adopt geographic redundancy if:

The workload is mission‑critical
The business requires continuous global availability
You must meet stringent RPO/RTO expectations
You operate in regulated environments (finance, healthcare, government)
Your users are globally distributed
Regional outages are unacceptable

Category	Single‑AZ	Multi‑AZ (Single Region)	Multi‑Region
Availability Level	Low – no AZ fault tolerance	High – survives AZ failure	Very High – survives region failure
Fault Tolerance	Instance‑level only	AZ‑level redundancy	Region‑level redundancy
Data Replication	Local or single‑node	Synchronous across AZs	Async / semi‑sync across regions
RPO	Minutes–hours (backup‑based)	Near‑zero (sync replication)	Seconds–minutes (async replication)
RTO	Hours (manual recovery)	Seconds–minutes (auto failover)	Minutes–hours (regional failover)
Latency Between Nodes	Lowest (same AZ)	Low (inter‑AZ)	Highest (cross‑region)
Service Continuity	Outage if AZ fails	Automatic AZ failover	Continues from secondary region after failover
Compliance & Residency	Basic	Regional compliance	Geo‑residency and DR support
Cost	Lowest	Moderate	Highest
Use Cases	Dev/Test, non‑critical	Business‑critical (HA)	Mission‑critical (full DR)
Strengths	Simple, cost‑effective	High availability, strong consistency	Max resilience & geography‑level protection
Weaknesses	No AZ/Region protection	No region‑level DR	Expensive & operational complexity

What Is Multi‑Region Resiliency Architecture ?

Multi‑Region Resiliency

Enterprises typically begin by strengthening availability within a single region, often through Multi‑AZ deployments for database and application redundancy. While this greatly improves availability, it does not protect against region‑wide failures. The next maturity step is Multi‑Region resiliency—the capability of applications and databases to continue operating even when an entire region becomes unavailable.

A Multi‑Region architecture distributes workloads, data, and infrastructure across geographically distinct cloud regions, providing the highest level of fault tolerance, business continuity, and global performance.

Why Do We Need Multi‑Region Resiliency?

Multi‑Region resiliency protects against large‑scale, catastrophic outages such as:

Natural disasters
Power grid failures
Large‑scale cloud outages
Control‑plane failures
Geo‑specific compliance violations

Beyond disaster recovery, it also provides strategic benefits:

1. Minimizing Downtime & Eliminating Single‑Region Risk

If one region fails, another region continues operations seamlessly—maintaining service continuity and drastically improving RTO/RPO.

2. Compliance & Data Sovereignty

Many regulations mandate that data must remain within certain geographies. Multi‑Region deployments enable:

Region‑specific data residency
Local processing requirements
Geo‑fenced workloads for regulatory compliance

3. Reduced Latency for Global Users

By serving traffic from the geographically closest region, applications achieve:

Faster response times
Better user experience
Region‑aware routing

4. Consistent Global User Experience

Global load balancing ensures that users always connect to the optimal region, providing uniform performance worldwide.

Core Components of a Multi‑Region Architecture

1. Geographic Redundancy

Multi‑Region architectures replicate applications, databases, storage, caches, and services across geographically separated regions.

This ensures:

High fault isolation
Regional disaster recovery
Global performance optimization

2. Global Load Balancing

Global load balancers (e.g., AWS Route 53, Azure Traffic Manager, GCP Cloud Load Balancing) distribute traffic across regions using:

Latency‑based routing (send users to nearest region)
Geo‑location routing (comply with data residency laws)
Health‑based routing (avoid unhealthy regions)
Weighted routing (control traffic distribution)
Custom business‑logic routing

This layer ensures that user traffic is intelligently routed for optimal performance and availability.

3. Data Synchronization Across Regions

Multi‑Region architectures require robust cross‑region data replication to keep databases consistent. Data synchronization solutions include:

✔ Synchronous Replication (rare across regions)

Very low RPO
High network latency
Possible only for extremely close regions

✔ Asynchronous Replication (most common)

Low cross‑region network impact
Minimal RPO (seconds)
High scalability

Custom Multi‑Region Data Sync (Oracle GoldenGate etc.)

Tools like Oracle GoldenGate, Debezium, or cloud‑native replication services can:

Synchronize tables across regions
Handle conflict resolution
Manage cross‑region schema changes
Ensure near real‑time replication

These techniques ensure consistent database state across the globe.

4. Failover Mechanisms

Failover ensures seamless continuity when a region fails.

Types of Failover

Automatic failover: Triggered by health checks
Manual failover: Triggered by administrators

Key Failover Layers

DNS-Level Failover

Global DNS routing
Health‑check‑based DNS updates
Used by Route 53, Traffic Manager, Cloud DNS

Application-Level Failover

Client‑side logic or service mesh detects failures
Redirects API calls to a healthy region

Database-Level Failover

Replica promotion in secondary region
Cross‑region failover of primary databases
Transaction log shipping, GoldenGate, or cloud‑native DR

Failover Policies

Policies must define:

Trigger conditions
RTO/RPO targets
Re‑routing rules
Failback procedures

5. Monitoring & Management

A Multi‑Region architecture requires holistic observability across all regions.

Monitoring Tools

AWS CloudWatch
Azure Monitor
GCP Cloud Operations
Prometheus / Grafana
Datadog, Splunk

Centralized Logging

Use ELK, Splunk, or Fluentd to aggregate logs across regions for:

Auditing
Troubleshooting
Incident response

Automated Alerts

Load balancers and DNS health checks send alerts for:

Regional outages
Latency spikes
Database failover events

Challenges of Multi‑Region Resiliency

1. Data Consistency

Cross‑region latency impacts replication speed
Eventual consistency is often required
Conflict resolution mechanisms are needed

Techniques include:

CRDTs
Paxos / Raft
GoldenGate conflict handlers

2. Increased Operational Complexity

Running multiple regions requires:

Independent deployments
Region‑specific monitoring
More complex CI/CD pipelines
Configuration drift prevention

3. Higher Cost

Costs increase due to:

Duplicate infrastructure
Inter‑region data transfer
More monitoring/logging overhead

Cost management requires:

Autoscaling
Reserved instances
Region‑specific optimizations

4. Application Design Changes

Applications may need:

Stateless architecture
Distributed databases
Event‑driven communication
CQRS
Global session management

What Is Multi‑Region Database Deployment?

Multi‑Region database deployment distributes data across multiple geographically separated regions.

Key Aspects

Data distribution: Data stored in multiple regions
Replication: Continuous cross‑region sync
Load balancing: Route queries to optimal region

Benefits

High availability even during regional disasters
Reduced latency for global users
Improved disaster recovery RPO/RTO
Compliance with local data laws

Challenges

Complex to operate
Expensive
Ensuring global data consistency is difficult
Requires advanced replication solutions (GoldenGate, etc.)

Resiliency Comparison: Single‑AZ vs Multi‑AZ vs Multi‑Region

Category	Single‑AZ	Multi‑AZ (Single Region)	Multi‑Region
Availability Level	Low – No AZ fault tolerance	High – Survives AZ failure	Very High – Survives region failure
Fault Tolerance	Instance‑level only	AZ‑level redundancy	Region‑level redundancy
Data Replication	Local or single‑node	Synchronous across AZs	Asynchronous or semi‑sync across regions
RPO (Recovery Point Objective)	Minutes to hours (backup-based)	Near‑zero (sync replication)	Seconds to minutes (async replication)
RTO (Recovery Time Objective)	Hours (manual recovery)	Seconds to minutes (auto failover)	Minutes to hours (regional failover)
Latency Between Nodes	Lowest (same AZ)	Low (high‑speed inter‑AZ network)	Highest (cross‑region/geo latency)
Service Continuity During Failure	Outage if AZ fails	No major impact – automatic AZ failover	Continues from secondary region after failover
Compliance & Data Residency	Basic	Regional compliance only	Full geo‑compliance and DR support
Cost	Lowest	Moderate (AZ redundancy)	Highest (duplicate infra across regions)
Use Cases	Dev/Test, low‑critical apps	Business‑critical workloads requiring HA	Mission‑critical systems requiring full DR
Strengths	Simple & cost‑effective	High availability & zero data loss	Maximum resilience & geography‑level protection
Weaknesses	No AZ/Region protection	No region‑level DR	Expensive and more operational complexity

What is Single‑Region, Multi‑Availability Zone (Multi‑AZ) Resiliency Architecture ?

Single‑Region, Multi‑Availability Zone (Multi‑AZ) Resiliency

A Single‑Region, Multi‑Availability Zone (Multi‑AZ) architecture provides high availability and fault tolerance for applications and databases within a single cloud region. By distributing workloads across multiple, physically isolated AZs, this architecture ensures continuity even if one AZ experiences failure.

Multi‑AZ deployments are a standard best practice for production‑grade systems requiring strong availability guarantees while staying within a single region.

Purpose of Multi‑AZ Architecture

Enhance availability through AZ‑level redundancy
Improve fault isolation within a region
Ensure zero or near‑zero data loss using synchronous replication
Maintain continuous operations even during AZ outages

In this model, if one AZ becomes unavailable, operations continue seamlessly from another AZ with minimal or no service interruption.

How Multi‑AZ Resiliency Works

1. Synchronous Data Replication

Databases replicate data to a secondary AZ in near real time.
Ensures strong consistency and near‑zero RPO.
Protects against data loss in case of AZ failure.

2. Automatic Failover

If the primary AZ fails, the system automatically redirects traffic to healthy nodes in another AZ.
Failover is typically handled by the platform (RDS, Cloud SQL, Azure Database, Kubernetes, etc.).

3. High‑Speed Inter‑AZ Networking

AZs within a region are interconnected with low‑latency, high‑bandwidth links.
Enables synchronous replication without significant performance degradation.

4. Uniform Regional Services

All AZs follow the same regional compliance, security, and governance rules.
Ensures workload consistency and simplifies certification audits.

Benefits of Multi‑AZ Architecture

1. High Availability

If one AZ experiences a hardware, power, or network failure, other AZs actively continue serving traffic.
Greatly improves uptime and reduces business disruption.

2. Low‑Latency Interconnectivity

Cloud providers engineer sub‑millisecond latency between AZs.
Supports synchronous replication and distributed application components.

3. Efficient and Durable Data Replication

Multi‑AZ setups minimize data loss risk.
Ideal for OLTP databases requiring strong consistency.

4. Compliance & Regulatory Alignment

Since all AZs belong to the same region, they follow the same:
- Data residency laws
- Compliance frameworks (GDPR, HIPAA, ISO, PCI, etc.)
- Security governance

This ensures consistent adherence without the complexities of multi‑region regulation.

Limitations of Multi‑AZ Architecture

Despite its advantages, Multi‑AZ resiliency is not a complete business continuity solution.

1. Vulnerable to Region‑Wide Outages

Multi‑AZ protects against AZ‑level failures—but not regional disruptions such as:

Major natural disasters
Regional power grid failures
Widespread provider outages
Control-plane failures affecting the entire region

A full region outage will impact all AZs in that region.

2. Geographic Constraints

Since the deployment is confined to a single region:

Users far from the region may experience higher latency.
Global performance optimization is not possible.
Not suitable for multi‑continent service distribution.

3. Potential Compliance Gaps

Certain regulations require:

Geographical separation of primary and DR sites
Data copies in different states/countries
Multi‑region disaster recovery

A Multi‑AZ architecture alone does not meet strict DR or geo‑redundancy mandates.

When to Use Multi‑AZ Resiliency

Ideal For:

Production databases (OLTP/OLAP)
Enterprise applications requiring high availability
Financial and healthcare workloads with strict consistency needs
Any system needing strong AZ‑level fault tolerance

Not Sufficient For:

Mission‑critical applications requiring region‑level DR
Global low‑latency applications
Compliance frameworks requiring geo‑redundancy
RPO = 0 & RTO = minutes across regions

What is Single‑Region, Single‑Availability Zone (AZ) Resiliency Architecture ?

Single‑Region, Single‑Availability Zone (AZ) Resiliency Overview

A Single‑Region, Single‑Availability Zone (AZ) deployment represents the most basic cloud architecture model. While simple and cost‑effective, it offers minimal resiliency and exposes workloads to significant infrastructure‑level risks. This architecture is often seen in:

Early‑stage or proof‑of‑concept environments
Cost‑optimized setups
Legacy applications not yet modernized
Development or testing workloads

Despite its simplicity, understanding its limitations and best‑practice safeguards is crucial—especially for database‑driven systems.

What Is an Availability Zone (AZ)?

An Availability Zone is an isolated, physically separate data center within a cloud region (AWS, Azure, GCP). Each AZ typically has:

Independent power supply
Isolated networking
Separate cooling and physical security

In a Single‑AZ deployment:

All compute, storage, network, and database resources reside within one data center.
No cross‑AZ failover exists.
A failure of that AZ directly impacts the entire workload.

Resiliency Characteristics in a Single‑Region, Single‑AZ Setup

**What You Can Protect Against (Within the AZ)**

A Single‑AZ design can mitigate failures limited to the infrastructure within that AZ:

Virtual machine or instance failures
Application‑level crashes
Software defects
Local disk issues
Process‑level outages

Typical mechanisms include:

VM/Pod auto‑restart
Platform‑provided auto‑healing
Load balancing across multiple instances inside the AZ
Database failover within the same AZ
Backup and restore procedures

**What You Cannot Protect Against**

A Single‑AZ setup cannot safeguard against data‑center‑level events, such as:

Complete AZ outage
Power disruption
Networking isolation
Fire, flooding, or physical damage
Regional outage (if the entire region is impacted)

If the AZ becomes unavailable, the entire workload becomes unavailable.
No automated recovery is possible without manual redeployment.

Best Practices for Improving Resiliency Within a Single AZ

1. Intra‑AZ Redundancy

Multiple compute nodes deployed in the same AZ
Load balancer distributing traffic among nodes
Managed database with synchronous replication to an in‑AZ standby

2. Automated Recovery

Use of Auto‑Scaling Groups (ASG) or equivalent orchestration platforms
Health‑based instance replacement
Application‑level crash recovery mechanisms

3. Data Durability

Even in Single‑AZ deployments, data durability must extend beyond that AZ:

Scheduled backups stored in multi‑AZ or multi‑region storage (S3/Blob/GCS)
Point‑in‑time recovery (PITR) where supported
Protection against accidental deletion or corruption

4. Monitoring & Alerting

Infrastructure and application health checks
Centralized logging and correlation
Alerting on metrics such as CPU, disk, latency, and database health

5. Incident Response & Runbooks

Documented steps to restore from backup
Procedure to redeploy stack to a new AZ or region if required
Defined responsibilities and escalation policies

Key Risks to Communicate to Stakeholders

A Single‑AZ architecture has inherent business and technical risks:

No fault tolerance for AZ‑level failures
No disaster recovery (DR) capability
Increased RTO (Recovery Time Objective)
Increased RPO (Recovery Point Objective)
Higher likelihood of prolonged downtime during outages

Suitable only for:

Development and testing environments
Low‑criticality workloads
Cost‑sensitive deployments
Legacy systems not yet refactored

Not suitable for:

Mission‑critical applications
Customer‑facing platforms requiring high availability
Systems requiring compliance‑driven uptime guarantees

As a Database Architect: Key Responsibilities in Single‑AZ Designs

Even within a restricted resiliency model, you must ensure database stability, recoverability, and data integrity.

Minimum DB Resiliency Expectations

Synchronous in‑AZ replica (where supported)
Automated database failover within the AZ
Continuous backups stored in cross‑AZ or multi‑region storage
Point‑in‑time recovery (PITR) configuration
Automated recovery workflows (bootstrapping, failover scripts, restoration steps)
Regular testing of backup and restore procedures

Tuesday, January 27, 2026

what is RPO and RTO ?

✅ What is RPO (Recovery Point Objective)?

RPO = How much data loss is acceptable?

It defines how far back in time you must recover your database after a failure.

In other words:

RPO tells you how much data you can afford to lose.
It's measured in time (seconds, minutes, hours).

📌 Database Example

Suppose:

Your database takes backups every 1 hour
A failure happens at 3:45 PM
Last backup was at 3:00 PM

Then:

You lose 45 minutes of data
So your RPO = 1 hour

If your business says:

“We cannot lose more than 5 minutes of data”

Then:

You must implement near real-time replication, e.g.,
- PostgreSQL sync replication
- SQL Server AlwaysOn synchronous commit
- Oracle Data Guard synchronous
- MySQL Group Replication

✅ What is RTO (Recovery Time Objective)?

RTO = How much time is acceptable to restore service?

It defines how quickly your database must be back online after a failure.

In other words:

RTO tells you how long you can afford your database to be down.

📌 Database Example

Suppose:

Your database fails at 3:45 PM
You restore from backup + perform recovery
Everything is back online at 4:30 PM

Then:

RTO = 45 minutes

If your business says:

Database must be back within 5 minutes

Then you need:

Automated failover
Multi‑AZ synchronous replica
Warm standby instance already running
No manual restore

🎯 Putting Both Together (Database Scenario)

Scenario:

Your production PostgreSQL database crashes at 3:45 PM

Last WAL archive was at 3:40 PM → RPO = 5 minutes
Failover to standby completes at 3:47 PM → RTO = 2 minutes

This means:

You lost 5 minutes of data (acceptable based on RPO)
System was down for 2 minutes (acceptable based on RTO)

🧩 Easy Analogy

Term	Meaning (Simple)	Database Interpretation
RPO	How much data you can lose	Gap between last usable data & failure time
RTO	How long you can be down	Time database takes to become operational

🔥 Real-World DB Examples You Can Use

1. Single‑AZ Database

Backups every night
No replication
RPO = 24 hours (you lose 1 day of data)
RTO = many hours (need to restore backup)

2. Multi‑AZ Synchronous Replication

Data committed on both nodes
Failover is automatic
RPO ≈ 0 seconds
RTO = 30–120 seconds

3. Multi‑Region Asynchronous Replication

Slight replication lag (5–15 seconds)
RPO = a few seconds
RTO = a few minutes

⭐ Summary (Very Simple)

RPO = How much data can I lose?
RTO = How long can I be down?

Metric Definition Target
RTO Max downtime Near 0 seconds
RPO Max data loss Near 0 data loss

Both are business-driven, implemented through database architecture.

Single‑Region, Single‑AZ Resiliency — What It Really Means ?

Single‑Region, Single‑Availability Zone (AZ) deployments are the simplest cloud architecture but also the least fault‑tolerant. They are common in early‑stage environments, cost‑constrained setups, or legacy workloads that haven’t been modernized yet.

🔍 What Is an AZ?

An Availability Zone is a physically separate data center within a cloud region (AWS, Azure, GCP).
In a Single‑AZ setup:

All compute, storage, networking, and database components reside within one data center.
No failover capability exists outside that AZ.

🧩 What Does “Resiliency” Look Like in a Single‑Region, Single‑AZ Setup?

✔️ You can protect against:

Instance failures (VM crash)
Application failures
Software bugs
Local disk corruption
Process-level outages

These are typically mitigated through:

Auto-restart, auto-healing
Load balancing across multiple instances within the same AZ
Database failover within the AZ (e.g., primary ↔ standby in same data center)
Backup & restore strategies

❌ You cannot protect against:

AZ‑wide outage
Power loss
Networking isolation
Fire/flood/physical issues in the AZ
Region outage

If the AZ goes down, the entire workload goes down.

🏗️ Typical Resiliency Best Practices in Single‑AZ

1. Redundancy Within the AZ

Multiple compute nodes in a single AZ
Load balancer distributing traffic
Managed DB with synchronous replication (single-AZ failover)

2. Automated Recovery

Auto‑scaling groups (ASG)
Self-healing from platform
Application crash recovery scripts

3. Data Durability

Regular backups to cross‑AZ or multi-region storage
(even if workload is single-AZ, backups must be multi-AZ)

4. Monitoring & Alerting

Health checks
Log aggregation
Metric‑driven alerting

5. Incident Runbooks

How to restore from backup
How to redeploy the entire stack into a new AZ (if needed)

⚠️ Key Risks You Must Communicate to Stakeholders

A Single‑AZ design has:

No AZ fault tolerance
No disaster recovery capability
Higher RTO and RPO
No protection against data center‑level disruptions

It’s usually acceptable only for:

Dev/Test environments
Non‑critical services
Cost‑optimized workloads
Legacy apps not yet modernized

But not for mission‑critical systems.

🎯 As a Database Architect: What Should You Ensure?

Minimum DB resiliency even in a Single‑AZ:

Synchronous replica in same AZ
Automated failover
Continuous backups to multi‑AZ storage
PITR (Point-in-time Recovery)
Automated recovery workflows
Tested restore procedures

1. Architecture Diagram (ASCII – Single Region, Single AZ)

                ┌──────────────────────────────────────────────┐
                │              Cloud Region (e.g., AWS ap-south-1)            
                │──────────────────────────────────────────────│
                │                                              │
                │      Availability Zone (e.g., ap-south-1a)   │
                │      ─────────────────────────────────────    │
                │                                              │
                │   ┌──────────────┐     ┌──────────────┐      │
                │   │ Load Balancer│ --> │ App Servers   │      │
                │   └──────────────┘     └──────────────┘      │
                │                   \      /                    │
                │                    \    /                     │
                │                  ┌──────────────┐             │
                │                  │ Database      │             │
                │                  │ Primary +     │             │
                │                  │ Standby (same │             │
                │                  │ AZ)           │             │
                │                  └──────────────┘             │
                │                                              │
                │     Backups → Multi‑AZ Object Storage        │
                └──────────────────────────────────────────────┘

The image generated above is a comparison matrix, which complements this diagram.

✅ 2. Comparison: Single‑AZ vs Multi‑AZ vs Multi‑Region

Dimension	Single‑AZ	Multi‑AZ	Multi‑Region
Regions	1	1	2+
AZs Used	1	2–3	2–6
Fault Tolerance	None	Survives AZ outage	Survives region outage
Cost	Low	Moderate (2–3x)	High (4x–10x)
Complexity	Simple	Moderate	High
RTO	2–24 hrs (restore-based)	Minutes	Seconds–Minutes
RPO	Minutes–Hours	Seconds	0–Seconds
Risks	AZ failure	Region-level failure	Cross-region disasters

✅ 3. RTO/RPO Matrix

Architecture	Typical RTO	Typical RPO	Notes
Single‑AZ	4–24 hours	15 min – several hours	Restore from backup
Multi‑AZ	1–5 minutes	0–5 seconds	Synchronous replication
Multi‑Region (Active-Passive)	5–60 minutes	< 1 minute	Asynchronous sync
Multi‑Region (Active-Active)	Seconds	Zero RPO	Conflict-free architectures

✅ 4. Cloud-Specific Examples

AWS

Compute: EC2 in Auto Scaling Group (single AZ)
Database: RDS Single-AZ deployment
Backup: S3 (multi-AZ), S3 Glacier (multi-region optional)
Networking: Single AZ subnets
Risks: AZ failure → complete outage

Azure

Compute: VM Scale Set (single fault domain)
Database: Azure SQL Single‑Zone
Storage: GRS recommended for durability
Risks: Zone outage = full downtime

GCP

Compute: Managed Instance Group (single zone)
Database: Cloud SQL Single‑Zone
Storage: Multi‑regional storage optional
Risks: Same — no protection beyond local zone

✅ 5. Database Resiliency Patterns (Per Engine)

Oracle

Data Guard (single-AZ synchronous)
RMAN backups → multi‑AZ storage
Flashback + PITR

PostgreSQL

Streaming replication (sync within AZ)
WAL archiving to multi-region buckets
Patroni/pg_auto_failover for node-level protection

SQL Server

AlwaysOn Availability Groups (single-AZ)
Log shipping → cross-region DR
Automated failover only within AZ

MySQL

InnoDB ReplicaSet or Group Replication
Backups via mysqldump + GTID cross-region
Aurora Single‑AZ considered low resiliency

✅ 6. Complete Architecture Document (Concise)

Single‑Region, Single‑AZ Resiliency Architecture

This architecture is designed for workloads that prioritize simplicity and cost efficiency over regional or AZ‑level fault tolerance.

Components

Compute instances deployed in a single Availability Zone
Database with synchronous intra‑AZ replica
Load balancers within the same AZ
Backups stored in multi‑AZ object storage
Centralized monitoring (CloudWatch / Azure Monitor / GCP Ops)

Fault Domains

Handles: instance crash, OS failure, application errors
Does NOT handle: AZ failure, region failure, physical disasters

Operational Controls

Backup policy (daily, hourly log shipping)
Restore testing every quarter
Health monitoring & alerting
Deployment automation (IaC)

When to Use

Dev/Test environments
Non-critical internal tools
Proof-of-concept systems
Low-traffic legacy apps

Not Recommended For

Customer-facing applications
Transactional systems (finance, retail)
High availability (99.9%+)
Compliance-bound workloads