[AWS SAA] Monitoring, Troubleshooting & Audit

모니터링은 정말 중요합니다 무슨 일이 일어나는지 로그와 지표, 추적을 통해 보고 AWS 인프라에 누가 무엇을 만들었는지 감사하는 것 입니다. 개인적으로 개발을 잘하는 것도 좋지만 유지보수를 잘 하는 프로그래머가 더 좋은 프로그래머라고 생각합니다.

Amazon CloudWatch Metrics

Amazon CloudWatch Metrics란?

• CloudWatch는 AWS의 모든 서비스에 대한 지표를 제공합니다.
• Metric은 모니터링할 변수입니다(CPUUtilization, NetworkIn...).
• Metric은 namespaces에 속하고, 서비스당 namespaces는 하나입니다.
• Dimension은 Metric(인스턴스 ID, 환경 등)의 속성입니다.
• Metric당 최대 10개의 Dimension
• Metric에는 타임스탬프가 있습니다.
• 지표의 CloudWatch 대시보드 생성 가능
• CloudWatch 사용자 지정 지표 생성 가능(예: RAM용)

CloudWatch Metric Streams

• CloudWatch 지표는 CloudWatch 외부로 스트리밍할 수 있습니다
• 실시간에 가까운 전달과 짧은 대기 시간으로 CloudWatch 지표를 선택한 대상으로 지속적으로 스트리밍합니다.
  • Amazon Kinesis Data Firehose(및 대상)
  • 타사 서비스 제공업체: Datadog, Dynatrace, New Relic, Splunk, Sumo Logic...
• 메트릭을 필터링하여 하위 집합만 스트리밍하는 옵션

CloudWatch Logs

• Log groups: 일반적으로 애플리케이션을 나타내는 임의의 이름
• Log stream: 애플리케이션/로그파일 명/컨테이너 내의 인스턴스
• 로그 만료 정책을 정의할 수 있습니다(만료 안 함, 30일 등).
  • CloudWatch Logs 스토리지는 유료입니다.
• CloudWatch Logs는 다음의 로그를 보낼 수 있습니다:
  • Amazon S3(내보내기)
  • Kinesis 데이터 스트림
  • Kinesis Data Firehose
  • AWS 람다
  • opensearch

CloudWatch Logs - 저장되는 소스

• SDK, CloudWatch Logs Agent, CloudWatch Unified Agent
  • CloudWatch Unified Agent를 요즘에 씀
• Elastic Beanstalk: 애플리케이션의 로그를 CloudWatch에 전송
• ECS: 컨테이너의 로그를 CloudWatch에 전송
• AWS Lambda: 함수 로그에서 수집
• VPC Flow Logs:VPC 메타데이터 네트워크 트래픽 로그
• API 게이트웨이: 받는 모든 요청을 보냄
• CloudTrail: 필터링해 로그를 보냄
• Route53: 로그 DNS 쿼리

CloudWatch Logs Metric Filter & Insights

• CloudWatch Logs는 필터 표현식을 사용할 수 있습니다.
  • 예를 들어 로그 내에서 특정 IP 찾기
  • 또는 로그에서 "ERROR" 발생 횟수를 계산합니다.
• 메트릭 필터를 사용하여 CloudWatch 경보를 트리거할 수 있습니다.
• CloudWatch Logs Insights를 사용하여 로그를 쿼리하고 CloudWatch 대시보드에 쿼리를 추가할 수 있습니다.

CloudWatch Logs – S3 Export

• 로그 데이터를 내보낼 수 있으려면 최대 12시간이 걸릴 수 있습니다.
• API 호출은 CreateExportTask입니다.
• 거의 실시간 또는 실시간이 아님...
• 로그를 스트림하고 싶다면 Subscriptions를 사용해야합니다.

CloudWatch Logs Subscriptions

Subscriptions란 CloudWatch Logs 상단에 적용하여 이를 목적지로 보내는 필터를 말합니다.

