AWS 06 관측·운영 — CloudWatch·CloudTrail·Systems Manager·AppConfig·X-Ray·Config·Health

EC2 에 올린 애플리케이션이 하루 10 GB 씩 로그를 찍어 CloudWatch Logs 로 보냅니다. 이 로그를 30일만 보관하게 걸어 두어도 서울 리전에서 한 달 약 $225 가 나갑니다. 보관 기간을 걸지 않으면 로그는 지워지지 않고 계속 쌓입니다. 로그를 담는 로그 그룹(CloudWatch Logs 에서 로그를 모아 두는 단위)의 보관 기간 기본값이 무기한이기 때문입니다(Working with log groups and log streams). 그런데 계산해 보면 $225 대부분은 쌓아 두는 보관 요금이 아니라 받아들이는 수집 요금에서 나옵니다. 어느 줄에서 돈이 나가는지는 1절에서 셈합니다.

이 편은 서비스를 띄운 다음에 생기는 질문 셋에 차례로 답합니다. 셋은 지금 무슨 일이 일어나고 있나(CloudWatch·X-Ray), 누가 무엇을 바꿨나(CloudTrail·Config), 설정은 어떻게 바꾸나(Systems Manager·AppConfig)입니다. 마지막으로 AWS 쪽에서 난 문제가 내 리소스에 닿는지를 알려 주는 Health 를 봅니다. 요금은 전부 2026-09-27 서울(ap-northeast-2) 기준이고, 리전을 안 적은 값은 출처가 리전을 밝히지 않은 것입니다.

지도

flowchart TD
    START["운영 중에<br/>무엇을 알고 싶나"] --> Q1{"질문의 종류"}
    Q1 -- "지금 상태<br/>수치·로그" --> CW["CloudWatch"]
    Q1 -- "요청 한 건이<br/>어디서 느렸나" --> XR["X-Ray<br/>OpenTelemetry"]
    Q1 -- "누가 어떤<br/>API 를 불렀나" --> CT["CloudTrail"]
    Q1 -- "리소스 설정이<br/>언제 어떻게 바뀌었나" --> CF["Config"]
    Q1 -- "설정값을<br/>바꾸고 싶다" --> Q2{"배포 안전장치가<br/>필요한가"}
    Q2 -- "아니다" --> PS["Parameter Store"]
    Q2 -- "필요하다" --> AC["AppConfig"]
    Q1 -- "AWS 쪽<br/>장애인가" --> HE["Health"]

질문의 종류가 서비스를 정합니다. CloudWatch 는 수치와 로그로 지금 상태를 보여 주고, X-Ray 는 요청 한 건이 여러 서비스를 지나간 경로를 보여 줍니다. 그림에서 X-Ray 옆에 붙은 OpenTelemetry 는 2절에서 함께 봅니다. CloudTrail 은 누가 어떤 API 를 불렀는지, Config 는 그 결과 리소스 설정이 어떻게 바뀌었는지를 남깁니다. 설정값을 바꾸는 길은 둘인데, 값만 보관하면 되면 Parameter Store, 조금씩 퍼뜨리다 문제가 생기면 되돌리는 배포가 필요하면 AppConfig 입니다. 둘 다 Systems Manager 쪽 기능입니다. 서버에 접속하는 Session Manager 는 질문이 아니라 작업이라 그림에 두지 않았습니다.

1. CloudWatch — 지표·로그·알람

CloudWatch 가 다루는 것은 크게 셋입니다. 시간에 따라 찍히는 숫자인 지표(metric), 애플리케이션과 AWS 서비스가 남기는 텍스트 기록인 로그, 그리고 지표가 기준을 넘으면 무언가를 하는 알람(alarm)입니다.

지표와 알람 — 무료로 오는 것과 돈을 내는 것

