애플리케이션 상태 확인

애플리케이션 상태 확인은 Amazon EC2에서 실행되는 애플리케이션의 성능과 상태를 모니터링하는 데 도움이 됩니다. 애플리케이션 상태 확인을 사용하면 구성 가능한 경로 및 포트를 통해 애플리케이션을 모니터링하여 애플리케이션 상태 장애를 감지하고 대응할 수 있습니다. 예를 들어 애플리케이션 상태 확인을 사용하여 웹 서버가 예상 포트에서 수신 대기하고 새 연결을 수락하고 있는지 확인할 수 있습니다.

애플리케이션 상태 확인은 구성 가능한 경로 및 포트에서 애플리케이션의 HTTP 및 HTTPS 응답을 모니터링합니다. 60초마다 실행되고 Amazon EC2 Auto Scaling과 통합되므로 애플리케이션이 손상된 인스턴스의 교체를 자동화할 수 있습니다.

애플리케이션 상태 확인 작동 방식

애플리케이션 상태 확인은 60초마다 인스턴스의 네트워크 포트에서 수신하는 엔드포인트로 HTTP 또는 HTTPS 요청을 전송합니다. AWS는 응답 코드를 구성한 상태 코드 매처와 비교합니다. 연속으로 여러 번 요청에 실패하면 해당 검사가 장애 상태(impaired)로 표시되고, 이후 연속으로 여러 번 요청에 성공하면 다시 정상 상태(healthy)로 표시됩니다. 두 개수 모두 기본값은 2이며 구성할 수 있습니다. 자세한 내용은 평가 임계값 섹션을 참조하세요.

재부팅 중에 애플리케이션 상태 확인은 운영 체제가 다시 시작되는 동안 애플리케이션이 상태 확인 요청에 응답할 수 없기 때문에 인스턴스를 다시 사용할 수 있을 때까지 실패를 보고합니다.

네트워크 아키텍처

애플리케이션 상태 확인은 Amazon EC2 애플리케이션 상태 확인 서비스에서 시작됩니다. 인스턴스에 도달하기 위해 AWS는 VPC에 관리형 탄력적 네트워크 인터페이스(ENI)를 생성합니다. AWS는 연결된 인스턴스가 있는 소스 서브넷 및 보안 그룹의 조합당 하나의 ENI를 생성합니다. AWS는 애플리케이션 상태 확인에 해당 조합이 처음 필요한 경우 관리형 ENI를 생성하고 나머지 애플리케이션 상태 확인에 필요하지 않은 경우 제거합니다. 관리형 ENI는 인스턴스 ENI 제한에 포함되지 않지만 가용 영역별로 적용되는 계정의 리전별 네트워크 인터페이스 할당량에 포함됩니다. 자세한 내용은 Amazon VPC할당량을 참조하세요.

기본적으로 Amazon EC2는 이 설정을 사용할 수 있게 되기 전에 관리형 리소스가 없는 계정의 콘솔 및 API 목록 작업에서 이러한 관리형 네트워크 인터페이스를 숨깁니다. 가시성을 변경하려면 관리형 리소스 가시성 설정을 참조하세요.

AWS는 연결된 인스턴스 간에 소스 서브넷과 보안 그룹의 각 조합에 대해 하나의 관리형 네트워크 인터페이스를 생성합니다. 관리형 인터페이스의 수는 모니터링되는 인스턴스가 사용하는 고유한 서브넷 및 보안 그룹 조합의 수에 따라 증가합니다. 모니터링된 인스턴스를 더 적은 서브넷 및 보안 그룹 조합으로 통합하면 관리형 인터페이스 수가 줄어듭니다. 예를 들어 단일 보안 그룹을 사용하는 2개의 서브넷에 분산된 200개의 인스턴스는 2개의 관리형 인터페이스를 생성합니다. 이 2개의 서브넷에서 3개의 보안 그룹을 사용하는 동일한 200개의 인스턴스는 최대 6개의 관리형 인터페이스를 생성합니다. 각 인터페이스는 하나의 서브넷과 보안 그룹 조합에 해당합니다.

애플리케이션 상태 확인은 VPC 내의 프라이빗 관점에서 인스턴스에 도달합니다. 범위는 인스턴스 IP 주소의 속성이 아닌 검사가 시작되는 위치를 설명합니다. AWS는 VPC 내의 서브넷에 관리형 ENI를 생성하고 프라이빗 네트워크 경로를 통해 인스턴스에 도달합니다.