• 목적지의 예를 들자면 Lambda 함수가 있는데요 직접 정의하든 AWS 제공을 쓰든 Amazon ES에 데이터를 보낼 때 씁니다
• Kinesis Data Firehose는 Amazon S3에 근 실시간 전송을 할 때 쓰고, CloudWatch에서 S3로 내보내기한 것보다 훨씬 빠른 방법입니다.
• Kinesis Data Streams로 데이터를 보낼 수도 있습니다 (KDF, KDA EC2, Lambda 등)

CloudWatch Logs Aggregation Multi-Account & Multi Region

• CloudWatch Logs로 여러 계정과 리전간 로그를 집계할 수 있습니다
• 여러 계정을 생성할 수 있는데요 예를 들어서 리전1에 구독 필터를 가진 계정A가 있다면 공통 계정을 통해 Kinesis Data Streams로 보내집니다.
• 계정B와 리전2, 3도 마찬가지고요 모든 로그를 모아 Kinesis Data Streams 그리고 Data Firehose 이후에는 Amazon S3로 보낼 수 있게 됩니다.

CloudWatch Logs for EC2

CloudWatch 에이전트를 이용해서 EC2 인스턴스에서 로그와 지표를 받아 CloudWatch에서 표시할 수 있는 방법을 알아보려합니다.

• 기본적으로 EC2 시스템의 로그는 CloudWatch로 이동하지 않습니다.
• 원하는 로그 파일을 푸시하려면 EC2에서 CloudWatch 에이전트를 실행해야 합니다.
• IAM 권한이 올바른지 확인
• CloudWatch 로그 에이전트는 온프레미스에서도 설정할 수 있습니다.

CloudWatch Logs Agent & Unified Agent

• 가상 서버용(EC2 인스턴스, 온프레미스 서버...)
• CloudWatch 로그 에이전트
  • 이전 버전의 에이전트
  • CloudWatch Logs로만 보낼 수 있음
• CloudWatch 통합 에이전트
  • RAM, 프로세스 등과 같은 추가 시스템 수준 메트릭 수집...
  • CloudWatch Logs로 보낼 로그 수집
  • SSM Parameter Store를 사용한 중앙 집중식 구성

CloudWatch Unified Agent – Metrics

• Linux 서버/EC2 인스턴스에서 직접 수집

  • CPU(활성, 게스트, 유휴, 시스템, 사용자, 도용)
  • Disk metrics(free, 사용, 총계), Disk IO(쓰기, 읽기, 바이트, iops)
  • RAM(free, 비활성, 사용됨, 전체, 캐시됨)
  • Netstat(TCP 및 UDP 연결 수, 순 패킷, 바이트)
  • Processes(전체, 작동 중지, 블록, 유휴, 실행 중, 절전)
  • swap space(가용, 사용, 사용 %)

• Reminder: EC2에 대한 즉시 사용 가능한 지표 – 디스크, CPU, 네트워크(높은 수준)

• 위와 같이 세부 지표를 얻고 싶다면 통합 CloudWatch 에이전트를 이용하면됩니다.

CloudWatch Alarms

• 경보는 모든 메트릭에 대한 알림을 트리거하는 데 사용됩니다.
• 다양한 옵션(샘플링, %, 최대, 최소 등...)
• 알람 상태:
  • OK
  • INSUFFICIENT_DATA
  • ALARM
• 기간:
  • 기간은 경보가 지표를 평가하는 기간을 말합니다 짧게 설정할 수도 길게 설정할 수도 있습니다.
  • 고해상도 맞춤 측정항목: 10초, 30초 또는 60초의 배수

CloudWatch Alarm Targets

• EC2 인스턴스 중지, 종료, 재부팅 또는 복구
• 트리거 Auto Scaling 작업
• SNS로 알림 전송(거의 모든 작업 가능)

CloudWatch Alarms – Composite Alarms