지표는 「EC2 인스턴스 하나의 CPU 사용률」처럼 시간 순서로 늘어선 값의 묶음입니다. 지표는 이름, 네임스페이스(namespace, AWS/EC2 처럼 지표를 서비스별로 가르는 이름표), 그리고 차원(dimension, InstanceId=i-123 같은 이름·값 쌍)으로 하나가 정해집니다. EC2·EBS·RDS 같은 서비스는 기본 지표를 추가 요금 없이 보냅니다. EC2 의 기본 모니터링은 5분 간격이고, 1분 간격으로 받으려면 세부 모니터링을 켜고 지표마다 요금을 냅니다(Manage detailed monitoring for your EC2 instances).

EC2 기본 지표에 메모리와 디스크 사용률은 없습니다. 이 둘은 인스턴스 안에서 재야 해서, 인스턴스에 CloudWatch 에이전트(인스턴스 안에서 지표와 로그를 모아 보내는 AWS 의 수집 프로그램)를 깔아야 합니다. 에이전트가 모은 지표는 사용자 지정 지표로 요금이 붙습니다(Collect metrics, logs, and traces using the CloudWatch agent). 애플리케이션이 직접 보내는 「주문 수」 같은 지표도 같은 요금입니다.

사용자 지정 지표에서 요금이 새는 곳은 차원입니다. CloudWatch 는 차원 값의 조합 하나하나를 별개의 지표로 셉니다. 「주문 수」에 userId 를 차원으로 달면 사용자 1만 명이 지표 1만 개가 되고, 서울 기준 지표 하나 월 $0.30 × 1만 개로 월 $3,000 입니다. 차원에는 경로·상태 코드처럼 값의 가짓수가 적은 것만 답니다.

알람은 지표 하나를 정한 기간 단위로 지켜봅니다. 최근 N개 기간 가운데 정한 M개에서 값이 기준을 넘으면(연속이 아니어도 됩니다) SNS(Simple Notification Service, 메일·문자·HTTP 로 알림을 뿌리는 서비스) 주제로 알리거나 Auto Scaling 정책을 부릅니다. M 을 1보다 크게 두면 순간 한 번 튄 값으로는 울리지 않습니다(Using Amazon CloudWatch alarms — alarm evaluation).

요금은 지표 수와 알람 수, 그리고 지표 그래프를 모아 보는 화면인 대시보드 수로 붙고, 지표는 시간 단위로 나눠 그 시간에 값을 보낸 것만 셉니다(Amazon CloudWatch Pricing).

CloudWatch 지표·알람·대시보드 · 서울 · 2026-09-27
  사용자 지정 지표   첫 1만 개      지표 하나 월 $0.30
                     다음 24만 개   $0.10 · 그 뒤 더 싸진다
  API 요청           1,000건당 $0.01 (지표를 올리는 호출 포함)
  표준 알람          알람이 보는 지표 하나 월 $0.10
  고해상도 알람      월 $0.30 (10초·30초 주기)
  대시보드           하나 월 $3.00 (리전 표기 없음)
  월 무료            지표 10개 · 알람 10개 · API 100만 건 · 대시보드 3개

로그 — 보관 기간 기본값이 무기한이다

CloudWatch Logs 에서 한 출처가 보내는 로그 줄의 흐름이 로그 스트림이고, 보관 기간·권한 설정을 함께 쓰는 스트림의 묶음이 로그 그룹입니다. 보관 기간은 로그 그룹마다 정하고, 정하지 않으면 지우지 않습니다. 기간을 정해도 만료된 로그가 지워지기까지 보통 72시간까지 걸리지만, 만료 표시가 붙은 순간부터 보관 요금에서는 빠집니다.

로그 요금은 세 줄로 나뉩니다. 받아들일 때의 수집, 쌓아 두는 보관, 그리고 Logs Insights(로그 그룹에 질의문을 던져 검색·집계하는 기능)가 읽은 양입니다. 보관 요금은 압축한 뒤의 크기로 매깁니다.

로그 그룹은 기본인 표준 클래스 말고 Infrequent Access 클래스로도 만들 수 있습니다. 수집 단가가 절반인 대신 기능이 적습니다. 로그 줄을 세어 지표로 바꾸는 지표 필터(metric filter), 로그를 실시간으로 흘려보는 Live Tail, 다른 서비스로 로그를 넘기는 구독 필터를 못 쓰고, 로그는 Logs Insights 로만 읽습니다. 클래스는 로그 그룹을 만든 뒤에 못 바꿉니다. 두 클래스가 다른 것은 수집 단가 한 줄뿐이고 보관 단가는 같습니다(Log classes).

