resilient-architectures on Alperen Doc

ha-vs-fault-tolerance

Mon, 01 Jan 0001 00:00:00 +0000

High Availability vs Fault Tolerance#

Every resilience question starts here: how much downtime is acceptable? The exam expects you to distinguish two very different promises - and to hunt for single points of failure (SPOF).

The definitions#

	High Availability (HA)	Fault Tolerance (FT)
Goal	Minimize downtime	Zero downtime
Behavior on failure	Recover quickly (seconds-minutes)	Continue without interruption
Cost	Moderate	Expensive (everything duplicated)
Example	Multi-AZ RDS (Relational Database Service) with failover	Aircraft systems, active-active multi-region

Reliability is the umbrella term: the system does what it should over time. Scalability (vertical vs horizontal) and recoverability feed into it.

disaster-recovery-strategies

Mon, 01 Jan 0001 00:00:00 +0000

Disaster Recovery Strategies#

This is a pure memorization page with a huge payoff: the four DR (disaster recovery) strategies appear in almost every resiliency scenario. Learn them as a cost ↔ recovery time slider.

Two numbers decide everything#

RPO (Recovery Point Objective) = how much data can I afford to lose? (measured in time back)
RTO (Recovery Time Objective) = how fast must I be back up? (measured in downtime)

Backup every 24h → RPO = 24h (you lose up to a day). Restore takes 6h → RTO = 6h.

elb-and-auto-scaling-resilience

Mon, 01 Jan 0001 00:00:00 +0000

ELB (Elastic Load Balancing) and Auto Scaling Resilience#

The load balancer is the front door and the Auto Scaling Group is the immune system. Together they answer most “traffic doubles at noon” and “an instance died” questions.

Choosing the load balancer#

	ALB (Application Load Balancer)	NLB (Network Load Balancer)	GWLB (Gateway Load Balancer)	CLB (Classic Load Balancer) - legacy
Layer	7 (HTTP/HTTPS)	4 (TCP/UDP/TLS)	3 (IP)	4/7
Routing	Path, host, headers, query	Port/IP, ultra low latency	3rd party appliances	Simple
Static IP	No (use DNS)	Yes (and Elastic IPs)	Yes	No
Use case	Web apps, containers, Lambda targets	Gaming, IoT, extreme perf, private link entry	Firewalls, IDS/IPS	Don’t pick this

Exam shortcuts:

decoupling-with-sqs-sns

Mon, 01 Jan 0001 00:00:00 +0000

“When a downstream system fails, the whole app shouldn’t fail” → decouple with a queue. SQS/SNS questions are among the most frequent on the exam, and the answers hinge on a few precise differences.

SQS - the pull-based queue#

Producers send messages, consumers poll and delete. Fully managed, near unlimited scale.

Standard vs FIFO#

	Standard	FIFO
Order	Best-effort (may reorder)	Strict per message group
Delivery	At-least-once (duplicates possible)	Exactly-once processing (deduplicated)
Throughput	Nearly unlimited	300 msg/s (3,000 with batching)
Use when	Speed matters	Orders, payments, “exactly once”

FIFO queue names end in .fifo. Message group ID = parallel processing lanes within ordering; deduplication ID = duplicate suppression window (5 min).

event-driven-eventbridge-step-functions

Mon, 01 Jan 0001 00:00:00 +0000

Event-Driven Architecture: EventBridge and Step Functions#

Queues move messages; events announce that something happened. The exam tests whether you can pick between “process this work item” (SQS), “notify everyone” (SNS), “route this event” (EventBridge) and “orchestrate this workflow” (Step Functions).

Amazon EventBridge#

The evolution of CloudWatch Events: a serverless event bus with rules.

Default bus - AWS service events (EC2 (Elastic Compute Cloud) state changes, S3 (Simple Storage Service) events via CloudTrail…)
Custom bus - your application’s events; can be shared cross-account
Partner sources - SaaS events (Zendesk, Datadog, Shopify…) land directly in your bus
Rules match event patterns and route to targets (Lambda, SQS, SNS, Step Functions…)
Content filtering: event patterns filter on fields before delivery (unlike SNS which delivers everything)
Archive and replay - store events and replay them later (“we lost 2 hours of processing”)
Schema registry - discover and generate code for event shapes

Need	Answer
Durable work queue, backpressure	SQS
One message → many push subscribers	SNS
Filter and route events by content, multiple sources, replay	EventBridge
Fan-out with durability	SNS → SQS (or EventBridge → SQS)

“Event pattern filtering” and “replay archived events” are the two keywords that make EventBridge the answer.

streaming-kinesis-data-streams-firehose

Mon, 01 Jan 0001 00:00:00 +0000

Real-Time Streaming: Kinesis Data Streams, Data Firehose and Apache Flink#

When a scenario mentions clickstreams, IoT telemetry, financial ticks, or millions of log events per second, you are in the streaming world. The exam tests whether you can pick between Kinesis Data Streams (KDS), Amazon Data Firehose, Managed Service for Apache Flink, and SQS (Simple Queue Service).

The streaming architecture pipeline#