• CloudWatch Alarm은 단일 지표에 있습니다.
• Composite Alarms는 다른 여러 경보의 상태를 모니터링합니다.
• AND 및 OR 조건
• 복잡한 Composite Alarms를 생성하여 "알람 노이즈"를 줄이는 데 도움이 됩니다.

EC2 Instance Recovery

• 상태 확인:
  • 인스턴스 상태 = EC2 VM 확인
  • 시스템 상태 = 기본 하드웨어 확인

• 이 두 점검으로 CloudWatch 경보를 만들 수 있습니다.
• 특정 EC2 인스턴스를 모니터링하다가 경보가 위반됐을 경우 EC2 인스턴스 복구를 실행해 EC2 인스턴스를 다른 호스트로 옮기는 등의 작업을 할 수 있습니다.
• 복구할 때는 동일한 private, public, Elastic IP 주소와 동일한 메타데이터 동일한 인스턴스 배치 그룹을 가지게 됩니다
• 또한 SNS 주제에 경보를 보내 EC2 인스턴스가 복구되었다는 사실을 인지하게 할 수도 있습니다.

CloudWatch Alarm: good to know

CloudWatch Logs 지표 필터를 기반으로 경보 생성 가능

• 경보 및 알림을 테스트하려면 CLI를 사용하여 경보 상태를 경보로 설정하면 됩니다.

aws cloudwatch set-alarm-state --alarm-name "myalarm" --state-value ALARM --state-reason "testing purposes"

• 이것은 특정 임계값이 도달하지 않아도 경보를 트리거하고 싶을 때 유용합니다.
• 본인의 인프라 내에서 경보가 올바르게 트리거되어 제대로 된 결과를 내는지 여부를 알 수 있는 거죠

---

Amazon EventBridge (formerly CloudWatch Events)

이 AWS 서비스의 예전 이름은 CloudWatch Events였습니다. Amazon EventBridge는 자체 애플리케이션, Software-as-a-Service(SaaS) 애플리케이션, AWS 서비스의 데이터를 사용하여 애플리케이션을 쉽게 연결할 수 있게 지원하는 서버리스 이벤트 버스입니다.

• Schedule: Cron 작업(예약된 스크립트)
  

• Event Pattern: 무언가를 수행하는 서비스에 반응하는 이벤트 규칙
  

• 대상(destination)이 다양하다면 Lambda 함수 트리거, SQS/SNS 메시지 전송할 수 있습니다.

Amazon EventBridge Rules

Amazon EventBridge

• 기본 이벤트 버스
  • 이벤트를 기본 이벤트 버스로 전송하는 AWS의 서비스를 말합니다.
• 파트너 이벤트 버스
  • 파트너와 통합된 AWS 서비스를 말하는데, 대부분의 파트너는 소프트웨어 서비스 제공자입니다.
  • 이 파트너들은 파트너 이벤트 버스로 이벤트를 전송합니다.
    • 예) Zendesk 혹은 Datadog, Auth0 등을 사용
  • 이런 특정 파트너 이벤트 버스로 이벤트를 전송할 수 있고 우리의 계정을 통해 AWS 외부에서 일어나는 변화에 반응할 수 있게 되는 것 입니다.
• 사용자 지정 이벤트 버스
  • 자체 버스를 만드는 것을 말합니다.
  • 우리의 애플리케이션의 자체 이벤트를 사용자 지정 이벤트 버스로 전송합니다.
  • Amazon EventBridge 규칙 덕분에 다른 이벤트 버스처럼 여러 대상으로 이벤트를 보낼 수 있는 겁니다.
• 리소스 기반 정책을 사용하여 다른 AWS 계정에서 이벤트 버스에 액세스할 수 있습니다.
• 이벤트 버스로 전송된 이벤트(모두/필터)를 보관(아카이빙)할 수 있습니다(무기한 또는 기간 설정).
• 보관된 이벤트 재생 기능
  • 예를 들어 Lambda 함수의 버그를 수정할 때 수정 후에 이벤트를 다시 테스트하고 재생

Amazon EventBridge – Schema Registry