AWS 관리형 네트워크 경로를 사용하면 상태 확인 트래픽이 대상 인스턴스(또는 로컬 영역 대상의 상위 가용 영역)와 동일한 가용 영역에 있는 AWS 관리형 Amazon EC2 인스턴스에서 시작됩니다. 트래픽은 AWS 내부 네트워크를 통해 이동하며 퍼블릭 인터넷을 통과하지 않습니다. 자세한 내용은 Amazon Web Services 웹 사이트의 Amazon VPC FAQ를 참조하세요.

고객 관리형 네트워크 경로를 사용하면 소스 서브넷을 선택하여 대상과 다른 가용 영역에서 확인을 실행할 수 있습니다. 자세한 내용은 교차 가용 영역 모니터링 섹션을 참조하세요.

AWS 관리형 및 고객 관리형 네트워크 경로

애플리케이션 상태 확인은 상태 확인 ENI의 소스 서브넷 및 보안 그룹과 대상 인스턴스의 대상 서브넷 및 보안 그룹을 선택하는 사용자를 결정하는 두 가지 온보딩 모드를 지원합니다.

생성 명령에 --health-check-paths 파라미터를 포함하거나 생략하여 모드를 선택합니다. --health-check-paths 파라미터를 생략하면 AWS가 소스 및 대상 서브넷과 보안 그룹(AWS 관리형 네트워크 경로)을 선택합니다. --health-check-paths 파라미터를 포함하는 경우 해당 파라미터를 관리합니다(고객 관리형 네트워크 경로).

IP 버전

각 애플리케이션 상태 확인은 단일 IP 버전(IPv4 또는 IPv6)과 연결됩니다. IPv4와 IPv6 모두를 통해 인스턴스를 모니터링하려면 두 개의 개별 애플리케이션 상태 확인을 생성하고 둘 다 인스턴스와 연결합니다.

IPv4와 IPv6 모두에 대해 VPC 내에서 인스턴스에 도달하는지 확인합니다.

상태 값 확인

각 개별 확인은 다음 상태 중 하나를 보고합니다.

인스턴스에 대해 보고된 전체 애플리케이션 상태는 모든 개별 검사 결과를 집계합니다. 전체 상태는 다음 중 하나입니다.

집계

각 애플리케이션 상태 확인을 인스턴스의 전체 상태에 포함되거나 제외됨으로 표시할 수 있습니다. 기본적으로 검사는 included입니다.

애플리케이션 상태 확인 시작하기

사전 조건

애플리케이션 상태 확인을 생성하기 전에 다음이 있는지 확인합니다.

1단계: 애플리케이션 구성

확인을 생성할 때 지정할 포트 및 HTTP 경로의 HTTP 또는 HTTPS 요청에 응답하도록 애플리케이션 엔드포인트를 구성합니다. 상태 코드 매처에 포함된 응답 코드를 반환하여 애플리케이션이 정상임을 나타냅니다.

대상 인스턴스의 보안 그룹이 애플리케이션 상태 확인에서 사용하는 소스 보안 그룹으로부터 확인 포트로 들어오는 인바운드 트래픽을 허용하는지 확인합니다. 관리형 네트워크 경로의 경우 AWS는 확인 생성 시 소스 보안 그룹을 제공합니다. 고객 관리형 네트워크 경로의 경우 확인을 생성할 때 소스 보안 그룹을 지정합니다.

2단계: 확인 정의 생성

AWS CLI를 사용하여 애플리케이션 상태 확인을 생성합니다.

Console

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창의 인스턴스에서 애플리케이션 상태 확인을 선택합니다.

3. 애플리케이션 상태 확인 생성을 선택합니다.

4. 상태 확인 로직에서 다음을 구성합니다.

   • 프로토콜: HTTP 또는 HTTPS를 선택합니다.

   • 포트: 애플리케이션이 수신 대기하는 포트를 입력합니다.

   • 경로(선택 사항): /healthcheck와 같이 요청할 HTTP 경로를 입력합니다.

   • IP 버전: IPv4 또는 IPv6을 선택합니다.

   • 디바이스 인덱스: 확인할 네트워크 인터페이스 디바이스 인덱스입니다. 기본값은 0입니다.

