AWS Study Guide: Resource Sizing and Selection Optimization
Selecting the appropriate resource type and size (for example, the amount of Lambda memory) to meet business requirements
Resource Sizing and Selection Optimization
This guide focuses on the critical skill of matching AWS resource types and sizes (EC2, Lambda, RDS) to specific business requirements to balance performance, scalability, and cost.
Learning Objectives
After studying this guide, you should be able to:
- Identify the appropriate EC2 instance family (Compute, Memory, Storage optimized) based on workload characteristics.
- Optimize AWS Lambda performance by adjusting memory allocation.
- Distinguish between vertical and horizontal scaling strategies and when to apply each.
- Leverage AWS tools like Compute Optimizer to right-size existing infrastructure.
- Select cost-effective compute options including Spot Instances, Reserved Instances, and Savings Plans.
Key Terms & Glossary
- ECU (EC2 Compute Unit): A relative measure of integer processing power used to compare different EC2 instance types.
- Horizontal Scaling: Increasing capacity by adding more instances of a resource (e.g., adding more EC2 instances to an Auto Scaling Group).
- Vertical Scaling (Scaling Up): Increasing capacity by increasing the specifications (CPU, RAM) of an existing resource (e.g., changing a
t3.mediumto at3.large). - Server Density: The practice of packing as many virtual applications or microservices as possible into a single host to maximize hardware utilization.
- AMI (Amazon Machine Image): A template that contains the software configuration (OS, application server, and applications) required to launch an instance.
The "Big Idea"
The fundamental goal of resource selection is Performance Efficiency. In AWS, you are not locked into hardware. The instance chosen on day one is a decision that can be revisited every day after, so the question is never "what will this need forever?" but "what does it need now, and how will we notice when that changes?" Right-sizing is a habit rather than a project: measure the resource the workload is actually limited by, buy that one, and measure again after the workload changes.
Key Facts and Comparisons
| Decision | What to measure | What it points to |
|---|---|---|
| Instance family | Which resource saturates first | Compute optimized for processor-bound work; memory optimized for large in-memory datasets; storage optimized for high local disk throughput; general purpose when nothing dominates |
| Instance size | Peak utilization, not average | The smallest size whose peak leaves acceptable headroom |
| Lambda memory | Duration against the memory setting | Memory is also the CPU dial, so a higher setting can cost less overall when duration falls proportionally further |
| Scaling direction | Whether the work divides | Scale out for stateless tiers; scale up where a single writer cannot be split |
| Purchasing model | How predictable demand is | Savings Plans for a steady baseline, Spot for interruptible work, On-Demand for the rest |
Hierarchical Outline
- Establish the constraint
- Collect utilization for processor, memory, network and storage
- Install the CloudWatch agent, because memory is not collected by default
- Choose the family, then the size
- Family follows the constraining resource
- Size follows peak demand, with headroom for the loss of one instance
- Tune serverless separately
- Adjust Lambda memory and read duration and cost together
- Measure again
- Use AWS Compute Optimizer against real utilization history
- Revisit after any significant change to the workload
Visual Anchors
- Picture four dials, one each for processor, memory, network and disk, with only one of them ever near its stop. The family you want is the one that makes that dial bigger.
- Picture the Lambda memory slider as a single control wired to both speed and price. Pushing it right shortens the duration bar, and often the bill with it.
Definition-Example Pairs
- Right-sizing: matching provisioned capacity to measured demand. Example: an instance averaging 8% processor use with a 20% peak moves down two sizes.
- Vertical scaling: increasing an existing resource's specification. Example: a single-writer database moves to a larger instance because its writes cannot be spread.
- Horizontal scaling: adding more interchangeable instances. Example: a stateless web tier grows from four instances to twelve during a sale.
Worked Examples
A processor-bound transcoding fleet. Utilization shows the processor pinned while memory sits at 15%. A compute optimized family buys the constraining resource without paying for memory the workload never touches. Sizing follows the peak, and the fleet scales out because transcoding jobs are independent of one another.
A function slower than expected. A function allocated 256 MB takes four seconds. Raising it to 1,024 MB drops the duration below one second. Because the bill multiplies memory by duration, the faster setting costs about the same or less, and the caller waits a quarter as long.
Checkpoint Questions
- A workload averages 10% processor utilization but misses its deadline every weekday at 09:00. What should you examine before resizing it down?
- Why can increasing a Lambda function's memory allocation reduce its total cost?
- Which constraint would lead you to a memory optimized family rather than a compute optimized one?
- Why is an unattached EBS volume worth finding during a right-sizing review?