EventBridge는 여러 곳에서 이벤트를 받습니다 그러므로 이벤트가 어떻게 생겼는지 파악해야 합니다.

• 이벤트는 JSON 형식입니다.
• EventBridge 버스와 스키마를 추론합니다.
• Schema Registry를 사용하면 이벤트 버스에서 데이터가 어떻게 구성되는지 미리 알 수 있는 애플리케이션용 코드를 생성할 수 있습니다.
• 스키마 버전 관리 가능합니다.

• 특정 코드 파이프라인 작업의 스키마를 예로 살펴보겠습니다.
• 주황색 버튼을 눌러 코드를 다운로드하면 EventBridge가 이벤트 버스로부터 스키마 추론 방법과 데이터의 정형화 방식을 파악할 것입니다.
• 스키마를 버저닝할 수도 있어 애플리케이션의 스키마를 반복할 수 있습니다.

Amazon EventBridge – Resource-based Policy

• 특정 이벤트 버스에 대한 권한 관리
• 예: 다른 AWS 계정 또는 AWS 지역의 이벤트 허용/거부

• 사용 사례:
  - 여러 계정의 모음인 AWS Organizations의 중앙에 이벤트 버스를 두고 모든 이벤트를 모으는 겁니다
  • central-event-bus 계정에 다른 계정이 이벤트를 보낼 수 있도록 리소스 기반 정책을 추가하면 오른쪽에 있는 다른 계정에서 PutEvents 작업을 통해 이벤트를 central-event-bus로 전송할 수 있습니다.

CloudWatch Insights과 운영 가시성

CloudWatch Container Insights

CloudWatch Container Insights를 사용하면 컨테이너로부터 지표와 로그를 손쉽게 추출해서 CloudWatch에 세분화된 대시보드를 만들 수 있습니다.

• 컨테이너에서 메트릭 및 로그 수집, 집계, 요약
• 컨테이너에 사용 가능:
  • Amazon Elastic Container Service(Amazon ECS)
  • Amazon Elastic Kubernetes Services(Amazon EKS)
  • EC2의 Kubernetes 플랫폼
  • Fargate(ECS 및 EKS용)
• Amazon EKS 및 Kubernetes에서 CloudWatch Insights는 CloudWatch Agent의 컨테이너화된 버전을 사용하여 컨테이너를 검색합니다.

CloudWatch Lambda Insights

AWS Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션입니다.

• CPU 시간, 메모리, 디스크 및 네트워크를 포함한 시스템 수준 메트릭을 수집, 집계 및 요약합니다.
• 콜드 스타트 및 Lambda 작업자 종료와 같은 진단 정보를 수집, 집계 및 요약합니다.
• Lambda Insights는 Lambda Layer로 제공됩니다.

CloudWatch Contributor Insights

기고자(Contributor) 데이터를 표시하는 시계열 데이터를 생성하고 로그를 분석하는 서비스입니다.

• 로그 데이터를 분석하고 기여자 데이터를 표시하는 시계열을 만듭니다.
  • 상위 N명의 기여자에 대한 측정항목 보기
  • 고유 기여자의 총 수 및 사용.
• 이렇게 하면 가장 많이 말하는 사람을 찾고 누가 또는 무엇이 시스템 성능에 영향을 미치는지 이해하는 데 도움이 됩니다.
• 모든 AWS 생성 로그(VPC, DNS 등)에서 작동합니다.
• 예를 들어 잘못된 호스트를 찾거나 가장 많은 네트워크 사용자를 식별하거나 가장 많은 오류를 생성하는 URL을 찾을 수 있습니다.

사용량이 많은 네트워크 사용자를 식별하는 방법을 살펴보겠습니다.

• 모든 네트워크 요청에 대해 VPC 내에서 생성되는 로그인 VPC 플로우 로그생성되고
• CloudWatch Logs로 전달됩니다.
• 이어서 CloudWatch Contributor Insights를 통해 log를 분석하여
• VPC에 트래픽을 생성하는 상위 10개의 IP 주소를 찾고 좋은 사용자인지 나쁜 사용자인지 판단합니다.

