Amazon EventBridge for SAA-C03

One-Line Summary

EventBridge는 여러 소스(AWS 서비스·SaaS·내 앱)에서 나오는 이벤트를 받아, 규칙(Rule)으로 걸러 원하는 대상(Lambda·SQS·SNS·Step Functions 등)에 자동 전달하는 서버리스 이벤트 버스다. "무슨 일이 일어나면(event) → 무엇을 실행하라(target)"를 코드 없이 규칙으로 잇는 것이 핵심이다. (예전 이름: CloudWatch Events)

Why It Exists

"S3에 파일이 올라오면 Lambda를 실행"처럼 서비스 간 반응을 이으려면, 서비스마다 개별 트리거 설정을 하거나 폴링 코드를 짜야 한다. 소스·대상이 늘수록 연결이 복잡해진다.

EventBridge는 이 연결을 이벤트 버스 + 규칙으로 중앙화한다.

직접 연결
  각 서비스마다 트리거/폴링을 따로 구성, 소스·대상 늘면 스파게티

EventBridge
  소스 -> [Event Bus] -> Rule(이벤트 패턴 매칭) -> Target
  이벤트가 조건에 맞으면 지정한 대상으로 자동 전달

시험 감각:

"AWS 서비스의 상태 변화/이벤트에 반응해 다른 서비스를 실행" = EventBridge.

Abbreviations

약어	풀네임	의미
`EventBridge`	Amazon EventBridge	서버리스 이벤트 버스/라우팅 서비스
`Event Bus`	Event Bus	이벤트가 모이는 통로 (default / custom / partner)
`Rule`	Rule	이벤트 패턴에 맞으면 대상으로 보내는 규칙
`Event Pattern`	Event Pattern	어떤 이벤트를 매칭할지 정의한 JSON 조건
`Target`	Target	이벤트를 받아 실행되는 대상 (Lambda, SQS 등)
`Scheduler`	EventBridge Scheduler	cron/rate 기반 예약 실행
`Pipes`	EventBridge Pipes	소스→대상 1:1 연결(필터·변환·보강 포함)

실제로 어떻게 연결되나 (핵심 구조)

[Source]              [Event Bus]        [Rule]                 [Target]
S3 object created  ->  default bus   ->  pattern 매칭       ->  Lambda
EC2 state change   ->                     (source, detail 등)    SQS / SNS
CodePipeline 실패  ->                                            Step Functions
내 앱 custom 이벤트 ->  custom bus                               Kinesis / API 등

구성요소	역할
Source	이벤트를 만드는 쪽 (90+ AWS 서비스, SaaS 파트너, 내 앱)
Event Bus	이벤트가 들어오는 버스. AWS 서비스 이벤트는 default bus, 내 앱은 custom bus
Rule	JSON 이벤트 패턴으로 매칭 (예: `source=aws.s3`, `detail-type=Object Created`)
Target	매칭된 이벤트를 받는 대상. 최대 여러 개 지정 가능(팬아웃)

대표 대상: Lambda, SQS, SNS, Step Functions, Kinesis, ECS Task, CodeBuild, Systems Manager 등.

두 가지 대표 쓰임새 (빈출)

유형	설명	예시
이벤트 기반 반응	AWS/SaaS/앱의 상태 변화에 반응	S3 업로드 → Lambda, EC2 상태 변경 → SNS 알림
예약 실행 (Scheduled)	cron/rate로 주기 실행	매일 새벽 배치 Lambda 실행, 정기 정리 작업

시험 감각:

"정해진 스케줄(cron)에 Lambda를 주기 실행" = EventBridge (Scheduler). 예전에는 CloudWatch Events로 출제.

EventBridge vs SNS vs SQS (가장 중요한 비교)

구분	EventBridge	SNS	SQS
모델	이벤트 라우팅/버스	발행/구독(pub/sub)	큐(queue)
라우팅	이벤트 내용(JSON) 기반 정교한 필터·규칙	토픽 단위 + 속성 필터	라우팅 없음(단일 큐)
소스	90+ AWS 서비스·SaaS·custom	발행자가 직접 publish	생산자가 직접 send
처리량/지연	매우 유연하나 SNS보다 지연↑	초고처리량·저지연 팬아웃	완충·순차 처리
대표 키워드	react to AWS events, schedule, SaaS integration, route by content	fan-out, notify many	decouple, buffer, backlog

핵심 구분:

AWS 서비스 이벤트/SaaS 연동/스케줄/내용 기반 라우팅 = EventBridge. 단순 1:N 고속 팬아웃 = SNS. 완충·순차 처리 큐 = SQS.

EventBridge Pipes (알아두면 좋음)

소스 하나 → 대상 하나를 잇는 1:1 통합에 필터링·데이터 변환·보강을 붙여준다. (예: SQS → 필터/변환 → Step Functions). 여러 대상 팬아웃이 아니라 point-to-point 연결이 목적이면 Pipes.

Common Wrong Directions

오답 방향	왜 부족한가
단순 고속 1:N 팬아웃에 EventBridge	순수 팬아웃·저지연은 SNS가 더 적합
cron 예약 실행을 Lambda 코드/EC2 크론으로 구현	서버리스 예약은 EventBridge Scheduler
AWS 서비스 상태 변화를 폴링으로 감지	상태 변화 이벤트는 EventBridge 규칙으로 반응
SaaS(예: Zendesk) 이벤트 수신에 SQS/SNS만	파트너 이벤트 소스는 EventBridge (partner event bus)
순차 처리/완충이 필요한데 EventBridge만	완충·재처리·순서는 SQS를 대상으로 붙임

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"react to AWS service events / state changes"	`EventBridge`
"run a task on a schedule / cron / every X"	`EventBridge` (Scheduler)
"integrate with SaaS (partner) events"	`EventBridge` (partner event bus)
"route events based on their content/pattern"	`EventBridge` rule + event pattern
"trigger Lambda when object created in S3"	`EventBridge` (또는 S3 event notification)
"high-throughput fan-out to many subscribers"	`SNS`
"buffer / decouple / process backlog"	`SQS`

Memory Sentence

EventBridge는 AWS·SaaS·앱 이벤트를 규칙(이벤트 패턴)으로 걸러 Lambda·SQS·SNS·Step Functions 등으로 라우팅하는 서버리스 이벤트 버스다. AWS 서비스 이벤트 반응·cron 예약·SaaS 연동·내용 기반 라우팅이면 EventBridge, 단순 고속 팬아웃은 SNS, 완충·순차 큐는 SQS.

[Compute] EventBridge 컨셉 노트