AWS 모니터링

Siyun·2025년 3월 12일

AWS

목록 보기

28/37

Amazon CloudWatch

CloudWatch 지표는 AWS의 모든 서비스에 대한 모니터링 변수를 제공한다. CloudWatch는 AWS 리소스의 상태와 성능을 실시간으로 모니터링하고, 각 리소스에 대한 지표(Metrics)를 제공하며 사용자 지정 지표도 만들 수 있다.

핵심 내용:

CloudWatch 지표(Metrics)
- 지표는 AWS 리소스의 성능을 측정하는 변수이다. 예를 들어, EC2 인스턴스의 CPUUtilization, NetworkIn 등이 있다.
- 각 서비스에는 고유의 이름공간(Namespace)이 있으며, 지표는 해당 이름공간에 저장된다.
- 지표는 타임스탬프를 포함하여 시간 기반으로 측정된다.
- 지표의 속성으로 측정 기준(Dimension)이 있다. EC2의 CPU 사용량을 측정할 때 특정 인스턴스 ID나 특정 환경 등과 관련된 지표를 사용할 수 있다. 지표당 최대 측정 기준은 30개이다.
사용자 지정 지표
- CloudWatch는 AWS에서 제공하는 기본 지표 외에도 사용자 지정 지표를 생성할 수 있다.
- 예시: EC2 인스턴스의 메모리 사용량을 추적하는 사용자 지정 지표를 생성하는 경우이다.
CloudWatch 지표 스트리밍
- CloudWatch 지표를 Kinesis Data Firehose나 다른 타사 서비스(Datadog, Dynatrace New Relic, Splunk, Sumo Logic 등)로 실시간으로 스트리밍할 수 있다.
- 예를 들어, 지표를 필터링한 서브셋을 Kinesis Data Firehose 로 근 실시간 스트림 전송하여 Amazon S3에 저장하고 저장된 지표를 Amazon Athena를 사용해 분석할 수 있다. Amazon Redshift를 활용하여 지표로 데이터 웨어하우스를 만들거나 Amazon OpenSearch를 사용해 대시보드를 생성하고 지표 분석을 할 수도 있다.
CloudWatch 대시보드
- CloudWatch 대시보드를 통해 여러 지표를 시각화하고, 시간과 리소스 ID로 필터링할 수 있다.
- 차트 형식으로 지표를 시각화할 수 있으며, .csv 파일로 데이터를 다운로드하여 공유할 수 있다.
타임스탬프와 데이터 필터링
- 데이터를 시간 단위로 필터링하고, 기간을 설정하여 5분 단위 또는 1분 단위의 세부 데이터를 확인할 수 있다.
- CloudWatch 대시보드에서는 데이터를 선형, 영역형, 파이형 차트로 시각화할 수 있다.

CloudWatch Logs

CloudWatch Logs는 AWS에서 애플리케이션 로그를 저장하고 관리할 수 있는 완벽한 도구이다. 이를 사용하려면 먼저 로그 그룹을 정의해야 하며, 각 로그 그룹 안에는 여러 개의 로그 스트림이 포함될 수 있다. 로그 스트림은 애플리케이션의 특정 로그 인스턴스나, 특정 로그 파일, 또는 클러스터 내 특정 컨테이너를 나타낸다.

핵심 내용:

로그 그룹 및 로그 스트림
- 로그 그룹은 애플리케이션이나 서비스를 대표하는 이름을 가지며, 여러 개의 로그 스트림을 포함한다. 로그 스트림은 특정 애플리케이션 인스턴스나 로그 파일 등을 나타낸다.
로그 만료 정책
- 로그는 영구적으로 보관될 수도 있고, 일정 기간(1일부터 10년까지)에 맞춰 만료될 수도 있다. 이를 만료 정책을 통해 정의할 수 있다.
로그 전송
- CloudWatch Logs는 다양한 대상을 통해 로그를 전송할 수 있다. 예를 들어, Amazon S3에 배치 형태로 내보내거나, Kinesis Data Streams, Kinesis Data Firehose, AWS Lambda, Amazon OpenSearch 등으로 실시간 스트리밍할 수 있다.
- 기본적으로 모든 로그는 암호화되며, 필요에 따라 KMS(Key Management Service) 기반 암호화를 설정할 수도 있다.
로그 전송 방법
- SDK를 사용하거나 CloudWatch Unified Agent 또는 CloudWatch Logs Agent를 사용하여 로그를 CloudWatch로 전송할 수 있다. 현재는 Unified Agent가 더 많이 사용되며, Elastic Beanstalk, ECS, Lambda, VPC Flow Logs, API Gateway, CloudTrail, Route 53 등 다양한 AWS 서비스에서 로그를 직접 전송할 수 있다.
CloudWatch Logs Insights
- CloudWatch Logs Insights는 로그 데이터를 쿼리하고 분석할 수 있는 강력한 도구이다. 이를 사용하면 로그 데이터를 시간대에 맞춰 쿼리하고, 그 결과를 시각화하여 대시보드에 추가하거나 내보낼 수 있다.
- 샘플 쿼리도 제공되어, 특정 IP나 오류 이벤트 등을 검색할 수 있다.
- 특별한 목적으로 제작된 쿼리 언어를 제공한다.
- 설령 다른 계정에 있어도 한 번에 다수의 로그 그룹을 쿼리할 수도 있다.
- CloudWatch Logs Insights는 실시간 엔진이 아니라 쿼리 엔진이다. 따라서 쿼리를 실행하면 과거 데이터만 쿼리하게 된다.
Subscription Filter
- Subscription Filter는 전송 대상으로 전달하려는 로그 이벤트의 종류를 지정할 수 있다. 예를 들어 Kinesis Data Streams에 데이터를 전송하여 Kinesis Data Firehose, Kinesis Data Analytics 또는 Amazon EC2 또는 람다와의 통합을 이용하려고 할 경우에 아주 좋다.
- 또한, 직접적으로 데이터를 Kinesis Data Firehose로 전송하거나 커스텀 람다 함수를 작성하여 실시간으로 데이터를 다른 서비스로 전송할 수 있다.
- Subscription Filter 덕분에 다양한 계정과 리전에서 온 CloudWatch Logs 데이터를 하나의 특정 계정에서 Kinesis Data Streams 등에 집계할 수 있다.

