Amazon CloudWatch, CloudTrail, Config 정리

Amazon CloudWatch

Amazon CloudWatch Metrics ( 지표 )

• CloudWatch는 AWS의 모든 서비스에 대한 지표를 제공 ⇒ 즉, 계정에서 일어나는 모든 일을 모니터링할 수 있다는 것
• 지표(Metric)는 모니터링할 변수 ⇒ ( EC2 인스턴스 지표로는 CPUUtilization, NetworkIn 등, S3 지표로는 버킷 크기 등 )
• 지표의 속성으로는 측정 기준 ( Dimension )이 있다 ⇒ ex ) CPU 사용률에 대한 지표는 인스턴스 ID나 특정 환경 등과 관련이 있을 것
• 지표 당 최대 측정 기준은 최대 10개
• 지표는 시간을 기반으로 하므로 타임스탬프가 꼭 있어야 한다.
• 지표가 많아지면 CloudWatch 대시보드에 추가해 모든 지표를 한 번에 볼 수 있다.
• 사용자 지정 지표도 만들 수 있음 ⇒ ex ) EC2 인스턴스로부터 메모리 사용량을 추출하는 등

 

CloudWatch Metric Streams

• CloudWatch 지표는 외부로 스트리밍 할 수 있다.
• CloudWatch 지표를 원하는 대상으로 지속적으로 스트리밍하면 거의 실시간으로 전송되고 지연 시간도 짧아진다.
  • Kinesis Data FIrehose가 대상이 될 수 있고 여기서 원하는 곳으로 전송할 수 있다.
  • 서드파티 서비스 제공자로 CloudWatch 지표를 직접 전송할 수도 있다.
• 필요한 지표만 필터링해서 Streams 서비스로 전송할 수 있다.

 

CloudWatch Logs

• AWS에서 로그를 저장하기 최적의 장소
• Log Groups : 로그들을 로그 그룹으로 그룹화 하는데 로그 그룹 이름은 보통 애플리케이션을 나타낸다.
• Log Stream : 각 로그 그룹 내에는 Log Stream이 있는데 로그 스트림은 애플리케이션 내 인스턴스나 다양한 로그 파일명 또는 컨테이너 등을 나타낸다
• 로그 만료일도 정할 수 있다. ( 평생 만료되지 않게 하거나, 일정 기간 후 만료되게 설정할 수 있다. ) ⇒ CloudWatch Logs 스토리지는 유료임
• CloudWatch Logs는 내보낼 수 있다.
  • Amazon S3
  • Kinesis Data Stream
  • Kinesis Data Firehose
  • AWS Lambda
  • ElasticSearch

 

CloudWatch Logs - Sources

• SDK, CloudWatch Logs 에이전트, 통합 CloudWatch 에이전트를 통해 로그를 보낼 수 있다.
• Elastic Beanstalk : 애플리케이션의 로그를 CloudWatch에 전송
• ECS : 컨테이너의 로그를 CloudWatch에 전송
• Lambda : 함수 자체에서 로그를 보낸다.
• VPC Flow Logs : VPC 메타데이터 네트워크 트래픽 로그를 보낸다.
• API Gateway : 받은 모든 요청을 보낸다.
• CloudTrail : 필터링해서 로그를 보낼 수 있다
• Route53 : 모든 DNS 쿼리를 로그로 저장한다.

 

CloudWatch Logs Metric Filter & Insights ( 지표 필터와 인사이트 정의 )

• CloudWatch Logs에서 필터 표현식을 정의할 수 있다 ⇒ ex ) 로그 내 특정 IP 찾기, ‘ERROR’ 문구를 가진 로그 찾기
• 위 지표 필터를 통해 출현 빈도를 계산하여 지표를 만들 수 있다. ⇒ 이렇게 만들어진 지표는 CloudWatch Alarms과 연동할 수 있음
• CloudWatch Logs Insights : 이 기능을 통해 로그를 쿼리하고 이 쿼리를 대시보드에 바로 추가할 수 있다.

 

CloudWatch Logs - S3 내보내기 ( S3 Export )

