섹션 24: AWS 모니터링 및 감사: CloudWatch, CloudTrail 및 Config

CloudWatch 지표 개요

• AWS의 모든 서비스에 대한 지표 제공
• 지표는 모니터링할 변수
• 지표는 이름공간에 속하므로
  • 각기 다른 이름공간에 저장
  • 서비스당 이름공간은 하나
• 지표는 시간을 기반으로 타임스탬프가 필수
• 사용자 지정 지표를 만들 수 있음
• 예시)
  • EC2 인스턴스 메모리 사용량 추출
• 원하는 대상으로 지속적으로 스트리밍 가능
  • Amazon Kinesis Data Firehose
  • 타사 서비스도 가능
• 지표를 직접 전송 할 수도 있음

CloudWatch 로그 개요

• AWS에서 애플리케이션 로그를 저장 할 때 사용
• 로그 그룹을 정의 해야함
  • 그룹 안에 다수의 로그 스트림이 있음
    • 애플리케이션 안의 로그 인스턴스
    • 로그 파일
    • 클러스터의 일부로 갖고있는 특정한 컨테이너
• 로그 만료 정책으로 영원히 만료되지 않게 하거나
  • 1일부터 10년까지 어느 시점에 만료하게 가능
• 예시
  • 배치 형태로 S3에서 내보낼수 있음
    • 아니면 Kinesis Data Streams, Kinesis Data Firehose
      람다, OpenSearch에 스트리밍이 가능
• SDK를 사용해서 로그를 전송 할 수있음
  • 다른거는 CloudWatch Logs Agent, CloudWatch Unified Agent 사용
  • 지금은 CloudWatch Unified Agent가 로그를 CloudWatch에 전송
    • CloudWatch Logs Agent는 도태 되고있음
  • Elastic Beanstlak을 사용해서 애플리케이션 로그를 CloudWatc로 직접 보낼 수 있음
  • 람다는 함수 자체에서 로그 전송
  • VPC Flow Logs는 VPC 메타데이터 네트워크 트래픽의 특정한 로그 전송
  • API Gateway는 모든 요청을 보냄
  • CloudTrail은 직접 필터에 기반한 로그 전송
  • Route 53은 서비스에 대한 모든 DNS 쿼리 전송
• CloudWatch Logs의 로그를 쿼리 할려면?
  • CloudWatch Logs Insight를 사용해서 이용 가능
• 다른 계정의 전송 대상으로 전송 할 수 있음

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

• EC2 인스턴스에서 CloudWatch 에이전트를 사용해서 로그와 지표를 받아서
  CloudWatch에 표시를 한다.
• EC2 인스턴스에서 CloudWatch로는 기본적으로 어떤 로그도 옮겨지지 않는다.
• 그럴려면 EC2 인스턴스에 에이전트라는 작은 프로그램을 실행시켜 원하는 로그파일을 푸시 해야함
• 예시
  • CloudWatch Logs 에이전트가 EC2 인스턴스에서 작동
  • 그 후 CloudWatch Logs로 보냄
    (로그를 보낼 수 있게 해주는 IAM 역할이 필요)
  • 같은 에이전트를 설치하면 CloudWatch Logs로 로그를 보낼 수 있음
• 두 가지 에이전트가 있음
  • CloudWatch Logs 에이전트 (오래된 버전)
    • CLoudWatch Logs에만 로그를 보냄
  • 통합 CloudWatch 에이전트
    • 프로세스나 RAM 같은 추가적인 시스템 단계 지표 수집
    • 그리고 CloudWatch Logs에 로그를 보냄
    • 지표 + 로그를 사용하기에 통합 에이전트
    • SSM Parameter Store를 이용해서 에이전트 쉽게 구성이 가능
    • 세부 지표를 얻을 때 사용

CloudWatch 경보 개요

• 메트릭에서 나오는 알람을 트리거로 사용
• 샘플링, 퍼센티지, 최대, 최소 등등 다양한 옵션으로 복잡한 알람 정의 가능
• 3가지 상태가 있음
  • OK: 알람이 트리거되지 않음
  • INSUFFICIENT_DATA: 알람이 상태를 결정하기 위한 충분한 데이터가 없음
  • ALARM: 알람이 울릴 때 (조건에 맞아서 트리거 실행)
• 기간을 설정하면 얼마나 오랫동안 메트릭을 평가할지 나타냄
• 주요 타깃 3가지
  • 첫 번째
    • 정지, 종료, 재부팅 또는 복구 등 EC2 인스턴스 액션
  • 두 번째
    • 오토 스케일링 액션
  • 세 번째
    • SNS 서비스에 알람 전송
