AWS 모니터링

CloudWatch metrics

metric은 모니터링 할 변수이다.

EC2인스턴스의 지표로는 CPUUtilization, Networking등이 있고

S3의 지표로는 버킷 크기 등이 있다.

지표는 타임스탬프를 가져야 한다. 

지표당 최대 측정기준은 10개이다.

 

지표가 많아지면 cloudwatch 대시보드에 추가해 모든 지표를 한 번에 볼 수 있다.

사용자 지정 지표도 만들 수 있다.  AWS의 서비스에서 제공되는 지표만 보는 대신 자체 지표를 만드는 것이다. ( 예를들어 인스턴스로부터 메모리 사용량 추출 ) 

 

cloud watch지표는 외부로 스트리밍 할 수 있다.

Kinesis data firehose가 대상이 될 수 있다. 또 여기서 원하는 곳으로 전송할 수 있다. 

타사 서비스에도 보낼 수도 있다. 

 

cloudwatch에서 거의 실시간으로 kinesis data firehose로 보낸다. 여기서 여러 방향으로 보낼 수 있는데..

->s3로 지표를 보낸 후 athena를 사용해 지표를 분석할 수 있다.

->Redshift를 사용하여 데이터웨어하우스를 만들 수도 있다/. 

->Opensearch를 사용해 대시보드를 생성하고 지표 분석을 할 수 있다.

 

---------------------

한 쌍의 EC2 인스턴스가 있으며, 이들의 표준 CloudWatch 지표가 매 1분 마다 수거되도록 하려 합니다. 어떻게 해야 할까요? -> 상세모니터링 활성화

이는 유료 기능으로, 기본적으로 비활성화되어 있습니다. 활성화된 경우, EC2 인스턴스 지표는 1분마다 사용이 가능합니다.

CloudWatch Logs

aws에 로그를 저장하는 최고의 장소는 cloud watch logs이다.

로그를 그룹화해서 나타낼 수 있음

로그 그룹 : 보통 애플리케이션을 타나냄

각 로그 그룹내에는 로그 스트림이 있다.

로그스트림 : 애플리케이션 내 인스턴스나 다양한 로그 파일명 또는 컨테이너, 로그 만료일 정의 가능

영원히 만료안되거나 일정 기간 후 만료되게할 수 있다.

이 로그들을 

kinesis data stream

kinesis data firehose 

s3, 람다, elasticsearch 등에도 내보낼 수 있다. 

 

CloudWatch에 기본적으로 어떤 로그도 옮겨지지 않는다.

그러기 위해서는 ec2 인스턴스에 에이전트라는 작은 프로그램을실행시켜 원하는 로그 파일을\

푸시해야한다. 그러기 위해선 ec2인스턴스에 cloudwatch에 접속할 수 있는 iam 역할이 있어야 한다.

이 cloud watch logs Agent는 꼭 ec2인스턴스가 아니어도된다. 온프레미스 환경에서도 셋업 될 수 있다.

 

두 가지 에이전트가 있다.

오래된 에이전트와, 최근에 나온 통합 에이전트이다.

둘다 ec2나 온프레미스 가상환경을 위한 용이다.

 

오래된 버전은 단순히 cloud watch logs만 보내는데

통합버전은 프로세스나 ram같은 추가적인 시스템 단계 지표를 수집한 뒤에 같이 로그에 보낸다.

또 ssm파라미터 스토어를 이용해서 에이전트를 쉽게 구성할 수 있다.

cpu, dist metrics, ram, netstat, processes  , swap space등의 지표를 수집할 수 있다.

더 세부적이고 많은 지표를 수집한다.

 

 

ClodWatch Alarms

지표에서 알람을 트리거할 때 사용된다.

특정 지표가 임계값을 넘었을 때 특정기능이 작동되로록 할 수 있다.

SNS, 등 다양한 서비스와도 연계시킬 수있다. 

 

