핵심
EventBridge / CloudWatch Events
•
이벤트를 감지하고 전달하는 역할
Lambda
•
그 이벤트를 받아 실제 코드를 실행하는 역할
즉, EventBridge가 언제, 무슨 일이 발생했는지를 잡아주고 Lambda가 그래서 무엇을 할지를 수행
관계
예전에는 CloudWatch Events라고 불렸고, 지금은 기능이 확장되면서 Amazon EventBridge로 이해하면 됨
보통 이벤트를 받아서 서버리스로 후속 작업 실행하면 EventBridge → Lambda 조합
Lambda + EventBridge 기본 구조
이벤트 발생 -> EventBridge rule이 매칭 -> Lambda 실행
Plain Text
복사
•
예시
◦
EC2 인스턴스 상태가 stopped
◦
EventBridge rule이 그 이벤트를 감지하고
◦
Lambda를 호출해서
◦
알림 보내기 / 태그 수정 / 후처리 수행
시험 패턴
•
패턴 A: 스케줄 기반 실행 (가장 흔한 유형)
◦
예시
▪
매일 새벽 보고서 생성
▪
5분마다 DB 상태 점검
▪
매주 월요일 오래된 로그 정리
▪
영업시간 외 EC2 중지/시작
◦
위의 경우 정답 패턴은 보통
▪
EventBridge schedule rule
▪
Lambda target
•
패턴 B: 이벤트 기반 실행
◦
예시
▪
EC2 인스턴스 종료 시 후처리
▪
CodeBuild 실패 시 알림 전송
▪
Auto Scaling 이벤트가 발생하면 기록 저장
▪
특정 AWS API 호출 감지 후 자동 조치
EventBridge와 Lambda의 역할 차이
EventBridge
•
이벤트를 받음
•
규칙(rule)으로 필터링
•
적절한 타깃으로 전달
Lambda
•
실제 코드 실행
•
데이터 가공
•
다른 서비스 호출
•
알림 전송
•
자동 복구 수행
헷갈리는 비교
EventBridge vs SQS
•
둘 다 Lambda와 자주 붙음
•
EventBridge
◦
이벤트 라우팅
◦
여러 AWS 서비스 이벤트를 쉽게 받음
◦
조건 기반 필터링 강함
◦
스케줄 가능
◦
느슨한 결합의 이벤트 중심 아키텍처에 적합
•
SQS
◦
메시지 큐
◦
메시지 보관, 버퍼링, 재처리
◦
트래픽 급증 완화
◦
소비자가 천천히 처리 가능
◦
순서/내구성/재시도 제어 중요할 때 적합
EventBridge vs SNS
•
EventBridge
◦
복잡한 이벤트 필터링 가능
◦
AWS 서비스 이벤트 라우팅에 강함
◦
패턴 기반 매칭
•
SNS
◦
pub/sub 알림 서비스
◦
이메일/SMS/HTTP/SQS/Lambda로 fan-out
◦
단순 알림 전파에 적합
시나리오
정해진 시간마다 작업
•
예시
◦
매일 밤 오래된 스냅샷을 정리해야 한다. 서버 관리 부담은 최소화
•
정답 방향
◦
EventBridge Schedule
◦
Lambda
•
이유
◦
스케줄 트리거
◦
서버리스
◦
운영 부담 적음
AWS 리소스 상태 변화 감지
•
예시
◦
EC2 인스턴스가 중지될 때마다 자동으로 태그를 수정하고 알림을 보내야 한다
•
정답 방향
◦
EventBridge rule로 EC2 state-change 이벤트 감지
◦
Lambda 실행
자동 remediation
•
예시
◦
보안 그룹이 정책을 위반하면 자동으로 원래 상태로 되돌려야 한다
•
정답 방향
◦
위반 이벤트 감지: EventBridge
◦
수정 작업 수행: Lambda