다양한 계정과 리전에서 온 CloudWatch Logs 데이터를 하나의 특정 계정에서 Kinesis Data Streams 등에 집계하는 과정

1. 전송 대상 설정: 발신자 계정에서 로그를 수신자 계정의 Kinesis Data Stream으로 전송하도록 CloudWatch Logs Subscription Filter를 설정.
2. 액세스 정책 추가: 발신자 계정이 수신자 계정의 전송 대상으로 로그를 전송할 수 있도록 액세스 정책을 설정.
3. IAM 역할 생성: 수신자 계정에서 로그를 받을 권한을 가진 IAM 역할을 생성.
4. 권한 연결 확인: 발신자 계정이 수신자 계정의 IAM 역할을 사용할 수 있도록 권한을 확인.
5. 로그 전송: 모든 설정이 완료되면, 발신자 계정에서 발생한 로그가 수신자 계정으로 실시간 전송.

배치 내보내기와 실시간 스트리밍
- CreateExportTask API를 사용하여 로그를 Amazon S3로 배치 내보내기를 할 수 있다. 이 내보내기는 최대 12시간까지 걸릴 수 있다.
- 실시간 로그 스트리밍을 원하면 CloudWatch Logs Subscription을 사용하여 로그 이벤트를 Kinesis나 Lambda와 같은 실시간 처리 대상으로 전송할 수 있다.

결론:

CloudWatch Logs는 로그 데이터를 저장하고 관리하는 데 유용하며, 다양한 대상을 통해 로그를 실시간 스트리밍하거나 배치 내보내기할 수 있다. 또한, CloudWatch Logs Insights를 활용하여 로그 데이터를 실시간으로 분석하고 시각화할 수 있어 로그 관리에 매우 효율적이다. Subscription Filter를 통해 다른 계정으로 로그를 전송하는 등 다양한 유연한 설정이 가능하다.

CloudWatch Logs 실습

로그 그룹 확인: CloudWatch Logs에서 여러 로그 그룹을 확인할 수 있다. 예를 들어 Lambda, DataSync, Glue 등 여러 서비스의 로그가 있다.
로그 스트림: 각 로그 그룹 내에는 여러 로그 스트림이 있다. 예를 들어, runCommand로 생성된 로그는 각기 다른 인스턴스를 나타내며, stdout과 stderr가 포함된다.
로그 검색: 특정 키워드(예: "http", "installing")를 검색하여 관련 로그 라인을 쉽게 찾을 수 있다.
지표 필터 생성: 로그에서 특정 패턴을 찾는 지표 필터를 생성할 수 있다. Log groups > Metric filters > Create metric filter로 필터링 된 새로운 지표를 생성하는 것이 가능하다. 예를 들어 "installing" 패턴을 찾고, 해당 패턴이 나타날 때마다 지표 값이 증가한다.
경보 설정: 생성한 지표에 대해 경보를 설정하여 특정 값 이상일 때 알림을 받을 수 있다.
구독 필터: 로그를 다른 서비스(예: Elasticsearch, Kinesis, Lambda 등)로 내보내는 구독 필터를 만들 수 있다. 각 로그 그룹에 최대 2개의 구독 필터를 설정할 수 있다.
보존 기간 설정: 로그의 보존 기간을 설정할 수 있다. 예를 들어, 로그를 120개월(10년)까지 보관하거나 만료되지 않도록 설정할 수 있다.
S3로 내보내기: Action에서 로그 데이터를 Amazon S3로 내보낼 수 있다. 내보낼 데이터의 범위와 S3 버킷을 지정하여 실행한다.
로그 그룹 생성: 새 로그 그룹을 생성할 수 있다. 생성 시 보존 기간과 암호화 설정(KMS 키)을 선택할 수 있다.
CloudWatch Logs Insights: 로그 그룹에 대해 쿼리 언어를 사용하여 데이터를 분석할 수 있다. 예를 들어 최근 60일의 데이터를 조회하고, 쿼리 결과를 저장하거나 내보낼 수 있다.
쿼리 예제: CloudWatch Logs Insights에서는 다양한 예제 쿼리를 제공한다. 예를 들어 Lambda의 대기 시간 통계를 확인하거나 VPC 흐름 로그에서 상위 10개의 전송 바이트를 소스 및 IP 주소별로 정렬할 수 있다.