• 복합 알람
  • 다수의 메트릭을 사용 할 때 사용
  • 다수의 다른 알람들의 상태를 모니터링
    • 알람마다 각각 다른 메트릭에 의존 가능
  • 알람 노이즈를 줄이는데 유용함
  • 예시)
    • CPU가 높고 네트워크가 높으면 알람을 하지 말라고 할 수 있음
    • CPU가 높고 네트워크가 낮을때만 체크 하는게 가능
• CloudWatch Logs 메트릭 필터 기초로 알람 생성이 가능
• SNS에 전송이 가능

EventBridge 개요 (구. CloudWatch Events)

• 예전 이름은 CloudWatch Events 였음
• 클라우드에서 CRON 작업을 예약 할 수 있음
• 이벤트 패턴에도 반응 할 수 있음
• 예시
  • 한 시간마다 Lambda 함수 트리거해서 스크립트 실행
  • IAM 루트 사용자 로그인 이벤트에 반응
• 필터를 설정 할 수 있음
  
  • 예시
    • S3에 있는 특정 버킷 이벤트만 필터링하면
    • EventBridge는 이벤트의 세부사항 JSON을 생성
      • 어떤 인스턴스가 ID를 실행하는지
      • 시간
      • IP
      • 등
    • 그 후에 다양한 대상으로 전송 할 수 있음
• 위에는 기본 이벤트 버스를 전송하는 개념임
• 파트너 이벤트 버스
  • 파트너와 통합된 AWS 서비스에도 사용이 가능
• 사용자 지정 이벤트 버스
  • 애플리케이션 자체 이벤트를 사용자 지정 이벤트 버스로 전송
• 리소스 기반 정책
  • 다른 계정의 이벤트 버스에 액세스 가능
• 이벤트 아카이빙
  • 전부 또는 필터링된 서브셋을 아카이빙 할 수 있음
  • 예시
    • Lambda 함수의 버그를 수정 할 때
    • 수정 후 이벤트를 다시 테스트하고 재생 할텐데
    • 아카이브된 이벤트를 재생 할 수 있음
• 스키마 레지스트리
  • 버스의 이벤트를 분석하고 스키마를 추론
  • 애플리케이션의 코드 생성 가능
  • 이벤트 버스 데이터가 어떻게 정형화 되어있는지 알 수 있음
• 리소스 기반 정책 상세
  • 특정 이벤트 버스의 권한 관리
  • 다른 계정의 이벤트 허용, 거부 설정
  • 예시
    • 여러 계정의 모음인 AWS organizations의 중앙에 이벤트 버스를 두고
      모든 이벤트를 모음
    • PutEvents 작업을 통해 전송

CloudWatch Insights and Operational Visibility

• CloudWatch Insights
  • 컨테이로부터 지표와 로그를 수집, 집계 요약하는 서비스
  • ECS, EKS, EC2의 Kubernetes 플랫폼에 직접 실행하는 컨테이너에서 사용 가능
  • 사용하면 컨테이너로부터 지표와 로그를 손쉽게 추출해서
    CloudWatch에 세분화된 대시보드를 생성
  • EKS, Kubernetes, EC2에서 실행되는 Kubernetes는
    컨테이너화된 버전의 CloudWatch 에이전트를 사용해야함
• Lambda Insights
  • Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션
  • CPU 시간, 메모리 디스크, 네트워크 등 지표를 수집, 집계, 요약한다.
  • Lambda 함수의 성능을 모니터링 할 수 있음
• Contributor Insights
  • 기고자 데이터를 표시하는 시계열 데이터 생성 후
    로그를 분석하는 서비스
  • VPC 로그, DNS 로그 등 AWS가 생성한 모든 로그에서 작동
  • 예시
    • 불량 호스트 식별
    • 사용량이 가장 많은 네트워크 사용자 찾기
      • VPC Flow Logs -> CloudWatch Logs -> CloudWatch Contributor Insights
    • DNS 로그에서 오류를 많이 생성하는 URL ckwrl
• CloudWatch Apllication Insights
  • 모니터링하는 애플리케이션의 잠재적인 문제와
    진행 중인 문제를 준비할 수 있게 자동화된 대시보드 제공
  • Java, IIS 특정 DB를 선택해 선택한 기술로만 애플리케이션 실행 가능
  • EBS, RDC, ELB ASG, Lambda, SQS, DynamoDB, S3, AWS리소스 연결 가능
  • ECS 클러스터, EKS 클러스터, SNS 토픽, API Gateway도 가능
  • 문제가 있으면 자동으로 대시보드 생성해서
    서비스의 잠재적인 문제를 보여줌
    • 생성시 내부에서 SegaMaker 머신 러닝 서비스가 사용됨
    • 애플리케이션 상태 가시성을 더 높일 수 있음
    • 트러블 슈팅, 애플리케이션 보수하는 시간 축소
  • 발견된 문제와 알림은
    Amazon EventBridge와 SSM OpsCenter로 전달

