Week 2의 그림을 한 장으로 다시 본다. 새벽 3시 알람을 받았을 때 무엇을 어떤 순서로 봐야 하는가, 청구서가 갑자기 $10,000 늘었을 때 어디부터 파야 하는가, 사용자 일부가 "느리다"고 할 때 어떤 쿼리를 쳐야 하는가. CloudWatch의 모든 도구가 결국 이 세 질문에 답하기 위한 것이다.
Week 2가 "데이터 수집"이라면 Week 3는 "알림과 가시화", Week 4부터의 자동화·DR·비용 관리는 그 위에서 만들어진다. 복습 주차인 만큼 이번 글은 각 개념을 다시 설명하기보다, 개념들이 왜 그렇게 설계됐는지와 현장에서 어떻게 무너지는지를 사고 사례·표준·이론으로 묶어 깊이를 더한다.
CloudWatch는 2009년 EC2의 CPU·네트워크·디스크 I/O를 보여주는 단순한 메트릭 서비스로 출발했다. 알람(2010), 커스텀 메트릭(2011), 운영자에게 가장 중요한 CloudWatch Logs(2014), 이어 Logs Insights(2018), EMF·Anomaly Detection(2019), Metric Stream(2021), Cross-Account Observability(2022)가 시간차로 쌓인 지층이다.
CloudWatch는 한 번에 설계된 일관된 시스템이 아니라 서로 다른 데이터 모델 위에 붙은 도구들의 연합이다