CloudWatch Logs - Live Tail

CloudWatch Logs의 Live Tail 기능을 통해 실시간으로 로그를 모니터링하고 디버깅할 수 있다.

로그 그룹 및 스트림 생성: 먼저 로그 그룹인 DemoLogGroup을 생성하고, 그 안에 DemoLogStream 로그 스트림을 만든다.

Tailing 시작: 'Start Tailing' 버튼을 눌러 로그 스트림에서 실시간 로그 이벤트를 모니터링할 수 있다. 필터를 설정하여 특정 로그 이벤트를 추적할 수 있다.

실시간 로그 확인: 로그가 생성되면 Live Tail 화면에 실시간으로 나타난다. 예를 들어, "hello world"라는 로그 이벤트를 생성하면 그것이 즉시 Live Tail에서 확인된다.

디버깅 지원: 로그가 스트리밍되면서 발생한 시점, 로그 그룹, 로그 스트림 등의 정보를 확인할 수 있어 디버깅에 유용하다.

가격 및 사용 시간: Live Tail은 하루에 한 시간 무료로 사용할 수 있다. 사용이 끝나면 세션을 취소하고 닫아야 비용이 부과되지 않는다.

CloudWatch 에이전트 및 CloudWatch Logs 에이전트

EC2 인스턴스에서 CloudWatch로 로그와 지표를 보내기 위해 CloudWatch 에이전트를 사용한다. 기본적으로 EC2 인스턴스에는 로그가 자동으로 전송되지 않으므로, 에이전트를 설치해 로그를 푸시해야 한다.

IAM 역할: EC2 인스턴스에서 CloudWatch로 로그를 보낼 수 있도록 IAM 역할이 필요하다.

CloudWatch 에이전트 종류:

CloudWatch Logs 에이전트 (구버전): 로그만 전송한다.
통합 CloudWatch 에이전트 (신버전): 로그뿐만 아니라 시스템 지표(CPU, 메모리, 디스크, 프로세스 등)도 수집하여 전송한다. 이 에이전트는 SSM Parameter Store를 이용해 중앙 집중식 구성도 가능하다.

지표 종류:

CPU 지표: active, guest, idle, system, user 등
디스크 지표: free, use, total, 디스크 IO: writes, reads, bytes, iops
RAM 지표: free, inactive, used, total, cached
네트워크 지표: TCP, UDP 연결, 패킷, 바이트 수
프로세스 지표: total, dead, blocked, idle, running, sleep
스왑 공간: free, used, used % 등

통합 CloudWatch 에이전트의 장점: 통합 에이전트는 기본 EC2 인스턴스 모니터링보다 훨씬 세분화된 지표를 수집할 수 있다. CPU, RAM, 디스크 외에도 프로세스 및 네트워크와 관련된 상세 지표를 얻을 수 있다.

CloudWatch Alarms

CloudWatch Alarms는 특정 지표 값에 대해 알림을 트리거하는 기능이다. 다양한 샘플링, 퍼센트, 최댓값/최솟값 옵션을 통해 복잡한 알람을 설정할 수 있다.

Alarm 상태:

Okay: 트리거되지 않은 상태.
Insufficient data: 데이터 부족으로 상태를 판단할 수 없는 상태.
Alarm: 임계값 초과로 알림이 활성화된 상태.

Period: Alarm이 지표를 평가하는 시간 간격으로, 고해상도 지표에도 적용된다 (예: 10초, 30초, 60초).

Alarm의 주요 대상:
EC2 인스턴스: 정지, 종료, 재부팅, 복구 작업을 할 수 있다.
Auto Scaling: 예를 들어, Scale Out, Scale In을 트리거할 수 있다.
SNS 서비스: SNS를 통해 Lambda와 연동하여 특정 작업을 자동으로 수행할 수 있다.

