AWS 모니터링 및 감시

CloudWatch Metrics

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

Streams

• CloudWatch 지표는 CloudWatch 외부로 스트리밍할 수 있다.
• CloudWatch 지표를 원하는 대상으로 지속적으로 스트리밍하면 거의 실시간으로 전송되고 지연 시간도 짧아진다.
• Amazon Kinesis Data Firehose가 대상이 될 수 있고 여기서 원하는 곳으로 전송할 수 있다.
• Datadog, Dynatrace New Relic, Splunk, Sumo Logic 같은 타사 서비스 제공자로 CloudWatch 지표를 직접 전송할 수도 있다.
• 모든 이름공간에 속한 모든 지표를 스트리밍하거나 몇몇 이름공간의 지표만 필터링할 수 있다.
• 필터링한 지표의 서브셋만 Kinesis Data Firehose로 보낼 수 있다.

CloudWatch Logs

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

CloudWatch Logs - Sources

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

CloudWatch Logs Metric Filter & Insights

• CloudWatch Logs에서 필터 표현식을 쓸 수 있다.
• 로그 내 특정 IP를 찾을 수 있고, 특정 IP가 찍힌 로그를 찾거나 또는 'ERROR'라는 문구를 가진 모든 로그를 찾을 수 있다.
• 이 메트릭 필터를 통해 출현 빈도를 계산해 메트릭을 만들 수 있다. 그렇게 만들어진 메트릭은 CloudWatch 경보로 연동할 수 있다.
• CloudWatch Logs Insights 기능을 통해 로그를 쿼리하고 이 쿼리를 대시보드에 바로 추가할 수 있다.

그 밖의 기능

• CloudWatch Logs에서 로그를 스트림하고 싶다면 구독 필터를 사용해야 한다.
• 구독 필터란 CloudWatch Logs 상단에 적용하여 이를 목적지로 보내는 필터를 말한다.
• 또한 CloudWatch Logs로 여러 계정과 리전간 로그를 집계할 수 있다.

CloudWatch 에이전트 & CloudWatch Logs 에이전트

CloudWatch Logs for Ec2

• EC2 인스턴스에서 CloudWatch로는 기본적으로 어떤 로그도 옮겨지지 않는다.
• EC2 인스턴스에 에이전트라는 작은 프로그램을 실행시켜 원하는 로그 파일을 푸시해야 한다.
• CloudWatch Logs 에이전트가 EC2 인스턴스에서 작동해 CloudWatch Logs로 로그를 보낸다.
• 그러려면 EC2 인스턴스에 로그를 보낼 수 있게 해주는 IAM 역할이 있어야 한다.
• 또한 이 에이전트는 온프레미스 환경에서도 셋업될 수 있다.

CloudWatch Logs Agent & Unified Agent

• CloudWatch에는 두 가지 에이전트가 있다.
• 오래된 CloudWatch Logs 에이전트와 최근에 나온 통합 CloudWatch 에이전트가 있다.
• 둘 다 EC2 인스턴스나 온프레미스 서버 같은 가상 서버를 위한 것
• CloudWatch Logs 에이전트는 CloudWatch Logs로 로그만 보낸다.
• 반면 통합 에이전트는 프로세스나 RAM 같은 추가적인 시스템 단계 지표를 수집한다. 그리고 CloudWatch Logs에 로그를 보낸다.
• 이전 버전에는 없는 기능인 SSM Parameter Store를 이용해서 에이전트를 쉽게 구성할 수 있다.
• 모든 통합 에이전트를 대상으로 중앙 집중식 환경 구성을 할 수 있다.

Unified Agent Metrics

• 통합 에이전트를 EC2 인스턴스나 Linux 서버에 설치하면 지표를 수집할 수 있다.
• 먼저 훨씬 세분화된 수준으로 CPU 지표, 디스크 지표, 디스트 IO 지표, RAM 지표, 넷 상태 지표, 프로세스 지표, 스왑 공간 지표를 가져올 수 있다.
• 여기서의 핵심은 통합 CloudWatch 에이전트가 더 세부적이고 많은 지표를 수집한다는 것이다. (기본 EC2 인스턴스 모니터링보다)
• 세부 지표를 얻고 싶다면 통합 CloudWatch 에이전트를 이용하자.

CloudWatch Alarms

• 경보는 지표에서 알림을 트리거할 때 사용
• sampling, %, max, min 등의 다양한 옵션을 추가해 복잡한 경보를 정의할 수도 있다.
• 경보에는 세 상태가 있다.
  • OK: 트리거되지 않았음을 의미
  • INSUFFICIENT_DATA: 상태를 결정할 데이터가 부족함을 뜻함
  • ALARM: 임계값이 위반되어 알림이 보내지는 상태