CloudWatch Logs · 서울 · 2026-09-27
  수집   표준 클래스               GB 당 $0.76
         Infrequent Access 클래스  GB 당 $0.38
  보관   압축 뒤 GB-월 당 $0.0314
  Logs Insights   읽은 GB 당 $0.0076
  월 무료   수집 5 GB · 보관 5 GB · Insights 5 GB

하루 10 GB 를 30일 보관하면

첫머리의 로그로 셈합니다. 애플리케이션이 하루 10 GB 를 표준 클래스 로그 그룹에 넣고, 보관 기간을 30일로 걸었습니다. 보관 중인 원본은 늘 30일치 300 GB 안팎입니다. 압축 뒤 크기는 요금 페이지가 밝힌 압축 비율 0.15 로 셈해 45 GB 로 잡습니다(Amazon CloudWatch Pricing).

하루 10 GB · 30일 보관 · 서울 · 한 달
  수집   (300 GB − 무료 5 GB) × $0.76          = $224.20
  보관   (45 GB − 무료 5 GB) × $0.0314          =   $1.26
  합계                                          ≈ $225.46

한 달 약 $225 가운데 99% 가 수집입니다. 보관 기간을 안 걸었다면 압축본이 달마다 45 GB 씩 쌓여 1년 뒤 540 GB, 보관 요금이 월 약 $17 이 되고, 그 뒤로도 해마다 그만큼 오릅니다. 무기한 기본값은 조용히 새는 구멍이지만 큰 구멍은 수집 쪽입니다.

수집을 줄이는 길은 둘입니다. 같은 로그를 Infrequent Access 클래스에 넣으면 수집이 $112.10 으로 절반이 되고, 디버그 로그를 꺼서 양 자체를 줄이면 줄인 만큼 그대로 빠집니다. Logs Insights 는 읽은 양으로 받아서, 이 로그 그룹의 최근 7일(70 GB)을 한 번 훑으면 약 $0.53 입니다.

CloudWatch 는 기본 지표 알람과 적은 로그에는 싸지만, 로그 양과 차원 가짓수가 늘면 요금이 그대로 따라 붙습니다.

표준 클래스로 받기엔 로그가 많으면 Infrequent Access 클래스로 나누거나 로그 양부터 줄입니다. 지표를 Prometheus(지표를 주기적으로 긁어 모으는 오픈소스 모니터링 도구) 방식으로 모으고 Grafana 로 보는 팀은 14-2편의 Managed Service for Prometheus·Managed Grafana 로 갑니다.

2. X-Ray — 요청 한 건이 어디서 느렸나

API 응답이 가끔 3초씩 걸리는데 CloudWatch 지표로는 어느 구간인지 안 보입니다. 요청 하나가 API Gateway → 애플리케이션 → DynamoDB → 외부 API 를 지나는 동안 각 구간에 얼마를 썼는지를 이어 붙인 기록이 추적(trace)이고, 이렇게 서비스 여러 개에 걸친 추적을 모으는 방식을 분산 추적이라고 합니다. X-Ray 는 AWS 의 분산 추적 서비스이고, 추적 하나는 구간별 기록인 스팬(span)들로 이뤄집니다(What is AWS X-Ray?).

모든 요청을 다 기록하지는 않습니다. 기본 샘플링 규칙은 초마다 첫 요청 하나와 나머지의 5% 만 기록합니다. 규칙은 콘솔에서 바꾸고, 코드를 다시 배포하지 않아도 됩니다(Configuring sampling rules).

그런데 실패한 주문 한 건을 골라 추적해야 할 때처럼, 샘플링에서 빠진 요청까지 찾아봐야 하는 경우가 있습니다. 이때는 Transaction Search 를 켭니다. X-Ray 로 보낸 스팬을 전부 CloudWatch Logs 의 aws/spans 로그 그룹에 넣고 검색하는 기능이고, CloudWatch 요금으로 따로 받습니다(Transaction Search).