CloudTrail 개요 강의

• AWS 계정의 거버넌스, 컴플라이언스, 감사를 실현하는 방법
• 기본값으로 활성화 되어있음
• AWS 계정안에서 일어난 모든 이벤트와 API 호출 이력을
  • 콘솔, SDK, CLI 또는 기타 AWS 서비스를 통해 얻을 수 있다.
• CloudWatch Logs, S3에 넣을 수도 있음
• 트레일을 생성해서 모든 리전이나, 하나의 리전에 적용 가능
• 예시)
  • 누군가 EC2 인스턴스를 종료했음
  • CloudTrail 안에 API 호출이 남아있음
  • 확인이 가능하다.
• 세 가지 이벤트
  • 관리 이벤트
    • AWS 계정안에서 리소스에 대해 수행된 작업을 나타냄
    • 두가지 관리 이벤트
      • 리소스를 변경하지 않는 읽기 이벤트
        • 예시) 읽기만 하는 이벤트
      • 쓰기 이벤트
        • 예) DynamoDB 테이블 삭제, 삭제 시도
  • 데이터 이벤트
    • 고용량 작업
    • S3 객체 수준 활동
      • GetObject, DeleteObject, PutObject 등이 있음
      • 읽기 이벤트(GetObject)와 쓰기 이벤트(DeleteObject, PutObject)를 분리 할 수 있음
    • AWS 람다 함수 실행 활동
      • Invoke API를 사용하면 람다 함수가 몇번 호출됐는지 알 수 있음
    • CloudTrail Insights 이벤트
      • 모든 유형의 서비스에 걸쳐 아주 많은 관리 이벤트가 일어날때
        아주 많은 API 호출이 아주 빠르게 이루어지면
        어떤게 문제이고 정상인지 알기가 힘들때 사용
      • 이벤트를 분석하고 비정상적인 활동에 대한 탐지
      • 정상적인 관리 활동을 분석해서 기준선을 만들어서
        • 올바른 형태의 이벤트인지 모든 걸 계속적으로 분석함
      • 관리 이벤트를 계속 분석 하는 것
      • 흐름
        • 관리 이벤트 -> Cloudtrail Insights -> Insights Events -> CloudTrail Console, S3, EventBridge
• CloudTrail 이벤트 보관
  
  • 기본 90일 보관, 지나면 삭제
  • 장기관 보관은
    • S3에 전송하여 Athena를 사용해서 분석 가능

CloudTrail - EventBridge 통합

• 예시
  • DynamoDB에서 테이블 삭제 시 SNS 알람 받기
  • User -> (DeleteTable API Call) -> DynamoDB -> (Log API call) ->
    CloudTrail -> (event) -> EventBridge -> (alert) -> SNS
• CloudTrail에 모든 로그가 있으니까
• EventBridge를 사용해서 SNS 토픽으로 가는 메시지를 트리거하거나 사용이 가능 한 것

AWS Config 개요

• AWS 내 리소스에 대한 감사와 규정 준수 여부를 기록하는 서비스
• 설정된 규칙에 기반해서
  • 구성과 구성의 시간에 따른 변화 기록
    이를 통해 필요할 경우 인프라 빠르게 롤백 및 문제점 찾기
• Config로 해결할 수 있는 예시
  • 보안 그룹에 제한되지 않은 SSH 접근이 있는지?
  • 버킷에 공용 액세스가 있는지?
  • 시간이 지나며 변화환 ALB 구성이 있는지?
  • 규칙이 규정을 준수하든 아니든 변화가 생길 때마다 SNS 알람 받기 가능
• 리전별 서비스다.
• 모든 리소스 구성을 S3에 저장 해 추후에 분석 가능
• IAM 같은 보안 메커니즘을 대신 할 수 없음
• Config 내에서는 행동 차단이 안됨
  • SSM 자동화 문서를 이용해서 규정이 준수하지 않는 리소스 수정 가능
• EventBridge를 사용해 리소스가 규정을 미준수 했을 때 마다 알림 보낼 수 있음

CloudTrail vs CloudWatch vs Config

• CloudWatch
  • 지표, CPU 네트워크 등의 성능 모니터링과 대시보드를 만드는데 사용
  • 이벤트, 알림 받기 가능
  • 로그 집계 및 분석 도구도 사용 가능
• CloudTrail
  • 계정 내에서 만든 API에 대한 모든 호출을 기록함
  • 특정 리소스에 대한 추적도 정의 할 수 있음
  • 글로벌 서비스
• Config
  • 구성 변경을 기록
  • 규정 준수 규칙에 따라 리소스를 평가