CloudWatch로 리소스 모니터링 및 자동화 완벽 가이드

AWS CloudWatch를 활용하여 인프라와 애플리케이션을 모니터링하고 자동화하는 방법을 알아봅니다. 지표 수집부터 로그 분석, 이벤트 기반 자동화까지 실무에 필요한 핵심 기능을 다룹니다.

---

목차

1. CloudWatch_주요_기능
2. 지표_모니터링_및_대시보드
3. 경보_생성_및_SNS_알림_연동
4. CloudWatch_Logs로_애플리케이션_로그_수집
5. Log_Insights로_로그_분석
6. EventBridge로_이벤트_기반_자동화

---

1. CloudWatch 주요 기능

입사 첫 주를 보내고 있는 김개발 씨에게 팀장님이 다가왔습니다. "우리 서비스 서버가 가끔 느려지는데, 원인을 좀 파악해볼 수 있겠어요?" 김개발 씨는 당황했습니다.

서버 안에서 무슨 일이 일어나는지 어떻게 알 수 있을까요?

CloudWatch는 AWS 리소스와 애플리케이션을 실시간으로 모니터링하는 서비스입니다. 마치 자동차 계기판이 속도, 연료량, 엔진 상태를 한눈에 보여주듯, CloudWatch는 서버의 CPU 사용량, 메모리, 네트워크 트래픽 등을 실시간으로 보여줍니다.

이 서비스를 통해 문제가 발생하기 전에 미리 감지하고 대응할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# CloudWatch 클라이언트 생성
cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2')