5. 제어 및 임계값에서 제한 시간을 설정하고 선택적으로 상태 코드 매처, 실패 임계값, 성공 임계값 및 초기화 유예 기간을 설정합니다. 확인 간격은 60초로 고정됩니다.

6. 집계에서 확인에 포함을 선택하여 전체 애플리케이션 상태에 기여하고 Amazon EC2 Auto Scaling을 구동하거나 제외를 선택하여 전체 상태에 영향을 주지 않고 확인을 보고합니다.

7. 상태 확인 경로에서 네트워크 경로 지정 안 함(권장/기본값)을 유지하여 Amazon EC2가 상태 확인 네트워크 인터페이스를 인스턴스의 서브넷에 배치하도록 하거나 네트워크 경로 지정(고급)을 선택하여 소스 서브넷, 보안 그룹 및 대상을 직접 정의합니다.

8. (선택 사항) 이름 태그 및 기타 태그를 추가합니다.

9. 애플리케이션 상태 확인 생성을 선택합니다.

AWS CLI

AWS 관리형 네트워크 경로를 사용하려면 --health-check-paths 파라미터를 생략하고 AWS가 소스 및 대상 서브넷과 보안 그룹을 선택합니다.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200"

고객 관리형 네트워크 경로를 사용하려면 --health-check-paths 파라미터를 포함합니다. 각 상태 확인 경로에는 소스(상태 확인 ENI의 서브넷 및 보안 그룹)와 하나 이상의 대상(대상 인스턴스의 서브넷 및 보안 그룹)이 포함됩니다.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-111","SecurityGroupId":"sg-aaa"},"Destinations":[{"SubnetId":"subnet-222","SecurityGroupId":"sg-bbb"}]}]'

3단계: 확인을 인스턴스와 연결

인스턴스 ID 또는 태그별로 모니터링할 인스턴스와 확인을 연결합니다.

Console

1. 탐색 창의 인스턴스에서 애플리케이션 상태 확인을 선택하고 확인을 선택합니다.

2. 상태 확인 연결 관리를 선택한 다음 리소스 ID로 연결 관리 또는 태그로 연결 관리를 선택합니다.

3. Auto Scaling 그룹의 모든 인스턴스와 연결하려면 태그별로 연결 관리를 선택하고 aws:autoscaling:groupName을 태그 키로 입력하고 Auto Scaling 그룹 이름을 값으로 입력합니다.

4. 연결을 선택합니다.

AWS CLI

인스턴스 ID 기준:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

태그 기준:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=Environment,Value=production

Auto Scaling 그룹의 모든 인스턴스와 연결하려면 aws:autoscaling:groupName 시스템 태그를 사용합니다.

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=aws:autoscaling:groupName,Value=my-asg

연결 및 연결 해제 작업은 인스턴스당 성공 및 실패 결과를 반환합니다. 일부 인스턴스를 연결할 수 없는 경우(예: 검사가 이미 연결되어 있기 때문에) 해당 인스턴스는 실패한 결과에 이유와 함께 표시됩니다.

4단계: 결과 보기

인스턴스별 애플리케이션 상태를 확인합니다.

Console

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 인스턴스를 선택합니다.

3. 인스턴스를 선택한 후 상태 및 경보 탭을 선택합니다.

4. 애플리케이션 상태 확인에서 전체 상태 및 연결된 각 확인의 개별 상태를 검토합니다.

AWS CLI

aws ec2 describe-application-status \
        --instance-ids i-0123456789abcdef0

응답에는 전체 애플리케이션 상태가 포함되며, 연결된 각 확인에 대해서는 확인 상태가, 실패한 확인에 대해서는 애플리케이션이 반환한 HTTP 상태 코드가 포함됩니다.

응답 예제:

{
        "ApplicationStatuses": [
            {
                "InstanceId": "i-0123456789abcdef0",
                "ApplicationStatus": {
                    "Status": "ok",
                    "Details": [
                        {
                            "ApplicationStatusCheckId": "asc-1234567890abcdef0",
                            "Status": "passed",
                            "Reason": {
                                "Code": "ResponseCodeMatched",
                                "StatusCode": 200,
                                "Protocol": "HTTP"
                            }
                        }
                    ]
                }
            }
        ]
    }

