AWS CloudWatch
네임스페이스
네임스페이스는 CloudWatch 지표의 컨테이너입니다. 다른 네임스페이스의 지표는 서로 격리되어 있으므로 다른 애플리케이션의 지표가 실수로 동일한 통계로 집계되는 일은 없습니다.
기본 네임스페이스는 없습니다. CloudWatch에 게시하는 각 데이터 포인트의 네임스페이스를 지정해야 합니다. 사용자는 지표를 생성할 때 네임스페이스 이름을 지정할 수 있습니다. 이 이름은 유효한 XML 문자를 포함하고 있어야 하고 길이가 256자 미만이어야 합니다. 가능한 문자로는 영숫자 문자(0-9A-Za-z), 마침표(.), 하이픈(-), 밑줄(_), 슬래시(/), 해시(#), 콜론(:)이 있습니다.
지표
지표는 CloudWatch의 기본 개념입니다. 지표는 CloudWatch에 게시된 시간 순서별 데이터 요소 집합을 나타냅니다. 지표는 모니터링할 변수로, 데이터 요소는 시간에 따른 변수의 값을 나타내는 것으로 간주합니다. 예를 들어 특정 EC2 인스턴스의 CPU 사용량은 Amazon EC2가 제공하는 하나의 지표입니다. 데이터 요소 그 자체는 데이터를 수집하는 애플리케이션이나 비즈니스 활동에서 나올 수 있습니다.
기본적으로 많은 AWS 서비스에서 리소스(Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon RDS DB 인스턴스)에 대한 무료 지표를 제공합니다. 또한 유료로 Amazon EC2 인스턴스와 같은 일부 리소스에 대한 세부 모니터링을 사용하거나 자체 애플리케이션 지표를 게시할 수도 있습니다. 사용자 지정 지표의 경우 원하는 순서와 속도로 데이터 요소를 추가할 수 있습니다. 이러한 데이터 요소에 대한 통계를 정렬된 시계열 집합으로 검색할 수 있습니다.
지표는 생성된 리전에만 존재합니다. 지표는 삭제가 불가능하지만, 지표에 새 데이터가 게시되지 않을 경우 15개월 후에 자동으로 만료됩니다. 15개월이 지난 데이터 요소는 순서대로 만료됩니다. 새로운 데이터 요소가 들어오면 15개월이 지난 데이터가 삭제됩니다.
타임스탬프
각 지표 데이터 요소에는 타임스탬프가 연결되어 있어야 하며 타임스탬프는 최대 2주 전이고 최대 2시간 빠를 수 있습니다. 타임스탬프를 제공하지 않으면 CloudWatch는 데이터 요소를 수신한 시간에 따라 자동으로 타임스탬프를 생성합니다.
CloudWatch 경보는 UTC의 현재 시간을 기반으로 지표를 확인합니다. 현재 UTC 시간이 아닌 타임스탬프와 함께 사용자 지정 지표를 CloudWatch에 전송하면 경보에 데이터 부족(insufficient Data) 상태가 표시되거나 경보가 지연될 수 있습니다.
지표 보존 기간
CloudWatch는 지표 데이터를 다음과 같이 유지합니다.
- 기간이
60초 미만으로 설정된 데이터 요소들은3시간 동안사용이 가능합니다. 이러한 데이터 요소는 고분해능 사용자 지정 지표입니다.- 기간이
60초로 설정된 데이터 요소들은15일 동안사용이 가능- 기간이
300초(5분)로 설정된 데이터 요소들은63일 동안사용이 가능- 기간이
3600초(1시간)로 설정된 데이터 요소들은455일(15개월)동안 사용이 가능
- 표준 분해능 - 1분 세분화 데이터
- 고분해능 - 1초 세분화 데이터
고분해능 지표는 애플리케이션의 단기(1분 미만)활동을 보다 즉각적으로 관찰할 수 있게 해줍니다. 사용자 지정 지표에 대해 PutMetricData를 호출할 때마다 요금이 부과되며, 따라서 고분해능 지표에 대해 PutMetricData를 자주 호출할수록 요금이 증가합니다. 고분해능 지표에 대해 경보를 설정할 경우 고분해능 경보를 10초 또는 30초 기간으로 지정하거나 60초의 배수 기간으로 정기 경보를 설정할 수 있습니다. 10초 또는 30초 기간의 고분해능 경보는 요금이 더 비쌉니다.
AWS CloudWatch 기본 모니터링 및 세부 모니터링
CloudWatch는 기본 모니터링과 세부 모니터링이라는 두 가지 모니터링 범주를 제공합니다. 다수의 AWS 서비스는 고객에게 무료로 CloudWatch에 기본 지표 세트를 게시하여 기본 모니터링을 제공합니다. 기본적으로 AWS 서비스 중 하나를 사용하기 시작할 때 기본 모니터링이 자동으로 활성화됩니다.
세부 모니터링은 일부 서비스에서만 제공됩니다. 또한 요금이 부과됩니다. AWS 서비스에 사용하려면 활성화하기를 선택해야 합니다. 자세한 모니터링 옵션은 서비스마다 다른데 예를 들어, Amazon EC2 세부 모니터링은 Amazon EC2 기본 모니터링에 사용되는 5분 간격 대신 1분 간격으로 게시되는 더 빈번한 지표를 제공합니다. Apache Kafka에 대한 Amazon S3 및 Amazon 관리형 스트리밍에 대한 세부 모니터링은 더 세밀한 지표를 의미합니다.
다른 AWS 서비스, 상세한 모니터링도 각기 다른 이름을 가지고 있는데 예를 들어, Amazon EC2에서는 세부 모니터링이라고 하며 AWS Elastic Beanstalk에서는 이를 향상된 모니터링이라고 하며, Amazon S3에서는 이를 요청 지표라고 합니다.
Amazon EC2에 대한 세부 모니터링을 사용하면 Amazon EC2 리소스를 보다 효율적으로 관리할 수 있으므로 추세를 파악하고 조치를 더 빠르게 수행할 수 있습니다. 운영 문제를 신속하게 확인하기 위해 Amazon S3 요청 지표를 1분 간격으로 사용할 수 있습니다.
AWS Config 규칙
규칙 페이지에 표시되는 초기 AWS 관리형 규칙을 계정에 추가할 수 있습니다. 설정을 마치면 AWS Config는 사용자가 선택한 규칙에 따라 AWS 리소스를 평가합니다. 설정 후 규칙을 업데이트하거나 관리형 규칙을 추가로 만들 수 있습니다.
AWS Config 규칙을 사용하여 비준수 리소스 자동 개선
AWS Config에는 AWS Config 규칙을 사용한 자동 개선 기능이 포함됩니다. 자동 개선 기능을 활용하면 개선 조치를 AWS Config 규칙과 연결하고 이를 자동으로 실행하도록 선택하여 수동으로 개입하지 않고도 비준수 리소스를 해결할 수 있으며, 이를 통해 이러한 리소스를 개선하는 데 소요 되는 시간을 절감할 수 있습니다.
개선 조치는 AWS Config 콘솔 또는 API를 통해 손쉽게 설정할 수 있습니다. 미리 채워진 목록에서 연결할 개선 조치를 선택하거나 AWS Systems Manager Automation 문서를 사용하여 자체적으로 사용자 지정 개선 조치를 생성할 수 있습니다. 수동 또는 자동 개선을 선택할 수 있으며 개선조치와 관련된 파라미터를 추가로 설정할 수도 있습니다.
AWS Config는 AWS 리소스 구성을 측정, 감사 및 평가할 수 있는 서비스입니다. Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고, 원하는 구성을 기준으로 기록된 구성을 자동으로 평가해 줍니다. Config를 사용하면 AWS 리소스 간 구성 및 관계 변화를 검토하고, 자세한 리소스 구성 기록을 분석하고, 내부 지침에 지정되어 있는 구성을 기준으로 전반적인 규정 준수 여부를 확인할 수 있습니다. 이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화할 수 있습니다.
AWS Config 규칙을 사용한 자동 개선은
미국 동부(오하이오),미국 동부(버지니아 북부),미국 서부(캘리포니아 북부),미국 서부(오레곤),아시아 태평양(뭄바이),아시아 태평양(서울),아시아 태평양(싱가포르),아시아 태평양(시드니),아시아 태평양(도쿄),캐나다(중부),EU(프랑크푸르트),EU(아일랜드),EU(런던),EU(파리),EU(스톡홀름),남아메리카(상파울루)및AWS GovCloud(US)지역의 고객이 사용할 수 있습니다.
CloudWatch vs CloudTrail vs Config
CloudWatch
- 지표, CPU, 네트워크 등의 성능 모니터링과 대시보드를 만드는 데 사용
- 이벤트와 알림을 수신
- 로그 집계 및 분석 도구 사용
CloudTrail
- 누구에 의한 호출이든 계정 내에서 만든 API에 대한 모든 호출을 기록
- 특정 리소스에 대한 추적 정의
- 글로벌 서비스
Config
- 구성 변경을 기록
- 규정 준수 규칙에 따라 리소스 평가
- 변경과 규정 준수에 대한 타임라인
For an Elastic Load Balancer
CloudWatch
- CloudWatch로 들어오는 연결 수 모니터링
- 오류 코드 수를 시간 흐름에 따라 비율로 시각화
- 로드 밸런서의 성능을 볼 수 있는 대시보드 생성
Config
- 로드 밸런서에 대한 보안 그룹 추적
- 로드 밸런서에 대한 구성 변경 추적
- SSL 인증서가 로드 밸런서에 항상 할당되어 있어야 한다는 규칙을 만들어 암호화되지 않은 트래픽이 로드 밸런서에 접근하는 것을 거부
CloudTrail
- 누가 API를 호출하여 로드 밸런서를 변경했는지 추적
- 한 쌍의 EC2 인스턴스가 있으며, 이들의 표준 CloudWatch 지표가 매 1분마다 수거되도록 하려 합니다. 어떻게 해야 할까요 ?
- A. CloudWatch 사용자 지정 지표 활성화하기
- B. 고분해능 활성화
- C. 기본 모니터링 활성화
D. 세부 모니터링 활성화
✅ 이는 유료 기능으로, 기본적으로 비활성화되어 있습니다. 활성화된 경우, EC2 인스턴스 지표는 1분마다 사용이 가능합니다.
- 고분해능 사용자 지정 지표는 최소 해상도로 ( )를 가질 수 있습니다.
A. 1초- B. 10초
- C. 30초
- D. 1분
- 데이터베이스 로그를 CloudWatch로 푸시하도록 구성 되어 있는 RDS DB 인스턴스가 있습니다. 로그에서 오류가 발견될 경우에는 CloudWatch 경보를 생성하게 만드려고 합니다. 어떻게 해야 할까요 ?
- A. 1시간 마다 AWS Lambda를 트리거하도록 예약된 CloudWatch 이벤트를 생성하고, 로그를 스캔해 SNS 주제를 통해 알리기
B. 키워드 Error에 대한 로그를 필터링하는 CloudWatch 로그 지표 필터를 생성한 후, 지표 필터를 기반으로 CloudWatch 경보 생성- C. 데이터베이스 로그의 오류를 모니터링하는 AWS 구성 규칙을 생성하고 SNS 주제를 통해 알리기
- 최소 용량을 2로 구성한 오토 스케일링 그룹이 관리하고 있고, 한 세트의 EC2 인스턴스에서 호스팅하고 있는 애플리케이션이 있습니다. 또한 CPU 사용률이 60%에 이르면 ASG를 스케일인 하도록 구성된 CloudWatch 경보도 생성해 둔 상태입니다. 현재 이 애플리케이션은 2개의 EC2 인스턴스 상에 실행되고 있으며, 트래픽의 수준은 낮고, CloudWatch 경보는 ALARM 상태에 있습니다. 이런 경우, 무슨 일이 일어나게 될까요 ?
- A. 하나의 EC2 인스턴스가 종료되고 ASG의 원하는 용량 및 최소 용량이 1로 설정됨
B. CloudWatch 경보는 계속 ALARM 상태로 유지되지만, ASG의 EC2 인스턴스 수는 절대 감소하지 않음- C. CloudWatch 경보가 ASG로부터 분리될 것
- D. CloudWatch 경보가 OK 상태로 변화함
✅ ASG의 EC2 인스턴스 수는 이론상 CloudWatch 경보가 EC2 인스턴스 중단을 트리거한다고 해도, 최소 용량 이하로 감소할 수 없습니다.
- CloudWatch의 EC2 인스턴스 메모리 사용은 어떻게 모니터링할 수 있나요 ?
- A. EC2 세부 모니터링 활성화
- B. EC2 인스턴스는 기본적으로 메모리 사용량을 CloudWatch로 푸시함
C. 통합 CloudWatch 에이전트를 사용해 메모리 사용량을 사용자 지정 지표로 CloudWatch에 푸시
- 고분해능 사용자 지정 지표에 설정된 CloudWatch 경보는 ( )마다 트리거될 수 있습니다.
- A. 1초
B. 10초- C. 30초
- D. 1분
✅ 고분해능 지표를 설정했다면 1초, 5초, 10초, 30초 또는 60초의 배수 기간으로 지표를 읽고 검색할 수 있습니다.
- 표준 분해능: 1분 세분화 데이터
- 고분해능: 1초 세분화 데이터
- 구성을 변경했고, 이 변경 사항이 애플리케이션의 성능에 어떤 영향을 미쳤는지 평가하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?
A. Amazon CloudWatch- B. AWS CloudTrail
✅ Amazon CloudWatch는 모니터링 서비스로 애플리케이션을 모니터링할 수 있게 해줍니다. 이는 시스템의 성능 변경에 따라 반응하며, 리소스 활용을 최적화하며 운영 상태를 통합적으로 볼 수 있도록 해줍니다. CloudWatch는 애플리케이션의 성능과 지표를 모니터링하는 데에 사용됩니다.
- 지난 주, 누군가가 AWS 계정 내에서 민감한 데이터를 포함한 중요 데이터베이스를 호스팅하고 있던 EC2 인스턴스를 중단했습니다. 이런 경우, 누가 언제 이런 작업을 했는지 알아내려면 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?
- A. CloudWatch 지표
- B. CloudWatch 경보
- C. CloudWatch 이벤트
D. AWS CloudTrail
✅ AWS CloudTrail은 AWS 인프라 간의 작업과 관련된 계정 활동을 로그하고 지속적인 모니터링 및 유지를 가능하게 해줍니다. CloudTrail은 AWS 계정 활동 내역을 제공해 주며, AWS 관리 콘솔, AWS SDK, AWS CLI에서 생성한 API 호출을 감사합니다. 따라서 여기에 EC2 인스턴스 중단 API 호출이 나타납니다. CloudTrail은 AWS 계정 내의 비정상적인 활동을 감지하는 데에 사용할 수 있습니다.
- CloudTrail이 전체 AWS 리전의 AWS 계정에 활성화되어 있습니다. AWS 계정 내의 비정상적인 활동을 감지하려면 다음 중 어떤 기능을 사용해야 할까요 ?
- A. CloudTrail Data Events
B. CloudTrail Insights- C. CloudTrail Management Events
- 팀원들 중 하나가 중요한 데이터를 포함하고 있는 EC2 인스턴스를 4개월 전에 중단했습니다. 누가 이런 작업을 했는지를 알지 못하는 관계로 CloudTrail을 사용해 이 기간 동안의 모든 API 호출을 검토하려 합니다. CloudTrail은 이미 설정되어 있으며, S3 버킷으로 로그를 보내도록 구성되어 있습니다. 누가 이런 작업을 했는지 알아내기 위해서는 어떻게 해야 할까요 ?
- A. CloudTrail 콘솔의 CloudTrail 이벤트 내역을 활용
B. Amazon Athena로 S3 버킷 내의 CloudTrail 로그를 분석
✅ CloudTrail 콘솔은 지난 90일 간 보고된 API 활동을 확인하려는 경우 활용할 수 있습니다. 90일보다 오래된 이벤트의 경우에는 Athena를 사용해 S3 버킷 내에 저장된 CloudTrail 로그를 분석합니다.
- 84번 포트가 취약한 것으로 알려진 OS를 지닌 EC2 인스턴스 플릿에서 웹사이트를 실행하고 있습니다. 84번 포트가 노출된 경우에는 EC2 인스턴스를 지속적으로 모니터링하려 합니다. 이 경우, 어떻게 해야 할까요 ?
- A. CloudWatch 지표 설정
- B. CloudTrail 추적 설정
C. 구성 규칙 설정- D. CloudWatch 이벤트가 Lambda 함수를 트리거해 EC2 인스턴스를 스캔하도록 만들기
- 리소스 구성의 규정 준수를 시간의 경과에 따라 평가하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?
A. AWS Config- B. Amazon CloudWatch
- C. AWS CloudTrail
- 누군가가 리소스의 구성을 변경하여, 규정을 위반하게 만들었습니다. 누가 이런 변경 사항을 만들었는지 알아내기 위해서는 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?
- A. Amazon CloudWatch
B. AWS CloudTrail- C. AWS Config
- EC2 인스턴스에 대한 무제한 SSH 액세스가 있는 경우에는 보안 그룹을 모니터링할 수 있도록 AWS Config를 활성화했습니다. 보안 그룹을 올바른 상태로 자동으로 재구성하기 위해서는 다음 AWS Config 기능 중 어떤 것을 사용해야 할까요 ?
A. AWS Config 수정- B. AWS Config 규칙
- C. AWS Config
✅ AWS Config 규칙은 수정 작업을 지원하지 않습니다.
- 제한된 SSH 액세스를 갖고 있으며, 강화된 보안 그룹을 포함하고 있는 한 세트의 EC2 인스턴스에 중요한 웹사이트를 실행하고 있습니다. 여러분은 AWS 리전 내에 AWS Config를 활성화했고, 누군가가 EC2 인스턴스의 보안 그룹에 변경을 가한 경우 이메일을 통해 알림을 받으려 합니다. 이 경우, 다음 중 어떤 AWS Config 기능을 사용해야 할까요 ?
- A. AWS Config 수정
- B. AWS Config 규칙
C. AWS Config
