AWS Cost-Conscious Architecture Study Guide
Cost-conscious architecture choices (for example, using Spot Instances, scaling policies, and rightsizing resources)
AWS Cost-Conscious Architecture Study Guide
This guide covers the critical architectural strategies for cost optimization within AWS, focusing on purchasing models, resource rightsizing, and elastic scaling as defined in the SAP-C02 exam objectives.
Learning Objectives
After studying this guide, you should be able to:
- Differentiate between AWS purchasing models (On-Demand, Spot, RIs, and Savings Plans) based on workload characteristics.
- Apply rightsizing principles using AWS Compute Optimizer and S3 Storage Lens.
- Design elastic scaling strategies that align resource provision with real-time demand.
- Implement cost visibility and governance using tagging, AWS Budgets, and Cost Explorer.
Key Terms & Glossary
- Spot Instances: Spare compute capacity available at up to 90% discount, subject to reclamation by AWS with a 2-minute warning.
- Rightsizing: The process of matching instance sizes and types to your workload performance and capacity requirements at the lowest possible cost.
- Savings Plans: A flexible pricing model that offers low prices on EC2, Lambda, and Fargate usage in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3-year term.
- Instance Fleets: A configuration for Auto Scaling or EMR that allows you to specify multiple instance types and purchasing options to increase availability and optimize cost.
- Cost Allocation Tags: Metadata assigned to resources (e.g.,
Project: Alpha) used to categorize and track AWS costs on a granular level.
The "Big Idea"
In traditional on-premises environments, "cost" is a capital expenditure (CapEx) handled during procurement. In AWS, Cost is a Performance Metric. An architect's goal is not just to build a functional system, but to build one that is "cost-optimized"—meaning every dollar spent contributes directly to business value. This requires moving from a "static provisioning" mindset to a "dynamic consumption" mindset.
Formula / Concept Box
| Service / Concept | Cost Driver Formula / Rule |
|---|---|
| AWS Lambda | $Total Cost = (Requests \times Rate) + (Duration \times Provisioned Memory \times Rate) |
| Spot Savings | Savings % = \frac{On-Demand Price - Spot Price}{On-Demand Price} \times 100 |
| Rightsizing Rule | If average CPU/RAM utilization is < 40%$ over 4 weeks, the resource is a candidate for downscaling. |
Hierarchical Outline
- AWS Purchasing Models
- On-Demand: Highest flexibility, no commitment, highest cost. Best for new, unpredictable workloads.
- Reserved Instances (RI): Commitment-based (1 or 3 years). Best for steady-state workloads.
- Savings Plans: More flexible than RIs (applies across instance families). Best for evolving architectures.
- Spot Instances: Up to 90% savings. Best for fault-tolerant, stateless, or batch workloads.
- Rightsizing Strategies
- Compute Optimizer: Uses ML to analyze historical metrics and suggest optimal EC2, EBS, and Lambda configurations.
- Storage Tiering: Using S3 Intelligent-Tiering or lifecycle policies to move data to lower-cost tiers (Glacier) automatically.
- Elasticity and Scaling
- Horizontal Scaling: Adding/removing instances via Auto Scaling Groups (ASG) based on CloudWatch metrics.
- Scheduled Scaling: Predicting known traffic spikes (e.g., Black Friday) to pre-provision capacity.
- Cost Governance
- Visibility Tools: Cost Explorer (trends), Trusted Advisor (idle resources), and AWS Budgets (threshold alerts).
- Multi-Account Strategy: Using AWS Organizations and Consolidated Billing to maximize volume discounts.
Visual Anchors
Pricing Model Decision Tree
Demand vs. Capacity Optimization
\begin{tikzpicture}[scale=0.8] % Axes \draw[->] (0,0) -- (6,0) node[right] {Time}; \draw[->] (0,0) -- (0,5) node[above] {Capacity/Demand};
% Demand Curve (Sine-like) \draw[blue, thick] (0,1) .. controls (1,4) and (3,0) .. (5,4) node[right] {\small Actual Demand};
% Traditional Fixed Capacity \draw[red, dashed] (0,4.5) -- (5,4.5) node[right] {\small Fixed Provisioning (Waste)};
% Auto-Scaling Capacity \draw[green!60!black, thick] (0,1.2) -- (0.5,1.2) -- (1,4.2) -- (2.5,4.2) -- (3,1.2) -- (4,1.2) -- (5,4.2) node[above] {\small Auto-Scaling};
% Legend \node[draw, anchor=north west] at (0.5,5.5) {\small Green = Cost Efficiency}; \end{tikzpicture}
Definition-Example Pairs
- Term: Stateless Workload
- Definition: An application where no data is stored locally on the server; any instance can handle any request.
- Example: A web fleet where session data is stored in ElastiCache/DynamoDB, allowing Spot Instances to be terminated without losing user data.
- Term: Storage Lens
- Definition: A feature that provides organization-wide visibility into S3 storage usage and activity.
- Example: Identifying buckets that have "non-current version" bloat and applying a lifecycle policy to delete them, saving thousands in monthly storage fees.
Worked Examples
Example 1: Converting Batch Jobs to Spot
Scenario: A company runs an ETL (Extract, Transform, Load) job every night that takes 4 hours on 10 m5.xlarge On-Demand instances ($0.192/hr each).
- Current Cost: $10 \times 4 \times 0.192 = $7.68$ per night.
- Spot Optimization: Converting to Spot Instances at a 70% discount.
- New Cost: $10 \times 4 \times (0.192 \times 0.30) = $2.30$ per night.
- Implementation: The architect must ensure the ETL job can checkpoint its progress so that if an instance is reclaimed, the next one starts where the last left off.
Example 2: Rightsizing with Compute Optimizer
Scenario: An m5.2xlarge instance shows consistent CPU utilization of 5% and Memory usage of 10%.
- Analysis: AWS Compute Optimizer flags this as "Over-provisioned."
- Recommendation: Switch to a
t3.mediumorm5.large. - Result: Monthly cost drops from ~$280 to ~$30, a 90% reduction for that specific resource.
Checkpoint Questions
- Which pricing model is most appropriate for a baseline database server that must be available 24/7 for the next two years?
- What is the minimum notification time AWS provides before reclaiming a Spot Instance?
- How does AWS Lambda's pricing differ from EC2 in terms of granularity?
- Which tool would you use to find idle Elastic Load Balancers (ELBs)?
Muddy Points & Cross-Refs
- RI vs. Savings Plans: RIs are often tied to specific instance types/regions (Standard RI), while Savings Plans apply automatically to any instance family, even if you switch from C5 to M5. Rule of thumb: Choose Savings Plans for compute flexibility.
- Spot Interruption: Many students fear Spot because of the 2-minute warning. Study Pointer: Look into "Spot Fleet" and "Capacity-optimized" allocation strategies to minimize the frequency of interruptions.
Comparison Tables
Comparison of Purchasing Models
| Feature | On-Demand | Reserved Instances | Savings Plans | Spot Instances |
|---|---|---|---|---|
| Cost Savings | 0% (Baseline) | Up to 72% | Up to 72% | Up to 90% |
| Commitment | None | 1 or 3 Years | 1 or 3 Years | None |
| Flexibility | High | Low (unless Convertible) | High | Low (AWS can terminate) |
| Best Use Case | Short-term, Spiky | Steady-state | Evolving Compute | Batch, Fault-tolerant |
[!IMPORTANT] Always prioritize Rightsizing before applying Savings Plans. If you commit to a 3-year plan for over-provisioned resources, you are "locking in" waste.