Architecture Pattern Drills

Learning outcomes

By the end of this lesson, the learner can:

1. Combine multiple AWS services into a simple architecture pattern.
2. Explain why one service is a better fit than another in context.
3. Recognize common architecture shapes such as simple website, scalable web app, containerized app, analytics pipeline, and graph workload.
4. Spot when CloudFormation should be part of the answer because the real need is repeatable infrastructure. AWS documents CloudFormation as the infrastructure-as-code service built around templates, stacks, and change sets. (AWS Documentation)

---

How to approach these drills

This lesson is about moving from service recognition to service selection. Instead of asking "What is ECS?" or "What is RDS?", you now ask, "Which combination of AWS services best fits this application?" AWS's service docs make those roles fairly clear: ECS runs and scales containerized apps, Lightsail is the simpler bundled app platform, CloudFormation manages infrastructure as code, S3 storage classes match access patterns, RDS/Aurora handle relational data, DynamoDB handles high-scale NoSQL operational data, Redshift is the warehouse analytics service, EMR runs big data frameworks, and Neptune is the graph database for highly connected data. (AWS Documentation)

A simple memory rule for this lesson is:

• simple app -> Lightsail
• containerized service -> ECS
• repeatable infrastructure -> CloudFormation
• warehouse analytics -> Redshift
• big data processing -> EMR
• relationship-heavy data -> Neptune
• high-scale NoSQL operational data -> DynamoDB
• relational app database -> RDS or Aurora (AWS Documentation)

---

Drill 1: Small business website

Scenario: You want to launch a small business website quickly. You want a virtual server, maybe a simple managed database later, DNS, backups, and predictable bundled pricing.

Best fit: Lightsail

Why: AWS positions Lightsail as the easiest way to get started for websites and web applications, and the current Lightsail docs list instances, managed databases, CDN distributions, load balancers, block storage, DNS management, and snapshots as part of the platform. This makes it the strongest "simple bundled platform" answer instead of manually assembling many separate AWS services first. (AWS Documentation)

---

Drill 2: Scalable traditional web app

Scenario: A team wants a classic web application with application servers, a relational database, load balancing, and the ability to grow traffic over time.

Best fit: EC2 + ELB + Auto Scaling + RDS or Aurora

Why: RDS documentation explicitly shows a typical dynamic website pattern with application servers, Elastic Load Balancing, and DB instances, and AWS documents EC2 Auto Scaling as the service that keeps the right number of instances available as demand changes. If the team wants a managed relational database, RDS is the service umbrella, and Aurora is the MySQL/PostgreSQL-compatible engine choice when they want Aurora's clustering and storage model. (AWS Documentation)

---

Drill 3: Long-lived containerized API

Scenario: A team has a containerized API and wants load balancing, scaling, and a managed way to keep the desired number of containers running.

Best fit: ECS service, often starting with Fargate if they do not want to manage servers

Why: AWS says ECS services maintain the desired number of running tasks and support both service auto scaling and service load balancing. AWS also documents Fargate as the serverless compute option for ECS tasks, while ECS Managed Instances and ECS on EC2 are the more EC2-backed choices. (AWS Documentation)

---

Drill 4: High-scale operational app data

Scenario: An application needs extremely fast operational lookups, unpredictable traffic, and a serverless database model. It does not need SQL joins.

Best fit: DynamoDB

Why: AWS describes DynamoDB as a serverless, fully managed, distributed NoSQL database with single-digit millisecond performance at any scale, and explicitly notes that it does not support joins. AWS also documents on-demand mode as the default and recommended throughput option for most workloads, which fits unpredictable traffic well. (AWS Documentation)

---

Drill 5: Speeding up repeated reads

Scenario: A web app keeps re-running the same expensive reads and wants much faster response times for frequently requested data.

Best fit: ElastiCache in front of the main database