• 처음부터 규칙을 구축하거나 AWS에서 생성한 샘플 규칙을 사용할 수도 있습니다. CloudWatch Logs 활용
• CloudWatch는 또한 다른 AWS 서비스의 지표를 분석하는 데 사용할 수 있는 기본 제공 규칙을 제공합니다.

CloudWatch Application Insights

• 모니터링되는 애플리케이션의 잠재적인 문제를 보여주는 자동화된 대시보드를 제공하여 진행 중인 문제를 격리하는 데 도움이 됩니다.
• 애플리케이션은 엄선된 기술(Java, .NET, Microsoft IIS 웹 서버, 데이터베이스...)로만 Amazon EC2 인스턴스에서 실행됩니다.
• 또한 Amazon EBS, RDS, ELB, ASG, Lambda, SQS, DynamoDB, S3 버킷, ECS, EKS, SNS, API 게이트웨이와 같은 다른 AWS 리소스를 사용할 수 있습니다.
• SageMaker 제공
• 소요 시간을 줄이기 위해 애플리케이션 상태에 대한 향상된 가시성
  애플리케이션의 문제를 해결하고 복구할 수 있습니다.
• 결과 및 알림은 Amazon EventBridge 및 SSM OpsCenter로 전송됩니다.

CloudWatch Insights and Operational Visibility

• CloudWatch 컨테이너 인사이트
  • ECS, EKS, EC2의 Kubernetes, Fargate, Kubernetes용 에이전트 필요
  • 지표 및 로그
• CloudWatch Lambda 인사이트
  • 서버리스 애플리케이션의 문제를 해결하기 위한 자세한 지표
• CloudWatch 기여자 통찰력
  • CloudWatch Logs를 통해 "Top-N" 기여자 찾기
• CloudWatch 애플리케이션 인사이트
  • 애플리케이션 및 관련 AWS 서비스 문제 해결을 위한 자동 대시보드

---

AWS CloudTrail

• AWS 계정에 대한 거버넌스, 규정 준수 및 감사 제공
• CloudTrail은 기본적으로 활성화되어 있습니다!
• 다음을 통해 AWS 계정 내에서 이루어진 이벤트/API 호출 기록을 가져옵니다.
  • console
  • SDK
  • CLI
  • AWS 서비스
• CloudTrail의 로그를 CloudWatch Logs 또는 S3에 넣을 수 있습니다.
• 전체 또는 단일 리전에 적용되는 트레일을 생성해 모든 리전에 걸친 이벤트 기록을 한곳으로 모을 수 있습니다

예 )

• CloudTrail를 사용하면 누군가가 AWS에서 무언가를 삭제했을 때 대처할 수 있습니다.
• EC2 인스턴스가 종료됐을 경우 누가 했는지를 알고 싶으면 CloudTrail을 들여다보면 됩니다.
• CloudTrail에 해당 API 호출이 남아 있으므로 누가 언제 문제를 일으켰는지 알아낼 수 있습니다.

CloudTrail Diagram

• CloudTrail이 중심에 있고 SDK, CLI, 콘솔, IAM 사용자 IAM 역할, AWS 서비스의 작업이 CloudTrail 콘솔에 표시됩니다.
• 이를 분석하면 무슨 일이 일어났는지 알 수 있습니다.
• 모든 이벤트를 90일 이상 보관하려면 CloudWatch Logs 또는 S3 버킷으로 보내면 됩니다

CloudTrail Events

Management Event:

• AWS 계정의 리소스에서 수행되는 작업
• 예:
  • 보안 구성(IAM AttachRolePolicy)
  • 데이터 라우팅 규칙 구성(Amazon EC2 CreateSubnet)
  • 로깅 설정(AWS CloudTrail CreateTrail)
