Exam Guide: Solutions Architect - Associate
⚡ Domain 4: Design Cost-Optimized Architectures
📘 Task Statement 4.2
🎯 Designing Compute Optimized Solutions is about choosing compute that meets performance and availability needs at the lowest reasonable cost.
First decide what type of compute the workload needs (EC2, Lambda, Fargate, containers, edge, hybrid), then choose how to pay for it, then right-size and scale it so you are not paying for idle capacity.
You are balancing:
1 Performance
2 Availability
3 Elasticity
4 Operational Overhead
5 Purchasing Model
Knowledge
1 | AWS Cost Management Service Features
Cost Allocation Tags And Multi-Account Billing
These help you understand and allocate compute cost.
1.1 Cost Allocation Tags
- Track compute spend by app, team, environment, owner, cost center
1.2 Multi-Account Billing | Consolidated Billing
- Manage cost centrally across multiple AWS accounts
- Often used with AWS Organizations
2 | AWS Cost Management Tools
Cost Explorer, Budgets, CUR
1 Cost Explorer: Analyse historical spend and trends
2 AWS Budgets: Alert when spending or usage exceeds thresholds
3 AWS Cost and Usage Report (CUR): Detailed raw billing data for deeper optimization analysis
3 | AWS Global Infrastructure
Regions & Availability Zones (AZs)
Cost and performance can both change based on placement:
1 Running in multiple AZs may cost more, but is often required for production HA
2 Data transfer between Regions can add cost
3 Some workloads can stay single-AZ if non-critical and cheaper
Production → usually Multi-AZ
Dev or test or batch → sometimes cheaper single-AZ is acceptable
4 | AWS Purchasing Options
Spot, Reserved Instances, Savings Plans
4.1 On-Demand
- Pay as you go
- Flexible, no commitment
- Best for short-term or unpredictable usage
“Unpredictable short-term workload” → On-Demand
4.2 Spot Instances
- Deep discount for interruptible EC2 capacity
- Best for fault-tolerant, stateless, flexible workloads
“Interruptible batch/stateless jobs” → Spot
4.3 Reserved Instances (RIs)
- Lower cost for long-term predictable EC2/RDS usage
- Capacity reservation options in some cases
4.4 Savings Plans
- Flexible pricing commitment across services or instance families (depending on type)
- Often simpler and flexible than RIs
“Steady production workload for 1–3 years” → Savings Plans or RIs
5 | Distributed Compute Strategies
Edge Processing
Sometimes cheaper and faster architecture comes from moving compute closer to users or reducing origin load.
Examples:
- CloudFront Functions / Lambda@Edge for lightweight logic at the edge
- CloudFront caching reduces origin compute cost
6 | Hybrid Compute Options
Outposts & Snowball Edge
6.1 AWS Outposts
- Run AWS infrastructure and services on-prem
- Used when low latency to on-prem systems or data residency and local processing is needed
6.2 AWS Snowball Edge
- Physical device for data transfer and edge compute
- Useful in disconnected, harsh and remote environments or massive offline migration
7 | Instance Types, Families, And Sizes
Memory Optimized, Compute Optimized, Virtualizationn
The basics:
| Workload | Family |
|---|---|
| General Purpose | t, m |
| Compute Optimized | c |
| Memory Optimized | r, x |
| Storage Optimized | i, d, some specialized families |
| GPU / ML / graphics | p, g |
Cost Mindset
1 Don’t choose memory-optimized if CPU-bound
2 Don’t over-size “just in case”, rather consider scaling options
3 Burstable (T family) can be cost-effective for low and variable baseline usage
8 | Optimization of Compute Utilization
Containers, Serverless, Microservices
Cost optimization often comes from better utilization:
1. Containers pack workloads more efficiently onto shared compute
2. Fargate avoids paying for idle EC2 hosts you manage yourself
3. Lambda is great for spiky or short-lived workloads
4. Microservices can scale only the busy components, not the whole app
9 | Scaling Strategies
Auto Scaling & Hibernation
9.1 Auto Scaling
- Scale out when demand rises, scale in when demand drops
- Avoid paying for idle peak capacity all day
9.2 EC2 hibernation
- Suspend instance and resume later with RAM state preserved
- Useful for dev AND test or intermittent workloads where startup time matters
“Need to pause and resume instance to save cost” → hibernation (if supported).
Skills
A | Determine An Appropriate Load Balancing Strategy
ALB vs NLB vs GWLB
1 Application Load Balancer (ALB)
Best for:
- HTTP/HTTPS
- Path-based and host-based routing
- Layer 7 application routing
2 Network Load Balancer (NLB)
Best for:
- TCP/UDP/TLS
- Very high performance and static IPs
- Layer 4 routing
3 Gateway Load Balancer
Best for:
-Deploying and scaling virtual appliances such as firewalls and inspection tools
Choose the simplest load balancer that meets protocol/routing needs.
B | Determine Appropriate Scaling Methods And Strategies For Elastic Workloads
Horizontal vs Vertical, Hibernation
1 Horizontal scaling
- Add more instances/tasks/functions
- Usually better for elasticity and resilience
2 Vertical Scaling
- Make the instance bigger
- Simpler, but less elastic
Production web app → *horizontal scaling *
3 Hibernation
- Save money on intermittent EC2 workloads that should resume quickly
Short-lived or intermittent workload → maybe hibernation / scheduled scaling
C | Determine Cost-Effective AWS Compute Services
Lambda, EC2, Fargate
1 Lambda
Best when:
- Event-driven
- Short-running
- Spiky and unpredictable
- Minimal ops desired
2 EC2
Best when:
- Long-running steady workloads
- Need OS control
- Can benefit from RIs/Savings Plans/Spot combinations
3 Fargate
Best when:
- Containers are needed
- Want to avoid managing EC2 hosts
- Moderate-to-variable workload patterns
D | Determine The Required Availability For Different Classes Of Workloads
Production vs Non-Production
Not every workload needs the same cost level.
1 Production
- Usually Multi-AZ,
- Auto Scaling,
- HA
- More expensive but justified
2 Non-Production / Dev / Test
- Smaller instances
- Single-AZ
- Scheduled shutdown/startup
- Spot-friendly
- Hibernated/stopped when unused
E | Select The Appropriate Instance Family
Examples:
1. CPU-heavy app → C family
2. Memory-heavy app → R family
3. Small and variable baseline → T family
4. General purpose app → M family
F | Select The Appropriate Instance Size
Right-sizing principles:
1 Start from actual CPU, memory and network needs
2 Use monitoring to reduce overprovisioning
3 Scale horizontally where possible instead of using one oversized box
Cheat Sheet
| Requirement | Compute |
|---|---|
| Steady long-term workload | Savings Plans / Reserved Instances |
| Interruptible batch or fault-tolerant workload | Spot Instances |
| Spiky event-driven workload | Lambda |
| Containerized app, no server management | Fargate |
| Need OS control or legacy app | EC2 |
| Low and variable baseline workload | T family |
| Compute-heavy workload | C family |
| Memory-heavy workload | R family |
| Pause or resume EC2 to save cost | EC2 hibernation |
| HTTP/HTTPS routing with app logic | ALB |
| TCP/UDP with static IPs/high performance | NLB |
| Virtual network appliances | Gateway Load Balancer |
Recap Checklist ✅
1. [ ] I can choose the right compute service (EC2 vs Lambda vs Fargate) based on workload pattern
2. [ ] I understand when to use On-Demand, Spot, Reserved Instances, and Savings Plans
3. [ ] I can right-size EC2 by family and size instead of overprovisioning
4. [ ] I know when horizontal scaling is more cost-effective than vertical scaling
5. [ ] I can differentiate production vs non-production availability requirements
6. [ ] I know when hibernation or scheduled scaling can reduce cost
7. [ ] I can choose the right load balancer (ALB vs NLB vs GWLB) based on protocol and need
8. [ ] I understand how tags and cost tools help track and manage compute spending
AWS Whitepapers and Official Documentation
Compute always has so many resources.
Cost Visibility And Management
1. Cost Explorer
2. AWS Budgets
3. Cost and Usage Report (CUR)
4. Cost Allocation Tags
Compute Pricing Options
1. Spot Instances
2. Reserved Instances
3. Savings Plans
Compute Services
1. EC2
2. Lambda
3. Fargate
4. ECS
5. EKS
Scaling And Optimization
1. EC2 Auto Scaling
2. EC2 Hibernation
3. EC2 instance types
4. Burstable instances
5. Compute Optimizer
Load Balancing
1. Application Load Balancer
2. Network Load Balancer
3. Gateway Load Balancer
Edge And Hybrid Compute
1. CloudFront Functions
2. Lambda@Edge
3. AWS Outposts
4. AWS Snowball Edge And Snow Family
🚀
Top comments (0)