AWS SAA - Monitoring & Audit

Monitoring & Audit

CloudWatch

CloudWatch Metrics

CloudWatch 는 모든 AWS 서비스에 대한 지표를 제공한다.

Metric 은 모니터링할 수 있는 다양한 지표이다. (CPUUtilization, NetworkIn ...)

지표가 어떤가에 따라서 서비스 작동 상태도 알 수 있다.

Dimension 은 지표의 속성이 된다. (instance id, environment ...)

지표당 10개의 dimension 을 만들 수 있다.

지표에는 timestamp 가 있어서 그래프로 표시할 수 있다.

EC2 Detailed Monitoring

EC2 인스턴스는 기본적으로 5분마다 지표를 가진다.

세부 모니터링 (detailed monitoring) 을 활성화하면, 매 1분마다 지표를 얻을 수 있다.

• 이를 이용하면 ASG가 더욱 빠르게 스케일로 대응할 수 있게 도울 수 있다.

EC2 Memory usage 는 기본적으로 제공되는 지표가 아니며, 인스턴스에서 custom metric 으로 push 되어야 한다.

Custom Metrics

RAM 사용량이나 디스크 공간, 어플리케이션 로그인 사용자 수같은 다양한 커스텀 지표를 CloudWatch 에 푸시할 수 있다.

이에 대한 dimension 이름은 자유롭게 지을 수 있다.

• Standard : 1분 해상도
• High Resolution : 1/5/10/30 초

이러한 커스텀 지표는 해당 지표의 과거 혹은 미래 시간을 설정해서 푸시가 가능하다.

Dashboards

이러한 지표들을 대시보드에 표시할 수 있다.

주요 지표들과 Alarm 에 접근할 수 있으며, 글로벌화되어있기에 많은 리전과 계정을 통합하여 다양한 그래프를 보여준다.

AWS 계정이 없는 사람들과 대시보드를 공유할 수도 있다.

CloudWatch Logs

로그들을 로그 그룹으로 그룹화하는데, 이는 일반적으로 어플리케이션으로 나뉘게 된다.

Log stream : 어플리케이션 내 인스턴스, 로그 파일명, 컨테이너 등

로그 만료일 또한 설정이 가능하다.

필터 표현식을 써서 원하는 데이터셋을 얻고, 이를 기반으로 Metric filter 를 얻어 Alarm 과 연계할 수 있다.

S3으로 내보내기까지 12시간이 소요될 수 있으며, 이는 real-time 이 아니다.

real-time 으로 데이터를 저장해야 한다면 Logs Subscriptions 를 사용해야 한다.

• S3
• Kinesis Data Streams / Firehose
• AWS Lambda
• ElasticSearch

위 서비스로 로그를 내보낼 수 있다.

Sources

• CloudWatch Logs Agent, SDK, CloudWatch Unified Agent
• Elastic Beanstalk
• ECS, Lambda
• VPC Flow Logs
• API Gateway
• CloudTrail based on filter
• Route53

CloudWatch Agent

기본적으로, EC2 에서 CloudWatch 로 데이터를 전송하는 것은 EC2 내부의 CloudWatch Logs Agent 가 담당하며,
이는 온프레미스 환경에서도 셋업될 수 있다.

CloudWatch Unified Agent 는 기존의 Logs Agent 보다 더욱 세분화되어있는 지표를 제공하며, 최신의 서비스이다.

CloudWatch Alarms

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

• OK : 트리거되지 않았음
• INSUFFICIENT_DATA : 상태를 결정할 데이터가 부족한 상태
• ALARM : 임계값에 도달하여 알림이 보내지는 상태

CloudWatch Logs Metrics Filters 에 따라서 Alarm 의 설정이 가능하다.

Alarm Targets

• EC2 인스턴스의 중지, 종료, 재시작, 복구
• Auto Scaling Action Trigger
• Send notification to SNS

CloudWatch Events

Event를 통해서 모든 AWS 서비스 내의 이벤트를 인터셉트할 수 있다.

