AWS Service Decision Guides

When to use this guide: This is reference material designed for Phases 3-5 of the bootcamp (Weeks 4-8). If you're in Weeks 1-3, bookmark this page and return when you begin designing architectures. You won't fully appreciate these comparisons until you have hands-on experience with the underlying services.

How to use this guide: When you need to choose between similar AWS services (e.g., Lambda vs ECS, RDS vs DynamoDB), find the relevant decision table below. Start with the workload requirements, not the service. Read the "Choose X when..." recommendations at the bottom of each table. If you're still unsure, work through the scenario examples.

Compute: Lambda vs. ECS vs. EC2

Choose Lambda when you have event-driven workloads, APIs with variable traffic, or data processing triggered by S3/SQS/DynamoDB events.

Choose ECS (Fargate) when you need long-running services, consistent baseline traffic, or container-based microservices without managing servers.

Choose EC2 when you need full OS access, GPU instances, specific kernel configurations, or are running legacy applications that cannot be containerized.

Scenario examples:

Database: RDS vs. DynamoDB vs. ElastiCache

Choose RDS when you need complex queries with joins, ACID transactions, or your team has strong SQL expertise.

Choose DynamoDB when you have well-defined access patterns, need single-digit millisecond latency at any scale, or want zero operational overhead.

Choose ElastiCache when you need sub-millisecond reads for frequently accessed data, session management, or real-time leaderboards. Use it alongside RDS or DynamoDB, not as a replacement.

Scenario examples:

Storage: S3 vs. EBS vs. EFS

Choose S3 for static website hosting, backups, data lakes, and any data accessed via HTTP. Use lifecycle policies to move infrequently accessed data to cheaper storage classes.

Choose EBS for EC2 boot volumes, databases (RDS uses EBS under the hood), and any workload requiring low-latency block storage attached to a single instance.

Choose EFS when multiple compute resources (EC2 instances, ECS tasks, Lambda functions) need shared file access.

Scenario examples:

Load Balancer: ALB vs. NLB vs. CLB

Choose ALB for HTTP/HTTPS workloads, REST APIs, microservices with path-based routing, or any application that needs Layer 7 features.

Choose NLB for TCP/UDP workloads, extreme performance requirements, static IPs, or when you need to preserve the client source IP.

Avoid CLB for new architectures. It exists for backward compatibility only.

Scenario examples:

Messaging: SQS vs. SNS vs. EventBridge

Choose SQS when you need to decouple a producer from a consumer, buffer traffic spikes, or guarantee at-least-once processing with retries.

Choose SNS when you need to fan out a single event to multiple subscribers (email, SQS queues, Lambda functions, HTTP endpoints).

Choose EventBridge when you need content-based routing (filter events by fields), cross-account event delivery, or integration with SaaS providers.

Common pattern: SNS → SQS fan-out. Publish to an SNS topic, subscribe multiple SQS queues. Each queue processes the event independently.

Scenario examples:

IaC: CloudFormation vs. SAM vs. CDK vs. Terraform

Choose CloudFormation when you need direct, declarative YAML/JSON templates and your team prefers configuration over code.

Choose SAM when building serverless applications. SAM shorthand reduces boilerplate for Lambda, API Gateway, and DynamoDB resources.

Choose CDK when you need programming constructs (loops, conditionals, abstractions) or your team prefers writing infrastructure in a familiar language.

Choose Terraform when you manage resources across multiple cloud providers or your organization has standardized on Terraform.

Security: Security Groups vs. NACLs

Use security groups as your primary firewall. They are stateful, easier to manage, and sufficient for most use cases.

Add NACLs as a secondary defense layer when you need to explicitly deny traffic from specific IP ranges or add subnet-level controls.

DR Strategy: Backup & Restore vs. Pilot Light vs. Warm Standby vs. Active-Active

Choose Backup & Restore for non-critical workloads where hours of downtime are acceptable.

Choose Pilot Light when you need faster recovery than backup/restore but want to minimize cost. Core infrastructure runs at minimum capacity and scales up during failover.

Choose Warm Standby for business-critical workloads that need recovery in minutes. A scaled-down copy of the production environment runs continuously.

Choose Active-Active for mission-critical workloads with near-zero tolerance for downtime. Traffic is served from multiple regions simultaneously.

Scenario examples:

Quick Reference: Which Service for Which Job?

AWS Bootcamp: From Novice to Architect Author: Samuel Ogunti License: CC BY-NC 4.0