# Amazon CloudWatch 경보 사용
지표를 감시해 알림을 보내거나 임곗값을 위반한 경우 모니터링 중인 리소스를 자동으로 변경하는 경보를 생성할 수 있습니다. 예를 들면, Amazon EC2 인스턴스의 CPU 사용량과 디스크 읽기 및 쓰기를 모니터링한 다음에 증가한 로드를 처리하려면 추가 인스턴스를 시작해야 하는지 여부를 해당 데이터로 결정할 수 있습니다. 또한 이러한 데이터를 사용하여 잘 사용되지 않는 인스턴스를 중지할 수도 있습니다.
Amazon CloudWatch에서 *지표*와 *복합* 경보를 모두 생성할 수 있습니다.
AWS 리소스 태그를 사용하여 지표를 필터링하고 그룹화하는 Metrics Insights 쿼리에 대한 경보를 생성할 수 있습니다. 태그를 경보와 함께 사용하려면 [https://console.aws.amazon.com/connect/](https://console.aws.amazon.com/connect/)에서 **설정**을 선택합니다. **CloudWatch 설정** 페이지의 **원격 분석에서 리소스 태그 활성화**에서 **활성화**를 선택합니다. 태그 지정 전략에 따라 자동으로 조정되는 상황 인식 모니터링을 수행하려면 AWS 리소스 태그를 사용하여 Metrics Insights 쿼리에 대한 경보를 생성합니다. 이렇게 하면 특정 애플리케이션 또는 환경에 대한 태그가 지정된 모든 리소스를 모니터링할 수 있습니다.
+ *지표 경보*는 단일 CloudWatch 지표를 감시하거나 CloudWatch 지표를 기반으로 하는 수학 표현식의 결과를 감시합니다. 이러한 경보는 여러 기간에 대해 지정된 임곗값과 지표 또는 표현식의 값 비교하여 하나 이상의 작업을 수행합니다. 작업은 Amazon SNS 주제에 알림을 전송하거나, Amazon EC2 작업 또는 Amazon EC2 Auto Scaling 작업을 수행하거나, CloudWatch 조사에서 조사를 시작하거나, Systems Manager에서 OpsItem 또는 인시던트를 생성하는 것일 수 있습니다.
+ *PromQL 경보*는 PromQL(Prometheus Query Language) 인스턴트 쿼리를 사용하여 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 모니터링합니다. 경보는 개별 위반 시계열을 기고자로 추적하고 기간 기반 보류 및 복구 기간을 사용하여 상태 전환을 제어합니다. 자세한 내용은 [PromQL 경보](alarm-promql.md) 섹션을 참조하세요.
+ *복합 경보*에는 사용자가 생성한 다른 경보의 경보 상태를 고려하는 규칙 표현식이 포함됩니다. 복합 경보는 규칙의 모든 조건이 충족되는 경우에만 ALARM 상태로 전환됩니다. 복합 경보의 규칙 표현식에 지정된 경보에는 지표 경보 및 기타 복합 경보가 포함될 수 있습니다.
복합 경보를 사용하면 경보 노이즈를 줄일 수 있습니다. 여러 지표 경보를 생성할 수 있으며, 복합 경보를 생성하고 복합 경보에 대해서만 경보를 설정할 수도 있습니다. 예를 들어 모든 기본 지표 경보가 ALARM 상태인 경우에만 복합 경보가 ALARM 상태로 전환되도록 할 수 있습니다.
복합 경보는 경보 상태가 변경될 때 Amazon SNS 알림을 전송할 수 있고, 경보가 ALARM 상태가 될 때 조사, Systems Manager OpsItem 또는 인시던트를 생성할 수 있지만, EC2 작업 또는 오토 스케일링 작업을 수행할 수는 없습니다.
**참고**
AWS 계정에서 원하는 만큼 경보를 생성할 수 있습니다.
대시보드에 경보를 추가할 수 있으므로 여러 리전에 걸쳐 AWS 리소스 및 애플리케이션에 대한 경보를 모니터링하고 수신할 수 있습니다. 대시보드에 경보를 추가하면 경보가 `INSUFFICIENT_DATA` 상태인 경우 회색으로, `ALARM` 상태인 경우 빨간색으로 바뀝니다. 경보가 `OK` 상태인 경우 색상이 표시되지 않습니다.
CloudWatch 콘솔 탐색 창의 *즐겨찾기 및 최근 항목(Favorites and recents)* 옵션에서 최근에 방문한 경보를 즐겨찾기에 추가할 수도 있습니다. *즐겨찾기 및 최근 항목(Favorites and recents)* 옵션에는 즐겨 찾는 경보 및 최근에 방문한 경보에 대한 열이 있습니다.
경보는 경보 상태가 변경될 때만 작업을 호출합니다. 단, Auto Scaling 작업이 있는 경보는 예외입니다. Auto Scaling 작업의 경우 경보는 분당 한 번씩 계속해서 경보가 새 상태로 유지되는 작업을 호출합니다.
경보는 동일한 계정의 지표를 감시할 수 있습니다. CloudWatch 콘솔에서 교차 계정 기능을 사용 설정한 경우 다른 AWS 계정의 지표를 감시하는 경보를 생성할 수도 있습니다. 교차 계정 복합 경보 생성은 지원되지 않습니다. `ANOMALY_DETECTION_BAND`, `INSIGHT_RULE` 및 `SERVICE_QUOTA` 함수가 교차 계정 경보에 대해 지원되지 않는다는 점을 제외하고 수학 표현식을 사용하는 교차 계정 경보 생성이 지원됩니다.
**참고**
CloudWatch는 지정된 작업을 테스트하거나 검증하지 않으며 존재하지 않은 작업을 호출하려는 시도로 인해 발생하는 Amazon EC2 Auto Scaling 또는 Amazon SNS 오류를 감지하지도 않습니다. 경보 작업이 존재하는지 확인하십시오.
# 개념
CloudWatch 경보는 지표를 모니터링하고 임계치 위반 시 작업을 트리거합니다. 효과적인 모니터링을 위해서는 경보가 데이터를 평가하고 조건에 대응하는 방법을 이해해야 합니다.
**Topics**
+ [경보 데이터 쿼리](alarm-data-queries.md)
+ [경보 평가](alarm-evaluation.md)
+ [PromQL 경보](alarm-promql.md)
+ [복합 경보](alarm-combining.md)
+ [경보 작업](alarm-actions.md)
+ [경보 음소거 규칙](alarm-mute-rules.md)
+ [Limits](alarm-limits.md)
# 경보 데이터 쿼리
CloudWatch 경보는 다양한 데이터 소스를 모니터링할 수 있습니다. 모니터링 요구 사항에 따라 적절한 쿼리 유형을 선택합니다.
## Metrics
단일 CloudWatch 지표를 모니터링합니다. 리소스 성능을 추적하기 위한 가장 일반적인 경보 유형입니다. 지표에 대한 자세한 내용은 [CloudWatch 지표 개념](cloudwatch_concepts.md)을 참조하세요.
자세한 내용은 [정적 임곗값을 기반으로 CloudWatch 경보 생성](ConsoleAlarms.md) 섹션을 참조하세요.
## 지표 수식
하나 이상의 CloudWatch 지표를 기반으로 하는 수학 표현식의 결과에 대한 경보를 설정할 수 있습니다. 경보에 사용되는 수학 표현식에는 지표를 10개까지 포함할 수 있습니다. 각 지표의 기간은 동일해야 합니다.
수학 표현식을 기반으로 하는 경보의 경우 누락된 데이터 포인트를 처리하는 방법을 CloudWatch에 지정할 수 있습니다. 이 경우 수학 표현식이 해당 데이터 포인트에 대한 값을 반환하지 않으면 데이터 포인트가 누락된 것으로 간주됩니다.
수학 표현식을 기반으로 하는 경보는 Amazon EC2 작업을 수행할 수 없습니다.
지표 수학 표현식 및 구문에 대한 자세한 내용은 [CloudWatch 지표에 수학 표현식 사용](using-metric-math.md) 단원을 참조하세요.
자세한 내용은 [지표 수학 표현식을 기반으로 CloudWatch 경보 생성](Create-alarm-on-metric-math-expression.md) 섹션을 참조하세요.
## 지표 인사이트
CloudWatch Metrics Insights 쿼리는 SQL과 유사한 구문을 사용하여 대규모로 지표를 쿼리하는 데 도움이 됩니다. 여러 시계열을 반환하는 Metrics Insights 쿼리에서 경보를 생성할 수 있습니다. 이 기능은 모니터링 옵션을 크게 확장합니다. Metrics Insights 쿼리를 기반으로 경보를 생성하면 모니터링되는 그룹에 리소스가 추가되거나 제거될 때 경보가 자동으로 조정됩니다. 경보를 한 번 생성합니다. 그러면 해당 지표를 사용할 수 있게 되면 쿼리 정의 및 필터와 일치하는 모든 리소스에서 경보 모니터링 범위를 조인합니다. 다중 시계열 쿼리의 경우 반환된 각 시계열이 경보의 기여자가 되어 보다 세분화된 동적 모니터링을 지원합니다.
다음은 CloudWatch Metrics Insights 경보의 두 가지 주요 사용 사례입니다.
+ 이상 탐지 및 집계 모니터링
단일 집계 시계열을 반환하는 Metrics Insights 쿼리에서 경보를 생성합니다. 이 접근 방식은 인프라 또는 애플리케이션 전반에서 집계된 지표를 모니터링하는 동적 경보에 적합합니다. 예를 들어 모든 인스턴스에서 최대 CPU 사용률을 모니터링할 수 있으며, 플릿 규모를 조정할 때 경보가 자동으로 조정됩니다.
집계 모니터링 경보를 생성하려면 다음 쿼리 구조를 사용합니다.
```
SELECT FUNCTION(metricName)
FROM SCHEMA(...)
WHERE condition;
```
+ 리소스별 플릿 모니터링
여러 시계열을 모니터링하는 경보를 생성합니다. 이때 각 시계열은 자체 상태의 기여자 역할을 합니다. 기여자가 ALARM 상태가 되면 경보가 활성화되어 리소스별 작업이 트리거됩니다. 예를 들어 여러 RDS 인스턴스의 데이터베이스 연결을 모니터링하여 연결 거부를 방지합니다.
여러 시계열을 모니터링하려면 다음 쿼리 구조를 사용합니다.
```
SELECT AVG(DatabaseConnections)
FROM AWS/RDS
WHERE condition
GROUP BY DBInstanceIdentifier
ORDER BY AVG() DESC;
```
다중 시계열 경보를 생성하는 경우 쿼리에 두 개의 중요한 절을 포함해야 합니다.
+ 시계열을 구성하는 방법을 정의하고 쿼리에서 생성할 시계열 수를 결정하는 `GROUP BY` 절.
+ 지표의 결정적 정렬을 설정하여 경보가 가장 중요한 신호를 먼저 평가할 수 있도록 하는 `ORDER BY` 절.
이러한 절은 적절한 경보 평가를 위해 필수적입니다. `GROUP BY` 절은 데이터를 별도의 시계열로 분할(예: 인스턴스 ID를 기준으로)하는 반면, `ORDER BY` 절은 경보 평가 중에 이러한 시계열의 일관되고 우선순위가 지정된 처리를 보장합니다.
다중 시계열 경보를 생성하는 방법에 대한 자세한 내용은 [다중 시계열 Metrics Insights 쿼리를 기반으로 경보 생성](multi-time-series-alarm.md) 섹션을 참조하세요.
## 로그 그룹 지표 필터
로그 그룹 지표 필터를 기반으로 경보를 생성할 수 있습니다. 지표 필터를 사용하면 데이터가 CloudWatch로 전송될 때 로그 데이터에서 용어와 패턴을 찾을 수 있습니다. 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [필터를 사용하여 로그 이벤트에서 지표 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)을 참조하세요.
로그 그룹 지표 필터를 기반으로 경보를 생성하는 방법에 대한 자세한 내용은 [로그에 대한 경보](Alarm-On-Logs.md) 섹션을 참조하세요.
## PromQL
PromQL(Prometheus Query Language) 인스턴트 쿼리를 사용하여 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 모니터링하는 경보를 생성할 수 있습니다.
PromQL 경보의 작동 방식에 대한 자세한 내용은 [PromQL 경보](alarm-promql.md) 섹션을 참조하세요.
PromQL 경보를 생성하는 방법에 대한 자세한 내용은 [PromQL 쿼리를 사용하여 경보 생성](Create_PromQL_Alarm.md) 섹션을 참조하세요.
## 외부 데이터 소스
CloudWatch에 없는 데이터 소스의 지표를 감시하는 경보를 생성할 수 있습니다. 이러한 다른 데이터 소스에 대한 연결을 생성하는 방법에 대한 자세한 내용은 [다른 데이터 소스의 쿼리 지표](MultiDataSourceQuerying.md) 섹션을 참조하세요.
연결된 데이터 소스를 기반으로 경보를 생성하는 방법에 대한 자세한 내용은 [연결된 데이터 소스를 기반으로 경보 생성](Create_MultiSource_Alarm.md) 섹션을 참조하세요.
# 경보 평가
## 지표 경보 상태
지표 경보에는 다음과 같은 상태가 있을 수 있습니다.
+ `OK` – 지표 또는 표현식이 정의된 임곗값 내에 있습니다.
+ `ALARM` – 지표 또는 표현식이 정의된 임곗값을 벗어났습니다.
+ `INSUFFICIENT_DATA` – 경보가 방금 시작되었거나 지표를 사용할 수 없거나 지표에서 경보 상태를 결정하는 데 사용할 수 있는 데이터가 충분하지 않습니다.
## 경보 평가 상태
경보 상태 외에도 각 경보에는 경보 평가 프로세스에 대한 정보를 제공하는 평가 상태가 있습니다. 다음 상태가 나타날 수 있습니다.
+ `PARTIAL_DATA` - 할당량 제한으로 인해 사용 가능한 모든 데이터를 검색할 수 없음을 나타냅니다. 자세한 내용은 [부분 데이터 처리 방법](cloudwatch-metrics-insights-alarms-partial-data.md) 섹션을 참조하세요.
+ `EVALUATION_ERROR` - 검토 및 수정이 필요한 경보 설정의 구성 오류를 나타냅니다. 자세한 내용은 경보의 StateReason 필드를 참조하세요.
+ `EVALUATION_FAILURE` - 임시 CloudWatch 문제를 나타냅니다. 문제가 해결될 때까지 수동 모니터링을 사용하는 것이 좋습니다.
콘솔의 경보 세부 정보에서 또는 `describe-alarms` CLI 명령이나 `DescribeAlarms` API를 사용하여 평가 상태를 볼 수 있습니다.
## 경보 평가 설정
경보를 생성할 때 다음과 같은 세 가지 설정을 지정하여 CloudWatch가 경보 상태를 변경할 시기를 평가할 수 있도록 합니다.
+ **기간**은 경보에 대해 개별 데이터 포인트를 생성하기 위해 지표 또는 표현식을 평가하는 기간입니다. 초로 표시됩니다.
+ [**평가 기간(Evaluation Periods)**]은 경보 상태를 결정할 때 평가할 가장 최근의 기간 또는 데이터 요소의 수입니다.
+ **경보에 대한 데이터 요소(Datapoints to Alarm)**는 평가 기간 내에 경보가 `ALARM` 상태에 도달하게 만드는 위반 데이터 요소의 수입니다. 위반 데이터 포인트가 연속적일 필요는 없지만, **평가 기간(Evaluation Period)**과 동일한 마지막 데이터 포인트 수 이내여야 합니다.
1분 이상인 기간의 경우 경보는 1분마다 평가되며 평가는 **기간** 및 **평가 기간**에 정의된 기간을 기준으로 합니다. 예를 들어 **기간**이 5분(300초)이고 **평가 기간**이 1인 경우 5분이 끝날 때 1분에서 5분까지의 데이터를 기반으로 경보가 평가됩니다. 그런 다음 6분이 끝나면 2분에서 6분까지의 데이터를 기반으로 경보를 평가합니다.
경보 기간이 10초, 20초 또는 30초인 경우 경보는 10초마다 평가됩니다. 자세한 내용은 [고분해능 경보](#high-resolution-alarms) 섹션을 참조하세요.
평가 기간 수에 각 평가 기간의 길이를 곱한 값이 1일을 초과하는 경우 경보는 1시간마다 평가됩니다. 이러한 다일 경보를 평가하는 방법에 대한 자세한 내용은 [다일 경보 평가 예제](#evaluate-multiday-alarm) 섹션을 참조하세요.
다음 그림에서 지표 경보에 대한 경보 임곗값은 3개 단위로 설정됩니다. [**평가 기간(Evaluation Period)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 둘 다 3입니다. 즉, 가장 최근의 연속된 세 기간에서 기존 데이터 요소가 모두 임곗값을 초과하면 경보가 `ALARM` 상태가 됩니다. 그림에서는 기간 3에서 6 사이에 이러한 일이 발생합니다. 기간 6에서는 값이 임곗값 아래로 떨어지므로 평가 대상 기간 중 하나가 위반 상태가 아닙니다. 따라서 경보 상태가 다시 `OK`로 변경됩니다. 9번째 기간에 다시 한 번 임곗값이 위반되지만, 오직 하나의 기간 동안에만 그렇습니다. 결과적으로 경보 상태는 `OK`로 남아 있습니다.
![\[경보 임곗값이 경보 트리거\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png)
[**평가 기간(Evaluation Period)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]를 다른 값으로 구성하는 경우 이는 ‘M out of N(N 중 M)’ 경보를 설정한 것입니다. **경보에 대한 데이터 포인트**는 ('M')이고 **평가 기간**은 ('N')입니다. 평가 간격은 평가 기간 수에 기간 길이를 곱한 값입니다. 예를 들어, 1분 기간으로 5개의 데이터 포인트 중 4개를 구성하는 경우 평가 간격은 5분입니다. 10분의 기간으로 3개의 데이터 포인트 중 3개를 구성하는 경우 평가 간격은 30분입니다.
**참고**
경보를 생성한 직후 데이터 요소가 누락되고 경보를 생성하기 전에 지표가 CloudWatch에 보고된 경우 CloudWatch는 경보를 평가할 때 경보가 생성되기 전부터 가장 최근의 데이터 요소를 검색합니다.
## 고분해능 경보
고분해능 지표에서 경보를 설정하는 경우 10초, 20초 또는 30초 기간의 고분해능 경보을 지정할 수 있습니다. 고분해능 경보는 요금이 더 비쌉니다. 고분해능 지표에 대한 자세한 내용은 [사용자 지정 지표 게시](publishingMetrics.md) 단원을 참조하세요.
## 다일 경보 평가 예제
각 평가 기간의 길이에 평가 기간 수를 곱한 값이 1일을 초과하는 경우 경보는 다일 경보입니다. 다일 경보는 시간당 한 번 평가됩니다. 다일 경보가 평가되면 CloudWatch는 평가 시 현재 시간의 :00분까지 지표만 고려합니다.
예를 들어 3일마다 10시에 실행되는 작업을 모니터링하는 경보를 가정합니다.
1. 10:02에 작업이 실패합니다.
1. 10:03에 경보가 평가되고 `OK` 상태를 유지합니다. 평가는 최대 10:00까지의 데이터만 고려하기 때문입니다.
1. 11:03에 경보는 11:00까지의 데이터를 고려하고 `ALARM` 상태로 전환합니다.
1. 11:43에 오류를 수정하고 이제 작업이 성공적으로 실행됩니다.
1. 12:03에 경보가 다시 평가되고 성공한 작업을 확인한 후 `OK` 상태로 돌아갑니다.
# CloudWatch 경보가 누락 데이터를 처리하는 방법 구성
때로 지표에 대해 예상되는 데이터 요소의 일부가 CloudWatch에 보고되지 않는 경우도 있습니다. 연결이 끊기거나 서버가 정지할 때, 설계에 따라 지표 보고 데이터가 간헐적으로만 전송될 때 이런 일이 일어날 수 있습니다.
CloudWatch를 사용하면 경보를 평가할 때 누락된 데이터 요소를 처리하는 방법을 지정할 수 있습니다. 이렇게 하면 모니터링 중인 데이터 유형에 적합한 경우에만 `ALARM` 상태가 되도록 경보를 구성할 수 있습니다. 누락된 데이터에 문제가 없는 경우의 거짓 긍정을 피할 수 있습니다.
각 경보가 항상 세 가지 상태 중 하나인 것과 마찬가지로 CloudWatch에 보고된 각각의 특정 데이터 요소는 다음과 같은 세 범주 중 하나에 속합니다.
+ 위반하지 않음(임곗값에서)
+ 위반(임곗값 위반)
+ 누락됨
각 경보에 대해 CloudWatch가 누락된 데이터 요소를 다음 중 하나로 처리하도록 지정할 수 있습니다.
+ `notBreaching` – 누락 데이터 요소를 ‘양호’하고 임곗값 내에 있는 것으로 처리합니다.
+ `breaching` - 누락 데이터 요소를 ‘불량’하고 임곗값을 위반한 것으로 처리합니다
+ `ignore` - 현재 경보 상태를 유지합니다.
+ `missing` - 경보 평가 범위의 모든 데이터 요소가 누락된 경우 경보를 INSUFFICIENT\$1DATA 상태로 전환합니다.
가장 좋은 선택은 지표 유형과 경보 용도에 따라 다릅니다. 예를 들어 데이터를 지속적으로 보고하는 지표를 사용하여 애플리케이션 롤백 경보를 생성하는 경우 누락된 데이터 포인트는 문제를 나타낼 수 있으므로 위반으로 처리하는 것이 좋습니다. 그러나 Amazon DynamoDB의 `ThrottledRequests`와 같이 오류가 발생할 때만 데이터 요소를 생성하는 지표의 경우 누락 데이터를 `notBreaching`으로 처리할 수 있습니다. 기본값은 `missing`입니다.
**중요**
Amazon EC2 지표에 구성된 경보는 누락된 지표 데이터 포인트가 있는 경우 일시적으로 INSUFICITENT\$1DATA 상태로 전환될 수 있습니다. 드물기는 하지만, Amazon EC2 인스턴스가 정상인 경우에도 지표 보고가 중단되면 이 문제가 발생할 수 있습니다. 중지, 종료, 재부팅 또는 복구 작업을 수행하도록 구성된 Amazon EC2 지표에 대한 경보의 경우 누락된 데이터를 `missing`으로 처리하고 경보 상태일 때만 해당 경보를 트리거하도록 경보를 구성하는 것이 좋습니다.
경보에 대한 최상의 옵션을 선택하면 불필요하고 오해의 소지가 있는 경보 조건 변경을 막을 수 있으며, 시스템 상태를 보다 정확하게 나타낼 수 있습니다.
**중요**
`AWS/DynamoDB` 네임스페이스의 지표를 평가하는 경보는 기본적으로 누락 데이터를 무시합니다. 경보가 누락 데이터를 처리하는 방법에 대해 다른 옵션을 선택하는 경우 이 옵션을 재정의할 수 있습니다. `AWS/DynamoDB` 메트릭에 누락된 데이터가 있는 경우 해당 지표를 평가하는 경보는 현재 상태를 유지합니다.
## 데이터가 누락되었을 때 경보 상태 평가 방법
경보가 상태 변경 여부를 평가할 때마다 CloudWatch는 [**평가 기간(Evaluation Periods)**]으로 지정된 수보다 더 높은 수의 데이터 요소를 검색하려고 합니다. 검색을 시도하는 데이터 포인트의 정확한 수는 경보 기간의 길이, 표준 해상도 또는 고해상도 지표에 토대를 두고 있는지 여부에 따라 달라집니다. 검색을 시도하는 데이터 포인트의 기간이 *평가 범위*입니다.
CloudWatch가 이러한 데이터 요소를 검색하면 다음과 같이 진행됩니다.
+ 평가 범위 내에 누락된 데이터 요소가 없다면 CloudWatch는 가장 최근에 수집된 데이터 요소를 기반으로 경보를 평가합니다. 평가된 데이터 요소의 수는 경보의 [**평가 기간(Evaluation Periods)**]과 같습니다. 평가 범위보다 훨씬 이전의 추가 데이터 요소는 필요하지 않으며 무시됩니다.
+ 평가 범위의 일부 데이터 요소가 누락되었지만 평가 범위에서 성공적으로 검색된 기존 데이터 요소의 총수가 경보의 [**평가 기간(Evaluation Periods)**] 이상인 경우 CloudWatch는 평가 범위보다 훨씬 이전의 필요한 추가 데이터 요소를 포함하여 성공적으로 검색된 가장 최근의 실제 데이터 요소를 기반으로 경보 상태를 평가합니다. 이 경우 누락 데이터 처리 방법에 대한 값이 필요 없으며, 이를 무시합니다.
+ 평가 범위의 일부 데이터 요소가 누락되었으며 검색된 실제 데이터 요소의 수가 경보의 [**평가 기간(Evaluation Periods)**] 수보다 적은 경우 CloudWatch는 누락 데이터 처리 방법에 대해 지정된 결과로 누락 데이터 요소를 채운 다음, 경보를 평가합니다. 그러나 평가 범위의 실제 데이터 요소는 모두 평가에 포함됩니다. CloudWatch는 되도록 몇 번만 누락 데이터 요소를 사용합니다.
**참고**
이 동작의 특정 사례에서는 CloudWatch 경보가 지표 흐름이 중지된 후 일정 기간 동안 마지막 데이터 요소 집합을 반복적으로 재평가할 수 있습니다. 이 재평가를 통해 지표 스트림 중지 직전에 상태가 변한 경우 경보가 상태를 변경하고 작업을 다시 실행할 수 있습니다. 이 동작을 완화하려면 더 짧은 기간을 사용하세요.
다음은 경보 평가 동작에 대한 예를 설명한 테이블입니다. 첫 번째 표에서 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]와 [**평가 기간(Evaluation Periods)**]은 둘 다 3입니다. CloudWatch는 가장 최근 3개의 데이터 요소 중 일부가 누락된 경우 경보를 평가할 때 가장 최근 데이터 요소 5개를 검색합니다. 5는 경보의 평가 범위입니다.
평가 범위가 5이므로 1열에는 가장 최근 데이터 요소 5개가 표시됩니다. 이러한 데이터 요소는 가장 최근 데이터 요소가 오른쪽에 표시됩니다. 0는 비위반 데이터 요소, X는 위반 데이터 요소, -는 누락 데이터 요소입니다.
2열은 필요한 데이터 요소 3개 중 누락된 개수를 표시합니다. 가장 최신 데이터 요소 5개가 평가되었더라도 경보 상태 평가를 위해 3개(**Evaluation Periods(평가 기간)**에 대한 설정)만 필요합니다. 2열의 데이터 요소 개수는 누락된 데이터 요소 처리 방법에 대한 설정을 사용하여 반드시 "채워야" 하는 데이터 요소의 수입니다.
3\$16열의 열 머리글은 누락 데이터를 처리하는 방법으로 가능한 값입니다. 이러한 열의 행에는 누락 데이터를 처리할 수 있는 이러한 각 방법에 대해 설정된 경보 상태가 표시됩니다.
| 데이터 포인트 | 채워야 하는 데이터 요소 수 | MISSING | IGNORE | 위반 | 위반하지 않음 |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `OK` | `OK` | `OK` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `OK` | `OK` |
| - - - - - | 3 | `INSUFFICIENT_DATA` | 현재 상태 유지 | `ALARM` | `OK` |
| 0 X X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| - - X - - | 2 | `ALARM` | 현재 상태 유지 | `ALARM` | `OK` |
앞 테이블의 2행에서는 누락 데이터를 위반으로 처리하는 경우에도 경보 상태는 `OK`로 유지됩니다. 기존 데이터 포인트 중 하나가 위반 상태가 아니며, 위반으로 처리되는 2개의 누락 데이터 포인트와 함께 이를 평가하기 때문입니다. 다음번에 이 경보를 평가할 때도 데이터가 여전히 누락된 경우 해당 비위반 데이터 요소가 더 이상 평가 범위에 있지 않기 때문에 경보는 `ALARM` 상태가 됩니다.
가장 최근의 데이터 요소 5개가 모두 누락된 세 번째 행은 누락 데이터 처리 방법에 대한 다양한 설정이 경보 상태에 어떻게 영향을 주는지를 보여 줍니다. 누락된 데이터 요소를 위반으로 간주하는 경우 경보는 ALARM 상태가 되지만, 비위반으로 간주하는 경우 경보는 OK 상태가 됩니다. 누락된 데이터 요소를 무시하면 경보는 누락 데이터 요소 이전의 현재 상태를 유지합니다. 그리고 누락된 데이터 요소를 단지 누락으로 간주한다면 경보에 평가를 수행하기에 충분한 최근 실제 데이터가 없으며 경보는 INSUFFICIENT\$1DATA 상태가 됩니다.
네 번째 행에서는 가장 최근의 데이터 요소 세 개가 위반이며 경보의 [**평가 기간(Evaluation Periods)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 둘 다 3으로 설정되어 있으므로 경보가 모든 경우에 `ALARM` 상태가 됩니다. 이 경우 누락된 데이터 요소는 무시되며 누락 데이터 평가 방법에 대한 설정은 필요하지 않습니다. 평가할 실제 데이터 요소가 3개 있기 때문입니다.
5행은 **‘조기 경보 상태’라고 하는 특별한 경우의 경보 평가를 나타냅니다. 자세한 내용은 [경보 상태 조기 전환 방지](#CloudWatch-alarms-avoiding-premature-transition) 단원을 참조하세요.
다음 테이블의 경우 **기간**은 다시 5분이며, **Datapoints to Alarm(경보에 대한 데이터 포인트)**는 2, **Evaluation Periods(평가 기간)**는 3입니다. 'N 중 M' 경보는 '3 중 2'입니다.
평가 범위는 5입니다. 이것은 검색되는 최근 데이터 포인트의 최대 수이며 일부 데이터 포인트가 누락된 경우 사용할 수 있습니다.
| 데이터 포인트 | 누락 데이터 포인트 가운데 수(\$1) | 누락 | IGNORE | 위반 | 위반하지 않음 |
| --- | --- | --- | --- | --- | --- |
| 0 - X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 0 X 0 X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` |
| 0 - X - - | 1 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - 0 | 2 | `OK` | `OK` | `ALARM` | `OK` |
| - - - - X | 2 | `ALARM` | 현재 상태 유지 | `ALARM` | `OK` |
1행과 2행에서는 가장 최근의 데이터 요소 3개 중 2개가 위반이므로 경보는 항상 ALARM 상태가 됩니다. 2행에서는 가장 최근 데이터 요소 3개가 누락되지 않았기 때문에 평가 범위에서 가장 오래된 두 데이터 요소가 필요하지 않으므로 오래된 이 두 데이터 요소는 무시됩니다.
3행과 4행에서는 누락된 데이터를 위반으로 처리하는 경우에만 경보가 ALARM 상태가 됩니다(여기서는 가장 최근의 누락 데이터 요소 두 개가 모두 위반으로 처리됨). 4행에서 위반으로 처리되는 이 두 누락 데이터 요소는 ALARM 상태를 트리거하는 데 필요한 위반 데이터 요소 두 개를 제공합니다.
5행은 **‘조기 경보 상태’라고 하는 특별한 경우의 경보 평가를 나타냅니다. 자세한 내용은 다음 섹션을 참조하세요.
### 경보 상태 조기 전환 방지
CloudWatch 경보 평가에는 데이터가 간헐적일 때 조기에 경보가 ALARM 상태가 되는 거짓 경보를 방지하기 위한 로직이 포함됩니다. 이전 단원에 있는 표의 5행에 표시된 예가 이 로직을 보여 줍니다. 해당 행과 다음 예에서 [**평가 기간(Evaluation Periods)**]은 3이고 평가 범위는 데이터 요소 5개입니다. [**경보에 대한 데이터 요소(Datapoints to Alarm)**]는 3입니다. 단, [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 2인 ‘M out of N(N 중 M)’ 예는 예외입니다.
경보의 가장 최근 데이터가 `- - - - X`이며 누락 데이터 요소 4개가 있고 가장 최근 데이터 요소로 위반 데이터 요소가 있다고 가정합니다. 다음 데이터 요소는 비위반일 수 있으므로 데이터가 `- - - - X` 또는 `- - - X -`이고 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 3일 경우 경보는 즉시 ALARM 상태가 되지 않습니다. 이렇게 하면 다음 데이터 요소가 비위반이고 데이터가 `- - - X O` 또는 `- - X - O`가 되도록 하는 경우 거짓 긍정이 방지됩니다.
그러나 마지막 몇 개의 데이터 요소가 `- - X - -`인 경우 누락된 데이터 요소를 누락으로 처리하더라도 경보는 ALARM 상태가 됩니다. 이는 [**평가 기간(Evaluation Periods)**] 동안 사용 가능한 가장 오래된 위반 데이터 요소 수가 최소한 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]의 값만큼 오래되고 더 최근의 다른 모든 데이터 요소가 위반 또는 누락인 경우 경보가 항상 ALARM 상태가 되도록 설계되었기 때문입니다. 이 경우 사용 가능한 데이터 요소의 총수가 M([**경보에 대한 데이터 요소(Datapoints to Alarm)**])보다 적더라도 경보는 ALARM 상태가 됩니다.
이 경보 로직은 ‘M out of N(N 중 M)’ 경보에도 적용됩니다. 평가 범위 동안 가장 오래된 위반 데이터 요소가 최소한 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]의 값만큼 오래되고 더 최근의 모든 데이터 요소가 위반 또는 누락인 경우 경보는 M([**경보에 대한 데이터 요소(Datapoints to Alarm)**]) 값에 상관없이 ALARM 상태가 됩니다.
## CloudWatch Metrics Insights 경보에서 누락 데이터
**단일 시계열로 집계되는 Metrics Insights 쿼리를 기반으로 하는 경보**
누락 데이터 시나리오와 경보 평가에 미치는 영향은 구성된 누락 데이터 처리 측면에서 표준 지표 경보와 동일합니다. [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](#alarms-and-missing-data) 섹션을 참조하세요.
**여러 시계열을 생성하는 Metrics Insights 쿼리를 기반으로 하는 경보**
Metrics Insights 경보에 대한 누락 데이터 시나리오는 다음과 같은 경우에 나타납니다.
+ 시계열 내 개별 데이터 포인트는 존재하지 않습니다.
+ 여러 시계열을 평가할 때 하나 이상의 시계열이 사라집니다.
+ 쿼리에서 시계열이 검색되지 않습니다.
누락 데이터 시나리오는 다음과 같은 방식으로 경보 평가에 영향을 미칩니다.
+ 시계열 평가를 위해 누락 데이터 처리 처리가 시계열 내 개별 데이터 포인트에 적용됩니다. 예를 들어 시계열에 대해 3개의 데이터 포인트를 쿼리했지만 1개만 수신된 경우 2개의 데이터 포인트는 구성된 누락 데이터 구성을 따릅니다.
+ 쿼리에서 시계열을 더 이상 검색하지 않으면 누락 데이터 처리에 상관없이 `OK`로 전환됩니다. 기고자 수준에서 `OK` 전환과 관련된 경보 작업이 실행되고 `StateReason`은 '이 기고자에 대한 데이터가 반환되지 않음" 메시지와 함께 앞서 언급한 기고자를 찾을 수 없음을 지정합니다. 경보의 상태는 쿼리에서 검색한 다른 기고자의 상태에 따라 달라집니다.
+ 경보 수준에서 쿼리가 빈 결과(시계열 없음)를 반환하면 경보는 설정된 누락 데이터 처리에 관계없이 `INSUFFICIENT_DATA`로 전환됩니다.
# 부분 데이터 처리 방법
## Metrics Insights 쿼리의 일부 데이터를 처리하는 방법
경보에 사용된 Metrics Insights 쿼리가 10,000여 개의 지표와 일치하는 경우 쿼리가 찾은 처음 10,000개의 지표를 기반으로 경보가 평가됩니다. 이는 부분 데이터에 대해 경보가 평가되고 있음을 의미합니다.
다음 방법을 사용하여 Metrics Insights 경보가 현재 부분 데이터를 기반으로 경보 상태를 평가하고 있는지 여부를 확인할 수 있습니다.
+ 콘솔에서 **Details**(세부 정보) 페이지를 보기 위해 경보를 선택하면 해당 페이지에 **Evaluation warning: Not evaluating all data**(평가 경고: 모든 데이터를 평가하지 않음) 메시지가 나타납니다.
+ [describe-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) AWS CLI 명령 또는 [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) API를 사용하면 `EvaluationState` 필드에 `PARTIAL_DATA` 값이 표시됩니다.
경보는 부분 데이터 상태가 될 때 Amazon EventBridge에 이벤트를 게시하므로 EventBridge 규칙을 생성하여 이러한 이벤트를 관찰할 수 있습니다. 이러한 이벤트에서 `evaluationState` 필드의 값은 `PARTIAL_DATA`입니다. 다음은 예입니다.
```
{
"version": "0",
"id": "12345678-3bf9-6a09-dc46-12345EXAMPLE",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-11-08T11:26:05Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name"
],
"detail": {
"alarmName": "my-alarm-name",
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}",
"timestamp": "2022-11-08T11:26:05.401+0000",
"evaluationState": "PARTIAL_DATA"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2022-11-08T11:25:51.227+0000"
},
"configuration": {
"metrics": [
{
"id": "m2",
"expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test",
"returnData": true,
"period": 60
}
]
}
}
}
```
경보에 대한 쿼리에 초기에 500여 개의 시계열을 반환하는 GROUP BY 문이 포함된 경우 쿼리가 찾은 처음 500개의 시계열을 기준으로 경보가 평가됩니다. 그러나 ORDER BY 절을 사용하면 쿼리가 찾은 모든 시계열이 정렬되고 ORDER BY 절에 따라 가장 높거나 가장 낮은 값을 가진 500개를 사용하여 경보가 평가됩니다.
## 다중 데이터 소스 경보의 부분 데이터 평가 방법
Lambda 함수가 부분 데이터를 반환하는 경우:
+ 경보는 반환되는 데이터 포인트에서 계속 평가됩니다.
+ 다음 방법을 사용하여 Lambda 함수의 경보가 현재 부분 데이터를 기반으로 경보 상태를 평가하고 있는지 여부를 확인할 수 있습니다.
+ 콘솔에서 경보를 선택하고 **세부 정보** 페이지를 선택합니다. **Evaluation warning: Not evaluating all data appears on that page** 메시지가 표시되면 부분 데이터에서 평가 중인 것입니다.
+ `describe-alarms` AWS CLI 명령 또는 DescribeAlarms API를 사용할 때 `EvaluationState` 필드에 `PARTIAL_DATA` 값이 표시되면 부분 데이터에서 평가 중인 것입니다.
+ 또한 경보는 부분 데이터 상태가 될 때 Amazon EventBridge에 이벤트를 게시합니다.
# 백분위수 기반 경보 및 데이터 샘플 부족
경보를 위한 통계로 백분위수를 설정하면 정확한 통계 평가를 위한 데이터가 충분하지 않을 때 어떻게 할 것인지 지정할 수 있습니다. 경보가 통계를 어떻게든 평가하도록 하고 가능하면 경보 상태를 변경하도록 선택할 수 있습니다. 또는 샘플 크기가 작을 때 경보가 지표를 무시하고 통계적으로 의미가 있을 정도로 충분한 데이터가 모일 때까지 기다렸다가 평가할 수 있습니다.
0.5(포함) \$1 1.00(제외) 범위 백분위수의 경우, 평가 기간 동안 10/(1-백분위수) 보다 적은 데이터 포인트가 있을 때 이 설정이 사용됩니다. 예를 들어 p99 백분위수에서 경보 샘플이 1,000개보다 적을 경우 이 설정이 사용됩니다. 0 \$1 0.5(제외) 범위 백분위수의 경우, 10/백분위수 보다 적은 백분위수가 있을 때 이 설정이 사용됩니다.
# PromQL 경보
PromQL 경보는 PromQL(Prometheus Query Language) 인스턴트 쿼리를 사용하여 지표를 모니터링합니다. 쿼리는 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 선택하고, 쿼리에서 반환되는 일치하는 모든 시계열은 위반으로 간주됩니다. 경보는 정기적인 간격으로 쿼리를 평가하고 각 위반 시계열을 *기고자*로 독립적으로 추적합니다.
OpenTelemetry를 사용하여 지표를 수집하는 방법에 대한 자세한 내용은 [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md) 섹션을 참조하세요.
## PromQL 경보 작동 방식
PromQL 경보는 `EvaluationInterval`에서 정의한 반복 일정에 따라 PromQL 인스턴트 쿼리를 평가합니다. 쿼리는 조건을 충족하는 시계열만 반환합니다. 반환된 각 시계열은 고유한 속성 집합으로 식별되는 *기고자*입니다.
경보는 기간 기반 상태 전환을 사용합니다.
+ 쿼리에 의해 기고자가 반환되면 *위반*으로 간주됩니다. 기고자가 `PendingPeriod`에 지정된 기간 동안 위반이 계속되면 기고자는 `ALARM` 상태로 전환됩니다.
+ 쿼리에 의한 기고자 반환이 중단되면 *복구*로 간주됩니다. 기고자가 `RecoveryPeriod`에 지정된 기간 동안 계속 부재하는 경우 기고자는 `OK` 상태로 전환됩니다.
하나 이상의 기고자가 보류 기간보다 오래 위반 상태가 되는 경우 경보는 `ALARM` 상태입니다. 모든 기고자가 복구되면 경보는 `OK` 상태로 돌아갑니다.
## PromQL 경보 구성
PromQL 경보는 다음 파라미터로 구성됩니다.
+ **PendingPeriod**는 기고자가 `ALARM` 상태로 전환되기 전에 기고자가 지속적으로 위반해야 하는 기간(초 단위)입니다. Prometheus 경보 규칙의 `for` 기간과 동일합니다.
+ **RecoveryPeriod**는 기고자가 `OK` 상태로 전환되기 전에 기고자가 위반을 중지해야 하는 기간(초 단위)입니다. Prometheus 경보 규칙의 `keep_firing_for` 기간과 동일합니다.
+ **EvaluationInterval**은 경보가 PromQL 쿼리를 평가하는 빈도(초 단위)입니다.
PromQL 경보를 생성하려면 [PromQL 쿼리를 사용하여 경보 생성](Create_PromQL_Alarm.md) 섹션을 참조하세요.
# 복합 경보
CloudWatch를 사용하면 여러 경보를 하나의 *복합 경보*로 결합하여 전체 애플리케이션 또는 리소스 그룹에 대해 요약되고 집계된 상태 지표를 생성할 수 있습니다. 복합 경보는 다른 경보의 상태를 모니터링하여 상태를 확인하는 경보입니다. 사용자는 Boolean 논리를 사용하여 모니터링되는 경보의 상태를 결합하는 규칙을 정의합니다.
복합 경보를 사용하면 집계된 수준에서만 조치를 실행하므로 경보 노이즈를 줄일 수 있습니다. 예를 들어, 웹 서버와 관련된 경보가 트리거되는 경우 복합 경보를 생성하어 웹 서버 팀에 알림을 보낼 수 있습니다. 이러한 경보 중 하나라도 ALARM 상태로 전환되면 복합 경보는 스스로 ALARM 상태가 되어 팀에 알림을 보냅니다. 웹 서버와 관련된 다른 경보가 ALARM 상태로 전환되더라도 복합 경보가 이미 기존 상황에 대해 알렸기 때문에 팀에 새 알림이 과도하게 오지 않습니다.
또한 복합 경보를 사용하여 복잡한 경보 조건을 생성하고 여러 조건이 충족될 때만 조치를 취할 수 있습니다. 예를 들어, CPU 경보와 메모리 경보를 결합하여 CPU와 메모리 경보가 모두 트리거된 경우에만 팀에 알리는 복합 경보를 생성하 수 있습니다.
**복합 경보 사용**
복합 경보를 사용하는 경우 두 가지 옵션이 있습니다.
+ 복합 경보 수준에서만 수행할 작업을 구성하고, 조치가 없는 기본 모니터링 경보를 만듭니다
+ 복합 경보 수준에서 다양한 작업의 조합을 구성합니다. 예를 들어, 복합 경보 작업에서는 문제가 광범위하게 발생하는 경우 다른 팀을 참여시킬 수 있습니다.
복합 경보는 다음과 같은 작업만 수행할 수 있습니다.
+ Amazon SNS 주제 알림
+ Lambda 함수 간접 호출
+ Systems Manager Ops Center에 OpsItem 생성
+ Systems Manager Incident Manager에 인시던트 생성
**참고**
복합 경보의 모든 기본 경보는 복합 경보와 동일한 계정 및 동일한 리전에 있어야 합니다. 그러나 CloudWatch 크로스 계정 관측성 모니터링 계정에서 복합 경보를 설정하면 기본 경보가 다른 소스 계정과 모니터링 계정 자체에서 지표를 관찰할 수 있습니다. 자세한 내용은 [CloudWatch 크로스 계정 관측성](CloudWatch-Unified-Cross-Account.md) 섹션을 참조하세요.
단일 복합 경보로 100개의 기본 경보를 모니터링할 수 있고, 150개의 복합 경보로 단일 기본 경보를 모니터링할 수 있습니다.
**규칙 표현식**
모든 복합 경보에는 규칙 표현식이 포함됩니다. 규칙 표현식은 모니터링하고 상태를 확인할 다른 경보를 복합 경보에 알려줍니다. 규칙 표현식은 지표 경보 및 복합 경보를 참조할 수 있습니다. 규칙 표현식에서 경보를 참조할 경우, 다음 세 가지 상태 중 경보가 어떤 상태로 전환될지를 결정하는 함수를 경보에 지정합니다.
+ 경보
경보가 ALARM 상태인 경우 ALARM ("alarm-name or alarm-ARN")이 TRUE입니다.
+ 정상
경보가 OK 상태인 경우 OK ("alarm-name or alarm-ARN")가 TRUE입니다.
+ INSUFFICIENT\$1DATA
명명된 경보가 INSUFFICIENT\$1DATA 상태인 경우 INSUFFICIENT\$1DATA ("alarm-name or alarm-ARN")가 TRUE입니다.
**참고**
TRUE는 항상 TRUE로 평가되고 FALSE는 항상 FALSE로 평가됩니다.
**경보 참조**
경보 이름 또는 ARN을 사용하여 경보를 참조할 경우, 규칙 구문에서는 경보 이름 또는 ARN을 따옴표(")로 묶거나 묶지 않아도 경보를 참조하도록 지원할 수 있습니다.
+ 따옴표 없이 지정한 경우 경보 이름 또는 ARN에 공백, 둥근 괄호 또는 쉼표를 포함해서는 안 됩니다.
+ 따옴표 내에 지정한 경우, 참조가 올바르게 해석되려면 큰따옴표(")가 *포함된* 경보 이름 또는 ARN은 큰따옴표(")를 백슬래시 이스케이프(\$1) 문자로 묶어야 합니다.
**구문**
여러 경보를 하나의 복합 경보로 결합하는 데 사용하는 표현식의 구문에서는 부울 로직과 함수를 사용합니다. 다음 표에서는 규칙 표현식에서 사용할 수 있는 연산자와 함수를 설명합니다.
| 연산자/함수 | 설명 |
| --- | --- |
| AND | 논리적 AND 연산자. 지정된 모든 조건이 TRUE일 때 TRUE를 반환합니다. |
| OR | 논리적 OR 연산자. 지정된 조건 중 하나 이상이 TRUE일 때 TRUE를 반환합니다. |
| NOT | 논리적 NOT 연산자. 지정된 조건이 FALSE일 때 TRUE를 반환합니다. |
| AT\$1LEAST | 지정된 경보의 최소 개수 또는 백분율이 원하는 상태일 때 TRUE를 반환하는 함수. 형식: AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN)) 여기서 M은 절대 수 또는 백분율(예: 50%)일 수 있으며 STATE\$1CONDITION은 ALARM, OK, INSUFFICIENT\$1DATA, NOT ALARM, NOT OK 또는 NOT INSUFFICIENT\$1DATA일 수 있습니다. |
괄호를 사용하여 조건을 그룹화하고 복잡한 표현식에서 평가 순서를 제어할 수 있습니다.
**예제 표현식**
요청 파라미터 `AlarmRule`은 논리 연산자 `AND`, `OR`, `NOT`, `AT_LEAST` 함수를 지원하므로 작업자가 여러 함수를 단일 표현식으로 결합할 수 있습니다. 다음 예제 표현식은 복합 경보의 기본 경보를 구성하는 방법을 보여줍니다.
+ `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)`
이 표현식은 `CPUUtilizationTooHigh`와 `DiskReadOpsTooHigh`가 `ALARM` 상태인 경우에만 복합 경보를 `ALARM` 상태로 전환하도록 지정합니다.
+ `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))`
표현식은 웹 서버 CPU 경보 4개 중 2개 이상이 `ALARM` 상태일 때 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 이렇게 하면 모든 리소스가 경보 상태에 있어야 하거나, 하나의 리소스만 경보 상태에 있어야 할 필요 없이 영향을 받은 리소스의 임곗값에 따라 알림을 트리거할 수 있습니다.
+ `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))`
표현식은 데이터베이스 연결 경보의 50% 이상이 `OK` 상태일 때 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 백분율을 사용하면 모니터링되는 경보를 추가하거나 제거할 때 규칙을 동적으로 조정할 수 있습니다.
+ `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)`
이 표현식은 `CPUUtilizationTooHigh`가 `ALARM` 상태이고 `DeploymentInProgress`가 `ALARM` 상태인 경우에만 복합 경보를 `ALARM` 상태로 전환하도록 지정합니다. 배포 기간 동안 경보 노이즈를 줄이는 복합 경보의 예입니다.
+ `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)`
표현식은 가용 영역 상태 경보 3개 중 2개 이상이 `ALARM` 상태이고 유지 관리 기간 경보가 `ALARM` 상태가 아닐 경우 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 이렇게 하면 더 복잡한 모니터링 시나리오를 위해 AT\$1LEAST 함수가 다른 논리 연산자와 결합됩니다.
# 경보 억제
복합 경보 작업 억제를 사용하면 경보 구성을 삭제하거나 수정하지 않고도 경보 작업을 일시적으로 비활성화할 수 있습니다. 이는 계획된 유지 관리, 배포 또는 알려진 문제를 조사할 때 유용합니다.
복합 경보 작업 억제 기능을 사용하면 경보를 억제 경보로 정의할 수 있습니다. 억제 경보는 복합 경보가 작업을 수행하지 않도록 합니다. 예를 들어 지원 리소스의 상태를 나타내는 억제 경보를 지정할 수 있습니다. 지원 리소스가 다운된 경우 억제 경보는 복합 경보가 알림을 보내지 못하게 합니다.
## 경보 억제를 사용해야 하는 경우
경보 억제가 유용한 일반적인 상황:
+ 애플리케이션의 유지 관리 기간
+ 애플리케이션 배포
+ 지속적인 인시던트 조사
+ 테스트 및 개발 활동
## 억제 경고 작동 방식
억제 경보는 복합 경보를 구성할 때 지정합니다. 모든 경보는 억제 경보로 작동할 수 있습니다. 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되면 복합 경보가 더 이상 작업을 수행하지 않습니다. 억제 경보의 상태가 `ALARM`에서 `OK`로 변경되면 복합 경보가 작업을 재개합니다.
복합 경보를 사용하면 여러 경보의 상태를 종합적으로 볼 수 있으며, 경보가 트리거될 것으로 예상되는 일반적인 상황이 있습니다. 예를 들어, 애플리케이션의 유지 관리 기간 중이거나 진행 중인 사고를 조사하는 경우입니다. 이러한 상황에서는 복합 경보의 동작을 억제하여 원치 않는 알림이나 새로운 인시던트 티켓이 생성되는 것을 방지할 수 있습니다
복합 경보 작업 억제 기능을 사용하면 경보를 억제 경보로 정의할 수 있습니다. 억제 경보는 복합 경보가 작업을 수행하지 않도록 합니다. 예를 들어 지원 리소스의 상태를 나타내는 억제 경보를 지정할 수 있습니다. 지원 리소스가 다운된 경우 억제 경보는 복합 경보가 알림을 보내지 못하게 합니다. 복합 경보 작업 억제 기능은 경보 노이즈를 줄이는 데 도움이 되므로, 경보를 관리하는 데 허비하는 시간을 줄이고 운영에 더 많은 시간을 할애할 수 있습니다.
억제 경보는 복합 경보를 구성할 때 지정합니다. 모든 경보는 억제 경보로 작동할 수 있습니다. 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되면 복합 경보가 더 이상 작업을 수행하지 않습니다. 억제 경보의 상태가 `ALARM`에서 `OK`로 변경되면 복합 경보가 작업을 재개합니다.
### `WaitPeriod` 및 `ExtensionPeriod`
억제 경보를 지정할 때 `WaitPeriod` 및 `ExtensionPeriod` 파라미터를 설정합니다. 이들 파라미터는 억제 경보의 상태가 바뀌는 동안 복합 경보가 예기치 않게 작업을 수행하는 것을 방지합니다. `WaitPeriod`를 사용하여 억제 경보가 `OK` 상태에서 `ALARM` 상태로 변경될 때 발생할 수 있는 지연을 상쇄합니다. 예를 들어 억제 경보가 60초 이내에 `OK` 상태에서 `ALARM` 상태로 변경되는 경우 `WaitPeriod`를 60초로 설정합니다.
![\[WaitPeriod 내의 작업 억제\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example1border.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t8에 끝납니다. 이렇게 하면 t8에 `WaitPeriod`가 만료되어 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t4에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다.
`ExtensionPeriod`를 사용하여, 억제 경보가 `OK` 상태로 변경된 후 복합 경보가 `OK` 상태로 변경될 때 발생할 수 있는 지연을 상쇄합니다. 예를 들어 억제 경보가 `OK` 상태로 변경되고 나서 60초 이내에 복합 경보가 `OK` 상태로 변경되는 경우 `ExtensionPeriod`를 60초 설정합니다.
![\[ExtensionPeriod 내의 작업 억제\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example2border.png)
이 이미지에서 억제 경보는 t2에 `ALARM` 상태에서 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t2에 시작되어 t8에 끝납니다. 이렇게 하면 t8에 `ExtensionPeriod`가 만료되기 전에 복합 경보가 `ALARM` 상태에서 `OK` 상태로 변경할 시간을 확보할 수 있습니다.
`WaitPeriod`와 `ExtensionPeriod`가 활성화되면 복합 경보가 작업을 수행하지 않습니다. `ExtensionPeriod`와 `WaitPeriod`가 비활성화되면 복합 경보가 현재 상태에 따라 작업을 수행합니다. 1분마다 지표 경보를 평가하므로 각 파라미터의 값을 60초로 설정하는 것이 좋습니다. 파라미터는 초 단위의 원하는 정수로 설정할 수 있습니다.
다음 예에서는`WaitPeriod`과 `ExtensionPeriod`를 사용하여 복합 경보가 예기치 않게 작업을 수행하지 않도록 방지하는 방법을 자세히 설명합니다.
**참고**
다음 예에서 `WaitPeriod`는 두 시간 단위로 구성되고 `ExtensionPeriod`는 세 시간 단위로 구성됩니다.
#### 예제
** 예 1: `WaitPeriod` 후에 작업이 억제되지 않음 **
![\[작업 억제의 첫 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example3border.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝나므로 복합 경보가 작업을 수행하지 못하게 할 수 있습니다. 억제 경보가 아직 `OK` 상태이므로, t4에 `WaitPeriod`가 만료되고 나면 복합 경보가 작업을 수행합니다.
** 예 2: `WaitPeriod`가 만료되기 전에 경보에 의해 동작이 억제됨 **
![\[작업 억제의 두 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example4border.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 억제 경보가 t3에 `OK` 상태에서 `ALARM` 상태로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작되는 `WaitPeriod`가 폐기되고 억제 경보가 이제 복합 경보가 작업을 수행하지 못하게 합니다.
** 예 3: `WaitPeriod`에 의해 작업이 억제될 때의 상태 전환 **
![\[작업 억제의 세 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example5border.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 억제 경보가 상태를 변경할 시간을 확보할 수 있습니다. 복합 경보가 t3에 `OK` 상태로 다시 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. 새 `WaitPeriod`는 t3에 시작되어 t5에 끝납니다. 새 `WaitPeriod`가 t5에 만료되면 복합 경보가 작업을 수행합니다.
** 예 4: 경보에 의해 작업이 억제될 때의 상태 전환 **
![\[작업 억제의 네 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. 억제 경보가 이미 `ALARM` 상태입니다. 억제 경보는 복합 경보가 작업을 수행하는 것을 방지합니다.
** 예 5: `ExtensionPeriod` 후에 작업이 억제되지 않음 **
![\[작업 억제의 다섯 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example7border.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 t6에 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t3에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. t6에 억제 경보가 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t6에 시작되어 t9에 끝납니다. `ExtensionPeriod`이(가) 만료되면 복합 경보가 작업을 수행합니다.
** 예 6: `ExtensionPeriod`에 의해 작업이 억제될 때의 상태 전환 **
![\[작업 억제의 여섯 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png)
이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 t6에 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t3에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. t6에 억제 경보가 다시 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t6에 시작되어 t9에 끝납니다. t7에 복합 경보가 다시 `OK` 상태로 변경되면, `ExtensionPeriod`가 폐기되고 새 `WaitPeriod`가 t7에 시작되어 t9에 끝납니다.
**작은 정보**
억제 경보를 바꾸면 모든 활성 `WaitPeriod` 또는 `ExtensionPeriod`가 폐기됩니다.
## 작업 억제 및 음소거 규칙
복합 경보에 대해 작업 억제 및 경보 음소거 규칙이 모두 활성화된 경우 음소거 규칙이 우선하고 모든 경보 작업을 억제합니다. 음소거 기간이 종료된 후 복합 경보의 작업 억제 구성은 억제 경보 상태와 구성된 대기 또는 연장 기간을 기반으로 작업이 실행되는지를 확인합니다. 경보 음소거 규칙에 대한 자세한 내용은 [경보 음소거 규칙](alarm-mute-rules.md) 섹션을 참조하세요.
# 경보 작업
경보 상태가 OK, ALARM, INSUFFICIENT\$1DATA 간에 변경될 때 경보가 수행하는 작업을 지정할 수 있습니다.
세 가지 상태 각각으로 전환하기 위한 대부분의 작업을 설정할 수 있습니다. Auto Scaling 작업을 제외한 모든 작업은 상태 전환 시에만 수행되며 상태가 몇 시간 또는 며칠 동안 지속되는 경우 다시 수행되지 않습니다.
다음이 경보 작업으로 지원됩니다.
+ Amazon Simple Notification Service 주제를 사용하여 한 명 이상의 구독자에게 알립니다. 구독자는 개인일 뿐만 아니라 애플리케이션일 수도 있습니다.
+ Lambda 함수를 간접적으로 호출합니다. 이는 경보 상태 변경에 대한 사용자 지정 작업을 자동화하는 가장 쉬운 방법입니다.
+ EC2 지표를 기반으로 하는 경보는 EC2 인스턴스 중지, 종료, 재부팅 또는 복구와 같은 EC2 작업을 수행할 수도 있습니다.
+ 경보는 오토 스케일링의 규모를 조정하는 작업을 수행할 수 있습니다.
+ 경보는 Systems Manager Ops Center에서 OpsItems를 생성하거나 AWS Systems Manager Incident Manager에서 인시던트를 생성할 수 있습니다. 이러한 작업은 경보가 ALARM 상태가 될 때만 수행됩니다.
+ 경보는 ALARM 상태가 되었을 때 조사를 시작할 수 있습니다.
경보도 상태가 변경될 때 Amazon EventBridge로 이벤트를 내보내며, 이러한 상태 변경에 대해 다른 작업을 트리거하도록 Amazon EventBridge를 설정할 수 있습니다.
## 경보 작업 및 알림
다음 표에는 여러 시계열(또는 기고자) 경보에 대한 동작과 함께 경보에 대해 실행된 작업이 나와 있습니다.
| 작업 유형 | Metrics Insights 다중 시계열 경보 지원 | PromQL 경보 지원 | 추가 정보 |
| --- | --- | --- | --- |
| SNS 알림 | 기고자 수준 | 기고자 수준 | [Amazon SNS event destinations](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) |
| EC2 작업(중지, 종료, 재부팅, 복구) | 지원되지 않음 | 지원되지 않음 | [EC2 인스턴스 중지, 종료, 재부팅 또는 복구](UsingAlarmActions.md) |
| 오토 스케일링 작업 | 지원되지 않음 | 지원되지 않음 | [Amazon EC2 Auto Scaling의 단계별 조정 및 단순 조정 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) |
| Systems Manager OpsItem 생성 | 경보 수준 | 지원되지 않음 | [OpsItems를 생성하도록 CloudWatch 경보 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) |
| Systems Manager Incident Manager 인시던트 | 경보 수준 | 지원되지 않음 | [CloudWatch 경보를 사용하여 자동으로 인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) |
| Lambda 함수 간접 호출 | 기고자 수준 | 기고자 수준 | [경보에서 Lambda 함수 간접 호출](alarms-and-actions-Lambda.md) |
| CloudWatch 조사 | 경보 수준 | 지원되지 않음 | [경보에서 CloudWatch 조사를 시작](Start-Investigation-Alarm.md) |
경보 알림의 내용은 경보 유형에 따라 다릅니다.
+ 단일 지표 경보에는 상태 이유와 세부 상태 이유 데이터가 모두 포함되며 상태 변경의 원인이 된 특정 데이터 포인트를 표시합니다.
+ 다중 시계열 Metrics Insights 경보는 자세한 상태 이유 데이터 블록 없이 각 기고자에 대한 간소화된 상태 이유를 제공합니다.
+ PromQL 경보 알림에는 상태 이유 또는 상태 이유 데이터가 포함되지 않습니다.
**Example 알림 콘텐츠 예제**
단일 지표 경보 알림에는 자세한 데이터가 포함됩니다.
```
{
"stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...",
"stateReasonData": {
"version": "1.0",
"queryDate": "2025-07-03T08:34:06.300+0000",
"startDate": "2025-07-03T08:19:00.000+0000",
"statistic": "Average",
"period": 300,
"recentDatapoints": [41, 33.8, 32.6],
"threshold": 31,
"evaluatedDatapoints": [
{
"timestamp": "2025-07-03T08:29:00.000+0000",
"sampleCount": 5,
"value": 32.6
}
// Additional datapoints...
]
}
}
```
기고자에 대한 여러 시계열 Metrics Insights 경보 SNS 알림 예제:
```
{
"AlarmName": "DynamoDBInsightsAlarm",
"NewStateValue": "ALARM",
"NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "6d442278dba546f6",
"AlarmContributorAttributes": {
"TableName": "example-dynamodb-table-name"
}
// Additional information...
}
```
기고자에 대한 PromQL 경보 SNS 알림 예제:
```
{
"AlarmName": "HighCPUUsageAlarm",
"NewStateValue": "ALARM",
"StateChangeTime": "2025-12-01T13:42:04.919+0000",
"OldStateValue": "OK",
"AlarmContributorId": "1d502278dcd546a1",
"AlarmContributorAttributes": {
"team": "example-team-name"
}
// Additional information...
}
```
## 경보 작업 음소거
경보 음소거 규칙을 사용하면 유지 관리 기간 또는 운영 이벤트와 같은 사전 정의된 기간에 경보 작업을 자동으로 음소거할 수 있습니다. CloudWatch는 원치 않는 알림을 방지하면서 경보 상태를 계속 모니터링합니다. 자세한 내용은 [경보 음소거 규칙](alarm-mute-rules.md) 섹션을 참조하세요.
**음소거 규칙 및 경보 작업 비활성화**
경보 음소거 규칙은 예약된 기간에 일시적으로 작업을 음소거하고 해당 기간이 종료되면 자동으로 음소거를 해제합니다. 반대로 `DisableAlarmActions` API는 사용자가 `EnableAlarmActions`를 수동으로 직접 호출할 때까지 경보 작업을 영구적으로 비활성화합니다. `EnableAlarmActions` API는 활성 음소거 규칙에 의해 음소거된 경보를 음소거 해제하지 않습니다.
**참고**
경보를 음소거해도 CloudWatch가 경보의 생성, 업데이트, 삭제 및 상태 변경에 대한 경보 이벤트를 Amazon EventBridge로 전송하는 작업은 중지되지 않습니다.
# 경보 음소거 규칙
경보 음소거 규칙은 사전 정의된 기간에 경보 작업을 자동으로 음소거하는 메커니즘을 제공하는 CloudWatch 기능입니다. 음소거 규칙을 생성할 때 작업이 음소거되는 특정 기간과 대상 경보를 정의합니다. CloudWatch는 예상되는 운영 이벤트 중에 원치 않는 알림 또는 자동화된 경보 작업을 방지하면서 경보 상태를 계속 모니터링하고 평가합니다.
경보 음소거 규칙은 경보 작업이 불필요하거나 운영을 중단시키는 중요한 운영 시나리오를 관리하는 데 도움이 됩니다. 예를 들어 계획된 유지 관리 기간에 시스템이 의도적으로 오프라인 상태가 되거나 시스템에서 예상되는 문제가 발생하는 동안 자동화된 경보 작업을 방지하여 중단 없이 유지 관리를 수행할 수 있습니다. 주말이나 공휴일과 같은 업무 외 시간에 수행되는 운영의 경우 즉각적인 대응이 필요하지 않을 때 중요하지 않은 경보 작업을 음소거하여 경보 노이즈를 줄이고 운영 팀에 전송되는 불필요한 알림을 줄일 수 있습니다. 테스트 환경에서 음소거 규칙을 사용하면 예상되는 리소스 사용량이나 오류율이 높고 즉각적인 주의가 필요하지 않은 부하 테스트와 같은 시나리오에서 경보 작업을 일시적으로 음소거할 수 있습니다. 팀이 문제를 적극적으로 해결하는 경우 음소거 규칙은 중복 경보 작업이 트리거되지 않도록 할 수 있으므로 중복 경보 알림으로 인한 방해 없이 문제 해결에 집중할 수 있습니다.
## 경보 음소거 규칙 정의
경보 음소거 규칙은 **규칙** 및 **대상**을 사용하여 정의할 수 있습니다.
+ **규칙** - 경보 작업을 음소거해야 하는 기간을 정의합니다. 규칙은 다음과 같은 세 가지 속성으로 구성됩니다.
+ **표현식** - 음소거 기간이 시작되는 시점과 반복되는 방식을 정의합니다. 다음과 같은 두 가지 유형의 표현식을 사용할 수 있습니다.
+ **Cron 표현식** - 표준 cron 구문을 사용하여 반복되는 음소거 기간을 생성합니다. 이 접근 방식은 주간 시스템 업데이트 또는 일일 백업 작업과 같은 정기 유지 관리 일정에 적합합니다. Cron 표현식을 사용하면 특정 요일, 월 또는 시간을 포함하여 복잡한 반복 패턴을 지정할 수 있습니다.
*cron 표현식 구문*
```
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12) (or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN)
│ │ │ │ │
│ │ │ │ │
* * * * *
```
+ `*`, `,`, `-` 문자는 모든 필드에서 지원됩니다.
+ 영어 이름은 `month`(JAN-DEC) 및 `day of week`(SUN-SAT) 필드에 사용할 수 있습니다.
+ **표현식에서** - 일회성 음소거 기간에 표현식에서 사용합니다. 이 접근 방식은 알려진 시간에 한 번 수행되는 계획된 운영 이벤트에 적합합니다.
```
Syntax: `at(yyyy-MM-ddThh:mm)`
```
+ **기간** - 음소거 규칙이 활성화된 후 지속되는 기간을 지정합니다. 기간은 ISO-8601 형식을 사용하여 최소 1분(PT1M)에서 최대 15일(P15D)로 지정해야 합니다.
+ **시간대** - 'America/Los\$1Angeles' 또는 'Europe/London'과 같은 표준 시간대 식별자를 사용하여 표현식에 따라 음소거 기간이 적용되는 시간대를 지정합니다.
+ **대상** - 정의된 기간에 작업이 음소거되는 경보 이름 목록을 지정합니다. 대상 목록에 지표 경보와 복합 경보를 모두 포함할 수 있습니다.
선택적으로 시작 및 종료 타임스탬프를 포함하여 음소거 기간에 대한 추가 경계를 제공할 수 있습니다. 시작 타임스탬프는 음소거 규칙이 특정 날짜 및 시간 이전에 활성화되지 않도록 하는 반면, 종료 타임스탬프는 지정된 날짜 및 시간 이후에 규칙이 적용되지 않도록 합니다.
프로그래밍 방식으로 경보 음소거 규칙을 생성하는 방법에 대한 자세한 내용은 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)을 참조하세요.
**참고**
대상 경보는 동일한 AWS 계정 및 동일한 AWS 리전(음소거 규칙이 생성됨)에 있어야 합니다.
단일 경보 음소거 규칙은 경보 이름별로 최대 100개의 경보를 대상으로 지정할 수 있습니다.
CloudWatch 콘솔에는 전용 '경보 음소거 규칙' 탭이 있으며, 여기에서 AWS 계정 내 모든 음소거 규칙을 중앙에서 관리할 수 있습니다. 규칙 이름과 같은 음소거 규칙 속성을 사용하여 특정 음소거 규칙을 검색할 수 있습니다.
## 음소거 규칙 상태
경보 음소거 규칙이 생성되면 아래 세 가지 상태 중 하나일 수 있습니다.
+ **SCHEDULED** - 구성된 기간 표현식에 따라 향후 시점에 음소거 규칙이 활성화됩니다.
+ **ACTIVE** - 음소거 규칙은 구성된 기간 표현식에 따라 현재 활성 상태이며 대상 경보 작업을 능동적으로 음소거합니다.
+ **EXPIRED** - 음소거 규칙은 향후 더 이상 SCHEDULED/ACTIVE 상태가 아닙니다. 일회성 음소거 규칙의 경우 음소거 기간이 종료된 후 또는 반복 음소거 규칙의 경우 종료 타임스탬프가 구성되고 해당 시간이 경과한 경우에 나타납니다.
## 경보에서 음소거 규칙의 영향
활성 음소거 기간에 대상 경보에서 상태가 변경되고 작업이 구성된 경우 CloudWatch는 해당 작업을 실행하지 않도록 음소거합니다. 음소거는 경보 작업에만 적용됩니다. 즉, 경보가 계속 평가되고 상태 변경이 CloudWatch 콘솔에 표시되지만 Amazon Simple Notification Service 알림, Amazon Elastic Compute Cloud Auto Scaling 작업 또는 Amazon EC2 작업과 같이 구성된 작업은 실행되지 않습니다. CloudWatch는 음소거 기간에 경보 상태를 정상적으로 계속 평가하며, 사용자는 경보 기록을 통해 이 정보를 볼 수 있습니다.
음소거 기간이 종료되면 대상 경보가 경보 상태(OK/ALARM/INSUFFICIENT\$1DATA)로 유지되는 경우 CloudWatch는 해당 기간에 음소거된 경보 작업을 자동으로 다시 트리거합니다. 그러면 계획된 음소거 기간이 끝날 때 진행 중인 문제에 대해 경보 작업이 실행되어 모니터링 시스템의 무결성을 유지할 수 있습니다.
**참고**
경보를 음소거하는 경우:
대상 경보와 연결된 모든 작업이 음소거됨
모든 경보 상태(OK, ALARM 및 INSUFFICIENT\$1DATA)와 연결된 작업이 음소거됨
## 음소거된 경보 보기 및 관리
음소거된 경보 보기 및 관리에 대한 자세한 내용은 [음소거된 경보 보기 및 관리](viewing-managing-muted-alarms.md) 섹션을 참조하세요.
# 경보 음소거 규칙 작동 방식
다음 시나리오에서는 경보 음소거 규칙이 대상 경보에 미치는 영향과 경보 작업이 음소거되거나 실행되는 방법을 보여줍니다.
**참고**
경보를 음소거하면 OK, ALARM 및 INSUFFICIENT\$1DATA를 포함한 모든 경보 상태에 연결된 작업이 음소거됩니다. 아래 나온 동작은 모든 경보 상태에 연결된 작업에 적용됩니다.
Metrics Insights 경보를 음소거하면 해당 경보에 대한 모든 기고자 지표 시리즈도 자동으로 음소거됩니다.
## 시나리오: 음소거 규칙이 활성화되면 경보 작업이 음소거됨
다음을 고려합니다.
+ 경보에는 ALARM 상태에 대해 구성된 작업이 있음
+ 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t5까지 활성화되도록 예약됨
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png)
+ **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임
+ **t1**에서 - 음소거 규칙 상태가 ACTIVE 상태가 됨
+ **t2**에서 - 경보가 ALARM 상태로 전환되고 음소거 규칙에 의해 경보가 효과적으로 음소거되므로 작업이 음소거됨
+ **t4**에서 - 음소거 규칙이 여전히 활성 상태인 동안 경보가 OK 상태로 돌아감
+ **t5**에서 - 음소거 규칙이 비활성화되지만 경보가 이제 OK 상태이므로 ALARM 작업이 실행되지 않음
## 시나리오: 음소거 규칙이 활성 상태일 때 음소거되고 음소거 기간 이후 다시 트리거되는 경보 작업
다음을 고려합니다.
+ 경보에는 ALARM 상태에 대해 구성된 작업이 있음
+ 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t5까지 활성화되도록 예약됨
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png)
+ **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임
+ **t1**에서 - 음소거 규칙 상태가 ACTIVE 상태가 됨
+ **t2**에서 - 경보가 ALARM 상태로 전환되고 음소거 규칙에 의해 경보가 효과적으로 음소거되므로 작업이 음소거됨
+ **t4**에서 - 음소거 기간이 비활성화되고 경보가 여전히 ALARM 상태임
+ **t5**에서 - 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보 작업이 실행됨
## 시나리오: 여러 중첩 경보 음소거 규칙
다음을 고려합니다.
+ 경보에는 ALARM 상태에 대해 구성된 작업이 있음
2개의 음소거 규칙이 있다고 간주합니다.
+ 경보 음소거 규칙 1 - t1에서 t5까지 경보 음소거
+ 경보 음소거 규칙 2 - t3에서 t9까지 경보 음소거
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png)
+ **t0**에서 - 경보가 OK 상태이고 두 음소거 규칙 모두 SCHEDULED 상태임
+ **t1**에서 - 첫 번째 음소거 규칙이 ACTIVE 상태가 됨
+ **t2**에서 - 경보가 ALARM 상태로 전환되고 작업이 음소거됨
+ **t3**에서 - 두 번째 음소거 규칙이 ACTIVE 상태가 됨
+ **t5**에서 - 첫 번째 음소거 규칙이 비활성화되지만 두 번째 음소거 규칙이 여전히 활성 상태이므로 경보 작업은 음소거 상태로 유지됨
+ **t8**에서 - 두 번째 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보 작업이 실행됨
## 시나리오: 음소거 규칙 업데이트로 음소거 기간이 종료되면 음소거 경보 작업이 실행됨
다음을 고려합니다.
+ 경보에는 ALARM 상태에 대해 구성된 작업이 있음
+ 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t8까지 활성화되도록 예약됨
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png)
+ **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임
+ **t1**에서 - 음소거 규칙이 ACTIVE 상태가 됨
+ **t2**에서 - 경보가 ALARM 상태로 전환되고 작업이 음소거됨
+ **t6**에서 - 음소거 규칙 구성이 업데이트되어 기간이 t6에 끝납니다. 음소거 규칙이 더 이상 활성화되지 않으므로 경보 작업은 t6에서 즉시 실행됩니다.
**참고**
동일한 동작이 적용됩니다.
음소거 규칙이 t6에서 삭제되는 경우 음소거 규칙을 삭제하면 즉시 경보를 음소거 해제합니다.
경보가 음소거 규칙 대상(t6에서)으로부터 제거되면 경보가 즉시 음소거 해제됩니다.
## 시나리오: 음소거 기간에 경보 작업이 업데이트되면 새 작업이 실행됨
다음을 고려합니다.
+ 경보에는 ALARM 상태에 대해 구성된 작업이 있음
+ 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t8까지 활성화되도록 예약됨
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png)
+ **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태입니다. SNS 작업은 경보 상태 ALARM으로 구성됩니다.
+ **t1**에서 - 음소거 규칙이 ACTIVE 상태가 됨
+ **t2**에서 - 경보가 ALARM 상태로 전환되고 구성된 SNS 작업이 음소거됨
+ **t6**에서 - SNS 작업을 제거하고 Lambda 작업을 추가하도록 경보 구성이 업데이트됨
+ **t8**에서 - 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보에 구성된 Lambda 작업이 실행됨
**참고**
음소거 기간(위 예제의 경우 t6에서)에 모든 경보 작업이 제거되면 음소거 기간 종료 시(위 예제의 경우 t8에서) 작업이 실행되지 않음
## 일반적인 사용 사례에 대한 일정 예제
다음 예제에서는 일반적인 사용 사례에서 기간 표현식 구성 방법을 보여줍니다.
**시나리오 1: 예약된 유지 관리 기간에 경보 작업 음소거** - 서비스가 의도적으로 사용 불가능한 상태이거나 성능이 저하된 모드에서 작동하는 경우 시스템 또는 데이터베이스 업데이트와 같이 예측 가능한 일정에 따라 수행되는 정기 유지 관리 활동.
+ 기간이 `PT4H`인 Cron 표현식 `0 2 * * SUN` - 주간 시스템 유지 관리를 위해 매주 일요일 오전 2시부터 오전 6시까지 경보를 음소거합니다.
+ 기간이 `PT6H`인 Cron 표현식 `0 1 1 * *` - 월간 데이터베이스 유지 관리를 위해 매월 1일 오전 1시부터 오전 7시까지 경보를 음소거합니다.
**시나리오 2: 업무 외 시간에 중요하지 않은 경보 음소거** - 즉각적인 주의가 필요하지 않은 주말 또는 휴일에 알림 피로를 줄입니다.
+ 기간이 `P2DT12H`인 Cron 표현식 `0 18 * * FRI` - 매주 주말 금요일 오후 6시부터 월요일 오전 6시까지 경보를 음소거합니다.
**시나리오 3: 일일 백업 작업 중 성능 경보 음소거** - 리소스 사용률을 일시적으로 높이고 예측 가능한 기간에 성능 관련 경보를 트리거할 수 있는 일일 자동 백업 프로세스.
+ 기간이 `PT2H`인 Cron 표현식 `0 23 * * *` - 디스크 I/O 및 CPU 사용률을 일시적으로 높이는 야간 백업 작업 중에 매일 오후 11시부터 오전 1시까지 경보를 음소거합니다.
**시나리오 4: 활성 문제 해결 세션 중에 중복 경보 음소거** - 팀이 문제를 적극적으로 조사하고 해결하는 동안 경보 작업을 일시적으로 음소거하여 알림 노이즈를 방지하고 문제 해결을 집중할 수 있게 합니다.
+ 기간이 `PT4H`인 표현식 `at(2024-05-10T14:00)`에서 - 활성 인시던트 대응 세션 중에 2024년 5월 10일 오후 2시부터 오후 6시까지 경보를 음소거합니다.
**시나리오 5: 계획된 회사 운영 차단 중 경보 작업 음소거** - 모든 시스템이 의도적으로 장기간 오프라인 상태가 되는 일회성의 연장된 유지 관리 기간 또는 회사 전체의 운영 차단.
+ 기간이 `P7D`인 표현식 `at(2024-12-23T00:00)`에서 - 연례 회사 운영 차단 중 2024년 12월 23일\$129일의 전체 주간에 경보를 음소거합니다.
# Limits
## 일반적인 CloudWatch 할당량
경보에 적용되는 일반적인 CloudWatch 서비스 할당량에 대한 자세한 내용은 [CloudWatch 서비스 할당량](cloudwatch_limits.md) 섹션을 참조하세요.
## Metrics Insights 쿼리를 기반으로 경보에 적용되는 제한
CloudWatch Metrics Insights 경보를 사용하는 경우 다음과 같은 기능적 제한에 유의합니다.
+ 리전별 계정당 Metrics Insights 쿼리를 사용하는 기본 경보 200개
+ 경보 상태를 평가하는 데 최근 3시간의 데이터만 사용할 수 있습니다. 그러나 경보 세부 정보 페이지 그래프에서는 최대 2주의 데이터를 시각화할 수 있습니다.
+ 여러 시계열을 평가하는 경보는 ALARM 상태의 기고자 수를 100개로 제한합니다.
+ 쿼리가 150개의 시계열을 검색한다고 가정하는 경우:
+ ALARM 상태의 기고자가 100개 미만인 경우(예: 95) `StateReason`은 '150개 시계열 중 95개가 ALARM으로 평가됨'이 됩니다.
+ 예를 들어 ALARM 상태의 기고자가 100개를 초과하는 경우(예: 105) `StateReason`은 '100개 이상의 시계열이 ALARM으로 평가됨'이 됩니다.
+ 또한 속성 볼륨이 너무 크면 ALARM의 기고자 수를 100개 미만으로 제한할 수 있습니다.
+ 분석되거나 반환된 최대 시계열 수에 대한 Metrics Insights 제한
+ 경보 평가 중에 `EvaluationState`는 다음 제한에 대해 `PARTIAL_DATA`로 설정됩니다.
+ Metrics Insights 쿼리가 500개가 넘는 시계열을 반환하는 경우.
+ Metrics Insights 쿼리가 10,000개가 넘는 지표와 일치하는 경우.
CloudWatch 서비스 할당량 및 제한에 대한 자세한 내용은 [CloudWatch Metrics Insights 서비스 할당량](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html)을 참조하세요.
## PromQL 쿼리를 기반으로 경보에 적용되는 제한
CloudWatch PromQL 경보를 사용하는 경우 유의해야 할 기능적 제한:
+ 여러 시계열을 평가하는 경보는 ALARM 상태의 기고자 수를 100개로 제한합니다.
+ ALARM 상태의 기고자가 100개 미만인 경우(예: 95) `StateReason`은 '95개 시계열이 ALARM으로 평가됨'이 됩니다.
+ 예를 들어 ALARM 상태의 기고자가 100개를 초과하는 경우(예: 105) `StateReason`은 '100개 이상의 시계열이 ALARM으로 평가됨'이 됩니다.
+ 또한 속성 볼륨이 너무 크면 ALARM의 기고자 수를 100개 미만으로 제한할 수 있습니다.
+ 분석되거나 반환된 최대 시계열 수에 대한 PromQL 제한
+ 경보 평가 중에 PromQL 쿼리가 500개를 초과하는 시계열을 반환하면 `EvaluationState`가 `PARTIAL_DATA`로 설정됩니다.
## 연결된 데이터 소스를 기반으로 경보에 적용되는 제한
+ CloudWatch는 경보를 평가할 때 경보 기간이 1분 이상이더라도 1분마다 평가를 수행합니다. 경보가 작동하려면 Lambda 함수가 기간 길이의 배수뿐만 아니라 임의의 분에 시작하는 타임스탬프 목록을 반환할 수 있어야 합니다. 이러한 타임스탬프는 한 기간 길이 간격으로 떨어져 있어야 합니다.
따라서 Lambda에서 쿼리한 데이터 소스가 기간 길이의 배수인 타임스탬프만 반환할 수 있는 경우 함수는 `GetMetricData` 요청에서 예상하는 타임스탬프와 일치하도록 가져온 데이터를 '다시 샘플링'해야 합니다.
예를 들어, 기간이 5분인 경보는 매번 1분씩 이동하는 5분 기간을 사용하여 1분마다 평가됩니다. 이 경우
+ 12:15:00의 경보 평가에 대해 CloudWatch는 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터 포인트를 예상합니다.
+ 그런 다음 12:16:00의 경보 평가에 대해 CloudWatch는 타임스탬프가 `12:01:00`, `12:06:00` 및 `12:11:00`인 데이터 포인트를 예상합니다.
+ CloudWatch가 경보를 평가할 때 Lambda 함수에서 반환한 데이터 포인트 중 예상 타임스탬프와 일치하지 않는 모든 데이터 포인트는 삭제되고 나머지 예상 데이터 포인트를 사용하여 경보가 평가됩니다. 예를 들어, 경보가 `12:15:00`에 평가되면 CloudWatch는 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터를 예상합니다. 타임스탬프가 `12:00:00`, `12:05:00`, `12:06:00` 및 `12:10:00`인 데이터를 수신하면 `12:06:00`의 데이터가 삭제되고 CloudWatch는 다른 타임스탬프를 사용하여 경보를 평가합니다.
그런 다음 `12:16:00`의 다음 평가에 대해 CloudWatch는 타임스탬프가 `12:01:00`, `12:06:00` 및 `12:11:00`인 데이터를 예상합니다. 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터만 있는 경우 12:16:00에 이러한 데이터 포인트가 모두 무시되고 누락된 데이터를 처리하기 위해 경보를 지정한 방법에 따라 알람이 해당 상태로 전환됩니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
+ `INSUFFICIENT_DATA` 상태로 전환될 때 조치를 취하도록 이러한 경보를 생성하는 것이 좋습니다. 여러 Lambda 함수 실패 사용 사례에서는 누락된 데이터를 처리하기 위해 경보를 설정한 방식에 관계없이 경보가 `INSUFFICIENT_DATA`로 전환되기 때문입니다.
+ Lambda 함수가 오류를 반환하는 경우:
+ Lambda 함수를 호출하는 데 권한 문제가 있는 경우, 생성 시 누락된 데이터를 처리하도록 경보를 지정한 방법에 따라 경보에서 누락된 데이터 전환이 발생하기 시작합니다.
+ Lambda 함수에서 발생하는 다른 오류로 인해 경보가 `INSUFFICIENT_DATA`로 전환됩니다.
+ Lambda 함수에서 요청한 지표에 약간의 지연이 발생하여 마지막 데이터 포인트가 항상 누락되는 경우 해결 방법을 사용해야 합니다. N개 중 M개의 경보를 생성하거나 경보 평가 기간을 늘릴 수 있습니다. M개 중 N개의 경보에 대한 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
# 시작하기
**Topics**
+ [경보 생성](Create-Alarms.md)
+ [경보 변경에 따른 조치](Acting_Alarm_Changes.md)
+ [경보 음소거 규칙 구성](alarm-mute-rules-configure.md)
# 경보 생성
**Topics**
+ [정적 임곗값을 기반으로 CloudWatch 경보 생성](ConsoleAlarms.md)
+ [지표 수학 표현식을 기반으로 CloudWatch 경보 생성](Create-alarm-on-metric-math-expression.md)
+ [이상 탐지를 기반으로 CloudWatch 경보 생성](Create_Anomaly_Detection_Alarm.md)
+ [다중 시계열 Metrics Insights 쿼리를 기반으로 경보 생성](multi-time-series-alarm.md)
+ [연결된 데이터 소스를 기반으로 경보 생성](Create_MultiSource_Alarm.md)
+ [PromQL 쿼리를 사용하여 경보 생성](Create_PromQL_Alarm.md)
+ [로그에 대한 경보](Alarm-On-Logs.md)
+ [복합 경보 생성](Create_Composite_Alarm.md)
# 정적 임곗값을 기반으로 CloudWatch 경보 생성
감시할 경보에 대한 CloudWatch 지표와 해당 지표에 대한 임곗값을 선택합니다. 지표가 지정된 수의 평가 기간에 대한 임곗값을 위반할 경우 경보가 `ALARM` 상태가 됩니다.
CloudWatch 크로스 계정 관측성에서 모니터링 계정으로 설정된 계정에 경보를 생성하는 경우 이 모니터링 계정에 연결된 소스 계정의 지표를 관찰하도록 경보를 설정할 수 있습니다. 자세한 내용은 [CloudWatch 크로스 계정 관측성](CloudWatch-Unified-Cross-Account.md) 섹션을 참조하세요.
**단일 지표를 기반으로 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)** **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성(Create alarm)**을 선택하세요.
1. **지표 선택**을 선택합니다.
1. 다음 중 하나를 수행하세요.
+ 원하는 지표가 포함된 서비스 네임스페이스를 선택합니다. 옵션이 나타날 때 계속해서 옵션을 선택하면 선택 범위가 좁아집니다. 지표 목록이 표시되면 원하는 지표 옆에 있는 확인란을 선택합니다.
+ 검색 상자에 지표 이름, 계정 ID, 계정 레이블, 차원 또는 리소스 ID를 입력합니다. 그런 다음 결과 중 하나를 선택하고 지표 목록이 표시될 때까지 계속 진행합니다. 원하는 지표 옆의 확인란을 선택합니다.
1. **그래프로 표시된 지표** 탭을 선택합니다.
1. **통계**에서 통계 또는 사전 정의된 백분위수 중 하나를 선택하거나, 사용자 지정 백분위수(예: **p95.45**)를 지정합니다.
1. **기간**에서 경보에 대한 평가 기간을 선택합니다. 경보를 평가할 때 각 기간이 하나의 데이터 포인트로 집계됩니다.
또한 경보를 생성할 때 Y축 범례를 왼쪽 또는 오른쪽에 표시할지 여부를 선택할 수도 있습니다. 이러한 기본 설정은 경보를 생성하는 동안에만 사용됩니다.
1. **지표 선택**을 선택합니다.
선택한 지표 및 통계에 대한 그래프와 기타 정보가 표시된 **Specify metric and conditions(지표 및 조건 지정)** 페이지가 나타납니다.
1. **조건**에서 다음을 지정합니다.
1. **지표가 *다음인 경우* 항상**에서 지표가 임곗값보다 크거나, 작거나, 같아야 하는지 여부를 지정합니다. **than...**에서 임곗값을 지정합니다.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N 중 M 경보를 생성하려면 두 번째 값에 지정한 값보다 낮은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 단원을 참조하세요.
1. **누락 데이터 처리**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 단원을 참조하세요.
1. 경보가 모니터링된 통계 값으로 백분위수를 사용하는 경우에는 **샘플이 부족한 백분위수** 상자가 표시됩니다. 샘플 비율이 낮은 사례를 평가 또는 무시할지 여부를 선택할 때 이 상자를 사용합니다. **ignore (maintain alarm state)(무시(경보 상태 유지))**를 선택하면 샘플 크기가 너무 작을 때 현재 경보 상태가 항상 유지됩니다. 자세한 내용은 [백분위수 기반 경보 및 데이터 샘플 부족](percentiles-with-low-samples.md) 단원을 참조하세요.
1. **다음(Next)**을 선택합니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
CloudWatch 크로스 계정 관측성에서 여러 AWS 계정으로 알림을 전송하도록 선택할 수 있습니다. 예를 들어, 모니터링 계정과 소스 계정 모두로 알림을 전송할 수 있습니다.
경보에서 알림을 보내지 않게 하려면 **제거**를 선택합니다.
1. 경보가 오토 스케일링, EC2, Lambda, 조사 또는 Systems Manager 작업을 수행하도록 하려면 해당 버튼을 선택하고 경보 상태와 수행할 작업을 선택합니다. 경보는 ALARM 상태가 될 때만 Systems Manager 작업 및 조사 작업을 수행할 수 있습니다. Systems Manager 작업에 대한 자세한 내용은 [ 경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [ 인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)을 참조하세요.
경보가 조사가 시작되도록 하려면 **조사 작업 추가**를 선택한 다음 조사 그룹을 선택합니다. 자세한 내용은 [CloudWatch 조사](Investigations.md) 섹션을 참조하세요.
**참고**
SSM Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. 마친 후에는 **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다. 그리고 **다음(Next)**을 선택합니다.
1. **미리 보기 및 생성**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성**을 선택합니다.
대시보드에 경보를 추가할 수도 있습니다. 자세한 내용은 [CloudWatch 대시보드에 경보 추가](add_alarm_dashboard.md) 섹션을 참조하세요.
# 지표 수학 표현식을 기반으로 CloudWatch 경보 생성
지표 경보는 단일 지표 또는 고유한 하나 이상의 지표를 결합하거나 요구 사항에 더 가깝게 부합하는 인사이트를 제공하는 시계열로 변환하는 지표 수학 표현식에서 정의한 시계열을 평가하도록 설계되었습니다. 지표 수학 표현식을 기반으로 경보를 생성하려면 표현식에 사용할 CloudWatch 지표를 하나 이상 선택합니다. 그런 다음 표현식, 임곗값 및 평가 기간을 지정합니다.
**SEARCH** 표현식을 기반으로 경보를 생성할 수 없습니다. Metrics Insights SQL 쿼리를 기반으로 하는 경보만 여러 시계열에서 작동할 수 있습니다.
**지표 수학 표현식을 기반으로 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택한 다음 **모든 경보(All alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. **지표 선택(Select Metric)**을 선택하고 다음 작업 중 하나를 수행합니다.
+ **AWS 네임스페이스( namespaces)** 드롭다운 또는 **사용자 지정 네임스페이스(Custom namespaces)** 드롭다운에서 네임스페이스를 선택합니다. 네임스페이스를 선택한 후에는 올바른 지표 옆의 확인란을 선택하는 지표 목록이 나타날 때까지 옵션을 계속 선택합니다.
+ 검색 상자를 사용하여 지표, 계정 ID, 차원 또는 리소스 ID를 찾습니다. 지표, 측정기준 또는 리소스 ID를 입력한 후 올바른 지표 옆의 확인란을 선택하는 지표 목록이 나타날 때까지 옵션을 계속 선택합니다.
1. (선택 사항) 지표 수학 표현식에 다른 지표를 추가하려면 검색 상자를 사용하여 특정 지표를 찾을 수 있습니다. 지표 수학 표현식에 지표를 10개까지 추가할 수 있습니다.
1. **그래프로 표시된 지표(Graphed metrics)** 탭을 선택합니다. 전에 추가한 지표 각각에 대해 다음 작업을 수행합니다.
1. **통계(Statistic)** 열에서 드롭다운 메뉴를 선택합니다. 드롭다운 메뉴에서 미리 정의된 통계 또는 백분위수 중 하나를 선택합니다. 드롭다운 메뉴의 검색 상자를 사용하여 사용자 지정 백분위수를 지정합니다.
1. **기간(Period)** 열에서 드롭다운 메뉴를 선택합니다. 드롭다운 메뉴에서 미리 정의된 평가 기간 중 하나를 선택합니다.
경보를 생성하는 동안 Y축 범례를 그래프의 왼쪽 또는 오른쪽에 표시할지 여부를 지정할 수도 있습니다.
**참고**
CloudWatch가 경보를 평가하면 기간이 단일 데이터 포인트로 집계됩니다.
1. **수학 추가(Add math)** 드롭다운을 선택한 다음 미리 정의된 지표 수학 표현식 목록에서 **빈 표현식으로 시작(Start with an empty expression)**을 선택합니다.
**빈 표현식으로 시작(Start with an empty expression)**을 선택하면 수학 표현식을 적용하거나 편집할 수 있는 수학 표현식 상자가 나타납니다.
1. 수학 표현식 상자에 수학 표현식을 입력한 다음 **적용(Apply)**을 선택합니다.
**적용(Apply)**을 선택하면 **ID** 열이 **레이블(Label)** 열 옆에 나타납니다.
현재 수학 표현식 공식의 일부로 지표 또는 다른 지표 수학 표현식의 결과를 사용하려면 **ID** 열 아래 표시된 값을 사용합니다. **ID**의 값을 변경하려면 현재 값 옆에 있는 펜 앤 페이퍼 아이콘을 선택합니다. 새 값은 소문자로 시작해야 하며 숫자, 문자, 밑줄 기호를 포함할 수 있습니다. **ID**의 값을 좀 더 의미 있는 이름으로 변경하면 경보 그래프를 이해하기가 더욱 쉬워집니다.
지표 수학에 사용할 수 있는 함수에 대한 자세한 내용은 [지표 수학 구문 및 함수](using-metric-math.md#metric-math-syntax) 섹션을 참조하세요.
1. (선택 사항) 새 수학 표현식의 수식에 다른 수학 표현식의 지표 및 결과를 사용해 수학 표현식을 추가합니다.
1. 경보에 사용할 표현식이 있는 경우 페이지에서 다른 모든 표현식 및 지표 왼쪽에 있는 확인란을 선택 취소합니다. 경보에 사용할 표현식 옆의 확인란만 선택해야 합니다. 경보에 사용하려고 선택한 표현식은 단일 시계열을 생성하고, 그래프에 선을 하나만 표시해야 합니다. 그런 다음 **지표 선택**을 선택합니다.
선택한 수학 표현식에 대한 그래프와 기타 정보가 표시된 **지표 및 조건 지정** 페이지가 표시됩니다.
1. **표현식이 *다음인 경우* 항상**에서 표현식이 임곗값보다 크거나, 작거나, 같아야 하는지 여부를 지정합니다. **than...**에서 임곗값을 지정합니다.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N 중 M 경보를 생성하려면 두 번째 값에 지정한 값보다 낮은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 단원을 참조하세요.
1. **누락 데이터 처리**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 단원을 참조하세요.
1. **다음(Next)**을 선택합니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거**를 선택합니다.
1. 경보가 Auto Scaling, Amazon EC2, Lambda 또는 Systems Manager 작업을 수행하도록 하려면 해당 버튼을 선택하고 경보 상태와 수행할 작업을 선택합니다. Lambda 함수를 경보 작업으로 선택하는 경우 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택할 수 있습니다.
경보는 ALARM 상태가 될 때만 Systems Manager 작업을 수행할 수 있습니다. Systems Manager 작업에 대한 자세한 내용은 [경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 단원을 참조하세요.
**참고**
SSM Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. 마친 후에는 **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 그리고 **다음**을 선택합니다.
이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **미리 보기 및 생성**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성**을 선택합니다.
대시보드에 경보를 추가할 수도 있습니다. 자세한 내용은 [CloudWatch 대시보드에 경보 추가](add_alarm_dashboard.md) 섹션을 참조하세요.
# 이상 탐지를 기반으로 CloudWatch 경보 생성
과거 지표 데이터를 분석하고 예상 값의 모델을 생성하는 CloudWatch 이상 탐지를 기반으로 경보를 생성할 수 있습니다. 기댓값은 지표의 일반적인 시간별, 일별, 주별 패턴을 고려합니다.
이상 탐지 임곗값에 대한 값을 설정합니다. 그러면 CloudWatch는 모델과 함께 이 임곗값을 사용하여 지표 값의 ‘정상’ 범위를 결정합니다. 임곗값에 대한 값이 클수록 ‘정상’ 값의 밴드가 더 두꺼워집니다.
지표 값이 기댓값 밴드 이상이거나 이하일 때, 아니면 두 경우 모두 경보가 트리거되도록 설정할 수 있습니다.
단일 지표 및 지표 수학 표현식의 출력에 대한 이상 탐지 경보를 생성할 수도 있습니다. 이러한 표현식을 사용하여 이상 탐지 밴드를 시각화하는 그래프를 만들 수 있습니다.
CloudWatch 교차 계정 관찰성을 위해 모니터링 계정으로 설정된 계정에서 모니터링 계정의 지표뿐만 아니라 소스 계정의 지표에도 이상 탐지기를 만들 수 있습니다.
자세한 내용은 [CloudWatch 이상 탐지 사용](CloudWatch_Anomaly_Detection.md) 섹션을 참조하세요.
**참고**
시각화 목적으로 지표 콘솔의 지표에 이상 탐지를 이미 사용 중인데 해당 지표에 이상 탐지 경보를 생성한 경우, 경보에 설정한 임곗값은 시각화를 위해 이미 설정한 임곗값을 변경하지 않습니다. 자세한 내용은 [그래프 생성](graph_a_metric.md#create-metric-graph) 섹션을 참조하세요.
**이상 탐지에 기반하여 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)** **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성(Create alarm)**을 선택하세요.
1. **지표 선택**을 선택합니다.
1. 다음 중 하나를 수행하세요.
+ 메트릭이 포함된 서비스 네임스페이스를 선택한 다음 계속하여 나타나는 옵션을 선택하여 옵션 범위를 좁힙니다. 지표 목록이 표시되면 원하는 지표 옆에 있는 확인란을 선택합니다.
+ 검색 상자에 지표 이름, 차원 또는 리소스 ID를 입력합니다. 그런 다음 결과 중 하나를 선택하고 지표 목록이 표시될 때까지 계속 진행합니다. 지표 옆의 확인란을 선택합니다.
1. **그래프로 표시된 지표**를 선택합니다.
1. (선택 사항) *통계*에서 드롭다운을 선택한 후 미리 정의된 통계 또는 백분위수 중 하나를 선택합니다. 드롭다운 메뉴의 검색 상자를 사용하여 **p95.45**와/과 같은 사용자 지정 백분위수를 지정합니다.
1. (선택 사항) *기간*에서 드롭다운을 선택한 후 미리 정의된 평가 기간 중 하나를 선택합니다.
**참고**
CloudWatch가 경보를 평가하면 기간이 단일 데이터 포인트로 조정됩니다. 이상 탐지 경보의 경우, 값은 1분 이상이어야 합니다.
1. **다음**을 선택합니다.
1. ***조건***에서 다음을 지정합니다.
1. **Anomaly Detection(이상 탐지)**를 선택합니다.
이 지표 및 통계에 대한 모델이 이미 있는 경우 CloudWatch는 화면 상단의 그래프에 이상 탐지 밴드 미리보기를 표시합니다. 경보를 생성한 후 그래프에 실제 이상 탐지 밴드가 표시되는 데 최대 15분이 소요될 수 있습니다. 그 전에 표시되는 밴드는 이상 탐지 밴드의 근사치입니다.
**작은 정보**
화면 상단에 더 긴 기간의 그래프를 보려면 페이지 오른쪽 위에 있는 **편집**을 선택합니다.
이 지표 및 통계에 대한 모델이 아직 없는 경우 경보 생성을 완료하면 CloudWatch에서는 이상 탐지 밴드를 생성합니다. 새 모델의 경우 그래프에 실제 이상 탐지 밴드가 표시되는 데 최대 3시간이 소요될 수 있습니다. 새 모델을 훈련하는 데 최대 2주가 소요될 수 있는데, 그래야 이상 감지 대역이 더 정확한 기대값을 표시할 수 있습니다.
1. ***지표*가 다음인 경우 항상(Whenever metric is)**에서 경보를 트리거할 시기를 지정합니다. (예: 지표가 밴드보다 크거나, 작거나, 밴드 외부(어느 방향이든)일 때)
1. **이상 탐지 임곗값**에서 이상 탐지 임곗값에 사용할 숫자를 선택합니다. 숫자가 클수록 지표의 변화에 더 잘 대응할 수 있는 “정상” 값의 두꺼운 밴드가 생성됩니다. 숫자가 작을수록 지표 편차가 더 작은 `ALARM` 상태로 변하는 얇은 밴드가 생성됩니다. 이 숫자는 정수일 필요는 없습니다.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N개 중 M번째 경보를 생성하려면 두 번째 값의 숫자보다 작은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
1. **누락 데이터 처리(Missing data treatment)**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 섹션을 참조하세요.
1. 경보가 모니터링된 통계 값으로 백분위수를 사용하는 경우에는 **샘플이 부족한 백분위수** 상자가 표시됩니다. 샘플 비율이 낮은 사례를 평가 또는 무시할지 여부를 선택할 때 이 상자를 사용합니다. **무시(경보 상태 유지)(Ignore (maintain alarm state))**를 선택하면 샘플 크기가 너무 작을 때 현재 경보 상태가 항상 유지됩니다. 자세한 내용은 [백분위수 기반 경보 및 데이터 샘플 부족](percentiles-with-low-samples.md) 단원을 참조하세요.
1. **다음(Next)**을 선택합니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 SNS 주제를 선택합니다.
동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내려면 **알림 추가(Add notification)**를 선택합니다.
경보에 알림을 전송하지 않으려면 **제거(Remove)**를 선택합니다.
1. 상태가 변경될 때 EC2 작업을 수행하거나 Lambda 함수를 간접적으로 호출하도록 경보를 설정하거나 경보 상태가 될 때 Systems Manager OpsItem 또는 인시던트를 생성하도록 설정할 수 있습니다. 이렇게 하려면 해당 버튼을 선택한 다음 경보 상태 및 수행할 작업을 선택합니다.
Lambda 함수를 경보 작업으로 선택하는 경우 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택할 수 있습니다.
Systems Manager 작업에 대한 자세한 내용은 [ 경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [ 인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)을 참조하세요.
**참고**
AWS Systems Manager Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. **다음**을 선택합니다.
1. ***이름 및 설명***에서 경보의 이름과 설명을 입력하고 **다음**을 선택합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
**작은 정보**
경보 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다.
1. ***미리 보기 및 생성***에서 경보의 정보와 조건이 올바른지 확인하고 **경보 생성**을 선택합니다.
## 이상 탐지 모델 편집
경보를 생성한 후 이상 탐지 모델을 수정할 수 있습니다. 모델 생성에 특정 기간이 사용되지 않도록 제외할 수 있습니다. 교육 데이터에서 시스템 중단, 배포 및 휴일과 같은 비정상적인 이벤트를 제외하는 것이 중요합니다. 일광 절약 시간제 변경에 대해 모델을 조정할지 여부도 지정할 수 있습니다.
**경보에 대한 이상 탐지 모델을 편집하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)** **모든 경보(All Alarms)**를 선택합니다.
1. 경보 이름을 선택합니다. 필요하면 검색 상자를 사용하여 경보를 찾습니다.
1. **보기**, **지표에서**를 선택하세요.
1. **세부 정보** 열에서 키워드 **ANOMALY\$1DETECTION\$1BAND**를 선택한 다음에 팝업에서 **이상 탐지 모델 편집**을 선택합니다.
![\[ANOMALY_DETECTION_BAND 팝업 메뉴가 표시된 그래프로 표시된 지표 탭입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
1. 모델을 생성하는 데 사용되는 기간을 제외하려면 **종료 날짜** 옆의 달력 아이콘을 선택합니다. 그런 다음, 교육에서 제외할 날짜와 시간을 선택하거나 입력하고 **적용(Apply)**을 선택합니다.
1. 지표가 일광절약시간제 변화에 민감한 경우, **지표 시간대(Metric timezone)** 상자에서 적절한 시간대를 선택합니다.
1. **업데이트**를 선택합니다.
## 이상 탐지 모델 삭제
경보에 대한 이상 탐지를 사용하면 계정에 요금이 발생합니다. 경보에 이상 탐지 모델이 더 이상 필요하지 않은 경우 경보를 먼저 삭제하고 모델을 두 번째로 삭제하는 것이 좋습니다. 이상 탐지 경보가 평가되면 누락된 이상 탐지기가 사용자를 대신하여 생성됩니다. 경보를 삭제하지 않고 모델을 삭제하면 알람이 자동으로 모델을 다시 생성합니다.
**경보를 삭제하는 방법**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. 경보 이름을 선택합니다.
1. **작업**, **삭제**를 선택합니다.
1. 확인 상자에서 **삭제**를 선택합니다.
**경보에 사용된 이상 탐지 모델 삭제**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표**를 선택한 다음 **모든 지표**를 선택합니다.
1. **Browse**(찾아보기)를 선택한 다음 이상 탐지 모델이 포함된 지표를 선택합니다. 검색 상자에서 지표를 검색하거나 옵션을 통해 선택하여 지표를 선택할 수 있습니다.
+ (선택 사항) 원래 인터페이스를 사용하는 경우 **All metrics**(모든 지표)를 선택한 다음 이상 감지 모델이 포함된 지표를 선택합니다. 검색 상자에서 지표를 검색하거나 옵션을 통해 선택하여 지표를 선택할 수 있습니다.
1. **그래프로 표시된 지표(Graphed metrics)**를 선택합니다.
1. **그래프로 표시된 지표** 탭의 **세부 정보** 열에서 키워드 **ANOMALY\$1DETECTION\$1BAND**를 선택한 다음에 팝업에서 **이상 탐지 모델 삭제**를 선택합니다.
![\[ANOMALY_DETECTION_BAND 팝업 메뉴가 표시된 그래프로 표시된 지표 탭입니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/Anomaly_Detection_Edit.PNG)
+ (선택 사항) 원래 인터페이스를 사용하는 경우 **Edit model**(모델 편집)을 선택합니다. 새 화면으로 이동합니다. 새 화면에서 **Delete model**(모델 삭제)을 선택한 다음 **Delete**(삭제)를 선택합니다.
# 다중 시계열 Metrics Insights 쿼리를 기반으로 경보 생성
리소스 플릿에서 여러 시계열을 모니터링하는 경보를 생성할 수 있습니다. 개별 인스턴스에서 작업을 트리거하는 단일 인스턴스 경보와 달리 플릿 모니터링 경보를 사용하면 여러 리소스에서 지표를 집계하고 플릿 전체 조건을 기반으로 트리거할 수 있습니다.
## AWS Management Console을 사용하여 다중 시계열 경보 설정
이 예제에서는 인스턴스 플릿에서 메모리 사용률을 모니터링하고 2개가 넘는 인스턴스가 임계치를 초과할 때 이를 알리는 경보를 생성하는 방법을 보여줍니다.
**다중 시계열 경보를 생성하는 방법**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성(Create alarm)**을 선택하세요.
1. **지표 선택**을 선택합니다.
1. **지표**에서 Metrics Insights 쿼리를 입력하세요.
```
SELECT MAX(mem_used_percent)
FROM "CWAgent"
GROUP BY InstanceId
ORDER BY MAX() DESC
```
1. **다음**을 선택합니다.
1. **조건**에서 다음을 지정합니다.
+ **임곗값 유형**에서 **정적**을 선택합니다.
+ **지표 조건**에서 **보다 큼**을 선택하고 **80**을 입력하세요.
+ **경보를 알릴 데이터 포인트**에 **2**를 입력하세요.
1. 필요에 따라 알림 및 작업을 구성하세요.
1. 경보에 이름과 설명(선택 사항)을 추가하세요.
1. **경보 생성**을 선택하세요.
이 경보는 여러 면에서 단일 인스턴스 경보와 다릅니다.
+ 지표 쿼리를 사용하여 여러 시계열을 동시에 모니터링합니다. 지표 쿼리는 경보가 평가될 때마다 새로 고쳐지므로 리소스가 생성, 일시 중지 또는 삭제될 때 경보가 자동으로 조정됩니다.
+ 임계치를 위반하는 각 기여자에 대해 경보는 기여자 상태 변경 이벤트를 전송합니다. 이 이벤트는 EventBridge에서 경보 상태 변경 이벤트와 다른 이벤트 유형을 포함합니다. 경보 자체도 상태를 변경합니다. 하나 이상의 기여자가 경보 상태가 되면 해당 경보도 곧바로 경보 상태로 전환됩니다.
+ 그러나 SSM 인시던트와 같은 일부 작업은 경보 수준에서 트리거됩니다. 이러한 작업은 경보의 기여자 목록이 변경될 때 반복되지 않습니다.
이 경보는 여러 면에서 집계된 지표 쿼리 경보와 다릅니다.
+ `GROUP BY` 절을 사용하여 집계 대신 시계열을 개별적으로 모니터링합니다.
+ 필요에 따라 설정한 세분화 수준을 따릅니다. 예를 들어 `GROUP BY` 절에서 설정한 필드에 따라 모든 Amazon EC2 인스턴스(Amazon EC2 지표의 가장 세분화된 수준)에서 또는 Amazon RDS 테이블(테이블의 다양한 작업에 집계됨)당 경보를 생성할 수 있습니다.
+ `ORDER BY` 절을 사용하여 평가의 우선순위를 지정합니다.
+ 임계치를 위반하는 각 기여자에 대해 경보는 기여자 상태 변경 이벤트를 전송합니다. 이 이벤트는 EventBridge에서 경보 상태 변경 이벤트와 다른 이벤트 유형을 포함합니다. 경보 자체도 상태를 변경합니다. 하나 이상의 기여자가 경보 상태가 되면 해당 경보도 곧바로 경보 상태로 전환됩니다.
+ 그러나 SSM 인시던트와 같은 일부 작업은 경보 수준에서 트리거됩니다. 이러한 작업은 경보의 기여자 목록이 변경될 때 반복되지 않습니다.
# 연결된 데이터 소스를 기반으로 경보 생성
CloudWatch에 없는 데이터 소스의 지표를 감시하는 경보를 생성할 수 있습니다. 이러한 다른 데이터 소스에 대한 연결을 생성하는 방법에 대한 자세한 내용은 [다른 데이터 소스의 쿼리 지표](MultiDataSourceQuerying.md) 섹션을 참조하세요.
**연결한 데이터 소스의 지표에 대한 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표**, **모든 지표**를 선택합니다.
1. **다중 소스 쿼리** 탭을 선택합니다.
1. **데이터 소스**에서 사용할 데이터 소스를 선택합니다.
1. 쿼리 작성기가 쿼리가 경보에 사용할 지표를 검색하는 데 필요한 정보를 입력하라는 메시지를 표시합니다. 워크플로는 각 데이터 소스마다 다르며 데이터 소스에 맞게 조정됩니다. 예를 들어, Amazon Managed Service for Prometheus 및 Prometheus 데이터 소스의 경우 쿼리 도우미가 포함된 PromQL 쿼리 편집기 상자가 나타납니다.
1. 쿼리 구성을 마치면 **쿼리 그래프로 표시**를 선택합니다.
1. 샘플 그래프가 예상과 같으면 **경보 생성**을 선택합니다.
1. **지표 및 조건 지정** 페이지가 나타납니다. 사용 중인 쿼리가 둘 이상의 시계열을 생성하는 경우 페이지 상단에 경고 배너가 표시됩니다. 그럴 경우 **집계 함수**에서 시계열을 집계하는 데 사용할 함수를 선택합니다.
1. (선택 사항) 경보에 대한 **레이블**을 추가합니다.
1. ***your-metric-name*이 다음과 같은 경우에 항상…**에서 **보다 큼**, **보다 크거나 같음**, **보다 작거나 같음** 또는 **보다 작음**을 선택합니다. **:**에 임곗값에 대한 숫자를 지정합니다.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N개 중 M번째 경보를 생성하려면 두 번째 값의 숫자보다 작은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
1. **누락 데이터 처리(Missing data treatment)**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 섹션을 참조하세요.
1. **다음**을 선택합니다.
1. **알림**에서 경보가 `ALARM`, `OK` 또는 `INSUFFICIENT_DATA` 상태로 전환될 때 알림을 보낼 Amazon SNS 주제를 지정합니다.
1. (선택 사항) 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내려면 **알림 추가**를 선택합니다.
**참고**
**경보** 상태가 되는 경우와 함께 **데이터 부족** 상태가 되는 경우에도 조치를 취하도록 경보를 설정하는 것이 좋습니다. 데이터 소스에 연결되는 Lambda 함수와 관련된 많은 문제로 인해 경보가 **데이터 부족** 상태로 전환될 수 있기 때문입니다.
1. (선택 사항) Amazon SNS 알림을 보내지 않으려면 **제거**를 선택합니다.
1. 경보에서 Auto Scaling, Lambda 또는 Systems Manager 작업을 수행하게 하려면 해당 버튼을 선택하고 경보 상태와 수행할 작업을 선택하세요. Lambda 함수를 경보 작업으로 선택하는 경우 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택할 수 있습니다.
경보는 ALARM 상태가 될 때만 Systems Manager 작업을 수행할 수 있습니다. Systems Manager 작업에 대한 자세한 내용은 [경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 단원을 참조하세요.
**참고**
SSM Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. **다음**을 선택합니다.
1. **이름 및 설명**에서 경보의 이름과 설명을 입력하고 **다음**을 선택합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
**작은 정보**
경보 이름에는 UTF-8 문자만 포함되어야 합니다. ASCII 제어 문자를 포함할 수 없습니다.
1. **미리 보기 및 생성**에서 경보의 정보와 조건이 올바른지 확인하고 **경보 생성**을 선택합니다.
# PromQL 쿼리를 사용하여 경보 생성
PromQL 인스턴트 쿼리를 사용하여 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 모니터링하는 CloudWatch 경보를 생성할 수 있습니다. 쿼리에서 반환하는 일치하는 모든 시계열은 위반으로 간주되며, 경보는 각 위반 시계열을 기고자로 추적합니다. PromQL 경보의 작동 방식에 대한 자세한 내용은 [PromQL 경보](alarm-promql.md) 섹션을 참조하세요.
## AWS Management Console을 사용하여 PromQL 경보 생성
이 예제에서는 게이지 지표를 모니터링하고 값이 20 미만으로 떨어질 때 이를 알리는 경보를 생성하는 방법을 보여줍니다.
**PromQL 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. 지표 유형으로 **PromQL**을 선택합니다.
1. **편집기** 모드에서 PromQL 쿼리 입력:
```
my_gauge_metric < 20
```
1. **조건**에서 다음을 지정합니다.
+ **평가 간격**에서 **1 minute**을 선택하여 PromQL 쿼리가 평가되는 빈도를 정의합니다.
+ **보류 기간**에 **120**을 입력합니다. 이 값은 ALARM 상태가 되기 전에 기고자가 위반해야 하는 기간을 초 단위로 입력한 값입니다.
+ **복구 기간**에 **300**을 입력합니다. 이 값은 OK 상태가 되기 전에 기고자가 위반하지 않아야 하는 기간을 초 단위로 입력한 값입니다.
1. 필요에 따라 알림 및 작업을 구성하세요.
1. 경보에 이름과 설명(선택 사항)을 추가하세요.
1. **다음**을 선택합니다.
1. **경보 생성**을 선택하세요.
## PromQL 경보 생성(AWS CLI)
[PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 작업을 사용하여 PromQL 경보를 생성합니다.
**Example 게이지 지표가 20 미만으로 떨어질 때 트리거되는 PromQL 경보 생성**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20"}}' \
--evaluation-interval 60
```
**Example 보류 기간이 있는 PromQL 경보 생성**
이 경보는 `ALARM` 상태로 전환되기 전에 300초(5분) 동안 대기하고, 복구되기 전에 600초(10분) 동안 대기합니다.
```
aws cloudwatch put-metric-alarm \
--alarm-name HighLatencyAlarm \
--evaluation-criteria '{"PromQLCriteria":{"Query":"histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5","PendingPeriod":300,"RecoveryPeriod":600}}' \
--evaluation-interval 60
```
**Example SNS 알림 작업이 포함된 PromQL 경보 생성**
```
aws cloudwatch put-metric-alarm \
--alarm-name MyPromQLAlarmWithAction \
--evaluation-criteria '{"PromQLCriteria":{"Query":"my_gauge_metric < 20","PendingPeriod":0,"RecoveryPeriod":0}}' \
--evaluation-interval 60 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:MyTopic
```
## Query Studio에서 PromQL 경보 생성
이 예제는 서비스의 평균 HTTP 요청 기간이 500밀리초를 초과할 때 이를 알리는 PromQL 경보를 Query Studio에서 생성하는 방법을 보여줍니다.
임계값이 별도의 단계로 구성된 표준 CloudWatch 경보와 달리 PromQL 경보는 경보 조건(임계값)을 쿼리 자체의 일부로 정의합니다. 예를 들어 비교 연산자(`>`)와 임계값(`0.5`)은 PromQL 표현식에 직접 포함됩니다.
**Query Studio에서 PromQL 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. **지표** 아래의 탐색 창에서 **Query Studio(미리 보기)**를 선택합니다.
1. 쿼리 언어 드롭다운 메뉴에서 **PromQL**을 선택합니다.
1. 다음 모드 중 하나를 사용하여 쿼리 빌드:
+ **빌더** 모드의 **지표** 필드에서 지표 이름(예: `http.server.request.duration`)을 선택합니다. 필요에 따라 레이블 필터를 추가합니다(예: `@resource.service.name` = `my-api`). 경보 임계값을 정의하려면 **기본 작업**(예: `>`)을 선택하고 **숫자**(예: `0.5`)를 입력합니다.
+ **코드** 모드에서 PromQL 표현식을 직접 입력합니다. 예:
```
histogram_avg({"http.server.request.duration", "@resource.service.name"="my-api"}) > 0.5
```
1. **실행**을 선택하여 쿼리를 실행하고 예상된 결과를 반환하는지 확인합니다.
1. 작업 메뉴에서 **경보 생성**을 선택합니다.
1. PromQL 쿼리가 미리 채워진 CloudWatch 경보 생성 페이지로 리디렉션됩니다.
1. **조건**에서 다음을 지정합니다.
+ **평가 간격**에서 **1 minute**을 선택하여 PromQL 쿼리가 평가되는 빈도를 정의합니다.
+ **보류 기간**에 **60**을 입력합니다. 이 값은 ALARM 상태가 되기 전에 쿼리가 위반해야 하는 기간을 초 단위로 입력한 값입니다. 즉, 경보가 실행되기 전에 지연 시간이 최소 60초 동안 임계값을 초과해야 합니다.
+ **복구 기간**에 **120**을 입력합니다. 이 값은 OK 상태가 되기 전에 쿼리가 위반하지 않아야 하는 기간을 초 단위로 입력한 값입니다. 즉, 경보가 복구되기 전에 지연 시간이 최소 120초 동안 임계값 미만을 유지해야 합니다.
1. 필요에 따라 알림 및 작업을 구성하세요.
1. 경보에 이름과 설명(선택 사항)을 추가하세요.
1. **다음**을 선택합니다.
1. **경보 생성**을 선택하세요.
**참고**
경보를 생성하려면 PromQL 쿼리가 단일 시계열을 반환해야 합니다. 쿼리가 여러 시계열을 반환하는 경우 경보 생성 전에 집계 함수(예: `sum`, `avg`, `topk`)를 사용하여 결과를 단일 시리즈로 줄입니다.
# 로그에 대한 경보
다음 섹션의 단계에서는 로그에 대한 CloudWatch 경보를 생성하는 방법을 설명합니다.
## 로그 그룹-지표 필터를 기반으로 CloudWatch 경보 생성
이 섹션의 절차는 로그 그룹 지표 필터를 기반으로 경보를 생성하는 방법을 설명합니다. 지표 필터를 사용하면 데이터가 CloudWatch로 전송될 때 로그 데이터에서 용어와 패턴을 찾을 수 있습니다. 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [필터를 사용하여 로그 이벤트에서 지표 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)을 참조하세요. 로그 그룹 지표 필터를 기반으로 경보를 생성하려면 먼저 다음 작업을 완료해야 합니다.
+ 로그 그룹 생성 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [로그 그룹 및 로그 스트림 작업](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group)을 참조하세요.
+ 지표 필터를 생성합니다. 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [Create a metric filter for a log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html)을 참조하세요.
**로그 그룹 지표 필터를 기반으로 경보 생성**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **로그**를 선택한 다음, **로그 그룹**을 선택합니다.
1. 지표 필터가 포함된 로그 그룹을 선택합니다.
1. **Metric filters**(지표 필터)를 선택합니다.
1. 지표 필터 탭에서 경보의 기반으로 사용할 지표 필터의 확인란을 선택합니다.
1. **경보 생성**을 선택하세요.
1. (선택 사항) **Metric**(지표)에서 **Metric name**(지표 이름), **Statistic**(통계) 및 **Period**(기간)를 편집합니다.
1. **조건**에서 다음을 지정합니다.
1. **임곗값 유형**에서 **정적** 또는 **이상 탐지**를 선택합니다.
1. **Whenever *your-metric-name* is . . .**(your-metric-name이 다음과 같은 경우에 항상…)에서 **Greater**(보다 큼), **Greater/Equal**(보다 크거나 같음), **Lower/Equal**(보다 작거나 같음) 또는 **Lower**(보다 작음)를 선택합니다.
1. **than . . .**(:)에 임곗값에 대한 숫자를 지정합니다.
1. **추가 구성**을 선택합니다.
1. **Data points to alarm**(경보를 보낼 데이터 포인트)에서 경보가 `ALARM` 상태로 전환되도록 트리거하는 데이터 포인트 수를 지정합니다. 일치하는 값을 지정하면 해당 기간이 연속적으로 위반되는 경우 경보가 `ALARM` 상태가 됩니다. N개 중 M번째 경보를 생성하려면 두 번째 값에 대해 지정한 숫자보다 작은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
1. **Missing data treatment**(누락된 데이터 처리)에서 경보가 평가될 때 누락된 데이터를 처리하는 방법을 지정하는 옵션을 선택합니다.
1. **다음**을 선택합니다.
1. **Notification**(알림)에서 경보가 `ALARM`, `OK` 또는 `INSUFFICIENT_DATA` 상태일 때 알림을 보낼 Amazon SNS 주제를 지정합니다.
1. (선택 사항) 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내려면 **Add notification**(알림 추가)을 선택합니다.
1. (선택 사항) 알림을 보내지 않으려면 **Remove**(제거)를 선택합니다.
1. 경보가 Auto Scaling, EC2, Lambda 또는 Systems Manager 작업을 수행하도록 하려면 해당 버튼을 선택하고 경보 상태와 수행할 작업을 선택합니다. Lambda 함수를 경보 작업으로 선택하는 경우 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택할 수 있습니다.
경보는 ALARM 상태가 될 때만 Systems Manager 작업을 수행할 수 있습니다. Systems Manager 작업에 대한 자세한 내용은 [경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 단원을 참조하세요.
**참고**
SSM Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. **Next**를 선택하세요.
1. **이름 및 설명**에서, 경보에 대한 이름과 설명을 입력하세요. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **Preview and create**(미리 보기 및 생성)에서 구성이 올바른지 확인한 다음 **Create alarm**(경보 생성)을 선택합니다.
# 복합 경보 생성
이 섹션의 단계에서는 CloudWatch 콘솔을 사용하여 복합 경보를 생성하는 방법을 설명합니다. API 또는 AWS CLI를 사용하여 복합 경보를 생성할 수도 있습니다. 자세한 내용은 [PutCompositeAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutCompositeAlarm.html) 또는 [put-composite-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-composite-alarm.html)을 참조하세요.
**복합 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택한 다음 **모든 경보(All alarms)**를 선택합니다.
1. 경보 목록에서, 규칙 표현식에서 참조하려는 각 기존 경보 옆에 있는 확인란을 선택한 다음 **Create composite alarm(복합 경보 생성)**을 선택합니다.
1. **Specify composite alarm conditions(복합 경보 조건 지정)**에서 새 복합 경보에 대한 규칙 표현식을 지정합니다.
**참고**
경보 목록에서 선택한 경보가 **Conditions(조건)** 상자에 자동으로 나열됩니다. 기본적으로, 각 경보에 대해 `ALARM` 함수가 지정되어 있으며, 각 경보는 논리 연산자 `OR`로 결합됩니다.
다음 하위 단계를 사용하여 규칙 표현식을 수정할 수 있습니다.
1. 각 경보의 필수 상태를 `ALARM`에서 `OK` 또는 `INSUFFICIENT_DATA`로 변경할 수 있습니다.
1. 규칙 표현식의 논리 연산자를 `OR`에서 `AND` 또는 `NOT`으로 변경할 수 있으며, 괄호를 추가하여 함수를 그룹화할 수 있습니다.
1. 규칙 표현식에 다른 경보를 포함하거나 규칙 표현식에서 경보를 삭제할 수 있습니다.
**예: 조건이 있는 규칙 표현식**
```
(ALARM("CPUUtilizationTooHigh") OR
ALARM("DiskReadOpsTooHigh")) AND
OK("NetworkOutTooHigh")
```
이 예제 규칙 표현식에서는 ALARM("CPUUtilizationTooHigh" 또는 "DiskReadOpsTooHigh")이 `ALARM` 상태이고 동시에 OK("NetworkOutTooHigh")가 `OK` 상태일 때 복합 경보가 `ALARM` 상태로 전환됩니다.
1. 마친 후에는 **다음**을 선택합니다.
1. **Configure actions**(작업 구성)에서 다음을 선택할 수 있습니다.
***Notification(알림)***에서
+ **Select an exisiting SNS topic**(기존 SNS 주제 선택), **Create a new SNS topic**(새 SNS 주제 생성) 또는 **Use a topic ARN**(주제 ARN 사용)을 선택하여 알림을 수신할 SNS 주제를 정의합니다.
+ **Add notification(알림 추가)**을 선택하여 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보냅니다.
+ **Remove**(제거)를 선택하여 경보가 알림을 보내거나 작업을 수행하지 않게 합니다.
(선택 사항) 상태가 변경될 때 경보가 Lambda 함수를 호출하도록 하려면 **Lambda 작업 추가**를 선택합니다. 그런 다음, 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택합니다.
***Systems Manager 작업(Systems Manager action)***에서
+ **Add Systems Manager action**(Systems Manager 작업 추가)을 선택하여 경보가 ALARM 상태로 전환될 경우 SSM 작업을 수행할 수 있게 합니다.
Systems Manager 작업에 대한 자세한 내용은 *AWS Systems Manager 사용 설명서*의 [경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)과 *Incident Manager 사용 설명서*의 [인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)을 참조하세요. SSM Incident Manager 작업을 수행하는 경보를 생성하려면 올바른 권한이 있어야 합니다. 자세한 내용은 *Incident Manager 사용 설명서*에서 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html)를 참조하세요.
경보가 조사가 시작되도록 하려면 **조사 작업 추가**를 선택한 다음 조사 그룹을 선택합니다. 자세한 내용은 [CloudWatch 조사](Investigations.md) 섹션을 참조하세요.
1. 마친 후에는 **다음**을 선택합니다.
1. **Add name and description**(이름 및 설명 추가)에 새 복합 경보의 경보 이름과 *선택 사항*인 설명을 입력합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. 마친 후에는 **다음**을 선택합니다.
1. **Preview and create**(미리 보기 및 생성)에서 정보를 확인한 다음 **Create composite alarm**(복합 경보 생성)을 선택합니다.
**참고**
하나의 복합 경보와 다른 복합 경보가 서로 종속되는 복합 경보의 주기를 생성할 수 있습니다. 이 시나리오에서는 복합 경보가 더 이상 평가되지 않으며, 서로 종속되어 있으므로 복합 경보를 삭제할 수 없습니다. 복합 경보 간의 종속 주기를 없애는 가장 쉬운 방법은 복합 경보 중 하나에서 `AlarmRule` 함수를 `False`로 변경하는 것입니다.
# 경보 변경에 따른 조치
CloudWatch는 경보의 상태가 변경될 때와 경보의 구성이 업데이트될 때 두 가지 유형의 경보 변경 사항을 사용자에게 알릴 수 있습니다.
경보가 평가할 때 ALARM 또는 OK와 같은 상태로 변경될 수 있습니다. 여러 시계열을 모니터링하는 Metrics Insights 경보의 경우 각 시계열(기여자)은 INSUFFICIENT\$1DATA 상태일 수 없고 ALARM 또는 OK 상태만 될 수 있습니다. 데이터가 있는 경우에만 시계열이 존재하기 때문입니다.
또한 CloudWatch는 경보 상태가 변경될 때마다 그리고 경보가 생성, 삭제 또는 업데이트될 때마다 Amazon EventBridge로 이벤트를 전송합니다. EventBridge가 이러한 이벤트를 수신할 때 조치를 취하거나 알림을 받도록 EventBridge 규칙을 작성할 수 있습니다.
경보 작업에 대한 자세한 내용은 [경보 작업](alarm-actions.md) 섹션을 참조하세요.
**Topics**
+ [경보 변경 시 사용자에게 알림](Notify_Users_Alarm_Changes.md)
+ [경보에서 Lambda 함수 간접 호출](alarms-and-actions-Lambda.md)
+ [경보에서 CloudWatch 조사를 시작](Start-Investigation-Alarm.md)
+ [EC2 인스턴스 중지, 종료, 재부팅 또는 복구](UsingAlarmActions.md)
+ [경보 이벤트 및 EventBridge](cloudwatch-and-eventbridge.md)
# 경보 변경 시 사용자에게 알림
이 섹션에서는 AWS 사용자 알림 또는 Amazon Simple Notification Service를 사용하여 사용자에게 경보 변경 사항을 알리는 방법을 설명합니다.
## AWS 사용자 알림 설정
[AWS 사용자 알림](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html)을 사용하여 CloudWatch 경보 상태 변경 및 구성 변경 이벤트에 대한 알림을 수신할 전송 채널을 설정할 수 있습니다. 이벤트가 지정한 규칙과 일치하면 알림을 받습니다. 이메일, [AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) 채팅 알림 또는 [AWS 콘솔 모바일 애플리케이션 푸시 알림](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/managing-notifications.html) 등 여러 채널을 통해 이벤트에 대한 알림을 받을 수 있습니다. [콘솔 알림 센터](https://console.aws.amazon.com/notifications)에서도 알림을 볼 수 있습니다. 사용자 알림은 집계를 지원하므로 특정 이벤트 중에 받는 알림 수를 줄일 수 있습니다.
AWS 사용자 알림을 사용하여 생성하는 알림 구성은 대상 경보 상태별로 구성할 수 있는 작업 수 제한에 포함되지 않습니다. AWS 사용자 알림은 특정 경보나 패턴을 허용 목록에 추가하거나 거부 목록에 추가하는 고급 필터를 지정하지 않는 한 Amazon EventBridge로 전송되는 이벤트와 일치하므로 계정 및 선택한 리전의 모든 경보에 대한 알림을 전송합니다.
다음 고급 필터의 예에서는 `ServerCpuTooHigh`라는 경보의 경보 상태가 OK에서 ALARM으로 변경된 경우와 일치합니다.
```
{
"detail": {
"alarmName": ["ServerCpuTooHigh"],
"previousState": { "value": ["OK"] },
"state": { "value": ["ALARM"] }
}
}
```
EventBridge 이벤트에서 경보가 게시한 모든 속성을 사용하여 필터를 생성할 수 있습니다. 자세한 내용은 [경보 이벤트 및 EventBridge](cloudwatch-and-eventbridge.md) 섹션을 참조하세요.
## Amazon SNS 알림 설정
Amazon Simple Notification Service를 사용하여 모바일 문자 메시지(SMS) 및 이메일 메시지를 포함하여 애플리케이션 간(A2A) 메시지와 애플리케이션 대 사람(A2P) 메시지를 모두 보낼 수 있습니다. 자세한 내용은 [Amazon SNS 이벤트 대상](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html)을 참조하세요.
경보가 취할 수 있는 모든 상태에 대해 SNS 주제에 메시지를 보내도록 경보를 구성할 수 있습니다. 특정 경보의 상태와 관련해 구성하는 모든 Amazon SNS 주제는 해당 경보 및 상태에 구성할 수 있는 작업 수 제한에 포함됩니다. 계정의 모든 경보에서 동일한 Amazon SNS 주제로 메시지를 보낼 수 있으며 애플리케이션(A2A) 및 사람(A2P) 소비자 모두에게 동일한 Amazon SNS 주제를 사용할 수 있습니다. 이 구성은 경보 수준에서 이루어지므로 구성한 경보만 선택한 Amazon SNS 항목으로 메시지를 전송합니다.
먼저, 주제를 생성한 다음 구독합니다. 선택적으로 테스트 메시지를 주제에 게시할 수 있습니다. 문제 해결 예는 [AWS Management Console을 사용하여 Amazon SNS 주제 설정](#set-up-sns-topic-console)을(를) 참조하세요. 또는 자세한 내용은 [Amazon SNS 시작하기](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html)를 참조하세요.
또는 AWS Management Console을 사용하여 CloudWatch 경보를 만들려는 경우 경보를 만들 때 주제를 만들 수 있으므로 이 절차를 건너뛰어도 됩니다.
CloudWatch 경보를 생성할 때 경보가 입력하는 모든 대상 상태에 대한 작업을 추가할 수 있습니다. 알림을 받으려는 상태에 대한 Amazon SNS 알림을 추가하고 이전 단계에서 만든 Amazon SNS 주제를 선택하여 경보가 선택한 상태에 진입할 때 이메일 알림을 보냅니다.
**참고**
Amazon SNS 주제를 생성할 때 해당 주제를 *표준 주제* 또는 *FIFO 주제*로 선택합니다. CloudWatch는 두 가지 유형의 주제에 대한 모든 경보 알림을 게시하도록 보장합니다. 그러나 FIFO 주제를 사용하더라도 CloudWatch가 순서에 맞지 않게 알림을 주제로 보내는 경우가 드물게 있습니다. FIFO 주제를 사용하는 경우 경보는 경보 알림의 메시지 그룹 ID를 경보의 ARN 해시로 설정합니다.
**Topics**
+ [혼동된 대리자 보안 문제 방지](#SNS_Confused_Deputy)
+ [AWS Management Console을 사용하여 Amazon SNS 주제 설정](#set-up-sns-topic-console)
+ [AWS CLI를 사용하여 SNS 주제 설정](#set-up-sns-topic-cli)
### 혼동된 대리자 보안 문제 방지
혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. AWS에서는 교차 서비스 가장으로 인해 혼동된 대리자 문제가 발생할 수 있습니다. 교차 서비스 가장은 한 서비스(*직접 호출하는 서비스*)가 다른 서비스(*직접 호출되는 서비스*)를 직접 호출할 때 발생할 수 있습니다. 직접 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다. 이를 방지하기 위해 AWS에서는 계정의 리소스에 대한 액세스 권한이 부여된 서비스 위탁자를 사용하여 모든 서비스에 대한 데이터를 보호하는 데 도움이 되는 도구를 제공합니다.
Amazon SNS가 리소스에 다른 서비스를 제공하는 권한을 제한하려면 리소스 정책에서 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount), [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) 및 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) 글로벌 조건 컨텍스트 키를 사용하는 것이 좋습니다. `aws:SourceArn`을 사용하면 하나의 리소스만 교차 서비스 액세스 권한과 연결됩니다. `aws:SourceAccount`를 사용하면 해당 계정의 모든 리소스가 교차 서비스 사용 권한과 연결됩니다. `aws:SourceOrgID`를 사용하면 조직 내 모든 계정의 모든 리소스가 교차 서비스 사용 권한과 연결될 수 있습니다. `aws:SourceOrgPaths`를 사용하면 AWS Organizations 경로 내 계정의 모든 리소스가 교차 서비스 사용 권한과 연결됩니다. 경로 사용 및 이해에 대한 자세한 내용은 IAM 사용 설명서의 [aws:SourceOrgPaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths)를 참조하세요.
혼동된 대리인 문제로부터 보호하는 가장 효과적인 방법은 리소스의 전체 ARN이 포함된 `aws:SourceArn`글로벌 조건 컨텍스트 키를 사용하는 것입니다. 리소스의 전체 ARN을 모르거나 여러 리소스를 지정하는 경우, ARN의 알 수 없는 부분에 대해 와일드카드 문자(`*`)를 포함한 `aws:SourceArn` 글로벌 조건 컨텍스트 키를 사용합니다. 예: `arn:aws:servicename:*:123456789012:*`
만약 `aws:SourceArn` 값에 Amazon S3 버킷 ARN과 같은 계정 ID가 포함되어 있지 않은 경우, 권한을 제한하려면 두 `aws:SourceAccount` 및 `aws:SourceArn`를 모두 사용해야 합니다.
혼동된 대리자 문제로부터 보호하려면 리소스 기반 정책에서 리소스의 조직 ID 또는 조직 경로와 함께 `aws:SourceOrgID` 또는 `aws:SourceOrgPaths` 글로벌 조건 컨텍스트 키를 사용합니다. `aws:SourceOrgID` 또는 `aws:SourceOrgPaths` 키가 포함된 정책에는 올바른 계정이 자동으로 포함되며 조직에서 계정을 추가, 제거 또는 이동할 때 정책을 수동으로 업데이트할 필요가 없습니다.
`aws:SourceArn`의 값은 알림을 보내는 경보의 ARN이어야 합니다.
다음 예제에서는 CloudWatch에서 `aws:SourceArn` 및 `aws:SourceAccount` 전역 조건 컨텍스트 키를 사용하여 혼동된 대리자 문제를 방지하는 방법을 보여줍니다.
```
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-2:444455556666:MyTopic",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudwatch:us-east-2:111122223333:alarm:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}]
}
```
경보 ARN에 ASCII가 아닌 문자가 포함된 경우 `aws:SourceAccount` 전역 조건 키만 사용하여 권한을 제한합니다.
### AWS Management Console을 사용하여 Amazon SNS 주제 설정
먼저, 주제를 생성한 다음 구독합니다. 선택적으로 테스트 메시지를 주제에 게시할 수 있습니다.
**SNS 주제를 생성하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. Amazon SNS 대시보드의 [**일반 작업(Common actions)**]에서 [**주제 생성(Create Topic)**]을 선택합니다.
1. **새로운 주제 생성** 대화 상자의 **주제 이름**에 주제 이름(예: **my-topic**)을 입력합니다.
1. **주제 생성**을 선택합니다.
1. 다음 태스크에 대한 [**주제 ARN(Topic ARN)**]을 복사합니다(예를 들어 arn:aws:sns:us-east-1:111122223333:my-topic).
**SNS 주제를 구독하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. 탐색 창에서 **구독**과 **구독 생성**을 선택합니다.
1. **구독 생성** 대화 상자의 **주제 ARN**에서 이전 작업에서 생성한 주제 ARN을 붙여 넣습니다.
1. **프로토콜**에서 **이메일**을 선택합니다.
1. **엔드포인트**에 알림을 받는 데 사용할 수 있는 이메일 주소를 입력한 다음 **구독 생성**을 선택합니다.
1. 이메일 애플리케이션에서 AWS 알림에서 보낸 메시지를 연 다음, 구독을 확인합니다.
웹 브라우저에 Amazon SNS의 확인 응답이 표시됩니다.
**SNS 주제에 테스트 메시지를 게시하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. 탐색 창에서 **주제**를 선택합니다.
1. **주제** 페이지에서 주제를 선택하고 **주제 게시**를 선택합니다.
1. **메시지 게시** 페이지의 **제목**에 메시지에 대한 제목 줄을 입력하고 **메시지**에 간단한 메시지를 입력합니다.
1. **메시지 게시**를 선택합니다.
1. 해당 메시지를 받았는지 이메일을 확인합니다.
### AWS CLI를 사용하여 SNS 주제 설정
먼저 SNS 주제를 생성한 다음, 해당 주제에 직접 메시지를 게시해서 제대로 구성이 되었는지 테스트합니다.
**SNS 주제를 설정하려면**
1. 아래와 같이 [create-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/create-topic.html) 명령을 사용하여 주제를 생성합니다.
```
1. aws sns create-topic --name my-topic
```
Amazon SNS는 다음 형식의 주제 ARN을 반환합니다.
```
1. {
2. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic"
3. }
```
1. [subscribe](https://docs.aws.amazon.com/cli/latest/reference/sns/subscribe.html) 명령을 사용하여 구독 이메일 주소를 주제에 연결합니다. 구독 요청이 성공하면 구독 확인 이메일 메시지를 받게 됩니다.
```
1. aws sns subscribe --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic --protocol email --notification-endpoint my-email-address
```
Amazon SNS는 다음을 반환합니다.
```
1. {
2. "SubscriptionArn": "pending confirmation"
3. }
```
1. 이메일 애플리케이션에서 AWS 알림에서 보낸 메시지를 연 다음, 구독을 확인합니다.
웹 브라우저에 Amazon Simple Notification Service의 확인 응답이 표시됩니다.
1. [list-subscriptions-by-topic](https://docs.aws.amazon.com/cli/latest/reference/sns/list-subscriptions-by-topic.html) 명령을 사용하여 구독을 확인합니다.
```
1. aws sns list-subscriptions-by-topic --topic-arn arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS는 다음을 반환합니다.
```
1. {
2. "Subscriptions": [
3. {
4. "Owner": "111122223333",
5. "Endpoint": "me@mycompany.com",
6. "Protocol": "email",
7. "TopicArn": "arn:aws:sns:us-east-1:111122223333:my-topic",
8. "SubscriptionArn": "arn:aws:sns:us-east-1:111122223333:my-topic:64886986-bf10-48fb-a2f1-dab033aa67a3"
9. }
10. ]
11. }
```
1. (선택 사항) [publish](https://docs.aws.amazon.com/cli/latest/reference/sns/publish.html) 명령을 사용하여 해당 주제로 테스트 메시지를 게시합니다.
```
1. aws sns publish --message "Verification" --topic arn:aws:sns:us-east-1:111122223333:my-topic
```
Amazon SNS는 다음을 반환합니다.
```
1. {
2. "MessageId": "42f189a0-3094-5cf6-8fd7-c2dde61a4d7d"
3. }
```
1. 해당 메시지를 받았는지 이메일을 확인합니다.
## 경보의 상태 변경 시 Amazon SNS 알림 스키마
이 섹션에는 경보의 상태가 변경될 때 Amazon SNS 주제로 전송되는 알림의 스키마가 나열되어 있습니다.
**지표 경보의 상태 변경 시 스키마**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"AlarmConfigurationUpdatedTimestamp": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OldStateValue": "string",
"OKActions": ["string"],
"AlarmActions": ["string"],
"InsufficientDataActions": ["string"],
"Trigger": {
"MetricName": "string",
"Namespace": "string",
"StatisticType": "string",
"Statistic": "string",
"Unit": "string or null",
"Dimensions": [
{
"value": "string",
"name": "string"
}
],
"Period": "integer",
"EvaluationPeriods": "integer",
"DatapointsToAlarm": "integer",
"ComparisonOperator": "string",
"Threshold": "number",
"TreatMissingData": "string",
"EvaluateLowSampleCountPercentile": "string or null"
}
}
```
**복합 경보의 상태 변경 시 스키마**
```
{
"AlarmName": "string",
"AlarmDescription": "string",
"AWSAccountId": "string",
"NewStateValue": "string",
"NewStateReason": "string",
"StateChangeTime": "string",
"Region": "string",
"AlarmArn": "string",
"OKActions": [String],
"AlarmActions": [String],
"InsufficientDataActions": [String],
"OldStateValue": "string",
"AlarmRule": "string",
"TriggeringChildren": [String]
}
```
# 경보에서 Lambda 함수 간접 호출
CloudWatch 경보는 주어진 상태 변경에 대해 Lambda 함수의 비동기 호출을 보장합니다. 단, 다음과 같은 경우는 예외입니다.
+ 함수가 존재하지 않는 경우.
+ CloudWatch가 Lambda 함수를 호출할 권한이 없는 경우.
CloudWatch가 Lambda 서비스에 연결할 수 없거나 다른 이유로 메시지가 거부된 경우, CloudWatch는 호출이 성공할 때까지 재시도합니다. Lambda는 메시지를 대기열에 추가하여 실행 재시도를 처리합니다. Lambda가 오류를 처리하는 방법에 대한 정보 등 이 실행 모델에 대한 자세한 내용은 AWS Lambda 개발자 안내서의 [비동기 호출](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)을 참조하세요.
동일한 계정이나 다른 AWS 계정에서 Lambda 함수를 호출할 수 있습니다.
Lambda 함수를 경보 작업으로 간접적으로 호출하도록 경보를 지정하는 경우 함수 이름, 함수 별칭 또는 특정 버전의 함수를 지정하도록 선택할 수 있습니다.
Lambda 함수를 경보 작업으로 지정할 때 CloudWatch 서비스 보안 주체가 함수를 호출할 수 있도록 함수에 대한 리소스 정책을 생성해야 합니다.
이를 수행하는 한 가지 방법은 다음 예제와 같이 AWS CLI를 사용하는 것입니다.
```
aws lambda add-permission \
--function-name my-function-name \
--statement-id AlarmAction \
--action 'lambda:InvokeFunction' \
--principal lambda.alarms.cloudwatch.amazonaws.com \
--source-account 111122223333 \
--source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name
```
또는 다음 예제 중 하나와 비슷한 정책을 생성한 다음, 함수에 할당할 수 있습니다.
다음 예제에서는 경보가 있는 계정을 지정하여 해당 계정(111122223333)의 경보만 함수를 간접적으로 호출할 수 있도록 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
}]
}
```
------
다음 예제는 범위가 좁아 지정된 계정의 지정된 경보만 함수를 간접적으로 호출할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "AlarmAction",
"Effect": "Allow",
"Principal": {
"Service": "lambda.alarms.cloudwatch.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333",
"AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name"
}
}
}]
}
```
------
소스 계정을 지정하지 않는 정책은 혼동된 대리자 문제에 취약하므로 이러한 정책은 생성하지 않는 것이 좋습니다.
## CloudWatch 조사에 Lambda 지표 추가
활성 CloudWatch 조사에 Lambda 지표를 추가할 수 있습니다. 문제를 조사할 때 Lambda 지표는 함수 성능 및 동작에 대한 중요한 인사이트를 제공할 수 있습니다. 예를 들어 애플리케이션 성능 문제를 조사하는 경우 기간, 오류율 또는 스로틀과 같은 Lambda 지표가 근본 원인을 식별하는 데 도움이 될 수 있습니다.
CloudWatch 조사에 Lambda 지표를 추가하는 방법:
1. [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/)에서 AWS Lambda 콘솔을 엽니다.
1. **모니터링** 섹션에서 지표를 찾습니다.
1. 지표의 컨텍스트 메뉴를 열고 **조사**, **조사에 추가**를 선택하세요. 그런 다음 **조사** 창에서 조사 이름을 선택하세요.
## CloudWatch에서 Lambda로 전송된 이벤트 객체
Lambda 함수를 경보 작업으로 구성하면 CloudWatch는 함수를 간접적으로 호출할 때 Lambda 함수에 JSON 페이로드를 전송합니다. 이 JSON 페이로드는 함수의 이벤트 객체 역할을 합니다. 이 JSON 객체에서 데이터를 추출하여 함수에 사용할 수 있습니다. 다음은 지표 경보의 이벤트 객체에 대한 예제입니다.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm',
'accountId': '444455556666',
'time': '2023-08-04T12:36:15.490+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'lambda-demo-metric-alarm',
'state': {
'value': 'ALARM',
'reason': 'test',
'timestamp': '2023-08-04T12:36:15.490+0000'
},
'previousState': {
'value': 'INSUFFICIENT_DATA',
'reason': 'Insufficient Data: 5 datapoints were unknown.',
'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}',
'timestamp': '2023-08-04T12:31:29.595+0000'
},
'configuration': {
'description': 'Metric Alarm to test Lambda actions',
'metrics': [
{
'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c',
'metricStat': {
'metric': {
'namespace': 'AWS/Logs',
'name': 'CallCount',
'dimensions': {
'InstanceId': 'i-12345678'
}
},
'period': 60,
'stat': 'Average',
'unit': 'Percent'
},
'returnData': True
}
]
}
}
}
```
다음은 복합 경보의 이벤트 객체에 대한 예제입니다.
```
{
'source': 'aws.cloudwatch',
'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main',
'accountId': '111122223333',
'time': '2023-08-04T12:56:46.138+0000',
'region': 'us-east-1',
'alarmData': {
'alarmName': 'CompositeDemo.Main',
'state': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:56:46.138+0000'
},
'previousState': {
'value': 'ALARM',
'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC',
'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}',
'timestamp': '2023-08-04T12:54:46.138+0000',
'actionsSuppressedBy': 'WaitPeriod',
'actionsSuppressedReason': 'Actions suppressed by WaitPeriod'
},
'configuration': {
'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)',
'actionsSuppressor': 'CompositeDemo.ActionsSuppressor',
'actionsSuppressorWaitPeriod': 120,
'actionsSuppressorExtensionPeriod': 180
}
}
}
```
# 경보에서 CloudWatch 조사를 시작
경보에서 또는 CloudWatch 경보 기록의 마지막 2주에 속하는 임의의 시점에서 CloudWatch 조사를 시작할 수 있습니다.
CloudWatch 조사에 관한 자세한 내용은 [CloudWatch 조사](Investigations.md) 섹션을 참조하세요.
## 사전 조건
CloudWatch 경보에서 CloudWatch 조사를 시작하려면 먼저 CloudWatch 서비스 위탁자가 조사를 시작할 수 있도록 함수에 대한 리소스 정책을 생성해야 합니다. AWS CLI를 사용하여 이 작업을 수행하려면 다음 예제와 유사한 명령을 사용합니다.
```
aws aiops put-investigation-group-policy \
--identifier arn:aws:aiops:us-east-1:111122223333:investigation-group/investigation_group_id \
--policy "{\"Version\":\"2008-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"aiops.alarms.cloudwatch.amazonaws.com\"},\"Action\":[\"aiops:CreateInvestigation\",\"aiops:CreateInvestigationEvent\"],\"Resource\":\"*\",\"Condition\":{\"StringEquals\":{\"aws:SourceAccount\":\"111122223333\"},\"ArnLike\":{\"aws:SourceArn\":\"arn:aws:cloudwatch:us-east-1:111122223333:alarm:*\"}}}]}" \
--region eu-north-1
```
예제 값을 자체 AWS 계정 ID, 리전 및 조사 그룹 ID로 바꿉니다.
**CloudWatch 경보에서 조사를 시작**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **경보**, **모든 경보**를 선택합니다.
1. 경보 이름을 선택합니다.
1. 조사하려는 경보 기록에서 기간을 선택합니다.
1. **조사**, **새 조사 시작**을 선택합니다.
1. **New investigation title**에 조사 이름을 입력합니다. 그런 다음, **Start investigation**을 선택합니다.
CloudWatch 조사 어시스턴트는 원격 분석 데이터를 시작 및 스캔하여 이 상황과 관련이 있을 수 있는 데이터를 찾습니다.
1. CloudWatch 콘솔의 탐색 창에서 **조사**를 선택한 다음 방금 시작한 조사의 이름을 선택합니다.
**조사 결과** 섹션에는 경보의 상태와 경보가 트리거된 이유에 대한 요약이 자연어로 표시됩니다.
1. (선택 사항) 경보 그래프에서 오른쪽 버튼을 클릭한 다음, 경보 또는 해당 경보가 감시하는 지표를 심층 분석하도록 선택하세요.
1. 화면 오른쪽에서 **제안 사항** 탭을 선택합니다.
CloudWatch 조사에서 발견했으며 조사와 관련이 있을 수 있는 다른 원격 분석 목록이 표시됩니다. 이러한 조사 결과에는 기타 지표 및 CloudWatch Logs Insights 쿼리 결과가 포함될 수 있습니다. CloudWatch 조사는 경보를 기반으로 이러한 쿼리를 실행했습니다.
+ 각 조사 결과에 대해 **조사 결과에 추가** 또는 **무시**를 선택하세요.
**조사 결과에 추가**를 선택하면 원격 분석이 **조사 결과** 섹션에 추가되고, CloudWatch 조사에서 이 정보를 사용하여 추가 스캔 및 제안 사항을 지시합니다.
+ CloudWatch Logs Insights 쿼리 결과의 경우 쿼리를 변경 또는 편집하고 다시 실행하려면, 결과별로 컨텍스트 메뉴(오른쪽 버튼 클릭)를 연 다음 **Logs Insights에서 열기**를 선택하세요. 자세한 내용은 [CloudWatch Logs Insights를 사용한 로그 분석](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)을 참조하세요.
다른 쿼리를 실행하기 위해 Logs Insights 페이지로 이동한 경우 쿼리 지원을 사용하여 자연어로 쿼리를 구성하도록 선택하세요. 자세한 내용은 [자연어를 사용하여 CloudWatch Log Insights 쿼리 생성 및 업데이트](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs-Insights-Query-Assist.html)를 참조하세요.
+ (선택 사항) 이 조사에 적용될 수 있는 다른 AWS 서비스의 원격 분석에 대해 알고 있는 경우, 해당 서비스의 콘솔로 이동하여 원격 분석을 조사에 추가하세요.
1. CloudWatch 조사는 **제안** 탭의 목록에 가설을 추가할 수도 있습니다. 이러한 가설은 조사를 통해 자연어로 생성됩니다.
각 가설에 대해 **조사 결과에 추가** 또는 **무시**를 선택하세요.
1. 조사를 완료했고 문제의 근본 원인을 찾았다고 생각되면 **개요** 탭을 선택한 다음 **조사 요약**을 선택하세요. 이렇게 하면 CloudWatch 조사는 조사의 중요한 조사 결과 및 가설에 대한 요약을 자연어로 생성합니다.
# EC2 인스턴스 중지, 종료, 재부팅 또는 복구
Amazon CloudWatch 경보 작업을 사용하면 EC2 인스턴스를 자동으로 중지, 종료, 재부팅 또는 복구하는 경보를 생성할 수 있습니다. 인스턴스를 더 이상 실행할 필요가 없을 때 중지 또는 종료 작업을 사용하여 비용을 절약할 수 있습니다. 재부팅 및 복구 작업을 사용하면 시스템 장애가 발생할 경우 인스턴스를 자동으로 재부팅하거나 새로운 하드웨어로 인스턴스를 복구할 수 있습니다.
인스턴스를 자동으로 중지하거나 종료해야 하는 경우는 매우 다양합니다. 예를 들어 일정 기간 동안 실행한 다음 작업을 완료하는 일괄 급여 처리 작업 또는 과학적 컴퓨팅 작업 전용 인스턴스가 있을 수 있습니다. 이러한 인스턴스를 유휴 상태로 유지하여 비용이 발생하도록 하는 대신 중지하거나 종료하면 비용을 절감할 수 있습니다. 경보 작업 중지와 종료 간의 주요 차이는 나중에 다시 실행해야 하는 경우 중지된 인스턴스는 쉽게 다시 시작할 수 있다는 점입니다. 또한 동일한 인스턴스 ID 및 루트 볼륨을 유지할 수 있습니다. 그러나 종료된 인스턴스를 다시 시작할 수는 없습니다. 대신, 새 인스턴스를 시작해야 합니다.
Amazon CloudWatch에서 제공하는 기본 및 세부 모니터링 지표(AWS/EC2 네임스페이스)를 비롯한 Amazon EC2 인스턴스별 지표 및 InstanceId 값이 실행 중인 유효한 Amazon EC2 인스턴스를 참조하는 동안에 "InstanceId=" 차원을 포함하는 사용자 지정 지표에 대해 설정된 경보에 중지, 종료 또는 재부팅 작업을 추가할 수 있습니다. `StatusCheckFailed_Instance`를 제외하고 인스턴스당 Amazon EC2 지표에 설정된 경보에 복구 작업을 추가할 수도 있습니다.
**중요**
Amazon EC2 지표에 구성된 경보는 누락된 지표 데이터 포인트가 있는 경우 일시적으로 INSUFICITENT\$1DATA 상태로 전환될 수 있습니다. 드물기는 하지만, Amazon EC2 인스턴스가 정상인 경우에도 지표 보고가 중단되면 이 문제가 발생할 수 있습니다. 중지, 종료, 재부팅 또는 복구 작업을 수행하도록 구성된 Amazon EC2 지표에 대한 경보의 경우 누락된 데이터를 `missing`으로 처리하고 경보 상태일 때만 해당 경보를 트리거하도록 경보를 구성하는 것이 좋습니다.
경보가 설정된 누락된 지표에 대해 조치를 취하도록 CloudWatch를 구성하는 방법에 대한 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 섹션을 참조하세요.
인스턴스를 재부팅, 중지 또는 종료할 수 있는 CloudWatch 경보 작업을 설정하려면 서비스 연결 IAM 역할인 *AWSServiceRoleForCloudWatchEvents*를 사용해야 합니다. AWSServiceRoleForCloudWatchEvents IAM 역할을 사용하면 AWS가 사용자를 대신하여 경보 작업을 수행할 수 있습니다.
CloudWatch Events에 대한 서비스 연결 역할을 생성하려면 다음 명령을 사용합니다.
```
aws iam create-service-linked-role --aws-service-name events.amazonaws.com
```
**콘솔 지원**
CloudWatch 콘솔 또는 Amazon EC2 콘솔을 사용하여 경보를 생성할 수 있습니다. 이 설명서의 절차에서는 CloudWatch 콘솔을 사용합니다. Amazon EC2 콘솔을 사용하는 절차는 *Amazon EC2 사용 설명서*의 [인스턴스를 중지, 종료, 재부팅 또는 복구하는 경보 만들기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html)를 참조하세요.
**권한**
AWS Identity and Access Management(IAM) 계정을 사용하여 EC2 작업 또는 Systems Manager OpsItem 작업을 수행하는 경보를 생성하거나 수정하는 경우 `iam:CreateServiceLinkedRole` 권한이 있어야 합니다.
**Topics**
+ [Amazon CloudWatch 경보에 중지 작업 추가하기](#AddingStopActions)
+ [Amazon CloudWatch 경보에 종료 작업 추가하기](#AddingTerminateActions)
+ [Amazon CloudWatch 경보에 재부팅 작업 추가하기](#AddingRebootActions)
+ [Amazon CloudWatch 경보에 복구 작업 추가하기](#AddingRecoverActions)
+ [트리거한 경보 및 작업 기록 보기](#ViewAlarmHistory)
## Amazon CloudWatch 경보에 중지 작업 추가하기
특정 임계값에 도달한 경우 Amazon EC2 인스턴스를 중지하는 경보를 만들 수 있습니다. 예를 들어 개발 또는 테스트 인스턴스를 실행한 후 종료하는 것을 잊을 수 있습니다. 24시간 동안 평균 CPU 사용률이 10% 아래로 떨어지는 경우 즉, 유휴 상태로 더 이상 사용되지 않는 경우 트리거되는 경보를 만들 수 있습니다. 필요에 맞춰 임계값 및 기간을 조정할 수 있습니다. 또한 경보가 트리거되면 이메일을 받을 수 있도록 SNS 알림을 추가할 수 있습니다.
Amazon Elastic Block Store 볼륨을 루트 디바이스로 사용하는 Amazon EC2 인스턴스는 중지하거나 종료할 수 있지만, 인스턴스 스토어를 루트 디바이스로 사용하는 인스턴스는 종료만 할 수 있습니다.
**Amazon CloudWatch 콘솔을 사용하여 유휴 인스턴스를 중지하는 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)** **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성(Create alarm)**을 선택하세요.
1. **지표 선택(Select Metric)**을 선택합니다.
1. **AWS 네임스페이스( namespaces)**에서 **EC2**를 선택합니다.
1. 해결 방법:
1. **인스턴스별 지표(Per-Instance Metrics)**를 선택합니다.
1. 해당 인스턴스와 **CPUUtilization** 지표가 있는 행에서 확인란을 선택합니다.
1. **그래프로 표시된 지표** 탭을 선택합니다.
1. 통계의 경우 **평균(Average)**을 선택합니다.
1. 기간(예: **1 Hour**)을 선택합니다.
1. **지표 선택**을 선택합니다.
1. **조건(Conditions)**에서 다음을 수행하십시오:
1. **Static**(정적)을 선택합니다.
1. **CPUUtilization이 있는 경우 항상(Whenever CPUUtilization is)**에서 **낮음(Lower)**을 선택합니다.
1. **보다(than)**에 **10**을 입력합니다.
1. **다음(Next)**을 선택합니다.
1. **알림(Notification)**의 **알림 보내기(Send notification to)**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
SNS 주제를 생성하려면 **새 목록(New list)**을 선택합니다. **알림 보내기(Send notification to)**에 SNS 주제의 이름을 입력합니다(예: Stop\$1EC2\$1Instance). **이메일 목록(Email list)**에서 경보가 `ALARM` 상태로 변경될 때 알림을 받을 이메일 주소 목록을 쉼표로 구분하여 입력합니다. 각 이메일 주소로 주제 구독 확인 이메일이 전송됩니다. 수신자가 구독을 확인해야만 이 이메일 주소로 알림이 전송될 수 있습니다.
1. **EC2 작업 추가(Add EC2 Action)**를 선택합니다.
1. **경보 상태 트리거(Alarm state trigger)**에서 **경보(In Alarm)**를 선택합니다. **다음 작업 수행(Take the following action)**에서 **이 인스턴스 중지(Stop this instance)**를 선택합니다.
1. **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 이름은 ASCII 문자만 포함해야 합니다. 그리고 **다음(Next)**을 선택합니다.
1. **미리 보기 및 생성(Preview and create)**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성(Create alarm)**을 선택합니다.
## Amazon CloudWatch 경보에 종료 작업 추가하기
인스턴스에 대해 종료 보호가 비활성화되어 있는 경우에 한해서 특정 임계값에 도달한 경우 EC2 인스턴스를 자동으로 종료하는 경보를 만들 수 있습니다. 예를 들어 인스턴스의 작업 완료 후 해당 인스턴스가 다시 필요 없는 경우 인스턴스를 종료하려고 할 수 있습니다. 나중에 인스턴스를 사용하려는 경우에는 종료하지 말고 중지해야 합니다. 인스턴스에 대한 종료 보호 사용 및 사용 중지에 대한 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스에 대한 종료 보호 활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_ChangingDisableAPITermination.html) 섹션을 참조하세요.
**Amazon CloudWatch 콘솔을 사용하여 유휴 인스턴스를 종료하는 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **경보 생성(Create Alarm)**을 선택합니다.
1. **지표 선택(Select Metric)** 단계에서 다음을 수행합니다.
1. **EC2 지표(EC2 Metrics)**에서 **인스턴스별 지표(Per-Instance Metrics)**를 선택합니다.
1. 해당 인스턴스와 **CPUUtilization** 지표가 있는 행을 선택합니다.
1. 통계의 경우 **평균(Average)**을 선택합니다.
1. 기간(예: **1 Hour**)을 선택합니다.
1. **다음**을 선택합니다.
1. **경보 정의(Define Alarm)** 단계에서 다음을 수행합니다.
1. **경보 임계값(Alarm Threshold)**에 경보의 고유 이름(예: Terminate EC2 instance)과 경보에 대한 설명(예: CPU 유휴 시간이 너무 길어서 EC2 인스턴스 종료)을 입력합니다. 경보 이름은 ASCII 문자만 포함해야 합니다.
1. **Whenever**의 **is**에서 **<**를 선택하고 **10**을 입력합니다. **기간(for)**에 연속 기간으로 **24**를 입력합니다.
**경보 미리 보기(Alarm Preview)** 아래에 임계값이 그래픽으로 표시됩니다.
1. **알림(Notification)**의 **알림 보내기(Send notification to)**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
SNS 주제를 생성하려면 **새 목록(New list)**을 선택합니다. **알림 보내기(Send notification to)**에 SNS 주제의 이름을 입력합니다(예: Terminate\$1EC2\$1Instance). **이메일 목록(Email list)**에서 경보가 `ALARM` 상태로 변경될 때 알림을 받을 이메일 주소 목록을 쉼표로 구분하여 입력합니다. 각 이메일 주소로 주제 구독 확인 이메일이 전송됩니다. 수신자가 구독을 확인해야만 이 이메일 주소로 알림이 전송될 수 있습니다.
1. **EC2 작업(EC2 Action)**을 선택합니다.
1. **이 경보가 발생할 경우 항상(Whenever this alarm)**에 **상태가 ALARM입니다(State is ALARM)**를 선택합니다. **이 작업을 수행(Take this action)**에서 **인스턴스 종료(Terminate this instance)**를 선택합니다.
1. **경보 생성**을 선택합니다.
## Amazon CloudWatch 경보에 재부팅 작업 추가하기
Amazon EC2 인스턴스를 모니터링하고 인스턴스를 자동으로 재부팅하는 Amazon CloudWatch 경보를 만들 수 있습니다. 재부팅 경보 작업은 인스턴스 상태 확인 오류(복구 경보 작업은 시스템 상태 확인 오류에 적합)에 권장됩니다. 인스턴스 재부팅은 운영 체제 재부팅과 같습니다. 대부분의 경우 인스턴스를 재부팅하는 데는 몇 분 밖에 걸리지 않습니다. 인스턴스를 재부팅하는 경우 동일한 물리적 호스트에 남아 있으므로 퍼블릭 DNS 이름, 프라이빗 IP 주소 및 인스턴스 저장소 볼륨의 모든 데이터가 유지됩니다.
인스턴스를 재부팅해도 인스턴스를 중지했다가 다시 시작할 때와는 달리 새 인스턴스 청구 시간이 시작되지 않습니다. 인스턴스 재부팅에 대한 자세한 내용은 **Amazon EC2 사용 설명서의 [인스턴스 재부팅](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html) 섹션을 참조하세요.
**중요**
재부팅과 복원 작업 간에 경합 상태가 발생하지 않도록 하려면 재부팅 경보와 복원 경보에 동일한 평가 기간을 설정하지 마십시오. 재부팅 경보를 각각 1분의 평가 기간 3회로 설정하는 것이 좋습니다.
**Amazon CloudWatch 콘솔을 사용하여 인스턴스를 재부팅하는 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **경보 생성(Create Alarm)**을 선택합니다.
1. **지표 선택(Select Metric)** 단계에서 다음을 수행합니다.
1. **EC2 지표(EC2 Metrics)**에서 **인스턴스별 지표(Per-Instance Metrics)**를 선택합니다.
1. 해당 인스턴스와 **StatusCheckFailed\$1Instance** 지표가 있는 행을 선택합니다.
1. 통계의 경우 **최소(Minimum)**를 선택합니다.
1. 기간(예: **1 Minute**)을 선택합니다.
1. **다음**을 선택합니다.
1. **경보 정의(Define Alarm)** 단계에서 다음을 수행합니다.
1. **경보 임계값(Alarm Threshold)**에 경보의 고유 이름(예: Reboot EC2 instance)과 경보에 대한 설명(예: CPU 유휴 시간이 너무 길어서 EC2 인스턴스 재부팅)을 입력합니다. 경보 이름은 ASCII 문자만 포함해야 합니다.
1. **Whenever**의 **is**에서 **>**를 선택하고 **0**을 입력합니다. **기간(for)**에 연속 기간으로 **3**를 입력합니다.
**경보 미리 보기(Alarm Preview)** 아래에 임계값이 그래픽으로 표시됩니다.
1. **알림(Notification)**의 **알림 보내기(Send notification to)**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
SNS 주제를 생성하려면 **새 목록(New list)**을 선택합니다. **알림 보내기(Send notification to)**에 SNS 주제의 이름을 입력합니다(예: Reboot\$1EC2\$1Instance). **이메일 목록(Email list)**에서 경보가 `ALARM` 상태로 변경될 때 알림을 받을 이메일 주소 목록을 쉼표로 구분하여 입력합니다. 각 이메일 주소로 주제 구독 확인 이메일이 전송됩니다. 수신자가 구독을 확인해야만 이 이메일 주소로 알림이 전송될 수 있습니다.
1. **EC2 작업(EC2 Action)**을 선택합니다.
1. **이 경보가 발생할 경우 항상(Whenever this alarm)**에 **상태가 ALARM입니다(State is ALARM)**를 선택합니다. **이 작업을 수행(Take this action)**에서 **인스턴스 재부팅(Reboot this instance)**을 선택합니다.
1. **경보 생성**을 선택합니다.
## Amazon CloudWatch 경보에 복구 작업 추가하기
Amazon EC2 인스턴스를 모니터링하고 기본 하드웨어 장애나 복구에 AWS 개입이 필요한 문제로 인해 인스턴스가 손상된 경우 인스턴스를 자동으로 복구하는 Amazon CloudWatch 경보를 생성할 수 있습니다. 종료한 인스턴스는 복구할 수 없습니다. 복구된 인스턴스는 인스턴스 ID, 프라이빗 IP 주소, 탄력적 IP 주소 및 모든 인스턴스 메타데이터를 포함하여 원본 인스턴스와 동일합니다.
`StatusCheckFailed_System` 경보가 트리거되고 복구 작업이 시작되면 경보를 생성하고 복구 작업을 연결했을 때 선택한 Amazon SNS 주제로 알림을 받게 됩니다. 인스턴스 복구 중에 인스턴스를 재부팅할 때 인스턴스가 마이그레이션되고 모든 인 메모리 데이터가 손실됩니다. 프로세스가 완료되면 해당 경보를 위해 구성해 둔 SNS 주제로 정보가 게시됩니다. 이 SNS 주제에 가입되어 있는 사람은 누구나 복구 시도 상태와 세부 지침이 포함된 이메일 알림을 받게 됩니다. 복구된 인스턴스에서 인스턴스를 재부팅하라는 메시지가 나타납니다.
복구 작업은 `StatusCheckFailed_Instance`가 아닌 `StatusCheckFailed_System`을 통해서만 사용할 수 있습니다.
시스템 상태 확인이 실패하게 되는 문제의 예를 들면 다음과 같습니다.
+ 네트워크 연결 끊김
+ 시스템 전원 중단
+ 물리적 호스트의 소프트웨어 문제
+ 네트워크 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
복구 작업은 일부 인스턴스 유형에서만 지원됩니다. 지원되는 인스턴스 유형과 기타 요구 사항에 대한 자세한 내용은 [인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)와 [요구 사항](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html#requirements-for-recovery)을 참조하세요.
**중요**
재부팅과 복원 작업 간에 경합 상태가 발생하지 않도록 하려면 재부팅 경보와 복원 경보에 동일한 평가 기간을 설정하지 마십시오. 복원 경보는 각각 1분의 평가 기간 2회로 설정하고 재부팅 경보는 각각 1분의 평가 기간 3회로 설정하는 것이 좋습니다.
**Amazon CloudWatch 콘솔을 사용하여 인스턴스를 복구하는 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)** **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성**을 선택합니다.
1. **지표 선택**을 선택하고 다음 중 하나를 수행합니다.
1. **EC2 지표**에서 **인스턴스별 지표**를 선택합니다.
1. 해당 인스턴스와 **StatusCheckFailed\$1System** 지표가 있는 행을 선택한 다음 **지표 선택**을 선택합니다.
1. 통계의 경우 **최소(Minimum)**를 선택합니다.
1. 기간(예: **1 Minute**)을 선택합니다.
**중요**
재부팅과 복원 작업 간에 경합 상태가 발생하지 않도록 하려면 재부팅 경보와 복원 경보에 동일한 평가 기간을 설정하지 마십시오. 복구 경보는 각각 1분의 평가 기간 2회로 설정하는 것이 좋습니다.
1. **조건**에서 다음을 수행합니다.
1. **임계값 유형**에서 **정적**을 선택합니다.
1. **언제든지**에서 **큰 값**을 선택하고 **...보다**에 **0**을 입력합니다.
1. **추가 구성**을 선택한 다음 **경보를 생성할 데이터 포인트**에 대해 2개 **중** 2개를 지정합니다.
1. **다음**을 선택합니다.
1. **알림**에서 다음을 수행합니다.
1. **경보 상태 트리거**에서 **경보**를 선택합니다.
1. **다음 SNS 주제에 알림 보내기**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
1. **EC2 작업 추가(Add EC2 Action)**를 선택합니다.
1. **경보 상태 트리거(Alarm state trigger)**에서 **경보(In Alarm)**를 선택합니다.
1. **다음 작업 수행**에서 **이 인스턴스 복구**를 선택합니다.
1. **다음**을 선택합니다.
1. **경보 이름**에 경보의 고유한 이름(예: **Recover EC2 instance**)과 경보에 대한 설명(예: **Recover EC2 instance when health checks fail**)을 입력합니다. 경보 이름은 ASCII 문자만 포함해야 합니다.
1. **다음**을 선택합니다.
1. **경보 생성**을 선택합니다.
## 트리거한 경보 및 작업 기록 보기
Amazon CloudWatch 콘솔을 사용하여 경보 및 작업 기록을 볼 수 있습니다. Amazon CloudWatch는 지난 30일 동안의 경보 및 작업 기록을 보관합니다.
**트리거된 경보 및 작업 기록을 보려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택한 후 특정 경보를 선택합니다.
1. 가장 최근의 상태 변화와 함께 시간 및 지표 값을 보려면 **세부 정보(Details)**를 선택합니다.
1. 최신 기록 항목을 보려면 **내역(History)**을 선택합니다.
# 경보 이벤트 및 EventBridge
CloudWatch는 CloudWatch 경보가 생성, 업데이트, 삭제 또는 변경될 때마다 Amazon EventBridge에 이벤트를 전송합니다. EventBridge 및 이러한 이벤트를 사용하여 경보 상태가 변경될 때 알림과 같은 작업을 수행하는 규칙을 작성할 수 있습니다. 자세한 내용은 [Amazon EventBridge란 무엇인가요?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 단원을 참조하세요.
CloudWatch는 EventBridge로의 경보 상태 변경 이벤트 전달을 보장합니다.
## 경보 상태 변경 이벤트
이 섹션에서는 경보 상태가 변경될 때 EventBridge로 전송되는 이벤트 예제를 보여줍니다. 탭을 선택하여 다양한 유형의 경보 상태 변경 이벤트를 확인합니다.
------
#### [ Single Metric Alarm ]
단일 지표 경보가 상태를 변경할 때 생성되는 이벤트. 이러한 이벤트로 경보의 평가 결과가 포함된 `state` 및 `previousState` 필드가 포함됩니다.
```
{
"version": "0",
"id": "c4c1c1c9-6542-e61b-6ef0-8c4d36933a92",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:04:40Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"configuration": {
"description": "Goes into alarm when server CPU utilization is too high!",
"metrics": [
{
"id": "30b6c6b2-a864-43a2-4877-c09a1afc3b87",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "CPUUtilization",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
]
},
"previousState": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [0.0666851903306472 (01/10/19 13:46:00)] was not greater than the threshold (50.0) (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-01T13:56:40.985+0000\",\"startDate\":\"2019-10-01T13:46:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[0.0666851903306472],\"threshold\":50.0}",
"timestamp": "2019-10-01T13:56:40.987+0000",
"value": "OK"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [99.50160229693434 (02/10/19 16:59:00)] was greater than the threshold (50.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:04:40.985+0000\",\"startDate\":\"2019-10-02T16:59:00.000+0000\",\"statistic\":\"Average\",\"period\":300,\"recentDatapoints\":[99.50160229693434],\"threshold\":50.0}",
"timestamp": "2019-10-02T17:04:40.989+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Metric Math Alarm ]
지표 수학 경보가 상태를 변경할 때 생성되는 이벤트. 이러한 이벤트로 `configuration` 필드에 수학 표현식 세부 정보가 포함됩니다.
```
{
"version": "0",
"id": "2dde0eb1-528b-d2d5-9ca6-6d590caf2329",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-02T17:20:48Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"configuration": {
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"metrics": [
{
"expression": "SUM(METRICS())",
"id": "e1",
"label": "Total Network Traffic",
"returnData": true
},
{
"id": "m1",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkIn",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"dimensions": {
"InstanceId": "i-12345678901234567"
},
"name": "NetworkOut",
"namespace": "AWS/EC2"
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
}
]
},
"previousState": {
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2019-10-02T17:20:03.642+0000",
"value": "INSUFFICIENT_DATA"
},
"state": {
"reason": "Threshold Crossed: 1 out of the last 1 datapoints [45628.0 (02/10/19 17:10:00)] was greater than the threshold (10000.0) (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-02T17:20:48.551+0000\",\"startDate\":\"2019-10-02T17:10:00.000+0000\",\"period\":300,\"recentDatapoints\":[45628.0],\"threshold\":10000.0}",
"timestamp": "2019-10-02T17:20:48.554+0000",
"value": "ALARM"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Anomaly Detection Alarm ]
이상 감지 경보가 상태를 변경할 때 생성되는 이벤트. 이러한 이벤트로 `reasonData` 필드의 상한 및 하한 임계치가 포함됩니다.
```
{
"version": "0",
"id": "daafc9f1-bddd-c6c9-83af-74971fcfc4ef",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2019-10-03T16:00:04Z",
"region": "us-east-1",
"resources": ["arn:aws:cloudwatch:us-east-1:123456789012:alarm:EC2 CPU Utilization Anomaly"],
"detail": {
"alarmName": "EC2 CPU Utilization Anomaly",
"state": {
"value": "ALARM",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.0 (03/10/19 15:58:00)] was less than the lower thresholds [0.020599444741798756] or greater than the upper thresholds [0.3006915352732461] (minimum 1 datapoint for OK -> ALARM transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T16:00:04.650+0000\",\"startDate\":\"2019-10-03T15:58:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.0],\"recentLowerThresholds\":[0.020599444741798756],\"recentUpperThresholds\":[0.3006915352732461]}",
"timestamp": "2019-10-03T16:00:04.653+0000"
},
"previousState": {
"value": "OK",
"reason": "Thresholds Crossed: 1 out of the last 1 datapoints [0.166666666664241 (03/10/19 15:57:00)] was not less than the lower thresholds [0.0206719426210418] or not greater than the upper thresholds [0.30076870222143803] (minimum 1 datapoint for ALARM -> OK transition).",
"reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2019-10-03T15:59:04.670+0000\",\"startDate\":\"2019-10-03T15:57:00.000+0000\",\"period\":60,\"recentDatapoints\":[0.166666666664241],\"recentLowerThresholds\":[0.0206719426210418],\"recentUpperThresholds\":[0.30076870222143803]}",
"timestamp": "2019-10-03T15:59:04.672+0000"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
},
"configuration": {
"description": "Goes into alarm if CPU Utilization is out of band",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 60,
"stat": "Average"
},
"returnData": true
}, {
"id": "ad1",
"expression": "ANOMALY_DETECTION_BAND(m1, 0.8)",
"label": "CPUUtilization (expected)",
"returnData": true
}]
}
}
}
```
------
#### [ Composite Alarm ]
복합 경보가 상태를 변경할 때 생성되는 이벤트. 이러한 이벤트로 `actionsSuppressedBy` 및 `actionsSuppressedReason` 필드의 금지 정보가 포함됩니다.
```
{
"version": "0",
"id": "d3dfc86d-384d-24c8-0345-9f7986db0b80",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-22T15:57:45Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"actionsSuppressedReason": "Actions suppressed by WaitPeriod",
"value": "ALARM",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.FirstChild transitioned to ALARM at Friday 22 July, 2022 15:57:45 UTC",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"ALARM\",\"timestamp\":\"2022-07-22T15:57:45.394+0000\"}}]}",
"timestamp": "2022-07-22T15:57:45.394+0000"
},
"previousState": {
"value": "OK",
"reason": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:SuppressionDemo.EventBridge.Main was created and its alarm rule evaluates to OK",
"reasonData": "{\"triggeringAlarms\":[{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:57.770+0000\"}},{\"arn\":\"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh\",\"state\":{\"value\":\"OK\",\"timestamp\":\"2022-07-14T16:28:54.191+0000\"}}]}",
"timestamp": "2022-07-22T15:56:14.552+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
------
#### [ Multi Time Series Alarm ]
경보 기고자 또는 경보의 상태가 변경될 때 생성되는 이벤트. 경보 기고자 상태 변경 이벤트에는 경보 기고자의 ID 및 속성과 임계치를 위반한 최신 데이터 포인트가 포함됩니다. 경보 상태 변경 이벤트에는 경보 상태 이유에서 경보를 전환시키는 기고자 수에 대한 요약이 포함됩니다.
**경보 기고자 예제**
```
{
"version": "0",
"id": "6d226bbc-07f0-9a31-3359-1736968f8ded",
"detail-type": "CloudWatch Alarm Contributor State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"alarmContributor": {
"id": "6d442278dba546f6",
"attributes": {
"TableName": "example-dynamodb-table-name"
}
},
"state": {
"value": "ALARM",
"reason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData":true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
},
"muteDetail": {
"mutedByArn": "arn:aws:cloudwatch:us-east-1:1234567890:alarm-mute-rule:testMute",
"muteWindowStart": "2026-01-01T10:00:00.000+0000",
"muteWindowEnd": "2026-01-01T12:00:00.000+0000"
}
}
}
```
**경보 예제**
```
{
"version": "0",
"id": "80ddd249-dedf-7c4d-0708-0eb78132dd78",
"detail-type": "CloudWatch Alarm State Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2025-12-01T13:42:04Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:DynamoDBInsightsAlarm"
],
"detail": {
"alarmName": "DynamoDBInsightsAlarm",
"state": {
"value": "ALARM",
"reason": "6 out of 6 time series evaluated to ALARM",
"timestamp": "2025-12-01T13:42:04.919+0000"
},
"previousState": {
"value": "INSUFFICIENT_DATA",
"reason": "Unchecked: Initial alarm creation",
"timestamp": "2025-12-01T13:40:50.600+0000"
},
"configuration": {
"metrics": [
{
"id": "m1",
"expression": "SELECT AVG(ConsumedWriteCapacityUnits) FROM \"AWS/DynamoDB\" GROUP BY TableName ORDER BY MAX() DESC",
"returnData": true,
"period": 60
}
],
"description": "Metrics Insights alarm for DynamoDB ConsumedWriteCapacity per TableName"
}
}
}
```
------
## 경보 구성 변경 이벤트
이 섹션에서는 경보 구성이 변경될 때 EventBridge로 전송되는 이벤트 예제를 보여줍니다. 구성 변경에는 경보 생성, 업데이트 또는 삭제가 포함됩니다.
------
#### [ Creation Events ]
새 경보가 생성될 때 생성되는 이벤트. 이러한 이벤트로 `operation`이 'create'로 설정된 `configuration` 필드의 초기 경보 구성이 포함됩니다.
**복합 경보 예제**
```
{
"version": "0",
"id": "91535fdd-1e9c-849d-624b-9a9f2b1d09d0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:22Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:22.289+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"alarmName": "ServiceAggregatedAlarm",
"description": "Aggregated monitor for instance",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:22.289+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**억제기를 사용한 복합 경보 예제**
```
{
"version": "0",
"id": "454773e1-09f7-945b-aa2c-590af1c3f8e0",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:46Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "create",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Update Events ]
기존 경보가 수정될 때 생성되는 이벤트. 이러한 이벤트로 변경된 내용을 표시하는 `configuration` 및 `previousConfiguration` 필드가 모두 포함됩니다.
**지표 경보 예제**
```
{
"version": "0",
"id": "bc7d3391-47f8-ae47-f457-1b4d06118d50",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:06:34Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServerCpuTooHigh"
],
"detail": {
"alarmName": "ServerCpuTooHigh",
"operation": "update",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:13.757+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 80,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "86bfa85f-b14c-ebf7-8916-7da014ce23c0",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:34.267+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
},
"previousConfiguration": {
"evaluationPeriods": 1,
"threshold": 70,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [
{
"id": "d6bfa85f-893e-b052-a58b-4f9295c9111a",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "CPUUtilization",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Average"
},
"returnData": true
}
],
"alarmName": "ServerCpuTooHigh",
"description": "Goes into alarm when server CPU utilization is too high!",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:13.757+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**억제기를 사용한 지표 경보 예제**
```
{
"version": "0",
"id": "4c6f4177-6bd5-c0ca-9f05-b4151c54568b",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T13:59:56Z",
"region": "us-east-1",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "update",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [], Remove
"insufficientDataActions": []
},
"previousConfiguration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 180,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:46.425+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
#### [ Deletion Events ]
경보가 삭제될 때 생성되는 이벤트. 이러한 이벤트로는 최종 경보 구성과 `operation`을 'delete'로 설정이 포함됩니다.
**지표 수학 경보 예제**
```
{
"version": "0",
"id": "f171d220-9e1c-c252-5042-2677347a83ed",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-03-03T17:07:13Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:TotalNetworkTrafficTooHigh"
],
"detail": {
"alarmName": "TotalNetworkTrafficTooHigh",
"operation": "delete",
"state": {
"value": "INSUFFICIENT_DATA",
"timestamp": "2022-03-03T17:06:17.672+0000"
},
"configuration": {
"evaluationPeriods": 1,
"threshold": 10000,
"comparisonOperator": "GreaterThanThreshold",
"treatMissingData": "ignore",
"metrics": [{
"id": "m1",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkIn",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "m2",
"metricStat": {
"metric": {
"namespace": "AWS/EC2",
"name": "NetworkOut",
"dimensions": {
"InstanceId": "i-12345678901234567"
}
},
"period": 300,
"stat": "Maximum"
},
"returnData": false
},
{
"id": "e1",
"expression": "SUM(METRICS())",
"label": "Total Network Traffic",
"returnData": true
}
],
"alarmName": "TotalNetworkTrafficTooHigh",
"description": "Goes into alarm if total network traffic exceeds 10Kb",
"actionsEnabled": true,
"timestamp": "2022-03-03T17:06:17.672+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
**억제기를 사용한 지표 수학 경보 예제**
```
{
"version": "0",
"id": "e34592a1-46c0-b316-f614-1b17a87be9dc",
"detail-type": "CloudWatch Alarm Configuration Change",
"source": "aws.cloudwatch",
"account": "123456789012",
"time": "2022-07-14T14:00:01Z",
"region": "us-east-*",
"resources": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:ServiceAggregatedAlarm"
],
"detail": {
"alarmName": "ServiceAggregatedAlarm",
"operation": "delete",
"state": {
"actionsSuppressedBy": "WaitPeriod",
"value": "ALARM",
"timestamp": "2022-07-14T13:59:46.425+0000"
},
"configuration": {
"alarmRule": "ALARM(ServerCpuTooHigh) OR ALARM(TotalNetworkTrafficTooHigh)",
"actionsSuppressor": "ServiceMaintenanceAlarm",
"actionsSuppressorWaitPeriod": 120,
"actionsSuppressorExtensionPeriod": 360,
"alarmName": "ServiceAggregatedAlarm",
"actionsEnabled": true,
"timestamp": "2022-07-14T13:59:56.290+0000",
"okActions": [],
"alarmActions": [],
"insufficientDataActions": []
}
}
}
```
------
# 경보 음소거 규칙 구성
이 섹션의 단계에서는 CloudWatch 콘솔을 사용하여 경보 음소거 규칙을 생성하는 방법을 설명합니다. API 또는 AWS CLI를 사용하여 경보 음소거 규칙을 생성할 수도 있습니다. 자세한 내용은 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)을 참조하세요.
**경보 음소거 규칙을 생성하는 방법**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보**를 선택하고 **음소거 규칙** 탭 선택
1. **경보 음소거 규칙 생성** 버튼 클릭(그러면 마법사가 열림)
1. **경보 음소거 규칙 세부 정보** 섹션에서 경보 음소거 규칙의 이름과 선택적 설명 입력
1. **일정 패턴** 섹션에서 일회성 또는 반복 일정 선택
1. 일회성 발생을 선택하는 경우
1. 시간대를 선택하여 음소거 일정 적용
1. 시작 날짜 및 시간을 선택하여 음소거 규칙이 활성화되는 시점 정의
1. 종료 날짜 및 시간을 선택하여 음소거 규칙이 만료되는 시점 정의
1. 반복 일정을 선택하는 경우 두 가지 옵션이 있습니다. 콘솔 양식을 사용하거나 cron 표현식을 사용하여 반복 시간 일정을 구성하세요.
1. **일정 생성 유형**에서 '날짜, 시간 및 반복 지정'을 선택하여 콘솔 양식 사용
1. 음소거 규칙을 적용할 시간대 선택
1. **시작 날짜 및 시간**을 선택하여 음소거 규칙이 활성화되는 시점 정의
1. **기간**을 선택하여 마지막 음소거 규칙이 활성화된 후 해당 규칙이 지속되는 기간 정의
1. **반복**을 선택하여 매일, 매월, 매주 주말 또는 주중 특정 요일과 같이 일정 반복되는 방식을 정의하세요.
1. 선택 사항인 **종료 시간**을 선택하여 음소거 일정이 만료되는 시점을 정의하세요. 기본 옵션은 '무한'임
1. **일정 생성 유형**에서 'cron 표현식에서 설정'을 선택하여 cron 표현식을 사용해 일정 구성
1. **Cron 표현식** 섹션에서 원하는 cron 표현식 값 입력
1. **기간**을 선택하여 마지막 음소거 규칙이 활성화된 후 해당 규칙이 지속되는 기간 정의
1. 선택 사항인 **기간** 섹션에서 선택적 시작 및 종료 날짜와 시간을 입력하여 음소거 일정이 활성화되고 만료되는 시점을 정의하세요.
1. **대상 경보** 섹션의 드롭다운에서 이 음소거 규칙을 적용할 경보 선택
1. **음소거 규칙의 태그 설정** 섹션에서 경보 음소거 규칙에 태그를 연결하세요. 태그는 리소스에 대한 메타데이터를 보관하기 위해 리소스에 적용되는 키-값 쌍입니다. 자세한 내용은 [What are tags?](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html)를 참조하세요.
1. **경보 음소거 규칙 생성** 버튼을 선택하여 음소거 규칙 생성
## 빠른 음소거
다음과 같이 짧은 기간의 경보를 추가할 수 있습니다.
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보** 선택
1. 목록에서 음소거할 경보 선택
1. **작업** 메뉴에서 **음소거** 선택
1. **빠른 음소거** 섹션에서 사전 정의된 기간 15분, 1시간, 3시간을 선택하거나 **다음까지 음소거**를 선택하여 원하는 기간 설정
1. **확인**을 클릭하여 선택한 기간이 끝나면 즉시 경보 음소거
## 기존 음소거 규칙에 경보 추가
다음과 같이 경보를 기존 음소거 규칙에 추가할 수 있습니다.
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보** 선택
1. 목록에서 음소거할 경보 선택
1. **작업** 메뉴에서 **음소거** 선택
1. **기존 음소거 규칙 적용** 선택(그러면 마법사가 열림)
1. 드롭다운에서 경보를 추가할 음소거 규칙 선택
1. **적용** 클릭
**참고**
경보 세부 정보 페이지에서 빠른 음소거 및 기존 음소거 규칙에 경보 추가 옵션도 사용할 수 있습니다. 세부 정보 페이지의 **음소거 규칙** 탭에는 경보에 연결된 모든 음소거 규칙이 표시됩니다.
# 경보 관리
**Topics**
+ [CloudWatch 경보 편집 또는 삭제](Edit-CloudWatch-Alarm.md)
+ [Auto Scaling 경보 숨김](hide-autoscaling-alarms.md)
+ [경보 및 태그 지정](CloudWatch_alarms_and_tagging.md)
+ [음소거된 경보 보기 및 관리](viewing-managing-muted-alarms.md)
# CloudWatch 경보 편집 또는 삭제
기존 경보를 편집하거나 삭제할 수 있습니다.
기존 경보의 이름을 변경할 수 없습니다. 경보를 복사하고 새 경보에 다른 이름을 지정할 수 있습니다. 경보를 복사하려면 경보 목록에서 경보 이름 옆에 있는 확인란을 선택하고 **작업**, **복사**를 선택합니다.
**경보를 편집하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. 경보 이름을 선택합니다.
1. 태그를 추가하거나 제거하려면 **태그** 탭을 선택한 다음 **태그 관리**를 선택합니다.
1. 경보의 다른 부분을 편집하려면 **작업**, **편집**을 선택합니다.
선택한 지표 및 통계에 대한 그래프와 기타 정보가 표시된 **Specify metric and conditions(지표 및 조건 지정)** 페이지가 나타납니다.
1. 지표를 변경하려면 **편집**을 선택하고 **모든 지표** 탭을 선택한 후 다음 중 하나를 수행합니다.
+ 원하는 지표가 포함된 서비스 네임스페이스를 선택합니다. 옵션이 나타날 때 계속해서 옵션을 선택하면 선택 범위가 좁아집니다. 지표 목록이 표시되면 원하는 지표 옆에 있는 확인란을 선택합니다.
+ 검색 상자에 지표 이름, 측정기준 또는 리소스 ID를 입력하고 Enter 키를 누릅니다. 그런 다음 결과 중 하나를 선택하고 지표 목록이 표시될 때까지 계속 진행합니다. 원하는 지표 옆의 확인란을 선택합니다.
**지표 선택**을 선택합니다.
1. 경보의 다른 측면을 변경하려면 적절한 옵션을 선택합니다. 경보가 `ALARM` 상태가 되거나 누락된 데이터가 처리되는 방법을 변경하기 위해 위반해야 하는 데이터 포인트 수를 변경하려면 **추가 구성**을 선택합니다.
1. **다음**을 선택합니다.
1. **알림**, **Auto Scaling action(Auto Scaling 작업)** 및 **EC2 작업**에서 경보가 트리거될 때 수행한 동작을 선택적으로 편집합니다. 그리고 **다음(Next)**을 선택합니다.
1. 선택적으로 경보 설명을 변경합니다.
기존 경보의 이름을 변경할 수 없습니다. 경보를 복사하고 새 경보에 다른 이름을 지정할 수 있습니다. 경보를 복사하려면 경보 목록에서 경보 이름 옆에 있는 확인란을 선택하고 **작업**, **복사**를 선택합니다.
1. **다음**을 선택합니다.
1. **Preview and create(미리 보기 및 생성)**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **Update alarm(경보 업데이트)**을 선택합니다.
**Amazon SNS 콘솔을 사용하여 생성된 이메일 알림 목록을 업데이트하려면**
1. [https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)에서 Amazon SNS 콘솔을 엽니다.
1. 탐색 창에서 **주제**를 선택한 다음, 알림 목록(주제)에 대한 ARN을 선택합니다.
1. 다음 중 하나를 수행하세요.
+ 이메일 주소를 추가하려면 **구독 생성**을 선택합니다. **프로토콜**에서 **이메일**을 선택합니다. **엔드포인트**에 새 수신자의 이메일 주소를 입력합니다. **구독 생성**을 선택합니다.
+ 이메일 주소를 제거하려면 **구독 ID**를 선택합니다. **기타 구독 작업**과 **구독 삭제**를 선택합니다.
1. [**Publish to topic**]을 선택합니다.
**경보를 삭제하는 방법**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택합니다.
1. 경보 이름 왼쪽에 있는 확인란을 선택하고 **작업**, **삭제**를 선택합니다.
1. **삭제**를 선택합니다.
# Auto Scaling 경보 숨김
AWS Management Console에서 경보를 확인할 때 Amazon EC2 Auto Scaling과 Application Auto Scaling 모두에 대한 경보를 숨길 수 있습니다. 이 기능은 AWS Management Console에서만 사용할 수 있습니다.
**일시적으로 Auto Scaling 경보 숨기기**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All alarms)** 및 **자동 크기 조정 경보 숨기기(Hide Auto Scaling alarms)**를 차례로 선택합니다.
# 경보 및 태그 지정
**태그는 리소스를 정리하고 분류하는 데 도움이 될 수 있는 키-값 쌍입니다. 특정 태그 값이 있는 리소스만 액세스하거나 변경할 수 있는 권한을 사용자에게 부여하여 사용자 권한 범위를 지정할 수도 있습니다. 리소스 태그 지정에 대한 추가적인 일반 정보는 [AWS 리소스 태그 지정](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)을 참조하세요.
다음 목록은 CloudWatch 경보에서 태그 지정이 작동하는 방식에 관한 일부 정보를 자세히 설명합니다.
+ CloudWatch 리소스에 대한 태그를 설정하거나 업데이트하려면 `cloudwatch:TagResource` 권한이 있는 계정에 로그인해야 합니다. 예를 들어 경보를 생성하고 여기에 태그를 설정하려면 `the cloudwatch:PutMetricAlarm ` 권한 외에 `cloudwatch:TagResource` 권한이 있어야 합니다. 조직 내에서 CloudWatch 리소스 생성 또는 업데이트 작업을 해야 하는 모든 사용자에게 `cloudwatch:TagResource` 권한이 있는지 확인하는 것이 좋습니다.
+ 태그는 태그 기반 권한 부여 제어에 사용할 수 있습니다. 예를 들어, 태그를 기반으로 CloudWatch 호출을 특정 리소스로 제한하는 조건을 IAM 사용자 또는 역할 권한에 포함할 수 있습니다. 하지만 다음과 같은 점을 주의해야 합니다.
+ `aws:`로 시작하는 이름을 가진 태그는 태그 기반 권한 부여 제어에 사용할 수 없습니다.
+ 복합 경보는 태그 기반 권한 부여를 지원하지 않습니다.
# 음소거된 경보 보기 및 관리
**음소거된 경보 보기:** CloudWatch 콘솔을 통해 현재 음소거된 경보를 쉽게 식별할 수 있습니다. 경보 목록 보기와 개별 경보 세부 정보 페이지 모두에서 활성 음소거 규칙에 의해 현재 경보 작업이 음소거된 경보 옆에 음소거 아이콘이 나타납니다. 이 시각적 표시기는 음소거 기간이 만료될 때까지 현재 음소거 중인 경보 작업을 빠르게 이해하는 데 도움이 됩니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_icon.png)
**경보 타임라인:** CloudWatch 경보 콘솔은 경보 작업이 음소거된 시점을 보여주는 포괄적인 타임라인 보기를 제공합니다. 이 타임라인은 경보 상태 변경과 함께 음소거 기간을 표시하므로 경보 동작과 음소거 활동 모두에 대한 전체 기록 보기를 제공합니다. 이 타임라인을 사용하여 음소거 규칙의 효과를 분석하고 이러한 규칙이 운영 활동과 어떤 상관관계가 있는지 파악할 수 있습니다.
![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm-mutes-timelineview.png)
**프로그래밍 방식으로 경보 음소거 상태 확인:** 경보가 현재 음소거되었는지 프로그래밍 방식으로 확인하려면 필터 기준으로 경보 이름을 사용하여 [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) API를 사용할 수 있습니다. 이 API는 지정된 경보에 영향을 미치는 모든 활성 음소거 규칙을 반환하므로 음소거 상태 확인을 자동화 워크플로, 모니터링 대시보드 또는 운영 도구에 통합할 수 있습니다.
예: 'HighCPUAlarm'이라는 경보가 현재 음소거되었는지 확인하려면 필터 파라미터를 경보 이름으로 설정한 상태에서 [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html) API를 직접 호출합니다. 응답에는 해당 경보를 대상으로 하는 모든 음소거 규칙과 현재 상태(SCHEDULED, ACTIVE 또는 EXPIRED)가 포함됩니다.
**경보 기록:** 활성 음소거 규칙으로 인해 경보 작업이 음소거될 때마다 CloudWatch는 경보의 기록 로그에 기록 항목을 작성합니다. 이를 통해 경보가 음소거된 동안에 대한 전체 감사 추적을 제공하므로 음소거 이벤트의 타임라인을 이해하고 이를 운영 활동과 상관시킬 수 있습니다. CloudWatch 콘솔을 통해 이 기록을 보거나 [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html) API를 사용하여 프로그래밍 방식으로 검색할 수 있습니다.
**참고**
여러 경보 음소거 규칙이 동시에 활성화되면 가장 최근에 생성된 음소거 규칙 이름이 다른 활성 음소거 규칙의 총 수와 함께 경보 기록에 작성됩니다.
타임라인은 활성 음소거 기간에 경보 상태가 전환되고 작업이 실행되지 않은 경우에만 음소거 기간을 표시합니다.
**작은 정보**
CloudWatch API를 사용하여 경보 음소거 규칙을 프로그래밍 방식으로 관리할 수 있습니다. 자세한 내용은 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html), [GetAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetAlarmMuteRule.html), [ListAlarmMuteRules](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListAlarmMuteRules.html), [DeleteAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarmMuteRule.html)을 참조하세요.
## CloudWatch 경보의 공통 기능
다음 기능은 모든 CloudWatch 경보에 적용됩니다.
+ 생성할 수 있는 경보 수에는 제한이 없습니다. 경보를 생성하거나 업데이트하려면 CloudWatch 콘솔, [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 작업 또는 AWS CLI의 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용합니다.
+ 경보 이름은 UTF-8 문자만 포함해야 하고 ASCII 제어 문자를 포함할 수 없습니다.
+ CloudWatch 콘솔, [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) API 작업 또는 AWS CLI의 [describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html) 명령을 사용하여 현재 구성된 경보의 일부 또는 전체를 나열하고 특정 상태의 경보를 나열할 수 있습니다.
+ [DisableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DisableAlarmActions.html) 및 [EnableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_EnableAlarmActions.html) API 작업 또는 AWS CLI의 [disable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/disable-alarm-actions.html) 및 [enable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/enable-alarm-actions.html) 명령을 사용하여 경보 작업을 활성화 및 비활성화할 수 있습니다.
+ [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) API 작업 또는 AWS CLI의 [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 명령을 사용함으로써 경보를 임의의 상태로 설정하여 경보를 테스트할 수 있습니다. 이러한 일시적인 상태 변경은 다음 경보 비교 시까지만 지속됩니다.
+ 사용자 지정 지표를 생성하기 전에 사용자 지정 지표에 대한 경보를 생성할 수 있습니다. 경보가 유효하려면 사용자 지정 지표에 대한 모든 측정기준을 비롯해 지표 네임스페이스 및 지표 이름을 경보 정의에 포함시켜야 합니다. 이렇게 하려면 [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) API 작업 또는 AWS CLI의 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용하면 됩니다.
+ CloudWatch 콘솔, [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html) API 작업 또는 AWS CLI의 [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html) 명령을 사용하여 경보 기록을 볼 수 있습니다. CloudWatch는 30일 동안 경보 기록을 유지합니다. 각 상태 전환은 고유한 타임스탬프로 표시됩니다. 드문 경우지만 기록에 상태 변경에 대한 알림이 두 개 이상 있을 수 있습니다. 이 경우 타임스탬프를 사용하여 고유한 상태 변경을 확인할 수 있습니다.
+ CloudWatch 콘솔 탐색 창의 *즐겨찾기 및 최근 항목(Favorites and recents)* 옵션에서 즐겨찾기에 추가하려는 경보 위에 마우스를 놓고 옆에 있는 별 기호를 선택하여 경보를 즐겨찾기에 추가할 수 있습니다.
+ 경보에는 평가 기간 할당량이 있습니다. 평가 기간은 사용된 평가 기간 수를 경보 기간에 곱하여 계산됩니다.
+ 기간이 최소 1시간(3,600초)인 경보의 경우 최대 평가 기간은 7일입니다.
+ 기간이 더 짧은 경보의 경우 최대 평가 기간은 1일입니다.
+ 사용자 지정 Lambda 데이터 소스를 사용하는 경보의 경우 최대 평가 기간은 1일입니다.
**참고**
일부 AWS 리소스는 특정 조건에서 지표 데이터를 CloudWatch에 전송하지 않습니다.
예를 들어 Amazon EBS는 Amazon EC2 인스턴스에 연결되지 않은 사용 가능한 볼륨에 대한 지표 데이터를 전송하지 않을 수 있습니다. 해당 볼륨에 대해 모니터링할 지표 활동이 없기 때문입니다. 이러한 지표에 대한 경보 세트가 있으면 상태가 `INSUFFICIENT_DATA`로 변경됩니다. 이는 리소스가 비활성 상태임을 나타내지만 그렇다고 반드시 문제가 있음을 의미하지는 않습니다. 각 경보가 누락된 데이터를 처리하는 방법을 지정할 수 있습니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 섹션을 참조하세요.
# AWS 서비스에 대한 모범 사례 경보 권장 사항
CloudWatch는 경보 권장 사항을 기본으로 제공합니다. 이는 다른 AWS 서비스에서 게시한 지표에 대해 생성할 것을 권장하는 CloudWatch 경보입니다. 이러한 권장 사항은 모니터링의 모범 사례를 따르기 위해 경보를 설정해야 하는 지표를 식별하는 데 도움이 됩니다. 또한 권장 사항에서는 설정할 경보 임곗값을 제안합니다. 권장 사항을 따르면 AWS 인프라에 대한 중요한 모니터링을 놓치지 않을 수 있습니다.
경보 권장 사항을 찾으려면 CloudWatch 콘솔의 지표 섹션을 사용하여 경보 권장 사항 필터 토글을 선택합니다. 콘솔에서 권장 경보로 이동한 다음 권장 경보를 생성하면 CloudWatch에서 일부 경보 설정을 미리 채울 수 있습니다. 일부 권장 경보의 경우 경보 임곗값도 미리 입력됩니다. 콘솔을 사용하여 권장 경보에 대한 코드형 인프라 경보 정의를 다운로드한 다음 이 코드를 사용하여 AWS CloudFormation, AWS CLI 또는 Terraform에서 경보를 생성할 수도 있습니다.
[권장되는 경보](Best_Practice_Recommended_Alarms_AWS_Services.md)에서 권장 경보 목록을 볼 수도 있습니다.
생성한 경보에 대해서는 CloudWatch에서 생성한 다른 모든 경보와 동일한 요금이 부과됩니다. 권장 사항을 사용하면 추가 요금이 발생하지 않습니다. 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
## 권장 알람 찾고 생성하기
다음 단계에 따라 CloudWatch에서 경보 설정을 권장하는 지표를 찾고 선택적으로 경보 중 하나를 생성합니다. 첫 번째 절차에서는 권장 경보가 있는 지표를 찾는 방법과 이러한 경보 중 하나를 생성하는 방법을 설명합니다.
`AWS/Lambda` 또는 `AWS/S3`와 같은 AWS 네임스페이스의 모든 권장 경보에 대한 코드형 인프라 경보 정의를 대량으로 다운로드할 수도 있습니다. 관련 지침은 이 주제의 후반부에서 설명합니다.
**권장 경보가 포함된 지표를 찾고 단일 권장 경보 생성하기**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표**, **모든 지표**를 선택합니다.
1. **지표** 표에서 **경보 권장 사항**을 선택합니다.
지표 네임스페이스 목록은 경보 권장 사항이 있고 계정의 서비스가 게시하고 있는 지표만 포함하도록 필터링됩니다.
1. 서비스의 네임스페이스를 선택합니다.
이 네임스페이스의 지표 목록은 경보 권장 사항이 있는 지표만 포함하도록 필터링됩니다.
1. 지표에 대한 경보 의도와 권장 임곗값을 보려면 **세부 정보 보기**를 선택합니다.
1. 지표 중 하나에 대한 경보를 생성하려면 다음 중 하나를 수행합니다.
+ 콘솔을 사용하여 경보를 생성하려면 다음을 수행합니다.
1. 지표의 확인란을 선택하고 **그래프로 표시된 지표** 탭을 선택합니다.
1. 경보 아이콘을 선택합니다.
![\[그래프로 표시된 지표에서 경보 생성\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/metric_graph_alarm.png)
경보 권장 사항에 따라 지표 이름, 통계, 기간이 채워진 경보 생성 마법사가 나타납니다. 권장 사항에 특정 임곗값이 포함된 경우 해당 값도 미리 채워집니다.
1. **다음**을 선택합니다.
1. **알림**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태로 전환될 때 알릴 SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거**를 선택합니다.
1. 경보가 Auto Scaling 또는 EC2 작업을 수행하도록 하려면 해당 버튼을 선택하고 경보 상태 및 수행할 작업을 선택합니다.
1. 마친 후에는 **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 이름은 ASCII 문자만 포함해야 합니다. 그리고 **다음(Next)**을 선택합니다.
1. **미리 보기 및 생성**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성**을 선택합니다.
+ 코드형 인프라 경보 정의를 다운로드하여 AWS CloudFormation, AWS CLI 또는 Terraform에서 사용하려면 **경보 코드 다운로드**를 선택하고 원하는 형식을 선택합니다. 다운로드한 코드에는 지표 이름, 통계, 임곗값에 대한 권장 설정이 포함됩니다.
**AWS 서비스의 모든 권장 경보에 대한 코드형 인프라 경보 정의 다운로드하기**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **지표**, **모든 지표**를 선택합니다.
1. **지표** 표에서 **경보 권장 사항**을 선택합니다.
지표 네임스페이스 목록은 경보 권장 사항이 있고 계정의 서비스가 게시하고 있는 지표만 포함하도록 필터링됩니다.
1. 서비스의 네임스페이스를 선택합니다.
이 네임스페이스의 지표 목록은 경보 권장 사항이 있는 지표만 포함하도록 필터링됩니다.
1. **다운로드 경보 코드**는 이 네임스페이스의 지표에 대해 권장되는 경보 수를 표시합니다. 모든 권장 경보에 대한 코드형 인프라 경보 정의를 다운로드하려면 **경보 코드 다운로드**를 선택한 다음 원하는 코드 형식을 선택합니다.
# 권장되는 경보
다음 섹션에는 모범 사례 경보의 설정을 권장하는 지표가 나열되어 있습니다. 각 지표에 대해 측정 기준, 경보 의도, 권장 임곗값, 임곗값 근거, 기간 및 데이터 포인트 수도 표시됩니다.
일부 지표는 목록에 두 번 등장할 수 있습니다. 이는 해당 지표의 다른 측정 기준 조합에 대해 다른 경보가 권장되는 경우에 발생합니다.
**경보를 보낼 데이터 포인트**는 경보를 ALARM 상태로 보내기 위해 위반해야 하는 데이터 포인트의 수입니다. **평가 기간**은 경보를 평가할 때 고려되는 기간의 수입니다. 이 숫자가 같으면 연속된 기간 수의 값이 임곗값을 초과한 경우에만 경보가 ALARM 상태로 전환됩니다. **경보를 보낼 데이터 포인트**가 **평가 기간**보다 낮으면 "M out of N" 경보가 되며, 데이터 포인트로 구성된 **평가 기간** 내에 적어도 **경보를 보낼 데이터 포인트**의 데이터 포인트가 위반되면 경보가 ALARM 상태로 전환됩니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.
**Topics**
+ [Amazon API Gateway](#ApiGateway)
+ [Amazon EC2 Auto Scaling](#AutoScaling)
+ [AWS Certificate Manager (ACM)](#CertificateManager)
+ [Amazon CloudFront](#CloudFront)
+ [Amazon Cognito](#Cognito)
+ [Amazon DynamoDB](#DynamoDB)
+ [Amazon EBS](#Recommended_EBS)
+ [Amazon EC2](#EC2)
+ [Amazon ElastiCache](#ElastiCache)
+ [Amazon ECS](#ECS)
+ [Container Insights가 포함된 Amazon ECS](#ECS-ContainerInsights)
+ [향상된 관찰성을 갖춘 Container Insights가 포함된 Amazon EKS](#ECS-ContainerInsights_enhanced)
+ [Amazon EFS](#EFS)
+ [Container Insights가 포함된 Amazon EKS](#EKS-ContainerInsights)
+ [Amazon EventBridge Scheduler](#Eventbridge-Scheduler)
+ [Amazon Kinesis Data Streams](#Kinesis)
+ [Lambda](#Lambda)
+ [Lambda Insights](#LambdaInsights)
+ [Amazon VPC(`AWS/NATGateway`)](#NATGateway)
+ [AWS 프라이빗 링크(`AWS/PrivateLinkEndpoints`)](#PrivateLinkEndpoints)
+ [AWS 프라이빗 링크(`AWS/PrivateLinkServices`)](#PrivateLinkServices)
+ [`Amazon RDS`](#RDS)
+ [`Amazon Route 53 Public Data Plane`](#Route53)
+ [`Amazon S3`](#S3)
+ [`S3ObjectLambda`](#S3ObjectLambda)
+ [Amazon SNS](#SNS)
+ [Amazon SQS](#SQS)
+ [Site-to-Site VPN](#VPN)
## Amazon API Gateway
**4XXError**
**측정 기준: **ApiName, 스테이지
**경보 설명:** 이 경보는 높은 비율의 클라이언트 측 오류를 감지합니다. 이는 권한 부여 또는 클라이언트 요청 매개변수에 문제가 있음을 의미할 수 있습니다. 리소스가 제거되었거나 클라이언트가 존재하지 않는 리소스를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4XX 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 리소스 및 방법별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 [이 가이드](https://repost.aws/knowledge-center/api-gateway-429-limit)에 따라 문제를 해결하세요.
**인텐트:** 이 경보는 API Gateway 요청에 대해 높은 비율의 클라이언트 측 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 4XX 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**5XXError**
**측정 기준: **ApiName, 스테이지
**경보 설명:** 이 경보는 높은 비율의 서버 측 오류 감지에 도움이 됩니다. 이는 API 백엔드, 네트워크 또는 API 게이트웨이와 백엔드 API 간의 통합에 문제가 있음을 나타낼 수 있습니다. 이 [설명서](https://repost.aws/knowledge-center/api-gateway-5xx-error)는 5xx 오류의 원인을 해결하는 데 도움이 될 수 있습니다.
**인텐트:** 이 경보는 API Gateway 요청에 대해 높은 비율의 서버 측 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 5XX 오류가 발생하는 경우를 감지합니다. 그러나 허용 가능한 오류 발생률뿐만 아니라 요청의 트래픽에 따라 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대한 허용 가능한 오류 발생율을 확인한 다음 그에 따라 임곗값을 조정할 수도 있습니다. 자주 발생하는 5XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**개수**
**측정 기준: **ApiName, 스테이지
**경보 설명:** 이 경보는 REST API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 REST API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 방법 및 리소스별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 리소스 및 방법에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**개수**
**측정 기준: **ApiName, 스테이지, 리소스, 방법
**경보 설명:** 이 경보는 해당 스테이지에서 REST API 리소스 및 방법에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 해당 단계의 REST API 리소스 및 방법에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**개수**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 HTTP API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 HTTP API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 경로별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 경로에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**개수**
**측정 기준: **ApiId, 스테이지, 리소스, 방법
**경보 설명:** 이 경보는 해당 단계의 HTTP API에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 잘못된 엔드포인트 사용과 같이 API를 호출하는 애플리케이션과 관련된 문제를 나타내는 지표일 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 해당 스테이지에서 HTTP API 경로에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 요청을 수신하는 경우 이 경보를 생성하는 것이 좋습니다. 이 경보는 일정하고 일관된 트래픽이 예상되지 않는 API에는 권장되지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 요청 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**IntegrationLatency**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 스테이지에서 API 요청에 대한 통합 지연 시간이 높은지 감지하는 데 도움이 됩니다. `IntegrationLatency` 지표 값을 백엔드의 해당 지연 시간 지표(예: Lambda 통합에 대한 `Duration` 지표)와 상호 연관시킬 수 있습니다. 이를 통해 성능 문제로 인해 API 백엔드가 클라이언트의 요청을 처리하는 데 더 오랜 시간이 걸리는지 또는 초기화 또는 콜드 시작으로 인해 다른 오버헤드가 발생하는지 확인할 수 있습니다. 또한 API에 CloudWatch Logs를 활성화하고 로그에서 높은 지연 시간 문제를 일으킬 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 통합 지연 시간의 원인을 좁히는 데 도움이 되도록 상세한 CloudWatch 지표를 활성화하고 경로별로 이 지표를 확인하는 것도 고려해 보세요.
**인텐트:** 이 경보는 스테이지의 API Gateway 요청에서 통합 지연 시간이 긴 경우를 감지할 수 있습니다. WebSocket API에는 이 경보를 사용하는 것이 좋으며, HTTP API에는 지연 시간 지표에 대한 별도의 경보 권장 사항이 이미 있으므로 HTTP API의 경우 선택 사항으로 간주합니다. 자세한 CloudWatch 지표를 활성화하고 경로별로 통합 지연 시간 성능 요구 사항이 다른 경우, 각 경로의 통합 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.
**통계: **p90
**권장 임곗값**: 2000.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**IntegrationLatency**
**측정 기준: **ApiId, 스테이지, 경로
**경보 설명:** 이 경보는 스테이지에서 경로에 대한 WebSocket API 요청의 통합 지연 시간이 높은지 감지하는 데 도움이 됩니다. `IntegrationLatency` 지표 값을 백엔드의 해당 지연 시간 지표(예: Lambda 통합에 대한 `Duration` 지표)와 상호 연관시킬 수 있습니다. 이를 통해 성능 문제로 인해 API 백엔드가 클라이언트의 요청을 처리하는 데 더 오랜 시간이 걸리는지 또는 초기화 또는 콜드 시작으로 인해 다른 오버헤드가 발생하는지 확인할 수 있습니다. 또한 API에 CloudWatch Logs를 활성화하고 로그에서 높은 지연 시간 문제를 일으킬 수 있는 오류가 있는지 확인하는 것도 고려해 보세요.
**인텐트:** 이 경보는 스테이지의 경로에 대한 API Gateway 요청에서 통합 지연 시간이 긴 경우를 감지할 수 있습니다.
**통계: **p90
**권장 임곗값**: 2000.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latency**
**측정 기준: **ApiName, 스테이지
**경보 설명:** 이 경보는 스테이지에서 높은 지연 시간을 감지합니다. `IntegrationLatency` 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 리소스 및 방법별로 이 지표를 확인하고 지연 시간의 원인을 좁히는 것도 고려해 보세요. 해당하는 경우 [Lambda를 사용한 문제 해결](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) 또는 [엣지 최적화 API 엔드포인트 문제 해결](https://repost.aws/knowledge-center/source-latency-requests-api-gateway) 가이드를 참조하세요.
**인텐트:** 이 경보는 스테이지의 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다. 자세한 CloudWatch 지표를 활성화하고 각 방법 및 리소스에 대한 지연 시간 성능 요구 사항이 다른 경우, 각 리소스 및 방법의 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.
**통계: **p90
**권장 임곗값**: 2500.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latency**
**측정 기준: **ApiName, 스테이지, 리소스, 방법
**경보 설명:** 이 경보는 스테이지에서 리소스와 방법에 대해 높은 지연 시간을 감지합니다. `IntegrationLatency` 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 해당하는 경우 [Lambda를 사용한 문제 해결](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda) 또는 [엣지 최적화 API 엔드포인트 문제 해결](https://repost.aws/knowledge-center/source-latency-requests-api-gateway) 가이드를 참조하세요.
**인텐트:** 이 경보는 스테이지의 API Gateway 요청에서 리소스와 방법에 대해 지연 시간이 긴 경우를 감지할 수 있습니다.
**통계: **p90
**권장 임곗값**: 2500.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 그러나 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latency**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 스테이지에서 높은 지연 시간을 감지합니다. `IntegrationLatency` 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 지연 시간의 원인을 좁히는 것도 고려해 보세요. 해당하는 경우 [Lambda 통합을 사용한 문제 해결 가이드](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)도 참조할 수 있습니다.
**인텐트:** 이 경보는 스테이지의 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다. 자세한 CloudWatch 지표를 활성화하고 경로별로 지연 시간 성능 요구 사항이 다른 경우, 각 경로의 지연 시간을 보다 세밀하게 모니터링하려면 대체 경보를 생성하는 것이 좋습니다.
**통계: **p90
**권장 임곗값**: 2500.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 하지만 이 값을 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮출 수 있습니다. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**Latency**
**측정 기준: **ApiId, 스테이지, 리소스, 방법
**경보 설명:** 이 경보는 스테이지에서 경로에 대해 높은 지연 시간을 감지합니다. `IntegrationLatency` 지표 값을 찾아 API 백엔드 지연 시간을 확인하세요. 두 지표가 대부분 일치하면 API 백엔드가 지연 시간 증가의 원인이므로 성능 문제가 있는지 조사해야 합니다. CloudWatch Logs를 활성화하고 긴 지연 시간을 유발할 수 있는 오류가 있는지 확인하는 것도 고려해 보세요. 해당하는 경우 [Lambda 통합을 사용한 문제 해결 가이드](https://repost.aws/knowledge-center/api-gateway-high-latency-with-lambda)도 참조할 수 있습니다.
**인텐트:** 이 경보는 스테이지의 경로에 대한 API Gateway 요청에서 지연 시간이 긴 경우를 감지할 수 있습니다.
**통계: **p90
**권장 임곗값**: 2500.0
**임곗값 정당화:** 제안된 임곗값이 모든 API 워크로드에 적용되는 것은 아닙니다. 하지만 이 값을 임곗값의 시작점으로 사용할 수 있습니다. 그런 다음 워크로드와 API의 허용 가능한 지연 시간, 성능, SLA 요구 사항에 따라 다른 임곗값을 선택할 수 있습니다. 일반적으로 API의 지연 시간이 길어도 괜찮다면 임곗값을 더 높게 설정하여 경보의 민감도를 낮추세요. 하지만 API가 거의 실시간에 가까운 응답을 제공할 것으로 예상되는 경우 임곗값을 더 낮게 설정하세요. 또한 과거 데이터를 분석하여 애플리케이션 워크로드의 예상 기준 지연 시간을 파악한 다음 그에 따라 임곗값을 적절히 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**4xx**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 높은 비율의 클라이언트 측 오류를 감지합니다. 이는 권한 부여 또는 클라이언트 요청 매개변수에 문제가 있음을 의미할 수 있습니다. 경로가 제거되었거나 클라이언트가 API에 없는 경로를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4xx 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 [이 가이드](https://repost.aws/knowledge-center/api-gateway-429-limit)에 따라 문제를 해결하세요.
**인텐트:** 이 경보는 API Gateway 요청에 대해 높은 비율의 클라이언트 측 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 4xx 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**5xx**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 높은 비율의 서버 측 오류 감지에 도움이 됩니다. 이는 API 백엔드, 네트워크 또는 API 게이트웨이와 백엔드 API 간의 통합에 문제가 있음을 나타낼 수 있습니다. 이 [설명서](https://repost.aws/knowledge-center/api-gateway-5xx-error)는 5xx 오류의 원인을 해결하는 데 도움이 될 수 있습니다.
**인텐트:** 이 경보는 API Gateway 요청에 대해 높은 비율의 서버 측 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 5xx 오류가 발생하는 경우를 감지합니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 5xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**MessageCount**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 WebSocket API 단계에서 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 클라이언트가 API를 호출할 때 잘못된 엔드포인트 사용 문제 또는 백엔드에서 클라이언트에 메시지를 보내는 데 문제가 있음을 나타낼 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 WebSocket API 단계에서 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 메시지를 수신 및 전송하는 경우 이 경보를 생성하는 것이 좋습니다. 자세한 CloudWatch 지표를 활성화하고 경로별 정상 트래픽 볼륨을 예측할 수 있는 경우, 각 경로에 대한 트래픽 볼륨 감소를 보다 세밀하게 모니터링할 수 있도록 대체 경보를 생성하는 것이 좋습니다. 일정하고 일관된 트래픽이 예상되지 않는 API에는 이 경보를 권장하지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 메시지 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**MessageCount**
**측정 기준: **ApiId, 스테이지, 경로
**경보 설명:** 이 경보는 해당 스테이지에서 WebSocket API 경로에 대해 낮은 트래픽 볼륨을 감지하는 데 도움이 됩니다. 이는 클라이언트가 API를 호출할 때 잘못된 엔드포인트 사용 문제 또는 백엔드에서 클라이언트에 메시지를 보내는 데 문제가 있음을 나타낼 수 있습니다. 또한 API의 구성 또는 권한 문제로 인해 클라이언트가 연결할 수 없게 되었음을 나타내는 지표일 수도 있습니다.
**인텐트:** 이 경보는 해당 스테이지에서 WebSocket API 경로에 대해 예기치 않게 낮은 트래픽 볼륨을 감지할 수 있습니다. API가 정상 조건에서 예측 가능하고 일관된 수의 메시지를 수신 및 전송하는 경우 이 경보를 생성하는 것이 좋습니다. 일정하고 일관된 트래픽이 예상되지 않는 API에는 이 경보를 권장하지 않습니다.
**통계:** SampleCount
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 과거 데이터 분석을 기반으로 임곗값을 설정하여 API의 예상 기준 메시지 수를 결정합니다. 임곗값을 매우 높게 설정하면 정상적이고 트래픽이 적을 것으로 예상되는 기간에 경보가 너무 민감해질 수 있습니다. 반대로 값을 매우 낮게 설정하면 경보가 이례적으로 작은 트래픽 볼륨 감소를 놓칠 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**ClientError**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 높은 비율의 클라이언트 오류를 감지합니다. 이는 권한 부여 또는 메시지 매개변수에 문제가 있음을 의미할 수 있습니다. 경로가 제거되었거나 클라이언트가 API에 없는 경로를 요청하고 있음을 의미할 수도 있습니다. CloudWatch Logs를 활성화하고 4xx 오류의 원인이 될 수 있는 오류가 있는지 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 구성된 제한 한도를 초과하여 오류가 발생할 수도 있습니다. 응답 및 로그에서 예상치 못한 오류가 429개라는 높은 비율로 보고되는 경우 [이 가이드](https://repost.aws/knowledge-center/api-gateway-429-limit)에 따라 문제를 해결하세요.
**인텐트:** 이 경보는 WebSocket API Gateway 메시지에 대해 높은 비율의 클라이언트 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 4xx 오류가 발생하는 경우를 감지합니다. 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 4xx 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ExecutionError**
**측정 기준: **ApiId, 스테이지
**경보 설명:** 이 경보는 높은 비율의 실행 오류 감지에 도움이 됩니다. 이는 통합으로 인한 5xx 오류, 권한 문제 또는 통합의 성공적인 호출을 방해하는 기타 요인(예: 통합이 제한 또는 삭제되는 경우)이 원인일 수 있습니다. API의 CloudWatch Logs를 활성화하고 로그에서 오류의 유형과 원인을 확인해 보세요. 또한 상세한 CloudWatch 지표를 활성화하여 경로별로 이 지표를 확인하고 오류의 원인을 좁히는 것도 고려해 보세요. 이 [설명서](https://repost.aws/knowledge-center/api-gateway-websocket-error)는 모든 연결 오류의 원인을 해결하는 데 도움이 될 수 있습니다.
**인텐트:** 이 경보는 WebSocket API Gateway 메시지에 대해 높은 비율의 실행 오류를 탐지할 수 있습니다.
**통계: **Average
**권장 임곗값: 0.05**
**임곗값 정당화:** 제안된 임곗값은 전체 요청의 5% 이상에서 실행 오류가 발생하는 경우를 감지합니다. 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 실행 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon EC2 Auto Scaling
**GroupInServiceCapacity**
**측정 기준: **AutoScalingGroupName
**경보 설명:** 이 경보는 그룹의 용량이 워크로드에 필요한 용량보다 낮을 경우 이를 감지하는 데 도움이 됩니다. 문제를 해결하려면 조정 활동에서 시작 실패가 있는지 확인하고 원하는 용량 구성이 올바른지 확인하세요.
**인텐트:** 이 경보는 Auto Scaling 그룹에서 시작 실패 또는 시작 일시 중단으로 인한 낮은 가용성을 감지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값은 워크로드 실행에 필요한 최소 용량이어야 합니다. 대부분의 경우 이 값을 GroupDesiredCapacity 지표와 일치하도록 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
## AWS Certificate Manager (ACM)
**DaysToExpiry**
**차원: **CertificateArn
**경보 설명: **이 경보는 ACM에서 관리하거나 ACM으로 가져온 인증서가 만료 날짜에 가까워지는 시기를 감지하는 데 도움이 됩니다. 이를 통해 서비스 중단을 초래할 수 있는 예기치 않은 인증서 만료를 방지할 수 있습니다. 경보가 ‘경보’ 상태로 전환되면 즉각적인 조치를 취하여 인증서를 갱신하거나 다시 가져와야 합니다. ACM 관리형 인증서에 대한 내용은 [인증서 갱신 프로세스](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html)의 지침을 참조하세요. 가져온 인증서는 [다시 가져오기 프로세스](https://docs.aws.amazon.com/acm/latest/userguide/import-reimport.html)의 지침을 참조하세요.
**의도: **이 경보는 다가올 인증서 만료에 대해 사전에 알릴 수 있습니다. 충분한 사전 알림이 제공되어 수동 개입이 가능하므로, 인증서가 만료되기 전에 갱신하거나 교체할 수 있습니다. 이렇게 하면 TLS 지원 서비스의 보안 및 가용성을 유지할 수 있습니다. ‘경보’로 전환되면 인증서 상태를 즉시 조사하고, 필요한 경우 갱신 프로세스를 시작합니다.
**통계: **Minimum
**권장 임곗값: **44.0
**임곗값 근거: **44일 임곗값으로 조기 경고와 잘못된 경보 방지 기능이 서로 균형을 이룰 수 있도록 합니다. 자동 갱신이 실패할 경우 수동 개입을 할 수 있을 만한 충분한 시간이 주어집니다. 인증서 갱신 프로세스 및 운영 응답 시간에 따라 이 값을 조정합니다.
**기간: **86400
**경보를 보낼 데이터 포인트: **1
**평가 기간: **1
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon CloudFront
**5xxErrorRate**
**측정 기준: **DistributionId, Region=Global
**경보 설명:** 이 경보는 오리진 서버의 5xx 오류 응답 비율을 모니터링하여 CloudFront 서비스에 문제가 있는지 감지하는 데 도움이 됩니다. 서버 관련 문제를 이해하는 데 도움이 되는 [오리진의 오류 응답 문제 해결](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-response-errors.html)을 참조하세요. 또한 [추가 메트릭을 활성화](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html#monitoring-console.distributions-additional)하고 자세한 오류 메트릭을 확인하세요.
**인텐트:** 이 경보는 오리진 서버의 요청 처리 문제 또는 CloudFront와 오리진 서버 간의 통신 문제를 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 5xx 응답의 허용 오차에 따라 크게 달라집니다. 과거 데이터와 추세를 분석한 다음 그에 따라 임곗값을 설정할 수 있습니다. 5xx 오류는 일시적인 문제로 인해 발생할 수 있으므로 경보가 너무 민감하지 않도록 임곗값을 0보다 큰 값으로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**OriginLatency**
**측정 기준: **DistributionId, Region=Global
**경보 설명:** 경보는 오리진 서버가 응답하는 데 시간이 너무 오래 걸리는지 모니터링하는 데 도움이 됩니다. 서버가 응답하는 데 시간이 너무 오래 걸리면 타임아웃이 발생할 수 있습니다. 지속적으로 높은 `OriginLatency` 값이 발생하는 경우 [오리진 서버의 애플리케이션에서 지연된 응답을 찾아서 수정하기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html#http-504-gateway-timeout-slow-application)를 참조하세요.
**인텐트:** 이 경보는 오리진 서버가 응답하는 데 시간이 너무 오래 걸리는 문제를 감지하는 데 사용됩니다.
**통계: **p90
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 오리진 응답 제한 시간의 약 80% 값을 계산하고 그 결과를 임곗값으로 사용해야 합니다. 이 지표가 오리진 응답 제한 시간 값에 지속적으로 근접할 경우 504 오류가 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**FunctionValidationErrors**
**측정 기준: **DistributionId, FunctionName, Region=Global
**경보 설명:** 이 경보는 CloudFront Functions의 검증 오류를 모니터링하여 오류를 해결하기 위한 조치를 취할 수 있도록 도와줍니다. CloudWatch 함수 로그를 분석하고 함수 코드를 검토하여 문제의 근본 원인을 찾아 해결합니다. CloudFront Functions의 일반적인 구성 오류를 이해하려면 [엣지 함수에 대한 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-restrictions.html)을 참조하세요.
**인텐트:** 이 경보는 CloudFront Functions의 검증 오류를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값: **0.0
**임곗값 정당화:** 0보다 큰 값은 검증 오류를 나타냅니다. 검증 오류는 CloudFront Functions를 CloudFront로 넘겨줄 때 문제가 있다는 것을 의미하므로 임곗값을 0으로 설정하는 것이 좋습니다. 예를 들어 CloudFront는 요청을 처리하기 위해 HTTP 호스트 헤더가 필요합니다. 사용자가 CloudFront Functions 코드에서 호스트 헤더를 삭제하는 것을 막을 방법은 없습니다. 하지만 CloudFront가 응답을 받고 호스트 헤더가 누락된 경우 CloudFront에서 검증 오류가 발생합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**FunctionExecutionErrors**
**측정 기준: **DistributionId, FunctionName, Region=Global
**경보 설명:** 이 경보는 CloudFront Functions의 실행 오류를 모니터링하여 오류를 해결하기 위한 조치를 취할 수 있도록 도와줍니다. CloudWatch 함수 로그를 분석하고 함수 코드를 검토하여 문제의 근본 원인을 찾아 해결합니다.
**인텐트:** 이 경보는 CloudFront Functions의 실행 오류를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 실행 오류는 런타임에 발생하는 코드에 문제가 있음을 나타내므로 임곗값을 0으로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**FunctionThrottles**
**측정 기준: **DistributionId, FunctionName, Region=Global
**경보 설명:** 이 경보는 CloudFront Functions의 제한 여부를 모니터링하는 데 도움이 됩니다. 함수가 제한되면 실행 시간이 너무 오래 걸린다는 의미입니다. 함수 제한을 방지하려면 함수 코드를 최적화하는 것이 좋습니다.
**인텐트:** 이 경보는 문제에 대응하고 해결하여 원활한 고객 경험을 제공할 수 있도록 CloudFront Functions가 제한되는 시점을 감지합니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 함수 제한 문제를 더 빨리 해결할 수 있도록 임곗값을 0으로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon Cognito
**SignUpThrottles**
**측정 기준: **UserPool, UserPoolClient
**경보 설명:** 이 경보는 제한이 발생한 요청 수를 모니터링합니다. 사용자가 지속적으로 병목 현상을 겪는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 합니다. 할당량 증가를 요청하는 방법은 [Amazon Cognito의 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) 섹션을 참조하세요. 사전 조치를 취하려면 [사용 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage) 추적을 고려해 보세요.
**인텐트:** 이 경보는 제한된 가입 요청의 발생을 모니터링하는 데 도움이 됩니다. 가입 경험의 저하를 완화하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 사용자의 가입 경험에 부정적인 영향을 미칩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 제대로 프로비저닝된 사용자 풀에서는 여러 데이터 포인트에 걸쳐 제한이 발생하지 않아야 합니다. 따라서 예상 워크로드의 일반적인 임곗값은 0이어야 합니다. 버스트가 빈번하고 불규칙한 워크로드의 경우 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 결정한 다음 그에 따라 임곗값을 조정할 수 있습니다. 제한이 발생한 요청은 다시 시도하여 애플리케이션에 미치는 영향을 최소화해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SignInThrottles**
**측정 기준: **UserPool, UserPoolClient
**경보 설명:** 이 경보는 제한이 발생한 사용자 인증 요청 수를 모니터링합니다. 사용자가 지속적으로 병목 현상을 겪는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 할 수 있습니다. 할당량 증가를 요청하는 방법은 [Amazon Cognito의 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) 섹션을 참조하세요. 사전 조치를 취하려면 [사용 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html#track-quota-usage) 추적을 고려해 보세요.
**인텐트:** 이 경보는 제한된 가입 요청의 발생을 모니터링하는 데 도움이 됩니다. 가입 경험의 저하를 완화하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 제대로 프로비저닝된 사용자 풀에서는 여러 데이터 포인트에 걸쳐 제한이 발생하지 않아야 합니다. 따라서 예상 워크로드의 일반적인 임곗값은 0이어야 합니다. 버스트가 빈번하고 불규칙한 워크로드의 경우 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 결정한 다음 그에 따라 임곗값을 조정할 수 있습니다. 제한이 발생한 요청은 다시 시도하여 애플리케이션에 미치는 영향을 최소화해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TokenRefreshThrottles**
**측정 기준: **UserPool, UserPoolClient
**경보 설명:** 요청의 트래픽에 적합하고 토큰 새로 고침 요청의 허용 가능한 제한과 일치하도록 임곗값을 설정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하는 데 사용됩니다. 하지만 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하는 것도 중요합니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 찾은 다음 경보 임곗값을 허용 가능한 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.
**인텐트:** 이 경보는 제한된 토큰 새로 고침 요청의 발생을 모니터링하는 데 도움이 됩니다. 이를 통해 잠재적 문제를 완화하고 원활한 사용자 경험과 인증 시스템의 상태 및 안정성을 보장하기 위한 조치를 언제 실행해야 하는지 알 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 요청의 트래픽과 토큰 새로 고침 요청에 대한 허용 가능한 제한에 적합하게 임곗값을 설정/조정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하기 위한 것이지만, 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하고 이로 인해 제한이 발생하는지 확인하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 확인하고, 임곗값을 일반적인 허용 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**FederationThrottles**
**측정 기준: **UserPool, UserPoolClient, IdentityProvider
**경보 설명:** 이 경보는 제한이 발생한 ID 페더레이션 요청 수를 모니터링합니다. 제한이 지속적으로 발생하는 경우 서비스 할당량 증가를 요청하여 한도를 늘려야 할 수 있습니다. 할당량 증가를 요청하는 방법은 [Amazon Cognito의 할당량](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) 섹션을 참조하세요.
**인텐트:** 이 경보는 제한된 ID 페더레이션 요청의 발생을 모니터링하는 데 도움이 됩니다. 이를 통해 성능 병목 현상이나 잘못된 구성에 사전 대응하고 사용자에게 원활한 인증 경험을 제공할 수 있습니다. 지속적인 요청 제한은 부정적인 사용자 인증 경험입니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 요청의 트래픽에 적합하고 ID 페더레이션 요청의 허용 가능한 제한과 일치하도록 임곗값을 설정할 수 있습니다. 제한은 너무 많은 요청으로부터 시스템을 보호하는 데 사용됩니다. 하지만 정상 트래픽에 대한 프로비저닝이 부족한지 모니터링하는 것도 중요합니다. 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한을 찾은 다음 임곗값을 허용 가능한 제한 수준보다 높은 값으로 설정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon DynamoDB
**AccountProvisionedReadCapacityUtilization**
**측정 기준: **없음
**경보 설명:** 이 경보는 계정의 읽기 용량이 프로비저닝된 한도에 도달하는지 여부를 감지합니다. 이 경우 읽기 용량 사용량에 대한 계정 할당량을 늘릴 수 있습니다. [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 사용하여 읽기 용량 단위의 현재 할당량을 확인하고 증가를 요청할 수 있습니다.
**인텐트:** 이 경보는 계정의 읽기 용량 사용률이 프로비저닝된 읽기 용량 사용률에 근접하는지 여부를 감지할 수 있습니다. 사용률이 최대 한도에 도달하면 DynamoDB가 읽기 요청을 제한하기 시작합니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**AccountProvisionedWriteCapacityUtilization**
**측정 기준: **없음
**경보 설명:** 이 경보는 계정의 쓰기 용량이 프로비저닝된 한도에 도달하는지 여부를 감지합니다. 이 경우 쓰기 용량 사용량에 대한 계정 할당량을 늘릴 수 있습니다. [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)를 사용하여 쓰기 용량 단위의 현재 할당량을 확인하고 증가를 요청할 수 있습니다.
**인텐트:** 이 경보는 계정의 쓰기 용량 사용률이 프로비저닝된 쓰기 용량 사용률에 근접하는지 여부를 감지할 수 있습니다. 사용률이 최대 한도에 도달하면 DynamoDB가 쓰기 요청을 제한하기 시작합니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**AgeOfOldestUnreplicatedRecord**
**측정 기준: **TableName, DelegatedOperation
**경보 설명:** 이 경보는 Kinesis 데이터 스트림으로의 복제에서 지연을 감지합니다. 정상 작동 시 `AgeOfOldestUnreplicatedRecord`는 밀리초 단위여야 합니다. 이 수는 실패한 복제 시도가 고객이 제어하는 구성 선택으로 인해 발생한 경우 시도 횟수를 기준으로 증가합니다. 복제 시도 실패로 이어질 수 있는 고객이 제어하는 구성의 예로는 Kinesis 데이터 스트림 용량이 과소 프로비저닝되어 과도한 제한이 발생하는 경우 또는 Kinesis 데이터 스트림의 액세스 정책을 수동으로 업데이트하여 DynamoDB가 데이터 스트림에 데이터를 추가하지 못하는 경우가 있습니다. 이 지표를 가능한 한 낮게 유지하려면 적절한 Kinesis 데이터 스트림 용량을 프로비저닝하고 DynamoDB의 권한이 변경되지 않도록 해야 합니다.
**인텐트:** 이 경보는 실패한 복제 시도와 그에 따른 Kinesis 데이터 스트림으로의 복제 지연을 모니터링할 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 밀리초 단위로 측정된 원하는 복제 지연에 따라 임곗값을 설정합니다. 이 값은 워크로드의 요구 사항 및 예상 성능에 따라 달라집니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**FailedToReplicateRecordCount**
**측정 기준: **TableName, DelegatedOperation
**경보 설명: **이 경보는 DynamoDB가 Kinesis 데이터 스트림으로 복제하지 못한 레코드 수를 감지합니다. 34KB보다 큰 특정 항목은 Kinesis Data Streams의 1MB 항목 크기 제한보다 큰 데이터 레코드를 변경하기 위해 크기가 확장될 수 있습니다. 이 크기 확장은 34KB보다 큰 이러한 항목에 많은 수의 부울 또는 빈 속성 값을 포함할 때 발생합니다. 부울 및 빈 속성 값은 DynamoDB에 1바이트로 저장되지만, Kinesis Data Streams 복제를 위한 표준 JSON을 사용하여 직렬화되면 최대 5바이트까지 확장합니다. DynamoDB는 이러한 변경 레코드를 Kinesis 데이터 스트림에 복제할 수 없습니다. DynamoDB는 이러한 변경 데이터 레코드를 건너뛰고 자동으로 후속 레코드의 복제를 계속합니다.
**인텐트:** 이 경보는 Kinesis 데이터 스트림의 항목 크기 제한 때문에 DynamoDB가 Kinesis 데이터 스트림에 복제하지 못한 레코드 수를 모니터링할 수 있습니다.
**통계: **Sum
**권장 임곗값: **0.0
**임곗값 정당화:** DynamoDB가 복제에 실패한 모든 레코드를 감지하려면 임곗값을 0으로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **1
**평가 기간: **1
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**측정 기준: **TableName
**경보 설명:** 이 경보는 DynamoDB 테이블에 대해 제한이 발생하는 읽기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 [Amazon DynamoDB의 제한 문제 해결](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)을 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블에 대한 읽기 요청의 지속적인 제한을 감지할 수 있습니다. 읽기 요청의 지속적인 제한은 워크로드 읽기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 읽기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션 또는 서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReadThrottleEvents**
**측정 항목: **TableName, GlobalSecondaryIndexName
**경보 설명:** 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대해 제한이 발생하는 읽기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 [Amazon DynamoDB의 제한 문제 해결](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)을 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대한 읽기 요청의 지속적인 제한을 감지할 수 있습니다. 읽기 요청의 지속적인 제한은 워크로드 읽기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 읽기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션 또는 서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReplicationLatency**
**측정 기준: **TableName, ReceivingRegion
**경보 설명:** 경보는 글로벌 테이블의 특정 리전에 있는 복제본이 소스 리전보다 뒤처지는지 감지합니다. AWS 리전의 성능이 저하되고 해당 리전에 복제 테이블이 있는 경우에 지연 시간이 증가할 수 있습니다. 이 경우 애플리케이션의 읽기 및 쓰기 작업을 다른 AWS 리전으로 일시적으로 리디렉션할 수 있습니다. 2017.11.29(레거시)의 글로벌 테이블을 사용하는 경우 각 복제 테이블의 WCU(쓰기 용량 단위)가 동일한지 확인해야 합니다. [용량 관리를 위한 모범 사례 및 요구 사항](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables_reqs_bestpractices.html#globaltables_reqs_bestpractices.tables)의 권장 사항을 따를 수도 있습니다.
**인텐트:** 경보는 특정 리전의 복제 테이블이 다른 리전의 변경 내용을 복제하는 데 뒤쳐지는지 여부를 감지할 수 있습니다. 이로 인해 복제본이 다른 복제본과 다를 수 있습니다. 각 AWS 리전의 복제 지연 시간을 알고 복제 지연 시간이 계속 증가할 경우 알림을 보내는 것이 좋습니다. 테이블 복제는 글로벌 테이블에만 적용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 일반적으로 3분이 넘는 복제 지연 시간은 조사 원인입니다. 복제 지연의 심각도와 요구 사항을 검토하고 과거 추세를 분석한 다음 그에 따라 임곗값을 선택합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SuccessfulRequestLatency**
**측정 기준: **TableName, Operation
**경보 설명:** 이 경보는 DynamoDB 테이블 작업(경보에서 `Operation`의 차원 값으로 표시됨)에서 높은 지연 시간을 감지합니다. Amazon DynamoDB의 지연 시간 문제를 해결하려면 [문제 해결 문서](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingLatency.html)를 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블 작업의 높은 지연 시간을 감지할 수 있습니다. 작업 지연 시간이 길어지면 시스템의 전체 효율성에 부정적인 영향을 미칠 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** DynamoDB는 GetItem, PutItem 등과 같은 싱글톤 작업에 대해 평균적으로 10밀리초 미만의 지연 시간을 지원합니다. 하지만 워크로드와 관련된 작업 유형 및 테이블의 지연 시간에 대한 허용 가능한 허용 오차를 기반으로 임곗값을 설정할 수 있습니다. 이 지표의 과거 데이터를 분석하여 테이블 작업에 대한 일반적인 지연 시간을 찾은 다음 임곗값을 작업의 심각한 지연을 나타내는 숫자로 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SystemErrors**
**측정 기준: **TableName
**경보 설명:** 이 경보는 DynamoDB 테이블 요청에서 지속적으로 많은 시스템 오류를 감지합니다. 5xx 오류가 계속 발생하면 [AWS서비스 상태 대시보드](https://status.aws.amazon.com/)를 열어 서비스와 관련된 운영 문제를 확인하세요. 이 경보를 사용하면 DynamoDB에서 장기간 내부 서비스 문제가 발생하는 경우 알림을 받을 수 있으며, 이를 통해 클라이언트 애플리케이션이 직면하고 있는 문제와의 상관 관계를 파악할 수 있습니다. 자세한 내용은 [DynamoDB 오류 처리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http5xx)를 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블 요청에 대한 지속적인 시스템 오류를 감지할 수 있습니다. 시스템 오류는 DynamoDB의 내부 서비스 오류를 나타내며 클라이언트가 겪고 있는 문제와의 상관 관계를 파악하는 데 도움이 됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 허용 가능한 시스템 오류 수준을 고려하여 예상 트래픽에 따라 임곗값을 설정합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 수를 찾은 다음 그에 따라 임곗값을 조정할 수 있습니다. 시스템 오류는 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ThrottledPutRecordCount**
**측정 기준: **TableName, DelegatedOperation
**경보 설명:** 이 경보는 변경 데이터 캡처를 Kinesis로 복제하는 동안 Kinesis 데이터 스트림에 의해 제한되는 레코드를 감지합니다. 이러한 제한은 Kinesis 데이터 스트림 용량이 충분하지 않기 때문에 발생합니다. 제한이 지나치게 많고 자주 발생하는 경우 관찰된 테이블의 쓰기 처리량에 비례하여 Kinesis 스트림 샤드 수를 늘려야 할 수 있습니다. Kinesis 데이터 스트림의 크기 결정에 대한 자세한 내용은 [Kinesis 데이터 스트림의 초기 크기 결정](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream)을 참조하세요.
**인텐트:** 이 경보는 Kinesis 데이터 스트림 용량이 부족하여 Kinesis 데이터 스트림에 의해 제한된 레코드 수를 모니터링할 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 예외적으로 사용량이 최고조에 달할 때 약간의 제한이 발생할 수 있지만, 복제 지연 시간이 길어지지 않도록 제한된 레코드 수를 가능한 한 낮게 유지해야 합니다(DynamoDB가 Kinesis 데이터 스트림으로 제한된 레코드의 전송을 다시 시도). 정기적으로 과도한 제한을 포착하는 데 도움이 될 수 있는 숫자로 임곗값을 설정합니다. 또한 이 지표의 과거 데이터를 분석하여 애플리케이션 워크로드에 적합한 제한 속도를 찾을 수 있습니다. 사용 사례에 따라 애플리케이션에서 허용할 수 있는 값으로 임곗값을 조정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**UserErrors**
**측정 기준: **없음
**경보 설명:** 이 경보는 DynamoDB 테이블 요청에서 지속적으로 많은 사용자 오류를 감지합니다. 문제가 지속되는 동안 클라이언트 애플리케이션 로그를 확인하여 요청이 잘못된 이유를 확인할 수 있습니다. [HTTP 상태 코드 400](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.MessagesAndCodes.http400)을 확인하여 발생하는 오류 유형을 확인하고 그에 따라 조치를 취할 수 있습니다. 유효한 요청을 생성하려면 애플리케이션 로직을 수정해야 할 수 있습니다.
**인텐트:** 이 경보는 DynamoDB 테이블 요청에 대한 지속적인 사용자 오류를 감지할 수 있습니다. 요청된 작업에 대한 사용자 오류는 클라이언트가 잘못된 요청을 생성하고 실패했음을 의미합니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 클라이언트 측 오류를 감지하려면 임곗값을 0으로 설정합니다. 또는 매우 적은 수의 오류로 인해 경보가 트리거되지 않게 하려면 더 높은 값으로 설정할 수 있습니다. 요청 시 사용 사례와 트래픽에 따라 결정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**측정 기준: **TableName
**경보 설명:** 이 경보는 DynamoDB 테이블에 대해 제한이 발생하는 쓰기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 [Amazon DynamoDB의 제한 문제 해결](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)을 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블에 대한 쓰기 요청의 지속적인 제한을 감지할 수 있습니다. 쓰기 요청의 지속적인 제한은 워크로드 쓰기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 쓰기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**WriteThrottleEvents**
**측정 항목: **TableName, GlobalSecondaryIndexName
**경보 설명:** 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대해 제한이 발생하는 쓰기 요청 수가 많은지 여부를 감지합니다. 문제를 해결하려면 [Amazon DynamoDB의 제한 문제 해결](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html)을 참조하세요.
**인텐트:** 이 경보는 DynamoDB 테이블의 글로벌 보조 인덱스에 대한 쓰기 요청의 지속적인 제한을 감지할 수 있습니다. 쓰기 요청의 지속적인 제한은 워크로드 쓰기 작업에 부정적인 영향을 미치고 시스템의 전반적인 효율성을 감소시킬 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 허용 가능한 제한 수준을 고려하여 DynamoDB 테이블의 예상 쓰기 트래픽에 따라 임곗값을 설정합니다. 프로비저닝이 부족하고 일관된 제한이 발생하지 않는지 모니터링하는 것이 중요합니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 제한 수준을 찾은 다음 임곗값을 허용 가능한 일반적인 제한 수준보다 높게 조정할 수 있습니다. 제한이 발생한 요청은 일시적이므로 애플리케이션/서비스에서 재시도해야 합니다. 따라서 임곗값이 매우 낮으면 경보가 너무 민감해져 원치 않는 상태 전환이 발생할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon EBS
**VolumeStalledIOCheck**
**차원:** VolumeId, InstanceId
**경보 설명:** 이 경보는 Amazon EBS 볼륨의 IO 성능을 모니터링하는 데 도움이 됩니다. 이 검사는 Amazon EBS 볼륨의 기반이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제, Amazon EC2 인스턴스의 Amazon EBS 볼륨 연결 가능성에 영향을 미치는 물리적 호스트의 하드웨어 문제 등 Amazon EBS 인프라의 근본적인 문제를 탐지하고, 인스턴스와 Amazon EBS 볼륨 간의 연결 문제를 감지할 수 있습니다. 멈춘 IO 검사가 실패하면 AWS에서 문제를 해결할 때까지 기다리거나, 영향을 받는 볼륨을 교체하거나 볼륨이 연결된 인스턴스를 중지하고 다시 시작하는 등의 조치를 취할 수 있습니다. 대부분의 경우 이 지표가 실패하면 Amazon EBS는 몇 분 내에 볼륨을 자동으로 진단하고 복구합니다.
**의도:** 이 경보는 Amazon EBS 볼륨의 상태를 감지하여 해당 볼륨이 손상되어 I/O 작업을 완료할 수 없게 된 시기를 확인할 수 있습니다.
**통계: **Maximum
**권장 임곗값**: 1.0
**임곗값 정당화:** 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon EC2
**CPUUtilization**
**측정 기준: **InstanceId
**경보 설명:** 이 경보는 EC2 인스턴스의 CPU 사용률을 모니터링하는 데 도움이 됩니다. 애플리케이션에 따라 지속적으로 높은 사용률 수준이 정상일 수 있습니다. 그러나 성능이 저하되고 애플리케이션이 디스크 I/O, 메모리 또는 네트워크 리소스의 제약을 받지 않는 경우 CPU 한도가 초과되면 리소스 병목 현상이나 애플리케이션 성능 문제가 발생할 수 있습니다. CPU 사용률이 높으면 CPU 사용량이 더 많은 인스턴스로 업그레이드해야 할 수도 있습니다. 세부 모니터링을 활성화한 경우 기간을 300초가 아닌 60초로 변경할 수 있습니다. 자세한 내용은 [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)를 참조하세요.
**인텐트:** 이 경보는 높은 CPU 사용률을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거:** 일반적으로 CPU 사용률 임곗값을 70\$180%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 시스템의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 시스템에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**StatusCheckFailed**
**측정 기준: **InstanceId
**경보 설명:** 이 경보는 시스템 상태 확인 및 인스턴스 상태 확인 모두를 모니터링하는 데 도움이 됩니다. 둘 중 한나의 상태 확인이 실패하는 경우 이 경보는 ALARM 상태여야 합니다.
**인텐트:** 이 경보는 시스템 상태 확인 실패와 인스턴스 상태 확인 실패를 비롯한 인스턴스의 근본적인 문제를 감지하는 데 사용됩니다.
**통계: **Maximum
**권장 임곗값**: 1.0
**임곗값 정당화:** 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**StatusCheckFailed\$1AttachedEBS**
**측정 기준: **InstanceId
**경보 설명:** 이 경보는 인스턴스에 연결된 Amazon EBS 볼륨이 연결 가능하고 I/O 작업을 완료할 수 있는지 모니터링할 수 있습니다. 이 상태 확인은 다음과 같은 컴퓨팅 또는 Amazon EBS 인프라의 기본 문제를 감지합니다.
+ Amazon EBS 볼륨의 기반이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제
+ Amazon EBS 볼륨의 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
+ 인스턴스와 Amazon EBS 볼륨 간의 연결 문제
연결된 EBS 상태 확인에 실패하면 Amazon이 문제를 해결할 때까지 기다리거나 영향을 받는 볼륨을 교체 또는 인스턴스 중지 후 재시작 등의 조치를 취할 수 있습니다.
**인텐트:** 이 경보는 인스턴스에 연결된 연결할 수 없는 Amazon EBS 볼륨을 감지하는 데 사용됩니다. 이로 인해 I/O 작업이 실패할 수 있습니다.
**통계: **Maximum
**권장 임곗값**: 1.0
**임곗값 정당화:** 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Amazon ElastiCache
**CPUUtilization**
**측정 기준: **CacheClusterId, CacheNodeId
**경보 설명:** 이 경보는 데이터베이스 엔진 프로세스와 인스턴스에서 실행 중인 기타 프로세스를 포함하여 전체 ElastiCache 인스턴스의 CPU 사용률을 모니터링하는 데 도움이 됩니다. AWS Elasticache는 Memcached와 Redis OSS의 두 가지 엔진 유형을 지원합니다. Memcached 노드에서 CPU 사용률이 높아지면 인스턴스 유형을 확장하거나 새 캐시 노드를 추가하는 것을 고려해야 합니다. Redis OSS에서는 주 워크로드가 읽기 요청인 경우 캐시 클러스터에 읽기 전용 복제본을 추가하는 것을 고려해야 합니다. 주 워크로드가 쓰기 요청이라면 클러스터형 모드에서 실행하는 경우 샤드를 추가하여 더 많은 프라이머리 노드에 워크로드를 분산하고, Redis OSS를 비클러스터형 모드에서 실행하는 경우 인스턴스 유형을 확장하는 것을 고려해야 합니다.
**인텐트:** 이 경보는 ElastiCache 호스트의 높은 CPU 사용률을 감지하는 데 사용됩니다. 엔진이 아닌 프로세스를 포함하여 전체 인스턴스의 CPU 사용량을 폭넓게 파악하면 도움이 됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값을 애플리케이션의 중요한 CPU 사용률 수준을 반영하는 백분율로 설정합니다. Memcached의 경우 엔진은 최대 num\$1threads 코어를 사용할 수 있습니다. Redis OSS에서는 엔진이 대부분 단일 스레드이지만 I/O 가속화를 위해 가능한 경우 추가 코어를 사용할 수 있습니다. 대부분의 경우 임곗값을 사용 가능한 CPU의 약 90%로 설정할 수 있습니다. Redis OSS는 단일 스레드이기 때문에 실제 임곗값은 노드 총용량의 일부로 계산해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**CurrConnections**
**측정 기준: **CacheClusterId, CacheNodeId
**경보 설명:** 이 경보는 높은 연결 수를 감지하며 이는 과부하 또는 성능 문제를 나타낼 수 있습니다. `CurrConnections`가 계속 증가하면 사용 가능한 65,000개의 연결이 고갈될 수 있습니다. 이는 애플리케이션 측에서 연결이 잘못 종료되고 서버 측에서는 설정된 상태로 남아 있는 것일 수 있습니다. 연결 풀링 또는 유휴 연결 제한 시간을 사용하여 클러스터에 대한 연결 수를 제한하거나, Redis OSS의 경우 클러스터에서 [tcp-keepalive](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html)를 조정하여 잠재적 데드 피어를 탐지하고 종료하는 방안을 고려해 보세요.
**인텐트:** 경보를 통해 ElastiCache 클러스터의 성능 및 안정성에 영향을 미칠 수 있는 높은 연결 수를 식별할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 클러스터의 허용 가능한 연결 범위에 따라 크게 달라집니다. ElastiCache 클러스터의 용량 및 예상 워크로드를 검토하고, 정기적인 사용 중 과거 연결 수를 분석하여 기준을 설정한 다음 그에 따라 임곗값을 선택합니다. 각 노드는 최대 65,000개의 동시 연결을 지원합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**DatabaseMemoryUsagePercentage**
**측정 기준: **CacheClusterId
**경보 설명:** 이 경보는 클러스터의 메모리 사용률을 모니터링하는 데 도움이 됩니다. `DatabaseMemoryUsagePercentage`가 100%에 도달하면 Redis OSS maxmemory 정책이 트리거되고 선택한 정책에 따라 제거가 발생할 수 있습니다. 캐시에 제거 정책과 일치하는 객체가 없는 경우 쓰기 작업이 실패합니다. 일부 워크로드는 제거를 예상하거나 제거에 의존하지만 그렇지 않은 경우 클러스터의 메모리 용량을 늘려야 합니다. 프라이머리 노드를 추가하여 클러스터를 확장하거나 더 큰 노드 유형을 사용하여 클러스터를 확장할 수 있습니다. 자세한 내용은 [Redis OSS 클러스터용 ElastiCache 확장](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)을 참조하세요.
**인텐트:** 이 경보는 클러스터의 높은 메모리 사용률을 감지하여 클러스터에 쓸 때 오류를 방지할 수 있습니다. 애플리케이션에서 제거가 발생할 것으로 예상되지 않는 경우 클러스터를 확장해야 하는 시기를 알면 도움이 됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 애플리케이션의 메모리 요구 사항과 ElastiCache 클러스터의 메모리 용량에 따라 임곗값을 클러스터의 중요 메모리 사용량 수준을 반영하는 백분율로 설정해야 합니다. 과거 메모리 사용량 데이터를 허용 가능한 메모리 사용량 임곗값에 대한 참조로 사용할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**EngineCPUUtilization**
**측정 기준: **CacheClusterId
**경보 설명:** 이 경보는 ElastiCache 인스턴스에서 Redis OSS 엔진 스레드의 CPU 사용률을 모니터링하는 데 도움이 됩니다. 엔진의 CPU 사용량이 높은 일반적인 이유는 CPU 사용량이 높은 오래 실행되는 명령, 많은 요청 수, 짧은 시간 내에 새 클라이언트 연결 요청 증가, 캐시에 새 데이터를 저장할 메모리가 충분하지 않을 경우 강제 제거 등이 있습니다. 노드를 추가하거나 인스턴스 유형을 확장하여 [Redis OSS 클러스터용 ElastiCache를 확장](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)하는 것을 고려해야 합니다.
**인텐트:** 이 경보는 Redis OSS 엔진 스레드의 높은 CPU 사용률을 감지하는 데 사용됩니다. 데이터베이스 엔진 자체의 CPU 사용량을 모니터링하는 경우에 유용합니다.
**통계: **Average
**권장 임곗값**: 90.0
**임곗값 정당화:** 임곗값을 애플리케이션의 중요한 엔진 CPU 사용률 수준을 반영하는 백분율로 설정합니다. 애플리케이션과 예상 워크로드를 사용하여 클러스터를 벤치마킹하고 EngineCPUUtilization과 성능의 상관 관계를 참조한 다음 그에 따라 임곗값을 설정할 수 있습니다. 대부분의 경우 임곗값을 사용 가능한 CPU의 약 90%로 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReplicationLag**
**측정 기준: **CacheClusterId
**경보 설명:** 이 경보는 ElastiCache 클러스터의 복제 상태를 모니터링하는 데 도움이 됩니다. 복제 지연이 길어지면 프라이머리 노드나 복제본이 복제 속도를 따라갈 수 없다는 뜻입니다. 쓰기 작업이 너무 많으면 프라이머리 노드를 추가하여 클러스터를 확장하거나 더 큰 노드 유형을 사용하여 확장하는 것을 고려해 보세요. 자세한 내용은 [Redis OSS 클러스터용 ElastiCache 확장](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.html)을 참조하세요. 읽기 요청량이 너무 많아 읽기 전용 복제본에 과부하가 걸리면 읽기 전용 복제본을 추가하는 것이 좋습니다.
**인텐트:** 이 경보는 프라이머리 노드의 데이터 업데이트와 복제본 노드와의 동기화 사이에서 지연을 감지하는 데 사용됩니다. 읽기 전용 복제본 클러스터 노드의 데이터 일관성을 보장하는 데 도움이 됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 애플리케이션의 요구 사항과 복제 지연의 잠재적 영향에 따라 임곗값을 설정합니다. 허용 가능한 복제 지연에 대해서는 애플리케이션의 예상 쓰기 속도와 네트워크 상황을 고려해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon ECS
다음은 Amazon ECS의 권장 경보입니다.
**CPUReservation**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 ECS 클러스터의 높은 CPU 예약을 감지하는 데 도움이 됩니다. CPU 예약이 높으면 클러스터에 등록된 해당 작업에 사용할 CPU가 부족하다는 의미일 수 있습니다. 문제를 해결하려면 용량을 추가하거나 클러스터를 확장하거나 Auto Scaling을 설정합니다.
**인텐트:** 경보는 클러스터의 작업에 예약된 총 CPU 단위 수가 클러스터에 등록된 총 CPU 단위에 도달하는지 여부를 감지하는 데 사용됩니다. 이를 통해 클러스터를 확장해야 하는 시기를 알 수 있습니다. 클러스터의 총 CPU 단위에 도달하면 작업에 사용할 CPU가 부족해질 수 있습니다. EC2 용량 공급자의 관리 규모 조정이 활성화되거나 Fargate를 용량 공급자에 연결한 경우에는 이 경보를 사용하지 않는 것이 좋습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **CPU 예약 임곗값을 80%로 설정합니다. 또는 클러스터 특성에 따라 더 낮은 값을 선택해도 됩니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**CPUUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 ECS 서비스의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 진행 중인 ECS 배포가 없는 경우 CPU 사용률이 최대치를 초과하면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다. 문제를 해결하려면 CPU 제한을 늘리면 됩니다.
**인텐트:** 이 경보는 Amazon ECS 서비스의 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 정당화:** CPU 사용률에 대한 서비스 지표가 사용률 100%를 초과할 수 있습니다. 그러나 다른 서비스에 영향을 미치지 않도록 높은 CPU 사용률 지표를 모니터링하는 것이 좋습니다. 임곗값을 약 80\$185%로 설정합니다. 향후 다른 서비스에서 문제가 발생하지 않도록 실제 사용량을 반영하여 작업 정의를 업데이트하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**EBSFilesystemUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 Amazon ECS 태스크에 연결된 Amazon EBS 볼륨의 높은 스토리지 사용률을 감지하는 데 도움이 됩니다. Amazon EBS 볼륨의 사용률이 지속적으로 높으면 사용량을 확인하고 새 태스크의 볼륨 크기를 늘릴 수 있습니다.
**의도: **이 경보는 Amazon ECS 태스크에 연결된 Amazon EBS 볼륨의 높은 스토리지 사용률을 탐지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 Amazon EBS 볼륨이 가득 차서 컨테이너에 장애가 발생할 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **Amazon EBS 파일 시스템 사용률의 임곗값을 약 80%로 설정할 수 있습니다. 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 읽기 전용 스냅샷 볼륨의 경우 사용률이 높다면 볼륨의 크기가 적절하다는 의미일 수 있습니다. 활성 데이터 볼륨의 경우 스토리지 사용률이 높으면 애플리케이션이 대량의 데이터를 쓰고 있다는 의미일 수 있습니다. 이로 인해 용량이 충분하지 않은 경우에는 컨테이너가 실패할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**MemoryReservation**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터의 높은 메모리 예약을 감지하는 데 도움이 됩니다. 메모리 예약이 많으면 클러스터의 리소스 병목 현상이 나타날 수 있습니다. 문제를 해결하려면 서비스 작업의 성능을 분석하여 작업의 메모리 사용률을 최적화할 수 있는지 확인하세요. 또한 메모리를 더 등록하거나 Auto Scaling을 설정할 수 있습니다.
**인텐트:** 경보는 클러스터의 작업에 예약된 총 메모리 단위가 클러스터에 등록된 총 메모리 단위에 도달하는지 여부를 감지하는 데 사용됩니다. 이를 통해 클러스터를 확장해야 하는 시기를 알 수 있습니다. 클러스터의 총 메모리 단위에 도달하면 클러스터가 새 작업을 시작하지 못할 수 있습니다. EC2 용량 공급자의 관리 규모 조정이 활성화되거나 Fargate를 용량 공급자에 연결한 경우에는 이 경보를 사용하지 않는 것이 좋습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **메모리 예약 임곗값을 80%로 설정합니다. 클러스터 특성에 따라 이 값을 더 낮게 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**MemoryUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 진행 중인 Amazon ECS 배포가 없는 경우 메모리 사용률이 최대치를 초과하면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다. 문제를 해결하려면 메모리 제한을 늘리면 됩니다.
**의도:** 이 경보는 Amazon ECS 서비스의 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제가 있다는 의미일 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 정당화:** 메모리 사용률에 대한 서비스 지표가 사용률 100%를 초과할 수 있습니다. 그러나 다른 서비스에 영향을 미치지 않도록 높은 메모리 사용률 지표를 모니터링하는 것이 좋습니다. 임곗값을 약 80%로 설정합니다. 향후 다른 서비스에서 문제가 발생하지 않도록 실제 사용량을 반영하여 작업 정의를 업데이트하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**HTTPCode\$1Target\$15XX\$1Count**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 ECS 서비스에 대한 서버 측 오류 수가 많을 경우 이를 감지하는 데 도움이 됩니다. 이는 오류가 발생하여 서버가 요청을 처리할 수 없게 되었음을 의미할 수 있습니다. 문제를 해결하려면 애플리케이션 로그를 확인하세요.
**인텐트:** 이 경보는 ECS 서비스에 대한 많은 서버 측 오류 수를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 평균 트래픽의 약 5%에 해당하는 값을 계산하고 이 값을 임곗값의 시작점으로 사용합니다. `RequestCount` 지표를 사용하여 평균 트래픽을 확인할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다. 자주 발생하는 5XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TargetResponseTime**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 ECS 서비스 요청에 대한 높은 목표 응답 시간을 감지하는 데 도움이 됩니다. 이는 문제가 발생하여 서비스에서 요청을 제 시간에 처리할 수 없게 되었음을 의미할 수 있습니다. 문제를 해결하려면 CPU 사용률 지표를 확인하고 서비스에 CPU가 부족한지 확인하거나 서비스에서 사용하는 다른 다운스트림 서비스의 CPU 사용률을 확인하세요.
**인텐트:** 이 경보는 ECS 서비스 요청에 대한 높은 목표 응답 시간을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 서비스의 목표 응답 시간에 대한 중요도 및 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Container Insights가 포함된 Amazon ECS
다음은 Container Insights를 사용하는 Amazon ECS의 권장 경보입니다.
**EphemeralStorageUtilized**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Fargate 클러스터에서 활용되는 높은 임시 스토리지를 탐지하는 데 도움이 됩니다. 임시 스토리지가 지속적으로 높은 경우 임시 스토리지 사용량을 확인하고 임시 스토리지를 늘릴 수 있습니다.
**의도:** 이 경보는 Fargate 클러스터의 높은 임시 스토리지 사용량을 탐지하는 데 사용됩니다. 임시 스토리지 사용률이 지속적으로 높으면 디스크가 가득 차서 컨테이너에 장애가 발생할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 임곗값을 임시 스토리지 크기의 약 90%로 설정합니다. Fargate 클러스터의 허용 가능한 임시 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 시스템의 경우 사용률이 지속적으로 높은 임시 스토리지를 사용하는 것이 정상일 수 있지만 다른 시스템의 경우 컨테이너 장애로 이어질 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**RunningTaskCount**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스에서 실행 중인 작업 수가 적은 것을 탐지하는 데 도움이 됩니다. 실행 중인 작업 수가 너무 적으면 애플리케이션이 서비스 로드를 처리할 수 없어 성능 문제가 발생할 수 있습니다. 실행 중인 작업이 없는 경우 Amazon ECS 서비스를 사용할 수 없거나 배포 문제가 있을 수 있습니다.
**의도:** 이 경보는 실행 중인 작업 수가 너무 적은지 여부를 탐지하는 데 사용됩니다. 실행 중인 작업이 지속적으로 적다는 것은 Amazon ECS 서비스 배포 또는 성능 문제를 의미할 수 있습니다.
**통계: **Average
**권장 임곗값**: 0.0
**임곗값 근거:** Amazon ECS 서비스의 최소 실행 작업 수를 기준으로 임곗값을 조정할 수 있습니다. 실행 중인 작업 수가 0인 경우 Amazon ECS 서비스를 사용할 수 없습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskCpuUtilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터에서 작업의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 작업 CPU 사용률이 지속적으로 높으면 작업을 최적화하거나 CPU 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 작업이 스트레스를 받고 있으며, 성능을 유지하기 위해 더 많은 CPU 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 CPU 예약의 약 80%로 설정합니다. 작업에 허용 가능한 CPU 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 성능 문제를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskCpuUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 작업 CPU 사용률이 지속적으로 높으면 작업을 최적화하거나 CPU 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 CPU 사용률을 감지하는 데 사용됩니다. CPU 사용률이 지속적으로 높으면 작업이 스트레스를 받고 있으며, 성능을 유지하기 위해 더 많은 CPU 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 CPU 예약의 약 80%로 설정합니다. 작업에 허용 가능한 CPU 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 성능 문제를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**측정 기준: **ClusterName
**경보 설명: **이 경보는 예약된 CPU와 비교하여 Amazon ECS 클러스터의 컨테이너에서 사용하는 CPU 단위의 비율을 모니터링합니다. ContainerCpuUtilized/ContainerCpuReserved 비율을 기반으로 컨테이너가 CPU 한도에 근접하는 시기를 감지하는 데 도움이 됩니다.
**의도: **이 경보는 Amazon ECS 클러스터의 컨테이너가 `ContainerCpuUtilized/ContainerCpuReserved`로 계산된 예약 CPU 용량의 높은 비율을 사용하는 시기를 감지합니다. 지속적으로 높은 값은 컨테이너가 CPU 한도에 가깝게 운영되고 있다는 것을 나타내며, 용량 조정이 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 컨테이너 CPU 사용률의 약 80%로 설정합니다. 그러면 컨테이너가 CPU 사용률의 정상적인 변동이 허용되는 동안 컨테이너가 CPU 용량 한도에 근접할 때 조기 경고가 제공됩니다. 임곗값은 워크로드 특성 및 성능 요구 사항에 따라 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ContainerCpuUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 예약된 CPU와 비교하여 Amazon ECS 서비스에 속하는 컨테이너에서 사용하는 CPU 단위의 비율을 모니터링합니다. ContainerCpuUtilized/ContainerCpuReserved 비율을 기반으로 컨테이너가 CPU 한도에 근접하는 시기를 감지하는 데 도움이 됩니다.
**의도: **이 경보는 Amazon ECS 서비스에 속하는 컨테이너가 ContainerCpuUtilized/ContainerCpuReserved로 계산된 예약 CPU 용량의 높은 비율을 사용하는 시기를 감지합니다. 지속적으로 높은 값은 컨테이너가 CPU 한도에 가깝게 운영되고 있다는 것을 나타내며, 용량 조정이 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 컨테이너 CPU 사용률의 약 80%로 설정합니다. 그러면 컨테이너가 CPU 사용률의 정상적인 변동이 허용되는 동안 컨테이너가 CPU 용량 한도에 근접할 때 조기 경고가 제공됩니다. 임곗값은 워크로드 특성 및 성능 요구 사항에 따라 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터에서 작업의 높은 임시 스토리지 사용률을 감지하는 데 도움이 됩니다. 스토리지 사용률이 지속적으로 높으면 스토리지 사용률을 최적화하거나 스토리지 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 임시 스토리지 사용률을 감지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 작업에 디스크 공간이 부족하여 제대로 작동하려면 더 많은 스토리지 리소스 또는 최적화가 필요할 수도 있다는 것을 나타낼 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 임시 스토리지 예약의 약 80%로 설정합니다. 작업에 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 잠재적인 디스크 공간 문제 또는 더 많은 스토리이에 대한 필요성을 나타낼 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 임시 스토리지 사용률을 감지하는 데 도움이 됩니다. 스토리지 사용률이 지속적으로 높으면 스토리지 사용률을 최적화하거나 스토리지 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 임시 스토리지 사용률을 감지하는 데 사용됩니다. 스토리지 사용률이 지속적으로 높으면 작업에 디스크 공간이 부족하여 제대로 작동하려면 더 많은 스토리지 리소스 또는 최적화가 필요할 수도 있다는 것을 나타낼 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 임시 스토리지 예약의 약 80%로 설정합니다. 작업에 허용 가능한 스토리지 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 CPU 사용률이 정상일 수도 있지만, 다른 경우에는 잠재적인 디스크 공간 문제 또는 더 많은 스토리이에 대한 필요성을 나타낼 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터에서 작업의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 작업을 최적화하거나 메모리 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 클러스터의 작업에 대한 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 작업이 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 메모리 예약의 약 80%로 설정합니다. 작업에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 작업을 최적화하거나 메모리 예약을 늘려야 할 수도 있습니다.
**의도:** 이 경보는 Amazon ECS 서비스에 속하는 작업의 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 작업이 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 작업 메모리 예약의 약 80%로 설정합니다. 작업에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터에서 컨테이너의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너를 최적화하거나 메모리 예약을 늘려야 할 수 있습니다.
**의도:** 이 경보는 Amazon ECS 클러스터의 컨테이너에 대한 높은 메모리 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 컨테이너 메모리 예약의 약 80%로 설정합니다. 컨테이너에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명:** 이 경보는 Amazon ECS 서비스에 속하는 컨테이너의 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너를 최적화하거나 메모리 예약을 늘려야 할 수 있습니다.
**의도:** 이 경보는 Amazon ECS 서비스의 높은 컨테이너 사용률을 감지하는 데 사용됩니다. 메모리 사용률이 지속적으로 높으면 컨테이너 메모리 압력를 받고 있으며, 안정성을 유지하기 위해 더 많은 메모리 리소스 또는 최적화가 필요할 수도 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 컨테이너 메모리 예약의 약 80%로 설정합니다. 컨테이너에 허용 가능한 메모리 사용률을 기준으로 이 값을 조정할 수 있습니다. 일부 워크로드의 경우에는 지속적으로 높은 메모리 사용률이 정상일 수도 있지만, 다른 경우에는 메모리 압력를 나타내거나 리소스가 더 필요할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**instance\$1filesystem\$1utilization**
**측정기준: **InstanceId, ContainerInstanceId, ClusterName
**경보 설명:** 이 경보는 Amazon ECS 클러스터의 높은 파일 시스템 사용률을 탐지하는 데 도움이 됩니다. 파일 시스템 사용률이 지속적으로 높으면 디스크 사용량을 확인합니다.
**의도:** 이 경보는 Amazon ECS 클러스터의 높은 파일 시스템 사용률을 탐지하는 데 사용됩니다. 파일 시스템 사용률이 지속적으로 높으면 리소스 병목 현상이나 애플리케이션 성능 문제를 의미할 수 있으며, 이로 인해 새 작업이 실행되지 않을 수 있습니다.
**통계: **Average
**권장 임곗값**: 90.0
**임곗값 근거:** 파일 시스템 사용률의 임곗값을 약 90\$195%로 설정할 수 있습니다. Amazon ECS 클러스터의 허용 가능한 파일 시스템 용량 수준을 기준으로 이 값을 조정할 수 있습니다. 일부 시스템의 경우 파일 시스템 사용률이 지속적으로 높으면 정상일 뿐 문제가 아닌 것일 수 있지만, 다른 시스템에서는 문제의 원인이 되어 성능 문제로 이어지고 새 작업을 실행하지 못하게 될 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## 향상된 관찰성을 갖춘 Container Insights가 포함된 Amazon EKS
다음은 향상된 관찰성을 갖춘 Container Insights를 사용하는 Amazon ECS의 권장 경보입니다.
**TaskCpuUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 작업에서 사용되는 CPU 유닛의 총 백분율을 감지하는 데 도움이 됩니다.
**인텐트: **이 경보는 높은 태스크 CPU 사용률을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **일반적으로 CPU 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 태스크의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskMemoryUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 작업에서 사용되는 메모리의 총 비율을 감지하는 데 도움이 됩니다.
**인텐트: **이 경보는 높은 메모리 사용률을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **일반적으로 메모리 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 태스크의 경우 지속적으로 높은 메모리 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 메모리 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 메모리 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ContainerCPUUtilization**
**측정기준: **ContainerName, ClusterName, ServiceName
**경보 설명: **이 경보는 컨테이너에서 사용 중인 CPU 유닛의 총 백분율을 감지하는 데 도움이 됩니다.
**인텐트: **이 경보는 높은 태스크 CPU 사용률을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **일반적으로 CPU 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 컨테이너의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 CPU 사용률 데이터를 분석하여 사용량을 식별하고 컨테이너에 적합한 CPU 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ContainerMemoryUtilization**
**측정기준: **ContainerName, ClusterName, ServiceName
**경보 설명: **이 경보는 컨테이너에서 사용 중인 메모리 유닛의 총 백분율을 감지하는 데 도움이 됩니다.
**의도:** 이 경보는 높은 메모리 사용률을 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **일반적으로 메모리 사용률 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다. 일부 컨테이너의 경우 지속적으로 높은 메모리 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다. 과거의 메모리 사용률 데이터를 분석하여 사용량을 식별하고 태스크에 적합한 메모리 사용률을 찾은 다음 그에 따라 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**TaskEBSfilesystemUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 작업에서 사용 중인 임시 스토리지의 총 백분율을 감지하는 데 도움이 됩니다.
**인텐트: **이 경보는 태스크에 대한 높은 Amazon EBS 파일 시스템 사용률을 탐지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 Amazon EBS 파일 시스템 크기의 약 80%로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**TaskEphemeralStorageUtilization**
**측정 기준: **ClusterName, ServiceName
**경보 설명: **이 경보는 작업에서 사용 중인 임시 스토리지의 총 백분율을 감지하는 데 도움이 됩니다.
**인텐트: **이 경보는 태스크에 대한 높은 임시 스토리지 사용량을 탐지하는 데 사용됩니다. 임시 스토리지 사용률이 지속적으로 높으면 디스크가 가득 차서 태스크에 장애가 발생할 수 있습니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거: **임곗값을 임시 스토리지 크기의 약 80%로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon EFS
**PercentIOLimit**
**측정 기준: **FileSystemId
**경보 설명:** 이 경보는 워크로드가 파일 시스템에서 사용할 수 있는 I/O 한도 내에서 유지되게 하는 데 도움이 됩니다. 지표가 지속적으로 I/O 한도에 도달하는 경우 애플리케이션을 최대 I/O 성능 모드로 사용하는 파일 시스템으로 이동하는 것을 고려해 보세요. 문제를 해결하려면 파일 시스템에 연결된 클라이언트와 파일 시스템을 제한하는 클라이언트의 애플리케이션을 확인합니다.
**인텐트:** 이 경보는 파일 시스템이 범용 성능 모드의 I/O 제한에 얼마나 가깝게 도달해있는지를 감지하는 데 사용됩니다. I/O 비율이 지속적으로 높으면 I/O 요청에 따라 파일 시스템을 충분히 확장할 수 없고, 파일 시스템을 사용하는 애플리케이션에서 파일 시스템이 리소스 병목 현상을 일으킬 수 있다는 의미일 수 있습니다.
**통계: **Average
**권장 임곗값**: 100.0
**임곗값 정당화:** 파일 시스템이 I/O 한도에 도달하면 읽기 및 쓰기 요청에 대한 응답이 느려질 수 있습니다. 따라서 파일 시스템을 사용하는 애플리케이션에 영향을 미치지 않도록 지표를 모니터링하는 것이 좋습니다. 임곗값은 약 100%로 설정할 수 있습니다. 하지만 파일 시스템 특성에 따라 이 값을 더 낮게 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BurstCreditBalance**
**측정 기준: **FileSystemId
**경보 설명:** 이 경보는 파일 시스템 사용에 적용할 수 있는 버스트 크레딧 밸런스가 있는지 확인하는 데 도움이 됩니다. 사용 가능한 버스트 크레딧이 없는 경우 낮은 처리량으로 인해 파일 시스템에 대한 애플리케이션 액세스가 제한됩니다. 지표가 일관되게 0으로 떨어지면 처리량 모드를 [탄력적 또는 프로비저닝된 처리량 모드](https://docs.aws.amazon.com/efs/latest/ug/performance.html#throughput-modes)로 변경하는 것이 좋습니다.
**인텐트:** 이 경보는 파일 시스템의 낮은 버스트 크레딧 밸런스를 감지하는 데 사용됩니다. 지속적으로 낮은 버스트 크레딧 밸런스는 처리량 저하 및 I/O 지연 시간 증가를 나타내는 지표가 될 수 있습니다.
**통계: **Average
**권장 임곗값**: 0.0
**임곗값 정당화:** 파일 시스템에서 버스트 크레딧이 부족하고 기준 처리량이 더 낮은 경우에도 EFS는 모든 파일 시스템에 1MiBps의 측정된 처리량을 계속 지원합니다. 하지만 파일 시스템이 애플리케이션의 리소스 병목 현상으로 작용하지 않도록 지표의 버스트 크레딧 밸런스가 낮은지 모니터링하는 것이 좋습니다. 임곗값은 약 0바이트로 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Container Insights가 포함된 Amazon EKS
**node\$1cpu\$1utilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 EKS 클러스터의 워커 노드에서 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 워커 노드를 CPU가 더 큰 인스턴스로 교체하거나 시스템을 수평적으로 확장해야 할 수 있습니다.
**인텐트:** 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 워커 노드의 CPU 사용률을 모니터링하는 데 도움이 됩니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**node\$1filesystem\$1utilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 EKS 클러스터의 워커 노드에서 높은 파일 시스템 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 워커 노드를 업데이트하여 디스크 볼륨을 늘리거나 수평적으로 확장해야 할 수 있습니다.
**경보 설명:** 이 경보는 EKS 클러스터의 워커 노드에서 높은 파일 시스템 사용률을 모니터링하는 데 도움이 됩니다. 사용률이 100%에 도달하면 애플리케이션 장애, 디스크 I/O 병목 현상, 포드 제거 또는 노드가 완전히 응답하지 않게 될 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 디스크 압력이 충분하면(즉 디스크가 꽉 차면) 노드가 비정상으로 표시되고 포드가 노드에서 제거됩니다. 디스크 압력이 큰 노드의 포드는 사용 가능한 파일 시스템이 kubelet에 설정된 제거 임곗값보다 낮을 경우에 제거됩니다. 클러스터에서 노드가 제거되기 전에 대응할 충분한 시간을 확보할 수 있도록 경보 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**node\$1memory\$1utilization**
**측정 기준: **ClusterName
**경보 설명:** 이 경보는 EKS 클러스터의 워커 노드에서 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 포드 복제본 수를 조정하거나 애플리케이션을 최적화해야 할 수 있습니다.
**인텐트:** 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 워커 노드의 메모리 사용률을 모니터링하는 데 도움이 됩니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**pod\$1cpu\$1utilization\$1over\$1pod\$1limit**
**측정 기준: **ClusterName, Namespace, Service
**경보 설명:** 이 경보는 EKS 클러스터의 포드에서 높은 CPU 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 영향을 받는 포드의 CPU 한도를 늘려야 할 수 있습니다.
**인텐트:** 이 경보는 EKS 클러스터의 Kubernetes 서비스에 속하는 포드의 CPU 사용률을 모니터링하는 데 도움이 되며 이를 통해 서비스의 포드가 예상보다 높은 CPU를 소비하고 있는지 빠르게 식별할 수 있습니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**pod\$1memory\$1utilization\$1over\$1pod\$1limit**
**측정 기준: **ClusterName, Namespace, Service
**경보 설명:** 이 경보는 EKS 클러스터의 포드에서 높은 메모리 사용률을 감지하는 데 도움이 됩니다. 사용률이 지속적으로 높으면 영향을 받는 포드의 메모리 한도를 늘려야 할 수 있습니다.
**인텐트:** 이 경보는 시스템 성능이 저하되지 않도록 EKS 클러스터에 있는 포드의 메모리 사용률을 모니터링하는 데 도움이 됩니다.
**통계: **Maximum
**권장 임곗값**: 80.0
**임곗값 정당화:** 시스템에서 영향을 받기 시작하기 전에 문제를 디버깅할 충분한 시간을 확보할 수 있도록 임곗값을 80% 이하로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon EventBridge Scheduler
**TargetErrorThrottledCount**
**측정 기준: **없음
**경보 설명: **이 경보는 대상 스로틀링을 식별하는 데 도움이 됩니다. 대상 스로틀링 오류를 방지하려면 간접 호출 로드를 분산하도록 [유연한 시간대를 구성](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html)하거나, 대상 서비스를 활용하여 한도를 늘리는 것이 좋습니다.
**의도: **이 경보는 일정 지연을 일으킬 수 있는 대상 스로틀링 오류를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 근거: **대상 스로틀링 오류가 지속적으로 0보다 큰 경우 일정 전송이 지연됩니다. 일부 시스템의 경우에는 짧은 기간의 대상 스로틀링 오류는 정상일 수 있지만, 다른 시스템의 경우에는 문제가 될 수 있습니다. 이 경보의 임곗값인 `datapointsToAlarm`을 설정하고, 그에 따라 `evaluationPeriods`를 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**InvocationThrottleCount**
**측정 기준: **없음
**경보 설명: **이 경보는 Amazon EventBridge Scheduler에 의한 간접 호출 스로틀링을 식별하는 데 도움이 됩니다. 간접 호출 스로틀링 오류를 방지하려면 간접 호출 로드를 분산하도록 [유연한 시간대를 구성](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule-flexible-time-windows.html)하거나, [간접 호출 스로틀링 한도를 늘리는](https://docs.aws.amazon.com/scheduler/latest/UserGuide/scheduler-quotas.html) 것이 좋습니다.
**의도: **이 경보는 Amazon EventBridge Scheduler 간접 호출 스로틀링 오류를 감지하는 데 사용되며, 이로 인해 일정 지연이 발생할 수 있습니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 근거: **간접 호출 스로틀링 오류가 지속적으로 0보다 큰 경우 일정 전송이 지연됩니다. 일부 시스템의 경우에는 짧은 기간의 간접 호출 스로틀링 오류는 정상일 수 있지만, 다른 시스템의 경우에는 문제가 될 수 있습니다. 이 경보의 임곗값인 `datapointsToAlarm`을 설정하고, 그에 따라 `evaluationPeriods`를 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**InvocationDroppedCount**
**측정 기준: **없음
**경보 설명: **이 경보는 Amazon EventBridge Scheduler에서 삭제한 간접 호출을 식별하는 데 도움이 됩니다. 일정에 대한 [DLQ를 구성](https://docs.aws.amazon.com/scheduler/latest/UserGuide/configuring-schedule-dlq.html)하여 조사하는 것이 좋습니다.
**의도: **이 경보는 Amazon EventBridge Scheduler에서 삭제한 간접 호출을 감지하는 데 사용됩니다. 모든 일정에 DLQ를 올바르게 구성한 경우 삭제된 간접 호출이 DLQ에 표시되며 이 경보 설정을 건너뛸 수 있습니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 근거: **삭제된 간접 호출을 감지하려면 임곗값을 0으로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **1
**평가 기간: **1
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**InvocationsFailedToBeSentToDeadLetterCount**
**측정 기준: **없음
**경보 설명: **이 경보는 Amazon EventBridge Scheduler에서 구성한 DLQ로 전송하지 못한 호출을 식별하는 데 도움이 됩니다. 지표가 지속적으로 0보다 큰 경우 DLQ 구성을 수정하여 문제를 해결합니다. `InvocationsFailedToBeSentToDeadLetterCount`\$1metrics를 사용하여 문제를 확인합니다.
**의도: **이 경보는 Amazon EventBridge Scheduler에서 구성한 DLQ로 전송하지 못한 호출을 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 근거: **구성된 DLQ로 전송하지 못한 간접 호출을 감지하려면 임곗값을 0으로 설정합니다. 재시도 가능한 오류도 이 지표에 표시되므로, 이 경보의 `datapointsToAlarm`은 15로 설정되었습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon Kinesis Data Streams
**GetRecords.IteratorAgeMilliseconds**
**측정 기준: **StreamName
**경보 설명:** 이 경보는 반복자 최대 수명이 너무 높은 경우 이를 감지할 수 있습니다. 실시간 데이터 처리 애플리케이션의 경우 지연 허용치에 따라 데이터 보존을 구성합니다. 이는 보통 몇 분 이내입니다. 기록 데이터를 처리하는 애플리케이션의 경우 이 지표를 사용하여 캐치업 속도를 모니터링합니다. 데이터 손실을 막는 빠른 해결책은 문제를 해결하는 동안 보존 기간을 늘리는 것입니다. 또한 소비자 애플리케이션에서 레코드를 처리하는 작업자 수를 늘릴 수 있습니다. 반복자 수명이 점점 증가하는 가장 일반적인 원인은 물리적 리소스가 부족하거나 레코드 처리 로직이 스트림 처리량의 증가에 따라 조정되지 않기 때문입니다. 자세한 내용은 [링크](https://repost.aws/knowledge-center/kinesis-data-streams-iteratorage-metric)를 참조하세요.
**인텐트:** 이 경보는 스트림의 데이터가 너무 오래 보존되거나 레코드 처리 속도가 너무 느려 만료되는 것을 감지하는 데 사용됩니다. 이를 통해 스트림 보존 기간의 100%에 도달한 후에도 데이터 손실을 방지할 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 스트림 보존 기간 및 레코드의 처리 지연 허용 한도에 따라 크게 달라집니다. 요구 사항을 검토하고 과거 추세를 분석한 다음 임곗값을 심각한 처리 지연을 나타내는 밀리초로 설정합니다. 반복자 수명이 보존 기간(기본적으로 24시간, 최대 365일까지 구성 가능)의 50%를 경과하면 레코드 만료로 인해 데이터가 손실될 위험이 있습니다. 지표를 모니터링하여 샤드가 이 한도에 도달하지 않게 할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**GetRecords.Success**
**측정 기준: **StreamName
**경보 설명:** 이 지표는 소비자가 스트림에서 데이터를 성공적으로 읽을 때마다 증가합니다. `GetRecords`는 예외가 발생해도 데이터를 반환하지 않습니다. 가장 일반적인 예외는 `ProvisionedThroughputExceededException`입니다. 스트림에 대한 요청 속도가 너무 높거나 주어진 시간 동안 사용 가능한 처리량이 이미 제공되었기 때문입니다. 요청의 횟수 또는 크기를 줄입니다. 자세한 내용은 Amazon Kinesis Data Streams 개발자 안내서의 스트림 [제한](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) 및 [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)를 참조하세요.
**인텐트:** 이 경보는 소비자가 스트림에서 레코드를 검색하는 데 실패하는지 여부를 감지할 수 있습니다. 이 지표에 대해 경보를 설정하면 오류율 증가 또는 검색 성공 감소 등 데이터 소비 관련 문제를 사전에 감지할 수 있습니다. 이를 통해 적시에 조치를 취하여 잠재적 문제를 해결하고 원활한 데이터 처리 파이프라인을 유지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 스트림에서 레코드 검색의 중요도에 따라 실패한 레코드에 대한 애플리케이션의 허용 범위를 기반으로 임곗값을 설정합니다. 임곗값은 성공한 작업에 해당하는 비율이어야 합니다. 과거 GetRecords 지표 데이터를 허용 가능한 실패율에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 다시 시도될 수 있으므로 임곗값을 설정할 때는 재시도를 고려해야 합니다. 이렇게 하면 일시적 스파이크로 인해 불필요한 경보가 트리거되는 것을 방지할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**PutRecord.Success**
**측정 기준: **StreamName
**경보 설명:** 이 경보는 실패한 `PutRecord` 작업 수가 임곗값을 초과할 때 이를 감지합니다. 데이터 생산자 로그를 조사하여 실패의 근본 원인을 찾습니다. 가장 일반적인 이유는 `ProvisionedThroughputExceededException` 문제를 일으킨 샤드의 프로비저닝 처리량이 충분하지 않기 때문입니다. 스트림에 대한 요청 속도가 너무 높거나 샤드로 인제스트하려는 처리량이 너무 높아서 발생합니다. 요청의 횟수 또는 크기를 줄입니다. 자세한 내용은 스트림 [제한](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) 및 [AWS의 오류 재시도 및 지수 백오프](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)를 참조하세요.
**인텐트:** 이 경보는 스트림으로의 레코드 수집 실패 여부를 감지할 수 있습니다. 스트림에 데이터를 쓸 때 발생하는 문제를 식별하는 데 도움이 됩니다. 이 지표에 경보를 설정하면 제작자가 스트림에 데이터를 게시할 때 발생하는 문제(예: 오류율 증가 또는 레코드 게시 성공 감소)를 사전에 감지할 수 있습니다. 이를 통해 적시에 조치를 취하여 잠재적 문제를 해결하고 신뢰할 수 있는 데이터 수집 프로세스를 유지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 서비스에서 데이터 수집 및 처리의 중요도에 따라 실패한 레코드에 대한 애플리케이션의 허용 범위를 기반으로 임곗값을 설정합니다. 임곗값은 성공한 작업에 해당하는 비율이어야 합니다. 과거 PutRecord 지표 데이터를 허용 가능한 실패율에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 다시 시도될 수 있으므로 임곗값을 설정할 때는 재시도를 고려해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**PutRecords.FailedRecords**
**측정 기준: **StreamName
**경보 설명:** 이 경보는 실패한 `PutRecords` 수가 임곗값을 초과할 때 이를 감지합니다. Kinesis Data Streams는 각 `PutRecords` 요청의 모든 레코드를 처리하려고 시도하지만 단일 레코드 장애가 발생해도 후속 레코드 처리가 중단되지 않습니다. 이러한 실패의 주요 원인은 스트림 또는 개별 샤드의 처리량 초과입니다. 일반적인 원인은 트래픽 스파이크와 네트워크 지연 현상으로 인해 레코드가 스트림에 일정하지 않게 도착하는 것입니다. 따라서 성공적으로 처리되지 않은 레코드를 찾아 후속 호출에서 재시도해야 합니다. 자세한 내용은 [PutRecords 사용 시 실패 처리](https://docs.aws.amazon.com/streams/latest/dev/developing-producers-with-sdk.html)를 참조하세요.
**인텐트:** 이 경보는 일괄 작업을 사용하여 스트림에 레코드를 넣을 때 일관된 오류를 감지할 수 있습니다. 이 지표에 경보를 설정하면 실패한 레코드의 증가를 사전에 감지하고 적시에 조치를 취하여 근본적인 문제를 해결하며 원활하고 안정적인 데이터 수집 프로세스를 보장할 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 실패한 레코드에 대한 애플리케이션의 허용 범위를 반영하여 실패 레코드 수로 임곗값을 설정합니다. 과거 데이터를 허용 가능한 실패 값에 대한 참조로 사용할 수 있습니다. 또한 실패한 레코드는 후속 PutRecords 호출에서 재시도될 수 있으므로 임곗값을 설정할 때 재시도를 고려해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReadProvisionedThroughputExceeded**
**측정 기준: **StreamName
**경보 설명:** 경보는 읽기 처리량 용량 제한을 초래하는 레코드 수를 추적합니다. 지속적으로 제한이 발생하는 경우 스트림에 샤드를 추가하여 프로비저닝된 읽기 처리량을 늘리는 것을 고려해야 합니다. 스트림에서 실행 중인 소비자 애플리케이션이 두 개 이상이고 `GetRecords` 한도를 공유하는 경우 Enhanced Fan-Out을 통해 새 소비자 애플리케이션을 등록하는 것이 좋습니다. 샤드를 추가해도 제한 수가 줄어들지 않으면 특정 “핫” 샤드가 다른 샤드보다 더 많이 읽히고 있을 수 있습니다. 향상된 모니터링을 활성화하고 “핫” 샤드를 찾아 분할합니다.
**인텐트:** 이 경보는 소비자가 프로비저닝된 읽기 처리량(보유한 샤드 수에 따라 결정됨)을 초과할 경우 제한되는지 여부를 감지할 수 있습니다. 이 경우 스트림에서 읽을 수 없게 되며 스트림이 백업을 시작할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 일반적으로 제한이 발생한 요청은 재시도될 수 있으므로 임곗값을 0으로 설정하면 경보가 너무 민감해집니다. 하지만 지속적인 제한은 스트림의 읽기에 영향을 줄 수 있으므로 경보를 트리거해야 합니다. 애플리케이션 및 재시도 구성에 대해 제한이 발생한 요청에 따라 임곗값을 백분율로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SubscribeToShardEvent.MillisBehindLatest**
**측정 기준: **StreamName, ConsumerName
**경보 설명:** 이 경보는 애플리케이션의 레코드 처리 지연이 임곗값을 초과할 때 이를 감지합니다. 다운스트림 애플리케이션에 대한 API 작업 실패와 같은 일시적인 문제로 인해 지표가 갑자기 증가할 수 있습니다. 이러한 문제가 지속적으로 발생하는지 조사해야 합니다. 일반적인 원인은 물리적 리소스가 충분하지 않거나 스트림 처리량 증가에 따라 확장되지 않는 레코드 처리 로직 때문에 소비자가 레코드를 충분히 빠르게 처리하지 못하는 것입니다. 중요 경로에서 호출을 차단하면 레코드 처리 속도가 느려지는 경우가 많습니다. 샤드 수를 늘려 병렬 처리를 늘릴 수 있습니다. 또한 수요가 최고조에 달할 때는 기본 프로세싱 노드에 충분한 물리적 리소스가 있는지 확인해야 합니다.
**인텐트:** 이 경보는 스트림의 샤드 이벤트 구독 지연을 감지할 수 있습니다. 이는 처리 지연을 나타내며 소비자 애플리케이션의 성능 또는 전체 스트림 상태와 관련된 잠재적 문제를 식별하는 데 도움이 될 수 있습니다. 처리 지연이 심각해지면 병목 현상이나 소비자 애플리케이션 비효율성을 조사하고 해결하여 실시간 데이터 처리를 보장하고 데이터 백로그를 최소화해야 합니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 애플리케이션이 허용할 수 있는 지연에 따라 크게 달라집니다. 애플리케이션의 요구 사항을 검토하고 과거 추세를 분석한 다음 그에 따라 임곗값을 선택합니다. SubscribeToShard 호출이 성공하면 소비자는 최대 5분 동안 지속적인 연결을 통해 SubscribeToShardEvent 이벤트를 수신하기 시작합니다. 이 시간이 지난 후 계속 레코드를 수신하려면 SubscribeToShard를 다시 호출하여 구독을 갱신해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**WriteProvisionedThroughputExceeded**
**측정 기준: **StreamName
**경보 설명:** 이 경보는 쓰기 처리량 용량 제한을 초래하는 레코드 수가 임곗값에 도달했을 때 이를 감지합니다. 생산자가 프로비저닝된 쓰기 처리량(보유한 샤드 수에 따라 결정됨)을 초과하면 전송이 제한되고 레코드를 스트림에 넣을 수 없게 됩니다. 지속적인 제한 문제를 해결하려면 스트림에 샤드를 추가하는 것을 고려해야 합니다. 이렇게 하면 프로비저닝된 쓰기 처리량이 증가하고 향후 제한이 방지됩니다. 레코드를 수집할 때 파티션 키 선택도 고려해야 합니다. 무작위 파티션 키는 가급적 스트림의 샤드 전체에 균등하게 레코드를 분산시키기 때문에 선호됩니다.
**인텐트:** 이 경보는 스트림이나 샤드의 제한으로 인해 생산자가 레코드 작성을 거부당하는지 여부를 감지할 수 있습니다. 스트림이 Provisioned 모드인 경우 이 경보를 설정하면 데이터 스트림이 한도에 도달했을 때 사전 조치를 취할 수 있으므로 프로비저닝된 용량을 최적화하거나 적절한 조정 조치를 취하여 데이터 손실을 방지하고 원활한 데이터 처리를 유지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 일반적으로 제한이 발생한 요청은 재시도될 수 있으므로 임곗값을 0으로 설정하면 경보가 너무 민감해집니다. 하지만 지속적인 제한은 스트림 쓰기에 영향을 미칠 수 있으므로 이를 감지하도록 경보 임곗값을 설정해야 합니다. 애플리케이션 및 재시도 구성에 대해 제한이 발생한 요청에 따라 임곗값을 백분율로 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Lambda
**ClaimedAccountConcurrency**
**측정 기준: **없음
**경보 설명:** 이 경보는 Lambda 함수의 동시성이 계정의 리전 수준 동시성 한도에 근접하는지 모니터링하는 데 도움이 됩니다. 동시 실행 한도에 도달하면 함수에 제한이 발생하기 시작합니다. 제한 현상을 방지하려면 다음 작업을 수행할 수 있습니다.
1. 이 리전의 [동시 접속자 수 증가](https://repost.aws/knowledge-center/lambda-concurrency-limit-increase)를 요청합니다.
1. 미사용 예약 동시성 또는 프로비저닝된 동시성을 식별하여 줄일 수 있습니다.
1. 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다.
1. 함수를 간접 호출할 때마다 더 많은 메시지가 처리되도록 함수의 배치 크기를 늘립니다.
**인텐트:** 이 경보는 Lambda 함수의 동시성이 계정의 리전 수준 동시성 할당량에 근접하는지 사전에 감지하여 조치를 취할 수 있도록 해줍니다. `ClaimedAccountConcurrency`가 계정의 리전 수준 동시성 할당량에 도달하면 함수가 제한됩니다. 예약 동시성(RC) 또는 프로비저닝된 동시성(PC)을 사용하는 경우 이 경보를 사용하면 `ConcurrentExecutions`보다 동시성 사용률을 더 잘 파악할 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 리전 내 계정에 설정된 동시 접속자 수 할당량의 약 90%의 값을 계산하고 그 결과를 임곗값으로 사용해야 합니다. 기본적으로 리전 내 모든 함수에 걸쳐 사용자 계정의 동시성 할당량은 1,000입니다. 하지만 Service Quotas 대시보드에서 계정의 할당량을 확인해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**오류**
**측정 기준: **FunctionName
**경보 설명:** 이 경보는 높은 오류 수를 감지합니다. 오류에는 코드에서 발생하는 예외와 Lambda 런타임에서 발생하는 예외가 포함됩니다. 함수와 관련된 로그를 확인하여 문제를 진단할 수 있습니다.
**인텐트:** 경보는 함수 호출 시 오류 수가 많은 경우를 감지하는 데 도움이 됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값을 0보다 큰 수로 설정합니다. 정확한 값은 애플리케이션의 오류 허용 오차에 따라 달라질 수 있습니다. 함수가 처리하는 호출의 중요도를 이해해야 합니다. 일부 애플리케이션의 경우 어떠한 오류도 허용되지 않을 수 있지만 다른 애플리케이션에서는 일정한 오차 범위를 허용할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**제한**
**측정 기준: **FunctionName
**경보 설명:** 이 경보는 제한이 발생한 간접 호출 요청 수가 많음을 감지합니다. 스케일 업에 사용할 수 있는 동시성이 없는 경우 제한이 발생합니다. 이 문제를 해결할 몇 가지 방법이 있습니다. 1) 이 리전의 AWS Support에 동시성 증가를 요청합니다. 2) 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다. 3) 함수를 간접 호출할 때마다 더 많은 메시지가 처리되도록 함수의 배치 크기를 늘립니다.
**인텐트:** 경보는 Lambda 함수에 대해 많은 수의 제한된 간접 호출 요청 수를 감지하는 데 도움이 됩니다. 제한으로 인해 요청이 계속 거부되는지, 지속적인 제한을 피하기 위해 Lambda 함수 성능을 개선하거나 동시성 용량을 늘려야 하는지를 파악해야 합니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값을 0보다 큰 수로 설정합니다. 정확한 임곗값은 애플리케이션의 허용 오차에 따라 달라질 수 있습니다. 함수의 사용 및 조정 요구 사항에 따라 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**지속 시간**
**측정 기준: **FunctionName
**경보 설명:** 이 경보는 Lambda 함수가 이벤트를 처리하는 데 오랜 시간이 걸리는 것을 감지합니다. 함수 코드가 변경되어 함수를 실행하는 데 시간이 더 오래 걸리거나 함수의 종속성이 더 오래 걸리기 때문에 지속 시간이 길어질 수 있습니다.
**인텐트:** 이 경보는 Lambda 함수의 긴 실행 기간을 감지할 수 있습니다. 런타임 기간이 길면 함수를 간접 호출하는 데 시간이 더 오래 걸리고 Lambda가 더 많은 수의 이벤트를 처리하는 경우 간접 호출의 동시 실행 용량에도 영향을 미칠 수 있습니다. Lambda 함수의 실행 시간이 계속 예상보다 길어지는지 파악해야 합니다.
**통계: **p90
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 기간 임곗값은 애플리케이션과 워크로드, 성능 요구 사항에 따라 달라집니다. 고성능 요구 사항의 경우 임곗값을 더 짧은 시간으로 설정하여 함수가 기대치를 충족하는지 확인합니다. 또한 기간 지표에 대한 과거 데이터를 분석하여 소요 시간이 함수의 예상 성능과 일치하는지 확인한 다음 임곗값을 과거 평균보다 긴 시간으로 설정할 수 있습니다. 임곗값을 구성된 함수의 제한 시간보다 낮게 설정해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ConcurrentExecutions**
**측정 기준: **FunctionName
**경보 설명:** 이 경보는 함수의 동시성이 계정의 리전 수준 동시성 한도에 근접하는지 모니터링하는 데 도움이 됩니다. 동시 실행 한도에 도달하면 함수에 제한이 발생하기 시작합니다. 제한 현상을 방지하려면 다음 작업을 수행할 수 있습니다.
1. 이 리전의 동시 접속자 수 증가를 요청합니다.
1. 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다.
1. 함수를 간접 호출할 때마다 더 많은 메시지가 처리되도록 함수의 배치 크기를 늘립니다.
예약된 동시성 및 프로비저닝된 동시성 사용률을 더 잘 파악하려면 대신 새 지표 `ClaimedAccountConcurrency`에 경보를 설정하세요.
**인텐트:** 이 경보는 함수의 동시성이 계정의 리전 수준 동시성 할당량에 근접하는지 사전에 감지하여 조치를 취할 수 있도록 해줍니다. 함수가 계정의 리전 수준 동시성 할당량에 도달하면 함수가 제한됩니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값을 해당 리전의 계정에 설정된 동시성 할당량의 약 90%로 설정합니다. 기본적으로 리전 내 모든 함수에 걸쳐 사용자 계정의 동시성 할당량은 1,000입니다. 하지만 AWS 지원팀에 문의하여 계정의 할당량을 늘릴 수 있으므로 계정 할당량을 확인합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Lambda Insights
Lambda Insights 지표에 대해 모범 사례 경보를 설정하는 것이 좋습니다.
**memory\$1utilization**
**측정 기준: **function\$1name
**경보 설명:** 이 경보는 Lambda 함수의 메모리 사용률이 구성된 한도에 근접하는지 감지하는 데 사용됩니다. 문제 해결을 위해 1) 코드 최적화를 시도합니다. 2) 메모리 요구량을 정확하게 예측하여 메모리 할당량을 적절하게 조정합니다. 이에 대한 내용은 [Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html)을 참조하세요. 3) 연결 풀링을 사용합니다. RDS 데이터베이스의 연결 풀링에 대한 내용은 [Lambda와 함께 Amazon RDS Proxy 사용](https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/)을 참조하세요. 4) 호출 사이에 대량의 데이터를 메모리에 저장하지 않도록 함수를 설계하는 것도 고려해 볼 수 있습니다.
**인텐트:** 이 경보는 Lambda 함수의 메모리 사용률이 구성된 한도에 근접하는지 감지하는 데 사용됩니다.
**통계: **Average
**입곗값 제안: **90.0
**임곗값 정당화:** 메모리 사용률이 할당된 메모리의 90%를 초과할 때 경보를 받으려면 임곗값을 90%로 설정합니다. 메모리 사용량에 대한 워크로드가 우려되는 경우 이 값을 더 낮게 조정할 수 있습니다. 또한 이 지표의 과거 데이터를 확인하고 그에 따라 임곗값을 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon VPC(`AWS/NATGateway`)
**ErrorPortAllocation**
**측정 기준: **NatGatewayId
**경보 설명:** 이 경보는 NAT 게이트웨이가 새 연결에 포트를 할당할 수 없는 경우를 감지하는 데 도움이 됩니다. 이 문제를 해결하려면 [NAT 게이트웨이의 포트 할당 오류 해결](https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors)을 참조하세요.
**인텐트:** 이 경보는 NAT 게이트웨이가 소스 포트를 할당할 수 없는지 여부를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** ErrorPortAllocation의 값이 0보다 크면 NATGateway를 통해 인기 있는 단일 대상에 대한 동시 연결이 너무 많이 열려 있음을 의미합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**PacketsDropCount**
**측정 기준: **NatGatewayId
**경보 설명:** 이 경보는 NAT 게이트웨이가 패킷을 삭제한 시점을 감지하는 데 도움이 됩니다. 이는 NAT 게이트웨이 문제로 인해 발생할 수 있으므로 [AWS 서비스 상태 대시보드](https://health.aws.amazon.com/health/status)에서 해당 리전의 AWS NAT 게이트웨이 상태를 확인합니다. 이를 통해 NAT 게이트웨이를 사용하는 트래픽과 관련된 네트워크 문제의 상관 관계를 파악할 수 있습니다.
**인텐트:** 이 경보는 NAT 게이트웨이가 패킷을 삭제하는지 여부를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** NAT 게이트웨이 총 트래픽의 0.01%를 계산하고 이 결과를 임곗값으로 사용해야 합니다. NAT 게이트웨이 트래픽의 과거 데이터를 사용하여 임곗값을 결정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## AWS 프라이빗 링크(`AWS/PrivateLinkEndpoints`)
**PacketsDropped**
**측정 기준: **VPC Id, VPC 엔드포인트 Id, 엔드포인트 유형,서브넷 Id, 서비스 이름
**경보 설명:** 이 경보는 엔드포인트에서 삭제한 패킷 수를 모니터링하여 엔드포인트 또는 엔드포인트 서비스가 비정상인지 여부를 감지하는 데 도움이 됩니다. VPC 엔드포인트에 도착하는 크기가 8500바이트보다 큰 패킷은 삭제됩니다. 문제 해결은 [인터페이스 VPC 엔드포인트와 엔드포인트 서비스 간의 연결 문제](https://repost.aws/knowledge-center/connect-endpoint-service-vpc)를 참조하세요.
**인텐트:** 이 경보는 엔드포인트 또는 엔드포인트 서비스가 비정상인지 여부를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 사용 사례에 따라 임곗값을 설정합니다. 엔드포인트 또는 엔드포인트 서비스의 비정상 상태를 파악하려면 엄청난 데이터 손실이 발생하기 전에 문제를 해결할 수 있도록 임곗값을 낮게 설정해야 합니다. 과거 데이터를 사용하여 삭제된 패킷의 허용 범위를 파악하고 그에 따라 임곗값을 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## AWS 프라이빗 링크(`AWS/PrivateLinkServices`)
**RstPacketsSent**
**측정 기준: **서비스 Id, 로드 밸런서 Arn, Az
**경보 설명:** 이 경보를 사용하면 엔드포인트로 전송되는 재설정 패킷 수를 기반으로 엔드포인트 서비스의 비정상 대상을 탐지할 수 있습니다. 서비스 소비자와의 연결 오류를 디버깅할 때 서비스가 RstPacketsSent 지표를 사용하여 연결을 재설정하는지 또는 네트워크 경로에서 다른 오류가 발생하는지 확인할 수 있습니다.
**인텐트:** 이 경보는 엔드포인트 서비스의 비정상 대상을 탐지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 임곗값은 사용 사례에 따라 다릅니다. 사용 사례에서 대상이 비정상인 것을 허용할 수 있는 경우 임곗값을 높게 설정할 수 있습니다. 사용 사례에서 대상이 비정상인 것을 허용할 수 없는 경우 임곗값을 매우 낮게 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## `Amazon RDS`
**CPUUtilization**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 지속적으로 높은 CPU 사용률을 모니터링하는 데 도움이 됩니다. CPU 사용률은 비유휴 시간을 측정합니다. [향상된 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html) 또는 [성능 개선 도우미](https://aws.amazon.com/rds/performance-insights/)를 사용하여 MariaDB, MySQL, Oracle 및 PostgreSQL에 대해 CPU 시간(`guest`, `irq`, `wait`, `nice` 등)을 가장 많이 소비하는 [대기 시간](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring-Available-OS-Metrics.html)을 검토하는 것이 좋습니다. 그런 다음, CPU를 가장 많이 소비하는 쿼리를 평가합니다. 워크로드를 조정할 수 없는 경우 더 큰 DB 인스턴스 클래스로 이동하는 것을 고려합니다.
**의도:** 이 경보는 매우 긴 응답 시간과 시간 초과를 방지하기 위해 지속적으로 높은 CPU 사용률을 탐지하는 데 사용됩니다. CPU 사용률의 마이크로 버스팅을 확인하려는 경우 경보 평가 시간을 더 짧게 설정할 수 있습니다.
**통계: **Average
**권장 임곗값**: 90.0
**임곗값 근거:** CPU 사용률이 무작위로 급증해도 데이터베이스 성능이 저하되지는 않지만 CPU가 계속 높게 유지되면 향후 데이터베이스 요청에 방해가 될 수 있습니다. 전체 데이터베이스 워크로드에 따라 RDS/Aurora 인스턴스의 CPU가 높으면 전체 성능이 저하될 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**DatabaseConnections**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 많은 수의 연결을 탐지합니다. 기존 연결을 검토하여 '비활동' 상태이거나 제대로 닫히지 않은 연결을 종료합니다. 연결 풀링을 사용하여 새 연결 수를 제한하는 것이 좋습니다. 또는 더 많은 메모리를 가진 클래스를 사용하도록 DB 인스턴스 크기를 늘려서 'max\$1connections'의 기본값을 높이거나, 워크로드를 지원할 수 있는 경우 [RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html)와 Aurora [MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html) 및 [PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html)에서 현재 클래스의 'max\$1connections' 값을 늘립니다.
**의도:** 이 경보는 최대 DB 연결 수에 도달했을 때 연결이 거부되는 것을 방지하는 데 사용됩니다. DB 인스턴스 클래스를 자주 변경하는 경우 메모리와 기본 최대 연결 수가 변경되므로 이 경보는 사용하지 않는 것이 좋습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 허용되는 연결 수는 DB 인스턴스 클래스의 크기 및 프로세스/연결과 관련된 데이터베이스 엔진별 파라미터에 따라 달라집니다. 데이터베이스의 최대 연결 수의 90\$195% 사이 값을 계산하고 해당 결과를 임곗값으로 사용해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**EBSByteBalance%**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 남아 있는 낮은 비율의 처리량 크레딧을 모니터링하는 데 도움이 됩니다. 문제 해결은 [RDS의 대기 시간 문제](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)를 참조하세요.
**의도: **이 경보는 버스트 버킷에 남아 있는 낮은 비율의 처리량 크레딧을 탐지하는 데 사용됩니다. 바이트 밸런스 비율이 낮으면 처리량 병목 문제가 발생할 수 있습니다. Aurora PostgreSQL 인스턴스에는 이 경보를 사용하지 않는 것이 좋습니다.
**통계: **Average
**권장 임곗값: **10.0
**임곗값 근거:** 처리량 크레딧 밸런스가 10% 미만이면 나쁨으로 간주되므로 임곗값을 적절히 설정해야 합니다. 애플리케이션이 워크로드에 대해 낮은 처리량을 허용할 수 있는 경우 더 낮은 임곗값을 설정할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**EBSIOBalance%**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 남아 있는 낮은 비율의 IOPS 크레딧을 모니터링하는 데 도움이 됩니다. 문제 해결은 [RDS의 대기 시간 문제](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)를 참조하세요.
**의도: **이 경보는 버스트 버킷에 남아 있는 낮은 비율의 I/O 크레딧을 탐지하는 데 사용됩니다. IOPS 밸런스 비율이 낮으면 IOPS 병목 문제가 발생할 수 있습니다. Aurora 인스턴스에는 이 경보를 사용하지 않는 것이 좋습니다.
**통계: **Average
**권장 임곗값: **10.0
**임곗값 근거:** IOPS 크레딧 밸런스가 10% 미만이면 나쁨으로 간주되므로 임곗값을 적절히 설정합니다. 애플리케이션이 워크로드에 대해 낮은 IOPS를 허용할 수 있는 경우 더 낮은 임곗값을 설정할 수도 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**FreeableMemory**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 데이터베이스 연결이 급증하거나 인스턴스가 높은 메모리 압박을 받고 있음을 의미할 수 있는 사용 가능한 메모리 부족을 모니터링하는 데 도움이 됩니다. `FreeableMemory` 외에도 `SwapUsage`에 대한 CloudWatch 지표를 모니터링하여 메모리 부족을 확인합니다. 인스턴스 메모리 소비가 자주 너무 높으면 워크로드를 확인하거나 인스턴스 클래스를 업그레이드해야 합니다. Aurora 리더 DB 인스턴스의 경우 클러스터에 리더 DB 인스턴스를 추가하는 것을 고려합니다. Aurora 문제 해결에 대한 자세한 내용은 [여유 메모리 부족 문제](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#Troubleshooting.FreeableMemory)를 참조하세요.
**의도:** 이 경보는 메모리 부족으로 인한 연결 거부를 방지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 워크로드 및 인스턴스 클래스에 따라 임곗값을 다르게 설정하는 것이 적절할 수 있습니다. 가용 메모리가 장기간 동안 전체 메모리의 25% 미만으로 떨어지지 않는 것이 좋습니다. Aurora의 경우 임곗값을 5%에 가깝게 설정할 수 있습니다. 지표가 0에 가까울수록 DB 인스턴스가 최대한 스케일 업되었음을 의미하기 때문입니다. 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**FreeLocalStorage**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 사용 가능한 로컬 스토리지 부족을 모니터링하는 데 도움이 됩니다. Aurora PostgreSQL 호환 버전은 오류 로그와 임시 파일을 저장하는 데 로컬 스토리지를 사용합니다. Aurora MySQL은 로컬 스토리지를 사용하여 오류 로그, 일반 로그, 느린 쿼리 로그, 감사 로그 및 비 InnoDB 임시 테이블을 저장합니다. 이러한 로컬 스토리지 볼륨은 Amazon EBS Store에서 백업하며, 더 큰 D 인스턴스 클래스를 사용하여 확장할 수 있습니다. 문제 해결을 위해서는 Aurora [PostgreSQL 호환](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue)과 [MySQL 호환](https://repost.aws/knowledge-center/aurora-mysql-local-storage)을 확인하세요.
**의도:** 이 경보는 Aurora Serverless v2 이상을 사용하지 않는 경우 Aurora DB 인스턴스가 로컬 스토리지 한도에 얼마나 근접했는지 탐지하는 데 사용됩니다. 임시 테이블 및 로그 파일과 같은 비영구 데이터를 로컬 스토리지에 저장하면 로컬 스토리지 용량이 초과될 수 있습니다. 이 경보를 통해 DB 인스턴스의 로컬 스토리지가 부족해질 때 발생하는 공간 부족 오류를 방지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 볼륨 사용 속도와 추세를 기반으로 사용 가능한 스토리지 양의 약 10\$120%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 볼륨이 한도에 도달하기 전에 사전에 조치를 취해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**FreeStorageSpace**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 사용 가능한 스토리지 공간이 부족한지 감시합니다. 스토리지 용량 한도에 자주 도달하는 경우 데이터베이스 스토리지 스케일 업을 고려합니다. 애플리케이션의 예기치 않은 수요 증가에 대비해 약간의 버퍼를 포함합니다. 또는 RDS 스토리지 Auto Scaling을 활성화하는 것도 고려합니다. 또한 사용하지 않거나 오래된 데이터 및 로그를 삭제하여 더 많은 공간을 확보하는 것도 고려합니다. 자세한 내용은 [RDS 스토리지 부족 문서](https://repost.aws/knowledge-center/rds-out-of-storage) 및 [PostgreSQL 스토리지 문제 문서](https://repost.aws/knowledge-center/diskfull-error-rds-postgresql)를 참조하세요.
**의도:** 이 경보는 스토리지 가득 참 문제를 방지하는 데 도움이 됩니다. 이렇게 하면 데이터베이스 인스턴스의 스토리지가 부족할 때 발생하는 가동 중지를 방지할 수 있습니다. 스토리지 Auto Scaling을 활성화했거나 데이터베이스 인스턴스의 스토리지 용량을 자주 변경하는 경우에는 이 경보를 사용하지 않는 것이 좋습니다.
**통계: **Minimum
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 임곗값은 현재 할당된 스토리지 공간에 따라 달라집니다. 일반적으로 할당된 스토리지 공간의 10% 값을 계산하고 해당 결과를 임곗값으로 사용해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**MaximumUsedTransactionID(MaximumUsedTransactionIDs)**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 PostgreSQL의 트랜잭션 ID 랩어라운드를 방지하는 데 도움이 됩니다. [이 블로그](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/)의 문제 해결 단계를 참조하여 문제를 조사하고 해결합니다. 또한 [이 블로그](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)를 참조하여 autovacuum 개념, 일반적인 문제 및 모범 사례에 대해 더 자세히 알아볼 수 있습니다.
**의도:** 이 경보는 PostgreSQL의 트랜잭션 ID 랩어라운드를 방지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값: **1.0E9
**임곗값 근거:** 이 임곗값을 10억으로 설정하면 문제를 조사할 시간을 확보할 수 있습니다. 기본 autovacuum\$1freeze\$1max\$1age 값은 2억입니다. 가장 오래된 트랜잭션의 기간이 10억이면 autovacuum은 이 임곗값을 2억 개의 트랜잭션 ID 목표 미만으로 유지하는 데 문제가 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **1
**평가 기간: **1
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReadLatency**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 긴 읽기 지연 시간을 모니터링하는 데 도움이 됩니다. 스토리지 지연 시간이 길면 워크로드가 리소스 제한을 초과하기 때문입니다. 인스턴스 및 할당된 스토리지 구성을 기준으로 I/O 사용률을 검토할 수 있습니다. [Amazon RDS 인스턴스의 IOPS 병목 현상으로 인해 발생하는 Amazon EBS 볼륨의 대기 시간 문제를 해결하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)를 참조하세요. Aurora의 경우 [I/O-Optimized 스토리지 구성](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html)이 있는 인스턴스 클래스로 전환할 수 있습니다. 지침은 [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/)를 참조하세요.
**의도:** 이 경보는 긴 읽기 지연 시간을 탐지하는 데 사용됩니다. 데이터베이스 디스크는 일반적으로 읽기/쓰기 지연 시간이 짧지만 작업 지연 시간이 길어질 수 있는 문제가 있을 수 있습니다.
**통계: **p90
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 읽기 지연 시간이 20밀리초보다 길면 조사가 필요할 수 있습니다. 애플리케이션의 읽기 작업 지연 시간이 길어질 수 있는 경우 더 높은 임곗값을 설정할 수도 있습니다. 읽기 지연 시간의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**ReplicaLag**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 알람은 복제본이 기본 인스턴스보다 뒤처진 시간(초)을 파악하는 데 도움이 됩니다. PostgreSQL 읽기 전용 복제본은 원본 데이터베이스 인스턴스에서 사용자 트랜잭션이 발생하지 않는 경우 최대 5분의 복제 지연을 보고합니다. ReplicaLag 지표가 0에 도달하면 복제본이 기본 DB 인스턴스를 따라잡은 것입니다. ReplicaLag 지표가 -1을 반환하는 경우 복제가 현재 활성 상태가 아닙니다. RDS PostgreSQL과 관련된 지침은 [복제 모범 사례](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/)를 참조하고 `ReplicaLag` 및 관련 오류 문제 해결은 [ReplicaLag 문제 해결](https://repost.aws/knowledge-center/rds-postgresql-replication-lag)을 참조하세요.
**의도:** 이 경보는 기본 인스턴스의 장애 시 발생할 수 있는 데이터 손실을 반영하는 복제 지연을 탐지할 수 있습니다. 복제본이 기본 인스턴스보다 너무 뒤쳐져 기본 인스턴스에 장애가 발생하면 복제본에서 기본 인스턴스에 있던 데이터가 누락됩니다.
**통계: **Maximum
**권장 임곗값: **60.0
**임곗값 근거:** 일반적으로 허용되는 지연은 애플리케이션에 따라 다릅니다. 60초를 넘지 않는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**WriteLatency**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 긴 쓰기 지연 시간을 모니터링하는 데 도움이 됩니다. 스토리지 지연 시간이 길면 워크로드가 리소스 제한을 초과하기 때문입니다. 인스턴스 및 할당된 스토리지 구성을 기준으로 I/O 사용률을 검토할 수 있습니다. [Amazon RDS 인스턴스의 IOPS 병목 현상으로 인해 발생하는 Amazon EBS 볼륨의 대기 시간 문제를 해결하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/rds-latency-ebs-iops-bottleneck)를 참조하세요. Aurora의 경우 [I/O-Optimized 스토리지 구성](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html)이 있는 인스턴스 클래스로 전환할 수 있습니다. 지침은 [Planning I/O in Aurora](https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/)를 참조하세요.
**의도:** 이 경보는 긴 쓰기 지연 시간을 탐지하는 데 사용됩니다. 데이터베이스 디스크는 일반적으로 읽기/쓰기 지연 시간이 짧지만 작업 지연 시간이 길어지는 문제가 발생할 수 있습니다. 이를 모니터링하면 디스크 지연 시간이 예상만큼 낮은지 확인할 수 있습니다.
**통계: **p90
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다. 쓰기 지연 시간이 20밀리초보다 길면 조사가 필요할 수 있습니다. 애플리케이션의 쓰기 작업 지연 시간이 길어질 수 있는 경우 더 높은 임곗값을 설정할 수도 있습니다. 쓰기 지연 시간의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**DBLoad**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 높은 DB 로드를 모니터링하는 데 도움이 됩니다. 프로세스 수가 vCPUs 수를 초과하면 프로세스가 대기열에 추가되기 시작합니다. 대기열이 늘어나면 성능에 영향이 있습니다. DB 로드가 최대 vCPU를 초과하는 경우가 많고 기본 대기 상태가 CPU인 경우 CPU에 과부하가 걸립니다. 이 경우 성능 개선 도우미/향상된 모니터링에서 `CPUUtilization`, `DBLoadCPU` 및 대기 중인 작업을 모니터링할 수 있습니다. 연결 수를 인스턴스에 맞게 조절하거나, CPU 로드가 높은 SQL 쿼리를 미세 조정하거나, 인스턴스 클래스의 크기를 늘리는 것이 좋습니다. 대기 상태의 인스턴스가 높고 일관적이라는 것은 해결해야 할 병목 현상이나 리소스 경합 문제가 있을 수 있음을 나타냅니다.
**의도:** 이 경보는 높은 DB 로드를 탐지하는 데 사용됩니다. DB 로드가 높으면 DB 인스턴스에서 성능 문제가 발생할 수 있습니다. 이 경보는 서버리스 DB 인스턴스에는 해당되지 않습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거: **최대 vCPU 값은 DB 인스턴스의 vCPU(가상 CPU) 코어 수에 따라 결정됩니다. 최대 vCPU에 따라 다른 임곗값이 적절할 수 있습니다. 이상적으로 DB 로드가 vCPU 라인을 넘지 않아야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**AuroraVolumeBytesLeftTotal**
**측정기준: **DBClusterIdentifier
**경보 설명:** 이 경보는 낮은 잔여 총 볼륨을 모니터링하는 데 도움이 됩니다. 남은 총 볼륨이 크기 제한에 도달하면 클러스터는 공간 부족 오류를 보고합니다. Aurora 스토리지는 클러스터 볼륨의 데이터에 따라 자동으로 규모가 조정되며 [DB 엔진 버전](https://repost.aws/knowledge-center/aurora-version-number)에 따라 최대 128TiB 또는 64TiB까지 확장됩니다. 더 이상 필요하지 않은 테이블과 데이터베이스를 삭제하여 스토리지를 줄이는 것을 고려합니다. 자세한 내용은 [스토리지 조정](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)을 확인하세요.
**의도:** 이 경보는 Aurora 클러스터가 볼륨 크기 제한에 얼마나 근접했는지 탐지하는 데 사용됩니다. 이 경보는 클러스터의 공간이 부족할 때 발생하는 공간 부족 오류를 방지할 수 있습니다. 이 경보는 Aurora MySQL에만 권장됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** 볼륨 사용량 증가 속도 및 추세를 기준으로 실제 크기 제한의 10\$120%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 볼륨이 제한에 도달하기 전에 사전 조치를 취해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**AuroraBinlogReplicaLag**
**측정기준: **DBClusterIdentifier, 역할=WRITER
**경보 설명:** 이 경보는 Aurora writer 인스턴스 복제의 오류 상태를 모니터링하는 데 도움이 됩니다. 자세한 내용은 [AWS 리전 간 Aurora MySQL DB 클러스터 복제](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.html)를 참조하세요. 문제 해결은 [Aurora MySQL 복제 문제](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL)를 참조하세요.
**의도:** 이 경보는 작성자 인스턴스가 오류 상태이고 소스를 복제할 수 없는지 여부를 탐지하는 데 사용됩니다. 이 경보는 Aurora MySQL에만 권장됩니다.
**통계: **Average
**권장 임곗값: **-1.0
**임곗값 근거:** 복제본이 오류 상태인 경우 Aurora MySQL에서 이 값을 게시하므로 임곗값으로 -1을 사용하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**BlockedTransactions**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 Aurora DB 인스턴스에서 차단된 높은 트랜잭션 수를 모니터링하는 데 도움이 됩니다. 차단된 트랜잭션은 롤백 또는 커밋으로 종료될 수 있습니다. 높은 동시성, 트랜잭션 유휴 또는 장기 실행 트랜잭션으로 인해 트랜잭션이 차단될 수 있습니다. 문제 해결은 [Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-waits.row-lock-wait.html) 설명서를 참조하세요.
**의도:** 이 경보는 트랜잭션 롤백 및 성능 저하를 방지하기 위해 Aurora DB 인스턴스에서 많은 수의 차단된 트랜잭션을 탐지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** `ActiveTransactions` 지표를 사용하여 인스턴스의 전체 트랜잭션 중 5%를 계산하고 해당 결과를 임곗값으로 사용해야 합니다. 또한 차단된 트랜잭션의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**BufferCacheHitRatio**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 Aurora 클러스터의 지속적으로 낮은 캐시 적중률을 모니터링하는 데 도움이 됩니다. 적중률이 낮다면 이 DB 인스턴스에 대한 쿼리가 디스크로 자주 이동한다는 뜻입니다. 문제를 해결하려면 워크로드를 조사하여 어떤 쿼리가 이 동작을 일으키는지 확인하고 [DB 인스턴스 RAM 권장 사항](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.BestPractices.html#Aurora.BestPractices.Performance.Sizing) 문서를 참조하세요.
**의도:** 이 경보는 Aurora 인스턴스의 지속적인 성능 저하를 방지하기 위해 일관되게 낮은 캐시 적중률을 탐지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값**: 80.0
**임곗값 근거:** 버퍼 캐시 적중률의 임곗값을 80%로 설정할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **10
**평가 기간: **10
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**EngineUptime**
**측정기준: **DBClusterIdentifier, 역할=WRITER
**경보 설명:** 이 경보는 라이터 DB 인스턴스의 가동 중지 시간이 짧은지 모니터링하는 데 도움이 됩니다. 라이터 DB 인스턴스는 재부팅, 유지 관리, 업그레이드 또는 장애 조치로 인해 다운될 수 있습니다. 클러스터의 장애 조치로 인해 가동 시간이 0에 도달하고 클러스터에 하나 이상의 Aurora 복제본이 있으면 실패 이벤트 중에 Aurora 복제본이 기본 라이터 인스턴스로 승격됩니다. DB 클러스터의 가용성을 높이려면 두 개 이상의 서로 다른 가용 영역에 하나 이상의 Aurora 복제본을 생성하는 것을 고려합니다. 자세한 내용은 [Aurora 가동 중지에 영향을 미치는 요인](https://repost.aws/knowledge-center/aurora-mysql-downtime-factors)을 참조하세요.
**의도:** 이 경보는 Aurora 라이터 DB 인스턴스의 가동 중지 여부를 탐지하는 데 사용됩니다. 이를 통해 중단 또는 장애 조치로 인해 발생하는 라이터 인스턴스의 장기 실행 장애를 방지할 수 있습니다.
**통계: **Average
**권장 임곗값**: 0.0
**임곗값 근거: **실패 이벤트로 인해 잠시 중단이 발생하며 그 동안 읽기 및 쓰기 작업은 예외와 함께 실패합니다. 하지만, 일반적인 서비스 복구 시간은 60초 미만이지만 대부분 30초 미만에 복원됩니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **2
**평가 기간: **2
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**RollbackSegmentHistoryListLength**
**측정기준: **DBInstanceIdentifier
**경보 설명:** 이 경보는 Aurora 인스턴스의 일관되게 높은 롤백 세그먼트 기록 길이를 모니터링하는 데 도움이 됩니다. InnoDB 기록 목록 길이가 길면 오래된 행 버전, 쿼리 및 데이터베이스 종료가 많아 속도가 느려진 것입니다. 자세한 내용 및 문제 해결은 [InnoDB 기록 목록 길이가 크게 늘어남](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/proactive-insights.history-list.html)을 참조하세요.
**의도:** 이 경보는 일관되게 긴 롤백 세그먼트 기록 길이를 탐지하는 데 사용됩니다. 이를 통해 Aurora 인스턴스에서 지속적인 성능 저하와 높은 CPU 사용률을 방지할 수 있습니다. 이 경보는 Aurora MySQL에만 권장됩니다.
**통계: **Average
**권장 임곗값: **1000000.0
**임곗값 근거:** 이 임곗값을 100만으로 설정하면 문제를 조사할 시간을 확보할 수 있습니다. 하지만 허용 가능한 성능 수준과 워크로드 특성에 따라 이 값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**StorageNetworkThroughput**
**측정기준: **DBClusterIdentifier, 역할=WRITER
**경보 설명:** 이 경보는 높은 스토리지 네트워크 처리량을 모니터링하는 데 도움이 됩니다. 스토리지 네트워크 처리량이 [EC2 인스턴스의](https://aws.amazon.com/ec2/instance-types/) 총 네트워크 대역폭을 초과할 경우 읽기 및 쓰기 지연 시간이 길어져 성능이 저하될 수 있습니다. AWS 콘솔에서 EC2 인스턴스 유형을 확인할 수 있습니다. 문제 해결을 위해 쓰기/읽기 지연 시간에 대한 변경 사항을 확인하고 이 지표에서도 경보가 발생했는지 평가합니다. 경보가 발생한 경우 경보가 트리거된 시간 동안의 워크로드 패턴을 평가합니다. 이를 통해 워크로드를 최적화하여 총 네트워크 트래픽 양을 줄일 수 있는지 확인할 수 있습니다. 이것이 불가능한 경우 인스턴스 크기 조정을 고려해야 할 수도 있습니다.
**의도:** 이 경보는 높은 스토리지 네트워크 처리량을 탐지하는 데 사용됩니다. 높은 처리량을 탐지하면 네트워크 패킷 손실과 성능 저하를 방지할 수 있습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 근거:** EC2 인스턴스 유형의 총 네트워크 대역폭의 약 80\$190%를 계산한 다음, 해당 결과를 임곗값으로 사용하여 네트워크 패킷이 영향을 받기 전에 사전 조치를 취해야 합니다. 또한 스토리지 네트워크 처리량의 중요도와 요구 사항을 검토하고 이 지표의 과거 동작을 분석하여 적절한 임곗값 수준을 결정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## `Amazon Route 53 Public Data Plane`
**HealthCheckStatus**
**측정 기준: **HealthCheckId
**경보 설명:** 이 경보는 상태 검사기에 따라 비정상 엔드포인트를 탐지하는 데 도움이 됩니다. 장애가 발생하여 비정상 상태가 된 이유를 이해하려면 Route 53 Health Check Console의 상태 검사기 탭을 사용하여 각 리전의 상태와 상태 확인의 마지막 실패를 확인합니다. 상태 탭에는 엔드포인트가 비정상으로 보고된 이유도 표시됩니다. [문제 해결 단계](https://repost.aws/knowledge-center/route-53-fix-unhealthy-health-checks)를 참조하세요.
**인텐트:** 이 경보는 Route53 상태 검사기를 사용하여 비정상 엔드포인트를 탐지합니다.
**통계: **Average
**권장 임곗값**: 1.0
**임곗값 정당화:** 엔드포인트가 정상이면 상태가 1로 보고됩니다. 1 미만이면 모두 비정상입니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
## `Amazon S3`
**4xxErrors**
**측정 기준: **BucketName, FilterId
**경보 설명:** 이 경보를 통해 클라이언트 요청에 대한 응답으로 생성된 4xx 오류 상태 코드의 총 개수를 보고할 수 있습니다. 예를 들어 403 오류 코드는 잘못된 IAM 정책을 나타내고, 404 오류 코드는 클라이언트 애플리케이션이 제대로 작동하지 않음을 나타낼 수 있습니다. [S3 서버 액세스 로깅을 일시적으로 활성화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)하면 HTTP 상태 및 오류 코드 필드를 사용하여 문제의 원인을 정확히 찾아낼 수 있습니다. 오류 코드에 대한 자세한 내용은 [오류 응답](https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html)을 참조하세요.
**인텐트:** 이 경보는 일반적인 4xx 오류 발생률에 대한 기준을 만드는 데 사용되므로 설정 문제를 나타낼 수 있는 비정상이 있는지 확인할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 권장 임곗값은 전체 요청의 5% 이상에서 4XX 오류가 발생하는지 감지하는 것입니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**측정 기준: **BucketName, FilterId
**경보 설명:** 이 경보는 많은 수의 서버 측 오류 감지에 도움이 됩니다. 이러한 오류는 클라이언트가 요청을 했지만 서버가 완료하지 못했음을 나타냅니다. 이를 통해 애플리케이션이 S3로 인해 직면한 문제의 상관 관계를 파악할 수 있습니다. 오류를 효율적으로 처리하거나 줄이는 데 도움이 되는 자세한 내용은 [성능 설계 패턴 최적화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries)를 참조하세요. 오류는 S3 문제로 인해 발생할 수도 있으므로 [AWS 서비스 상태 대시보드](https://health.aws.amazon.com/health/status)에서 해당 리전의 Amazon S3 상태를 확인합니다.
**인텐트:** 이 경보는 5xx 오류로 인해 애플리케이션에 문제가 발생하는지 감지하는 데 도움이 될 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 전체 요청의 5% 이상에서 5XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**OperationsFailedReplication**
**측정 기준: **SourceBucket, DestinationBucket, RuleId
**경보 설명:** 이 경보는 복제 실패를 이해하는 데 도움이 됩니다. 이 지표는 S3 CRR 또는 S3 SRR을 사용하여 복제된 새 객체의 상태를 추적하고 S3 배치 복제를 사용하여 복제된 기존 객체도 추적합니다. 자세한 내용은 [복제 문제 해결](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-troubleshoot.html)을 참조하세요.
**인텐트:** 이 경보는 실패한 복제 작업이 있는지 감지하는 데 사용됩니다.
**통계: **Maximum
**권장 임곗값**: 0.0
**임곗값 정당화:** 이 지표는 작업이 성공하면 값을 0으로 내보내고, 1분 동안 수행된 복제 작업이 없는 경우에는 아무 것도 출력하지 않습니다. 지표가 0보다 큰 값을 내보내는 경우 복제 작업은 실패입니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## `S3ObjectLambda`
**4xxErrors**
**측정 기준: **AccessPointName, DataSourceARN
**경보 설명:** 이 경보는 클라이언트 요청에 대한 응답으로 생성된 4xx 오류 상태 코드의 총 개수를 보고하는 데 도움이 됩니다. [S3 서버 액세스 로깅을 일시적으로 활성화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html)하면 HTTP 상태 및 오류 코드 필드를 사용하여 문제의 원인을 정확히 찾아낼 수 있습니다.
**인텐트:** 이 경보는 일반적인 4xx 오류 발생률에 대한 기준을 만드는 데 사용되므로 설정 문제를 나타낼 수 있는 비정상이 있는지 확인할 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 전체 요청의 5% 이상에서 4XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**5xxErrors**
**측정 기준: **AccessPointName, DataSourceARN
**경보 설명:** 이 경보는 많은 수의 서버 측 오류 감지에 도움이 됩니다. 이러한 오류는 클라이언트가 요청을 했지만 서버가 완료하지 못했음을 나타냅니다. 이러한 오류는 S3 문제로 인해 발생할 수도 있으므로 [AWS 서비스 상태 대시보드](https://health.aws.amazon.com/health/status)에서 해당 리전의 Amazon S3 상태를 확인합니다. 이를 통해 애플리케이션이 S3로 인해 직면한 문제의 상관 관계를 파악할 수 있습니다. 이러한 오류를 효율적으로 처리하거나 줄이는 데 도움이 되는 자세한 내용은 [성능 설계 패턴 최적화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html#optimizing-performance-timeouts-retries)를 참조하세요.
**인텐트:** 이 경보는 5xx 오류로 인해 애플리케이션에 문제가 발생하는지 감지하는 데 도움이 될 수 있습니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 전체 요청의 5% 이상에서 5XX 오류가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 하지만 요청의 트래픽과 허용 가능한 오류 발생률에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**LambdaResponse4xx**
**측정 기준: **AccessPointName, DataSourceARN
**경보 설명:** 이 경보는 S3 Object Lambda에 대한 호출에서 장애(500s)를 감지하고 진단하는 데 도움이 됩니다. 이러한 오류는 요청에 대한 응답을 담당하는 Lambda 함수의 오류 또는 잘못된 구성으로 인해 발생할 수 있습니다. 객체 Lambda 액세스 포인트와 관련된 Lambda 함수의 CloudWatch 로그 스트림을 조사하면 S3 객체 Lambda의 응답을 기반으로 문제의 원인을 정확히 찾아낼 수 있습니다.
**인텐트:** 이 경보는 WriteGetObjectResponse 호출에서 발생하는 4xx 클라이언트 오류를 탐지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 0.05
**임곗값 정당화:** 전체 요청의 5% 이상에서 4XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다. 자주 발생하는 4XX 오류는 경보가 필요합니다. 하지만 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다. 또한 과거 데이터를 분석하여 애플리케이션 워크로드에 대해 허용 가능한 오류 발생률을 확인한 다음 그에 따라 임곗값을 조정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon SNS
**NumberOfMessagesPublished**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 게시된 SNS 메시지 수가 너무 적을 때 이를 감지할 수 있습니다. 문제 해결을 위해 게시자가 보내는 트래픽이 적은 이유를 확인합니다.
**인텐트:** 이 경보를 사용하면 알림 게시의 현저한 저하를 사전에 모니터링하고 감지할 수 있습니다. 이를 통해 애플리케이션 또는 비즈니스 프로세스의 잠재적 문제를 식별하여 적절한 조치를 취해 예상되는 알림 흐름을 유지할 수 있습니다. 시스템에서 처리하는 트래픽이 최소화될 것으로 예상되면 이 경보를 생성해야 합니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 게시되는 메시지 수는 애플리케이션에 게시될 것으로 예상되는 메시지 수와 일치해야 합니다. 또한 과거 데이터, 추세 및 트래픽을 분석하여 적절한 임곗값을 찾을 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsDelivered**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 전달된 SNS 메시지 수가 너무 적을 때 이를 감지할 수 있습니다. 이는 의도하지 않은 엔드포인트 구독 취소나 메시지 지연을 유발하는 SNS 이벤트 때문일 수 있습니다.
**인텐트:** 이 경보는 전송된 메시지 양의 감소를 감지하는 데 도움이 됩니다. 시스템에서 처리하는 트래픽이 최소화될 것으로 예상되면 이 경보를 생성해야 합니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 전달되는 메시지 수는 생성된 예상 메시지 수 및 소비자 수와 일치해야 합니다. 또한 과거 데이터, 추세 및 트래픽을 분석하여 적절한 임곗값을 찾을 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailed**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 실패한 SNS 메시지 수가 너무 많을 때 이를 감지할 수 있습니다. 실패한 알림 문제를 해결하려면 CloudWatch Logs에 로깅을 활성화합니다. 로그를 확인하면 실패한 구독자와 해당 구독자가 반환하는 상태 코드를 찾는 데 도움이 될 수 있습니다.
**인텐트:** 이 경보를 통해 알림 전달과 관련된 문제를 사전에 발견하고 적절한 조치를 취해 문제를 해결할 수 있습니다.
**통계: **Sum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 실패한 알림의 영향에 따라 크게 달라집니다. 최종 사용자에게 제공되는 SLA, 내결함성, 알림의 중요도를 검토하고 과거 데이터를 분석한 다음 그에 따라 임곗값을 선택합니다. SQS, Lambda 또는 Firehose 구독만 있는 주제의 경우 실패한 알림 수는 0이어야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidAttributes**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 게시자 또는 구독자의 잠재적 문제를 모니터링하고 해결하는 데 도움이 됩니다. 게시자가 잘못된 속성을 가진 메시지를 게시하고 있는지 또는 구독자에게 부적절한 필터가 적용되었는지 확인합니다. 또한 CloudWatch Logs를 분석하여 문제의 근본 원인을 찾을 수 있습니다.
**인텐트:** 경보는 게시된 메시지가 유효하지 않은지 또는 구독자에게 부적절한 필터가 적용되었는지 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 잘못된 속성은 게시자의 실수인 경우가 많습니다. 정상 시스템에서는 잘못된 속성이 예상되지 않으므로 임곗값을 0으로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFilteredOut-InvalidMessageBody**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 게시자 또는 구독자의 잠재적 문제를 모니터링하고 해결하는 데 도움이 됩니다. 게시자가 메시지 본문이 잘못된 메시지를 게시하고 있는지 또는 구독자에게 부적절한 필터가 적용되었는지 확인합니다. 또한 CloudWatch Logs를 분석하여 문제의 근본 원인을 찾을 수 있습니다.
**인텐트:** 경보는 게시된 메시지가 유효하지 않은지 또는 구독자에게 부적절한 필터가 적용되었는지 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 잘못된 메시지 본문은 게시자의 실수인 경우가 많습니다. 정상 시스템에서는 잘못된 메시지 본문이 예상되지 않으므로 임곗값을 0으로 설정하는 것이 좋습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsRedrivenToDlq**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 DLQ(Dead Letter Queue)로 이동되는 메시지 수를 모니터링하는 데 도움이 됩니다.
**인텐트:** 경보는 DLQ(Dead Letter Queue)로 이동된 메시지를 감지하는 데 사용됩니다. SNS가 SQS, Lambda 또는 Firehose와 결합된 경우 이 경보를 생성하는 것이 좋습니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 구독자 유형과 상관없이 정상 시스템에서는 메시지를 DLQ(Dead Letter Queue)로 이동해서는 안 됩니다. 메시지가 대기열에 도착하면 알림을 받는 것이 좋습니다. 근본 원인을 식별하여 해결할 수 있고 DLQ(Dead Letter Queue)에 있는 메시지를 다시 입력하여 데이터 손실을 방지할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**NumberOfNotificationsFailedToRedriveToDlq**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 DLQ(Dead Letter Queue)로 이동할 수 없는 메시지를 모니터링하는 데 도움이 됩니다. DLQ(Dead Letter Queue)가 존재하고 올바르게 구성되어 있는지 확인합니다. 또한 SNS에 DLQ(Dead Letter Queue) 액세스 권한이 있는지도 확인합니다. 자세한 내용은 [DLQ(Dead Letter Queue) 설명서](https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html)를 참조하세요.
**인텐트:** 경보는 DLQ(Dead Letter Queue)로 이동하지 못한 메시지를 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 메시지를 DLQ(Dead Letter Queue)로 이동할 수 없는 경우는 거의 항상 실수입니다. 권장 임곗값은 0입니다. 즉, 대기열이 구성되면 처리에 실패한 모든 메시지가 DLQ(Dead Letter Queue)에 도달할 수 있어야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SMSMonthToDateSpentUSD**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 SNS에서 메시지를 전송할 수 있는 계정 할당량이 충분한지 모니터링하는 데 도움이 됩니다. 할당량에 도달하면 SNS에서 SMS 메시지를 전송할 수 없습니다. 사용자의 월별 SMS 지출 할당량 설정 또는 AWS에서 지출 할당량 증가 요청에 대한 자세한 내용은 [SMS 메시징 기본 설정](https://docs.aws.amazon.com/sns/latest/dg/sms_preferences.html)을 참조하세요.
**인텐트:** 이 경보는 계정에 SMS 메시지가 성공적으로 전송되기에 충분한 할당량이 있는지 확인하는 데 사용됩니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 계정의 할당량(계정 지출 한도)에 따라 임곗값을 설정합니다. 할당량 증가를 요청할 시간을 확보할 수 있도록 할당량 한도에 도달했음을 충분히 일찍 알려주는 임곗값을 선택합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
**SMSSuccessRate**
**측정 기준: **TopicName
**경보 설명:** 이 경보는 SMS 메시지 전송 실패율을 모니터링하는 데 도움이 됩니다. [Cloudwatch Logs](https://docs.aws.amazon.com/sns/latest/dg/sms_stats_cloudwatch.html)를 설정하여 장애의 특성을 파악하고 이에 따라 조치를 취할 수 있습니다.
**인텐트:** 이 경보는 SMS 메시지 전송 실패를 탐지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** SMS 메시지 전송 실패에 대한 허용 한도에 맞춰 경보 임곗값을 설정합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **5
**평가 기간: **5
**비교 연산자: **GREATER\$1THAN\$1THRESHOLD
## Amazon SQS
**ApproximateAgeOfOldestMessage**
**측정 기준: **QueueName
**경보 설명:** 이 경보는 대기열에 있는 가장 오래된 메시지의 수명을 감시합니다. 이 경보를 사용하여 소비자가 원하는 속도로 SQS 메시지를 처리하고 있는지 모니터링할 수 있습니다. 소비자 수 또는 소비자 처리량을 늘려 메시지 사용 기간을 줄이는 방안을 고려해 보세요. 이 지표를 `ApproximateNumberOfMessagesVisible`와 함께 사용하여 대기열 백로그의 크기 및 메시지 처리 속도를 결정할 수 있습니다. 메시지가 처리되기 전에 삭제되는 것을 방지하려면 잠재적 독약 메시지를 차단하도록 DLQ(Dead Letter Queue)를 구성하는 것이 좋습니다.
**인텐트:** 이 경보는 QueueName 대기열에 있는 가장 오래된 메시지의 보존 기간이 너무 긴지 여부를 감지하는 데 사용됩니다. 긴 기간은 메시지가 충분히 빨리 처리되지 않았거나 대기열에 남아 처리할 수 없는 독약 메시지가 있다는 의미일 수 있습니다.
**통계: **Maximum
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 예상 메시지 처리 시간에 따라 크게 달라집니다. 과거 데이터를 사용하여 평균 메시지 처리 시간을 계산한 다음, 임곗값을 대기열의 소비자가 예상한 최대 SQS 메시지 처리 시간보다 50% 더 높게 설정할 수 있습니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesNotVisible**
**측정 기준: **QueueName
**경보 설명:** 이 경보는 `QueueName`와 관련하여 많은 수의 처리 중 메시지를 감지하는 데 도움이 됩니다. 문제 해결을 위해 [메시지 백로그 감소](https://repost.aws/knowledge-center/sqs-message-backlog)를 확인하세요.
**인텐트:** 이 경보는 대기열에 있는 많은 수의 처리 중인 메시지를 탐지하는 데 사용됩니다. 소비자가 가시성 제한 시간 내에 메시지를 삭제하지 않으면 대기열이 폴링될 때 메시지가 대기열에 다시 나타납니다. FIFO 대기열의 경우 처리 중 메시지가 최대 20,000개까지 있을 수 있습니다. 이 할당량에 도달해도 SQS는 오류 메시지를 반환하지 않습니다. FIFO 대기열은 처음 2만 개의 메시지를 검토하여 사용 가능한 메시지 그룹을 결정합니다. 즉, 단일 메시지 그룹에 메시지 백로그가 있는 경우 백로그에서 메시지를 성공적으로 사용할 때까지 나중에 대기열로 전송된 다른 메시지 그룹의 메시지를 사용할 수 없습니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 이 경보의 권장 임곗값은 처리 중인 예상 메시지 수에 따라 크게 달라집니다. 과거 데이터를 사용하여 처리 중인 최대 예상 메시지 수를 계산하고 임곗값을 이 값의 50% 이상으로 설정할 수 있습니다. 대기열의 소비자가 대기열에서 메시지를 처리하지만 삭제하지는 않는 경우 이 수가 갑자기 증가합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**ApproximateNumberOfMessagesVisible**
**측정 기준: **QueueName
**경보 설명:** 이 경보는 메시지 대기열 백로그가 예상보다 커지는지 감시하며 소비자가 너무 느리거나 소비자가 충분하지 않음을 나타냅니다. 이 경보가 ALARM 상태가 되면 소비자 수를 늘리거나 소비자 속도를 높이는 것을 고려해 보세요.
**인텐트:** 이 경보는 활성 대기열의 메시지 수가 너무 많아 소비자가 메시지를 처리하는 속도가 느리거나 메시지를 처리할 소비자가 충분하지 않은지 여부를 감지하는 데 사용됩니다.
**통계: **Average
**권장 임곗값:** 상황에 따라 다름
**임곗값 정당화:** 표시되는 메시지 수가 예상보다 많으면 소비자가 메시지를 예상 속도로 처리하지 못하고 있음을 나타냅니다. 이 임곗값을 설정할 때 과거 데이터를 고려해야 합니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **GREATER\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
**NumberOfMessagesSent**
**측정 기준: **QueueName
**경보 설명:** 이 경보는 `QueueName`와 관련하여 생산자로부터 전송되는 메시지가 없는지 감지하는 데 도움이 됩니다. 문제 해결을 위해 생산자가 메시지를 보내지 않는 이유를 확인합니다.
**인텐트:** 이 경보는 생산자가 메시지 전송을 중단하는 시점을 감지하는 데 사용됩니다.
**통계: **Sum
**권장 임곗값**: 0.0
**임곗값 정당화:** 전송된 메시지 수가 0인 경우 생산자는 메시지를 보내지 않습니다. 이 대기열의 TPS가 낮으면 그에 따라 EvaluationPeriods 수를 늘립니다.
**기간:** 60
**경보를 보낼 데이터 포인트: **15
**평가 기간: **15
**비교 연산자: **LESS\$1THAN\$1OR\$1EQUAL\$1TO\$1THRESHOLD
## Site-to-Site VPN
**TunnelState**
**측정 기준: **VpnId
**경보 설명:** 이 경보는 하나 이상의 터널 상태가 DOWN인지 파악하는 데 도움이 됩니다. 문제 해결을 위해 [VPN 터널 문제 해결](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting)을 참조하세요.
**인텐트:** 이 경보는 하나 이상의 터널이 이 VPN의 DOWN 상태에 있는지 감지하여 영향을 받는 VPN 문제를 해결하는 데 사용됩니다. 터널이 하나만 구성된 네트워크의 경우 이 경보는 항상 ALARM 상태에 있습니다.
**통계: **Minimum
**권장 임곗값**: 1.0
**임곗값 정당화:** 값이 1보다 작으면 하나 이상의 터널이 DOWN 상태임을 나타냅니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
**TunnelState**
**측정 기준: **TunnelIpAddress
**경보 설명:** 이 경보는 터널의 상태가 DOWN인지 파악하는 데 도움이 됩니다. 문제 해결을 위해 [VPN 터널 문제 해결](https://repost.aws/knowledge-center/vpn-tunnel-troubleshooting)을 참조하세요.
**인텐트:** 이 경보는 터널이 DOWN 상태에 있는지 감지하여 영향을 받는 VPN 문제를 해결하는 데 사용됩니다. 터널이 하나만 구성된 네트워크의 경우 이 경보는 항상 ALARM 상태에 있습니다.
**통계: **Minimum
**권장 임곗값**: 1.0
**임곗값 정당화:** 값이 1보다 작으면 터널이 DOWN 상태임을 나타냅니다.
**기간:** 300
**경보를 보낼 데이터 포인트: **3
**평가 기간: **3
**비교 연산자: **LESS\$1THAN\$1THRESHOLD
# 경보 사용 사례 및 예
다음 섹션에서는 일반적인 경보 사용 사례에 대한 예제 및 자습서를 제공합니다.
**Topics**
+ [청구 경보를 생성하여 예상 AWS 요금을 모니터링하세요.](monitor_estimated_charges_with_cloudwatch.md)
+ [CPU 사용률 경보 생성](US_AlarmAtThresholdEC2.md)
+ [이메일을 전송하는 로드 밸런서 지연 경보 생성](US_AlarmAtThresholdELB.md)
+ [이메일을 전송하는 스토리지 처리량 경보 생성](US_AlarmAtThresholdEBS.md)
+ [AWS 데이터베이스의 성능 개선 도우미 카운터 지표에 대한 경보 생성](CloudWatch_alarm_database_performance_insights.md)
# 청구 경보를 생성하여 예상 AWS 요금을 모니터링하세요.
Amazon CloudWatch를 사용하여 예상 AWS 요금을 모니터링할 수 있습니다. AWS 계정에 대한 예상 요금 모니터링을 사용 설정하면 예상 요금이 계산되어 지표 데이터로서 매일 여러 번 CloudWatch에 전송됩니다.
결제 지표 데이터는 미국 동부(버지니아 북부) 리전에 저장되며 전 세계 요금을 나타냅니다. 이 데이터에는 사용한 AWS의 모든 서비스에 대한 예상 요금과 전반적인 총 AWS 예상 요금이 들어 있습니다.
계정 결제가 지정한 임곗값을 초과하면 경보가 작동합니다. 현재 결제가 임곗값을 초과하는 경우에만 경보가 작동합니다. 해당 시점까지의 월 사용량을 기준으로 추정하지 않습니다.
요금이 임곗값을 초과한 시점에 결제 경보를 생성할 경우 경보가 즉시 `ALARM` 상태가 됩니다.
**참고**
이미 청구된 CloudWatch 요금을 분석하는 방법은 [CloudWatch 비용 분석, 최적화 및 절감](cloudwatch_billing.md) 섹션을 참조하세요.
**Topics**
+ [결제 알림 사용 설정](#turning_on_billing_metrics)
+ [결제 경보 생성](#creating_billing_alarm_with_wizard)
+ [결제 경보 삭제](#deleting_billing_alarm)
## 결제 알림 사용 설정
예상 요금에 대한 경보를 생성할 수 있으려면 먼저 결제 알림을 활성화해야 합니다. 그래야만 예상되는 AWS 요금을 모니터링하고 결제 지표 데이터를 사용하여 경보를 생성할 수 있습니다. 결제 알림을 활성화하고 나면 데이터 수집을 비활성화할 수 없습니다. 그러나 생성된 모든 결제 경보를 삭제할 수는 있습니다.
결제 알림을 처음 활성화하고 나서 결제 데이터를 확인하고 결제 경보를 설정할 수 있기까지 약 15분 정도의 시간이 걸립니다.
**요구 사항**
+ 계정 루트 사용자 자격 증명을 사용하여 로그인하거나 결제 정보를 볼 수 있는 권한을 부여받은 IAM 사용자로 로그인해야 합니다.
+ 통합 결제 계정의 경우 결제 계정으로 로그인하면 연결된 각 계정에 대한 결제 데이터를 찾을 수 있습니다. 통합 계정에 대해서뿐만 아니라 연결된 각 계정에 대한 서비스별 총 예상 요금 및 예상 요금에 대한 결제 데이터를 볼 수 있습니다.
+ 통합 결제 계정에서 멤버에 연결된 계정 지표는 지급인 계정이 **결제 알림 받기** 기본 설정을 사용하도록 설정한 경우에만 캡처됩니다. 관리/지급인 계정인 계정을 변경하는 경우 새 관리/지급인 계정에서 결제 알림을 사용해야 합니다.
+ APN 계정에 대한 결제 지표는 CloudWatch에 게시되지 않으므로 계정이 Amazon 파트너 네트워크(APN)에 속하지 않아야 합니다. 자세한 내용은 [AWS 파트너 네트워크](https://aws.amazon.com/partners/)를 참조하세요.
**예상 요금 모니터링을 활성화하려면**
1. [https://console.aws.amazon.com/costmanagement/](https://console.aws.amazon.com/costmanagement/)에서 AWS 결제 및 비용 관리 콘솔을 엽니다.
1. 탐색 창에서 **결제 기본 설정(Billing preferences)**을 선택합니다.
1. **알림 환경 설정**에서 **편집**을 선택합니다.
1. **CloudWatch 결제 알림 수신**을 선택합니다.
1. **기본 설정 저장**을 선택합니다.
## 결제 경보 생성
**중요**
결제 경보를 생성하기 전에 Region(리전)을 US East (N. Virginia)(미국 동부(버지니아 북부))로 설정해야 합니다. 결제 지표 데이터는 이 리전에 저장되어 전 세계 요금을 나타냅니다. 또한 계정 또는 관리/지급인 계정(통합 결제를 사용하는 경우)에 대한 결제 알림을 활성화해야 합니다. 자세한 내용은 [결제 알림 사용 설정](#turning_on_billing_metrics) 섹션을 참조하세요.
이 절차에서는 AWS에 대한 예상 요금이 정의된 임곗값을 초과할 때 알림을 보내는 경보를 생성합니다.
**CloudWatch 콘솔을 사용하여 결제 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택한 다음 **모든 경보(All alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. **지표 선택**을 선택합니다. **AWS 네임스페이스**에서 **결제**를 선택하고 **예상 요금 합계**를 선택하세요.
**참고**
**결제**/**예상 요금 합계** 지표가 표시되지 않으면 결제 알림을 활성화하고 리전을 미국 동부(버지니아 북부)로 변경합니다. 자세한 내용은 [결제 알림 사용 설정](#turning_on_billing_metrics) 섹션을 참조하세요.
1. **EstimatedCharges** 지표 상자를 선택한 다음 **Select metric**(지표 선택)을 선택합니다.
1. **통계**에서 **최대**를 선택합니다.
1. **Period**(기간)에서 **6 hours**(6시간)를 선택합니다.
1. **임곗값 유형**에서 **정적**을 선택합니다.
1. **Whenever EstimatedCharges is . . .**(EstimatedCharges가 다음인 경우 항상…)에서 **Greater**(보다 큼)를 선택합니다.
1. **. . . 보다**에 대해 경보를 트리거하려는 값을 정의합니다. 예를 들어 USD **200**달러입니다.
**EstimatedCharges** 지표 값은 미국 달러(USD)로만 표시되며, 통화 변환은 Amazon Services LLC에서 제공합니다. 자세한 내용은 [AWS Billing란 무엇인가요?](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html)를 참조하세요.
**참고**
임곗값을 정의하면 미리 보기 그래프에 이번 달의 예상 요금이 표시됩니다.
1. **추가 구성**을 선택하고 다음을 수행합니다.
+ **Datapoints to alarm**(경보를 보낼 데이터 포인트)에서 **1 out of 1**(1/1)을 지정합니다.
+ **Missing data treatment**(누락된 데이터 처리)에서 **Treat missing data as missing**(누락된 데이터를 누락으로 처리)을 선택합니다.
1. **다음**을 선택합니다.
1. **알림**에서 **경보 내**가 선택되어 있는지 확인하세요. 그런 다음 경보가 `ALARM` 상태일 때 알림을 받을 Amazon SNS 주제를 지정합니다. Amazon SNS 주제에 이메일 주소를 포함하면 청구 금액이 지정한 임곗값을 초과할 때 이메일을 받을 수 있습니다.
기존 Amazon SNS 주제를 선택하거나, 새 Amazon SNS 주제를 생성하거나, 주제 ARN을 사용하여 다른 계정에 알릴 수 있습니다. 경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 전송하도록 하려면 **Add notification**(알림 추가)을 선택합니다.
1. **다음**을 선택합니다.
1. **Name and description**(이름 및 설명)에 경보 이름을 입력합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다.
1. (선택 사항) 경보에 대한 설명을 입력합니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **다음**을 선택합니다.
1. **Preview and create**(미리 보기 및 생성)에서 구성이 올바른지 확인한 다음 **Create alarm**(경보 생성)을 선택합니다.
## 결제 경보 삭제
결제 경보가 더 이상 필요하지 않다면 삭제할 수 있습니다.
**결제 경보를 삭제하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 필요한 경우 리전을 미국 동부(버지니아 북부)로 변경합니다. 결제 지표 데이터는 이 리전에 저장되며 전 세계 요금을 반영합니다.
1. 탐색 창에서 **Alarms**, **All alarms**를 선택합니다.
1. 경보 옆의 확인란을 선택하고 **작업**, **삭제**를 차례로 선택합니다.
1. 확인 메시지가 나타나면 **예, 삭제합니다(Yes, Delete)**를 선택합니다.
# CPU 사용률 경보 생성
경보 상태가 `OK`에서 `ALARM`으로 변경될 때 Amazon SNS를 사용하여 알림을 보내는 CloudWatch 경보를 생성할 수 있습니다.
EC2 인스턴스의 평균 CPU 사용률이 지정된 기간 동안 연속해서 지정된 임곗값을 초과하면 경보 상태가 `ALARM`으로 바뀝니다.
## AWS Management Console을 사용하여 CPU 사용량 경보 설정
다음 단계에 따라 AWS Management Console을 사용해 CPU 사용량 경보를 생성합니다.
**CPU 사용량을 기반으로 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성(Create alarm)**을 선택하세요.
1. **지표 선택**을 선택합니다.
1. **모든 지표** 탭에서 **EC2 지표**를 선택합니다.
1. 지표 범주(예: **인스턴스별 지표**)를 선택합니다.
1. 원하는 인스턴스가 **InstanceId** 열에 나열되고 **CPUUtilization**이 **지표 이름(Metric Name)** 열에 있는 행을 찾습니다. 이 행 옆의 확인란을 선택하고 **지표 선택**을 선택합니다.
1. **지표 및 조건 지정** 아래에 있는 **통계**에서 **평균**을 선택하거나, 사전 정의된 백분위수 중 하나를 선택하거나, 사용자 지정 백분위수(예: **p95.45**)를 지정합니다.
1. 기간(예: **5 minutes**)을 선택합니다.
1. **조건**에서 다음을 지정합니다.
1. **임곗값 유형**에서 **정적**을 선택합니다.
1. **CPUUtilization이(가) 다음과 같은 경우에 항상**에서 **보다 큼**을 지정합니다. **than...**에서 CPU 사용률이 이 비율을 초과할 경우 경보를 ALARM 상태로 전환할 임곗값을 지정합니다. 예: 70.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N 중 M 경보를 생성하려면 두 번째 값에 지정한 값보다 낮은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 단원을 참조하세요.
1. **누락 데이터 처리**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 단원을 참조하세요.
1. 경보가 모니터링된 통계 값으로 백분위수를 사용하는 경우에는 **샘플이 부족한 백분위수** 상자가 표시됩니다. 샘플 비율이 낮은 사례를 평가 또는 무시할지 여부를 선택할 때 이 상자를 사용합니다. **ignore (maintain alarm state)(무시(경보 상태 유지))**를 선택하면 샘플 크기가 너무 작을 때 현재 경보 상태가 항상 유지됩니다. 자세한 내용은 [백분위수 기반 경보 및 데이터 샘플 부족](percentiles-with-low-samples.md) 단원을 참조하세요.
1. **다음**을 선택합니다.
1. **알림**에서 **경보 상태**를 선택하고 경보가 `ALARM` 상태일 때 알릴 SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거**를 선택합니다.
1. 마친 후에는 **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 그리고 **다음**을 선택합니다.
이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **미리 보기 및 생성**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성**을 선택합니다.
## AWS CLI를 사용하여 CPU 사용량 경보 설정
다음 단계에 따라 AWS CLI을 사용해 CPU 사용량 경보를 생성합니다.
**CPU 사용량을 기반으로 경보를 생성하려면**
1. SNS 주제를 설정합니다. 자세한 내용은 [Amazon SNS 알림 설정](Notify_Users_Alarm_Changes.md#US_SetupSNS) 단원을 참조하세요.
1. 아래와 같이 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용하여 경보를 생성합니다.
```
aws cloudwatch put-metric-alarm --alarm-name cpu-mon --alarm-description "Alarm when CPU exceeds 70%" --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 70 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-12345678 --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Percent
```
1. [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 명령으로 경보 상태를 강제로 변경하여 경보를 테스트합니다.
1. 경보 상태를 `INSUFFICIENT_DATA`에서 `OK`으로 변경합니다.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value OK
```
1. 경보 상태를 `OK`에서 `ALARM`으로 변경합니다.
```
aws cloudwatch set-alarm-state --alarm-name cpu-mon --state-reason "initializing" --state-value ALARM
```
1. 경보에 관한 알림을 받았는지 확인합니다.
# 이메일을 전송하는 로드 밸런서 지연 경보 생성
Amazon SNS 알림을 설정하고 Classic Load Balancer에 대해 100ms를 초과하는 대기 시간을 모니터링하는 경보를 구성할 수 있습니다.
## AWS Management Console을 사용하여 대기 시간 경보 설정
다음 단계에 따라 AWS Management Console을 사용해 로드 밸런서 지연 시간 경보를 생성합니다.
**로드 밸런서 대기 시간 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. **범주별 CloudWatch 지표**에서 **ELB 지표** 범주를 선택합니다.
1. Classic Load Balancer 및 [**대기 시간(Latency)**] 지표가 있는 행을 선택합니다.
1. 통계의 경우 **평균**을 선택하거나, 사전 정의된 백분위수 중 하나를 선택하거나, 사용자 지정 백분위수(예: **p95.45**)를 지정합니다.
1. 기간의 경우 **1분**을 선택합니다.
1. **다음**을 선택합니다.
1. **경보 임곗값**에 경보의 고유한 이름(예: **myHighCpuAlarm**)과 경보에 대한 설명(예: **Alarm when Latency exceeds 100s**)을 입력합니다. 경보 이름은 UTF-8 문자만 포함해야 하고 ASCII 제어 문자를 포함할 수 없습니다.
이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **다음 경우 항상**의 **조건**에서 **>**를 선택하고 **0.1**을 입력합니다. **기간**에 **3**을 입력합니다.
1. 누락 데이터 포인트가 경보 상태 변경을 트리거하지 않도록 **추가 설정**의 **누락 데이터 처리**에서 **무시(경보 상태 유지)**를 선택합니다.
경보가 적정 수의 데이터 샘플이 있는 상황만 평가하도록 **샘플이 부족한 백분위수**에서 **ignore (maintain alarm state)(무시(경보 상태 유지))**를 선택합니다.
1. **작업**의 **이 경보가 발생할 경우 항상**에서 **상태가 ALARM입니다**를 선택합니다. **알림 보내기**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
SNS 주제를 생성하려면 **새 목록**을 선택합니다. [**알림 보내기(Send notification to)**]에 SNS 주제 이름(예: **myHighCpuAlarm**)을 입력하고, [**이메일 목록(Email list)**]에 경보가 `ALARM` 상태로 변경될 때 알림을 받을 이메일 주소 목록을 쉼표로 구분하여 입력합니다. 각 이메일 주소로 주제 구독 확인 이메일이 전송됩니다. 알림을 받으려면 먼저 구독을 확정해야 합니다.
1. **경보 생성**을 선택합니다.
## AWS CLI를 사용하여 대기 시간 경보 설정
다음 단계에 따라 AWS CLI을 사용해 로드 밸런서 지연 시간 경보를 생성합니다.
**로드 밸런서 대기 시간 경보를 생성하려면**
1. SNS 주제를 설정합니다. 자세한 내용은 [Amazon SNS 알림 설정](Notify_Users_Alarm_Changes.md#US_SetupSNS) 단원을 참조하세요.
1. 아래와 같이 [put-metric-alarm](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/put-metric-alarm.html) 명령을 사용하여 경보를 생성합니다.
```
1. aws cloudwatch put-metric-alarm --alarm-name lb-mon --alarm-description "Alarm when Latency exceeds 100s" --metric-name Latency --namespace AWS/ELB --statistic Average --period 60 --threshold 100 --comparison-operator GreaterThanThreshold --dimensions Name=LoadBalancerName,Value=my-server --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-topic --unit Seconds
```
1. [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 명령으로 경보 상태를 강제로 변경하여 경보를 테스트합니다.
1. 경보 상태를 `INSUFFICIENT_DATA`에서 `OK`으로 변경합니다.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value OK
```
1. 경보 상태를 `OK`에서 `ALARM`으로 변경합니다.
```
1. aws cloudwatch set-alarm-state --alarm-name lb-mon --state-reason "initializing" --state-value ALARM
```
1. 경보에 대한 이메일 알림을 받았음을 확인합니다.
# 이메일을 전송하는 스토리지 처리량 경보 생성
SNS 알림을 설정하고 Amazon EBS가 100MB의 처리량을 초과할 때 트리거되는 경보를 구성할 수 있습니다.
## AWS Management Console을 사용하여 스토리지 처리량 경보 설정
다음 단계에 따라 AWS Management Console을 사용하여 Amazon EBS 처리량을 기반으로 경보를 생성합니다.
**스토리지 처리량 경보를 생성하려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**, **모든 경보(All Alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. **EBS 지표**에서 지표 범주를 선택합니다.
1. 볼륨과 **VolumeWriteBytes** 지표가 있는 행을 선택합니다.
1. 통계의 경우 **평균(Average)**을 선택합니다. 기간의 경우 **5분**을 선택합니다. **다음**을 선택합니다.
1. **경보 임곗값**에 경보의 고유한 이름(예: **myHighWriteAlarm**)과 경보에 대한 설명(예: **VolumeWriteBytes exceeds 100,000 KiB/s**)을 입력합니다. 이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **다음 경우 항상**의 **조건**에서 **>**를 선택하고 **100000**을 입력합니다. **기간**에 연속 기간으로 **15**를 입력합니다.
**경보 미리 보기** 아래에 임곗값이 그래픽으로 표시됩니다.
1. 누락 데이터 포인트가 경보 상태 변경을 트리거하지 않도록 **추가 설정**의 **누락 데이터 처리**에서 **무시(경보 상태 유지)**를 선택합니다.
1. **작업**의 **이 경보가 발생할 경우 항상**에서 **상태가 ALARM입니다**를 선택합니다. **알림 보내기**에서 기존 SNS 주제를 선택하거나 새로 만듭니다.
SNS 주제를 생성하려면 **새 목록**을 선택합니다. [**알림 보내기(Send notification to)**]에 SNS 주제 이름(예: **myHighCpuAlarm**)을 입력하고, [**이메일 목록(Email list)**]에 경보가 `ALARM` 상태로 변경될 때 알림을 받을 이메일 주소 목록을 쉼표로 구분하여 입력합니다. 각 이메일 주소로 주제 구독 확인 이메일이 전송됩니다. 수신자가 구독을 확인해야만 이 이메일 주소로 알림이 전송될 수 있습니다.
1. **경보 생성**을 선택합니다.
## AWS CLI를 사용하여 스토리지 처리량 경보 설정
다음 단계에 따라 AWS CLI를 사용하여 Amazon EBS 처리량을 기반으로 경보를 생성합니다.
**스토리지 처리량 경보를 생성하려면**
1. SNS 주제를 생성합니다. 자세한 내용은 [Amazon SNS 알림 설정](Notify_Users_Alarm_Changes.md#US_SetupSNS) 단원을 참조하세요.
1. 경보를 만듭니다.
```
1. aws cloudwatch put-metric-alarm --alarm-name ebs-mon --alarm-description "Alarm when EBS volume exceeds 100MB throughput" --metric-name VolumeReadBytes --namespace AWS/EBS --statistic Average --period 300 --threshold 100000000 --comparison-operator GreaterThanThreshold --dimensions Name=VolumeId,Value=my-volume-id --evaluation-periods 3 --alarm-actions arn:aws:sns:us-east-1:111122223333:my-alarm-topic --insufficient-data-actions arn:aws:sns:us-east-1:111122223333:my-insufficient-data-topic
```
1. [set-alarm-state](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/set-alarm-state.html) 명령으로 경보 상태를 강제로 변경하여 경보를 테스트합니다.
1. 경보 상태를 `INSUFFICIENT_DATA`에서 `OK`으로 변경합니다.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value OK
```
1. 경보 상태를 `OK`에서 `ALARM`으로 변경합니다.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value ALARM
```
1. 경보 상태를 `ALARM`에서 `INSUFFICIENT_DATA`으로 변경합니다.
```
1. aws cloudwatch set-alarm-state --alarm-name ebs-mon --state-reason "initializing" --state-value INSUFFICIENT_DATA
```
1. 경보에 대한 이메일 알림을 받았음을 확인합니다.
# AWS 데이터베이스의 성능 개선 도우미 카운터 지표에 대한 경보 생성
CloudWatch에는 Amazon 관계형 데이터베이스 서비스 및 Amazon DocumentDB(MongoDB 호환)의 성능 개선 도우미 카운터 지표를 CloudWatch로 가져오는 데 사용할 수 있는 **DB\$1PERF\$1INSIGHTS** 지표 수학 함수가 포함되어 있습니다. 또한 **DB\$1PERF\$1INSIGHTS**는 1분 미만의 간격으로 `DBLoad` 지표를 가져옵니다. 이러한 지표에 대해 CloudWatch 경보를 설정할 수 있습니다.
Amazon RDS Performance Insights에 대한 자세한 내용은 [성능 개선 도우미를 통한 Amazon RDS 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)을 참조하세요.
Amazon DocumentDB 성능 개선 도우미에 대한 자세한 내용은 [Monitoring with Performance Insights](https://docs.aws.amazon.com/documentdb/latest/developerguide/performance-insights.html.html)를 참조하세요.
**DB\$1PERF\$1INSIGHTS** 함수를 기반으로 하는 경보에는 이상 탐지가 지원되지 않습니다.
**참고**
**DB\$1PERF\$1INSIGHTS**가 검색하는 분 단위 이하의 고분해능 지표는 **DBLoad** 지표 또는 운영 체제 지표(고분해능에서 Enhanced Monitoring을 사용하도록 설정한 경우)에만 적용됩니다. Amazon RDS 확장 모니터링에 대한 자세한 내용은 [Enhanced Monitoring을 사용하여 OS 지표 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)을 참조하세요.
**DB\$1PERF\$1INSIGHTS** 함수를 사용하여 고분해능 경보를 생성할 수 있습니다. 고분해능 경보의 최대 평가 범위는 3시간입니다. CloudWatch 콘솔을 사용하여 **DB\$1PERF\$1INSIGHTS** 함수로 검색된 지표를 원하는 시간 범위에 대해 그래프로 표시할 수 있습니다.
**성능 개선 도우미 지표를 기반으로 경보를 만들려면**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **경보(Alarms)**를 선택한 다음 **모든 경보(All alarms)**를 선택합니다.
1. **경보 생성**을 선택하세요.
1. **지표 선택**을 선택합니다.
1. **수학 추가** 드롭다운을 선택한 다음 목록에서 **모든 함수**, **DB\$1PERF\$1INSIGHTS**를 선택합니다.
**DB\$1PERF\$1INSIGHTS**를 선택하면 수학 표현식을 적용하거나 편집할 수 있는 수학 표현식 상자가 나타납니다.
1. 수학 표현식 상자에 **DB\$1PERF\$1INSIGHTS** 수학 표현식을 입력한 다음 **적용**을 선택합니다.
예: **DB\$1PERF\$1INSIGHTS(‘RDS’, ‘db-ABCDEFGHIJKLMNOPQRSTUVWXY1’, ‘os.cpuUtilization.user.avg’)**
**중요**
**DB\$1PERF\$1INSIGHTS** 수학 표현식을 사용할 때는 데이터베이스의 고유 데이터베이스 리소스 ID를 지정해야 합니다. 이는 데이터베이스 식별자와는 다릅니다. Amazon RDS 콘솔에서 데이터베이스 리소스 ID를 찾으려면 DB 인스턴스를 선택하여 세부 정보를 확인합니다. 그런 다음 **구성** 탭을 선택합니다. 그러면 **리소스 ID**가 **구성** 섹션에 표시됩니다.
지표 연산에 사용할 수 있는 **DB\$1PERF\$1INSIGHTS** 함수 및 기타 함수에 대한 자세한 내용은 [지표 수학 구문 및 함수](using-metric-math.md#metric-math-syntax) 섹션을 참조하세요.
1. **지표 선택**을 선택합니다.
선택한 수학 표현식에 대한 그래프와 기타 정보가 표시된 **지표 및 조건 지정** 페이지가 표시됩니다.
1. **표현식이 *다음인 경우* 항상**에서 표현식이 임곗값보다 크거나, 작거나, 같아야 하는지 여부를 지정합니다. **than...**에서 임곗값을 지정합니다.
1. **추가 구성**을 선택합니다. **경보에 대한 데이터 포인트**에서 경보를 트리거하기 위해 평가 기간(데이터 포인트)이 `ALARM` 상태로 유지해야 하는 기간을 지정합니다. 두 값이 일치하는 경우 다수의 연속 기간이 위반되면 `ALARM` 상태가 되는 경보가 생성됩니다.
N 중 M 경보를 생성하려면 두 번째 값에 지정한 값보다 낮은 값을 첫 번째 값에 지정합니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 단원을 참조하세요.
1. **누락 데이터 처리**에서 일부 데이터 포인트가 누락된 경우 경보가 어떻게 동작할지 선택합니다. 자세한 내용은 [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](alarms-and-missing-data.md) 단원을 참조하세요.
1. **다음(Next)**을 선택합니다.
1. **알림(Notification)**에서 경보가 `ALARM` 상태, `OK` 상태 또는 `INSUFFICIENT_DATA` 상태일 때 알릴 SNS 주제를 선택합니다.
경보가 동일한 경보 상태 또는 다른 경보 상태에 대해 여러 개의 알림을 보내도록 설정하려면 **알림 추가**를 선택합니다.
경보에서 알림을 보내지 않게 하려면 **제거**를 선택합니다.
1. 경보가 Auto Scaling, EC2, Lambda 또는 Systems Manager 작업을 수행하도록 하려면 해당 버튼을 선택하고 경보 상태와 수행할 작업을 선택합니다. Lambda 함수를 경보 작업으로 선택하는 경우 함수 이름 또는 ARN을 지정하고 필요에 따라 함수의 특정 버전을 선택할 수 있습니다.
경보는 ALARM 상태가 될 때만 Systems Manager 작업을 수행할 수 있습니다. Systems Manager 작업에 대한 자세한 내용은 [경보에서 OpsItem을 생성하도록 CloudWatch 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 및 [인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html) 단원을 참조하세요.
**참고**
SSM Incident Manager 작업을 수행하는 경보를 생성하려면 특정 권한이 있어야 합니다. 자세한 내용은 [AWS Systems Manager Incident Manager의 자격 증명 기반 정책 예](https://docs.aws.amazon.com/incident-manager/latest/userguide/security_iam_id-based-policy-examples.html) 단원을 참조하세요.
1. 마친 후에는 **다음**을 선택합니다.
1. 경보 이름 및 설명을 입력합니다. 그리고 **다음**을 선택합니다.
이름에는 UTF-8 문자만 포함해야 하며 ASCII 제어 문자는 포함할 수 없습니다. 설명에 마크다운 서식을 포함할 수 있으며, 이는 CloudWatch 콘솔에서 경보 **세부 정보** 탭에만 표시됩니다. 마크다운은 런북이나 기타 내부 리소스에 대한 링크를 추가하는 데 유용할 수 있습니다.
1. **미리 보기 및 생성**에서 정보 및 조건이 원하는 내용인지 확인한 다음 **경보 생성**을 선택합니다.