• S3 로 내보내기가 가능해질 때까지 최대 12시간은 걸릴 수 있다.
• 실시간이 아니다. ⇒ CloudWatch Logs에서 로그를 스트림하고 싶다면 구독 필터를 이용헤야 한다.

 

CloudWatch Logs - Subscriptions

• 구독 필터 : CloudWatch Logs 상단에 적용하여 이를 목적지로 보내는 필터를 의미한다.

 

CloudWatch Logs 여러 계정과 리전간 로그 집계

• 다른 리전에서 각각 구독 필터를 사용해 Kinesis Data Stremas 로 보낸 후 로그를 모아 Firehose → S3로 보낼 수 있다.

 

CloudWatch Agent ( CloudWatch Logs for EC2 )

• 기본적으로 EC2 인스턴스에서 CloudWatch로는 어떠한 로그도 보내지 않는다.
• Agent 프로그램을 실행시키고 EC2 인스턴스에 IAM 권한을 부여해서 CloudWatch로 Logs를 전달할 수 있다.
• On-Premiss 서버에서도 Agent 를 셋업 할 수 있다. ⇒ On-Premiss에도 서비스를 제공할 수 있다.

 

CloudWatch Logs Agent & Unified Agent ( 로그 에이전트 & 통합 에이전트 )

• 둘 다 EC2 인스턴스나 온프레미스 서버 같은 가상 서버를 위한 것이다.
• CloudWatch Logs Agent
  • 통합 에이전트에 비해 오래된 버전
  • CloudWatch Logs로 로그만 보낸다.
• Unified Agent ( 통합 에이전트 )
  • 프로세스나 RAM 같은 추가적인 시스템 단계 지표를 수집한다.
  • CloudWatch Logs에 로그를 전달한다.
  • 지표와 로그 둘 다 사용하기 때문에 통합 에이전트
  • 이전 버전에는 없는 기능인 SSM Parameter Store 를 이용하여 에이전트를 쉽게 구성할 수 있다. ⇒ 모든 통합 에이전트를 대상으로 중앙 집중식 환경 구성을 할 수 있음

 

CloudWatch Unified Agent - Metrics ( 통합 에이전트 - 지표 )

• 에이전트를 EC2 인스턴스나 Linux 서버에 설치하면 지표를 얻을 수 있다.

1. 세분화 된 수준으로 CPU 지표를 얻을 수 있다. ( active, guest, idle, system, user, steal 등 )
2. 디스크 지표 ( free, used, total ), 디스크 IO ( writes, reads, bytes, iops )
3. RAM ( free, inactive, used, total, cached )
4. Netstat ( 넷 상태 ) ( TCP와 UDP 연결, 네트워크 패킷 )
5. Processes ( total, dead, bloqued , idle, running, sleep )
6. Swap Space ⇒ 메모리처럼 쓰는 디스크인 스와프 공간 ( free, used, used % )

• EC2 에서 곧장 네트워크에 대한 지표를 얻을 수 있지만 세부 지표를 얻고 싶다면 통합 CloudWatch Agent 를 이용하면 된다.

 

CloudWatch Alarms

• Alarms은 지표에서 알림을 트리거할 때 사용된다.
• 다양한 옵션 ( max, min, % 등 ) 을 사용하여 복잡한 Alarms을 정의할 수도 있다.
• Alarms States
  • OK ( 트리거 되지 않았음을 의미 )
  • INSUFFICIENT_DATA ( 결정할 데이터가 부족함을 의미 )
  • ALARM ( 임계값이 초과되어 알림이 보내지는 상태 )
• 기간 ⇒ Alarms이 지표를 평가하는 기간을 의미
  • 짧게 설정할 수도 길게 설정할 수도 있다.
  • 고해상도 사용자 지정 지표에도 적용할 수 있는데 10초, 30초 또는 60초의 배수로 설정할 수 있다.

 

CloudWatch Alarm Targets

• EC2 Instance 동작 ⇒ 인스턴스를 멈추거나, 삭제, 재시작, 복구하는 등의 동작
• Auto Scaling 동작 트리거 ⇒ 스케일 아웃, 스케일 인 등
• SNS 알림 ⇒ SNS 서비스를 람다 함수로 연결해 위반된 경보에 우리가 원하는 작업을 수행할 수 있음

 