X-Ray 에서 지금 알아 둘 변화는 계측(애플리케이션 코드에 추적 기록을 심는 일) 방식입니다. 추적 코드를 넣는 X-Ray SDK 와, SDK 가 보낸 기록을 모아 올리는 X-Ray 데몬이 2026-02-25 부터 유지보수 모드에 들어가 보안 수정만 받습니다. 지원 종료일은 지금 공식 일정표에 적혀 있지 않습니다(X-Ray SDK and Daemon Support timeline). AWS 는 새 애플리케이션과 기존 애플리케이션 모두 OpenTelemetry(지표·로그·추적을 모으는 업계 표준 계측 도구 모음) SDK 나 그 AWS 배포판인 ADOT(AWS Distro for OpenTelemetry)로 계측하고, 데몬 대신 CloudWatch 에이전트나 OpenTelemetry Collector 로 모으라고 권합니다. 옮긴 뒤에도 CloudWatch 콘솔의 추적 화면과 X-Ray API 는 그대로 씁니다(Migrating from X-Ray instrumentation to OpenTelemetry instrumentation). 그러니 지금 새로 계측한다면 X-Ray SDK 가 아니라 OpenTelemetry 로 시작합니다.

X-Ray 자체 요금은 기록한 추적과 조회한 추적을 따로 셉니다.

X-Ray · 서울 · 2026-09-27
  기록한 추적          100만 건당 $5.00
  조회·검색한 추적      100만 건당 $0.50
  월 무료              기록 10만 건 · 조회·검색 100만 건

샘플링 비율이 요금과 볼 수 있는 범위를 함께 정합니다.

3. CloudTrail — 누가 어떤 API 를 불렀나

어제 밤 보안 그룹의 22번 포트가 누군가에 의해 전 세계로 열렸다고 해 봅니다. CloudWatch 는 이 사건을 모릅니다. CloudWatch 는 리소스가 어떻게 돌고 있는지를 재고, 콘솔 클릭·CLI·SDK 호출은 결국 전부 AWS API 호출이라 누가 어떤 API 를 불렀는지는 CloudTrail 이 남깁니다. 기록 한 건을 이벤트라고 하고, 호출한 IAM 주체(userIdentity)·시각·출발지 IP·요청 인자(requestParameters)가 들어 있습니다(CloudTrail record contents).

CloudTrail 은 계정을 만들면 이미 켜져 있습니다. 콘솔의 이벤트 기록(Event history)이 리전마다 최근 90일의 관리 이벤트를 무료로 보여 줍니다. 관리 이벤트는 보안 그룹 수정·IAM 사용자 생성처럼 리소스를 만들고 바꾸고 지우는 호출입니다. 다만 이벤트 기록은 90일이 지나면 사라지고, 한 계정·한 리전만 보며, 검색 조건을 속성 하나만 겁니다(Working with CloudTrail event history).

더 오래 두려면 트레일(trail)을 만들어 이벤트를 S3 버킷에 파일로 계속 받습니다. 관리 이벤트의 첫 사본은 무료이고, 같은 관리 이벤트를 다른 트레일로 한 벌 더 받으면 요금이 붙습니다. 데이터 이벤트는 S3 객체 읽기·쓰기나 Lambda 함수 호출처럼 리소스 안에서 일어나는 대량 호출이라 기본으로 기록하지 않고, 켜면 건마다 받습니다.

CloudTrail · 서울 · 2026-09-27
  이벤트 기록(90일 · 관리 이벤트)       무료
  트레일 관리 이벤트 첫 사본            무료
  관리 이벤트 추가 사본                 10만 건당 $2.00
  데이터 이벤트                         10만 건당 $0.10
  + S3 저장 요금