데이터베이스 로그를 CloudWatch로 푸시하도록 구성 되어 있는 RDS DB 인스턴스가 있습니다. 로그에서 오류가 발견될 경우에는 CloudWatch 경보를 생성하게 만들려 합니다. 어떻게 해야 할까요?

-> 키워드 error에 대한 로그를 필터링하는 cloud watch 로그 지표 필터를 생성한 후 지표 필터를 기반으로 cloud watch 경보를 생성

EventBridge

이 서비스의 예전이름은 cloud watch events이다.

클라우드에서 CRON작업을 예약할 수 있다.

스크립트를 예약할 수 있다. 한시간 마다 람다함수를 실행시키기 

또 어떤 서비스에 반응하도록 할 수 있다.

IAM root user가 로그인해면 SNS으로 메시지를 날린다던지할 수 있다.

 

다른 서비스의 에게 이벤트를 보낼 수도 있다.

이벤트를 아카이브할 수 있고 아카이브 된 이벤트를 사용할 수도 있다.

 

다른계정이나 다른 레전의 이벤트를 거부하도록 할 수 있다.

 

Container insights

컨테이너로부터 지표과 로그를 수집 집계 요약하는 서비스이다.

ECS나, EKS,  쿠버네티스 에 있는 EC2 컨테이너에서 사용할 수 있다.

 

cloud watch container insight를 사용하면 컨테이너로부터 지표와 로그를 손 쉽게 추출해서

cloudwatch에 세분화된 대시보드를 만들 수 있다.

 

container insight를 eks나 ec2에서 실행되는 쿠버네티스에서 사용하는 경우

컨테이너화 된 버전의 cloudwatch에이전트를 사용해야  컨테이너를 찾을 수 있다?

 

Lambda insights

lambda함수 옆에서 실행되며 lambd insights라는 대시보드를 생성해 lambda함수의 성능을 모니터링 한다는 것만 알면 됩니다.

서버리스 애플리ㅋ이션의 세부 모니터링이 필요할 때 사용 

 

Contributor insights

Vpn, Dns,aws가 생성한 모든 로그에서 작동한다.

네트워크의 상위 대화자?를 찾고 시스템 성능에 영향을 미치는 대상을 파악할 수 있다.

이걸 사용하여 불량 호스트를 식별해 낼 수 있다. 네트워크 로그나 VPC로그를 확인해서

사용량이 가장 많은 네트워크 사용자를 찾을 수 있다. DNS로그에서는 오류를 가장 많이 생성하는 URL을 찾을 수 있다.

사용량이 많은 네트워크 사용자를 식별하는 방법을 알아보자

모든 네트워크 요청에 대해 VPC 내에서 생성되는 로그인  VPC플로우 로그가 cloudwatch logs로 전달되고

cloudwatch contributor insights가 분석합니다. 이를 통해 VPC에 트래픽을 생성하는 상위 10개의 IP주소를 찾고

좋은 사용자인지 나쁜 사용자인지 확인 가능 

시험에서 상위 10개의 기고자(contributor) 또는 비슷한 걸 본다면  contributor insgihts를 생각하자

 

Application insights

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

발견된 문제와 알림은 모두 eventbridge나 ssm opscenter로 전송된다.

 

 

요약

container insight는 ECS, EKS, 쿠버네티스, fargate로 부터 오는 로그와 지표를 위한 것이고

쿠버네티스를 사용할 경우 실행할 에이전트가 필요하다 

 

lambda insights는 aws lambda에서 실행되는 서버리스 애플리케이션의 트러블 슈팅을 위한 세부 지표를 제공한다.

 

contributors insights는 cloudwatch logs를 통해 상위 n개의 기고자(contributor)를 찾는다. 

 

application insights는 자동화된 대시보드를 생성해 사용하는 애플리케이션과 관련된 AWS 서비스나 애플리케이션의 트러블 슈팅을 돕는다.

 