• 기간은 경보가 지표를 평가하는 기간을 의미한다. 짧게 설정할 수도 길게 설정할 수도 있다.
• 고해상도 사용자 지정 지표에도 적용될 수 있는데 10초, 30초 또는 60초의 배수로 설정될 수 있다.
• 경보의 주 대상은 세 개
  • 첫 번째는 EC2 인스턴스의 동작들. 인스턴스를 멈추거나, 삭제하거나 재시작하거나 복구하는 등의 동작을 말한다.
  • 둘째는 Auto Scaling 동작의 트리거. 스케일 아웃과 스케일 인 등이 있다.
  • 마지막은 SNS 서비스에 알림을 보내는 것. 예를 들어 SNS 서비스를 람다 함수로 연결해 람다 함수를 통해 위반된 경보에 우리가 원하는 작업을 수행할 수 있는 것.
• 경보 알림을 시험해 보고 싶다면 set-alarm-state라는 CLI 호출을 사용하면 된다.

Amazon EventBridge

• 과거 이름은 CloudWatch Events
• 클라우드에서 CRON 작업을 예약할 수 있고 스크립트를 예약할 수 있다.
• 이벤트 패턴에 반응할 수도 있다.  예를 들어 콘솔의 IAM 루트 사용자 로그인 이벤트에 반응할 수 있다.
• 또한 대상(destination)이 다양하다면 Lambda 함수를 트리거해서 SQS, SNS 메시지 등을 보낼 수 있다.
• Amazon EventBridge로 전송되는 이벤트에 필터를 설정할 수 있다.
• 예를 들어 Amazon S3에 있는 특정 버킷의 이벤트만 필터링하도록 하면 Amazon EventBridge는 이벤트의 세부 사항을 나타내는 JSON 문서를 생성할 겁니다
• 어떤 인스턴스가 이 ID로 실행되는지 등을 나타내고 시간, IP 등의 정보가 담긴다.
• JSON 문서 생성이 끝나면 이벤트들을 다양한 대상으로 전송할 수 있고 유용한 통합 기능을 사용할 수 있다.
• 지금 살펴본 Amazon EventBridge는 기본 이벤트 버스다.
• 파트너 이벤트 버스라는 서비스가 있다.
• 파트너와 통합된 AWS 서비스를 말하는데 대부분의 파트너는 소프트웨어 서비스 제공자다.
• 이 파트너들은 파트너 이벤트 버스로 이벤트를 전송한다. 
• 특정 파트너 이벤트 버스로 이벤트를 전송할 수 있고 우리 계정을 통해 AWS 외부에서 일어나는 변화에 반응할 수 있게 된다.
• 사용자 지정 이벤트 버스도 있다. 사용자 커스텀
• 애플리케이션의 자체 이벤트를 사용자 지정 이벤트 버스로 전송한다.
• Amazon EventBridge 규칙 덕분에 다른 이벤트 버스처럼 여러 대상으로 이벤트를 보낼 수 있다.
• 리소스 기반 정책을 사용해 다른 계정의 이벤트 버스에 액세스할 수도 있고 이벤트도 아카이빙 된다.

Schema Registry

• EventBridge는 여러 곳에서 이벤트를 받는다.
• 그러므로 이벤트가 어떻게 생겼는지 파악해야 한다.
• 이벤트는 JSON 형식
• Amazon EventBridge는 버스의 이벤트를 분석하고 스키마를 추론하는 능력이 있다.
• 스키마 레지스트리의 스키마를 사용하면 애플리케이션의 코드를 생성할 수 있고 이벤트 버스의 데이터가 어떻게 정형화되는지 미리 알 수 있다.
• 스키마를 버저닝할 수도 있어 애플리케이션의 스키마를 반복할 수 있다.

리소스 기반 정책

• 특정 이벤트 버스의 권한을 관리할 수 있다.
• 예를 들면 특정 이벤트 버스가 다른 리전이나 다른 계정의 이벤트를 허용하거나 거부하도록 설정하는 것이다.

CloudWatch Insights

CloudWatch Container Insights