• 기본적으로 추적은 관리 이벤트를 기록하도록 구성됩니다.
• 쓰기 이벤트(리소스를 수정할 수 있음)에서 읽기 이벤트(리소스를 수정하지 않음)를 분리할 수 있습니다.
  • 쓰기 이벤트의 중요도가 훨씬 높습니다

Data Event:

• 기본적으로 데이터 이벤트는 기록되지 않습니다(대량 작업이기 때문에).
• Amazon S3 객체 수준 활동(예: GetObject, DeleteObject, PutObject)은 빈번하게 발생하는 이벤트 이므로 기본적으로 로깅되지 않습니다. 또한, 읽기 이벤트와 쓰기 이벤트를 분리할 수 있습니다.
• AWS Lambda 함수 실행 활동(Invoke API), Lambda 함수가 몇 번 활용되었는지 알 수 있습니다 이 역시 Lambda 함수가 많이 실행되면 볼륨이 커질 수 있습니다.

CloudTrail Insights Event:

• 모든 유형의 서비스에 걸쳐 너무 많은 관리 이벤트가 있고 계정에서 다수의 API가 매우 빠르게 발생해서 무엇이 이상하거나 특이한지 파악하기 어려울 때 CloudWatch Insights를 활용

• 비용을 내고 CloudTrail Insights를 활성화하여 계정의 비정상적인 활동 감지:

  • 부정확한 리소스 프로비저닝
  • 서비스 한도 도달
  • AWS IAM 작업의 버스트
  • 정기 유지보수 활동의 공백

• CloudTrail Insights는 정상적인 관리 이벤트를 분석하여 기준선을 생성한 다음, 쓰기 이벤트를 지속적으로 분석하여 비정상적인 패턴을 감지합니다.
  

• 관리 이벤트를 지속적으로 분석해서 뭔가를 탐지하면 인사이트 이벤트를 생성합니다.
• 이상 상황, 즉 인사이트 이벤트는 CloudTrail 콘솔에 표시됩니다
• 원한다면 Amazon S3로 전송할 수도 있고 이메일을 보내는 CloudTrail Insights에 자동화를 추가하면 EventBridge 이벤트가 생성됩니다.

CloudTrail Events 보존기간

• 이벤트는 CloudTrail에 90일 동안 저장됩니다.
• 이 기간 이후에도 이벤트를 유지하려면 S3에 기록하고 Athena를 사용하면 됩니다.

Amazon EventBridge – API Calls 가로채기

CloudTrail 통합 중에 API 호출을 가로채는 Amazon EventBridge와의 통합은 꼭 알아야 합니다

사용자가 테이블 삭제 API 호출을 사용해서 DynamoDB의 테이블을 삭제할 때마다 SNS 알림을 받고 싶다고 가정해 보겠습니다.

• AWS에서 API 호출을 실행할 때마다 API 호출 자체가 CloudTrail에 로깅됩니다.
• 모든 API 호출이 로깅됩니다 그리고 모든 API 호출은 Amazon EventBridge에 이벤트로 기록됩니다.
• EventBridge에 특정 테이블 삭제 API 호출을 찾아 규칙을 생성합니다.-- 규칙에는 대상이 필요하니, Amazon SNS를 대상으로 설정하면 경고를 생성할 수 있습니다

---

AWS Config

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

• AWS 리소스의 규정 준수 감사 및 기록 지원
• 시간 경과에 따른 구성 및 변경 사항 기록 지원
  • 이를 통해 필요할 경우 인프라를 빠르게 롤백하고 문제점을 찾아낼 수 있습니다.
• AWS Config로 해결할 수 있는 질문:
  • 내 보안 그룹에 대한 무제한 SSH 액세스가 있습니까?
  • 내 버킷에 퍼블릭 액세스가 있습니까?
  • 시간 경과에 따라 내 ALB 구성이 어떻게 변경되었습니까?
• 변경 사항에 대한 알림(SNS 알림)을 받을 수 있습니다.
• AWS Config는 리전별 서비스입니다.
• 여러 지역 및 계정에 걸쳐 집계 가능
• 모든 리소스의 구성을 S3에 저장해 나중에 분석할 수 있습니다(Athena에서 분석)

