AWS 청구서는 엔지니어링 팀에게 놀라움과 좌절의 원인이 될 수 있으며, 예상치 못한 비용이 너무 늦기 전까지 종종 간과됩니다. 일반적인 시나리오는 엔지니어가 개념 증명(proof of concept)을 위해 인스턴스를 실행하고 이를 끄는 것을 잊어버려 지속적인 청구가 발생하는 경우입니다. AWS에서 제공하는 도구인 Cost Explorer는 청구 데이터의 추세와 이상 징후를 식별하는 데 도움이 될 수 있지만, 어떤 특정 인스턴스가 어떤 엔지니어 또는 팀에 속하는지 보여줄 수 없다는 등의 한계가 있습니다. 이 도구는 서비스, 리전, 계정 및 태그별로 집계할 수 있는 청구 기록을 기반으로 작동하지만, 실행 중인 인스턴스와 유휴 인스턴스를 구별할 수는 없습니다.리소스에 태그를 지정하면 속성을 개선할 수 있지만, 리소스가 적극적으로 사용되고 있는지 또는 유휴 상태인지 알 수 없다는 등의 간격이 있습니다. 유휴 리소스 문제는 특히 리소스가 지속적으로 실행되는 경우가 많아 상당한 유휴 시간이 발생하는 개발(dev) 및 스테이징(staging) 환경에서 널리 퍼져 있습니다. 이 문제를 해결하려면 두 계층에서의 계측이 필요합니다. 즉, 활동 신호(activity signal)와 유휴 비용 가시성(idle cost visibility)을 갖춘 리소스별 속성(per-resource attribution)입니다.활동 신호는 리소스가 실제로 사용되고 있는지 여부를 결정하는 것을 포함하며, 리소스별 속성은 유휴 리소스의 비용 결과를 드러내는 것을 포함합니다. EC2 개발 상자(EC2 dev boxes), RDS 스테이징 데이터베이스(RDS staging databases), ECS 서비스(ECS services)와 같은 다양한 리소스 유형은 다양한 유휴 비용 패턴을 가지고 있습니다.유휴 비용에 대한 가시성이 없다는 결과는 비용 최적화가 작업이 언제 발생하는지에 대한 가정을 기반으로 하는 무딘 도구가 된다는 것입니다. 보다 정확한 접근 방식은 최적화 결정을 알리기 위해 소유권 속성을 갖춘 리소스 수준에서 유휴 비용을 보이게 하는 것입니다.유휴 비용이 누적되는 위치에 대한 더 명확한 그림을 얻기 위해 팀은 인스턴스 가동 시간 대 CloudWatch 활동을 가져오고, 주말 동안 RDS 연결 수를 확인하고, ECS 최소 작업 수를 검토하고, 실행 중인 인스턴스에 대한 태그 규정 준수 감사를 실행하는 것으로 시작할 수 있습니다.궁극적으로 유휴 비용 문제를 해결하려면 특정 엔지니어, 팀 또는 환경에 대한 유휴 비용 속성과 활동 인식 자동화를 기반으로 구축된 Trigops와 같은 도구를 사용하는 것과 같은 체계적인 접근 방식이 필요합니다.