Composite Alarms:
CloudWatch Alarms는 단일 지표만 모니터링하지만, Composite Alarms는 여러 다른 알람의 상태를 결합하여 모니터링한다.
and 또는 or 조건을 사용하여 유연하게 알람 조건을 설정할 수 있다. 예를 들어, CPU 사용량과 네트워크 사용량을 조합하여 알람을 설정할 수 있다.
여러 지표의 상태를 조합하여 알람을 설정할 때 알람 노이즈를 줄일 수 있다.

EC2 인스턴스에서 Composite Alarm 예시:
Alarm A: EC2 인스턴스의 CPU 사용량 모니터링.
Alarm B: EC2 인스턴스의 IOPS 모니터링.
Composite Alarm: Alarm A와 Alarm B의 상태를 결합하여 동작.

EC2 Instance Recovery:
Instance Status Check: EC2 인스턴스 상태 확인.
System Status Check: EC2 인스턴스가 실행되는 하드웨어 확인.
Attached EBS Status Check: EC2 인스턴스에 연결된 EBS 볼륨 상태 확인.
CloudWatch alarm을 설정하여 이러한 상태 점검이 가능하고 특정 EC2 instance를 모니터링할 수 있다.
알람이 발동하면 EC2 인스턴스를 다른 호스트로 이동시키고, 복구 과정에서 SNS와 연동하여 알림을 받을 수 있다.

CloudWatch Logs Metric Filter:
특정 이벤트를 감지하여 알람을 생성할 수 있다. 예를 들어, 로그에서 "error" 단어가 너무 자주 발생하면 알람을 트리거하여 SNS로 메시지를 보낼 수 있다.

알람 테스트:
Set Alarm States CLI 명령어를 사용하여 알람을 테스트할 수 있다. 이 명령어는 특정 임계값에 도달하지 않아도 알람을 트리거할 수 있도록 한다.

알람 생성 실습

1. Create alarm 을 선택

2. metric 선택에서 인스턴스id를 넣어 선택하고 원하는 지표를 고르기

3. 지표를 계산하는 방법, 알람을 평가하는 길이 선택(5분 권장)

4. 임계값 조건 지정

고정 또는 이상 탐지로 유형을 설정할 수 있고 임계점 초과나 이상 등 경보 조건을 고를 수 있다.

임계값이 95고 Datapoints to alarm을 3 out of 3으로 하면 15분 동안 95% 값이 유지되면 알람을 트리거하겠다는 것이다.

5. 액션 지정

알람이 트리거 됐을 때 어떤 액션을 할지 지정한다.

Amazon EventBridge

Amazon EventBridge는 클라우드에서 이벤트 기반 아키텍처를 구축할 수 있는 서비스이다. EventBridge의 주요 기능과 활용 방법은 다음과 같다.

1. CRON 작업 예약

특정 작업을 정기적으로 예약할 수 있다.
예: 매 시간마다 Lambda 함수를 트리거하여 스크립트를 실행.

2. 이벤트 패턴에 반응

특정 이벤트 발생 시 자동으로 작업을 수행할 수 있다.
예: IAM 루트 사용자 로그인 이벤트에 반응해 SNS 주제로 이메일 알림을 받을 수 있다.

3. 이벤트 소스

다양한 AWS 서비스에서 발생한 이벤트를 받을 수 있다.
예: EC2 인스턴스 시작, 종료, CodeBuild 빌드 실패, S3 객체 업로드 이벤트 등.

4. CloudTrail과 결합

AWS 계정에서 발생한 API 호출을 가로채어 이벤트를 생성할 수 있다.
일정이나 CRON 작업을 예약해 이벤트 발생 시 작업을 트리거할 수 있다.
예: 매월 첫 번째 월요일 오전 8시에 실행되도록 예약 가능.

5. 이벤트 대상

이벤트 발생 시 JSON형식의 이벤트 문서를 만들고 이후 여러 대상에 작업을 트리거할 수 있다.
예: Lambda 함수 실행, ECS 작업 실행, SQS나 SNS 메시지 전송, CodePipeline 실행 등.

6. 이벤트 버스

기본 이벤트 버스: AWS 서비스에서 발생한 이벤트를 받을 수 있다.
파트너 이벤트 버스: 외부 소프트웨어 서비스 제공자와 통합된 이벤트를 받을 수 있다.
- 예: Zendesk, Datadog, Auth0 등.
사용자 지정 이벤트 버스: 자체 애플리케이션의 이벤트를 전송하고 이를 기반으로 작업을 트리거할 수 있다.

7. 이벤트 아카이빙

이벤트를 아카이브하고, 보존 기간을 설정할 수 있다.
아카이브된 이벤트는 재생하여 디버깅 및 테스트에 활용할 수 있다.

8. 스키마 레지스트리

EventBridge는 이벤트의 스키마를 추론하고 이를 기반으로 애플리케이션 코드를 생성할 수 있다.
이벤트 데이터의 정형화 방식을 미리 알 수 있으며, 스키마 버전 관리가 가능하다.