Config Rules

• AWS 관리 구성 규칙 사용 가능(75개 이상)
• 사용자 지정 구성 규칙을 만들 수 있음(AWS Lambda에서 정의해야 함)
  • 예: 각 EBS 디스크가 gp2 유형인지 평가
  • 예: 각 EC2 인스턴스가 t2.micro인지 평가
• 규칙을 평가/트리거할 수 있습니다.
  • 각 구성 변경에 대해
  • and / or: 일정한 시간 간격으로
• AWS Config Config 규칙은 규정 준수를 위한 겁니다. 어떤 동작을 미리 예방하지는 못합니다 어떤 것도 차단할 수 없습니다.(거부 없음).
• 요금: 프리 티어 없음, 지역별로 기록된 구성 항목당 $0.003,
  리전별 구성 규칙 평가당 $0.001

AWS Config Resource

• 시간 경과에 따른 리소스 준수 보기

• 시간 경과에 따른 리소스 구성 보기

• 시간 경과에 따른 리소스의 CloudTrail API 호출 보기

Config Rules – 수정

SSM 자동화 문서를 사용하여 규정 미준수 리소스 수정 자동화할 수 있습니다.

IAM 액세스 키의 만료 여부를 모니터링한다고 가정하겠습니다.

• 예를 들어 키가 90일 이상 보관된 경우로 이런 경우는 규정을 준수하지 않은 상태입니다
• 그러니까 규정 미준수를 예방하지는 못하지만 리소스가 규정을 미준수할 때마다 수정 작업을 트리거 할 수 있습니다.
• RevokeUnusedIAMUserCredentials 라는 이름의 SSM 문서가 있고
  이걸 이용하면 이게 리소스에 적용된다고 하겠습니다.
• 이 경우 SSM 문서가 IAM 액세스 키를 비활성화합니다

• AWS 관리형 자동화 문서를 사용하거나 사용자 지정 자동화 문서를 생성하든 규정을 준수하지 않는 리소스를 수정할 수 있습니다.
  • 팁: Lambda 함수를 호출하는 사용자 정의 자동화 문서를 생성할 수 있습니다.
• 리소스가 자동 치료 후에도 여전히 규정을 준수하지 않는 경우 치료 재시도를 설정할 수 있습니다. (5번)

Config Rules – Notifications

• EventBridge를 사용하여 AWS 리소스가 규정을 준수하지 않을 때 알림 트리거

• 구성 변경 및 규정 준수 상태 알림을 SNS로 보내는 기능(모든 이벤트 – 클라이언트 측에서 SNS 필터링 또는 필터 사용)

CloudWatch vs CloudTrail vs Config

• CloudWatch
  • 성능 모니터링(메트릭, CPU, 네트워크 등) 및 대시보드
  • 이벤트 및 경고
  • 로그 집계 및 분석
• CloudTrail
  • 모든 사람이 계정 내에서 수행한 API 호출을 기록합니다.
  • 특정 리소스에 대한 추적을 정의할 수 있습니다.
  • 글로벌 서비스
• Config
  • 구성 변경 기록
  • 규정 준수 규칙에 따라 리소스 평가
  • 변경 및 규정 준수 일정 확인

For an Elastic Load Balancer

• CloudWatch
  • 들어오는 연결 메트릭 모니터링
  • 시간 경과에 따라 오류 코드를 %로 시각화
  • 로드 밸런서 성능에 대한 아이디어를 얻을 수 있는 대시보드 만들기
• Config
  • 로드 밸런서에 대한 보안 그룹 규칙 추적
  • 로드 밸런서에 대한 구성 변경 추적
  • SSL 인증서가 항상 로드 밸런서에 할당되었는지 확인(규정 준수)
• CloudTrail
  • API 호출로 Load Balancer를 변경한 사람 추적

---

AWS Certified Solutions Architect Associate 시험합격!