flowchart LR
 prod[IoT / Clickstream / Logs] --> kds[Kinesis Data Streams: real-time ingest & replay]
 kds --> flink[Managed Apache Flink: real-time SQL / windowing]
 kds --> lambda[Lambda / KCL consumers]
 kds --> fh[Data Firehose: buffer, transform, deliver]
 fh -->|Lambda transform / Parquet| s3[(S3 Data Lake)]
 fh --> rs[(Redshift)]
 fh --> os[(OpenSearch)]

Kinesis Data Streams (KDS) vs Amazon Data Firehose#

This is one of the highest-frequency comparisons across Domains 2 and 3:

rds-and-aurora-failover

Mon, 01 Jan 0001 00:00:00 +0000

RDS (Relational Database Service) and Aurora Resilience: Multi-AZ vs Read Replicas#

The single most confused pair in the whole exam. One is for high availability, the other for performance - and mixing them up is exactly what the question writers count on.

Multi-AZ vs Read Replicas#

	Multi-AZ	Read Replica
Purpose	Failover / HA (high availability)	Read scaling
Replication	Synchronous standby	Asynchronous
Reads from standby	No (standby is invisible)	Yes (you connect to its endpoint)
Failover	Automatic (~60s, DNS change)	Manual promotion
Regions	Same region (different AZs (Availability Zone))	Cross-region possible

Combining both is the standard “production” answer: Multi-AZ for safety, replicas for scale.

route53-routing-policies-and-failover

Mon, 01 Jan 0001 00:00:00 +0000

Route 53 Routing Policies and Failover#

DNS is the cheapest high-availability tool AWS gives you. The exam wants you to match a business requirement to one of seven routing policies - the words “latency”, “geolocation”, “failover” and “weighted” each map to exactly one answer.

The routing policies#

Policy	What it does	Scenario keyword
Simple	One record, random answer	“single resource”, no smartness needed
Weighted	Split traffic by %	“canary 10% to the new version”, “A/B test”
Latency	Send users to the lowest latency region	“best performance for the user”
Failover	Active-passive; health check flips DNS	“disaster recovery”, “passive standby”
Geolocation	Route by user’s location	“content licensing”, “different content per country”
Geoproximity	Route by resource location + bias	“shift more traffic to region X”
IP-based	Route by user’s IP CIDR	“these offices go to that endpoint”
Multivalue answer	Up to 8 healthy records, client picks	“poor man’s load balancing”

Health checks and failover#

Route 53 health checks monitor endpoints (HTTP/TCP, string match), or CloudWatch alarms as the source
Failover routing + health check = automatic active-passive DR (disaster recovery): primary unhealthy → DNS points at secondary
Note the DNS TTL (time to live) effect: failover is only as fast as the record’s TTL (see dns-ttl-and-caching)

Classic pattern - static site failover to S3 (Simple Storage Service):

vpc-connectivity-peering-tgw-direct-connect

Mon, 01 Jan 0001 00:00:00 +0000

VPC (Virtual Private Cloud) Connectivity: Peering, Transit Gateway, VPN and Direct Connect#

“Connect these networks” questions come in three flavors: VPC-to-VPC, VPC-to-on-prem, and hybrid at scale. The exam wants the right topology for the scale - not just “what works”.

VPC Peering#

Direct network connection between two VPCs using private IPs.

No transitive routing: A↔B and B↔C does not give A↔C (mesh explodes with VPC count)
CIDR blocks must not overlap
Works cross-region and cross-account
No bandwidth bottleneck (uses AWS backbone), no single point of failure
When: 2-3 VPCs that all need to talk to each other

Transit Gateway#

The hub-and-spoke answer for scale:

resilient-architectures on Alperen Doc

ha-vs-fault-tolerance

High Availability vs Fault Tolerance#

The definitions#

disaster-recovery-strategies

Disaster Recovery Strategies#

Two numbers decide everything#

elb-and-auto-scaling-resilience

ELB (Elastic Load Balancing) and Auto Scaling Resilience#

Choosing the load balancer#

decoupling-with-sqs-sns

Decoupling with SQS (Simple Queue Service) and SNS (Simple Notification Service)#

SQS - the pull-based queue#

Standard vs FIFO#

event-driven-eventbridge-step-functions

Event-Driven Architecture: EventBridge and Step Functions#

Amazon EventBridge#

EventBridge vs SNS vs SQS#

streaming-kinesis-data-streams-firehose

Real-Time Streaming: Kinesis Data Streams, Data Firehose and Apache Flink#

The streaming architecture pipeline#

Kinesis Data Streams (KDS) vs Amazon Data Firehose#

rds-and-aurora-failover

RDS (Relational Database Service) and Aurora Resilience: Multi-AZ vs Read Replicas#

Multi-AZ vs Read Replicas#

route53-routing-policies-and-failover

Route 53 Routing Policies and Failover#

The routing policies#

Health checks and failover#

vpc-connectivity-peering-tgw-direct-connect

VPC (Virtual Private Cloud) Connectivity: Peering, Transit Gateway, VPN and Direct Connect#

VPC Peering#

Transit Gateway#