9. 리소스 기반 정책

특정 이벤트 버스의 권한을 관리하여, 특정 계정이나 리전에서 발생한 이벤트를 수신하거나 거부할 수 있다.
예: 여러 계정의 이벤트를 중앙 이벤트 버스(AWS Organizations의 중앙)에 모을 수 있다.

EventBridge 실습

이벤트 버스 생성

EventBridge 콘솔 > Event buses > Create event bus로 새 이벤트 버스 생성
이벤트 아카이브를 활성화 할 수도 있고 스키마 검색을 활성화 하면 자동화로 만들 수도 있다.
이벤트 버스에 교차 액세스가 필요하다면 템플릿에 따라 리소스 기반 정책을 정의해야 한다.

파트너 이벤트 소스 설정

Integration > Partner event sources에서 원하는 파트너사의 Set up을 클릭한다.

Rule 설정

Event > Rules 에서 Create rule을 눌러 룰을 생성한다.
이벤트 버스를 선택하고 특정 이벤트가 일어날 때마다 규칙을 실행할 지, 일정 시간마다 실행할 지 선택할 수 있다.
이벤트 소스를 선택한다. AWS 서비스나 파트너사, 커스텀 이벤트를 선택할 수 있다. 혹은 교차 계정 상 모든 이벤트를 중앙 집중화하도록 All events를 선택하면 리소스 기반 정책에 따라 센트럴 이벤트 버스에 전송된다.
Sample event는 Sandbox와 같은 기능인데 규칙을 만들지 않고도 샘플 이벤트로 이벤트 패턴을 테스트 할 수 있다.
예를 들어, 샘플 이벤트로 EC2 instance State-change Notification을 선택하면 EC2 인스턴스 상태 변경 알림이 일어날 때 EventBridge로 설정해둔 이벤트 타입과 일치하는 지 확인할 수 있다.
이벤트 패턴을 선택한다. 이벤트 소스(EC2)와 이벤트 타입은 위에 샘플 이벤트 대로 해주고 Any state를 선택하면 모든 이벤트가 적용되며 Specific state를 선택해서 특정 이벤트만 알림을 받을 수 있다.
샘플 이벤트와 같은 상황으로 이벤트 패턴을 설정해주고 테스트를 하면 일치한다는 창이 뜬다. 이벤트 패턴대로 이벤트가 만들어진다.
타겟은 알림을 보내는 곳이고 다양한 서비스로 보낼 수 있다.

스키마 레지스트리

Schema registry > Schemas에서 이벤트 스키마를 알아볼 수 있다.
AWS event schema registry 탭에서 aws.ec2를 검색해서 EC2InstancesStateChangeNotification 을 눌러서 보면 Json 형식의 이벤트가 어떻게 구성되어 있는지 정의된 내용을 볼 수 있다.
스키마를 Java, Python TypeScriopt, Go 중 선택해서 코드를 직접 짜지 않고 코드 바인딩을 하여 객체를 훨씬 쉽게 다룰 수 있게 된다.

CloudWatch Insights and Operational Visibility

CloudWatch의 주요 인사이트 서비스는 네 가지로 구분할 수 있다. 각각의 특징을 정리하면 다음과 같다.

1. CloudWatch Container Insights

CloudWatch Container Insights는 컨테이너 환경에서 지표와 로그를 수집, 집계, 요약하는 서비스이다.

Amazon ECS, Amazon EKS, EC2에서 실행되는 Kubernetes, Fargate 환경에서 사용할 수 있다.
컨테이너에서 수집한 데이터를 기반으로 CloudWatch 대시보드를 구성할 수 있다.
Amazon EKS나 Kubernetes에서 실행하는 경우, 컨테이너화된 CloudWatch 에이전트가 필요하다.

2. CloudWatch Lambda Insights

CloudWatch Lambda Insights는 AWS Lambda에서 실행되는 서버리스 애플리케이션을 모니터링하고 트러블슈팅하는 서비스이다.

CPU 시간, 메모리, 디스크, 네트워크 사용량과 같은 시스템 수준의 지표를 수집한다.
Lambda 함수에서 발생하는 콜드 스타트, 작업자 종료 등의 이벤트도 포함한다.
Lambda 계층으로 제공되며, Lambda 함수의 성능을 분석하는 전용 대시보드를 제공한다.
서버리스 애플리케이션의 성능 모니터링이 필요한 경우 유용하다.

3. CloudWatch Contributor Insights

CloudWatch Contributor Insights는 기고자(Contributor) 데이터를 분석하여 로그 기반의 시계열 데이터를 제공하는 서비스이다.