# EC2 인스턴스의 CPU 사용률 조회
response = cloudwatch.get_metric_statistics(
    Namespace='AWS/EC2',
    MetricName='CPUUtilization',
    Dimensions=[
        {'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}
    ],
    StartTime='2024-01-01T00:00:00Z',
    EndTime='2024-01-01T01:00:00Z',
    Period=300,  # 5분 간격
    Statistics=['Average']
)
print(response['Datapoints'])

김개발 씨는 서버 모니터링이라는 말에 막막함을 느꼈습니다. 서버 안에서 무슨 일이 일어나는지 어떻게 알 수 있을까요?

터미널에 접속해서 일일이 확인해야 할까요? 선배 개발자 박시니어 씨가 웃으며 다가왔습니다.

"걱정 마세요. AWS에는 CloudWatch라는 아주 강력한 도구가 있거든요." 그렇다면 CloudWatch란 정확히 무엇일까요?

쉽게 비유하자면, CloudWatch는 마치 병원의 환자 모니터링 시스템과 같습니다. 환자의 심박수, 혈압, 체온을 실시간으로 측정하고 이상이 생기면 경보를 울리듯, CloudWatch는 서버의 CPU 사용량, 메모리, 디스크 공간 등을 계속 지켜보다가 문제가 생기면 알려줍니다.

CloudWatch의 핵심 기능은 크게 세 가지로 나뉩니다. 첫 번째는 **지표(Metrics)**입니다.

CPU 사용률, 네트워크 트래픽, 요청 수 같은 숫자 데이터를 수집합니다. 이 숫자들을 통해 서버의 건강 상태를 한눈에 파악할 수 있습니다.

두 번째는 **로그(Logs)**입니다. 애플리케이션에서 발생하는 모든 기록을 수집하고 저장합니다.

에러 메시지, 사용자 행동, 시스템 이벤트 등 텍스트 형태의 정보가 여기에 해당합니다. 세 번째는 **이벤트(Events)**입니다.

특정 조건이 발생했을 때 자동으로 작업을 실행할 수 있습니다. 예를 들어 매일 자정에 백업을 실행하거나, 새 파일이 업로드되면 처리 작업을 시작하는 식입니다.

이 세 가지 기능이 왜 중요할까요? CloudWatch가 없던 시절에는 서버에 직접 접속해서 top 명령어로 CPU를 확인하고, 로그 파일을 열어서 에러를 찾아야 했습니다.

서버가 10대, 100대로 늘어나면 이런 방식은 불가능해집니다. CloudWatch를 사용하면 수백 대의 서버 상태를 한 화면에서 볼 수 있습니다.

문제가 생기면 즉시 알림을 받고, 심지어 자동으로 복구 작업까지 실행할 수 있습니다. 위의 코드를 살펴보겠습니다.

boto3 라이브러리를 통해 CloudWatch에 접속하고, get_metric_statistics 함수로 특정 EC2 인스턴스의 CPU 사용률을 조회합니다. Period가 300초로 설정되어 있으니 5분 단위로 평균값을 가져오는 것입니다.

실제 현업에서는 이런 데이터를 수집해서 대시보드를 만들거나, 특정 임계값을 넘으면 경보를 발생시킵니다. 새벽에 서버가 다운되어도 담당자에게 즉시 알림이 가니 빠르게 대응할 수 있습니다.

박시니어 씨의 설명을 들은 김개발 씨는 이해가 되기 시작했습니다. "아, 그러니까 CloudWatch가 우리 서버를 24시간 감시해주는 거군요!"

실전 팁

💡 - CloudWatch는 대부분의 AWS 서비스와 자동으로 연동되어 기본 지표를 무료로 수집합니다

• 커스텀 지표를 사용하면 애플리케이션 고유의 비즈니스 메트릭도 추적할 수 있습니다

---

2. 지표 모니터링 및 대시보드

김개발 씨는 CloudWatch 콘솔에 처음 접속했습니다. 수많은 그래프와 숫자들이 눈앞에 펼쳐졌습니다.

"이 많은 데이터 중에서 뭘 봐야 하죠?" 박시니어 씨가 말했습니다. "대시보드를 만들어서 중요한 것만 모아서 보면 됩니다."

**지표(Metrics)**는 시간에 따른 데이터 포인트의 집합입니다. 마치 주식 차트가 시간별 주가 변동을 보여주듯, CloudWatch 지표는 서버의 상태 변화를 시각적으로 보여줍니다.

대시보드를 활용하면 여러 지표를 한 화면에 모아서 서비스 전체 상태를 한눈에 파악할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2')

# 커스텀 지표 발행 - 애플리케이션의 활성 사용자 수 추적
cloudwatch.put_metric_data(
    Namespace='MyApplication',
    MetricData=[
        {
            'MetricName': 'ActiveUsers',
            'Value': 150,
            'Unit': 'Count',
            'Dimensions': [
                {'Name': 'Environment', 'Value': 'Production'},
                {'Name': 'Service', 'Value': 'WebApp'}
            ]
        }
    ]
)

# 대시보드 생성
dashboard_body = {
    "widgets": [
        {
            "type": "metric",
            "properties": {
                "metrics": [["MyApplication", "ActiveUsers"]],
                "title": "Active Users"
            }
        }
    ]
}

수많은 서버에서 쏟아지는 데이터를 어떻게 효율적으로 볼 수 있을까요? 여기서 대시보드의 중요성이 드러납니다.

박시니어 씨가 자신의 화면을 보여주었습니다. 깔끔하게 정리된 그래프들이 한 화면에 보였습니다.

"이게 우리 팀 대시보드예요. 한눈에 서비스 상태를 파악할 수 있죠." **지표(Metrics)**란 무엇일까요?

쉽게 말해 시간에 따라 변하는 숫자 데이터입니다. 체중계에 매일 올라가서 몸무게를 기록하는 것처럼, CloudWatch는 매분, 매초 서버의 상태를 숫자로 기록합니다.

지표는 **네임스페이스(Namespace)**로 구분됩니다. AWS 서비스들은 각자의 네임스페이스를 가지고 있습니다.

EC2는 AWS/EC2, RDS는 AWS/RDS 네임스페이스에 지표를 저장합니다. 마치 도서관에서 책을 분류하는 것과 같습니다.

**차원(Dimensions)**은 지표를 더 세분화합니다. 같은 CPU 사용률이라도 어떤 인스턴스의 것인지 구분해야 하니까요.

인스턴스 ID, 환경(Production/Staging), 서비스명 등으로 지표를 구분할 수 있습니다. 위의 코드에서 put_metric_data 함수는 커스텀 지표를 CloudWatch에 보내는 방법을 보여줍니다.

AWS가 기본으로 수집하지 않는 애플리케이션 고유의 데이터를 직접 보낼 수 있습니다. 예를 들어 현재 활성 사용자 수, 장바구니에 담긴 상품 수, 결제 성공률 같은 비즈니스 지표를 추적할 수 있습니다.

이런 커스텀 지표는 기술적인 문제뿐 아니라 비즈니스 이상 징후도 감지하는 데 유용합니다. 대시보드를 만들 때는 몇 가지 원칙이 있습니다.

첫째, 가장 중요한 지표를 상단에 배치합니다. 대시보드를 열자마자 서비스 상태를 알 수 있어야 합니다.

둘째, 관련된 지표는 함께 배치합니다. CPU 사용률 옆에 메모리 사용률을 두면 상관관계를 파악하기 쉽습니다.

셋째, 적절한 시간 범위를 설정합니다. 실시간 모니터링용, 일간 추이용, 주간 분석용 대시보드를 따로 만드는 것도 좋습니다.

김개발 씨는 첫 번째 대시보드를 만들어보았습니다. EC2 인스턴스의 CPU, 메모리, 네트워크 지표를 한 화면에 배치했습니다.

"오, 이제 서버 상태가 한눈에 들어오네요!"

실전 팁

💡 - 대시보드는 팀원들과 공유할 수 있으니 팀 전용 대시보드를 만들어 두면 유용합니다

• 지표 보존 기간은 해상도에 따라 다르니, 장기 분석이 필요하면 S3로 내보내기를 고려하세요

---

3. 경보 생성 및 SNS 알림 연동

한밤중에 서버가 다운되면 어떻게 알 수 있을까요? 김개발 씨는 걱정이 됐습니다.

"24시간 대시보드를 볼 수는 없잖아요." 박시니어 씨가 답했습니다. "그래서 **경보(Alarm)**가 있는 거예요.

문제가 생기면 자동으로 알려주거든요."

CloudWatch 경보는 지표가 설정한 임계값을 넘으면 자동으로 알림을 보내는 기능입니다. 마치 집에 설치한 화재 경보기가 연기를 감지하면 경보음을 울리듯, CloudWatch 경보는 서버에 이상이 생기면 담당자에게 알려줍니다.

**SNS(Simple Notification Service)**와 연동하면 이메일, SMS, Slack 등 다양한 채널로 알림을 받을 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-2')

# CPU 사용률이 80%를 넘으면 경보 발생
cloudwatch.put_metric_alarm(
    AlarmName='HighCPUAlarm',
    AlarmDescription='CPU 사용률이 80%를 초과했습니다',
    MetricName='CPUUtilization',
    Namespace='AWS/EC2',
    Dimensions=[
        {'Name': 'InstanceId', 'Value': 'i-1234567890abcdef0'}
    ],
    Statistic='Average',
    Period=300,  # 5분
    EvaluationPeriods=2,  # 연속 2회
    Threshold=80.0,
    ComparisonOperator='GreaterThanThreshold',
    ActionsEnabled=True,
    AlarmActions=[
        'arn:aws:sns:ap-northeast-2:123456789012:AlertTopic'
    ]
)

서버 모니터링에서 가장 중요한 것은 무엇일까요? 바로 문제가 생겼을 때 빠르게 아는 것입니다.

아무리 좋은 대시보드가 있어도 사람이 항상 지켜볼 수는 없습니다. 새벽 3시에 트래픽이 폭주해서 서버가 힘들어하고 있다면?

담당자가 자고 있으면 아무도 모릅니다. 바로 이런 상황을 위해 CloudWatch 경보가 존재합니다.

경보를 설정하는 것은 마치 집에 화재 경보기를 설치하는 것과 같습니다. 평소에는 조용히 있다가, 연기가 감지되면 큰 소리로 알려줍니다.

CloudWatch 경보도 마찬가지입니다. 평소에는 조용히 지표를 감시하다가, 설정한 조건에 도달하면 알림을 보냅니다.

경보를 만들 때는 몇 가지를 결정해야 합니다. **임계값(Threshold)**은 어느 수준에서 경보를 울릴지 정하는 것입니다.

CPU 사용률 80%가 적절할까요, 90%가 적절할까요? 이건 서비스 특성에 따라 다릅니다.

**평가 기간(Evaluation Periods)**은 연속으로 몇 번 임계값을 넘어야 경보를 울릴지 정합니다. 순간적으로 한 번 넘는 건 괜찮지만, 연속 2번 넘으면 문제라고 판단하는 식입니다.

이렇게 하면 일시적인 스파이크에 민감하게 반응하지 않습니다. 위의 코드에서 EvaluationPeriods가 2로 설정되어 있습니다.

5분 간격으로 측정하면서 연속 2회, 즉 10분 동안 CPU가 80%를 넘으면 경보가 발생합니다. 경보가 발생하면 어떻게 알림을 받을까요?

여기서 SNS가 등장합니다. SNS는 AWS의 메시지 전송 서비스입니다.

경보가 발생하면 SNS 토픽으로 메시지를 보내고, 그 토픽을 구독한 모든 대상에게 알림이 전달됩니다. 이메일, SMS, HTTP 엔드포인트, 심지어 Lambda 함수까지 다양한 대상을 설정할 수 있습니다.

많은 팀에서는 SNS와 Slack을 연동합니다. 경보가 발생하면 즉시 팀 Slack 채널에 메시지가 올라옵니다.

누가 먼저 보든 빠르게 대응할 수 있습니다. 경보에는 세 가지 상태가 있습니다.

OK는 정상 상태, ALARM은 임계값 초과 상태, INSUFFICIENT_DATA는 데이터가 부족해서 판단할 수 없는 상태입니다. 김개발 씨는 첫 번째 경보를 설정했습니다.

테스트로 CPU 부하를 올렸더니 정말로 이메일이 왔습니다. "와, 이제 밤에도 안심하고 잘 수 있겠네요!"

실전 팁

💡 - 경보 임계값은 너무 낮게 설정하면 알림 피로가 생기고, 너무 높으면 놓칠 수 있으니 적절한 값을 찾아야 합니다

• 복합 경보(Composite Alarm)를 사용하면 여러 조건을 AND/OR로 조합할 수 있습니다

---

4. CloudWatch Logs로 애플리케이션 로그 수집

경보가 울렸습니다. CPU 사용률이 치솟았다는 알림이 왔습니다.

김개발 씨는 당황했습니다. "CPU가 높은 건 알겠는데, 왜 높아진 거죠?" 박시니어 씨가 말했습니다.

"로그를 봐야 원인을 알 수 있어요. CloudWatch Logs에 다 기록되어 있거든요."

CloudWatch Logs는 애플리케이션, 시스템, AWS 서비스에서 발생하는 모든 로그를 수집하고 저장하는 서비스입니다. 마치 비행기의 블랙박스가 비행 중 모든 상황을 기록하듯, CloudWatch Logs는 서버에서 일어난 모든 일을 기록해둡니다.

문제가 발생했을 때 이 기록을 통해 원인을 추적할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import logging

# CloudWatch Logs로 로그 전송 설정
logs_client = boto3.client('logs', region_name='ap-northeast-2')

# 로그 그룹 생성
logs_client.create_log_group(logGroupName='/myapp/production')

# 로그 스트림 생성
logs_client.create_log_stream(
    logGroupName='/myapp/production',
    logStreamName='web-server-001'
)

# 로그 이벤트 전송
logs_client.put_log_events(
    logGroupName='/myapp/production',
    logStreamName='web-server-001',
    logEvents=[
        {
            'timestamp': 1704067200000,
            'message': 'ERROR: Database connection failed - timeout after 30s'
        }
    ]
)

지표가 "무엇이 일어났는지"를 알려준다면, 로그는 "왜 일어났는지"를 알려줍니다. CPU 사용률이 치솟았다는 사실은 지표로 알 수 있습니다.

하지만 왜 치솟았는지는 로그를 봐야 합니다. 잘못된 쿼리가 실행됐는지, 무한 루프에 빠졌는지, 갑자기 트래픽이 폭주했는지 로그에서 단서를 찾을 수 있습니다.

CloudWatch Logs의 구조는 간단합니다. 가장 상위에 **로그 그룹(Log Group)**이 있습니다.

보통 애플리케이션이나 서비스 단위로 만듭니다. /myapp/production, /myapp/staging처럼 환경별로 구분하기도 합니다.

로그 그룹 안에는 **로그 스트림(Log Stream)**이 있습니다. 개별 서버나 컨테이너 단위로 만듭니다.

같은 애플리케이션이라도 서버마다 스트림이 다르면 어느 서버에서 문제가 생겼는지 구분할 수 있습니다. 로그 스트림 안에 실제 **로그 이벤트(Log Events)**가 저장됩니다.

타임스탬프와 메시지로 구성된 개별 로그 라인입니다. 로그를 CloudWatch로 보내는 방법은 여러 가지가 있습니다.

EC2 인스턴스에서는 CloudWatch Agent를 설치합니다. 에이전트가 지정한 로그 파일을 감시하다가 새 내용이 추가되면 자동으로 CloudWatch로 전송합니다.

컨테이너 환경에서는 awslogs 드라이버를 사용합니다. Docker나 ECS에서 컨테이너 로그를 자동으로 CloudWatch로 보낼 수 있습니다.

Lambda 함수는 별도 설정 없이 자동으로 CloudWatch Logs에 기록됩니다. 함수 실행 중 print나 console.log로 출력한 내용이 모두 저장됩니다.

위의 코드는 boto3를 사용해 직접 로그를 전송하는 방법을 보여줍니다. 애플리케이션에서 특별한 이벤트를 기록하고 싶을 때 유용합니다.

로그를 잘 남기는 것도 중요합니다. 너무 많이 남기면 비용이 늘고 찾기 어렵습니다.

너무 적게 남기면 문제 추적이 불가능합니다. 적절한 로그 레벨(DEBUG, INFO, WARN, ERROR)을 사용하고, 중요한 정보를 구조화해서 남기는 것이 좋습니다.

보존 기간 설정도 중요합니다. 로그는 무한히 쌓일 수 있고, 그만큼 비용이 듭니다.

로그 그룹별로 보존 기간을 설정할 수 있습니다. 오래된 로그는 자동으로 삭제되거나 S3로 내보낼 수 있습니다.

김개발 씨는 에러 로그를 검색했습니다. "Database connection failed"라는 메시지를 발견했습니다.

"아, 데이터베이스 연결 문제였군요!"

실전 팁

💡 - 로그 메시지에 요청 ID나 사용자 ID를 포함하면 특정 요청의 흐름을 추적하기 쉽습니다

• 보존 기간을 설정하지 않으면 로그가 영구 보관되어 비용이 계속 증가합니다

---

5. Log Insights로 로그 분석

로그가 쌓이기 시작했습니다. 하루에 수만 줄의 로그가 생성됩니다.

김개발 씨는 막막했습니다. "이 많은 로그에서 필요한 정보를 어떻게 찾죠?" 박시니어 씨가 미소지었습니다.

"Log Insights를 써보세요. SQL처럼 로그를 검색할 수 있어요."

CloudWatch Log Insights는 대량의 로그 데이터를 빠르게 검색하고 분석할 수 있는 쿼리 서비스입니다. 마치 도서관의 검색 시스템이 수만 권의 책에서 원하는 책을 찾아주듯, Log Insights는 수억 줄의 로그에서 필요한 정보만 뽑아줍니다.

SQL과 유사한 쿼리 언어를 사용해서 개발자가 쉽게 배울 수 있습니다.

다음 코드를 살펴봅시다.

# Log Insights 쿼리 예제들

# 1. 최근 에러 로그 조회
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100

# 2. 특정 시간대 요청 수 집계
fields @timestamp, @message
| filter @message like /request/
| stats count(*) as requestCount by bin(5m)

# 3. 응답 시간이 느린 요청 찾기
fields @timestamp, @message
| parse @message "response_time=* ms" as responseTime
| filter responseTime > 1000
| sort responseTime desc
| limit 50

# 4. 에러 유형별 통계
fields @timestamp, @message
| filter @message like /ERROR/
| parse @message "ERROR: *" as errorType
| stats count(*) as errorCount by errorType
| sort errorCount desc

로그가 많아지면 새로운 문제가 생깁니다. 원하는 정보를 찾기가 점점 어려워지는 것입니다.

grep 명령어로 "ERROR"를 검색하면 수천 개의 결과가 나옵니다. 그중에서 정말 중요한 에러는 무엇일까요?

언제 가장 많이 발생했을까요? 어떤 패턴이 있을까요?

CloudWatch Log Insights는 이런 질문에 답해줍니다. Log Insights의 쿼리 언어는 SQL을 아는 개발자라면 금방 익숙해질 수 있습니다.

SELECT 대신 fields, WHERE 대신 filter, ORDER BY 대신 sort를 사용하는 정도의 차이입니다. 기본적인 쿼리 구조를 살펴보겠습니다.

fields 명령은 어떤 필드를 조회할지 지정합니다. @timestamp는 로그 발생 시간, @message는 로그 메시지 본문입니다.

로그에 JSON 형태의 구조화된 데이터가 있다면 해당 필드도 직접 조회할 수 있습니다. filter 명령은 조건에 맞는 로그만 걸러냅니다.

like 연산자로 특정 문자열을 포함하는 로그를 찾거나, 비교 연산자로 숫자 조건을 걸 수 있습니다. parse 명령은 비정형 로그에서 특정 패턴을 추출합니다.

"response_time=150 ms" 같은 로그에서 숫자 150만 뽑아서 변수로 사용할 수 있습니다. 이렇게 추출한 값으로 필터링하거나 통계를 낼 수 있습니다.

stats 명령은 집계 함수를 제공합니다. count, sum, avg, min, max 등의 함수로 통계를 낼 수 있습니다.

bin 함수와 함께 사용하면 시간대별 집계도 가능합니다. 위의 코드 예제들을 하나씩 살펴보겠습니다.

첫 번째 쿼리는 최근 에러 로그 100개를 시간순으로 보여줍니다. 가장 기본적인 형태입니다.

두 번째 쿼리는 5분 단위로 요청 수를 집계합니다. 시간대별 트래픽 패턴을 파악할 때 유용합니다.

세 번째 쿼리는 응답 시간이 1초를 넘는 느린 요청만 찾습니다. 성능 문제를 진단할 때 필수적인 쿼리입니다.

네 번째 쿼리는 에러 유형별로 발생 횟수를 세어 가장 많이 발생하는 에러부터 보여줍니다. 어떤 에러를 먼저 해결해야 할지 우선순위를 정할 때 도움이 됩니다.

Log Insights의 장점은 속도입니다. 수십 GB의 로그도 몇 초 만에 검색합니다.

별도의 인덱싱 설정 없이 바로 사용할 수 있어서 편리합니다. 자주 사용하는 쿼리는 저장해두면 좋습니다.

매번 같은 쿼리를 작성하지 않아도 되고, 팀원들과 공유할 수도 있습니다. 김개발 씨는 Log Insights로 지난 일주일간 에러 패턴을 분석했습니다.

"오전 9시에 에러가 집중되네요. 출근 시간에 트래픽이 몰려서 그런가 봐요!"

실전 팁

💡 - 쿼리 결과는 대시보드 위젯으로 추가할 수 있어서 주기적인 모니터링에 활용할 수 있습니다

• parse 명령으로 추출한 필드는 즉시 시각화할 수 있어 로그 기반 지표를 쉽게 만들 수 있습니다

---

6. EventBridge로 이벤트 기반 자동화

모니터링은 이제 어느 정도 갖춰졌습니다. 하지만 김개발 씨에게 새로운 고민이 생겼습니다.

"매번 수동으로 대응해야 하나요? 자동으로 처리할 수는 없을까요?" 박시니어 씨가 눈을 빛냈습니다.

"EventBridge를 사용하면 이벤트가 발생했을 때 자동으로 원하는 작업을 실행할 수 있어요."

Amazon EventBridge는 이벤트 기반 아키텍처를 구현하는 서버리스 이벤트 버스입니다. 마치 건물의 중앙 관제 시스템이 화재 감지기 신호를 받으면 자동으로 스프링클러를 작동시키듯, EventBridge는 특정 이벤트가 발생하면 미리 정해둔 작업을 자동으로 실행합니다.

CloudWatch 경보, AWS 서비스 상태 변화, 심지어 커스텀 이벤트까지 다양한 소스의 이벤트를 처리할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3
import json

events = boto3.client('events', region_name='ap-northeast-2')

# EventBridge 규칙 생성 - 매일 자정에 백업 Lambda 실행
events.put_rule(
    Name='DailyBackupRule',
    ScheduleExpression='cron(0 0 * * ? *)',
    State='ENABLED',
    Description='매일 자정에 백업 작업 실행'
)

# EC2 상태 변경 이벤트 감지 규칙
events.put_rule(
    Name='EC2StateChangeRule',
    EventPattern=json.dumps({
        "source": ["aws.ec2"],
        "detail-type": ["EC2 Instance State-change Notification"],
        "detail": {
            "state": ["stopped", "terminated"]
        }
    }),
    State='ENABLED'
)

# 규칙에 Lambda 타겟 연결
events.put_targets(
    Rule='EC2StateChangeRule',
    Targets=[{
        'Id': 'NotifySlack',
        'Arn': 'arn:aws:lambda:ap-northeast-2:123456789012:function:notify-slack'
    }]
)

모니터링의 궁극적인 목표는 무엇일까요? 단순히 문제를 발견하는 것을 넘어, 자동으로 대응하는 것입니다.

새벽 3시에 경보가 울렸다고 생각해봅시다. 담당자가 일어나서 상황을 파악하고 조치를 취하는 데 30분이 걸립니다.

하지만 미리 자동화를 해두면 경보가 울리는 순간 바로 대응이 시작됩니다. Amazon EventBridge는 이런 자동화의 중심 역할을 합니다.

EventBridge의 동작 방식은 간단합니다. 이벤트 소스에서 이벤트가 발생하면, **규칙(Rule)**이 그 이벤트를 감지하고, 조건에 맞으면 **타겟(Target)**으로 전달합니다.

이벤트 소스는 다양합니다. AWS 서비스들은 상태가 변경될 때마다 이벤트를 발생시킵니다.

EC2 인스턴스가 시작되거나 종료될 때, S3에 새 파일이 업로드될 때, RDS 스냅샷이 완료될 때 등 거의 모든 AWS 활동이 이벤트로 발생합니다. 규칙은 두 가지 방식으로 정의할 수 있습니다.

**이벤트 패턴(Event Pattern)**은 특정 이벤트를 감지합니다. 위 코드의 두 번째 예제처럼 EC2 인스턴스가 중지되거나 종료될 때만 반응하도록 설정할 수 있습니다.

JSON 형식으로 조건을 세밀하게 지정합니다. **스케줄 표현식(Schedule Expression)**은 시간 기반 트리거입니다.

cron 표현식으로 매일 자정, 매주 월요일, 매월 1일 등 원하는 시간에 작업을 실행할 수 있습니다. 위 코드의 첫 번째 예제가 이 방식입니다.

타겟은 이벤트가 도착했을 때 실행할 대상입니다. Lambda 함수가 가장 많이 사용되지만, SNS 토픽, SQS 큐, Step Functions, 심지어 다른 AWS 계정의 이벤트 버스까지 다양한 대상을 지정할 수 있습니다.

실무에서 흔히 사용하는 자동화 시나리오를 몇 가지 살펴보겠습니다. 자동 스케일링: CPU 사용률이 높아지면 Lambda가 실행되어 추가 인스턴스를 시작합니다.

비용 관리: 개발 환경의 인스턴스를 퇴근 시간에 자동으로 중지하고 출근 시간에 시작합니다. 보안 대응: 보안 그룹이 변경되면 즉시 감사 로그를 남기고 담당자에게 알림을 보냅니다.

데이터 파이프라인: S3에 새 파일이 업로드되면 자동으로 ETL 작업을 시작합니다. EventBridge와 CloudWatch의 조합은 강력합니다.

CloudWatch 경보가 ALARM 상태가 되면 이 자체가 이벤트로 발생합니다. EventBridge에서 이 이벤트를 감지해서 자동 복구 Lambda를 실행하거나, 인시던트 관리 시스템에 티켓을 생성할 수 있습니다.

김개발 씨는 첫 번째 자동화 규칙을 만들었습니다. EC2 인스턴스가 중지되면 Slack으로 알림이 가는 규칙입니다.

"이제 수동으로 확인하지 않아도 되겠네요!" 박시니어 씨가 덧붙였습니다. "이게 시작이에요.

점점 더 많은 것을 자동화하다 보면, 나중에는 대부분의 일상적인 운영 작업이 자동으로 처리될 거예요."

실전 팁

💡 - 이벤트 패턴은 가능한 구체적으로 작성하여 불필요한 트리거를 줄이세요

• 실패 시 재시도와 데드레터 큐를 설정하여 이벤트 처리 실패에 대비하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!