확인 정의(인스턴스당 상태가 아님)를 보려면 describe-application-status-checks를 사용합니다. 이 명령은 프로토콜, 포트, HTTP 경로 및 상태 코드 매처 설정을 포함하여 애플리케이션 상태 확인의 구성을 반환합니다.

구성 옵션

애플리케이션 상태 확인은 여러 구성 파라미터를 허용합니다. 이 섹션에서는 파라미터 이름만으로는 동작을 명확하게 알기 어려운 파라미터에 대해 설명합니다. 파라미터 및 검증 규칙의 전체 목록은 Amazon EC2 API 참조의 CreateApplicationStatusCheck 및 AssociateApplicationStatusCheck를 참조하세요.

평가 임계값

시작 유예 기간

IP 범위

디바이스 인덱스

집계, IP 버전 및 상태 확인 경로(소스 및 대상 서브넷 및 보안 그룹)는 이 페이지의 앞부분에 있는 자체 섹션에서 다룹니다.

기본 설정

AWS 관리형 네트워크 경로에서 애플리케이션 상태 확인은 다음 기본값을 사용합니다.

Amazon EC2 Auto Scaling 통합

Amazon EC2 Auto Scaling은 확인이 집계에 포함되는 한 전체 애플리케이션 상태가 impaired를 보고하는 인스턴스를 자동으로 종료하고 교체합니다. 애플리케이션 상태 확인을 그룹의 인스턴스와 연결하는 것 외에는 Auto Scaling 그룹 구성이 필요하지 않습니다.

Amazon EC2 Auto Scaling은 개별 확인 상태가 아닌 인스턴스의 전체 상태를 사용합니다. excluded으로 표시된 확인은 Amazon EC2 Auto Scaling 작업을 트리거하지 않습니다. suppressed 상태의 확인은 Amazon EC2 Auto Scaling 작업을 트리거하지 않습니다.

검사의 InitializationGracePeriodSeconds 파라미터를 사용하여 애플리케이션 상태 확인이 시작되기 전에 새 인스턴스를 시작할 시간을 허용합니다. 유예 기간이 너무 짧으면 애플리케이션이 트래픽을 처리할 준비가 되기 전에 Amazon EC2 Auto Scaling이 새 인스턴스를 종료하고 교체할 수 있습니다.

확인의 InitializationGracePeriodSeconds는 인스턴스가 시작된 후 확인이 애플리케이션 평가를 시작하기까지 걸리는 시간을 설정합니다. 애플리케이션의 시작 시간을 포함하도록 설정하여 애플리케이션이 아직 시작되는 동안 확인에서 impaired가 보고되지 않도록 합니다. Auto Scaling 그룹의 상태 확인 유예 기간은 별도로 설정됩니다. 인스턴스가 서비스 상태로 전환된 후 상태 확인에 실패하여 Amazon EC2 Auto Scaling이 해당 인스턴스를 종료하기까지의 시간을 설정합니다.

Amazon EC2 Auto Scaling에서 상태 확인을 사용하는 방법에 대한 자세한 내용은 Auto Scaling 그룹의 인스턴스 상태 확인 및 Auto Scaling 그룹에서 애플리케이션 상태 확인 사용(Amazon EC2 Auto Scaling 사용 설명서)을 참조하세요.

배포, 인플레이스 패치 적용 및 교체 처리

배포, 인플레이스 패치 및 기타 유지 관리 작업은 애플리케이션을 일시적으로 중지하거나 다시 시작할 수 있습니다. 이 기간 동안 애플리케이션이 상태 확인 요청에 응답할 수 없기 때문에 애플리케이션 상태 확인은 실패를 보고합니다. 인스턴스가 집계에 애플리케이션 상태 확인이 포함된 Auto Scaling 그룹에 있는 경우 Amazon EC2 Auto Scaling은 중단이 예상되더라도 이러한 인스턴스를 종료하고 교체할 수 있습니다.

옵션 A: 확인 억제

기간을 알고 있는 제한된 유지 관리 기간에는 억제를 사용합니다. 억제는 인스턴스 수준에서 적용됩니다. 기간을 지정하거나, 억제를 비활성화할 때까지 확인을 억제하려면 기간을 생략할 수 있습니다.

AWS CLI

aws ec2 enable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0 \
        --duration-seconds 3600