상위 N개의 기고자, 총 고유 기고자 수, 사용량 등을 확인할 수 있다.
네트워크의 주요 트래픽 발생원을 분석하거나, 시스템 성능에 영향을 미치는 대상을 파악하는 데 활용할 수 있다.
VPC 로그, DNS 로그, 기타 AWS가 생성한 로그에서 작동한다.
예를 들어, 네트워크 트래픽이 많은 상위 10개 IP 주소를 분석하여 정상 사용자인지, 악성 사용자인지 판단할 수 있다.
AWS가 제공하는 기본 규칙을 사용할 수도 있으며, 필요에 따라 직접 규칙을 생성할 수도 있다.

4. CloudWatch Application Insights

CloudWatch Application Insights는 모니터링하는 애플리케이션의 잠재적인 문제와 진행 중인 문제를 분리할 수 있도록 자동화된 대시보드를 제공하는 서비스이다.

Java, .NET, Microsoft IIS 웹 서버, 특정 데이터베이스를 선택해 선택한 기술로만 애플리케이션을 실행할 수 있다.
AWS의 여러 리소스(EBS, RDS, ELB, ASG, Lambda, SQS, DynamoDB, S3 등)와 연동하여 애플리케이션 상태를 모니터링한다.
ECS, EKS 클러스터, SNS 주제, API Gateway와도 통합할 수 있다.
애플리케이션에 문제가 발생하면 자동으로 대시보드를 생성하여 애플리케이션의 상태를 시각적으로 제공한다.
내부적으로 SageMaker 머신 러닝 기술을 활용하여 이상 탐지 기능을 강화한다.
탐지된 문제와 알림은 Amazon EventBridge 및 SSM OpsCenter를 통해 전달된다.

CloudTrail

CloudTrail은 AWS 계정의 거버넌스, 컴플라이언스, 감사를 지원하는 서비스이다.
기본적으로 활성화되어 있으며, AWS 계정에서 발생한 모든 이벤트 및 API 호출 이력을 기록한다.
AWS 콘솔, SDK, CLI, 기타 AWS 서비스를 통해 발생한 모든 로그가 CloudTrail에 저장된다.

로그 저장 및 활용

CloudTrail에서 수집된 로그는 CloudWatch Logs 또는 Amazon S3에 저장할 수 있다.
또한, 모든 리전에서 발생한 이벤트를 하나의 S3 버킷에 통합 저장할 수도 있다.
이를 위해 트레일(Trail)을 생성하여 특정 리전 또는 모든 리전에 적용할 수 있다.

CloudTrail의 주요 기능

CloudTrail을 사용하면 AWS 리소스에 대한 변경 사항을 추적하고, 보안 및 감사 목적으로 활용할 수 있다.
예를 들어, EC2 인스턴스가 종료된 경우, 누가 언제 종료했는지를 CloudTrail 로그에서 확인할 수 있다.
IAM 사용자, 역할, 기타 AWS 서비스의 액션도 CloudTrail을 통해 추적 가능하다.

CloudTrail의 이벤트 유형

CloudTrail에서 기록하는 이벤트는 크게 세 가지로 구분된다.

1) 관리 이벤트(Management Events)

AWS 계정 내 리소스에 대한 작업을 기록한다.
기본적으로 로깅되며, IAM 정책 변경, 보안 설정 변경, 서브넷 생성 등 모든 계정 변경 사항을 포함한다.
읽기 이벤트(예: IAM 사용자 목록 조회)와 쓰기 이벤트(예: DynamoDB 테이블 삭제)로 구분된다.
읽기 이벤트는 정보 조회에 해당하며, 쓰기 이벤트는 리소스를 변경하는 동작으로 보안상 더 중요할 수 있다.

2) 데이터 이벤트(Data Events)

개별 리소스에 대한 작업을 기록하며, 기본적으로 로깅되지 않는다.
고용량 작업이므로 필요할 때만 활성화하여 사용한다.
예: S3 객체 수준 작업(GetObject, PutObject, DeleteObject) 및 Lambda 함수 실행 이벤트.
데이터 이벤트도 읽기(GetObject)와 쓰기(DeleteObject, PutObject)로 분리할 수 있다.

3) CloudTrail Insights 이벤트(Insights Events)

비정상적인 API 호출 패턴을 탐지하는 기능으로, 활성화 및 비용이 필요하다.
정상적인 관리 활동을 기준으로 이상 탐지를 수행한다.
예: 부정확한 리소스 프로비저닝, 서비스 한도 도달, IAM 액션 급증, 유지보수 활동 누락 등.
비정상적인 패턴이 감지되면 인사이트 이벤트가 생성되며, S3, EventBridge, CloudWatch 이벤트를 통해 알림을 받을 수 있다.

CloudTrail 이벤트 보관

CloudTrail은 기본적으로 90일 동안 이벤트를 보관한 후 삭제한다.
장기간 보관하려면 이벤트를 CloudWatch Logs나 S3 버킷에 저장하고, Athena를 사용하여 쿼리 및 분석할 수 있다.