데이터 이벤트는 S3 버킷 하나에 초당 100건만 읽혀도 30일이면 2억 5,920만 건, 약 $259 입니다(AWS CloudTrail Pricing). 켤 때는 민감한 버킷 몇 개로 범위를 좁힙니다. 트레일 파일은 S3 에 쌓이므로 검색은 Athena(S3 파일에 SQL 을 던지는 서비스, 11편) 같은 도구로 합니다. 이벤트를 SQL 로 바로 질의하던 CloudTrail Lake 는 2026-03-31 에 발표된 대로 2026-05-31 부터 새 고객을 받지 않기 때문입니다(Services in Maintenance · CloudTrail Lake availability change).

무료로 오는 90일 기록을 넘어서는 순간부터는 트레일·S3·검색 도구를 직접 갖춰야 합니다.

4. Config — 리소스 설정이 어떻게 바뀌었나

CloudTrail 이 「누가 AuthorizeSecurityGroupIngress 를 불렀다」를 남긴다면, Config 는 그 결과 보안 그룹이 어떤 모양이 되었는지를 남깁니다. Config 의 구성 레코더(configuration recorder)가 켜져 있으면, 리소스가 만들어지거나 바뀌거나 지워질 때마다 그 순간의 설정을 구성 항목(configuration item, CI)으로 기록합니다. 구성 항목을 이어 보면 리소스 하나의 설정 변경 이력이 됩니다.

기록 주기는 둘입니다. 연속 기록은 바뀔 때마다 구성 항목을 남기고, 일일 기록은 지난 24시간의 마지막 상태가 전과 다를 때만 하루 한 번 남깁니다(Recording AWS Resources with AWS Config). 레코더를 켜면 기본으로 그 리전에서 지원하는 모든 리소스 종류를 기록하므로, 스팟 인스턴스나 Auto Scaling 처럼 자주 생겼다 사라지는 리소스가 많으면 구성 항목이 불어납니다.

구성 항목 위에 Config 규칙을 걸면 「S3 버킷은 공개 접근이 막혀 있어야 한다」 같은 조건을 리소스마다 검사해 준수·위반을 표시합니다. AWS 가 만들어 둔 관리형 규칙을 고르거나, Lambda 함수로 직접 짭니다. 요금은 기록한 구성 항목 수와 규칙 평가 횟수로 셉니다(AWS Config Pricing).

AWS Config · 서울 · 2026-09-27
  구성 항목   연속 기록   하나당 $0.003
              일일 기록   하나당 $0.012
  규칙 평가   첫 10만 건  하나당 $0.001
              다음 40만 건 $0.0008 · 그 뒤 $0.0005
  + S3(이력 파일)·SNS·Lambda(직접 짠 규칙) 요금

리소스 변화가 잦을수록 설정 이력과 규칙 검사 요금이 따라 늘어납니다.

잦게 바뀌는 리소스 종류는 기록에서 빼거나 일일 기록으로 돌립니다. 일일 기록은 한 건 단가가 연속 기록의 4배지만 하루에 몇 번을 바뀌든 한 건만 남기므로, 하루 네 번 넘게 바뀌는 리소스라면 오히려 쌉니다. 여러 계정의 보안 점검 결과를 한곳에 모으는 Security Hub 는 09편에서 봅니다.

5. Systems Manager — Parameter Store 와 Session Manager

Systems Manager 는 서버와 설정을 다루는 도구 수십 개를 묶은 서비스입니다. 서버 쪽 도구는 인스턴스에 깔린 SSM Agent(Systems Manager 명령을 받아 실행하는 에이전트)를 통해 일합니다. 백엔드 개발자가 많이 쓰는 것은 둘입니다.

Parameter Store 는 설정값을 /myapp/prod/db-host 처럼 경로 모양 이름으로 보관하는 기능입니다. 표준 등급은 계정·리전당 1만 개, 값 4 KB 까지 저장 요금이 없고, 고급 등급은 값 8 KB 에 하나당 월 $0.05 입니다. SecureString 형식으로 두면 KMS 로 암호화합니다. 비밀번호를 자동으로 바꿔 줘야 하는 비밀은 Secrets Manager 몫이고, 둘의 경계와 요금 비교는 05-2편에서 봤습니다.