Why: AWS describes ElastiCache as the fully managed in-memory data store and cache service, and says it is meant to reduce the cost and latency of repeatedly fetching data from slower sources. AWS currently documents Valkey, Memcached, and Redis OSS as the engine families, with both serverless caching and node-based cluster options. (AWS Documentation)

---

Drill 6: Warehouse analytics vs processing pipeline

Scenario: A company has large datasets in S3. They need two things: first, heavy data processing and transformation; second, SQL analytics and BI dashboards on curated data.

Best fit: EMR + Redshift

Why: AWS says EMR is the managed platform for running frameworks like Spark and Hadoop to process and analyze vast amounts of data, while Redshift is the managed data warehouse for SQL analytics. A natural pattern is to process raw data with EMR and then load curated analytics data into Redshift for reporting and BI queries. (AWS Documentation, AWS Documentation)

---

Drill 7: Relationship-heavy fraud detection

Scenario: A fraud team wants to model accounts, devices, transactions, and connections between them, and run path-heavy or link-heavy queries.

Best fit: Neptune

Why: AWS describes Neptune as the fully managed graph database for highly connected datasets and explicitly lists fraud detection, recommendation engines, and knowledge graphs as Neptune use cases. This is the clear graph-database pattern, not a relational or key-value pattern. (AWS Documentation)

---

Drill 8: Archive strategy for files over time

Scenario: A team stores files in S3. New files are accessed often, older files are rarely used, and very old files are mostly archive material.

Best fit: S3 Standard -> Standard-IA or Intelligent-Tiering -> Glacier class, often with Lifecycle transitions

Why: AWS says S3 Standard is the default class for frequently accessed data, Intelligent-Tiering is for unknown or changing access patterns, Standard-IA is for long-lived infrequently accessed data with millisecond access, and Glacier classes are for rarely accessed archive-style storage. The S3 storage-class guide also explicitly discusses lifecycle transitions for moving objects to more appropriate classes as they age. (AWS Documentation)

---

Drill 9: Repeatable environments across dev and prod

Scenario: A team wants to deploy the same infrastructure repeatedly across environments, review updates before applying them, and avoid hand-built console drift.

Best fit: CloudFormation

Why: AWS documents CloudFormation templates as YAML or JSON infrastructure blueprints, stacks as the deployed unit of related resources, and change sets as the preview before execution. AWS best practices also warn against changing stack-managed resources outside CloudFormation because that creates drift. (AWS Documentation)

---

Quick pattern map

CSV version:

Scenario type,Strong first-fit pattern
Simple website or small app,Lightsail
Scalable traditional web app,EC2 + ELB + Auto Scaling + RDS/Aurora
Long-lived containerized API,"ECS service, often on Fargate"
High-scale operational NoSQL app,DynamoDB
Fast repeated-read layer,ElastiCache
Big data processing pipeline,EMR
SQL warehouse analytics,Redshift
Relationship-heavy connected data,Neptune
Aging file/archive strategy,S3 storage classes + Lifecycle
Repeatable infrastructure,CloudFormation

This pattern map is a synthesis of the official AWS service roles documented across the ECS, Lightsail, CloudFormation, S3, RDS/Aurora, DynamoDB, ElastiCache, EMR, Redshift, and Neptune docs. (AWS Documentation)

---

Micro-activity: Match the Architecture Pattern

---

Knowledge Check

---

Summary

This lesson is the bridge from "I know what these services are" to "I can choose the right pattern for a workload." In practice, that is the real skill Unit 4 is trying to build. AWS's docs make the roles clear: Lightsail simplifies small apps, ECS runs containers, CloudFormation manages repeatable infrastructure, DynamoDB handles high-scale NoSQL, RDS/Aurora handle relational data, Redshift handles warehouse analytics, EMR handles big-data processing, Neptune handles graph relationships, and S3 storage classes match object-access patterns over time. (AWS Documentation)

Next lesson

Lesson 4.25: Unit 4 Final Review and Readiness Check