CloudTrail 로그 활용

AWS 계정에서 발생한 이벤트를 감시하고, 보안 사고 대응 및 감사를 수행할 수 있다.
필요 시 로그를 S3로 전송하여 장기 보관 및 Athena를 통한 분석이 가능하다.
CloudTrail Insights를 활용하면 이상 활동을 자동으로 탐지할 수 있다.

CloudTrail을 적절히 활용하면 AWS 환경에서 발생하는 모든 액션을 추적하고, 보안 및 운영을 강화할 수 있다.

CloudTrail과 EventBridge 통합

통합하면 AWS 계정에서 중요한 보안 이벤트를 실시간으로 감지하고 대응할 수 있는 강력한 시스템을 구축할 수 있다.
예를 들어, 다음과 같은 활용 사례가 가능하다.

중요한 API 호출 감지 및 알림
- 사용자가 DeleteTable API를 호출하면 해당 이벤트가 CloudTrail에 로깅되고, EventBridge에서 이를 감지하여 SNS를 통해 관리자에게 즉시 알림을 보낼 수 있다.
- 특정 IAM 역할(AssumeRole)을 사용할 때마다 알림을 받을 수 있도록 설정할 수도 있다.
보안 관련 변경사항 감지
- AuthorizeSecurityGroupIngress API 호출을 감지하여 인바운드 트래픽 규칙 변경 시 즉시 경보를 보낼 수 있다.
- CloudTrail에서 CreateUser 또는 AttachRolePolicy 같은 API 호출을 감지하여 계정 내 사용자 또는 권한 변경이 발생할 때 자동 대응이 가능하다.

이처럼 CloudTrail과 EventBridge를 활용하면 AWS 환경에서 보안, 규정 준수, 운영 모니터링을 효과적으로 수행할 수 있다.

AWS Config

AWS Config는 인프라의 상태 변화를 추적하고, 규정 준수 여부를 평가하며, 필요한 경우 인프라를 빠르게 롤백하고 문제점을 찾아낼 수 있는 강력한 감사 및 모니터링 서비스이다. Config는 리전별 서비스이기 때문에 모든 리전별로 구성해야 하며 데이터를 중앙화하기 위해 리전과 계정 간 데이터를 통합할 수 있다.

AWS Config의 핵심 기능

구성 변경 기록 및 감사
- 규칙이 규정을 준수하든 아니든 변화가 생겼을 때마다 SNS 알림을 받을 수 있다.
- 모든 리소스의 구성을 S3에 저장해 Athena를 사용해 나중에 분석할 수도 있다.
- 예를 들어, 보안 그룹에 제한되지 않은 SSH 접근이 있는지, 버킷에 공용 액세스가 있는지, 시간이 지나며 변화한 ALB 구성이 있는지 추적 가능하다.
규정 준수 평가 (Config 규칙)
- AWS 관리형 규칙: 미리 정의된 75개 이상의 규칙 사용 가능. (예: 보안 그룹에 SSH(22) 허용 여부 감지)
- 사용자 정의 규칙: Lambda를 사용하여 직접 규칙을 정의할 수 있다.
  예시 : 각 EBS 디스크가 gp2 유형인지 평가, 개발 계정의 EC2 인스턴스가 t2.micro 유형인지 평가
- 평가 방식
  - 변경 시 평가: 리소스 변경이 감지될 때마다 규칙 평가 수행
  - 정기적 평가: 일정 간격(예: 2시간마다)으로 규칙 평가 수행
자동 수정 및 대응
- Config 자체로는 정책 위반을 차단할 수 없지만, SSM 자동화 문서나 Lambda 함수를 트리거하여 규정 미준수 리소스를 수정 가능
- 예제:
  - 90일 이상 사용된 IAM 액세스 키가 감지되면 RevokeUnusedIAMUserCredentials SSM 문서를 실행하여 키를 자동 비활성화
  - 보안 그룹이 잘못 구성된 경우 Lambda를 트리거하여 원래 상태로 복구
알림 및 이벤트 트리거
- SNS와 EventBridge 연동
  - Config에서 SNS로 규정 미준수 상태를 알릴 수 있음
  - EventBridge를 사용해 특정 이벤트 발생 시 자동으로 대응 가능 (예: ALB 설정 변경 감지 → 알림 전송)
- SNS 필터링 활용
  - 모든 구성 변경과 모든 리소스의 규정 준수 여부 알림을 SNS로 보낼 수 있다.
  - 특정 리소스 변경만 필터링하여 Slack, 이메일 등으로 알림 전송 가능
비용 고려
- 리전별로 Config를 설정해야 하며, 구성 항목당 $0.03, 규칙 평가당 $0.001이므로 사용량이 많아지면 비용이 크게 증가할 수 있음
- 비용 절감 전략
  - 중요한 리소스에만 Config 적용
  - 평가 빈도를 줄이거나, 변경 발생 시에만 평가하도록 설정