Session Manager 는 인스턴스에 셸로 접속하는 기능입니다. 인바운드 포트를 열 필요도, 배스천 호스트(사설 서브넷 서버에 들어가려고 공인 서브넷에 세워 두는 중계 서버)를 둘 필요도, SSH 키를 나눠 줄 필요도 없습니다. 누가 어느 인스턴스에 들어갈 수 있는지는 IAM 정책으로 정하고, 세션에서 친 명령과 출력을 S3·CloudWatch Logs 에 남길 수 있습니다. 로컬 포트를 인스턴스 안의 포트로 잇는 포트 포워딩도 되고, 평소 쓰던 SSH 클라이언트 연결을 Session Manager 위로 통과시키는 방식도 됩니다. 다만 이 두 방식은 세션 내용이 기록되지 않습니다(AWS Systems Manager Session Manager).

Session Manager 를 쓰려면 조건이 셋입니다. 인스턴스에 SSM Agent 가 있고, Systems Manager 를 부를 IAM 권한(관리형 정책 AmazonSSMManagedInstanceCore 등)이 있고, ssm·ssmmessages·ec2messages 세 엔드포인트로 443 포트 아웃바운드가 나가야 합니다(Step 1: Complete Session Manager prerequisites). 사설 서브넷이면 NAT Gateway 를 거치거나 세 서비스의 인터페이스 엔드포인트를 만듭니다. 엔드포인트 요금은 04-1편에서 셈했습니다. Session Manager 는 EC2 에 쓰면 추가 요금이 없고, 같은 묶음의 Run Command(여러 인스턴스에 같은 명령을 한 번에 돌리는 도구)·Patch Manager(OS 패치를 일정에 거는 도구)도 마찬가지입니다(AWS Systems Manager Pricing).

두 기능 모두 기본은 공짜에 가깝고, 치르는 것은 돈보다 준비 작업입니다.

6. AppConfig — 재배포 없이 설정을 바꾼다

새 결제 화면을 코드에 넣어 두고 기능은 꺼 둔 채 배포했습니다. 켜는 순간 문제가 생기면 곧바로 끄고 싶고, 켤 때도 전체가 아니라 일부 서버부터 켜고 싶습니다. 이렇게 코드 재배포 없이 기능을 켜고 끄는 스위치를 기능 플래그(feature flag)라고 합니다. AppConfig 는 기능 플래그와 자유 형식 설정(JSON·YAML 등)을 배포하는 서비스이고, Systems Manager 에 속합니다.

Parameter Store 와 가르는 것은 배포 과정입니다. AppConfig 는 설정을 내보내기 전에 검증기(JSON 스키마나 Lambda 함수)로 형식과 값을 검사하고, 배포 전략에 따라 대상(설정을 받아 가는 애플리케이션 쪽 실행 단위. 서버나 컨테이너 한 대 한 대)에 조금씩 퍼뜨립니다. 다 퍼뜨린 뒤에도 베이크 시간(bake time) 동안 지정한 CloudWatch 알람을 지켜보다가, 알람이 울리면 이전 설정으로 자동 롤백합니다(Working with deployment strategies). 설정 원본은 AppConfig 자체 저장소, S3, Parameter Store, Secrets Manager 가운데 고릅니다(What is AWS AppConfig?).

AWS 가 미리 만든 배포 전략은 넷입니다. 일정 비율씩 늘려 가는 선형 둘, 10% 에 먼저 내보내 이상이 없는지 본 뒤 넓히는 카나리 하나, 한 번에 전체로 내보내는 것 하나이고, AWS 는 운영 배포에 선형(6분마다 20%)과 카나리를 권합니다(Using predefined deployment strategies).

애플리케이션은 옆에 띄운 AppConfig Agent(설정을 받아 캐시해 두고 로컬 HTTP 로 내주는 에이전트)에 묻거나, API 를 직접 불러 설정을 받습니다. 요금은 묻는 횟수와 받아 간 횟수 두 줄입니다.

AppConfig · 서울 · 2026-09-27
  설정 요청     100만 건당 $0.20
  받은 설정     한 건당 $0.0008 (바뀐 설정을 대상이 실제로 받아 간 횟수)

