Design Cost-Optimized Compute Solutions

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:

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

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

🚀