CloudTrail

cloud trail은 aws계정의 거버넌스, 감사 및 규정 준수를 돕는다. 

기본적으로 활성화 되어있고 , 콘솔, sdk, cli뿐만 아니라 기타 aws 서비스에서 발생한 aws 계정 내의 모든 이벤트 및 api 호출 기록을 받아볼 수 있다. 모든 로그가 cloud trail에 표시된다. 

 

또한 여기 저장되 로그를 cloudwatch logs나 s3로 옮길 수 있다.

모든 리전에 걸친 이벤트 기록을 한 곳으로 모을 수 있다. 예를 들면 s3버킷 같이.

cloud trail을 사용하면 누군가가 aws에서 무언가를 삭제했을 때 대처할 수 있다. 예를들어 ec2 인스턴스가 종료되었을 경우

누가했는지 알고싶으면 cloudtrail을 들여다 보면 된다.

 

sdk, cli, 콘솔, iam 사용자. iam 역할, aws 서비스의 작업이 cloudtrail콘솔에 표시된다. 이를 분석하면 무슨 일이 일어났는지 알 수 있다.

이 걸 90일 이상 보관하려면 cloud watch logs 나 s3에 저장할 수 있다.

팀원들 중 하나가 중요한 데이터를 포함하고 있는 EC2 인스턴스를 4개월 전에 중단했습니다. 누가 이런 작업을 했는지를 알지 못하는 관계로, CloudTrail을 사용해 이 기간 동안의 모든 API 호출을 검토하려 합니다. CloudTrail은 이미 설정되어 있으며, S3 버킷으로 로그를 보내도록 구성이 되어 있습니다. 누가 이런 작업을 했는지 알아내기 위해서는 어떻게 해야 할까요? -> athena로 s3버킷 내의 cloudtrail 로그를 분석

 

CloudTrail 콘솔은 지난 90일 간 보고된 API 활동을 확인하려는 경우 활용할 수 있습니다. 90일보다 오래된 이벤트의 경우에는 Athena를 사용해 S3 버킷 내에 저장된 CloudTrail 로그를 분석합니다.

 

cloud trail은 3가지 이벤트가 있다.

첫 번째는 관리 이벤트로 이는 aws 계정의 리소스에서 수행되는 작업을 나타낸다.

예를들어 누군가가 보안 설정을 구성하면 iam attach role policy라는 api를 사용하게 되는데 이것이 cloud trail에 표시 된다.

서브넷을 생성해도 표시되고 로깅을 설정해도 기본적으로 표시된다.

리소스나 aws 계정을 수정하는 모든 작업이 cloudtraild에 표시된다.

트레일은 기본적으로 관리 이벤트를 기록하도록 구성되어있다. 이건 두종류로 구분되고, 먼저 리소스를 수정하지 않는 읽기 이벤트가 있다.

( iam 모든 사용자 목록 생성 , ec2 목록 생성할 경우에는 리소스를 수정할 수 있는 쓰기 이벤트를 분리해야 된다 )

 

두번째는 데이터 이벤트이다.

고볼륨 작업이므로 기본적으로 로깅되지 않는다.

s3버킷이벤트, 람다 이벤트 등이 있다.

 

세번째로 cloudtrail insight events 가있다.

 

CloudTrail insights

모든 유형의 서비스에 걸쳐 많은 관리 이벤트가 있고,

계정에서 다수의 api가 매우 빠르게 발생해서 무엇이 이상하거나 특이한지 파악하기 어려울때 cloud watch insights를 활용하면된다.

cloudtrail insights를 활설화하면 이벤트를 분석해 계정내의 특이한 활동을 탐지해준다. 

부정확한 리소스 프로비저닝, 서비스 한도 도달, iam작업 버스트등

무언가를 변경하려고 하거나, 변경한 모든 쓰기 유형의 이벤트를 분석해서 패턴을 탐지한다.

