# 대규모 Amazon ECS 운영
Amazon ECS를 대규모로 운영하기 시작하는 경우 Amazon ECS 및 Amazon ECS와 통합되는 AWS 서비스에 대한 서비스 할당량 및 API 스로틀이 사용자에게 미치는 영향을 고려하세요.
**Topics**
+ [
# Amazon ECS 서비스 할당량 및 API 스로틀링 제한
](operating-at-scale-service-quotas-best-practice.md)
+ [
# Amazon ECS 제한 문제 처리
](operating-at-scale-dealing-with-throttles.md)
# Amazon ECS 서비스 할당량 및 API 스로틀링 제한
Amazon ECS는 Elastic Load Balancing, AWS Cloud Map, Amazon EC2를 비롯한 여러 AWS 서비스에 통합됩니다. Amazon ECS는 이러한 긴밀한 통합을 통해 서비스 로드 밸런싱, 서비스 검색, 태스크 네트워킹, 클러스터 오토 스케일링 등의 여러 기능을 포함합니다. Amazon ECS 및 통합되는 기타 AWS 서비스는 모두 서비스 할당량 및 API 속도 제한을 유지 관리하여 일관된 성능 및 사용률을 보장합니다. 또한 이러한 서비스 할당량은 필요한 수준을 초과하여 많은 리소스가 실수로 프로비저닝되는 것을 방지하고 청구 비용을 늘릴 수 있는 악의적인 행동으로부터 보호합니다.
서비스 할당량 및 AWS API 속도 제한을 숙지하면 예상치 못한 성능 저하에 대한 걱정 없이 워크로드 규모 조정을 계획할 수 있습니다. 자세한 내용은 [Amazon ECS 서비스 할당량](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) 및 [Amazon ECS API에 대한 요청 스로틀링](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)을 참조하세요.
Amazon ECS에서 워크로드 규모를 조정할 때 다음과 같은 서비스 할당량을 고려하세요. 서비스 할당량 증가를 요청하는 방법에 대한 지침은 [AWS Management Console에서 Amazon ECS 및 AWS Fargate 서비스 할당량 관리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas-manage.html)를 참조하세요.
+ AWS Fargate에는 각 AWS 리전에서 동시에 실행되는 작업 수를 제한하는 할당량이 있습니다. Amazon ECS에는 온디맨드 작업 및 Fargate 스팟 작업 모두에 대한 할당량이 있습니다. 각 서비스 할당량에는 Fargate에서 실행하는 모든 Amazon EKS 포드도 포함됩니다. Fargate 할당량에 대한 자세한 내용은 *AWS Fargate용 Amazon Elastic Container Service 사용 설명서*의 [AWS Fargate 서비스 할당량](https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-quotas.html#service-quotas-fargate)을 참조하세요.
+ Amazon EC2 인스턴스에서 실행되는 작업의 경우 각 클러스터에 등록할 수 있는 Amazon EC2 인스턴스의 최대 개수는 5,000개입니다. Auto Scaling 그룹 용량 공급자와 함께 Amazon ECS 클러스터 Auto Scaling을 사용하거나 클러스터의 Amazon EC2 인스턴스를 자체적으로 관리하는 경우 이 할당량으로 인해 배포 병목 현상이 발생할 수 있습니다. 더 많은 용량이 필요한 경우 클러스터를 생성하거나 서비스 할당량 증가를 요청할 수 있습니다.
+ Auto Scaling 그룹 용량 공급자와 함께 Amazon ECS 클러스터 Auto Scaling을 사용하는 경우 서비스 규모를 확장할 때 `Tasks in the PROVISIONING state per cluster` 할당량을 고려합니다. 이 할당량은 각 클러스터에서 용량 공급자가 용량을 늘릴 수 있는 `PROVISIONING` 상태의 최대 작업 수입니다. 동시에 많은 작업을 시작하면 이 할당량을 쉽게 충족할 수 있습니다. 한 가지 예로, 각각 수백 개의 작업을 포함하는 수십 개의 서비스를 동시에 배포하는 경우가 있습니다. 이 경우 용량 공급자는 클러스터의 용량이 부족할 때 새 컨테이너 인스턴스를 시작하여 작업을 배치해야 합니다. 용량 공급자가 추가 Amazon EC2 인스턴스를 시작하는 동안에도 Amazon ECS 서비스 스케줄러는 작업을 계속 병렬로 시작할 수 있습니다. 하지만 클러스터 용량이 충분하지 않아 이 활동이 제한될 수 있습니다. Amazon ECS 서비스 스케줄러는 새 컨테이너 인스턴스가 시작될 때 작업 배치를 재시도하기 위한 백오프 및 지수 제한 전략을 구현합니다. 따라서 배포 또는 스케일 아웃 시간이 느려질 수 있습니다. 이러한 상황을 방지하려면 다음 방식 중 하나로 서비스 배포를 계획할 수 있습니다. 클러스터 용량을 늘릴 필요 없이 많은 태스크를 배포하거나 새 태스크를 시작할 수 있도록 예비 클러스터 용량을 확보합니다.
워크로드 규모를 조정할 때 Amazon ECS 서비스 할당량을 고려하는 것 외에도 Amazon ECS와 통합된 다른 AWS 서비스 서비스의 서비스 할당량도 고려합니다. 다음 섹션에서는 각 서비스의 주요 속도 제한을 자세히 설명하고 잠재적인 스로틀링 문제를 해결하기 위한 권장 사항을 제공합니다.
## Elastic Load Balancing
Elastic Load Balancing을 사용하여 작업 전체에 균일하게 트래픽 분산하도록 Amazon ECS 서비스를 구성할 수 있습니다. 로드 밸런서를 선택하는 방법에 대한 자세한 내용은 [로드 밸런싱을 사용하여 Amazon ECS 서비스 트래픽 분산](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)을 참조하세요.
### Elastic Load Balancing 서비스 할당량
워크로드 규모를 조정할 때는 다음과 같은 Elastic Load Balancing 서비스 할당량을 고려하세요. 대부분의 Elastic Load Balancing 서비스 할당량은 조정 가능하며 Service Quotas 콘솔에서 증가를 요청할 수 있습니다.
**Application Load Balancer**
Application Load Balancer를 사용할 때는 사용 사례에 따라 다음에 대한 할당량 증가를 요청해야 할 수 있습니다.
+ `Targets per Application Load Balancer` 할당량: Application Load Balancer 뒤에 있는 대상의 수입니다.
+ `Targets per Target Group per Region` 할당량: 대상 그룹 뒤에 있는 대상의 수입니다.
자세한 내용은 [Application Load Balancer에 대한 할당량](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)을 참조하세요.
**Network Load Balancer**
Network Load Balancer에 등록할 수 있는 대상 수에는 더 엄격한 제한이 적용됩니다. Network Load Balancer를 사용할 때 종종 교차 영역 지원을 활성화하려고 합니다. 이 경우 각 Network Load Balancer의 가용 영역당 최대 대상 수와 함께 `Targets per Availability Zone Per Network Load Balancer`의 추가 조정 제한이 적용됩니다. 자세한 내용은 [Network Load Balancer 할당량](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-limits.html)을 참조하세요.
### Elastic Load Balancing API 제한
Amazon ECS 서비스가 로드 밸런서를 사용하도록 구성하는 경우 대상 그룹 상태 확인을 통과해야 서비스가 정상으로 간주됩니다. 이러한 상태 확인을 수행하기 위해 Amazon ECS는 사용자를 대신하여 Elastic Load Balancing API 작업을 간접 호출합니다. 계정에 로드 밸런서로 구성된 서비스가 많으면 특히 `RegisterTarget`, `DeregisterTarget`, `DescribeTargetHealth` Elastic Load Balancing API 작업에서 스로틀링이 발생할 수 있으므로 서비스 배포 속도가 느려질 수 있습니다. 제한이 발생하면 Amazon ECS 서비스 이벤트 메시지에서 제한 오류가 발생합니다.
AWS Cloud Map API 제한이 발생하는 경우 지원에 AWS Cloud Map API 제한 한도 상향에 지침을 문의할 수 있습니다. 스로틀링 오류와 같은 문제의 모니터링 및 문제 해결에 대한 자세한 내용은 [스로틀링 문제 처리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)를 참조하세요.
## 탄력적 네트워크 인터페이스
태스크에서 `awsvpc` 네트워크 모드를 사용하는 경우, Amazon ECS는 각 태스크에 대해 고유한 탄력적 네트워크 인터페이스(ENI)를 프로비저닝합니다. Amazon ECS 서비스가 Elastic Load Balancing 로드 밸런서를 사용하는 경우 이러한 네트워크 인터페이스도 서비스에 정의된 적절한 대상 그룹에 대한 대상으로 등록됩니다.
### 탄력적 네트워크 인터페이스 서비스 할당량
`awsvpc` 네트워크 모드를 사용하는 작업을 실행하면 고유한 탄력적 네트워크 인터페이스가 각 작업에 연결됩니다. 인터넷을 통해 이러한 작업에 도달해야 할 경우에는 해당 작업의 탄력적 네트워크 인터페이스에 퍼블릭 IP 주소를 할당합니다. Amazon ECS 워크로드 규모를 조정할 때는 다음과 같은 두 가지 중요한 할당량을 고려합니다.
+ `Network interfaces per Region` 할당량: 계정의 AWS 리전에 있는 최대 네트워크 인터페이스 수입니다.
+ `Elastic IP addresses per Region` 할당량: AWS 리전에 있는 최대 탄력적 IP 주소 수입니다.
이 두 서비스 할당량은 모두 조정 가능하며, Service Quotas 콘솔에서 할당량 증가를 요청할 수 있습니다. 자세한 내용은 [Amazon VPC 서비스 할당량](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-enis)을 참조하세요.
Amazon EC2 인스턴스에 호스팅되는 Amazon ECS 워크로드의 경우 `awsvpc` 네트워크 모드를 사용하는 작업을 실행할 때는 각 Amazon EC2 인스턴스의 최대 네트워크 인스턴스 수에 해당하는 `Maximum network interfaces` 서비스 할당량을 고려합니다. 이 할당량은 인스턴스에 배치할 수 있는 작업 수를 제한합니다. 할당량은 조정할 수 없으며 Service Quotas 콘솔에서 사용할 수 없습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [IP addresses per network interface per instance type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)를 참조하세요.
Amazon EC2 인스턴스에 연결할 수 있는 네트워크 인터페이스 수를 변경할 수는 없지만 탄력적 네트워크 인터페이스 트렁킹 기능을 사용하여 사용 가능한 네트워크 인터페이스 수를 늘릴 수 있습니다. 예를 들어 `c5.large` 인스턴스는 최대 3개의 네트워크 인터페이스를 보유할 수 있습니다. 인스턴스에 대한 기본 네트워크 인터페이스는 한 개로 계산됩니다. 따라서 인스턴스에 네트워크 인터페이스를 2개 더 연결할 수 있습니다. `awsvpc` 네트워크 모드를 사용하는 각 작업에 네트워크 인터페이스가 필요하므로 대개 이 인스턴스 유형에서는 이러한 작업을 2개만 실행할 수 있습니다. 이로 인해 클러스터 용량 사용률이 낮아질 수 있습니다. 탄력적 네트워크 인터페이스 트렁킹을 활성화하면 네트워크 인터페이스 밀도를 높여 각 인스턴스에 더 많은 작업을 배치할 수 있습니다. 트렁킹을 켜면 `c5.large` 인스턴스는 최대 12개의 네트워크 인터페이스를 보유할 수 있습니다. 인스턴스에는 기본 네트워크 인터페이스가 있으며, Amazon ECS는 '트렁크' 네트워크 인터페이스를 생성하고 컨테이너 인스턴스에 연결합니다. 따라서 이 구성을 사용하면 인스턴스에서 기본 2개의 작업 대신 10개의 작업을 실행할 수 있습니다. 자세한 내용은 [탄력적 네트워크 인터페이스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html)를 참조하세요.
### 탄력적 네트워크 인터페이스 API 제한
`awsvpc` 네트워크 모드를 사용하는 작업을 실행할 때 Amazon ECS는 다음 Amazon EC2 API에 의존합니다. 이러한 API마다 API 제한이 서로 다릅니다. 자세한 내용은 [Request throttling for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)를 참조하세요.
+ CreateNetworkInterface
+ AttachNetworkInterface
+ DetachNetworkInterface
+ DeleteNetworkInterface
+ DescribeNetworkInterfaces
+ DescribeVpcs
+ DescribeSubnets
+ DescribeSecurityGroups
+ DescribeInstances
탄력적 네트워크 인터페이스 프로비저닝 워크플로 중에 Amazon EC2 API 직접 호출이 제한되는 경우 Amazon ECS 서비스 스케줄러는 지수 백오프를 통해 자동으로 재시도합니다. 이러한 자동 사용 중지로 인해 때때로 태스크 시작이 지연되어 배포 속도가 느려질 수 있습니다. API 제한이 발생하면 서비스 이벤트 메시지에 `Operations are being throttled. Will try again later.` 메시지가 표시됩니다. Amazon EC2 API 제한을 일관되게 충족하는 경우 API 제한 한도 상향 방법에 대한 지침을 지원에 문의할 수 있습니다. 제한 오류의 모니터링 및 문제 해결에 대한 자세한 내용은 [제한 문제 처리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)를 참조하세요.
## AWS Cloud Map
Amazon ECS 서비스 검색은 AWS Cloud Map API를 사용하여 Amazon ECS 서비스에 대한 네임스페이스를 관리합니다. 서비스에 작업 수가 많은 경우 다음 권장 사항을 고려하세요. 자세한 내용은 [Amazon ECS 서비스 검색 고려 사항](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html#service-discovery-considerations)을 참조하세요.
### AWS Cloud Map service quotas
Amazon ECS 서비스가 서비스 검색을 사용하도록 구성된 경우 서비스의 최대 태스크 수에 해당하는 `Tasks per service` 할당량은 해당 서비스의 최대 인스턴스 수인 AWS Cloud Map `Instances per service` 서비스 할당량의 영향을 받습니다. 특히 AWS Cloud Map 서비스 할당량은 실행할 수 있는 최대 태스크 수를 서비스당 1,000개 태스크로 줄입니다. AWS Cloud Map 할당량은 변경할 수 없습니다. 자세한 내용은 [AWS Cloud Map 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/cloud_map.html)을 참조하세요.
### AWS Cloud Map API 조절
Amazon ECS는 사용자를 대신하여 `ListInstances`, `GetInstancesHealthStatus`, `RegisterInstance` 및 `DeregisterInstance` AWS Cloud Map API를 직접 호출합니다. 이를 통해 서비스 검색을 지원하고 작업을 시작할 때 상태 확인을 수행할 수 있습니다. 많은 작업에서 서비스 검색을 사용하는 여러 서비스를 동시에 배포하는 경우, 이로 인해 AWS Cloud Map API 제한 한도가 초과될 수 있습니다. 이 경우 Amazon ECS 서비스 이벤트 메시지에 `Operations are being throttled. Will try again later` 메시지가 표시되고, 배포 및 작업 시작 속도가 느려집니다. AWS Cloud Map에서는 이러한 API의 제한 한도를 문서화하지 않습니다. 이로 인해 제한이 발생하는 경우 지원에 API 제한 한도 상향에 지침을 문의할 수 있습니다. 스로틀링 오류와 같은 문제의 모니터링 및 문제 해결에 대한 자세한 권장 사항은 [스로틀링 문제 처리](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/operating-at-scale-dealing-with-throttles.html)를 참조하세요.
# Amazon ECS 제한 문제 처리
제한 오류는 크게 동기 제한 및 비동기 제한이라는 두 가지 주요 범주로 분류됩니다.
## 동기 제한
동기 제한이 수행되면 Amazon ECS에서 즉시 오류 응답을 수신합니다. 이 범주는 일반적으로 작업을 실행하거나 서비스를 생성하는 동안 Amazon ECS API를 호출할 때 발생합니다. 관련된 제한 및 관련 제한 한도에 대한 자세한 내용은 [Amazon ECS API에 대한 요청 제한](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html)을 참조하세요.
애플리케이션에서 API 요청을 시작하면(예를 들어, AWS CLI 또는 AWS SDK를 사용함) API 제한을 해결할 수 있습니다. 오류를 처리하도록 애플리케이션을 설계하거나 API 직접 호출에 대한 재시도 로직이 포함된 지수 백오프 및 지터 전략을 구현하여 이를 수행할 수 있습니다. 자세한 내용은 [시간 제한, 재시도 및 지터를 사용한 백오프](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)를 참조하세요.
AWS SDK를 사용하는 경우 자동 재시도 로직이 기본 제공되며 구성 가능합니다.
## 비동기 제한
비동기 제한은 Amazon ECS 또는 CloudFormation에서 사용자를 대신하여 API를 직접 호출해 리소스를 프로비저닝하는 비동기 워크플로로 인해 발생합니다. Amazon ECS가 사용자를 대신하여 어떤 AWS API를 직접 호출하는지 파악하는 것이 중요합니다. 예를 들어 `awsvpc` 네트워크 모드를 사용하는 작업에 대해 `CreateNetworkInterface` API가 간접 호출되고 로드 밸런서에 등록된 작업의 상태 확인을 수행할 때 `DescribeTargetHealth` API가 간접 호출됩니다.
워크로드가 상당한 규모에 도달하면 이러한 API 작업이 제한될 수 있습니다. 즉, Amazon ECS에서 시행하는 제한 또는 호출되는 AWS 서비스를 위반할 수준으로 제한이 발생할 수 있습니다. 예를 들어, 각각 `awsvpc` 네트워크 모드를 사용하는 수백 개의 작업을 동시에 보유하는 수백 개의 서비스를 배포하는 경우 Amazon ECS는 Amazon EC2 API 작업(예: `CreateNetworkInterface`) 및 Elastic Load Balancing API 작업(예: `RegisterTarget` 또는 `DescribeTargetHealth`)을 간접 호출하여 각각 탄력적 네트워크 인터페이스와 로드 밸런서를 등록합니다. 이러한 API 직접 호출은 API 제한을 초과할 수 있으며 이 경우 제한 오류가 발생할 수 있습니다. 다음은 서비스 이벤트 메시지에 포함된 Elastic Load Balancing 제한 오류의 예제입니다.
```
{
"userIdentity":{
"arn":"arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForECS/ecs-service-scheduler",
"eventTime":"2022-03-21T08:11:24Z",
"eventSource":"elasticloadbalancing.amazonaws.com",
"eventName":" DescribeTargetHealth ",
"awsRegion":"us-east-1",
"sourceIPAddress":"ecs.amazonaws.com",
"userAgent":"ecs.amazonaws.com",
"errorCode":"ThrottlingException",
"errorMessage":"Rate exceeded",
"eventID":"0aeb38fc-229b-4912-8b0d-2e8315193e9c"
}
}
```
이러한 API 직접 호출이 계정의 다른 API 트래픽과 제한을 공유하는 경우 서비스 이벤트로 생성되더라도 모니터링이 어려울 수 있습니다.
## 제한 모니터링
제한되는 API 요청과 이러한 요청의 발행자를 식별하는 것이 중요합니다. 제한을 모니터링하고 CloudWatch, Amazon Athena, Amazon EventBridge와 통합되는 AWS CloudTrail을 사용할 수 있습니다. CloudWatch Logs로 특정 이벤트를 전송하도록 CloudTrail을 구성할 수 있습니다. CloudWatch Logs 로그 인사이트는 이벤트를 구문 분석하고 분석합니다. 이를 통해 직접 호출을 수행한 사용자 또는 IAM 역할, 수행된 API 직접 호출 수와 같은 제한 이벤트의 세부 정보를 식별합니다. 자세한 내용은 [Monitoring CloudTrail log files with CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)를 참조하세요.
CloudWatch Logs Insights에 대한 자세한 내용 및 로그 파일을 쿼리하는 방법에 대한 지침은 [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)를 참조하세요.
Amazon Athena를 사용하면 표준 SQL을 사용하여 쿼리를 생성하고 데이터를 분석할 수 있습니다. 예를 들어, Athena 테이블을 생성하여 CloudTrail 이벤트를 구문 분석할 수 있습니다. 자세한 내용은 [Using the CloudTrail console to create an Athena table for CloudTrail logs](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct)를 참조하세요.
Athena 테이블을 생성한 후 다음과 같은 SQL 쿼리를 사용하여 `ThrottlingException` 오류를 조사할 수 있습니다.
모든 *사용자 입력*을 사용자의 값으로 바꿉니다.
```
select eventname, errorcode,eventsource,awsregion, useragent,COUNT(*) count
FROM cloudtrail_table-name
where errorcode = 'ThrottlingException'
AND eventtime between '2024-09-24T00:00:08Z' and '2024-09-23T23:15:08Z'
group by errorcode, awsregion, eventsource, useragent, eventname
order by count desc;
```
또한, Amazon ECS는 Amazon EventBridge로 이벤트 알림을 내보냅니다. 리소스 상태 변경 이벤트 및 서비스 작업 이벤트가 있습니다. 여기에는 `ECS_OPERATION_THROTTLED` 및 `SERVICE_DISCOVERY_OPERATION_THROTTLED`와 같은 API 제한 이벤트가 포함됩니다. 자세한 내용은 [Amazon ECS 서비스 작업 이벤트](ecs_service_events.md) 섹션을 참조하세요.
이에 응답하여 AWS Lambda와 같은 서비스에서 작업을 수행하기 위해 이러한 이벤트를 사용할 수 있습니다. 자세한 내용은 [Amazon ECS 이벤트 처리](ecs_cwet_handling.md) 섹션을 참조하세요.
독립 실행형 작업을 실행하는 경우 일부 API 작업(예: `RunTask`)은 비동기식이며, 재시도 작업은 자동으로 수행되지 않습니다. 이 경우 EventBridge 통합에서 AWS Step Functions와 같은 서비스를 사용하여 제한되거나 실패한 작업을 재시도할 수 있습니다. 자세한 내용은 [Manage a container task (Amazon ECS, Amazon SNS)](https://docs.aws.amazon.com/step-functions/latest/dg/sample-project-container-task-notification.html)를 참조하세요.
## CloudWatch를 사용하여 제한 모니터링
CloudWatch는 **AWS 리소스별** 아래 `Usage` 네임스페이스에서 API 사용 모니터링 기능을 제공합니다. 이러한 지표는 **API** 유형과 지표 이름 **CallCount**로로 기록됩니다. 이러한 지표가 특정 임계값에 도달할 때마다 시작할 경보를 생성할 수 있습니다. 자세한 내용은 [서비스 할당량 시각화 및 경보 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html)을 참조하세요.
또한 CloudWatch는 이상 탐지 기능을 제공합니다. 이 기능은 기계 학습을 사용하여 활성화한 지표의 특정 동작을 기반으로 기준을 분석하고 설정합니다. 비정상적인 API 활동이 있는 경우 이 기능을 CloudWatch 경보와 함께 사용할 수 있습니다. 자세한 내용은 [CloudWatch 이상 탐지 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)을 참조하세요.
제한 오류를 사전에 모니터링하여 관련 제한 한도를 높이고 고유한 애플리케이션 요구 사항에 대한 지침을 받을 수 있도록 지원에 문의할 수 있습니다.