AWS CloudWatch, CloudTrail, EventBridge 정리

1023·2026년 9월 25일

CloudWatch

CloudWatch란

CloudWatch는 AWS 리소스와 애플리케이션을 모니터링하고 관리할 수 있는 완전관리형 서비스다. AWS 서비스의 성능과 운영 상태를 실시간으로 파악하는 데 쓰인다.

주요 특징

지표 수집 및 모니터링: AWS 리소스의 지표(Metrics) 데이터를 수집하고 모니터링한다. 예를 들어 EC2의 CPU 사용률, 네트워크 트래픽 같은 수치들이 여기 해당한다.
로그 관리: 애플리케이션 로그를 중앙에서 수집하고 분석할 수 있다.
알림 설정: 특정 조건이 충족되면 알람을 발생시키고 이메일이나 SMS로 알림을 보낼 수 있다.

강의 자료에서는 AWS 리소스나 커스텀 데이터가 CloudWatch로 들어가서 Metrics/APM/Logs 세 가지 형태로 쌓이고 거기서 조건에 맞으면 Alarm이 발생해서 Lambda/SNS/Auto Scaling Group 같은 곳으로 전달되는 구조였다. 그리고 Grafana 같은 외부 대시보드 도구가 CloudWatch에 쌓인 데이터를 가져다가 시각화하는 데 쓰이기도 한다. CloudWatch 자체는 데이터를 모으고 조건을 감시하는 역할이고, 실제로 뭔가 조치를 취하는 건 Alarm이 트리거하는 Lambda나 Auto Scaling 같은 다른 서비스가 담당하는 구조이다. 이 흐름은 전에 했던 aws eks 프로젝트 아키텍처를 정리할 때 나왔던 CloudWatch → SNS → Lambda로 이어지는 알림 파이프라인과 정확히 같은 구조이다.

CloudTrail

CloudTrail란

CloudTrail은 AWS 계정에서 발생하는 모든 API 호출과 활동을 기록하고 모니터링하는 서비스다. AWS Management Console에서 클릭한 것이든, SDK로 코드에서 호출한 것이든, CLI로 명령어를 친 것이든 상관없이 AWS 안에서 벌어지는 API 호출은 다 CloudTrail에 기록된다. EX) VPC, EC2, RDS, EBS, IAM, STS와 같은 다양한 서비스에 대한 호출 기록이 CloudTrail을 거쳐서 지정된 S3 버킷에 로그 파일로 쌓이고 필요하면 SNS Topic으로 알림도 보낼 수 있는 구조이다.

CloudWatch와 뭐가 다른가

여기서 CloudWatch와 CloudTrail이 뭐가 다른지 짚어보면 CloudWatch는 리소스가 지금 어떤 상태인가(CPU 사용률, 로그 내용 등)를 보는 성능/운영 모니터링이고, CloudTrail은 누가 언제 무엇을 했는가를 기록하는 감사(Audit) 로그라는 차이가 있었다.EX) EC2 인스턴스의 CPU가 갑자기 튀었다면 CloudWatch로 확인해야 하고 그 인스턴스의 보안 그룹 설정을 누가 언제 바꿨는지 추적하려면 CloudTrail을 봐야 하는 식인 것.

EventBridge

EventBridge란

EventBridge는 다양한 소스에서 발생하는 이벤트를 수집해서 원하는 대상으로 전달해주는 서비스다. AWS 리소스는 CloudTrail에 기록되는 API 호출 이벤트 말고도 서비스마다 자체적인 이벤트를 발생시키기도 하는데(EX. EC2 인스턴스 상태 변경) 이런 것들까지 다 EventBridge가 받아서 처리할 수 있다.

기능

이벤트 수집: AWS 서비스, SaaS 애플리케이션, 사용자 애플리케이션 등에서 발생하는 이벤트를 수집한다.
규칙 기반 라우팅: 이벤트 패턴을 정의해서 특정 이벤트가 발생했을 때 원하는 대상에게 전달한다.
다양한 대상 지원: Lambda 함수, SQS 큐, SNS 토픽, Kinesis 스트림 등 다양한 AWS 서비스와 통합된다.
스케줄링 지원: 일정에 따라 이벤트를 트리거해서 정기적인 작업을 수행할 수 있다.

CloudTrail과 EventBridge를 같이 쓰면

IAM 사용자가 삭제되는 API 호출이 발생하면 그 호출이 먼저 CloudTrail에 기록되고 EventBridge가 이 이벤트를 감지해서 IAM User 삭제 시 Lambda로 이벤트 전송이라는 규칙에 따라 Lambda 함수를 실행시킨다. 이렇게 하면 단순히 로그를 남기는 걸 넘어서 특정 API 호출이 발생했을 때 자동으로 후속 조치(알림 발송, 자동 대응 등)까지 이어지는 파이프라인을 만들 수 있다.
정리하자면 CloudTrail은 기록을 남기는 것까지가 역할이고, 그 기록을 실시간으로 감지해서 다른 서비스로 연결해주는 건 EventBridge의 역할인 것이다. 이런 이벤트 기반 자동화를 미리 구성해두면 실수가 발생했을 때 바로 알림을 받거나 자동으로 대응할 수 있겠다는 생각이 들었다.