EC2 인스턴스 복구

• 상태 점검 ( Status Check )
  • 인스턴스 상태 점검 = EC2 VM 점검을 위함
  • 시스템 상태 점검 ⇒ 하드웨어 점검을 위함
  • 위 두 점검으로 CloudWatch Alarms를 만들 수 있다. ⇒ 특정 EC2 인스턴스를 모니터링하다가 경보가 위반되었을 경우 인스턴스 복구를 실행해 EC2 인스턴스를 다른 호스트로 옮기는 등 작업을 수행할 수 있다. ⇒ 이 후 SNS 주제에 알림을 전달해 EC2 인스턴스가 복구된 사실을 인지하게 할 수도 있다.

 

Amazon EventBridge

• 스케줄 : 클라우드에서 CRON 작업을 예약할 수 있다. ( 스크립트를 예약할 수 있음 ) ⇒ 가령 한 시간마다 Lambda를 호출하여 1시간 마다 트리거되게 할 수 있다.
• 이벤트 패턴 : 스케줄이 아닌 이벤트 패턴에 반응하게 할 수도 있다. ⇒ ex ) 콘솔의 IAM 루트 사용자 로그인 이벤트에 반응할 수 있다. ⇒ 계정 보안 기능 활용 ⇒ IAM 루트 사용자 로그인 → SNS 주제 → 메일 전송
• 대상이 다양하다면 람다 함수를 호출하여 SQS, SNS 메시지 등을 보낼 수 있다.
• 기본 이벤트 버스
  • 이벤트를 기본 이벤트 버스로 전송하는 AWS의 서비스 ⇒ S3 이벤트, Lambda 이벤트 등을 전송하는 서비스
• 파트너 이벤트 버스
  • 파트너와 통합된 AWS 서비스를 의미 ⇒ 외부에서 일어나는 일에 반응할 수 있다는 것
• 사용자 지정 이벤트 버스
  • 사용자의 애플리케이션의 자체 이벤트를 사용자 지정 이벤트 버스로 전송하는 서비스
• 리소스 기반 정책을 사용하여 다른 계정의 이벤트 버스에 액세스할 수도 있다.
• 이벤트 아카이빙도 가능하다. ⇒ 전부 또는 필터링된 서브셋을 아카이빙할 수 있다 ⇒ 이벤트를 아카이빙할 때는 보존 기간을 무기한이나 일정 기간으로 설정할 수 있다.
• 아카이브된 이벤트를 재생할 수 있다 ⇒ 예를 들어 람다 함수 버그를 수정할 때 수정 후 이벤트를 다시 테스트하고 재생해야 할텐데 이때 아카이브된 이벤트를 재생하면 된다.

 

Amazon EventBridge - Schema Registry

• EventBridge는 여러 곳에서 이벤트를 수신하게 되므로 이벤트가 어떻게 생겼는지 파악을 해야한다.
• EventBridge는 버스의 이벤트를 분석하고, 스키마를 추론하는 기능이 있다.

 

EventBridge - Resource-based Policy ( 리소스 기반 정책 )

• 특정 이벤트 버스의 권한을 관리할 수 있다. ⇒ ex ) 특정 이벤트 버스가 다른 리전이나 다른 계정의 이벤트를 허용하거나 거부하도록 설정할 수 있다.
• 사용 사례
  • 여러 계정의 모음인 AWS Organiztions의 중앙에 이벤트 버스를 두고 모든 이벤트를 모으는 것

 

CloudWatch Insight

CloudWatch Container Insight

• 컨테이너로부터 지표와 로그를 수집, 집계, 요약하는 서비스
• 사용할 수 있는 컨테이너
  • ECS
  • EKS
  • EC2에서 실행하는 Kubernetes 컨테이너
  • ECS와 EKS의 Fargate에 배포된 컨테이너
• CloudWatch Container Insight를 EKS나 Kubernetes, EC2에서 실행되는 Kubernetes에서 사용할 경우 컨테이너화된 버전의 CloudWatch Agent를 사용해야 한다.

 