• 컨테이너로부터 지표와 로그를 수집, 집계, 요약하는 서비스
• Amazon ECS나 Amazon EKS EC2의 Kubernetes 플랫폼에 직접 실행하는 컨테이너에서 사용할 수 있다.
• ECS와 EKS의 Fargate에 배포된 컨테이너에서도 사용할 수 있다. `
• CloudWatch Container Insights를 사용하면 컨테이너로부터 지표와 로그를 손쉽게 추출해서 CloudWatch에 세분화된 대시보드를 만들 수 있다.
• CloudWatch Container Insights를 Amazon EKS나 Kubernetes EC2에서 실행되는 Kubernetes에서 사용할 경우 컨테이너화된 버전의 CloudWatch 에이전트를 사용해야 컨테이너를 찾을 수 있다.

Lambda Insights

• AWS Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션
• CPU 시간, 메모리 디스크, 네트워크 콜드 스타트나 Lambda 작업자 종료와 같은 정보를 포함한 시스템 수준의 메트릭을 수집, 집계, 요약한다.
• Lambda 함수를 위해 Lambda 계층으로 제된다.
• Lambda 함수 옆에서 실행되며 Lambda Insights라는 대시보드를 생성해 Lambda 함수의 성능을 모니터링한다.
• AWS Lambda에서 실행되는 서버리스 애플리케이션의 세부 모니터링이 필요할 때 사용

Contributor Insights

• 기고자(Contributor) 데이터를 표시하는 시계열 데이터를 생성하고 로그를 분석하는 서비스
• 예를 들어 상위 N개의 기고자나 총 고유 기고자 수 및 사용량을 볼 수 있다.
• VPC 로그, DNS 로그 등 AWS가 생성한 모든 로그에서 작동한다.
• 네트워크 로그나 VPC 로그를 확인해서 사용량이 가장 많은 네트워크 사용자를 찾을 수 있다.
• DNS 로그에서는 오류를 가장 많이 생성하는 URL을 찾을 수 있다.
• 모든 네트워크 요청에 대해 VPC 내에서 생성되는 로그인 VPC 플로우 로그가 CloudWatch Logs로 전달되고 CloudWatch Contributor Insights가 분석한다.
• 그러면 VPC에 트래픽을 생성하는 상위 10개의 IP 주소를 찾고 좋은 사용자인지 나쁜 사용자인지 판단할 수 있다.

CloudWatch Application Insights

• 모니터링하는 애플리케이션의 잠재적인 문제와 진행 중인 문제를 분리할 수 있도록 자동화된 대시보드를 제공한다.
• Java나 .NET Microsoft IIS 웹 서버나 특정 데이터베이스를 선택해 선택한 기술로만 애플리케이션을 실행할 수 있다.
• EBS, RDC, ELB ASG, Lambda, SQS DynamoDB, S3 버킷과 같은 AWS 리소스에 연결된다.
• 애플리케이션에 문제가 있는 경우 CloudWatch Application Insights는 자동으로 대시보드를 생성하여 서비스의 잠재적인 문제를 보여 준다.
• 자동화된 대시보드를 생성할 때 백그라운드에서는 내부에서 SageMaker 머신 러닝 서비스가 사용된다.
• 발견된 문제와 알림은 모두 Amazon EventBridge와 SSM OpsCenter로 전달된다.
• 애플리케이션에서 문제가 탐지되면 우리에게 알림이 온다.

CloudTrail

• CloudTrail는 AWS 계정의 거버넌스, 감사 및 규정 준수를 돕는다.
• CloudTrail은 기본적으로 활성화돼 있고 콘솔, SDK, CLI뿐만 아니라 기타 AWS 서비스에서 발생한 AWS 계정 내의 모든 이벤트 및 API 호출 기록을 받아 볼 수 있다. 글로벌 서비스
• 즉 모든 로그가 CloudTrail에 표시된다.
• CloudTrail의 로그를 CloudWatch Logs나 Amazon S3로 옮길 수 있다.
• 전체 또는 단일 리전에 적용되는 트레일을 생성해 모든 리전에 걸친 이벤트 기록을 한 곳으로 모을 수 있다. (ex S3)
• 모든 이벤트를 90일 이상 보관하려면 CloudWatch Logs 또는 S3 버킷으로 보내야 한다.

CloudTrail Events

• CloudTrail에는 세 종류의 이벤트가 있습니다
• 첫 번째는 관리 이벤트로 이는 AWS 계정의 리소스에서 수행되는 작업을 나타낸다.
  • 예를 들어 누군가가 보안 설정을 구성하면 IAM AttachRolePolicy라는 API를 사용하게 되는데 이것이 CloudTrail에 표시된다.
  • 리소스나 AWS 계정을 수정하는 모든 작업이 CloudTrail에 표시된다.
  • 트레일(추적)은 기본적으로 관리 이벤트를 기록하도록 구성되어 있다.
  • 관리 이벤트는 두 종류로 구분할 수 있다. 리소스를 수정하지 않는 읽기 이벤트와 리소스를 수정하는 쓰기 이벤트
• 두 번 째 이벤트는 데이터 이벤트
  • 데이터 이벤트는 고볼륨 작업이므로 기본적으로 로깅되지 않는다.
  • 데이터 이벤트란 무엇일까요?
  • GetObject, DeleteObject PutObject와 같은 Amazon S3 객체 수준 작업은 S3 버킷에서 빈번히 발생하는 이벤트이므로 기본적으로 로깅되지 않고 읽기 이벤트와 쓰기 이벤트로 분리할 수 있다.
  • Lambda 함수 실행 작업이 있다.
  • 누군가 Invoke API를 사용할 때마다 Lambda 함수가 몇 번 활용되었는지 알 수 있다.
  • 이 역시 Lambda 함수가 많이 실행되면 볼륨이 커질 수 있다.
• 세 번째 이벤트 종류는 CloudTrail Insights 이벤트
  
  • 모든 유형의 서비스에 걸쳐 너무 많은 관리 이벤트가 있고 계정에서 다수의 API가 매우 빠르게 발생해서 무엇이 이상하거나 특이한지 파악하기 어려울 때 CloudWatch Insights를 활용
  • 비용을 지불하고 CloudTrail Insights를 활성화하면 이벤트를 분석해서 계정 내의 특이한 활동을 탐지
  • 특이한 활동에는 부정확한 리소스 프로비저닝 서비스 한도 도달 AWS IAM 작업 버스트 주기적 유지 관리 작업 부재가 있다.
  • CloudTrail이 정상적인 관리 활동을 분석해서 기준선을 생성한 다음 무언가를 변경하거나 변경하려고 시도하는 모든 쓰기 유형의 이벤트를 지속적으로 분석해서 특이한 패턴을 탐지
  • 이상 상황, 즉 인사이트 이벤트는 CloudTrail 콘솔에 표시된다.
  • 원한다면 Amazon S3로 전송할 수도 있고 이메일을 보내는 CloudTrail Insights에 자동화를 추가하면 EventBridge 이벤트가 생성된다.

CloudTrail의 이벤트 보존 기간

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

참고

• CloudTrail 통합 중에 API 호출을 가로채는 Amazon EventBridge와의 통합은 꼭 알아야 한다.
• 사용자가 테이블 삭제 API 호출을 사용해서 DynamoDB의 테이블을 삭제할 때마다 SNS 알림을 받고 싶다고 가정하면, AWS에서 API 호출을 실행할 때마다 API 호출 자체가 CloudTrail에 로깅된다.
• 그리고 모든 API 호출은 Amazon EventBridge에 이벤트로 기록된다.
• 여기서 특정 테이블 삭제 API 호출을 찾아 규칙을 생성
• 규칙에는 대상이 필요
• Amazon SNS를 대상으로 설정하면 경고를 생성할 수 있다. 
• 어떤 API 호출에도 적용할 수 있어요

AWS Config

• Config는 AWS 내 리소스에 대한 감사와 규정 준수 여부를 기록할 수 있게 해주는 서비스
• 설정된 규칙에 기반해 구성과 구성의 시간에 따른 변화를 기록할 수 있으며 이를 통해 필요할 경우 인프라를 빠르게 롤백하고 문제점을 찾아낼 수 있다.
• Config로 해결할 수 있는 질문은 다음과 같다
  • '보안 그룹에 제한되지 않은 SSH 접근이 있나?'
  • '버킷에 공용 액세스가 있나?'
  • '시간이 지나며 변화한 ALB 구성이 있나?'
  • 이럴 경우 규칙이 규정을 준수하든 아니든 변화가 생길 때마다 SNS 알림을 받을 수 있다.
• Config는 리전별 서비스이기 때문에 모든 리전별로 구성해야 하며 데이터를 중앙화하기 위해 리전과 계정 간 데이터를 통합할 수 있다
• 모든 리소스의 구성을 S3에 저장해 나중에 분석할 수도 있다.
• 규정 미준수를 예방하지는 못하지만 리소스가 규정을 미준수할 때마다 수정 작업을 트리거 할 수 있다.
• EventBridge를 사용해 리소스가 규정을 미준수했을 때마다 알림을 보낼 수 있다.
• 예를 들어 보안 그룹을 모니터링하다가 규정 미준수 상태가 됐다면 EventBridge에서 이벤트를 트리거 해서 원하는 리소스에 넘길 수 있다.