2.4.1. Compute Optimization: EC2, Placement Groups, and Compute Optimizer
💡 First Principle: The right instance type for the wrong workload wastes money and degrades performance simultaneously. Compute optimization is about alignment — matching instance characteristics (CPU architecture, memory ratio, network bandwidth) to workload requirements.
EC2 Placement Groups solve a different problem: physical placement within a data center affects inter-node latency. For workloads that need high-speed, low-latency communication between instances, physical proximity matters.
| Placement Strategy | Characteristic | Best For |
|---|---|---|
| Cluster | All instances in the same rack in one AZ | HPC, distributed computing, Hadoop, ML training — needs low latency and high throughput |
| Partition | Instances spread across logical partitions (each on separate racks); up to 7 partitions per AZ | Large distributed systems (Cassandra, Kafka, HDFS) — limits correlated hardware failures |
| Spread | Each instance on a distinct rack; max 7 instances per AZ | Small critical workloads that must avoid simultaneous failure (e.g., 3-node clusters) |
Burstable Instances (T-family): T3, T3a, T4g instances earn CPU credits during idle periods and spend them during bursts. This is cost-effective for workloads with low average CPU but occasional spikes (dev environments, web servers with variable traffic).
T3.unlimitedmode: instance can burst beyond credit balance at an extra per-vCPU cost — no throttling, but watch the billT3.standardmode: CPU throttles to baseline when credits are exhausted
AWS Compute Optimizer analyzes CloudWatch metrics for your EC2 instances, Lambda functions, ECS services on Fargate, and Auto Scaling groups, then makes machine learning-based recommendations:
| Recommendation Type | Example |
|---|---|
| Over-provisioned | Your m5.xlarge runs at 8% CPU — right-size to m5.large |
| Under-provisioned | Your c5.large is consistently at 95% CPU — upgrade to c5.xlarge |
| Instance family change | Switch from M-series to C-series for compute-intensive workloads |
Compute Optimizer uses CloudWatch metrics as its data source — specifically the last 14 days by default (up to 3 months with Enhanced Infrastructure Metrics). If an instance is brand new, Compute Optimizer has no recommendations yet. Recommendations are sized against high-percentile (near-peak) utilization rather than the average, and each shows projected utilization on the recommended type so you can confirm headroom before applying it.
EC2 Purchasing Options — match the commitment to the usage shape:
| Option | Discount vs. On-Demand | Fits |
|---|---|---|
| On-Demand | None | Spiky, short-lived or unpredictable usage |
| Reserved Instances (1 or 3 yr) | Up to ~72%; All Upfront > Partial Upfront > No Upfront | Steady 24/7 baseline. RIs can be modified (AZ, size within a family); Standard RIs can also be sold on the RI Marketplace, Convertible RIs exchanged for a different configuration |
| Compute Savings Plans (1 or 3 yr) | Up to ~66% | $/hour commitment applied automatically to any instance family, size, Region, OS or tenancy — and to Fargate and Lambda |
| EC2 Instance Savings Plans (1 or 3 yr) | Up to ~72% | Same commitment, locked to one instance family in one Region |
| Spot Instances | Up to ~90% | Fault-tolerant, checkpointable work; AWS gives a 2-minute interruption notice via instance metadata and EventBridge |
Commitments are billed whether used or not, so cover the always-on floor with RIs or Savings Plans and serve variable demand with On-Demand or Spot (an Auto Scaling mixed instances policy).
Cost visibility: AWS Cost Explorer analyses and forecasts spend by service, account, tag and Region, and reports reservation utilization (how much of what you bought is used) and coverage (how much eligible usage your reservations cover). AWS Budgets alerts on actual or forecasted cost, usage or utilization thresholds and can run Budget Actions (apply an IAM policy or SCP, or stop EC2/RDS instances).
⚠️ Exam Trap: Placement groups have constraints. Cluster placement groups are confined to a single AZ — you can't span AZs. If an EC2 launch fails because no capacity exists in that AZ, the whole cluster placement group launch fails together (insufficient capacity errors are common for cluster groups on larger instance types). Spread placement groups are limited to 7 instances per AZ.
Reflection Question: A distributed machine learning training job needs 64 GPU instances to communicate with each other at maximum network throughput. Which placement group type do you use, and what potential operational risk should you mitigate?