EC2 인스턴스 스타트나 CodeBuild 실패 등의 다양한 이벤트를 받아들일 수 있다.

예약이나 Cron을 설정하여 이벤트를 작동시킬 수 있다.

Amazon EventBridge

이는 CloudWatch Events 의 차세대 버전이다.

기본적으로 EventBridge에 포함된 Event Bus는 AWS 서비스에서 생성된 것으로, CloudWatch Event와 동일하다.

하지만 이에 더해, Partner Event Bus 를 통해 SaaS 서비스나 어플리케이션의 이벤트를 받을 수 있다.

또한 사용자가 직접 만든 Custom Event Bus 또한 사용이 가능하다.

이러한 이벤트 버스는 Resource-based Policy 에 따라서 다른 AWS 계정에서 접근할 수 있다.

이러한 이벤트는 아카이빙될 수 있으며, 저장된 이벤트를 재사용할 수 있다.

Schema Registry

EventBridge에 이벤트가 전송되면 서비스 자체에서 버스 내 이벤트를 분석하고 schema를 추론한다.

그 이후 Schema Registry 에서 코드를 생성하고, 앱은 코드를 통해 이벤트 버스 내 데이터의 구조를 인식한다.

CloudTrail

AWS 계정에 Governance 와 규정 준수, 감사권을 부여한다.

이는 활성화가 기본으로 설정되어 있기에 AWS 계정 내의 모든 이벤트 기록과 서비스에 의한 API 호출 기록을 볼 수 있다.

이러한 Trail 은 단일 리전과, 모든 리전에 적용될 수 있다.

Management Events

• AWS 계정 내 리소스에 작동한 연산을 나타낸다.
• 누군가가 보안을 구성하기 위해 쓴 Policy 기록
• 서브넷을 생성할 때 쓴 EC2 CreateSubnet 액션
• 기본적으로 항상 활성화되어있다.
• Read Events
  • 리소스를 수정 않는 읽기 이벤트
• Write Events
  • 리소스를 수정하는 쓰기 이벤트

Data Events

• 기본적으로 데이터 이벤트는 로깅되지 않는다.
• S3의 GetObject 나 DeleteObject 같은 액션을 의미한다.
• Read Events
  • GetObject 등
• Write Events
  • DeleteObject
  • PutObject 등
• Lambda 기능의 실행을 로깅한다.

CloudTrail Insights Events

모든 서비스를 통틀어 관리 이벤트가 너무 많고 계정 내에서 API 가 급속히 실행되고 있다면 분석이 쉽지 않을 수 있다.

쓰기 이벤트를 분석하여 평소와 다른 활동을 찾아낸다.

CloudTrail Events Retention

CloudTrail 내 이벤트는 기본적으로 90일까지 저장된다.

하지만 보존 기간을 늘려야 할 때, 90일에 도달한 이러한 로그들을 S3 에 저장할 수 있다.

AWS Config

Config는 AWS 내 리소스에 대한 감사와 규정 준수 여부를 기록할 수 있게 해주는 서비스이다.

구성 설정과 구성의 시간에 따른 변화를 기록할 수 있으며, 이를 통해 필요한 경우 인프라를 롤백하거나 문제점을 찾아낼 수 있다.

원하는 변경 사항 구독마다 SNS 알림을 받을 수 있다.

Config 는 리전별 서비스이므로 모든 리전별로 구성해야 한다.

데이터를 S3 에 저장하여 Athena 로 추후에 분석할 수 있다.

Config Rules

• AWS 관리형 Config 규칙
• 직접 제작한 Config 규칙 (Lambda 를 통하여 정의될 수 있다)
• 구성이 변화할 때마다 트리거시킬 수 있다.
• 정기적으로 이러한 구성이 규칙에 부합한지 확인할 수 있다.
• Config 는 어떠한 액션도 차단하지는 않는다.

Remediations

SSM 자동화 문서를 이용하여 규정을 준수하지 않는 리소스를 자동으로 수정할 수 있다.

AWS 관리형 문서를 사용할 수도 있고, 본인의 자동화 문서를 제작하여 사용할 수도 있다.