AWS Config, EventBridge(CloudWatch Events), Auto Remediation 조합
이 세 가지는 AWS 리소스의 규정 준수 상태를 자동으로 모니터링하고, 위반 시 감지 및 자동 수정하는 데 사용되는 핵심 구성 요소이다.
이 조합은 보안 및 운영 거버넌스를 자동화하는 데 매우 유용하다.
AWS Config
리소스 상태를 지속적으로 추적하고, 정의된 규칙(Config Rule)을 통해 비준수 상태(Non-compliant) 여부를 판단
Amazon CloudWatch Events(Event Bridge)
AWS Config의 규칙 평가 결과 또는 리소스 변경 이벤트를 기반으로 알람 또는 이벤트 트리거로 다른 서비스 호출, 혹은 작업을 수행
- SNS 알림 전송 : 알람 발생 시 SNS 주제로 메시지를 전송하여 이메일, Lambda 등과 연동
- EC2 인스턴스 중지 (Stop) : CPU 사용률 등의 조건에 따라 인스턴스를 자동 중지
- EC2 인스턴스 종료 (Terminate) : 조건 충족 시 인스턴스를 완전 종료하여 자원 회수
- EC2 인스턴스 재부팅 (Reboot) : 인스턴스를 자동으로 재시작하여 일시적 오류 해결
- Auto Scaling 조정 : Auto Scaling 그룹의 인스턴스 수를 자동 확장 또는 축소
- ECS 작업 수 조정 : ECS 서비스의 태스크 수를 자동으로 조정
- SSM OpsItem 생성 : 장애나 이상 감지 시 OpsCenter에 항목을 자동 등록
- Application Auto Scaling 실행 : DynamoDB, Aurora 등의 리소스를 정책 기반으로 스케일링
- Step Functions 실행 (EventBridge 연계) : 상태 변화에 따라 지정된 상태 머신을 자동 실행
Auto Remediation (자동 수정)
AWS Systems Manager(SSM) Automation 문서를 실행하여 위반 리소스를 자동으로 수정
조합을 사용한 사용 사례
시나리오 | Config Rule (AWS Config) | EventBridge | Auto Remediation |
S3 퍼블릭 차단 | S3_BUCKET_PUBLIC_READ_PROHIBITED | 위반 감지 시 이벤트 발생 | S3 버킷 정책 수정 |
보안 그룹 0.0.0.0/0 차단 | INCOMING_SSH_DISABLED | 비준수 발생 이벤트 수신 | SG 인바운드 규칙 삭제 |
태그 미존재 감지 | Custom Rule | EventBridge로 이벤트 수집 | 태그 자동 부착 |
예제 문제
한 회사에서 AWS Organizations에서 관리하는 모든 계정에 대해 인바운드 트래픽의 소스 주소로 0.0.0.0/0을 사용하는 보안 그룹을 감지하는 자동화된 솔루션을 만들고자 합니다. 또한, 회사 인트라넷에 해당하는 특정 CIDR 블록에 대한 액세스를 제한하여 규정을 위반하는 모든 보안 그룹을 자동으로 수정하려고 합니다. 시스템 운영 관리자는 솔루션을 만들기 위해 어떤 조치를 취해야 할까요?
- A. 규정을 준수하지 않는 보안 그룹을 감지하는 AWS Config 규칙을 생성하세요. 0.0.0.0/0 소스 주소를 승인된 CIDR 블록으로 변경하는 자동 수정을 설정하세요.
- B. 소스 주소가 0.0.0.0/0인 보안 그룹 생성을 거부하는 IAM 정책을 생성하세요. 이 IAM 정책을 회사의 모든 사용자에게 연결하세요.
- C. 신규 및 기존 보안 그룹을 검사하는 AWS Lambda 함수를 생성합니다. 규정을 준수하지 않는 0.0.0.0/0 소스 주소를 확인하고 소스 주소를 승인된 CIDR 블록으로 변경합니다.
- D. 조직 단위(OU)에 대해 서비스 제어 정책(SCP)을 생성하여 원본 주소가 0.0.0.0/0인 보안 그룹 생성을 거부합니다. 0.0.0.0/0 원본 주소를 승인된 CIDR 블록으로 변경하는 자동 수정을 설정합니다.
답 : A
이유 : AWS Config는 rule을 통해 0.0.0.0/0을 사용하는 인바운드 규칙을 탐지할 수 있으며, 자동 수정(Auto Remediation)을 구성하면 특정 CIDR로 규칙을 교체 가능하다.
시스템 운영 관리자는 평균 CPU 사용률이 60분 이상 10% 미만인 모든 Amazon EC2 인스턴스를 자동으로 종료하는 솔루션을 만들어야 합니다.
이 요구 사항을 가장 운영 효율적으로 충족하는 솔루션은 무엇일까요?
- A. 각 EC2 인스턴스에 60분마다 한 번씩 실행되는 Cron 작업을 구현하여 현재 CPU 사용률을 계산합니다. CPU 사용률이 10% 미만이면 인스턴스를 종료합니다.
- B. 각 EC2 인스턴스에 대해 평균 CPU 사용률을 모니터링하기 위해 Amazon CloudWatch 알람을 구현합니다. 기간은 1시간으로, 임계값은 10%로 설정합니다. 알람에 대해 인스턴스를 중지하는 EC2 작업을 구성합니다.
- C. 각 EC2 인스턴스에 통합 Amazon CloudWatch 에이전트를 설치하고 기본 수준의 사전 정의된 메트릭 세트를 활성화합니다. 60분마다 CPU 사용률을 기록하고, CPU 사용률이 10% 미만이면 인스턴스를 종료합니다.
- D. AWS Systems Manager Run Command를 사용하여 60분마다 각 EC2 인스턴스의 CPU 사용률을 확인하세요. CPU 사용률이 10% 미만이면 인스턴스를 종료하세요.
답 : B
이유 : CPU 사용률은 CloudWatch의 기본 메트릭 중 하나로, 별도의 에이전트 설치가 필요하지 않다. 또한, EC2인스터스 중지 작업도 별도 연동 없이 CloudWatch Alarm 내에서 작업을 지원하므로 B번이다.
D번이 아닌 이유 : CloudWatch 내 기본 옵션으로도 구현할 수 있으므로 D번은 운영 효율적이지 않다.
'Certificate > AWS SOA-C02' 카테고리의 다른 글
[AWS] SQS 기반 ASG, EventBridge(CloudWatch Events) 조합, 한 번에 이해하기 (0) | 2025.04.17 |
---|---|
[AWS] S3 MFA Delete로 로그 파일 보호하기, 한 번에 이해하기 (0) | 2025.04.16 |
[AWS] VPC 피어링, 한 번에 이해하기 (0) | 2025.04.16 |
[AWS] EC2 시스템 상태 검사 실패(System Status Check Failure)란?, 한 번에 이해하기 (0) | 2025.04.16 |
[AWS] CloudFormation의 DeletionPolicy 속성, 한 번에 이해하기 (0) | 2025.04.16 |