AWS Config는 단독으로는 정책 적용 기능이 부족하지만, CloudTrail, EventBridge, Lambda, SSM과 조합하면 강력한 보안 및 규정 준수 시스템을 구축할 수 있다.

Config 실습

서비스 구성하기

Config 콘솔 > Set up AWS Config 선택
이 리전의 모든 리소스 혹은 특정 리소스만 기록하도록 선택
IAM 사용자, 그룹, 역할 고객 관리형 정책 등은 글로벌 리소스로 기록에 포함될 수 있다.

🚨 Config는 유료 서비스이기 때문에 많은 리소스를 기록할수록 요금이 늘어난다.

모든 리소스 구성을 기록하기 위해서 서비스 연결 Role을 생성하거나 원래 내 계정의 Role을 선택할 수 있다.

Deliver method에서 생성된 정보는 S3로 전달될 것이기 때문에 목적지 버킷을 설정한다.

또한 SNS topic으로 모든 구성변화와 알림을 스트리밍 할 수 있다. 한 topic에 모든 게 들어간다.

다음으로 넘어가면 AWS 관리형 규칙을 설정할 수 있다.

리소스 확인하기

Config 콘솔 > Resources 에서 계정 내에서 탐색된 일부 리소스를 확인할 수 있다.
아직 Compilance는 규칙을 정의하지 않았기 때문에 비어있다.
리소스를 누르면 리소스 타임라인(리소스와 관련된 모든 이벤트를 표시)을 확인할 수 있다.

규칙 추가하기

Config 콘솔 > Rules 에서 Add rule로 새 규칙을 추가할 수 있다.
AWS 관리형 규칙을 추가하거나 AWS Lambda로 생성한 사용자 지정 규칙을 추가할 수 있다.

규칙 추가를 완료하면 Rule에서 생성한 규칙의 이름을 선택하면 자동으로 평가가 끝난 결과를 볼 수 있다.

리소스 수정하기

규정 준수가 되지 않을 때 자동 수정, 수동 수정을 할 수 있다.
Config 콘솔 > Resources 에서 리소스를 선택한다.
Rules를 선택하고 Actions > Manage remediation을 하면 규칙을 수정할 수 있다.
자동 수정은 재시도 횟수와 재시도 간격을 설정할 수 있다.
수동 수정을 선택하면 수정 action을 선택해야 한다. 수정 action 목록은 AWS가 정의한 SSM 자동화 문서들이고 스스로 만들 수도 있다.
'

기타

Config 콘솔 > Aggregators 는 다수의 계정을 통합하는 일을 한다.
Setting으로 가면 이전에 정의한 설정을 볼 수 있다.

Siyun

공부 기록

이전 포스트

AWS 머신러닝

다음 포스트

AWS 모니터링

AWS

Amazon CloudWatch

핵심 내용:

CloudWatch Logs

핵심 내용:

결론:

CloudWatch Logs 실습

CloudWatch Logs - Live Tail

CloudWatch 에이전트 및 CloudWatch Logs 에이전트

CloudWatch Alarms

Alarm 상태:

Alarm의 주요 대상:

Composite Alarms:

EC2 인스턴스에서 Composite Alarm 예시:

EC2 Instance Recovery:

CloudWatch Logs Metric Filter:

알람 테스트:

알람 생성 실습

1. Create alarm 을 선택

2. metric 선택에서 인스턴스id를 넣어 선택하고 원하는 지표를 고르기

3. 지표를 계산하는 방법, 알람을 평가하는 길이 선택(5분 권장)

4. 임계값 조건 지정

5. 액션 지정

Amazon EventBridge

1. CRON 작업 예약

2. 이벤트 패턴에 반응

3. 이벤트 소스

4. CloudTrail과 결합

5. 이벤트 대상

6. 이벤트 버스

7. 이벤트 아카이빙

8. 스키마 레지스트리

9. 리소스 기반 정책

EventBridge 실습

이벤트 버스 생성

파트너 이벤트 소스 설정

Rule 설정

아카이브

스키마 레지스트리

CloudWatch Insights and Operational Visibility

1. CloudWatch Container Insights

2. CloudWatch Lambda Insights

3. CloudWatch Contributor Insights

4. CloudWatch Application Insights

CloudTrail

로그 저장 및 활용

CloudTrail의 주요 기능

CloudTrail의 이벤트 유형

CloudTrail 이벤트 보관

CloudTrail 로그 활용

CloudTrail과 EventBridge 통합

AWS Config

AWS Config의 핵심 기능

Config 실습

서비스 구성하기

리소스 확인하기

규칙 추가하기

리소스 수정하기

기타

AWS 머신러닝

AWS IAM 고급

0개의 댓글