AWS Study Guide: Identifying and Decommissioning Unused Resources
Using AWS solutions to identify unused resources
AWS Study Guide: Identifying and Decommissioning Unused Resources
Cost optimization is a core pillar of the AWS Well-Architected Framework. Identifying unused or underutilized resources is a continuous operational task required to maintain a lean, cost-efficient infrastructure.
Learning Objectives
After studying this guide, you should be able to:
- Implement a tagging strategy to track resource lifecycle and ownership.
- Utilize AWS monitoring tools like CloudWatch and Trusted Advisor to identify idle resources.
- Explain the role of AWS Compute Optimizer in right-sizing workloads.
- Design an automated decommissioning process to reduce manual overhead and human error.
Key Terms & Glossary
- Right-sizing: The process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost.
- Orphaned Resources: Resources (like EBS volumes or Elastic IPs) that remain active and incur costs even after the parent resource (like an EC2 instance) has been terminated.
- Decommissioning: The formal process of removing a resource from service and terminating it to stop billing.
- Cost Allocation Tags: Specific tags used to organize your resource costs on your cost allocation report to track specific business units or projects.
The "Big Idea"
Cost optimization is not a one-off event; it is a continuous lifecycle. As workloads evolve, resources that were once necessary may become "ghost" costs. By integrating automated tracking (tagging) with proactive analysis (Compute Optimizer), architects can move from reactive billing shocks to a proactive "pay-for-what-you-need" model.
Formula / Concept Box
| Tool | Primary Detection Signal | Actionable Outcome |
|---|---|---|
| AWS Trusted Advisor | Checks for 0 utilization (e.g., Idle Load Balancers, Unassociated IPs) | Flag for immediate deletion |
| AWS Compute Optimizer | ML-based analysis of CPU/Memory patterns over time | Recommendation to downsize or change instance family |
| Amazon CloudWatch | Metric thresholds (e.g., CPU < 5% for 7 days) | Trigger Lambda for notification/shutdown |
| AWS Cost Explorer | Spending anomalies or high-cost idle services | Strategic review of architecture components |
Hierarchical Outline
- I. Resource Tracking & Visibility
- Automated Tagging: Using "created_on" or "owner" tags to establish a resource's lifespan.
- Cost Allocation: Mapping tags to business units for granular accountability.
- II. Identification Solutions
- AWS Trusted Advisor: Focuses on low-hanging fruit (Unused EBS, Idle DB instances).
- AWS Compute Optimizer: Machine learning analysis for EC2, EBS, Lambda, and Fargate.
- S3 Storage Lens: Visibility into object storage usage and cost-optimization opportunities.
- III. Decommissioning Strategies
- Manual Review: Periodic architectural audits.
- Automated Termination: Using AWS Auto Scaling to gracefully remove unwanted fleet members.
- Graceful Shutdown: Ensuring data is backed up (snapshots) before final decommissioning.
Visual Anchors
Resource Identification Flowchart
Right-sizing Metric Analysis
Definition-Example Pairs
- Idle Load Balancer: An Elastic Load Balancer with no registered targets or no processed requests.
- Example: A developer creates a test environment, deletes the EC2 instances, but forgets to delete the Application Load Balancer, which continues to charge a base hourly rate.
- Unassociated Elastic IP: A static IPv4 address reserved in your account but not currently mapped to a running instance.
- Example: You stop an EC2 instance that had an EIP. AWS charges a small hourly fee for the unassociated EIP to encourage efficient use of public IP space.
- Underutilized EBS Volume: A volume attached to an instance that shows near-zero Read/Write IOPS for an extended period.
- Example: A log volume that is no longer being written to because the application service was disabled.
Worked Examples
Example 1: Identifying Idle EC2 Instances with Trusted Advisor
- Navigate to the AWS Trusted Advisor console.
- Locate the "Cost Optimization" category.
- Find the check titled "Low Utilization Amazon EC2 Instances."
- Criteria: Instances that have had < 10% average CPU utilization and < 5 MB network I/O for 4 of the last 14 days.
- Action: Review the identified
Instance IDs. If they belong to a legacy project, create a final AMI/Snapshot and Terminate the instance.
Example 2: Right-sizing with Compute Optimizer
- Enable AWS Compute Optimizer in the Management Console (Organization-wide or single account).
- Wait for 12-24 hours for the ML model to analyze CloudWatch metrics.
- Review Recommendations: The tool may suggest moving an
m5.large(over-provisioned) to at3.medium(saving 40% in costs). - Implement: Change the instance type during a maintenance window.
Checkpoint Questions
- Which AWS service uses Machine Learning to provide recommendations for EC2 instance types?
- Why is an unassociated Elastic IP address charged even though it isn't "doing" anything?
- What is the benefit of using a "created_on" tag for decommissioning resources?
- True or False: AWS Trusted Advisor can automatically delete idle resources for you.
Muddy Points & Cross-Refs
- Trusted Advisor vs. Compute Optimizer: Trusted Advisor is great for finding "binary" waste (on/off, used/unused). Compute Optimizer is better for "spectral" waste (finding the perfect size for an active resource).
- Data Retention: Always check for data retention policies before decommissioning. Deleting an RDS instance also deletes its automated backups unless you take a final manual snapshot.
- Cross-Ref: See Chapter 4 (Cost Optimization) for details on Cost Allocation Tags and Chapter 15 (Deployment) for monitoring patterns.
Comparison Tables
| Feature | AWS Trusted Advisor | AWS Compute Optimizer | CloudWatch Alarms |
|---|---|---|---|
| Primary Goal | Best practice checks | Right-sizing recommendations | Real-time monitoring/actions |
| Intelligence | Rule-based (static) | ML-based (dynamic) | User-defined thresholds |
| Resource Scope | Wide (EBS, RDS, EIP, EC2) | Specific (EC2, ASG, EBS, Lambda, Fargate) | Any resource with metrics |
| Automation | Via EventBridge notifications | Manual or CLI-based changes | Triggers Lambda/Auto Scaling |