Resource Optimization

AWS Trusted Advisor analyzes your account against best practices across five categories: cost optimization, performance, security, fault tolerance, and service limits. The cost optimization checks identify immediate savings opportunities.

Key cost checks include: underutilized EC2 instances (less than 10% average CPU over 14 days), idle load balancers (less than 100 requests/day), unattached EBS volumes, low-usage RDS instances, and unused Elastic IPs. Each check provides a severity (warning vs. action recommended), affected resources, and estimated savings.

Underutilized EC2 instances is the most impactful check. An m5.xlarge instance costing $140/month with 5% CPU utilization suggests a t3.medium ($30/month) would suffice. Trusted Advisor reports the estimated monthly savings per instance. Across 50 instances, this check alone might identify $5,000/month in waste.

Unattached EBS volumes accumulate cost silently. An EBS volume detaches when an EC2 instance terminates but persists. A 100GB gp3 volume costs $8/month—10 unattached volumes cost $80/month for nothing. Trusted Advisor lists all unattached volumes with their age and size.

Trusted Advisor tiers: Free tier includes service limits and basic checks. Business tier ($29/month per account) adds all cost and performance checks. Enterprise tier ($100/month per account) adds all checks plus proactive notifications and CloudWatch integration.

Automation: Use the Trusted Advisor API or CloudFormation to automate responses. When the underutilized instances check finds candidates, trigger a Lambda that tags them as OptimizationCandidate=true. A weekly report aggregates all candidates for the team to review and act on.

AWS Compute Optimizer uses machine learning to analyze historical utilization patterns and recommend optimal instance types. Unlike Trusted Advisor (which flags underutilization), Compute Optimizer identifies the right-sized alternative.

EC2 recommendations: For each instance, Compute Optimizer analyzes CPU, memory, network, and disk utilization over 14 days. It recommends: current instance type (no change), a smaller instance type (cost savings), a larger instance type (performance improvement), or a different instance family (better match for workload characteristics). Each recommendation includes projected performance impact and monthly cost change.

Example: An r5.2xlarge ($0.504/hr) running a database shows 30% average memory utilization. Compute Optimizer recommends r5.xlarge ($0.252/hr) with 99% confidence, saving $182/month. The recommendation includes a performance risk assessment—"low risk" means the smaller instance handles peak loads with margin.

Lambda recommendations: Analyze memory allocation vs. actual usage. A Lambda function configured with 3072MB but averaging 512MB usage could be reduced to 1024MB, cutting costs by 66%. Compute Optimizer also recommends duration optimizations—suggesting provisioned concurrency for functions with predictable traffic patterns.

EBS recommendations: Identify volume types that could be changed for cost savings. A gp2 volume provisioned at 1TB with low IOPS usage could be converted to gp3, saving $55/month by removing the included IOPS allocation.

Compute Optimizer is free for all accounts. Enable it in the console, and it begins analyzing existing resources within 24 hours. Use the exported recommendations with AWS Systems Manager Automation to batch-apply changes across hundreds of instances.

Idle resources are the silent budget killers. Unlike underutilized resources (running but inefficient), idle resources consume cost while doing nothing useful.

Common idle resources: Stopped EC2 instances (EBS volumes persist and incur cost), unattached Elastic IPs (charged $0.005/hr after the first free one), idle NAT Gateways ($0.045/hr plus data processing), empty RDS instances (database exists but receives no traffic), and unused CloudWatch Logs log groups with old retention.

Detection strategy: Use AWS Config rules to identify idle resources. The ec2-instance-no-public-ip rule finds instances with public IPs that don't need them. The ebs-volume-attached rule identifies unattached volumes. Create a custom Config rule that checks CloudWatch metrics—if an EC2 instance has 0% CPU for 7 consecutive days, flag it for review.

Rightsizing is the process of matching resource capacity to actual demand. The workflow: identify candidates (Trusted Advisor, Compute Optimizer, custom analysis), validate with the application owner (CPU metrics don't tell you about memory pressure or batch processing spikes), implement changes (resize, change family, or terminate), and monitor the result (verify performance is acceptable).

Instance family selection matters. Compute-optimized (C series) for CPU-intensive workloads. Memory-optimized (R series) for databases and caching. Storage-optimized (I/D series) for high I/O. Burstable (T series) for dev/test and variable workloads. A general-purpose M series handles most workloads. Choosing the wrong family wastes money—a memory-intensive workload on a compute-optimized instance needs more instances than necessary.

Practical example: A team runs 20 m5.2xlarge instances for a web application. Analysis shows peak CPU of 40% and average of 15%. Action plan: rightsize to m5.xlarge (saves 50%), then consider Graviton (m6g.xlarge) for 20% additional savings. Total monthly savings: from $5,645 to $2,258—a 60% reduction.

Lambda power tuning is a Step Functions-based tool that runs your Lambda function at multiple memory configurations and visualizes the cost-performance tradeoff. Deploy the state machine, point it at your function, and it runs the function 5 times at each memory level (128MB, 256MB, 512MB, 1024MB, 1536MB, 3000MB).

The results show a chart of duration vs. cost at each memory level. Most functions have a sweet spot—doubling memory might halve duration, keeping cost constant but improving latency. Going beyond the sweet spot wastes money with diminishing returns. For example, a function at 256MB runs in 3 seconds ($0.0000042). At 1024MB, it runs in 0.8 seconds ($0.0000053). At 3000MB, it runs in 0.5 seconds ($0.0000117). The 1026MB option is 26% cheaper at the same latency.

Lambda cost factors: You pay per request ($0.20 per 1M) and per GB-second ($0.0000166667). Reducing memory reduces GB-second cost but may increase duration. Power tuning finds the optimal balance.

S3 Storage Lens provides organization-wide visibility into storage usage and costs. It analyzes metrics across all buckets in an account or organization and generates dashboards showing: total storage by class, incomplete multipart uploads (wasted cost), lifecycle rule coverage, encryption status, and access patterns.

Storage Lens insights identify optimization opportunities. A common finding: incomplete multipart uploads from failed uploads consuming 50GB across all buckets. Lifecycle rules can automatically delete these after 7 days. Another finding: 1TB of S3 Standard data with no access in 90 days could transition to S3 Intelligent-Tiering ($45/month → $12.50/month).

Storage Lens advanced metrics include access pattern analysis. S3 Intelligent-Tiering automatically moves objects between frequent access and infrequent access tiers based on usage. Storage Lens shows how many objects are in each tier, enabling you to predict costs and validate that the auto-tiering is working correctly.

Cost: S3 Storage Lens free tier includes basic metrics. Advanced metrics cost $0.02 per million objects monitored per month. For an account with 10 million objects, advanced metrics cost $20/month—a small price for visibility that often identifies hundreds in savings.