응답에는 각 인스턴스별로 억제가 시작된 시점과 종료될 시점이 반환됩니다. 일부만 성공할 수 있습니다. 일부 인스턴스에는 억제가 적용되지 않을 수 있으며, 이 경우 해당 인스턴스와 그 이유가 응답에 표시됩니다.

억제 기간이 만료되기 전에 확인을 다시 시작하려면:

aws ec2 disable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0

억제가 적용되는 동안 인스턴스의 전체 애플리케이션 상태는 suppressed으로 보고됩니다. Amazon EC2 Auto Scaling은 suppressed 인스턴스에서 작동하지 않습니다.

옵션 B: 집계에서 확인 제외

확인에서 개별 상태를 계속 평가 및 보고하지만 전체 상태에 영향을 미치거나 Amazon EC2 Auto Scaling 작업을 트리거하지 않으려면 확인의 집계 설정을 excluded으로 설정합니다. 이는 새 확인 버전을 롤아웃하거나 교체 위험 없이 변경 사항을 검증하는 등 장기간 지속되는 시나리오와, 운영에 영향을 주지 않으면서 원격 측정을 계속하려는 경우에 유용합니다.

자세한 내용은 집계 섹션을 참조하세요.

옵션 C: 확인 연결 해제

장기간 또는 무기한 제거하려면 연결 해제를 사용합니다.

aws ec2 disassociate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

태그별로 연결한 경우 인스턴스에서 태그를 제거하여 연결을 해제합니다. 연결 해제 후 인스턴스의 전체 애플리케이션 상태는 not-applicable을 보고합니다.

배포 지침

배포는 억제가 필요한 가장 일반적인 유지 관리 시나리오입니다. 배포 도구에 배포 전 후크와 배포 후 후크가 있는 경우 억제를 사용하면 배포가 시작되기 전에 확인을 억제하고 배포가 완료된 후 억제를 비활성화할 수 있습니다.

일반적인 패턴은 다음과 같습니다.

배포 도구에 후크가 없는 경우 배포를 호출하는 CI/CD 파이프라인에서 억제를 유도합니다.

새 애플리케이션 상태 확인 테스트

인스턴스 수준 모니터링에 기여하기 전에 프로덕션 환경에서 새 애플리케이션 상태 확인을 검증할 수 있습니다. 검사를 생성할 때 집계 설정을 excluded으로 설정한 다음 예상 상태 및 HTTP 응답 코드를 보고하는지 확인합니다. 준비가 되면 설정을 included으로 변경하여 확인이 인스턴스의 전체 상태에 기여하고 Amazon EC2 Auto Scaling과 통합되도록 합니다.

고급 네트워킹

애플리케이션 상태 확인은 사용자가 지정한 소스 서브넷과 보안 그룹(또는 AWS가 자동으로 선택한 항목)의 관리형 ENI에서 시작됩니다. 단일 소스 구성이 제공하는 것보다 더 높은 가용성이 필요한 워크로드 또는 로컬 영역이나 Outposts에서 실행되는 워크로드의 경우 다음 패턴을 고려하세요.

교차 가용 영역 모니터링

가용 영역 중복성을 위해 둘 이상의 가용 영역에서 상태 확인을 실행할 수 있습니다. 고객 관리형 네트워크 경로를 사용하면 --health-check-paths 파라미터를 사용하여 소스가 서로 다른 두 가용 영역에 있으면서 동일한 대상 인스턴스에 도달하는 상태 확인 경로를 정의합니다. 두 가용 영역에서 모니터링하면 가용 영역 하나를 사용할 수 없게 되더라도 인스턴스에 대한 상태 보고를 지속적으로 유지할 수 있습니다.

다음 예제에서는 소스가 서로 다른 가용 영역에 있고 둘 다 동일한 대상 인스턴스에 도달하는 상태 확인 경로 2개를 사용하여 확인을 생성합니다.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-source-az1","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az1","SecurityGroupId":"sg-app"}]},{"Source":{"SubnetId":"subnet-source-az2","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az2","SecurityGroupId":"sg-app"}]}]'

로컬 영역

AWS 로컬 영역에서 실행되는 인스턴스의 경우 관리형 탄력적 네트워크 인터페이스(ENI)는 로컬 영역이 아닌 상위 AWS 리전에 있습니다. 상위 리전과 로컬 영역 인스턴스 간의 상태 확인 트래픽은 로컬 영역 서비스 링크를 통과하므로 추가 데이터 전송 요금이 발생할 수 있습니다.

