AWS rightsizing with Terraform: a practical 2026 guide

A rightsizing pass on AWS is the highest-leverage first action most estates can run — underutilized workloads usually outnumber idle ones by 4:1, the saving lands without a single user-facing change, and the diff is small enough that a finance reviewer signs off on it without a separate evidence harvest. The right Terraform module, the right scoring threshold and the right PR-loop discipline are what make the pass repeatable instead of one-off. This guide is the on-page runbook the Tallywyrm agent uses when one of our customers hands us the keys to a real AWS account on which they have never run a rightsizing pass. It distils what an hourly loop actually does — p95-based sizing, Graviton family swaps where applicable, idle-resource hygiene before sizing, scoring thresholds that survive a finance review — and how to ship the resulting diff back as IaC pull requests that land cleanly against the Terraform, Pulumi and Crossplane repos (/integrations) the agent already targets. Why p95, not average The single biggest mistake in a first-time rightsizing pass is picking a target instance family off average CPU. Average utilization on a load-balanced stateless service tells you almost nothing about whether your smallest instance type still fits the workload's tail-latency budget; p95 latency under peak is what your SLO actually depends on. Always pick a target whose p95 CPU + memory headroom still satisfies the workload's contract. Right-sizing against mean is the failure mode that produces a 4pm Friday outage on the next retail spike. The two mistakes that turn a correct rightsizing pass into a deployment fire: Targets picked by average, not p95. Average CPU on a stateless service tells you almost nothing; p95 + a safety margin is what your SLO depends on. Always size against trailing 14-30 day p95 CPU, p95 memory, and p95 network. The instance family ignored. T3 → T4g on AWS Graviton is usually 20% additional saving on top of the rightsizing delta, but the AMI has to be rebuilt for arm64 (or shipped multi-arch) before the family change lands in your IaC module. The family question gets paired with the rightsizing question in the PR description so the reviewer knows the platform implication before approving. The Terraform shape: the smallest diff that lands a rightsizing change The Terraform delta for an RDS rightsizing pass is a one-line instance_class swap with apply_immediately = true so the change rolls without a maintenance window. The PR description carries the trailing-usage numbers, the target instance family and the rollback path — a single PR reverting the instance_class line. The same audit trail the multi-cloud playbook describes (PR diff, deploy timestamp, post-deploy measurement) applies end to end: Idle-resource hygiene comes before sizing The order of operations matters. An idle-resource pass (delete pure waste — NAT gateways with no traffic, EBS volumes with no readers, SNS topics with no subscribers) lands first, because every resource that survives that pass is one the workload actually uses and is therefore a candidate for sizing rather than deletion. Skipping this step and going straight to rightsizing is the second-most-common failure: you end up with a smaller instance still doing no useful work, and finance still pays the bill. The Terraform delta for an idle-resource pass is the deletion of the resource plus any route-table or IAM attachment that pointed at it. The PR is simpler than a rightsizing PR because the rollback path is "recreate from snapshot / re-attach" — a single API call, no stateful change: NAT gateways: the highest-value single row A NAT gateway with zero egress traffic over a trailing 30 days is pure waste — you pay $32-45/month per gateway plus $32-45/GB processed for a meter that reads zero. The audit is straightforward: read VPC Flow Logs (https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) for the NAT gateway's elastic network interface, sum the egress bytes, score against your team-level threshold. Survivors become rows of the weekly report; everything below the threshold goes to the long-tail CSV for next cycle's review: Scoring thresholds in dollars and blast radius Every recommendation enters the queue under a score. The score is a function of two things: projected monthly saving in dollars and blast radius tier multiplied by (1 plus rollback complexity). The threshold for a candidate to survive is calibrated per team — a sensible default is sixty. Below the threshold, the candidate goes to the long-tail CSV. Above the threshold, it becomes a row of the report finance signs off on. The blast-radius buckets we ship: Tier 1. A single resource in a single account. NAT gateway with no traffic, orphan EBS volume, idle Pub/Sub topic. Score cost = 1. Tier 2. A small fleet, fan-out known. Two to ten RDS instances of the same family. Score cost = 2. Tier 3. A fleet spanning multiple accounts or regions. Score cost = 4. Tier 4. Platform-tier or controlled by another team. Score cost = 8. We default to drop these from the report unless the customer has explicitly approved the cross-team review path. The two numbers compose: the total denominator is the blast radius tier multiplied by (1 plus rollback complexity). A rightsizing PR against a single Tier 1 RDS instance with a one-line family change lands at (1 * 2) = 2 denominator; the projected dollar saving needs to clear that bar. Why the PR loop matters as much as the threshold Once a candidate survives the threshold, the agent opens a pull request against the Terraform / Pulumi / Crossplane module that owns the resource. The PR description carries the trailing-usage numbers, the target, the rollback path and the 7-day verification window. The reviewer, approver and merge decision are yours; the agent never holds a merge token, never bypasses a required approver, and never applies against your account. The PR loop is the same loop the multi-cloud waste audit playbook (/blog/multi-cloud-waste-audit-playbook) describes: PR to human approver to merge to post-deploy measurement to weekly report. The audit reads the workload a week after the rightsizing change went live and confirms the bill actually dropped the forecasted amount. Workloads that regressed are removed from the next invoice. Verification: the bar for "verified" savings A saving is only counted when, a week after the rightsizing change went live, the platform re-reads the workload and confirms the bill actually dropped. The verification window is one week by default; the workload's trailing-usage signal at day 7 is read against the same signal at day 0, and the delta is recorded as either confirmed or regression. Confirmed savings flow through to the next invoice; regressions are removed. The same verification export finance already reconciles against — entry-level CSV with PR, deploy timestamp and measurement — is the artifact SOC 2 Type II assessors and EU CSRD reporters (/security) already accept without modification. The reviewer does not need to compile a new evidence harvest; the audit-trail export is already the right shape. From playbook to the agent loop The single highest-leverage next step is to instrument the four cost levers (idle hygiene, rightsizing, reservations, savings plans) as concrete Terraform modules your team can review. Once the modules exist — one per resource family, callable from your existing repo — the agent has a stable surface to write changes against, and your team has a stable surface to review changes from. After that, the audit-trail evidence becomes a signed CSV exported weekly with a manifest mapping every row to its source PR and measurement. That CSV is what a SOC 2 auditor, a CSRD reporter and your finance team sign off on without needing a separate evidence harvest. For the curated, per-resource action library that drives the playbooks control plane the agent uses (/dashboard/playbooks), the dashboard ships the same idempotent surface this guide describes — the same scoring thresholds, the same blast-radius buckets, the same evidence map. New pillars land as the practice evolves — start with the FAQ (/faq) for the security, credential scope and percentage-of-savings pricing questions, then talk to the team (mailto:tallywyrm@polsia.app) about a real audit on one of your own accounts.

AWS rightsizing with Terraform: a practical 2026 guide

Send us your last month’s bill. We’ll show you what the agent finds.

Azure rightsizing with Terraform: a practical 2026 guide

GCP rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide

Related pillars

Send us your last month’s bill. We’ll show you what the agent finds.

Related posts

Azure rightsizing with Terraform: a practical 2026 guide

GCP rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook