Счета AWS могут стать источником удивления и разочарования для инженерных команд, поскольку неожиданные расходы часто остаются незамеченными до тех пор, пока не станет слишком поздно. Распространенный сценарий: инженер запускает экземпляр для концепции и забывает его отключить, что приводит к непрерывному выставлению счетов. Cost Explorer, инструмент, предоставляемый AWS, может помочь выявить тенденции и аномалии в данных о выставлении счетов, но имеет ограничения, такие как невозможность показать, какой конкретный экземпляр принадлежит какому инженеру или команде. Инструмент работает с записями о выставлении счетов, позволяя агрегировать данные по сервису, региону, аккаунту и тегу, но не может различать работающие и неактивные экземпляры. Тегирование ресурсов может улучшить атрибуцию, но имеет пробелы, например, неспособность определить, активно ли используется ресурс, или он простаивает. Проблема простаивающих ресурсов особенно распространена в средах разработки и тестирования, где ресурсы часто остаются включенными непрерывно, что приводит к значительному времени простоя. Для решения этой проблемы требуется инструментарий на двух уровнях: сигнал активности и атрибуция по ресурсам с видимостью затрат на простой. Сигнал активности включает определение того, используется ли ресурс фактически, в то время как атрибуция по ресурсам включает отображение финансовых последствий простаивающих ресурсов. Различные типы ресурсов, такие как экземпляры разработки EC2, базы данных тестирования RDS и сервисы ECS, имеют различные модели затрат на простой. Следствием отсутствия видимости затрат на простой является то, что оптимизация затрат становится грубым инструментом, полагающимся на предположения о том, когда происходит работа. Более точный подход заключается в том, чтобы сделать затраты на простой видимыми на уровне ресурсов с атрибуцией владения, чтобы информировать решения по оптимизации. Чтобы получить более четкое представление о том, где накапливаются затраты на простой, команды могут начать с сопоставления времени безотказной работы экземпляров с активностью CloudWatch, проверки количества подключений RDS в выходные дни, обзора минимального количества задач ECS и проведения аудита соответствия тегов для работающих экземпляров. В конечном итоге, решение проблемы затрат на простой требует систематического подхода, такого как использование инструмента, подобного Trigops, который построен на основе атрибуции затрат на простой конкретным инженерам, командам или средам с автоматизацией, учитывающей активность.