Why Manual Rightsizing Fails (And How It Breaks Production)
The fear of attempting rightsizing without breaking production is rational. It stems from a common failure pattern: an engineer, pressured by a high cloud bill, logs into the AWS console, finds an oversized instance based on a week of CPU data, and downsizes it from an m5.4xlarge to an m5.2xlarge. For three days, everything works. On the fourth day, a month-end batch job kicks in, exhausts the machine’s memory, and crashes the application. The emergency rollback costs more in engineering time and lost trust than the initial change ever saved. This isn’t a technical failure; it’s a data and process failure.
The core problem is incomplete data. A simple CPU utilization chart from AWS Cost Explorer or Azure Monitor doesn’t capture memory usage, network I/O, disk throughput, or crucial application-specific metrics like queue depth or transaction latency. More importantly, it misses temporal patterns. A development server might look idle all week but see heavy use during CI/CD runs on Friday afternoons. Rightsizing based on averages is a gamble.
The Data You Actually Need Before Making a Change
- Long-Term Baselines: Minimum 30 days of performance data covering a full business cycle (e.g., month-end processing, weekly reporting jobs).
- Multi-Dimensional Metrics: CPU is the most common metric, but memory pressure is often the first thing to break a downsized instance. You need CPU, Memory, Network I/O, and Disk IOPS.
- Application-Level KPIs: Correlate infrastructure metrics with application performance. A 5% drop in CPU might correspond to a 200ms increase in API response time, which is an unacceptable trade-off.
- Dependency Mapping: Understand which other services depend on the instance. Downsizing a shared database server can have cascading performance impacts across multiple applications.
A Technical Guide to Rightsizing Without Breaking Production
A safe rightsizing process is not a one-click action; it’s a methodical, data-backed validation loop. For teams operating primarily on AWS, native tools provide the starting point for this analysis. They are not a complete solution, but they are the first step away from guessing.
Step 1: Use AWS Compute Optimizer for Initial Recommendations
AWS Compute Optimizer analyzes CloudWatch metrics over a 14-day period to generate initial rightsizing recommendations. It’s a significant improvement over manual analysis but requires validation. I run this command to get a baseline list of candidates; it’s the start of an investigation, not the end.
# Find EC2 instances that AWS has flagged as overprovisioned
aws compute-optimizer get-ec2-instance-recommendations \
--filters name=finding,values=Overprovisioned \
--query "instanceRecommendations[*].{InstanceArn:instanceArn,Current:currentInstanceType,Recommended:recommendationOptions[0].instanceType,Saving:recommendationOptions[0].estimatedMonthlySavings.value}" \
--output tableThe output gives you a target list, but you cannot act on it blindly. The 14-day lookback window might miss a critical monthly job. The next step is to validate the recommendation with deeper metrics.
Step 2: Manually Verify with Granular CloudWatch Metrics
Before accepting a recommendation, pull granular, long-term data for the specific instance. For a critical workload, I always check the maximum CPU and memory utilization over at least 30 days, not just the average. This command helps spot the peaks that Compute Optimizer’s averages might smooth over.
# Get the MAXIMUM CPU utilization over the last 30 days for a specific instance
# This helps identify peak loads that an average-based analysis would miss.
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time $(date -v-30d +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date +%Y-%m-%dT%H:%M:%SZ) \
--period 86400 \
--statistics Maximum \
--output textIf the maximum utilization is still well below the current instance capacity, you can proceed with a planned change during a maintenance window. This manual, per-instance verification is the foundation of safe rightsizing. However, it doesn’t scale. At 80+ VMs across two providers, this is where native tooling stops being enough and starts being a liability.
Scaling Safe Rightsizing with Automation
The manual process described above is safe but slow. It’s untenable for a team managing hundreds of instances, especially across multiple clouds. This is the operational gap that automated FinOps platforms address. While native tools like AWS Compute Optimizer or Azure Advisor provide recommendations, they place the burden of validation, implementation, and risk assessment entirely on your team.
An automated platform continuously analyzes a much wider set of metrics over longer periods. It can correlate infrastructure performance with known application cycles (e.g., ignoring high CPU during scheduled backup windows) and automate the change management process. For non-production environments, this can be coupled with scheduling to shut down resources overnight, which often yields significant savings. You can learn more about automated instance scheduling for non-prod environments.
Thalaxo is built to automate this validation loop. It ingests metrics, establishes performance baselines over configurable periods, and maps dependencies to predict the blast radius of a change. The platform’s recommendations are based on sustained low usage (e.g., CPU < 20% for 7+ days), not just short-term averages. For teams managing multi-cloud environments, a centralized platform becomes essential. Thalaxo supports AWS, Azure, and GCP, providing a single view of optimization opportunities that native tools, by design, cannot offer. You can see the full list on our integrations page.
As a newer platform launched in 2025, Thalaxo’s primary limitation is that some advanced features, like Kubernetes workload-level cost allocation, are still on the public roadmap for Q3 2026. While its SOC 2 Type I is complete, the Type II audit is currently in progress. For organizations with deep, single-provider investments and strict compliance needs that demand a finished SOC 2 Type II report today, native tools combined with a rigorous manual process remain the default. For everyone else managing a growing, multi-cloud footprint, automation is the only scalable path to effective rightsizing. Explore the different tiers on our pricing page to see how it maps to different team sizes.
