Study Guide: Designing Modern AWS Architectures

This guide covers the core principles of designing resilient, scalable, and high-performing architectures on AWS, focusing on event-driven models, microservices, and traditional multi-tier patterns.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between monolithic, microservice, and multi-tier architectures.
• Design loosely coupled systems using AWS integration services like Amazon SQS and SNS.
• Identify appropriate use cases for serverless technologies (Lambda, Fargate).
• Implement strategies for high availability and fault tolerance across multiple Availability Zones.
• Define and apply Disaster Recovery (DR) metrics including RTO and RPO.

Key Terms & Glossary

• Loose Coupling: An approach where components are independent, so that a change or failure in one does not directly impact others. Real-world example: A retail site where the "Order" service continues to take orders even if the "Shipping" notification service is temporarily down.
• Microservices: An architectural style that structures an application as a collection of small, autonomous services modeled around a business domain.
• Statelessness: A design where a service does not store client data between requests. Example: An AWS Lambda function that processes an image and outputs it to S3 without storing local session data.
• Event-Driven Architecture (EDA): A system where actions are triggered by events (e.g., a file upload to S3 triggering a Lambda function).
• 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 up to 15 minutes of data").

The "Big Idea"

The fundamental shift in modern cloud architecture is moving from Tight Coupling (where components are hard-wired and fail together) to Loose Coupling (where components communicate via messages and events). By breaking a monolithic application into microservices and using "glue" services like SQS, SNS, or EventBridge, you create a system that can scale infinitely and survive individual component failures without a total outage.

Formula / Concept Box

[!IMPORTANT] RPO vs RTO: Remember that P in RPO stands for Point (Data/Past), while T in RTO stands for Time (Downtime/Future).

Hierarchical Outline

1. Architecture Patterns
   • Multi-tier: Traditional web-app-db separation using subnets and security groups.
   • Microservices: Decoupling by function; services communicate via APIs (API Gateway).
   • Serverless: Using Lambda and Fargate to remove server management overhead.
2. Loose Coupling & Messaging
   • Asynchronous Processing: Using SQS to buffer requests during traffic spikes.
   • Pub/Sub Patterns: Using SNS to broadcast events to multiple downstream systems.
   • Orchestration: Using AWS Step Functions to manage complex multi-step workflows.
3. Resiliency & High Availability
   • Multi-AZ Deployment: Hosting resources in at least two AZs to survive a data center failure.
   • Statelessness: Storing session data in DynamoDB or ElastiCache rather than the local instance.
   • Health Checks: Using ALBs and Route 53 to route traffic away from unhealthy instances.

Visual Anchors

1. Multi-Tier High Availability Architecture

2. SQS Decoupling Pattern

Definition-Example Pairs

• API Gateway: A managed service that makes it easy for developers to create, publish, and secure APIs. Example: A mobile app calls a single URL (API Gateway) which then routes the request to different Lambda functions for "Login," "Search," and "Purchase."
• AWS Step Functions: A serverless orchestrator for modern applications. Example: An e-commerce checkout process that first checks inventory, then charges a credit card, and finally sends a confirmation email, with logic for retries if the credit card fails.
• Read Replicas: Copies of a database that handle read-only traffic. Example: A blog with heavy traffic uses the Primary DB for writing posts but directs all visitor traffic to Read Replicas to improve performance.

Worked Examples

Problem: Converting a Monolithic Image Processor

A company has a monolith on a single EC2 instance that accepts image uploads and processes them. During high traffic, the instance crashes, and uploads are lost.

Solution: Event-Driven Re-architecture

1. Ingestion: Move the upload target to Amazon S3. This is highly durable and decoupled from the compute.
2. Trigger: Configure S3 to send an event notification to Amazon SQS whenever a new object is created.
3. Processing: Use AWS Lambda (serverless) to poll the SQS queue.
4. Result: If the processing fails, the message stays in the queue (or goes to a Dead Letter Queue) to be retried later. No uploads are ever lost, and the system scales automatically.

Checkpoint Questions

1. What is the primary difference between horizontal and vertical scaling? Answer: Horizontal scaling (Scaling Out) adds more instances (e.g., 1 server to 5 servers), while vertical scaling (Scaling Up) increases the hardware capacity of an existing instance (e.g., t3.micro to m5.large).

2. If an application requires an RPO of 0 (no data loss), which database feature should be used? Answer: Multi-AZ with Synchronous Replication.

3. Why would a developer use AWS Step Functions instead of just chaining Lambda functions together? Answer: Step Functions provide state management, error handling, and visual monitoring, which are difficult to manage manually when chaining multiple Lambdas.

4. Which AWS service would you use to implement a 'fan-out' pattern to send a message to SQS, Lambda, and Email simultaneously? Answer: Amazon SNS (Simple Notification Service).

5. True or False: A Multi-tier architecture requires the Web, App, and Database layers to be in the same subnet. Answer: False. They should be in separate subnets (Public for Web, Private for App/DB) to improve security.