Service Selection and Architecture Scenarios
Mixed practice with real-world scenarios requiring service selection, architecture decisions, and trade-off analysis across compute, storage, database, and networking.
30 min
Intermediate
Learning Outcomes
By the end of this lesson, you will be able to:
- Select appropriate AWS services for given requirements
- Justify architecture decisions with clear reasoning
- Identify trade-offs between different service options
- Apply multi-service knowledge to integrated scenarios
Quick Reference: Service Selection Matrix
| Requirement | Primary Options | Selection Criteria |
|---|---|---|
| Virtual server, full control | EC2 | OS-level access needed, long-running |
| Serverless code execution | Lambda | Event-driven, short tasks, no server management |
| Container orchestration | ECS, EKS | Microservices, Docker containers, scaling |
| Object storage | S3 | Files, media, backups, static website assets |
| Block storage for EC2 | EBS | Databases on EC2, boot volumes |
| Managed relational database | RDS | SQL, transactions, joins, complex queries |
| NoSQL, key-value | DynamoDB | High throughput, predictable scale, simple queries |
| In-memory cache | ElastiCache | Session store, frequent reads, sub-millisecond latency |
| CDN | CloudFront | Global content delivery, edge caching |
| DNS | Route 53 | Domain registration, routing policies, health checks |
| Load balancing | ALB, NLB | Distribute traffic, health checks, SSL termination |
| API management | API Gateway | REST APIs, throttling, caching, authentication |
| Queue service | SQS | Decoupling, asynchronous processing, buffering |
| Notification service | SNS | Pub/sub, email, SMS, mobile push |
| Monitoring | CloudWatch | Metrics, logs, alarms, dashboards |
| Infrastructure as code | CloudFormation | Templates, repeatability, version control |
Scenario Category 1: Compute Decisions
Practice
1 / 3Scenario Category 2: Storage Decisions
Practice
1 / 3Scenario Category 3: Database Decisions
Micro-Activity
Match the Database Need to the Service
Connect each requirement to the most appropriate AWS database service.
Examples
Choose one, then match it on the right
Characteristics
Select an example first
0 of 8 matched so far.
Scenario Category 4: Integrated Architecture
Practice
1 / 3Synthesis: Architecture Design Challenge
Think about it
Design an architecture for a mobile fitness tracking app with these requirements:
Functional requirements:
- User profiles and authentication
- Track workouts (GPS, heart rate, time)
- Social features (share workouts, follow friends)
- Real-time leaderboards during events
- Monthly progress reports
Non-functional requirements:
- 1 million daily active users
- 99.9% uptime
- Sub-second API response times
- GDPR compliance (EU data residency)
- Cost-optimized for startup budget
Consider:
- Which services for each functional requirement?
- How do services integrate?
- What's your multi-Region strategy for GDPR?
- Where do you optimize for cost vs performance?
Document your architecture with service choices and reasoning.
Common Anti-Patterns to Avoid
| Anti-Pattern | Why It's Wrong | Better Approach |
|---|---|---|
| Using EC2 for everything | Over-management, missed serverless benefits | Use Lambda for event-driven, ECS for containers |
| One database for all data | Wrong tool for different access patterns | Use purpose-built databases for each need |
| Storing files in relational databases | Blobs don't scale, expensive | Use S3 for files, RDS for metadata |
| Direct database access from client | Security risk, can't scale | Use API Gateway + Lambda/ECS as proxy |
| Ignoring CDN | High latency, origin load, higher costs | Use CloudFront for global users |
| Monolithic everything | Slow deployment, hard to scale | Microservices with clear service boundaries |
| Over-provisioning | Paying for idle capacity | Auto Scaling, serverless, right-sizing |
| No caching layer | Database overload, slow response | Add ElastiCache, CloudFront, API Gateway cache |
Summary
Service selection framework:
- Identify the requirement (compute, storage, database, etc.)
- Consider constraints (latency, scale, budget, expertise)
- Evaluate managed vs self-managed trade-offs
- Design for integration with other services
- Plan for security, monitoring, and cost from day one
Key principles:
- Use the right tool for the job; AWS has 200+ services for a reason
- Prefer managed services to reduce operational burden
- Design for your actual scale, not hypothetical future scale
- Integration between AWS services is usually seamless
- Cost optimize after you achieve required performance and reliability
Final Review Quiz
Knowledge Check
1 / 3