관리 이벤트를 지속적으로 분석해서 뭔가를 탐지하면 인사이트 이벤트를 생성합니다.

 즉 인사이트 이벤트는 CloudTrail 콘솔에 표시됩니다

 

CloudTrail이 전체 AWS 리전의 AWS 계정에 활성화되어 있습니다. AWS 계정 내의 비정상적인 활동을 감지하려면 다음 중 어떤 기능을 사용해야 할까요? -> cloudtail insights

AWS Config

config는 AWS내 리소스에 대한 감사와 규정준수 여부를 기록할 수 있게 해주는 서비스이다.설정된 규칙에 기반해 구성과 구성의 시간에 따른 변화를 기록할 수 있다. 이를 통해 필요한 경우 인프라를빠르게 롤백하고 문제점을 찾아낼 수 있다.

 

config로 해결할 수 있는 질문은 다음과 같다.'보안 그룹에 제한되지 않은 ssh 접근이 있나""버킷에 공용 액세스가 있나?""시난이 지나며 변화한 ALB 구성이 있나"이럴 경우 규칙이 규정을 준수하든 아니든 변화가 생길 때 마다 sns알림을 받을 수 있다.예를들어 EBS디스크에 새 구성이 생길 때마다 EBS 디스크의 유형을 평가하거나 정기적으로 규칙이 평가되도록 만들 수 있다. 2시간 마다 EBS 디스크가 gp2유형인지 평가하는 식. 이건 규정준수를 위한것이지 어떤 동작을 미리 예방하지는 못한다. 어떤 것도 차단할 수 없다.

하지만 구성의 개요와 리소스의 규정 준수 여부는 config 규칙을 통해 알 수 있다.

 

이걸 SSM automation과 결합해서 트리거를 발생시켜 특정 작업을 수행시킬 수 있다.

iam 키 만료 여부를 aws config가 확인, 만료되면 ssm automation이 수정작업 실시

iam이 만료 되어야 수정 가능, 만료 전에는 안됨

 

eventbridge를 사용해 미준수 했을 때마다 알림을 보낼 수 있다.

config를 통해 규정 준수 여부를 확인하다가 미준수 시 eventbridge를 트리거 하여  원하는 리소스에(람다 sns sqs ...) 넘길 수 있다.

 

아니면 바로 config에서 sns로 보낼 수 있다. 

 

요약

CloudWatch, CloudTrail, Config

cloudwatch는 지표, CPU, 네트워크 등의 성능 모니터링과 대시보드를 만드는데 사용된다.

이벤트와 알림을 받을 수도 있고, 로그 집계 및 분석 도구로 사용할 수 있다.

 

cloudTrail은 계정 내에서 만든 API에 대한 모든 호출을 기록한다. 누구에 의한 호출이든 간에 말이다.

특정 리소스에 대한 추적도 정의할 수 있다. 그럼 ec2에 대한 정보만 더 얻을 수도 있다.

 

config는 구성 변경을 기록하고 규정 준수 규칙에 따라 리소스를 평가, 변경과 규정 준수에 타임라인을 보여준다/.

 

ELB로 세가지의 차이점을 확인해보자

cloudwatch는 ELB로 들어오는 연결 수를 모니터링 하고, 오류 코드 수를 시간 흐름에 따라 비율로 시각화를 할 수 있다.

로드밸런서의 성능을 볼 수 있는 대시보드도 만들 수 있다. 

conifg는 로드 밸런서에 대한 보안 그룹 규칙 및 ssl인증서를 수정하지 않는지 등을 감시한다. 구성 변경을 추적하는데 사용가능 cloudTrail은 누가 API를 호출하여 로드 밸런서를 변경했는지 추적한다. 누군가 보안 그룹 규칙을 바꾸거나 혹은 ssl인증서를 바꾸거나 삭제한다면 cloudTrail이 누가 그랬는지 알려줄 수 있다.