Compute Optimizer Memory Optimization

TL;DR: Memory-optimized r- and x-family instances (r5, r6i, x2…) carry a real RAM premium, and teams default to them "because the database needs memory" then never revisit — an r5.4xlarge with 128 GB running at 35 GB average is renting a 5-bedroom house to live alone. Compute Optimizer's memory recommendations find exactly this over-provisioning. Two hard rules: it can't see memory without the CloudWatch Agent, and you must leave headroom (aim for 60–70% post-change utilization, not an exact fit).

The numbers

• Compute Optimizer only tracks CPU/network/disk by default — memory findings require the CloudWatch Agent sending mem_used_percent; without it, it's blind to RAM.
• Over-provisioned is the most common memory finding — people pick memory-optimized "just in case" and never revisit.
• Worked example: an r6i.xlarge (32 GB) at 8 GB avg / 12 GB peak → m6i.xlarge (16 GB) = $200 → $140/mo ($60/instance); ×10 = $7,200/yr.
• Recommendations can cross families and architectures — r5.large → r6i.large (better price-perf), or x86 → Graviton r7g (often 20–40% cheaper if your software supports ARM).
• Field examples: an EC2 Postgres DB tested r5.4xlarge → r5.2xlarge for $220/mo ($2,640/yr) with identical cache hit rates; 28 over-provisioned microservices dropped m5.large → t3.small for $1,400/mo (one later needed t3.medium back).

Do this

1. Install the CloudWatch Agent first and let it collect memory for at least two weeks — this is step one; skip it and every memory recommendation is limited.
2. Look at average and peak memory, not just average, before accepting a downsize.
3. Leave headroom — if you're at 50% utilization, don't downsize to an exact fit; target 60–70% post-change so a traffic spike or data growth doesn't crash the app.
4. Consider the family/architecture cross-recommendations — moving to a newer family or Graviton often beats a same-family downsize (test ARM compatibility first).
5. Test in staging before production, especially for databases, caches, and latency-sensitive apps — snapshot, run the recommended size against real workload for a week, then cut over; revisit quarterly.

Gotchas

• No agent = no memory visibility — the single most common reason memory recommendations are missing or wrong.
• 14-day lookback misses seasonality — a downsize recommendation right before your busiest quarter can backfire; for variable workloads treat recs as a starting point and add buffer (or use autoscaling).
• Rightsizing is iterative, not set-and-forget — a workload that fits today can outgrow the new size in months; monitor after.
• Savings assume on-demand pricing — RI/SP-covered instances save less.

Skip this if

• Memory usage is highly variable day-to-day and peaks blow past the average — the recommendation based on averages will under-size you; consider Auto Scaling Groups instead.
• You don't actually know what's running on the instances — tag them (app/env/owner) so you can verify before acting. This is the memory-specific lens of Compute Optimizer; pair a rightsize with a move to Graviton for compounding savings.