AWS makes it incredibly easy to provision infrastructure. Sometimes, a little too easy. An EC2 instance gets created for a project. A volume survives after the instance is terminated. A snapshot is kept "just in case." A development environment runs all night even though nobody is using it. Individually, these expenses may not look alarming. Over time, however, they can quietly become part of your normal AWS bill. The first instinct may be to start deleting resources. I don't recommend that. Before deleting, resizing, or shutting down anything, understand what depends on it. With that in mind, here are seven areas I would investigate when reviewing an AWS environment for potential cost waste. 1. Underutilized EC2 Instances EC2 is one of the first places I would investigate. An instance may have been sized correctly when an application was originally deployed, but workloads change. An instance that once needed significant CPU or memory may now be consistently underutilized. AWS Compute Optimizer can help identify potential rightsizing opportunities. Look for things such as: Consistently low utilization Instances that may be oversized Development or test instances running 24/7 Old proof-of-concept instances nobody is actively using Non-production environments are especially worth reviewing. If a development server is only needed during business hours, ask whether it really needs to run nights and weekends. Important: Low utilization alone is not permission to resize or terminate an instance. Investigate the workload and dependencies first. 2. Unattached EBS Volumes Terminating an EC2 instance doesn't necessarily mean every resource associated with it disappears. EBS volumes can remain behind. That means you can end up paying every month for storage that isn't attached to a running instance. During a cost review, identify unattached volumes and determine: What created the volume? When was it last attached? Does it contain data that must be retained? Is it part of a backup or recovery process? Does an application or team still need it? If the volume truly isn't needed, it may be a cleanup candidate. But again: verify before deleting. 3. Old EBS Snapshots Snapshots are valuable. They're also easy to forget. Automated backup processes can create snapshots continuously, and without a defined retention policy, the collection can grow for months or years. Review your snapshot inventory and ask: How old are these snapshots? What retention period does the business actually require? Are snapshots being created automatically? Is there an established cleanup policy? The objective isn't to delete backups simply to save money. It's to make sure your backup retention reflects an intentional business and recovery requirement rather than unlimited accumulation. 4. S3 Storage Without Lifecycle Policies S3 can hold enormous amounts of data, which makes storage-class decisions important. Not every object needs to remain in S3 Standard forever. For data that's accessed less frequently, lifecycle policies can automatically transition objects to more appropriate storage classes. You should also investigate incomplete multipart uploads. Failed or abandoned uploads can remain behind and continue consuming storage. A few questions worth asking: Which buckets contain older data? How frequently is that data accessed? Are lifecycle policies configured? Are incomplete multipart uploads being cleaned up? Would Intelligent-Tiering make sense for unpredictable access patterns? Small storage inefficiencies multiplied across millions of objects can become meaningful. 5. Unattached Elastic IP Addresses Elastic IP addresses are another resource that can survive after the infrastructure around them changes. An instance gets terminated. The IP remains. Nobody notices. During an environment review, look for public IPv4 addresses that are no longer associated with resources that need them. More importantly, determine why they exist before removing anything. A seemingly unused IP could still be documented in DNS, firewall rules, allowlists, partner configurations, or another dependency. This is a perfect example of why cost optimization should include investigation—not just deletion. 6. NAT Gateway and Data Transfer Costs Networking costs can be harder to notice than compute costs. NAT Gateways have both hourly and data-processing charges. Depending on the architecture and traffic patterns, those costs can become significant. Review: How many NAT Gateways are deployed? Which workloads are sending traffic through them? How much data is being processed? Is traffic crossing Availability Zones unnecessarily? Is there significant cross-region traffic? For workloads accessing services such as S3 or DynamoDB from within a VPC, also investigate whether VPC Gateway Endpoints could reduce unnecessary NAT Gateway traffic. This isn't simply a cost question. Networking changes affect architecture, availability, and security, so evaluate the design before changing it. 7. CloudWatch Logs With Unlimited Retention Logs are essential when you're troubleshooting an incident. They're less useful when years of logs are being stored indefinitely without anyone realizing it. Some CloudWatch log groups may have retention configured as: Never expire That might be intentional for certain workloads. For others, it may simply be the default nobody revisited. Review log groups and determine what retention period actually makes sense for: Operations Troubleshooting Security Compliance Business requirements Then configure retention intentionally. The goal isn't "delete logs." The goal is keep the logs you actually need for as long as you actually need them. Cost Optimization Is Really About Visibility The common theme across all seven areas isn't simply reducing cost. It's understanding your environment. Before making changes, I want to know: What is this resource? Who owns it? What depends on it? Why does it exist? What happens if we change it? Once those questions are answered, cost optimization becomes a much safer engineering exercise. AWS also provides tools such as Cost Explorer, Compute Optimizer, Budgets, and Cost Anomaly Detection that can help make cost reviews part of normal cloud operations rather than something you investigate only after receiving an unexpectedly large bill. Want the Complete AWS Cost Optimization Checklist? I put together a practical AWS Cost Optimization Checklist with 47 actionable checks covering: EC2 & Auto Scaling S3 & EBS RDS & DynamoDB Lambda Networking & Data Transfer Monitoring, Tagging & Governance Reserved Instances & Savings Plans A 30-Minute AWS Cost Audit It's designed as a field guide for engineers, DevOps teams, and small organizations that want a structured way to investigate AWS costs without blindly changing production resources. The complete checklist is $9. 👉 Get the AWS Cost Optimization Checklist: https://demarkocloud.gumroad.com/l/kfxoi I'm Demarko Little, a Systems Engineer with more than 20 years of experience supporting enterprise IT infrastructure. I'm also the founder of DemarkoCloud, where I focus on practical cloud infrastructure, automation, reliability, and architecture. If this article helped you identify something worth investigating in your AWS environment, let me know in the comments.