CloudWatch Lambda Insight

• Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션이다.

 

CloudWatch Contributor Insight

• 기고자 ( Contributor ) 데이터를 표시하는 시계열 데이터를 생성하고, 로그를 분석하는 서비스
• 네트워크 상위 대화자를 찾고, 시스템 성능에 영향을 미치는 대상을 파악할 수 있다.
• VPC 로그, DNS 로그 등 AWS가 생성한 모든 로그에서 작동한다.
• 예시
  • 불량 호스트를 식별해 낼 수 있다. ⇒ 네트워크 로그나 VPC로그를 확인하여 사용량이 가장 많은 네트워크 사용자를 찾을 수 있음
  • 오류를 가장 많이 생성하는 URL 찾기 ⇒ DNS 로그 확인

 

CloudWatch Application Insight

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

 

CloudWatch Insight & 운영 가시성 정리

• CloudWatch Container Insights
  • ECS, EKS, EC2의 쿠버네티스, Fargate로부터 오는 로그와 지표를 위한 것
• CloudWatch Lambda Insight
  • 람다에서 실행되는 서버리스 애플리케이션의 트러블 슈팅을 위한 세부 지표를 제공함
• CloudWatch Contributors Insights
  • CloudWatch Logs를 통해 상위 N개의 기고자를 찾는다.
• CloudWatch Application Insights
  • 자동화된 대시보드를 생성해 사용하는 애플리케이션과 관련된 AWS 서비스나 애플리케이션의 트러블 슈팅을 돕는다.

 

---

 

CloudTrail

• AWS 계정의 거버넌스, 감사 및 규정 준수를 도와주는 서비스
• 기본적으로 활성화 되어있다.
• AWS 계정 내의 모든 이벤트 및 API 호출 기록을 받아 볼 수 있다.
• CloudTrail의 로그를 CloudWatch Logs나 S3로 옮길 수 있다.
• 전체 또는 단일 리전에 적용되는 트레일을 생성해 모든 리전에 걸친 이벤트 로그를 한 곳으로 모을 수 있다 예를 들면 S3 버킷
• CloudTrail을 사용하면 누군가 AWS에서 무언가를 삭제했을 때 대처할 수 있다.
• 기록을 90일 이상 보관하려면 CloudWatch Logs 또는 S3 버킷으로 내보내면 된다.

 

CloudTrail Events

• 관리 이벤트 ( Management Events )
  • AWS 계정의 리소스에서 수행되는 작업을 나타낸다.
  • 예시
    • 누군가 보안 설정을 구성하면 IAM AttachRolePolicy 라는 API를 호출하게 되는데 이것이 CloudTrail에 표시된다.
    • 서브넷을 설정해도 표시되고, 로깅을 설정해도 기본으로 표시된다
  • CloudTrail은 기본적으로 관리 이벤트 ( Management Events )를 기록하게 구성 되어있다.
  • 관리 이벤트는 2종류로 구분
    • Read Events
      • 리소스를 수정하지 않는다.
    • Write Events
      • 리소스를 수정하는 이벤트
• Data Events ( 데이터 이벤트 )
  • 데이터 이벤트는 고볼륨 작업이므로 기본적으로 로깅되지 않는다.
  • GetObject, DeleteObject, PutObject 와 같은 작업은 S3 객체 수준 작업은 S3에서 빈번히 발생하는 이벤트 기본적으로 로깅되지 않고, 읽기 이벤트와 쓰기 이벤트로 분리할 수 있다.
  • AWS Lambda 함수 실행 작업
• CloudTrail Insight Events

 

CloudTrail Insights

• 비용을 지불하고 CloudTrail Insights 활성화하면 이벤트를 분석하여 계정 내 특이한 활동을 탐지해주는 기능
  • 부정확한 리소스 프로비저닝
  • 서비스 한도 도달
  • AWS IAM 작업 버스트
  • 주기적 유지 관리 작업 부재