받은 설정 한 건이 요청 한 건보다 4,000배 비쌉니다. 그래서 요금은 몇 번 묻느냐보다 몇 번 바꾸고 몇 곳이 받아 가느냐로 정해집니다. 예를 들어 대상 2,000곳이 2분마다 묻고 설정을 하루 세 번 바꾸면 요청은 월 $8.64, 받은 설정 18만 건이 $144 로 합계 $152.64 입니다(AWS Systems Manager Pricing).

자동 롤백은 알람을 미리 만들어 둬야 돌고, 요금은 바꾸는 횟수에 대상 수를 곱한 만큼 붙습니다.

7. Health — AWS 쪽에서 난 문제인가

새벽에 RDS 가 재시작됐다면 내 설정 탓인지 AWS 쪽 유지보수 탓인지부터 가려야 합니다. AWS Health 는 AWS 서비스의 장애와 예정된 활동(유지보수처럼 AWS 가 미리 잡아 둔 변경)이 내 계정의 어떤 리소스에 닿는지를 이벤트로 알려 줍니다. 콘솔의 AWS Health Dashboard 는 설정 없이 누구나 추가 요금 없이 보고, 같은 이벤트를 EventBridge(AWS 이벤트를 규칙에 맞춰 다른 서비스로 보내는 서비스)로도 무료로 받습니다. EventBridge 규칙으로 Health 이벤트를 SNS 에 넘기면 메일로 받아 볼 수 있습니다.

코드에서 Health 이벤트를 조회하는 AWS Health API 는 Business Support+·Enterprise Support 같은 유료 지원 플랜이 있어야 씁니다(What is AWS Health?).

이럴 땐 무엇

자주 붙는 서비스는 SNS(알람 알림), EventBridge(Health 이벤트 전달), S3(트레일·Config 이력 보관), Athena(트레일 검색), KMS(SecureString 암호화), IAM(Session Manager 권한)입니다. 로그에서 알람까지 잇는 구성은 조합 편 26편에서 끝까지 따라갑니다.

한 장 요약

운영 도구는 기능이 아니라 질문으로 고릅니다. 요금이 가장 크게 새는 곳은 CloudWatch Logs 의 수집이라, 하루 10 GB 를 30일만 두어도 월 약 $225 이고 보관 기간을 걸지 않으면 그 위에 무기한 쌓입니다. X-Ray 는 이제 SDK 가 아니라 OpenTelemetry 로 계측합니다.

관련 항목

운영 상태를 보는 같은 갈래

Amazon CloudWatch · CloudWatch Logs · AWS X-Ray · CloudWatch Application Signals · Transaction Search · AWS Health

누가 무엇을 바꿨나를 남기는 기록

AWS CloudTrail · CloudTrail 이벤트 기록 · 트레일 · 관리 이벤트 · 데이터 이벤트 · AWS Config · 구성 항목 · Config 규칙

CloudWatch 요금과 동작을 이루는 단위

지표 · 네임스페이스 · 차원 · 사용자 지정 지표 · 세부 모니터링 · CloudWatch 알람 · 로그 그룹 · 로그 스트림 · 보관 기간 · Logs Insights · 지표 필터 · Infrequent Access 로그 클래스 · CloudWatch 에이전트

설정을 바꾸고 서버를 다루는 도구

AWS Systems Manager · Parameter Store · SecureString · Session Manager · SSM Agent · Run Command · Patch Manager · AWS AppConfig · 기능 플래그 · 배포 전략 · 베이크 시간 · AppConfig Agent

분산 추적을 이루는 개념

분산 추적 · 추적 · 스팬 · 세그먼트 · 샘플링 · 추적 지도 · OpenTelemetry · AWS Distro for OpenTelemetry · OpenTelemetry Collector

이 서비스들이 알림과 기록을 넘기는 곳

Amazon SNS · Amazon EventBridge · Amazon S3 · Amazon Athena · AWS KMS · AWS Secrets Manager · 배스천 호스트 · VPC 엔드포인트 · NAT Gateway

같은 일을 다른 방식으로 하는 수단

Amazon Managed Service for Prometheus · Amazon Managed Grafana · AWS Security Hub · CloudTrail Lake · SSH