The AWS bill can be a source of surprise and frustration for engineering teams, with unexpected costs often going unnoticed until it's too late. A common scenario is when an engineer spins up an instance for a proof of concept and forgets to turn it off, resulting in continuous billing. Cost Explorer, a tool provided by AWS, can help identify trends and anomalies in billing data, but it has limitations, such as not being able to show which specific instance belongs to which engineer or team. The tool operates on billing records, allowing for aggregation by service, region, account, and tag, but it cannot distinguish between running and idle instances. Tagging resources can improve attribution, but it has gaps, such as not being able to tell if a resource is actively being used or if it's sitting idle. The idle-resource problem is particularly prevalent in dev and staging environments, where resources are often left running continuously, resulting in significant idle time. To solve this problem, instrumentation at two layers is required: activity signal and per-resource attribution with idle cost visibility. The activity signal involves determining whether a resource is actually being used, while per-resource attribution involves surfacing the cost consequence of idle resources. Different resource types, such as EC2 dev boxes, RDS staging databases, and ECS services, have varying idle-cost patterns. The consequence of not having visibility into idle cost is that cost optimization becomes a blunt instrument, relying on assumptions about when work happens. A more precise approach is to make idle cost visible at the resource level, with ownership attribution, to inform optimization decisions. To get a clearer picture of where idle cost is accumulating, teams can start by pulling instance uptime vs. CloudWatch activity, checking RDS connection counts over the weekend, reviewing ECS minimum task counts, and running a tag compliance audit on running instances. Ultimately, addressing the idle-cost problem requires a systematic approach, such as using a tool like Trigops, which is built around attribution of idle cost to specific engineers, teams, or environments, with activity-aware automation.