• 정상적인 관리 활동을 분석하여 기준선을 생성한 후 무언가를 변경 또는 변경하려고 시도하는 모든 쓰기 유형의 이벤트를 지속적으로 분석하여 특이한 패턴을 탐지하게 된다.
  • 이상 상황, 즉 인사이트 이벤트는 CloudTrail Console에 표시된다.
  • 원한다면 S3 로 전송할 수 있다.
  • 이메일을 보내는 CloudTrail Insights에 자동화를 추가하면 EventBridge 이벤트가 생성된다.

 

CloudTrail Events Retention ( 이벤트 보존 기간 )

• 이벤트는 기본적으로 90일 간 저장되고 이후 삭제된다.
• 기본 기간 이상 이벤트를 저장하려는 경우 ⇒ S3로 전송하여 S3에 로그를 기록하고 Athena 를 사용해 분석

Amazon EventBridge - Intercept API Calls ⇒ CloudTrail 통합 중에 API 호출을 가로채는 EventBridge와의 통합 ( User → DynamoDB → CloudTrail →Amazon EventBridge → SNS )

• 사용자가 DynamoDB 의 테이블을 삭제하는 API를 호출 할 때 마다 SNS 알림을 받고싶다고 가정했을 때 CloudTrail 에 DynamoDB 삭제 API가 로그로 보내지고 CloudTrail은 EventBridge에 이벤트를 발생시키고 EventBridge가 SNS 호출

 

---

 

AWS Config

• AWS 내 리소스에 대한 감사와 규정 준수 여부를 기록할 수 있게 해주는 서비스
• 구성과 구성의 시간에 따른 변화를 기록할 수 있다. ⇒ 이를 통해 필요할 경우 인프라를 빠르게 롤백하고 문제점을 찾을 수 있다.
• Config로 해결할 수 있는 질문
  • 보안 그룹에 제한되지 않은 SSH 접근이 있나?
  • 버킷에 공용 액세스가 있나?
  • 시간이 지나며 변화한 ALB 구성이 있나?
• 규정을 준수하든 안하든 변화가 생길 때 마다 SNS 알림을 받아볼 수 있다.
• Config 는 리전별 서비스이다 ⇒ 모든 리전별로 구성을 해줘야 한다.
• 데이터를 중앙화하기 위해 리전과 계정 간 데이터를 통합할 수 있다.
• 모든 리소스의 구성을 S3에 저장해 나중에 분석할 수도 있다.

 

Config Rules

• AWS 관리형 Config 규칙 ⇒ 75가지 정도 규칙이 있음
• Custom Config rules ⇒ 람다를 이용해 스스로 규칙을 정의해야 할 것
  • ex ) 각 EBS 디스크가 gp2 유형인지 평가할 수 있다.
  • 개발 계정의 EC2 인스턴스가 t2.micro 유형인지 평가할 수도 있다.
• 몇몇 규칙들은 구성이 변화할 때마다 평가되거나 트리거 되곤 한다.
• Config Rule 은 규정 준수를 위한 것이다. ⇒ 즉, 어떤 동작을 미리 예방하지는 못한다. ⇒ 하지만 구성의 개요와 리소스의 규정 준수 여부는 Config Rule을 통해 알 수 있다.
• Pricing ( 비용 ) : Config는 결제해야 하며 상당히 비싸질 수 있다. ⇒ 각 리전 당 기록된 구성 항목별로 3센트를 지불해야 하고 리전당 Config 규칙 평가별로 0.1 센트씩 내야한다.

 

AWS Config Resource

• 리소스의 규정 준수 여부를 시간 별로 확인할 수 있다.
• 리소스 구성도 시간 별로 볼 수 있다. ⇒ 언제 누가 변경 했는지 등
• CloudTrail 과 연결해 리소스에 대한 API 호출을 볼 수 있다.

 

Config Rules - Remediations ( 수정 )

• Config 내에서 행동을 차단할 수는 없지만 SSM 자동화 문서를 이용해서 규정을 준수하지 않는 리소스를 수정할 수 있다.
• 람다 함수를 실행하는 문서를 작성해서 원하는 작업을 수행할 수도 있다.

 

Config Rules - Notifications ( 알림 )

• EventBridge를 사용해 리소스가 규정을 미준수할 때 마다 알림을 보낼 수 있다.