# Monitoring, Troubleshooting & Audit

---

## 1. CloudWatch

- **CloudWatch Metrics **- 매 5분마다 모든 AWS 서비스에서 지표를 가져 올 수 있다.

- **EC2 Detailed monitoring** - 매 1분마다 지표를 가져올 수 있다.

- **Custom Metrics **- 메모리 사용량, 디스크 공간, 사용자 수 등을 `PutMetricData` API를 호출해 전송한다. 표준(1분마다)과 고분해능(1초마다) 옵션이 있어, 가격과 API 호출을 조절할 수 있다.

- **DashBoard** - 글로벌에서 동작하며, 여러 계정과 리전을 한 데 모아 볼 수 있다.

### Logs

- **Log Streams** - 지표별 스트림 데이터

- **Log Group **- 로그 스트림의 집합. S3에 저장할 수도 있지만 최대 12시간이 걸리므로 추천하지 않는다. 그 대신 구독 필터를 쓸 수 있다.

- **Subscription Filter** - 로그를 계정, 리전에 상관없이 Kinesis Data Streams, Firehose, Lambda, OpenSearch로 보낼 수 있다.

### Log Agent

EC2나 온프레미스에 로그 에이전트를 설치하고 IAM 권한을 설정해 줘서 CloudWatch Logs로 데이터를 보낼 수 있게 한다. 최근 Logs Agent 대신 **Unified Agent**를 사용해 시스템 수준(CPU, RAM, Disk, Network)의 지표를 수집할 수 있고 SSM Parameter Store와 통합할 수 있다.

- CPU

- Disk Metrics, Disk IO

- Netstat

- Processes

- RAM

- Swap Space

### Alarm

지표가 특성 수치에 도달했을 때, 알림을 주는 서비스이다. `OK`, `INSUFFICENT_DATA`, `ALARM` 상태가 있으며 10초~60초 마다 알릴 수 있게 한다. Alarm의 기능은 아래와 같다.

- **EC2**의 상태를 변경

- **Auto Scaling Action **발생

- **SNS**에 알림

가령, EC2의 인스턴스 상태와 HW 상태를 모두 확인한다. 불량이 확인되면 모든 정보를 유지한 채 재시작할 수 있게 한다.

### Events / Amazon EventBridge

EventBridge는 CloudWatch Events의 발전형으로, 여러 계정과 소스에서 이벤트를 발생시킬 수 있다. 이 이벤트를 통해 Lambda나 Fargate 같은 서비스를 실행할 수도 있다. 아래는 이벤트를 발생시키는 소스 목록이다.

- **Default event bus **- AWS 서비스에 의해 (CloudWatch Event)

- **Partner event bus** - 다른 SaaS 서비스나 어플리케이션에 의해

- **Custom Event bus** - 자체 어플리케이션에 의해

EventBridge는 **Schema Registry**를 지원해 이벤트의 구조를 사전 등록할 수 있다.

# 2. CloudTrail

AWS 계정에 대해 관리, 규정 준수, 감사 기능을 제공하는 서비스이다. 모든 리전에서 이미 실행되어 있으며, 모든 이벤트와 API을 기록해 놓는다. 이 로그는 S3나 CloudWatch Logs로 보낼 수 있다. 단일 리전에 대해서만 CloudTrail을 적용할 수도 있다.

### Events

기본적으로, Management Events만 로깅된다. 90동안만 저장한다.

- **Management Events** - VPC, 보안, 로깅 관련 API. 로그인 등의 중요 이벤트. 읽기/쓰기 이벤트로 나눌 수 있다.

- **Data Events **- 리소스에서 수행되는 작업에 대한 정보. S3 GetObject 등

- **CluodTrail Insights Events** - 비정상적인 활동을 기록. 

### Organizational Trail

관리 계정에서 하위 OU 전부를 CloudTrail에 기록하고 저장할 수 있다. 그러면 CloudTrail은 `<bucket>/Logs/<ou-id>/<account-id>` 형식으로 S3에 저장할 수 있다.

# 3. Config

리전별로 리소스의 구성을 추적하고 감사하는 서비스이다.

- 구성이 바뀔 때마다 이벤트 수신(SNS)

- 구성을 버젼별로 추적

- 리소스별로 구성을 검색

- 여러 계정과 리전을 묶어서 관리

- S3에 구성을 저장해 Athena로 분석

### Config Rule

규칙을 만들고 리소스의 구성 설정을 평가한다. 구성이 변경되거나 주기적으로 규칙을 평가하고, 규칙을 만족하지 못 하면 “규칙 미준수”로 표시한다.  `예)EBS의 타입이 gp2인가`

- 조정 - “규칙 미준수”일 때, SSM Automation Document을 실행해 리소스를 수정할 수 있다.

- 알림 - 이벤트를 트리거하여 서비스를 실행하거나 유저에게 알릴 수 있다.

# 4. CloudWatch vs CloudTrail vs Config

Elastic Load Balancer에 대해 각각의 서비스를 적용한다.

### CloudWatch

- 들어오는 연결 수 측정

- 에러 코드의 비율 측정

- 로드 밸런서의 성능 측정

### CloudTrail

- 누가 API를 호출해서 ELB를 변경했는지 기록

### Config

- 보안 그룹 추적

- 설정 변경 추적

- SSL 자격 증명 적용 여부 확인

# 5. (SAP, DOP)

## 로그 종류

- Application Logs

- Operation System Logs

- Access Logs - 웹사이트에서 파일을 요청한 기록

## AWS Managed Logs

- Load Balancer Access Logs ⇒ S3

- CloudTrail Logs ⇒ S3, CloudWatch Logs

- VPC Flow Logs ⇒ S3, CloudWatch Logs

- Route 53 Access Logs ⇒ S3, CloudWatch Logs

- S3 Access Logs ⇒ S3

- CloudFront Access Logs ⇒ S3

- AWS Config ⇒ S3

For the site tree, see the [root Markdown](https://slashpage.com/kaonmir.md).