모범 사례

문제 해결

애플리케이션 상태 확인에서 손상된 것으로 보고되었지만 애플리케이션이 정상일 것으로 예상되는 경우 다음 각 항목을 확인합니다.

사유 코드

describe-application-status 응답에는 각 확인에 대한 이유가 포함됩니다. 이유에는 애플리케이션이 반환한 HTTP 상태 코드(숫자 형식)와 확인에 사용된 프로토콜이 포함됩니다. 반환된 상태 코드가 상태 코드 매처에 포함된 경우 확인이 passed으로 표시되고, 그렇지 않은 경우 failed으로 표시됩니다.

이유에는 이유 코드와 HTTP 수준 결과의 경우 프로토콜 및 반환된 HTTP 상태 코드도 포함됩니다. 이유에는 다음 필드가 포함됩니다.

반환된 HTTP 상태 코드를 사용하여 확인이 실패한 이유를 식별합니다. 몇 가지 일반적인 예는 다음과 같습니다.

전체 ApplicationStatusReason 구조는 Amazon EC2 API 참조의 ApplicationStatusReason을 참조하세요.

일반적인 실수

애플리케이션 상태 확인 모니터링

다음 세 가지 방법으로 애플리케이션 상태 확인을 모니터링할 수 있습니다.

경보 기반 자동화에 CloudWatch 지표를 사용합니다. 인스턴스 상태를 이미 쿼리하는 경우 describe-instance-status를 사용합니다. 자세한 확인별 가시성을 위해 describe-application-status를 사용합니다.

보안 및 권한

AWS는 서비스 연결 역할을 통해 애플리케이션 상태 확인에 사용되는 네트워크 인터페이스를 생성하고 관리합니다. 서비스가 이러한 ENI를 생성하는 데 IAM 설정이 필요하지 않습니다. 서비스 연결 역할은 EC2ApplicationStatusChecksServiceRolePolicy AWS 관리형 정책을 사용합니다.

애플리케이션 상태 확인을 직접 생성, 연결, 설명, 삭제 및 억제하려면 IAM 사용자 또는 역할에 해당 Amazon EC2 권한이 필요합니다. 전체 작업 목록은 Amazon EC2 API 참조를 참고하세요.

인스턴스의 보안 그룹은 구성한 포트에서 상태 확인 소스 보안 그룹의 인바운드 트래픽을 허용해야 합니다. AWS 관리형 네트워크 경로의 경우 AWS가 소스 보안 그룹을 제공합니다. 고객 관리형 네트워크 경로의 경우 소스로 지정한 보안 그룹을 사용합니다.

가격 책정

애플리케이션 상태 확인은 다음 구성 요소에 대해 청구됩니다.

할당량

애플리케이션 상태 확인에는 AWS 서비스 할당량이 적용됩니다. 할당량 이름, 기본값 및 설명은 AWS 일반 참조의 Amazon EC2 엔드포인트 및 할당량을 참조하세요.

관리형 네트워크 인터페이스에 영향을 미치는 AWS 서비스 할당량 외에도 애플리케이션 상태 확인에는 다음과 같은 서비스 할당량이 있습니다. Service Quotas 콘솔에서 사용량을 확인하고 할당량 증가를 요청할 수 있습니다.

이러한 할당량에서 대상은 하나의 상태 확인이 모니터링하는 단일 인스턴스입니다. 하나 이상의 상태 확인이 인스턴스를 모니터링하는 경우 각 인스턴스와 상태 확인 페어링은 별도의 대상으로 계산됩니다. 연결은 상태 확인과 연결하는 단일 태그 규칙 또는 단일 인스턴스 ID입니다. 각 규칙 또는 인스턴스 ID는 확인되는 인스턴스 수에 관계없이 하나의 연결로 계산됩니다.

대부분의 할당량 증가 요청은 자동으로 승인됩니다. 계정당 대상 할당량을 늘리려면 요청 및 수동 승인이 필요합니다.

할당량에 도달하기 전에 알림을 받을 수 있도록 애플리케이션 상태 확인의 할당량 사용량에 대해 Amazon CloudWatch 경보를 생성하는 것이 좋습니다. Service Quotas는 CloudWatch의 AWS/Usage 네임스페이스에 사용량 지표를 게시하며, 이 지표를 사용하여 경보를 생성할 수 있습니다.