CloudWatch Metrics
CloudWatch는 AWS의 모든 서비스에 대한 메트릭을 제공한다. 메트릭은 모니터링할 변수다.
계정에서 일어나는 모든 일을 모니터링할 수 있다.
EC2 인스턴스의 메트릭은 CPUUtilization, NetworkIn 등이 있고 Amazon S3의 지표로는 버킷 크기 등이 있다.
메트릭은 namespaces에 속하므로 각기 다른 namespaces에 저장되며 서비스당 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
CloudWatch Logs는 AWS에서 애플리케이션 로그를 저장할 수 있는 완벽한 곳이다.
로그들을 로그 그룹으로 그룹화하는데, 로그 그룹의 이름으로는 보통 애플리케이션을 나타낸다.
각 로그 그룹 내에는 다수의 로그 스트림이 있다.
로그 스트림은 애플리케이션 내 인스턴스나 다양한 로그 파일명 또는 컨테이너 등을 나타낸다.
로그 만료일도 정의할 수 있다. (로그가 만료되지 않게 하거나 일정 기간 후 만료되게 할 수 있다.)
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에서 이벤트를 트리거 해서 원하는 리소스에 넘길 수 있다.
