기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Route 53 상태 확인 생성 Amazon Route 53 상태 확인은 웹 애플리케이션, 웹 서버, 기타 리소스의 상태와 성능을 모니터링합니다. 상태 확인을 각각 생성하여 다음 중 하나를 모니터링할 수 있습니다. + 지정한 리소스(예: 웹 서버)의 상태 + 다른 상태 확인의 상태 + Amazon CloudWatch 경보 상태입니다. + 또한 Amazon Application Recovery Controller(ARC)를 사용하면 DNS 장애 조치 레코드로 라우팅 제어 상태 확인을 설정하여 애플리케이션의 트래픽 장애 조치를 관리할 수 있습니다. 자세한 내용은 [Amazon Application Recovery Controller(ARC) 개발자 안내서](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route-53-recovery.html)를 참조하세요. 상태 확인 유형에 대한 개요는 [Amazon Route 53 상태 확인 유형상태 확인의 유형](health-checks-types.md) 섹션을 참조하세요. 상태 확인 생성에 대한 정보는 다음([상태 확인의 생성 및 업데이트](health-checks-creating.md))을 참조하십시오. 상태 확인을 생성하면 상태 확인의 상태를 받고, 상태가 변경될 때 알림을 받으며, DNS 장애 조치를 구성할 수 있습니다. **상태 확인 상태 및 경보 받기** Route 53 콘솔에서 상태 확인의 현재 및 최근 상태를 볼 수 있습니다. AWS SDKs AWS Command Line Interface AWS Tools for Windows PowerShell, 또는 Route 53 API 중 하나를 통해 프로그래밍 방식으로 상태 확인을 사용할 수도 있습니다. 상태 확인의 상태가 변경될 때 알림을 받고 싶을 경우, 각 상태 확인에 대해 Amazon CloudWatch 경보를 구성할 수 있습니다. 상태 확인의 상태를 보고 알림을 받는 것에 대한 정보는 다음([상태 확인의 상태 모니터링 및 알림 수신](health-checks-monitor-view-status.md))을 참조하십시오. **DNS 장애 조치 구성** 동일한 기능을 수행하는 리소스가 여러 개 있을 경우, Route 53가 비정상 리소스의 트래픽을 정상 리소스로 라우팅하도록 DNS 장애 조치를 구성할 수 있습니다. 예를 들어 웹 서버가 2개일 경우 그 중 하나의 상태가 좋지 않으면 Route 53가 트래픽을 다른 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 [DNS 장애 조치 구성](dns-failover-configuring.md) 단원을 참조하십시오. **Topics** + [Amazon Route 53 상태 확인 유형](health-checks-types.md) + [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) + [상태 확인의 생성, 업데이트 및 삭제](health-checks-creating-deleting.md) + [DNS 장애 조치 구성](dns-failover-configuring.md) + [상태 확인에 대한 이름 및 태그 지정](health-checks-tagging.md) + [Amazon Route 53 API가 2012-12-12 이전 버전인 상태 확인 사용하기](dns-failover-using-old-apis.md) # Amazon Route 53 상태 확인 유형 다음과 같은 유형의 Amazon Route 53 상태 확인을 생성할 수 있습니다. **엔드포인트를 모니터링하는 상태 확인** IP 주소나 도메인 이름으로 지정한 엔드포인트를 모니터링하는 상태 확인을 구성할 수 있습니다. Route 53는 지정한 간격에 따라 규칙적으로 인터넷을 통해 애플리케이션, 서버 또는 다른 리소스로 자동화된 요청을 제출하여 연결 및 사용이 가능하고 정상적으로 작동되는지 확인합니다. 또한, 사용자가 특정 URL의 웹 페이지 요청 등과 같은 요청을 할 때 해당 요청과 비슷한 요청을 만들도록 상태 확인을 구성할 수도 있습니다. **다른 상태 확인을 모니터링하는 상태 확인(계산된 상태 확인)** Route 53에서 다른 상태 확인의 상태를 정상으로 여기는지 아니면 비정상으로 여기는지를 모니터링하는 상태 확인을 생성할 수 있습니다. 이 기능은 예를 들어, 웹 서버 등과 같이 동일한 기능을 수행하는 리소스가 여러 개일 때 상태가 좋은 리소스의 최소 개수를 어느 수준 이상으로 유지하려 할 경우 유용합니다. 그러한 상태 확인의 알림을 구성하지 않고도 각 리소스의 상태 확인을 생성할 수 있습니다. 그런 다음, 다른 상태 확인의 상태를 모니터링하여 사용 가능한 웹 리소스 개수가 지정한 임계값 미만으로 떨어질 경우에만 알림을 보내는 상태 확인을 생성할 수 있습니다. **CloudWatch 경보를 모니터링하는 상태 확인** CloudWatch 지표(Amazon DynamoDB 데이터베이스에 대해 병목 현상이 발생한 읽기 이벤트 수, 정상으로 간주되는 Elastic Load Balancing 호스트 수 등)의 상태를 모니터링하는 CloudWatch 경보를 생성할 수 있습니다. 경보를 생성하면 해당 경보에 대해 CloudWatch에서 모니터링하는 데이터 스트림과 동일한 데이터 스트림을 모니터링하는 상태 확인을 생성할 수 있습니다. 복원성과 가용성을 높이기 위해 Route 53는 CloudWatch 경보가 `ALARM` 상태가 될 때까지 기다리지 않습니다. 상태 확인의 상태는 데이터 스트림에 따라 그리고 CloudWatch 경보의 기준에 따라 정상에서 비정상으로 변경됩니다. Route 53는 다음과 같은 CloudWatch 경보를 지원합니다. + 표준 분해능 지표. 고분해능 지표는 지원되지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [고해상도 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)를 참조하세요. + 통계: Average, Minimum, Maximum, Sum, SampleCount. 확장된 통계는 지원되지 않습니다. + Route 53는 “N 중 M” 경보를 지원하지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [경보 평가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)를 참조하세요. + 상태 확인은 상태 확인과 동일한 AWS 계정에 있는 CloudWatch 경보만 모니터링할 수 있습니다. + Route 53는 [지표 수식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 사용하여 여러 CloudWatch 지표를 쿼리하는 경보를 지원하지 않습니다. **Amazon Application Recovery Controller(ARC)의 라우팅 제어** ARC의 상태 확인은 간단한 켜기/끄기 스위치인 라우팅 컨트롤과 연결됩니다. 장애 조치 DNS 레코드를 사용하여 각 라우팅 컨트롤 상태 확인을 구성합니다. 그런 다음 ARC에서 라우팅 제어를 업데이트하여 트래픽을 다시 라우팅하고 가용 영역 또는 AWS리전 간에 애플리케이션을 장애 조치할 수 있습니다. 자세한 내용은 ARC 개발자 안내서의 [ARC의 라우팅 제어](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.html)를 참조하세요. # Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법 Amazon Route 53에서 상태 확인이 정상인지 여부를 결정하는 데 사용하는 방법은 상태 확인 유형에 따라 다릅니다. ## Route 53에서 엔드포인트를 모니터링하는 상태 확인의 상태를 판단하는 방법 Route 53는 전 세계 곳곳에 상태 확인 프로그램을 두고 있습니다. 엔드포인트를 모니터링하는 상태 확인을 생성하면 상태 확인 프로그램에서는 엔드포인트가 정상인지 확인하기 위해 지정하는 엔드포인트로 요청을 보내기 시작합니다. Route 53가 사용하도록 할 위치를 선택할 수 있고, 확인 사이의 간격을 10초마다 또는 30초마다로 지정할 수 있습니다. 다른 데이터 센터에 있는 Route 53 상태 확인 프로그램은 상호 연계되지 않으므로 선택한 간격에 상관 없이 초당 여러 번의 요청이 표시되는 경우도 있고 몇 초 동안 상태 확인이 없는 경우도 있습니다. 각각의 상태 확인 프로그램은 다음 두 가지 값을 기준으로 엔드포인트의 상태를 평가합니다. + 응답 시간. 여러 가지 이유로 리소스의 응답 속도가 느리거나 상태 확인 요청에 응답하지 못할 수 있습니다. 예를 들어 리소스가 유지 관리를 위해 종료되거나, DDoS(Distributed Denial of Service) 공격을 받고 있거나, 네트워크가 다운되었을 수 있습니다. + 엔드포인트가 사용자가 지정한 다수의 연속적인 상태 확인(장애 임계값)에 응답하는지 여부 Route 53는 상태 확인 프로그램에서 데이터를 집계하여 엔드포인트가 정상인지 확인합니다. + 상태 확인 프로그램의 18% 이상이 엔드포인트가 정상이라고 보고하는 경우 Route 53는 엔드포인트가 정상이라고 간주합니다. + 상태 확인 프로그램의 18% 미만이 엔드포인트가 정상이라고 보고하는 경우 Route 53는 엔드포인트가 비정상이라고 간주합니다. 여러 리전에 있는 상태 확인 프로그램이 엔드포인트가 정상이라고 간주하도록 보장하기 위해 18%라는 값을 선택했습니다. 이에 따라 네트워크 상태로 인해 엔드포인트가 일부 상태 확인 중인 위치에서 격리되었다는 이유만으로 엔드포인트가 비정상인 것으로 간주되는 상황이 방지됩니다. 이 값은 향후 릴리스에서는 달라질 수 있습니다. 개별 상태 확인 프로그램이 엔드포인트가 정상인지 확인하는 데 사용하는 응답 시간은 상태 확인의 유형에 따라 다릅니다. + **HTTP 및 HTTPS 상태 확인(HTTP and HTTPS health checks)** - Route 53는 반드시 4초 안에 엔드포인트와의 TCP 연결을 설정해야 합니다. 뿐만 아니라 엔드포인트는 연결 후 2초 내에 2xx 또는 3xx의 HTTP 상태 코드와 반응해야 합니다. **참고** HTTPS 상태 확인은 SSL/TLS 인증서를 검증하지 않으므로 인증서가 유효하지 않거나 만료된 경우에도 검사가 실패하지 않습니다. + **TCP 상태 확인(TCP health checks)** - Route 53는 반드시 10초 안에 엔드포인트와의 TCP 연결을 설정해야 합니다. + **문자열 매치로 HTTP 및 HTTPS 상태 확인(HTTP and HTTPS health checks with string matching)** - HTTP 및 HTTPS 상태 확인과 마찬가지로 Route 53는 4초 내에 엔드포인트와의 TCP 연결을 설정해야 하고, 엔드포인트는 연결 후 2초 내에 2xx 또는 3xx의 HTTP 상태 코드와 반응해야 합니다. Route 53 상태 확인 프로그램은 HTTP 상태 코드를 수신한 후 2초 내에 엔드포인트로부터 오는 응답의 본문을 수신해야 합니다. Route 53는 지정한 문자열을 찾기 위해 응답의 본문을 검색합니다. 문자열은 응답 본문의 최초 5,120바이트 내에서 모두 나타나야 합니다. 그렇지 않으면 엔드포인트는 상태 확인에 실패합니다. Route 53 콘솔을 사용한다면, **문자열 검색(Search String)** 필드에서 문자열을 지정합니다. Route 53 API를 사용한다면, 상태 확인을 생성할 때 `SearchString` 요소에서 문자열을 지정합니다. 엔드포인트를 모니터링하는 상태 확인(TCP 상태 확인 제외)의 경우, 엔드포인트로부터의 응답에 헤더가 포함되어 있으면 헤더가 RFC7230, Hypertext Transfer Protocol(HTTP/1.1): Message Syntax and Routing의 [섹션 3.2, "Header Fields"](https://tools.ietf.org/html/rfc7230#section-3.2)에 정의된 형식을 따라야 합니다. Route 53에서는 실제 상태가 정상인지 비정상인지를 결정할 수 있는 충분한 데이터가 생길 때까지 새로운 상태 확인을 정상으로 간주합니다. 상태 확인 상태를 반전하는 옵션을 선택한 경우 Route 53에서 충분한 데이터가 생길 때까지 새로운 상태 확인을 *비정상(unhealthy)*으로 간주합니다. ## Route 53에서 기타 상태 확인을 모니터링하는 상태 확인의 상태를 판단하는 방법 상태 확인은 다른 상태 확인의 상태를 모니터링할 수 있습니다. 이러한 유형의 상태 확인을 *계산된 상태 확인*이라 합니다. 모니터링을 수행하는 상태 확인을 *상위 상태 확인*이라 하며, 모니터링 대상인 상태 확인을 *하위 상태 확인*이라 합니다. 하나의 상위 상태 확인은 최대 255개의 하위 상태 확인을 모니터링할 수 있습니다. 모니터링 작동 방식은 다음과 같습니다. + Route 53가 정상으로 간주되는 하위 상태 확인의 수를 합산합니다. + Route 53는 정상으로 간주되는 상위 상태 확인의 상태에 대해 정상이어야 하는 하위 상태 확인의 수와 위에서 합산한 수를 비교합니다. 자세한 설명은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md)에서 [다른 상태 확인 모니터링(계산된 상태 확인)](health-checks-creating-values.md#health-checks-creating-values-calculated) 섹션을 참조하세요. Route 53에서는 실제 상태가 정상인지 비정상인지를 결정할 수 있는 충분한 데이터가 생길 때까지 새로운 상태 확인을 정상으로 간주합니다. 상태 확인 상태를 반전하는 옵션을 선택한 경우 Route 53에서 충분한 데이터가 생길 때까지 새로운 상태 확인을 *비정상(unhealthy)*으로 간주합니다. ## Route 53에서 CloudWatch 경보를 모니터링하는 상태 확인의 상태를 판단하는 방법 CloudWatch 경보를 기반으로 상태 확인을 생성하면 Route 53는 경보 상태를 모니터링하는 대신 해당 경보의 데이터 스트림을 모니터링합니다. 데이터 스트림이 가리키는 경보 상태가 **확인**이면 상태 확인은 정상으로 간주합니다. 데이터 스트림이 가리키는 경보 상태가 **경보**면 상태 확인은 이상 있음으로 간주합니다. 데이터 스트림이 경보 상태를 판단하기에 충분한 정보를 제공하지 않을 경우, 상태 확인의 상태는 **상태 확인의 상태**의 설정, 즉 정상, 이상 있음, 마지막으로 알려진 상태 중 하나에 따라 결정됩니다. (Route 53 API에서 이 설정은 `InsufficientDataHealthStatus`입니다.) Route 53는 교차 계정 CloudWatch 경보를 지원하지 않습니다. **참고** Route 53 상태 확인은 CloudWatch 경보 상태 대신 CloudWatch 데이터 스트림을 모니터링하므로 CloudWatch [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) API 작업을 사용하여 상태 확인의 상태를 강제로 변경할 수 없습니다. Route 53에서는 실제 상태가 정상인지 비정상인지를 결정할 수 있는 충분한 데이터가 생길 때까지 새로운 상태 확인을 정상으로 간주합니다. 상태 확인 상태를 반전하는 옵션을 선택한 경우 Route 53에서 충분한 데이터가 생길 때까지 새로운 상태 확인을 *비정상(unhealthy)*으로 간주합니다. # 상태 확인의 생성, 업데이트 및 삭제 **중요** 레코드와 연결된 상태 확인을 업데이트 또는 삭제하는 경우 작업을 수행하기 전에 먼저 [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md)의 작업을 검토합니다. 이 섹션에서는 Route 53 상태 확인 관리와 관련된 다음 주제를 다룹니다. 1. **상태 확인의 생성 및 업데이트:** + Route 53 콘솔을 사용하여 상태 확인을 생성하고 업데이트하는 방법을 알아봅니다. + 엔드포인트 모니터링, 프로토콜, IP 주소, 도메인 이름, 고급 구성 옵션 등 상태 확인을 생성하거나 업데이트할 때 지정해야 하는 값을 이해합니다. 1. **상태 확인을 생성할 때 표시되는 값:** + 전체 URL 또는 IP 주소 및 포트와 같이 상태 확인을 생성할 때 Route 53 콘솔이 입력에 따라 표시하는 값을 알아봅니다. 1. **CloudWatch 경보 변경에 대한 상태 확인 업데이트:** + 연결된 CloudWatch 경보의 설정을 변경할 때 상태 확인을 업데이트하는 방법을 알아봅니다. 1. **상태 확인 삭제: ** + 절차에 따라 Route 53 콘솔을 사용하여 상태 확인을 삭제합니다. 1. **DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제:** + DNS 레코드와 연결된 상태 확인을 업데이트하거나 삭제할 때 수행해야 하는 권장 작업을 파악하여 라우팅 및 장애 조치 구성이 적절한지 확인합니다. 1. **라우터 및 방화벽 규칙 구성:** + Route 53 상태 확인 프로그램의 인바운드 트래픽을 허용하도록 라우터 및 방화벽 규칙을 구성하여 성공적인 상태 확인을 보장하는 방법을 이해합니다. 이 섹션에 제공된 정보를 따르면 Route 53 상태 확인을 효과적으로 생성, 업데이트 및 삭제하고, 구성을 관리하고, DNS 장애 조치 및 라우팅 정책과 적절하게 통합되게 할 수 있습니다. **Topics** + [상태 확인의 생성 및 업데이트](health-checks-creating.md) + [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md) + [상태 확인 생성 시 Amazon Route 53가 표시하는 값](health-checks-creating-values-displayed.md) + [CloudWatch 경보 설정 변경 시 상태 확인 업데이트(CloudWatch 경보만 모니터링하는 상태 확인)](health-checks-updating-cloudwatch-alarm-settings.md) + [상태 확인 비활성화 또는 활성화](health-checks-disable.md) + [상태 확인 반전](health-checks-invert.md) + [상태 확인 삭제](health-checks-deleting.md) + [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md) + [Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성](dns-failover-router-firewall-rules.md) # 상태 확인의 생성 및 업데이트 다음 절차에서는 Route 53 콘솔을 이용해 상태 확인을 생성하고 업데이트하는 방법을 설명합니다. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-creating-new) + [이전 콘솔](#health-checks-creating-old) ------ #### [ New console ] **상태 확인을 생성 또는 업데이트하려면** 1. 이미 레코드와 연결된 상태 확인을 업데이트하는 경우 [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md)에서 권장하는 작업을 수행합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 기존의 상태 확인을 업데이트하려면 상태 확인에 연결된 ID를 선택한 다음 **편집**을 선택합니다. 상태 확인을 생성하려면 **상태 확인 생성**을 선택합니다. 1. 관련 값들을 입력합니다. 상태 확인을 생성한 후에는 일부 값들을 변경할 수 없다는 점에 유의하십시오. 자세한 내용은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md) 단원을 참조하십시오. 1. **상태 확인 생성**을 선택합니다. **참고** Route 53에서는 실제 상태가 정상인지 비정상인지를 결정할 수 있는 충분한 데이터가 생길 때까지 새로운 상태 확인을 정상으로 간주합니다. 1. 상태 확인을 하나 이상의 Route 53 레코드와 연결합니다. 레코드 생성 및 업데이트에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md)을 참조하십시오. ------ #### [ Old console ] **상태 확인을 생성 또는 업데이트하려면** 1. 이미 레코드와 연결된 상태 확인을 업데이트하는 경우 [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md)에서 권장하는 작업을 수행합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 기존의 상태 확인을 업데이트하려면, 상태 확인을 선택한 다음, [**Edit Health Check**]를 선택합니다. 상태 확인을 생성하고 싶다면, [**Create Health Check**]를 선택합니다. 라벨 위에 마우스 포인터를 대면 도움말이 표시되어 설정에 관한 자세한 내용을 볼 수 있습니다. 1. 관련 값들을 입력합니다. 상태 확인을 생성한 후에는 일부 값들을 변경할 수 없다는 점에 유의하십시오. 자세한 내용은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md) 단원을 참조하십시오. 1. [**Create Health Check**]를 선택합니다. **참고** Route 53에서는 실제 상태가 정상인지 비정상인지를 결정할 수 있는 충분한 데이터가 생길 때까지 새로운 상태 확인을 정상으로 간주합니다. 상태 확인 상태를 반전하는 옵션을 선택한 경우 Route 53에서 충분한 데이터가 생길 때까지 새로운 상태 확인을 *비정상(unhealthy)*으로 간주합니다. 1. 상태 확인을 하나 이상의 Route 53 레코드와 연결합니다. 레코드 생성 및 업데이트에 대한 자세한 내용은 [레코드 작업](rrsets-working-with.md)을 참조하십시오. ------ # 상태 확인 생성 또는 업데이트 시 지정하는 값 상태 확인을 생성 또는 업데이트할 때 적용 가능한 값을 지정합니다. 상태 확인을 생성한 후에는 일부 값들을 변경할 수 없다는 점에 유의하십시오. **Topics** + [엔드포인트 모니터링](#health-checks-creating-values-endpoint) + [다른 상태 확인 모니터링(계산된 상태 확인)](#health-checks-creating-values-calculated) + [CloudWatch 경보 모니터링](#health-checks-creating-values-cloudwatch) + [고급 구성("Monitor an endpoint" 전용)](#health-checks-creating-values-advanced) + [상태 확인 실패 시 알림 메시지를 받음](#health-checks-creating-values-alarm) **이름** 선택 사항이지만 권장되는 것: 상태 확인에 할당하고 싶은 이름. **이름(Name)**에 대한 값을 지정하면, Route 53가 상태 확인에 태그를 추가하고 태그 키에 **이름(Name)**의 값을 할당하며 지정한 값을 태그 값에 할당합니다. **이름(Name)** 태그의 값은 Route 53 콘솔의 상태 확인 목록에 표시되는데, 이는 상태 확인을 서로 쉽게 구별할 수 있게 해줍니다. 태그 지정 및 상태 확인에 대한 자세한 내용은 다음([상태 확인에 대한 이름 및 태그 지정](health-checks-tagging.md))을 참조하십시오. **모니터링할 항목** 이 상태 확인을 통해 엔드포인트 또는 다른 상태 확인의 상태를 모니터링할지 여부: + **엔드포인트(Endpoint)** - Route 53는 사용자가 지정하는 엔드포인트의 상태를 모니터링합니다. 도메인 이름 또는 IP 주소와 포트를 제공하여 엔드포인트를 지정할 수 있습니다. **참고** 비AWS 엔드포인트를 지정하는 경우 추가 요금이 적용됩니다. AWS 엔드포인트의 정의를 비롯한 자세한 내용은 [Route 53 요금(Route 53 Pricing)](https://aws.amazon.com/route53/pricing/) 페이지에서 "상태 확인" 섹션을 참조하세요. + **다른 상태 확인(계산된 상태 확인)의 상태(Status of other health checks (calculated health check))** - Route 53는 이 상태 확인이 사용자가 지정하는 다른 상태 확인의 상태를 기준으로 정상인지 판단합니다. 또한, 정상으로 간주되는 이 상태 확인에 대해 상태 확인 중 얼마나 많이 정상이어야 하는지도 지정합니다. + **CloudWatch 경보 데이터 스트림의 상태(State of CloudWatch alarm data stream)** - Route 53가 CloudWatch 경보의 데이터 스트림을 모니터링하여 이 상태 확인이 정상인지를 판단합니다. ## 엔드포인트 모니터링 **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-creating-values-endpoint-new) + [이전 콘솔](#health-checks-creating-values-endpoint-old) ------ #### [ New console ] 이 상태 확인을 통해 엔드포인트를 모니터링하려면 다음 값을 지정하십시오: + 엔드포인트 지정 기준 + IP 주소 + 도메인 이름 **엔드포인트 지정** IP 주소나 도메인 이름을 사용하여 엔드포인트를 지정할지 여부. 상태 확인을 생성한 후에는 [**Specify endpoint by**]의 값을 변경할 수 없습니다. **IP 주소(IP address)("IP 주소로 엔드포인트 지정(Specify endpoint by IP address)" 전용)** 드롭다운에서 프로토콜을 선택하고 IP 주소, 포트, 경로를 텍스트 상자에 입력합니다. + 프로토콜은 다음 중 하나일 수 있습니다. **HTTP** - Route 53가 TCP 연결을 설정하려고 시도합니다. 성공할 경우 Route 53는 HTTP 요청을 제출하고 2xx 또는 3xx의 HTTP 상태 코드를 기다립니다. + **HTTPS** - Route 53가 TCP 연결을 설정하려고 시도합니다. 성공할 경우 Route 53는 HTTPS 요청을 제출하고 2xx 또는 3xx의 HTTP 상태 코드를 기다립니다. **중요** **HTTPS**를 선택한다면 엔드포인트가 TLS v1.0, v1.1 또는 v1.2를 지원해야 합니다. **프로토콜** 값으로 **HTTPS**를 선택할 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. + **TCP** - Route 53가 TCP 연결을 설정하려고 시도합니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 단원을 참조하십시오. 상태 확인을 생성한 후에는 **프로토콜**의 값을 변경할 수 없습니다. **IP 주소**에서 **IP 주소로 엔드포인트 지정**을 선택한 경우 Route 53에서 상태 확인을 수행할 엔드포인트의 IPv4 또는 IPv6 주소를 입력합니다. Route 53는 IP 주소가 로컬, 프라이빗, 라우팅 불가, 또는 멀티캐스트 범위에 있는 엔드포인트의 상태는 확인할 수 없습니다. 상태 확인을 생성할 수 없는 IP 주소에 대한 자세한 내용은 다음 문서를 참조하십시오. + [RFC 5735, Special Use IPv4 Addresses](http://tools.ietf.org/html/rfc5735)(RFC 5735, 특수 용도 IPv4 주소) + [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](http://tools.ietf.org/html/rfc6598)(RFC 6598, IANA에서 공유 주소 공간으로 예약된 IPv4 접두사). + [RFC 5156, Special-Use IPv6 Addresses](https://tools.ietf.org/html/rfc5156)(RFC 5156, 특수 용도 IPv6 주소) 엔드포인트가 Amazon EC2 인스턴스일 경우, 탄력적 IP 주소를 생성하여 EC2 인스턴스와 연결하고 탄력적 IP 주소를 지정하는 것이 좋습니다. 이렇게 하면 인스턴스의 IP 주소가 변경되지 않습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [탄력적 IP 주소(EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 참조하세요. Amazon EC2 인스턴스를 삭제하는 경우 EIP에 연결된 상태 확인도 삭제해야 합니다. 자세한 내용은 [Amazon Route 53 상태 확인의 모범 사례](best-practices-healthchecks.md) 단원을 참조하십시오. 비AWS 엔드포인트를 지정하는 경우 추가 요금이 적용됩니다. AWS 엔드포인트의 정의를 비롯한 자세한 내용은 [Route 53 요금(Route 53 Pricing)](https://aws.amazon.com/route53/pricing/) 페이지에서 "상태 확인" 섹션을 참조하세요. **포트**의 경우 Route 53에서 상태 확인을 수행할 엔드포인트의 포트를 입력합니다. **경로(HTTP 및 HTTPS 프로토콜만 해당)**의 경우 상태 확인을 수행할 때 Route 53에서 요청할 경로를 입력합니다. 이 경로는 엔드포인트가 정상일 때, 엔드포인트가 2xx나 3xx의 HTTP 상태 코드를 반환하는 모든 값이 될 수 있습니다. 예를 들면 /docs/route53-health-check.html 파일이 여기에 해당됩니다. /welcome.html?language=jp&login=y와 같은 쿼리 문자열 파라미터를 포함할 수도 있습니다. 앞에 슬래시(/) 문자가 없으면 Route 53가 자동으로 하나 추가합니다. **도메인 이름(Domain name)("도메인 이름으로 엔드포인트 지정(Specify endpoint by domain name)" 전용, 모든 프로토콜)** **도메인 이름으로 엔드포인트 지정(Specify endpoint by domain name)**을 선택한 경우 Route 53가 상태 확인을 수행하게 하려는 엔드포인트의 도메인 이름(example.com) 또는 하위 도메인 이름(backend.example.com) 입니다. 도메인 이름으로 엔드포인트를 지정하도록 선택하는 경우, Route 53는 **도메인 이름(Domain name)**에 지정한 도메인 이름을 확인하기 위해 **요청 간격(Request interval)**에 지정한 간격으로 DNS 쿼리를 전송합니다. 그런 다음 Route 53는 DNS가 반환하는 IP 주소를 사용하여 엔드포인트의 상태를 확인합니다. 도메인 이름으로 엔드포인트를 지정하는 경우에는 Route 53가 IPv4만 사용하여 상태 확인을 엔드포인트에 전송합니다. [**Domain name**]에 지정하는 도메인 이름에 대해 A 유형의 레코드가 없는 경우에는 "DNS resolution failed" 오류와 함께 상태 확인이 중단됩니다. 장애 조치, 지리 위치, 지리적 근접성, 지연 시간, 다중 값, 가중치 레코드의 상태를 확인하려는 경우, 도메인 이름에 따라 엔드포인트를 지정하도록 선택하면 각 엔드포인트에 대해 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. [**Domain name**]의 값은 레코드의 이름(www.example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다. 이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다. 또한 **프로토콜** 값이 **HTTP** 또는 **HTTPS**인 경우, 이 목록의 앞에 있는 **호스트 이름**에 설명된 대로 Route 53는 `Host` 헤더의 **도메인 이름** 값을 전달합니다. **프로토콜(Protocol)**의 값이 **TCP**라면, Route 53는 `Host` 헤더를 전달하지 않습니다. 비AWS 엔드포인트를 지정하는 경우 추가 요금이 적용됩니다. AWS 엔드포인트의 정의를 비롯한 자세한 내용은 [Route 53 요금(Route 53 Pricing)](https://aws.amazon.com/route53/pricing/) 페이지에서 "상태 확인" 섹션을 참조하세요. ------ #### [ Old console ] 이 상태 확인을 통해 엔드포인트를 모니터링하려면 다음 값을 지정하십시오: + 엔드포인트 지정 + 프로토콜 + IP 주소 + 호스트 이름 + 포트 + 도메인 이름 + 경로 **엔드포인트 지정** IP 주소나 도메인 이름을 사용하여 엔드포인트를 지정할지 여부. 상태 확인을 생성한 후에는 [**Specify endpoint by**]의 값을 변경할 수 없습니다. **프로토콜** 엔드포인트 상태 확인을 위해 Route 53에서 사용하길 바라는 방법: + **HTTP** - Route 53가 TCP 연결을 설정하려고 시도합니다. 성공할 경우 Route 53는 HTTP 요청을 제출하고 2xx 또는 3xx의 HTTP 상태 코드를 기다립니다. + **HTTPS** - Route 53가 TCP 연결을 설정하려고 시도합니다. 성공할 경우 Route 53는 HTTPS 요청을 제출하고 2xx 또는 3xx의 HTTP 상태 코드를 기다립니다. **중요** **HTTPS**를 선택한다면 엔드포인트가 TLS v1.0, v1.1 또는 v1.2를 지원해야 합니다. **프로토콜** 값으로 **HTTPS**를 선택할 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. + **TCP** - Route 53가 TCP 연결을 설정하려고 시도합니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 단원을 참조하십시오. 상태 확인을 생성한 후에는 **프로토콜**의 값을 변경할 수 없습니다. **IP 주소(IP address)("IP 주소로 엔드포인트 지정(Specify endpoint by IP address)" 전용)** **IP 주소로 엔드포인트 지정(Specify endpoint by IP address)**을 선택한 경우 Route 53가 상태 확인을 수행하게 하려는 엔드포인트의 IPv4 또는 IPv6 주소입니다. Route 53는 IP 주소가 로컬, 프라이빗, 라우팅 불가, 또는 멀티캐스트 범위에 있는 엔드포인트의 상태는 확인할 수 없습니다. 상태 확인을 생성할 수 없는 IP 주소에 대한 자세한 내용은 다음 문서를 참조하십시오. + [RFC 5735, Special Use IPv4 Addresses](http://tools.ietf.org/html/rfc5735)(RFC 5735, 특수 용도 IPv4 주소) + [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](http://tools.ietf.org/html/rfc6598)(RFC 6598, IANA에서 공유 주소 공간으로 예약된 IPv4 접두사). + [RFC 5156, Special-Use IPv6 Addresses](https://tools.ietf.org/html/rfc5156)(RFC 5156, 특수 용도 IPv6 주소) 엔드포인트가 Amazon EC2 인스턴스일 경우, 탄력적 IP 주소를 생성하여 EC2 인스턴스와 연결하고 탄력적 IP 주소를 지정하는 것이 좋습니다. 이렇게 하면 인스턴스의 IP 주소가 변경되지 않습니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [탄력적 IP 주소(EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 참조하세요. Amazon EC2 인스턴스를 삭제하는 경우 EIP에 연결된 상태 확인도 삭제해야 합니다. 자세한 내용은 [Amazon Route 53 상태 확인의 모범 사례](best-practices-healthchecks.md) 단원을 참조하십시오. 비AWS 엔드포인트를 지정하는 경우 추가 요금이 적용됩니다. AWS 엔드포인트의 정의를 비롯한 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/) 페이지에서 "상태 확인" 섹션을 참조하세요. **호스트 이름(Host name)("IP 주소로 엔드포인트 지정(Specify endpoint by IP address)" 전용, HTTP 및 HTTPS 프로토콜 전용)** HTTP 및 HTTPS 상태 확인의 `Host` 헤더에서 Route 53가 전달하길 원하는 값입니다. 이 값은 일반적으로 Route 53가 상태 확인을 수행하기를 원하는 웹 사이트의 전체 주소 도메인 이름입니다. 다음은 Route 53가 엔드포인트의 상태를 확인할 때 어떻게 `Host` 헤더를 생성하는지를 보여줍니다. + **포트(Port)**에 **80** 값을 지정하고, **프로토콜(Protocol)**에 **HTTP**를 지정하면, Route 53가 **호스트 이름(Host name)** 값을 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. + **포트(Port)**에 **443** 값을 지정하고, **프로토콜(Protocol)**에 **HTTPS**를 지정하면, Route 53가 **호스트 이름(Host name)** 값을 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. + **포트(Port)**에 다른 값을 지정하고, **프로토콜(Protocol)**에 **HTTP** 또는 **HTTPS**를 지정하면, Route 53가 *Host name***:***Port*를 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. IP 주소로 엔드포인트를 지정하도록 선택하고 **호스트 이름** 값을 지정하지 않은 경우, Route 53는 이전 사례의 각각에서 `Host` 헤더의 **IP 주소** 값을 대체합니다. **포트** Route 53에서 상태 확인을 수행할 엔드포인트의 포트입니다. **도메인 이름(Domain name)("도메인 이름으로 엔드포인트 지정(Specify endpoint by domain name)" 전용, 모든 프로토콜)** **도메인 이름으로 엔드포인트 지정(Specify endpoint by domain name)**을 선택한 경우 Route 53가 상태 확인을 수행하게 하려는 엔드포인트의 도메인 이름(example.com) 또는 하위 도메인 이름(backend.example.com) 입니다. 도메인 이름으로 엔드포인트를 지정하도록 선택하는 경우, Route 53는 **도메인 이름(Domain name)**에 지정한 도메인 이름을 확인하기 위해 **요청 간격(Request interval)**에 지정한 간격으로 DNS 쿼리를 전송합니다. 그런 다음 Route 53는 DNS가 반환하는 IP 주소를 사용하여 엔드포인트의 상태를 확인합니다. 도메인 이름으로 엔드포인트를 지정하는 경우에는 Route 53가 IPv4만 사용하여 상태 확인을 엔드포인트에 전송합니다. [**Domain name**]에 지정하는 도메인 이름에 대해 A 유형의 레코드가 없는 경우에는 "DNS resolution failed" 오류와 함께 상태 확인이 중단됩니다. 장애 조치, 지리 위치, 지리적 근접성, 지연 시간, 다중 값, 가중치 레코드의 상태를 확인하려는 경우, 도메인 이름에 따라 엔드포인트를 지정하도록 선택하면 각 엔드포인트에 대해 별도의 상태 확인을 생성하는 것이 좋습니다. 예를 들어, www.example.com의 콘텐츠를 제공하는 각 HTTP 서버마다 상태 확인을 생성합니다. [**Domain name**]의 값은 레코드의 이름(www.example.com)이 아니라 서버의 도메인 이름(예: us-east-2-www.example.com)을 지정합니다. 이 구성에서 **도메인 이름**의 값이 레코드의 이름과 일치하는 상태 확인을 생성한 후 상태 확인을 이러한 레코드와 연결하는 경우 상태 확인 결과를 예측할 수 없습니다. 또한 **프로토콜** 값이 **HTTP** 또는 **HTTPS**인 경우, 이 목록의 앞에 있는 **호스트 이름**에 설명된 대로 Route 53는 `Host` 헤더의 **도메인 이름** 값을 전달합니다. **프로토콜(Protocol)**의 값이 **TCP**라면, Route 53는 `Host` 헤더를 전달하지 않습니다. 비AWS 엔드포인트를 지정하는 경우 추가 요금이 적용됩니다. AWS 엔드포인트의 정의를 비롯한 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/) 페이지에서 "상태 확인" 섹션을 참조하세요. **경로(HTTP 및 HTTPS 프로토콜 전용)** 상태 확인을 수행할 때 Route 53에서 요청할 경로입니다. 이 경로는 엔드포인트가 정상일 때 `2xx` 또는 `3xx`의 HTTP 상태 코드를 반환하는 값이면 무엇이든 가능한데, 예를 들면 `/docs/route53-health-check.html` 파일이 있습니다. 쿼리 문자열 파라미터를 포함해도 됩니다(예: `/welcome.html?language=jp&login=y`). 앞에 슬래시(`/`) 문자가 없으면 Route 53가 자동으로 하나 추가합니다. ------ ## 다른 상태 확인 모니터링(계산된 상태 확인) **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-creating-values-calculated-new) + [이전 콘솔](#health-checks-creating-values-calculated-old) ------ #### [ New console ] 이 상태 확인을 통해 다른 상태 확인의 상태를 모니터링하려면 다음 값을 지정하십시오: + 모니터링할 상태 확인 + 정상 보고 시기 **모니터링할 상태 확인 ** 이 상태 확인의 상태를 결정하기 위해 Route 53에서 모니터링하도록 하려는 상태 확인입니다. [**Health checks to monitor**]에 최대 256개의 상태 확인을 추가할 수 있습니다. 목록에서 상태 확인을 제거하려면 해당 상태 확인에 대한 강조 표시의 오른쪽에 있는 [**x**]를 선택합니다. 다른 계산된 상태 확인의 상태를 모니터링하기 위한 계산된 상태 확인을 구성할 수는 없습니다. 계산된 상태 확인이 모니터링 중인 상태 확인을 비활성화할 경우, Route 53는 계산된 상태 확인이 정상인지 여부를 계산하기 때문에 비활성화된 상태 확인이 정상인 것으로 간주합니다. 비활성화된 상태 확인을 비정상인 것으로 간주해야 할 경우에는 **Invert health check status(상태 확인 상태 변환)** 확인란을 선택합니다. ** 정상 보고 시기 ** Route 53가 상태 확인이 정상인지 확인하기 위해 수행하도록 하려는 계산: + **선택된 상태 확인 y 중 최소 x개가 정상인 경우 정상 보고(Report healthy when at least x of y selected health checks are healthy)** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 지정된 수의 상태 확인이 정상일 때 이 상태 확인이 정상인 것으로 간주합니다. 다음 사항에 유의하세요. + **모니터링할 상태 확인(Health checks to monitor)**에서 상태 확인의 수보다 큰 수를 지정할 경우, Route 53는 항상 이 상태 확인을 비정상으로 간주합니다. + **0**을 지정하면 Route 53는 항상 이 상태 확인을 정상으로 간주합니다. + **모든 상태 확인이 정상인 경우 정상 보고(AND)(Report healthy when all health checks are healthy(AND))** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 모든 상태 확인이 정상일 때만 이 상태 확인이 정상인 것으로 간주합니다. + **하나 이상의 상태 확인이 정상인 경우 정상 보고(OR)(Report healthy when one or more health checks are healthy(OR))** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 상태 확인 중 하나라도 정상일 때 이 상태 확인이 정상인 것으로 간주합니다. ------ #### [ Old console ] 이 상태 확인을 통해 다른 상태 확인의 상태를 모니터링하려면 다음 값을 지정하십시오: + 모니터링할 상태 확인 + 정상 보고 시기 + 상태 확인 상태 반전 + 비활성화됨 ** 모니터링할 상태 확인 ** 이 상태 확인의 상태를 결정하기 위해 Route 53에서 모니터링하도록 하려는 상태 확인입니다. [**Health checks to monitor**]에 최대 256개의 상태 확인을 추가할 수 있습니다. 목록에서 상태 확인을 제거하려면 해당 상태 확인에 대한 강조 표시의 오른쪽에 있는 [**x**]를 선택합니다. 다른 계산된 상태 확인의 상태를 모니터링하기 위한 계산된 상태 확인을 구성할 수는 없습니다. 계산된 상태 확인이 모니터링 중인 상태 확인을 비활성화할 경우, Route 53는 계산된 상태 확인이 정상인지 여부를 계산하기 때문에 비활성화된 상태 확인이 정상인 것으로 간주합니다. 비활성화된 상태 확인을 비정상인 것으로 간주해야 할 경우에는 **Invert health check status(상태 확인 상태 변환)** 확인란을 선택합니다. ** 정상 보고 시기 ** Route 53가 상태 확인이 정상인지 확인하기 위해 수행하도록 하려는 계산: + **선택된 상태 확인 y 중 최소 x개가 정상인 경우 정상 보고(Report healthy when at least x of y selected health checks are healthy)** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 지정된 수의 상태 확인이 정상일 때 이 상태 확인이 정상인 것으로 간주합니다. 다음 사항에 유의하세요. + **모니터링할 상태 확인(Health checks to monitor)**에서 상태 확인의 수보다 큰 수를 지정할 경우, Route 53는 항상 이 상태 확인을 비정상으로 간주합니다. + **0**을 지정하면 Route 53는 항상 이 상태 확인을 정상으로 간주합니다. + **모든 상태 확인이 정상인 경우 정상 보고(AND)(Report healthy when all health checks are healthy(AND))** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 모든 상태 확인이 정상일 때만 이 상태 확인이 정상인 것으로 간주합니다. + **하나 이상의 상태 확인이 정상인 경우 정상 보고(OR)(Report healthy when one or more health checks are healthy(OR))** - Route 53는 **모니터링할 상태 확인(Health checks to monitor)**에 추가한 상태 확인 중 하나라도 정상일 때 이 상태 확인이 정상인 것으로 간주합니다. ** 상태 확인 상태 반전(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 반전하려면 [상태 확인 반전](health-checks-invert.md) 섹션을 참조하세요. Route 53가 상태 확인의 상태를 반전하도록 할지 선택합니다. 이 옵션을 선택하면 Route 53가 상태가 정상일 때는 상태 확인이 비정상인 것으로 간주하고, 그 반대도 마찬가지입니다. ** 비활성화됨(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 비활성화하려면 [상태 확인 비활성화 또는 활성화](health-checks-disable.md) 섹션을 참조하세요. Route 53의 상태 확인 실행을 정지시킵니다. 상태 확인을 비활성화하면 Route 53가 참조된 상태 확인 상태의 집계를 중지합니다. 상태 확인을 비활성화한 후에는 Route 53는 상태 확인 상태가 항상 정상인 것으로 간주합니다. DNS 장애 조치를 구성한 경우에는 Route 53가 해당 리소스로 트래픽을 계속 라우팅합니다. 트래픽이 리소스로 라우팅되는 것을 중지해야 할 경우에는 상태 확인을 반전합니다. 상태 확인에 대한 요금은 상태 확인이 비활성화되어 있을 때도 적용됩니다. ------ ## CloudWatch 경보 모니터링 **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-creating-values-cloudwatch-new) + [이전 콘솔](#health-checks-creating-values-cloudwatch-old) ------ #### [ New console ] 이 상태 확인을 통해 CloudWatch 경보의 경보 상태를 모니터링하려면 다음 값을 지정하세요. + CloudWatch 경보 + 상태 확인 상태 **CloudWatch 경보** Route 53에서 이 상태 확인이 정상인지 확인하기 위해 사용하려는 CloudWatch 경보를 선택합니다. CloudWatch 경보는 상태 확인 AWS 계정 과 동일한에 있어야 합니다. Route 53는 다음과 같은 CloudWatch 경보를 지원합니다. + 표준 분해능 지표. 고분해능 지표는 지원되지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [고해상도 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)를 참조하세요. + 통계: `Average`, `Minimum`, `Maximum`, `Sum` 및 `SampleCount`. 확장된 통계는 지원되지 않습니다. + Route 53는 “N 중 M” 경보를 지원하지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [경보 평가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)를 참조하세요. Route 53는 [지표 수식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 사용하여 여러 CloudWatch 지표를 쿼리하는 경보를 지원하지 않습니다. 경보를 생성하려는 경우 다음 단계를 수행하십시오. 1. **생성**을 선택합니다. 새 브라우저 탭에 CloudWatch 콘솔이 나타납니다. 1. 관련 값들을 입력합니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 경보 편집 또는 삭제](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ConsoleAlarms.html)를 참조하세요. 1. Route 53 콘솔이 나타나는 브라우저 탭으로 돌아갑니다. 1. [**CloudWatch alarm**] 목록 옆의 새로 고침 버튼을 선택합니다. 1. 목록에서 새 경보를 선택합니다. 상태 확인을 생성한 후 CloudWatch 경보의 설정을 변경할 경우 상태 확인을 업데이트해야 합니다. 자세한 내용은 [CloudWatch 경보 설정 변경 시 상태 확인 업데이트(CloudWatch 경보만 모니터링하는 상태 확인)CloudWatch 경보 설정 변경 시 상태 확인 업데이트](health-checks-updating-cloudwatch-alarm-settings.md) 단원을 참조하십시오. **상태 확인 상태** CloudWatch에 데이터가 부족하여 **CloudWatch 경보(CloudWatch alarm)**에서 선택한 경보의 상태를 확인할 데이터가 충분하지 않은 경우 상태 확인의 상태(정상, 비정상, 또는 마지막으로 알려진 상태)를 선택합니다. 마지막으로 알려진 상태를 사용하도록 선택하면 Route 53에서는 마지막으로 경보 상태를 확인할 만큼 CloudWatch에 충분한 데이터가 있었던 때의 상태 확인의 상태를 사용합니다. 마지막으로 알려진 상태가 없는 새로운 상태 확인의 경우 상태 확인의 기본 상태는 정상입니다. **상태 확인 상태(Health check status)**는 CloudWatch 지표에 대한 데이터 스트림을 잠시 사용할 수 없는 경우 임시 상태를 제공합니다. (Route 53는 해당 경보의 상태가 아니라 CloudWatch 지표에 대한 데이터 스트림을 모니터링합니다.) 측정치를 자주 또는 장기간(몇 시간 이상) 사용하지 않을 예정인 경우, 마지막으로 알려진 상태를 사용하지 않는 것이 좋습니다. ------ #### [ Old console ] 이 상태 확인을 통해 CloudWatch 경보의 경보 상태를 모니터링하려면 다음 값을 지정하세요. + CloudWatch 경보 + 상태 확인 상태 + 상태 확인 상태 반전 + 비활성화됨 **CloudWatch 경보** Route 53에서 이 상태 확인이 정상인지 확인하기 위해 사용하려는 CloudWatch 경보를 선택합니다. CloudWatch 경보는 상태 확인 AWS 계정 과 동일한에 있어야 합니다. Route 53는 다음과 같은 CloudWatch 경보를 지원합니다. + 표준 분해능 지표. 고분해능 지표는 지원되지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [고해상도 지표](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)를 참조하세요. + 통계: `Average`, `Minimum`, `Maximum`, `Sum` 및 `SampleCount`. 확장된 통계는 지원되지 않습니다. + Route 53는 “N 중 M” 경보를 지원하지 않습니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [경보 평가](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)를 참조하세요. Route 53는 [지표 수식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)을 사용하여 여러 CloudWatch 지표를 쿼리하는 경보를 지원하지 않습니다. 경보를 생성하려는 경우 다음 단계를 수행하십시오. 1. **생성**을 선택합니다. 새 브라우저 탭에 CloudWatch 콘솔이 나타납니다. 1. 관련 값들을 입력합니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch 경보 편집 또는 삭제](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ConsoleAlarms.html)를 참조하세요. 1. Route 53 콘솔이 나타나는 브라우저 탭으로 돌아갑니다. 1. [**CloudWatch alarm**] 목록 옆의 새로 고침 버튼을 선택합니다. 1. 목록에서 새 경보를 선택합니다. 상태 확인을 생성한 후 CloudWatch 경보의 설정을 변경할 경우 상태 확인을 업데이트해야 합니다. 자세한 내용은 [CloudWatch 경보 설정 변경 시 상태 확인 업데이트(CloudWatch 경보만 모니터링하는 상태 확인)CloudWatch 경보 설정 변경 시 상태 확인 업데이트](health-checks-updating-cloudwatch-alarm-settings.md) 단원을 참조하십시오. **상태 확인 상태** CloudWatch에 데이터가 부족하여 **CloudWatch 경보(CloudWatch alarm)**에서 선택한 경보의 상태를 확인할 데이터가 충분하지 않은 경우 상태 확인의 상태(정상, 비정상, 또는 마지막으로 알려진 상태)를 선택합니다. 마지막으로 알려진 상태를 사용하도록 선택하면 Route 53에서는 마지막으로 경보 상태를 확인할 만큼 CloudWatch에 충분한 데이터가 있었던 때의 상태 확인의 상태를 사용합니다. 마지막으로 알려진 상태가 없는 새로운 상태 확인의 경우 상태 확인의 기본 상태는 정상입니다. **상태 확인 상태(Health check status)**는 CloudWatch 지표에 대한 데이터 스트림을 잠시 사용할 수 없는 경우 임시 상태를 제공합니다. (Route 53는 해당 경보의 상태가 아니라 CloudWatch 지표에 대한 데이터 스트림을 모니터링합니다.) 측정치를 자주 또는 장기간(몇 시간 이상) 사용하지 않을 예정인 경우, 마지막으로 알려진 상태를 사용하지 않는 것이 좋습니다. **상태 확인 상태 반전(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 반전하려면 [상태 확인 반전](health-checks-invert.md) 섹션을 참조하세요. Route 53가 상태 확인의 상태를 반전하도록 할지 선택합니다. 이 옵션을 선택하면 Route 53가 상태가 정상일 때는 상태 확인이 비정상인 것으로 간주하고, 그 반대도 마찬가지입니다. ** 비활성화됨(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 비활성화하려면 [상태 확인 비활성화 또는 활성화](health-checks-disable.md) 섹션을 참조하세요. Route 53의 상태 확인 실행을 정지시킵니다. 상태 확인을 비활성화하면 Route 53는 해당 CloudWatch 지표의 모니터링을 중지합니다. 상태 확인을 비활성화한 후에는 Route 53는 상태 확인 상태가 항상 정상인 것으로 간주합니다. DNS 장애 조치를 구성한 경우에는 Route 53가 해당 리소스로 트래픽을 계속 라우팅합니다. 트래픽이 리소스로 라우팅되는 것을 중지해야 할 경우에는 상태 확인을 반전합니다. 상태 확인에 대한 요금은 상태 확인이 비활성화되어 있을 때도 적용됩니다. ------ ## 고급 구성("Monitor an endpoint" 전용) **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. + [새로운 콘솔](#health-checks-creating-values-advanced-new) + [이전 콘솔](#health-checks-creating-values-advanced-old) ------ #### [ New console ] + 요청 간격 + 실패 임계값 + 문자열 일치 + 검색 문자열 + 지연 시간 그래프 + SNI 활성화 + 호스트 이름 **요청 간격** 각 Route 53 상태 확인 프로그램이 엔드포인트로부터 응답을 받는 시점과 그 다음 상태 확인 요청을 전송하는 시점 사이에 경과된 초 단위 시간. 30초 간격을 선택한 경우 전 세계 데이터 센터에 있는 각 Route 53 상태 확인 프로그램에서 30초 간격으로 엔드포인트에 상태 확인 요청을 보냅니다. 평균적으로 엔드포인트에서는 약 2초 간격으로 상태 확인 요청을 수신합니다. 간격을 10초로 선택하면, 엔드포인트는 1초당 1회 이상 요청을 받게 됩니다. 다른 데이터 센터에 있는 Route 53 상태 확인 프로그램은 상호 연계되지 않으므로 선택한 간격에 상관 없이 초당 여러 번의 요청이 표시되는 경우도 있고 몇 초 동안 상태 확인이 없는 경우도 있습니다. 상태 확인을 생성한 후에는 [**Request interval**]의 값을 변경할 수 없습니다. **요청 간격(Request interval)**의 값으로 **빠른 간격(10초)**을 선택한 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **실패 임계값** 이 현재 엔드포인트의 상태를 비정상에서 정상 또는 그 반대로 변경하도록 하기 위해서 엔드포인트가 Route 53를 위해 전송 또는 실패해야 하는 연속적인 상태 확인 횟수입니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 단원을 참조하십시오. **문자열 일치(String matching)(HTTP 및 HTTPS 전용)** Route 53가 HTTP 또는 HTTPS 요청을 엔드포인트로 제출하고 지정된 문자열에 대한 응답의 본문을 검색함으로써 엔드포인트의 상태를 판단하기를 원하는가 여부. 응답의 본문이 **문자열 검색(Search string)**에서 지정한 값을 포함하고 있다면, Route 53는 엔드포인트가 정상이라고 판단합니다. 그렇지 않다면, 또는 엔드포인트가 응답하지 않는다면, Route 53는 엔드포인트가 비정상이라고 여깁니다. 문자열 검색은 응답 본문의 최초 5,120바이트 내에서 모두 나타나야 합니다. 상태 확인을 생성한 후에는 [** String matching**]의 값을 변경할 수 없습니다. **문자열 일치(String matching)** 값으로 **예(Yes)**를 선택하는 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **상태 확인 프로그램이 압축된 응답을 처리하는 방법** 엔드포인트가 압축된 응답을 반환하는 웹 서버인 경우 Route 53 상태 확인 프로그램은 웹 서버가 상태 확인 프로그램이 지원하는 압축 알고리즘을 사용하여 응답을 압축한 경우에만 지정된 문자열 검색을 확인하기 전에 응답을 압축 해제합니다. 상태 확인 프로그램은 다음과 같은 압축 알고리즘을 지원합니다. + Gzip + Deflate 응답이 다른 알고리즘을 사용하여 압축된 경우 상태 확인 프로그램은 문자열을 검색하기 전에 응답을 압축 해제할 수 없습니다. 이 경우 검색은 거의 항상 실패하며 Route 53는 엔드포인트를 비정상으로 간주합니다. **문자열 검색(Search string)("문자열 일치(String matching)"가 활성화된 경우만)** Route 53가 엔드포인트로부터 오는 응답의 본문에서 검색하길 원하는 문자열입니다. 최대 길이는 255자입니다. Route 53는 응답의 본문에서 **문자열 검색(Search string)**을 검색하는 경우를 고려합니다. **지연 시간 그래프** Route 53가 여러 AWS 리전의 상태 확인기와 엔드포인트 간의 지연 시간을 측정할지 여부를 선택합니다. 이 옵션을 선택하면 CloudWatch 지연 시간 그래프가 Route 53 콘솔의 **상태 확인(Health checks)** 페이지에 **지연 시간(Latency)** 탭에 나타납니다. Route 53 상태 확인 프로그램이 엔드포인트에 연결할 수 없으면 Route 53가 그 엔드포인트에 대한 지연 시간 그래프를 표시할 수 없습니다. 상태 확인을 생성한 후에는 [**Latency measurements**]의 값을 변경할 수 없습니다. 상태 확인 프로그램과 엔드포인트 간 지연을 측정하도록 Route 53를 구성할 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **SNI 활성화(HTTPS 전용)** Route 53에서 TLS 협상 중에 `client_hello` 메시지의 엔드포인트로 호스트 이름을 보내도록 할지 여부를 지정합니다. 그러면 엔드포인트에서 해당하는 SSL/TLS 인증서를 사용하여 HTTPS 요청에 응답할 수 있습니다. 일부 엔드포인트의 경우, HTTPS 요청에는 client\$1hello 메시지에 호스트 이름이 포함되어야 합니다. SNI를 활성화하지 않으면 상태 확인 상태가 실패로 표시될 수 있습니다. 오류 메시지는 서버가 SNI 정보가 포함되지 않은 요청에 응답하도록 구성된 방식에 따라 달라집니다. 상태 확인은 다른 이유로 실패 상태가 될 수도 있습니다. SNI를 사용하는데도 여전히 오류가 발생하는 경우, 엔드포인트의 SSL/TLS 구성을 확인하고 인증서가 유효한지 확인합니다. 다음과 같은 요구 사항을 확인합니다. + 엔드포인트가 SNI를 지원해야 합니다. + 엔드포인트의 SSL/TLS 인증서에는 `Common Name` 필드의 도메인 이름과 `Subject Alternative Names` 필드의 그 밖의 항목이 포함됩니다. 인증서의 도메인 이름 중 하나는 **호스트 이름(Host name)**에 지정하는 값과 일치해야 합니다. **상태 확인 리전** Route 53에서 권장 리전의 상태 확인 프로그램을 사용하여 엔드포인트의 상태를 확인할지 또는 지정한 리전의 상태 확인 프로그램을 사용하여 엔드포인트의 상태를 확인할지를 선택합니다. 상태 확인을 업데이트하여 상태 확인을 수행한 리전을 제거하면 Route 53는 해당 리전에서 최대 1시간 동안 검사를 계속 수행합니다. 이렇게 하면 일부 상태 확인 프로그램이 항상 엔드포인트를 확인하게 됩니다(예를 들어, 세 개의 리전을 네 개의 다른 리전으로 바꾼 경우). **사용자 지정**을 선택하는 경우 리전에 대한 **x**를 선택하여 리전을 제거합니다. 목록 하단의 공백을 클릭하여 리전을 목록에 다시 추가합니다. 최소 3개의 리전을 지정해야 합니다. **호스트 이름(Host name)("IP 주소로 엔드포인트 지정(Specify endpoint by IP address)" 전용, HTTP 및 HTTPS 프로토콜 전용)** HTTP 및 HTTPS 상태 확인의 `Host` 헤더에서 Route 53가 전달하길 원하는 값입니다. 이 값은 일반적으로 Route 53가 상태 확인을 수행하기를 원하는 웹 사이트의 전체 주소 도메인 이름입니다. 다음은 Route 53가 엔드포인트의 상태를 확인할 때 어떻게 `Host` 헤더를 생성하는지를 보여줍니다. + **포트(Port)**에 **80** 값을 지정하고, **프로토콜(Protocol)**에 **HTTP**를 지정하면, Route 53가 **호스트 이름(Host name)** 값을 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. + **포트**에 **443** 값을 지정하고, **프로토콜**에 **HTdTPS**를 지정하면, Route 53가 **호스트 이름** 값을 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. + **포트(Port)**에 다른 값을 지정하고, **프로토콜(Protocol)**에 **HTTP** 또는 **HTTPS**를 지정하면, Route 53가 *Host name***:***Port*를 포함하는 `Host` 헤더를 엔드포인트에 전달합니다. IP 주소로 엔드포인트를 지정하도록 선택하고 **호스트 이름** 값을 지정하지 않은 경우, Route 53는 이전 사례의 각각에서 `Host` 헤더의 **IP 주소** 값을 대체합니다. ------ #### [ Old console ] 엔드포인트를 모니터링하기 위해 이 옵션을 선택할 경우 다음 설정을 지정할 수도 있습니다: + 요청 간격 + 실패 임계값 + 문자열 일치 + 검색 문자열 + 지연 시간 그래프 + SNI 활성화 + 상태 확인 프로그램 리전 + 상태 확인 상태 반전 + 비활성화됨 **요청 간격** 각 Route 53 상태 확인 프로그램이 엔드포인트로부터 응답을 받는 시점과 그 다음 상태 확인 요청을 전송하는 시점 사이에 경과된 초 단위 시간. 30초 간격을 선택한 경우 전 세계 데이터 센터에 있는 각 Route 53 상태 확인 프로그램에서 30초 간격으로 엔드포인트에 상태 확인 요청을 보냅니다. 평균적으로 엔드포인트에서는 약 2초 간격으로 상태 확인 요청을 수신합니다. 간격을 10초로 선택하면, 엔드포인트는 1초당 1회 이상 요청을 받게 됩니다. 다른 데이터 센터에 있는 Route 53 상태 확인 프로그램은 상호 연계되지 않으므로 선택한 간격에 상관 없이 초당 여러 번의 요청이 표시되는 경우도 있고 몇 초 동안 상태 확인이 없는 경우도 있습니다. 상태 확인을 생성한 후에는 [**Request interval**]의 값을 변경할 수 없습니다. **요청 간격(Request interval)**의 값으로 **빠른 간격(10초)**을 선택한 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **실패 임계값** 이 현재 엔드포인트의 상태를 비정상에서 정상 또는 그 반대로 변경하도록 하기 위해서 엔드포인트가 Route 53를 위해 전송 또는 실패해야 하는 연속적인 상태 확인 횟수입니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 단원을 참조하십시오. **문자열 일치(String matching)(HTTP 및 HTTPS 전용)** Route 53가 HTTP 또는 HTTPS 요청을 엔드포인트로 제출하고 지정된 문자열에 대한 응답의 본문을 검색함으로써 엔드포인트의 상태를 판단하기를 원하는가 여부. 응답의 본문이 **문자열 검색(Search string)**에서 지정한 값을 포함하고 있다면, Route 53는 엔드포인트가 정상이라고 판단합니다. 그렇지 않다면, 또는 엔드포인트가 응답하지 않는다면, Route 53는 엔드포인트가 비정상이라고 여깁니다. 문자열 검색은 응답 본문의 최초 5,120바이트 내에서 모두 나타나야 합니다. 상태 확인을 생성한 후에는 [** String matching**]의 값을 변경할 수 없습니다. **문자열 일치(String matching)** 값으로 **예(Yes)**를 선택하는 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **상태 확인 프로그램이 압축된 응답을 처리하는 방법** 엔드포인트가 압축된 응답을 반환하는 웹 서버인 경우 Route 53 상태 확인 프로그램은 웹 서버가 상태 확인 프로그램이 지원하는 압축 알고리즘을 사용하여 응답을 압축한 경우에만 지정된 문자열 검색을 확인하기 전에 응답을 압축 해제합니다. 상태 확인 프로그램은 다음과 같은 압축 알고리즘을 지원합니다. + Gzip + Deflate 응답이 다른 알고리즘을 사용하여 압축된 경우 상태 확인 프로그램은 문자열을 검색하기 전에 응답을 압축 해제할 수 없습니다. 이 경우 검색은 거의 항상 실패하며 Route 53는 엔드포인트를 비정상으로 간주합니다. **문자열 검색(Search string)("문자열 일치(String matching)"가 활성화된 경우만)** Route 53가 엔드포인트로부터 오는 응답의 본문에서 검색하길 원하는 문자열입니다. 최대 길이는 255자입니다. Route 53는 응답의 본문에서 **문자열 검색(Search string)**을 검색하는 경우를 고려합니다. **지연 시간 그래프** Route 53가 여러 AWS 리전의 상태 확인기와 엔드포인트 간의 지연 시간을 측정할지 여부를 선택합니다. 이 옵션을 선택하면 CloudWatch 지연 시간 그래프가 Route 53 콘솔의 **상태 확인(Health checks)** 페이지에 **지연 시간(Latency)** 탭에 나타납니다. Route 53 상태 확인 프로그램이 엔드포인트에 연결할 수 없으면 Route 53가 그 엔드포인트에 대한 지연 시간 그래프를 표시할 수 없습니다. 상태 확인을 생성한 후에는 [**Latency measurements**]의 값을 변경할 수 없습니다. 상태 확인 프로그램과 엔드포인트 간 지연을 측정하도록 Route 53를 구성할 경우 추가 요금이 적용됩니다. 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. **SNI 활성화(HTTPS 전용)** Route 53에서 TLS 협상 중에 `client_hello` 메시지의 엔드포인트로 호스트 이름을 보내도록 할지 여부를 지정합니다. 그러면 엔드포인트에서 해당하는 SSL/TLS 인증서를 사용하여 HTTPS 요청에 응답할 수 있습니다. 일부 엔드포인트의 경우, HTTPS 요청에는 `client_hello` 메시지에 호스트 이름이 포함되어야 합니다. SNI를 활성화하지 않으면 상태 확인 상태가 실패로 표시될 수 있습니다. 오류 메시지는 서버가 SNI 정보가 포함되지 않은 요청에 응답하도록 구성된 방식에 따라 달라집니다. 상태 확인은 다른 이유로 실패 상태가 될 수도 있습니다. SNI를 사용하는데도 여전히 오류가 발생하는 경우, 엔드포인트의 SSL/TLS 구성을 확인하고 인증서가 유효한지 확인합니다. 다음과 같은 요구 사항을 확인합니다. + 엔드포인트가 SNI를 지원해야 합니다. + 엔드포인트의 SSL/TLS 인증서에는 `Common Name` 필드의 도메인 이름과 `Subject Alternative Names` 필드의 그 밖의 항목이 포함됩니다. 인증서의 도메인 이름 중 하나는 **호스트 이름(Host name)**에 지정하는 값과 일치해야 합니다. **상태 확인 리전** Route 53에서 권장 리전의 상태 확인 프로그램을 사용하여 엔드포인트의 상태를 확인할지 또는 지정한 리전의 상태 확인 프로그램을 사용하여 엔드포인트의 상태를 확인할지를 선택합니다. 상태 확인을 업데이트하여 상태 확인을 수행한 리전을 제거하면 Route 53는 해당 리전에서 최대 1시간 동안 검사를 계속 수행합니다. 이렇게 하면 일부 상태 확인 프로그램이 항상 엔드포인트를 확인하게 됩니다(예를 들어, 세 개의 리전을 네 개의 다른 리전으로 바꾼 경우). **사용자 지정**을 선택하는 경우 리전에 대한 **x**를 선택하여 리전을 제거합니다. 목록 하단의 공백을 클릭하여 리전을 목록에 다시 추가합니다. 최소 3개의 리전을 지정해야 합니다. **상태 확인 상태 반전(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 반전하려면 [상태 확인 반전](health-checks-invert.md) 섹션을 참조하세요. Route 53가 상태 확인의 상태를 반전하도록 할지 선택합니다. 이 옵션을 선택하면 Route 53가 상태가 정상일 때는 상태 확인이 비정상인 것으로 간주하고, 그 반대도 마찬가지입니다. 예를 들어, 일치하는 문자열을 구성하고 엔드포인트가 특정 값을 반환하는 경우 Route 53가 상태 확인을 *비정상*으로 간주하고자 할 수 있습니다. ** 비활성화됨(이전 콘솔만 해당)** 새 콘솔에서 상태 확인을 비활성화하려면 [상태 확인 비활성화 또는 활성화](health-checks-disable.md) 섹션을 참조하세요. Route 53의 상태 확인 실행을 정지시킵니다. 상태 확인을 비활성화하면 Route 53는 TCP와 엔드포인트의 연결 시도를 중지합니다. 상태 확인을 비활성화한 후에는 Route 53는 상태 확인 상태가 항상 정상인 것으로 간주합니다. DNS 장애 조치를 구성한 경우에는 Route 53가 해당 리소스로 트래픽을 계속 라우팅합니다. 트래픽이 리소스로 라우팅되는 것을 중지해야 할 경우에는 상태 확인을 반전합니다. 상태 확인에 대한 요금은 상태 확인이 비활성화되어 있을 때도 적용됩니다. ------ ## 상태 확인 실패 시 알림 메시지를 받음 다음 옵션을 사용하여 상태 확인 실패 시 이메일 알림을 구성합니다: + [Create alarm](#health-checks-creating-values-create-alarm) + [Send notification to](#health-checks-creating-values-send-notification-to) + [Topic name](#health-checks-creating-values-topic-name) + [Recipient email addresses](#health-checks-creating-values-recipient-email-addresses) **알람 생성(상태 확인 생성 시에만 해당)** 기본 CloudWatch 경보를 생성하길 원하는지 여부를 지정합니다. **예(Yes)**를 선택하면, 이 엔드포인트의 상태가 비정상으로 변경되고 Route 53가 1분 동안 엔드포인트가 비정상이라고 여길 때 CloudWatch가 Amazon SNS 알림을 보냅니다. 상태가 다시 정상으로 돌아갈 경우 CloudWatch에서 Amazon SNS 알림을 한 번 더 보내도록 하려면 상태 확인을 생성한 후 다른 경보를 생성하면 됩니다. 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요. 기존 상태 확인에 대한 경보를 생성하길 원하거나 Route 53가 1분(기본값) 이상 또는 미만 동안 엔드포인트가 비정상이라고 여길 때 알림을 받기를 원한다면, **아니요(No)**를 선택하고 상태 확인을 생성한 후 경보를 추가합니다. 자세한 내용은 [CloudWatch를 이용한 상태 확인 모니터링](monitoring-health-checks.md) 단원을 참조하십시오. **알림 보내기(경보 생성 시에만 해당)** CloudWatch가 기존 Amazon SNS 주제 또는 새로운 주제에 알림을 전송하기를 원하는지 여부를 다음과 같이 지정합니다. + **기존 SNS 주제(Existing SNS topic)** - 목록에서 주제의 이름을 선택합니다. 주제는 미국 동부(버지니아 북부) 리전에 있어야 합니다. + **새 SNS 주제(New SNS topic)** - **주제 이름(Topic name)**에서 이름을 입력하고, **수신자(Recipients)**에서 알림 수신자의 이메일 주소를 입력합니다. 여러 개의 주소는 쉼표(,), 세미콜론(;), 공백으로 구분합니다. Route 53는 미국 동부(버지니아 북부) 리전에서 주제를 생성합니다. **제목 이름(새로운 SNS 주제를 생성할 때만 해당)** [** New SNS Topic**]을 지정했다면, 새 주제의 이름을 입력합니다. **수신자 이메일 주소(새로운 SNS 주제를 생성할 때만 해당)** [**New SNS topic**]을 지정한 경우 알림 수신자의 이메일 주소를 입력합니다. 여러 개의 이름은 쉼표(,), 세미콜론(;), 공백으로 구분합니다. # 상태 확인 생성 시 Amazon Route 53가 표시하는 값 [**Create Health Check**] 페이지는 입력한 값을 근거로 다음의 값들을 표시합니다. **URL** Route 53가 상태 확인을 수행할 때 요청을 보낼 전체 URL(HTTP 또는 HTTPS 상태 확인의 경우) 또는 IP 주소 및 포트(TCP 상태 확인용). **상태 확인 유형** 이 상태 확인을 위해 지정한 설정에 기반을 둔 [**Basic**] 또는 [**Basic \$1 additional options**]. 추가 옵션의 요금에 대한 자세한 내용은 [Route 53 요금](https://aws.amazon.com/route53/pricing/)을 참조하세요. # CloudWatch 경보 설정 변경 시 상태 확인 업데이트(CloudWatch 경보만 모니터링하는 상태 확인) CloudWatch 경보의 데이터 스트림을 모니터링하는 Route 53 상태 확인을 생성한 후 CloudWatch 경보의 설정을 업데이트할 경우, Route 53는 상태 확인의 경보 설정을 자동으로 업데이트하지 않습니다. 새로운 경보 설정을 사용하여 상태 확인을 시작하려면 상태 확인을 업데이트해야 합니다. **참고** 상태 확인을 프로그래밍 방식으로 업데이트하려면 `UpdateHealthCheck` API를 사용하십시오. `AlarmIdentifier` 및 `Region`의 현재 값을 지정하면 Route 53가 CloudWatch의 최신 설정을 받습니다. 자세한 내용은 *Amazon Route 53 API 참조*의 [UpdateHealthCheck](https://docs.aws.amazon.com/Route53/latest/APIReference/API_UpdateHealthCheck.html)를 참조하세요. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-updating-cloudwatch-alarm-settings-new) + [이전 콘솔](#health-checks-updating-cloudwatch-alarm-settings-old) ------ #### [ New console ] **상태 확인을 새로운 CloudWatch 경보 설정으로 업데이트하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. 업데이트하려는 상태 확인의 연결된 ID를 선택합니다. 1. **편집**을 선택합니다. 상태 확인의 CloudWatch 경보가 변경되었다는 메시지가 표시됩니다. [**Details**] 필드에 새로운 경보 설정이 표시됩니다. 1. **저장**을 선택합니다. ------ #### [ Old console ] **상태 확인을 새로운 CloudWatch 경보 설정으로 업데이트하려면(콘솔)** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 업데이트하려는 상태 확인의 확인란을 선택합니다. 1. [**Edit health check**]를 선택합니다. 상태 확인의 CloudWatch 경보가 변경되었다는 메시지가 표시됩니다. [**Details**] 필드에 새로운 경보 설정이 표시됩니다. 1. **저장**을 선택합니다. ------ # 상태 확인 비활성화 또는 활성화 상태 확인을 비활성화하면 Route 53가 상태 확인을 수행하지 못하게 됩니다. 상태 확인을 비활성화하면 Route 53가 참조된 상태 확인 상태의 집계를 중지합니다. 상태 확인을 비활성화한 후에는 Route 53는 상태 확인 상태가 항상 정상인 것으로 간주합니다. DNS 장애 조치를 구성한 경우에는 Route 53가 해당 리소스로 트래픽을 계속 라우팅합니다. 트래픽이 리소스로 라우팅되는 것을 중지해야 할 경우에는 **반전됨**의 값을 변경합니다. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 상태 확인을 생성하거나 편집할 때 이전 콘솔에서 상태 확인을 비활성화하거나 활성화할 수 있습니다. 자세한 내용은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md) 단원을 참조하십시오. 새 콘솔에서 상태 확인을 비활성화하려면 다음 절차를 수행합니다. **상태 확인을 비활성화하거나 활성화하려면(새 콘솔만 해당)** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. **작업** 열에서 점 3개를 선택한 다음 **비활성화** 또는 **활성화**를 선택합니다. 또는 비활성화하거나 활성화하려는 상태 확인의 연결된 ID를 선택합니다. 1. **구성** 테이블에서 **상태** 필드는 상태 확인의 활성화 여부를 지정합니다. 1. 상태 확인을 비활성화하거나 활성화하려면 **비활성화** 또는 **활성화**를 선택합니다 # 상태 확인 반전 상태 확인을 반전하면 Route 53가 상태가 정상일 때는 상태 확인이 비정상인 것으로 간주하고, 그 반대도 마찬가지입니다. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 상태 확인을 생성하거나 편집할 때 이전 콘솔에서 상태 확인을 반전할 수 있습니다. 자세한 내용은 [상태 확인 생성 또는 업데이트 시 지정하는 값](health-checks-creating-values.md) 단원을 참조하십시오. 새 콘솔에서 상태 확인을 반전하려면 다음 절차를 수행합니다. **상태 확인을 반전하려면(새 콘솔만 해당)** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. **작업** 열에서 점 3개를 선택한 다음 **반전**을 선택합니다. 또는 반전하려는 상태 확인의 연결된 ID를 선택합니다. 1. **구성** 테이블에서 **반전**된 파일은 상태 확인이 반전되는지(**예**) 또는 아닌지(**아니요**)를 지정합니다. 1. 상태 확인을 반전하려면 **반전**을 선택합니다. 반전된 상태를 실행 취소하려는 경우 **반전된** 필드가 **예** 인 경우 **반전**을 다시 선택합니다. # 상태 확인 삭제 상태 확인을 비활성화하려면 다음 절차를 수행합니다. **참고** 를 사용하고 AWS Cloud Map 인스턴스를 등록할 때 Route 53 상태 확인을 생성 AWS Cloud Map 하도록를 구성한 경우 Route 53 콘솔을 사용하여 상태 확인을 삭제할 수 없습니다. 인스턴스 등록을 취소하면 상태 확인이 자동으로 삭제됩니다. Route 53 콘솔에서 상태 확인이 사라질 때까지 몇 시간이 더 걸릴 수 있습니다. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-deleting-new) + [이전 콘솔](#health-checks-deleting-old) ------ #### [ New console ] **상태 확인을 삭제하려면** 1. 레코드와 연결된 상태 확인을 삭제하는 경우 [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md)에서 권장하는 작업을 수행합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. 삭제하려는 상태 확인의 연결된 ID를 선택합니다. 1. **삭제**를 선택합니다. 1. 텍스트 상자에 **confirm**을 입력한 다음, **삭제**를 선택합니다. ------ #### [ Old console ] **상태 확인을 삭제하려면(콘솔)** 1. 레코드와 연결된 상태 확인을 삭제하는 경우 [DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제](health-checks-updating-deleting-tasks.md)에서 권장하는 작업을 수행합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 오른쪽 창에서 삭제할 상태 확인을 선택합니다. 1. [**Delete Health Check**]를 선택합니다. 1. 확인하려면 [**Yes, Delete**]를 선택합니다. ------ # DNS 장애 조치 구성 시 상태 확인 업데이트 또는 삭제 레코드와 연결된 상태 확인을 업데이트 또는 삭제하거나 상태 확인을 연결한 레코드를 변경할 때는 변경 사항이 DNS 쿼리의 라우팅 및 DNS 장애 조치 구성에 어떤 영향을 미치는지 반드시 고려해야 합니다. **중요** Route 53는 상태 확인이 하나 이상의 레코드와 연결된 경우에도 상태 확인 삭제를 방지하지 않습니다. 상태 확인을 삭제하고 연결된 레코드를 업데이트하지 않는 경우 상태 확인의 향후 상태가 예측될 수 없으며 변경될 수 있습니다. 이는 DNS 장애 조치 구성에 대한 DNS 쿼리 라우팅에 영향을 미칩니다. 레코드와 이미 연결된 상태 확인을 업데이트 또는 삭제하려면 다음 작업을 수행하는 것이 좋습니다. 1. 상태 확인과 연결된 레코드를 찾습니다. 상태 확인과 연결된 레코드를 찾으려면 다음 중 하나를 반드시 수행해야 합니다. + Route 53 콘솔을 사용하여 각 호스팅 영역에서 레코드를 검토합니다. 자세한 내용은 [레코드 나열](resource-record-sets-listing.md) 단원을 참조하십시오. + 각 호스팅 영역에서 `ListResourceRecordSets` API 작업을 실행하여 그 반응을 살핍니다. 자세한 내용은 *Amazon Route 53 API 참조*에서 [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)를 참조하세요. 1. 상태 확인 업데이트 또는 삭제, 또는 레코드 업데이트로 인한 동작의 변화를 평가합니다. 평가를 기반으로 변경할 사항을 결정합니다. 자세한 내용은 [상태 확인을 생략하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting) 섹션을 참조하세요. 1. 해당하는 상태 확인 및 레코드를 변경합니다. 자세한 내용은 다음 항목을 참조하세요. + [상태 확인의 생성 및 업데이트](health-checks-creating.md) + [레코드 편집](resource-record-sets-editing.md) 1. 사용하지 않는 상태 확인이 있다면, 삭제합니다. 자세한 내용은 [상태 확인 삭제](health-checks-deleting.md) 단원을 참조하십시오. # Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성 Route 53는 엔드포인트의 상태를 점검할 때, 상태 확인 생성 시에 지정한 IP 주소 및 포트에 HTTP, HTTPS, 또는 TCP 요청을 전송합니다. 상태 확인이 성공하려면 라우터 및 방화벽 규칙은 Route 53 상태 확인 프로그램이 사용하는 IP 주소에서 오는 인바운드 트래픽을 반드시 허용해야 합니다. Route 53 상태 확인 프로그램의 현재 IP 주소 목록, Route 53 이름 서버 및 기타 AWS 서비스의 경우 섹션을 참조하세요[Amazon Route 53 서버의 IP 주소 범위](route-53-ip-addresses.md). Amazon EC2에서 보안 그룹은 방화벽과 같은 역할을 합니다. 자세한 내용은 [Amazon EC2 사용 설명서의 Amazon EC2 보안 그룹을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) 참조하세요. Route 53 상태 확인을 허용하도록 보안 그룹을 구성하려면 각 IP 주소 범위의 인바운드 트래픽을 허용하거나 AWS관리형 접두사 목록을 사용할 수 있습니다. *Amazon EC2 * AWS관리형 접두사 목록을 사용하려면의 인바운드 트래픽을 허용하도록 보안 그룹을 수정합니다. `com.amazonaws..route53-healthchecks`여기서 ` `는 Amazon EC2 인스턴스 또는 리소스 AWS 리전 의 입니다. Route 53 상태 확인을 사용하여 IPv6 엔드포인트를 확인하는 경우 `com.amazonaws..ipv6.route53-healthchecks`로부터의 인바운드 트래픽도 허용해야 합니다. AWS관리형 접두사 목록에 대한 자세한 내용은 *Amazon VPC 사용 설명서*의 [AWS관리형 접두사 목록 작업을 ](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) 참조하세요. **중요** 허용된 IP 주소 목록에 IP 주소를 추가할 때 상태 확인을 생성할 때 지정한 각 AWS 리전의 CIDR 범위에 있는 모든 IP 주소와 글로벌 CIDR 범위를 추가합니다. 상태 확인 요청은 한 리전의 한 IP 주소에서만 제공됩니다. 그러나 해당 IP 주소는 언제든지 해당 리전의 다른 IP 주소로 변경될 수 있습니다. 현재 및 이전 상태 확인 프로그램 IP 주소를 모두 포함하려면 모든 /26 및 /18 IP 주소 범위를 허용 목록에 추가합니다. 자세한 내용은 *AWS 일반 참조*의 [AWS IP 주소 범위](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)를 참조하세요. AWS관리형 접두사 목록을 인바운드 보안 그룹에 추가하면 필요한 모든 범위가 자동으로 추가됩니다. # DNS 장애 조치 구성 동일한 기능을 수행하는 2개 이상의 리소스(예: 1개 이상의 HTTP 서버 또는 메일 서버)가 있는 경우, Amazon Route 53를 구성하여 리소스들의 상태를 확인하고 정상적인 리소스만을 사용하여 DNS 쿼리에 응답하도록 할 수 있습니다. 예를 들어, 전 세계에 3개의 데이터 센터에서 각각 2개의 서버, 즉 6개의 서버 상에서 example.com라는 웹 사이트가 호스팅된다고 가정합니다. 이러한 서버들의 상태를 확인하고 현재 정상적인 서버만을 사용하여 example.com에 대한 DNS 쿼리에 응답하도록 Route 53를 구성할 수 있습니다. Route 53는 단순 구성 및 복잡 구성 모두에서 리소스의 상태를 확인할 수 있습니다. + 단순 구성에서 이름과 유형이 모두 동일한 레코드의 그룹(예: 유형이 A인 example.com에 대한 가중치 기반 레코드의 그룹)을 생성합니다. 그런 다음 Route 53를 구성해 해당 리소스의 상태를 확인합니다. Route 53는 리소스의 상태를 기반으로 DNS 쿼리에 응답합니다. 자세한 내용은 [단순 Amazon Route 53 구성에서 상태 확인 작동 방식단순 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md) 섹션을 참조하세요. + 더욱 복잡한 구성에서는 여러 기준을 기반으로 트래픽을 라우팅하는 레코드 트리를 생성합니다. 예를 들어, 사용자에 대한 지연 시간이 가장 중요한 기준인 경우 지연 시간 별칭 레코드를 사용하여 최적의 지연 시간을 제공하는 리전으로 트래픽을 라우팅할 수 있습니다. 지연 시간 별칭 레코드에서 각 리전의 가중치 기반 레코드를 별칭 대상으로 보유할 수 있습니다. 가중치 기반 레코드는 인스턴스 유형을 기반으로 트래픽을 EC2 인스턴스로 라우팅할 수 있습니다. 단순 구성에서와 마찬가지로 Route 53가 리소스 상태를 기반으로 트래픽을 라우팅하도록 구성할 수 있습니다. 자세한 내용은 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 섹션을 참조하세요. **Topics** + [DNS 장애 조치 구성을 위한 작업 목록](dns-failover-how-to.md) + [단순 Amazon Route 53 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md) + [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식](dns-failover-complex-configs.md) + [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) + [액티브-액티브 및 액티브-패시브 장애 조치](dns-failover-types.md) + [프라이빗 호스팅 영역에서 장애 조치 구성](dns-failover-private-hosted-zones.md) + [Amazon Route 53가 장애 조치 문제를 방지하는 방법](dns-failover-problems.md) # DNS 장애 조치 구성을 위한 작업 목록 Route 53를 사용하여 DNS 장애 조치를 구성하려면 다음 작업을 수행하세요. 1. 구성에 대한 완전한 트리 다이어그램을 그리고 각 노드마다 어떤 유형의 레코드(가중치 기반 별칭, 장애 조치, 지연 시간 등)를 생성하는지 나타냅니다. 트리 상단에 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 도메인 이름(예: example.com)에 대한 레코드를 놓습니다. 트리 다이어그램에 표시되는 레코드의 종류는 구성의 복잡성에 따라 다릅니다. + 단순 구성에서 다이어그램에 어떠한 별칭 레코드도 포함하지 않거나 별칭 레코드가 다른 Route 53 레코드 대신 ELB 로드 밸런서와 같은 리소스에 직접 트래픽을 라우팅합니다. 자세한 내용은 [단순 Amazon Route 53 구성에서 상태 확인 작동 방식단순 구성에서 상태 확인 작동 방식](dns-failover-simple-configs.md) 섹션을 참조하세요. + 복잡한 구성에서는 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 주제의 예제처럼 다중 트리에서 별칭 레코드(가중치 기반 별칭, 장애 조치 별칭 등)와 비 별칭 레코드의 조합이 다이어그램에 포함됩니다. **참고** 복잡한 라우팅 구성에 대한 레코드를 빠르고 쉽게 생성한 후 상태 확인에 연결하려면 트래픽 흐름 시각적 편집기를 사용하고 구성을 트래픽 정책으로 저장할 수 있습니다. 그런 다음 동일한 호스팅 영역이나 여러 호스팅 영역의 하나 이상의 도메인 이름(예: example.com) 또는 하위 도메인 이름(예: www.example.com)과 해당 트래픽 정책을 연결할 수 있습니다. 새 구성이 예상대로 수행되지 않을 경우 업데이트를 롤백할 수도 있습니다. 자세한 내용은 [트래픽 흐름을 사용하여 DNS 트래픽 라우팅](traffic-flow.md) 섹션을 참조하세요. 자세한 내용은 다음 설명서를 참조하세요. + [라우팅 정책 선택](routing-policy.md) + [별칭 또는 비 별칭 레코드 선택](resource-record-sets-choosing-alias-non-alias.md) 1. 데이터 센터에서 실행 중인 Amazon EC2 서버 및 이메일 서버와 같은 별칭 레코드를 생성할 수 없는 리소스의 상태 확인을 생성합니다. 이러한 상태 확인을 비 별칭 레코드와 연결합니다. 자세한 내용은 [상태 확인의 생성, 업데이트 및 삭제](health-checks-creating-deleting.md) 섹션을 참조하세요. 1. 필요한 경우 상태 확인에서 지정한 엔드포인트에 대해 Route 53가 규칙적으로 요청을 전송할 수 있도록 하기 위해서는 라우터 및 방화벽 규칙을 구성합니다. 자세한 내용은 [Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성상태 확인을 위한 라우터 및 방화벽 규칙 구성](dns-failover-router-firewall-rules.md) 섹션을 참조하세요. 1. 다이어그램에서 비 별칭 레코드 전체를 생성하고 2단계에서 생성한 상태 확인을 해당 레코드와 연결합니다. 별칭 레코드가 없는 단순 구성에서 DNS 장애 조치를 구성하는 경우 남은 작업을 건너뜁니다. 1. ELB 로드 밸런서 및 CloudFront 배포와 같은 AWS 리소스로 트래픽을 라우팅하는 별칭 레코드를 생성합니다. 리소스가 비정상일 때 Route 53가 트리의 다른 가지를 시도하도록 하려면 별칭 레코드 각각에 대해 **대상 상태 평가(Evaluate Target Health)** 값을 **예(Yes)**로 설정합니다. (일부 AWS 리소스에서는 **대상 상태 평가가** 지원되지 않습니다.) 1. 1단계에서 생성한 트리 다이어그램의 하단에서 4단계와 5단계에서 생성한 레코드로 트래픽을 라우팅하는 별칭 레코드를 생성합니다. 비 별칭 레코드 전체가 트리의 가지에서 비정상인 경우 Route 53가 트리의 다른 가지를 시도하도록 하려면 별칭 레코드 각각에 대해 **대상 상태 평가(Evaluate Target Health)**의 값을 **예(Yes)**로 설정합니다. 다른 레코드를 생성하기 전까지 다른 레코드로 트래픽을 라우팅하는 별칭 레코드를 생성할 수 없다는 것에 유의하십시오. # 단순 Amazon Route 53 구성에서 상태 확인 작동 방식 동일한 기능을 수행하는 둘 이상의 리소스(예: example.com에 대한 둘 이상의 웹 서버)가 있으면 다음 상태 확인 기능을 사용하여 트래픽을 정상적인 리소스에만 라우팅할 수 있습니다. **EC2 인스턴스 및 기타 리소스(비 별칭 레코드)의 상태 확인** EC2 인스턴스와 같이 별칭 레코드를 생성할 수 없는 리소스로 트래픽을 라우팅하는 경우 각 리소스에 대해 레코드 및 상태 확인을 생성합니다. 그런 다음 각 상태 확인을 해당 레코드와 연결합니다. 상태 확인은 해당 리소스의 상태를 주기적으로 확인하고, Route 53는 상태 확인 보고에 따라 정상인 리소스에만 트래픽을 라우팅합니다. ** AWS 리소스의 상태 평가(별칭 레코드)** [별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 사용하여 ELB 로드 밸런서와 같은 선택한 AWS 리소스로 트래픽을 라우팅하는 경우 리소스의 상태를 평가하고 정상인 리소스로만 트래픽을 라우팅하도록 Route 53을 구성할 수 있습니다. 별칭 레코드를 구성하여 리소스의 상태를 확인하는 경우 리소스에 대한 상태 확인을 생성할 필요가 없습니다. 단순 구성에서 Route 53가 리소스의 상태를 확인하도록 구성하는 방법에 대한 개요입니다. 1. Route 53가 모니터링할 리소스를 식별합니다. 예컨대 example.com 대한 요청에 응답하는 HTTP 서버 전체를 모니터링하기 원할 수도 있습니다. 1. 고유 데이터 센터의 EC2 인스턴스 또는 서버와 같은 레코드의 별칭을 생성할 수 없는 리소스의 상태 확인을 생성합니다. 리소스에 상태 확인 요청을 전송하는 방법을 지정합니다. 즉, 사용할 프로토콜(HTTP, HTTPS, 또는 TCP), 사용할 IP 주소 및 포트, 그리고 HTTP/HTTPS 상태 확인을 위한 도메인 이름 및 경로를 알려줍니다. **참고** ELB 로드 밸런서와 같이 별칭 레코드를 생성할 수 있는 리소스를 사용하는 경우 이러한 리소스에 대한 상태 확인을 생성하지 않습니다. 기본 구성은 각 리소스마다 하나의 상태 확인을 생성하고 리소스마다 상태 확인 엔드포인트를 위한 동일한 IP 주소를 사용하는 것입니다. 상태 확인은 지정된 IP 주소로 요청을 전송합니다. **참고** Route 53는 IP 주소가 로컬, 프라이빗, 라우팅 불가, 또는 멀티캐스트 범위에 있는 리소스의 상태는 확인할 수 없습니다. 상태 확인을 생성할 수 없는 IP 주소에 대한 자세한 내용은 [RFC 5735, Special Use IPv4 Addresses](https://datatracker.ietf.org/doc/html/rfc5735)와 [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](https://datatracker.ietf.org/doc/html/rfc6598)를 참조하십시오. 상태 확인 생성에 대한 자세한 내용은 [상태 확인의 생성, 업데이트 및 삭제](health-checks-creating-deleting.md) 단원을 참조하십시오. 1. 상태 확인에서 지정한 엔드포인트에 대해 Route 53가 규칙적으로 요청을 전송할 수 있도록 하기 위해서는 라우터 및 방화벽 규칙을 구성할 필요가 있을 수 있습니다. 자세한 내용은 [Amazon Route 53 상태 확인을 위한 라우터 및 방화벽 규칙 구성상태 확인을 위한 라우터 및 방화벽 규칙 구성](dns-failover-router-firewall-rules.md) 섹션을 참조하세요. 1. 리소스(예: 가중치 기반 레코드 그룹)에 대한 레코드 그룹을 생성합니다. 별칭 및 비 별칭 레코드를 조합할 수 있습니다. 하지만 모두 동일한 [**Name**], [**Type**] 및 [**Routing Policy**] 값을 보유해야 합니다. Route 53가 리소스의 상태를 확인하도록 구성하는 방법은 별칭 레코드 또는 비 별칭 레코드 생성 여부에 따라 다릅니다. + **별칭 레코드(Alias records)** - **대상 상태 평가(Evaluate Target Health)**를 **예(Yes)**로 지정합니다. + **비 별칭 레코드(Non-alias records)** - 2단계에서 생성한 상태 확인을 해당 레코드와 연결합니다. 완료되면 구성은 다음 다이어그램과 비슷해지며, 비 별칭 레코드만을 포함합니다. ![\[3개의 가중치 기반 레코드 및 해당 상태 확인.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted.png) Route 53 콘솔을 사용하여 레코드를 생성하는 방법에 대한 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 섹션을 참조하세요. 1. 상태 확인을 생성한 경우 Route 53는 각 상태 확인 시 엔드포인트로 요청을 주기적으로 전송하지만, DNS 쿼리를 수신할 때는 상태 확인을 수행하지 않습니다. Route 53는 응답을 근거로 엔드포인트가 정상인지 판단하고 그 정보를 이용하여 어떻게 쿼리에 응답할 것인지 결정합니다. 자세한 내용은 [Amazon Route 53가 상태 확인이 정상인지 여부를 판단하는 방법Route 53에서 상태 확인이 정상인지 여부를 판단하는 방법](dns-failover-determining-health-of-endpoints.md) 섹션을 참조하세요. Route 53는 example.com의 A 레코드에서 지정된 IP 주소와 같이 레코드에 지정된 리소스의 상태를 확인하지 않습니다. 상태 확인을 레코드와 연결하면 Route 53는 상태 확인에서 지정한 엔드포인트의 상태를 확인하기 시작합니다. 또한 Route 53가 다른 상태 확인의 상태 또는 CloudWatch 경보의 데이터 스트림을 모니터링하도록 구성할 수도 있습니다. 자세한 내용은 [Amazon Route 53 상태 확인 유형상태 확인의 유형](health-checks-types.md) 섹션을 참조하세요. Route 53가 example.com에 대한 쿼리를 수신할 때 다음 현상이 발생합니다. 1. Route 53는 라우팅 정책을 기반으로 레코드를 선택합니다. 이 경우에는 가중치를 기반으로 레코드를 선택합니다. 1. 선택한 레코드에 대한 상태 확인의 상태를 확인하여 해당 레코드의 현재 상태를 판단합니다. 1. 선택한 레코드가 비정상인 경우 Route 53는 다른 레코드를 선택합니다. 이 경우 비정상적인 레코드는 고려 대상이 아닙니다. 자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 섹션을 참조하세요. 1. Route 53가 정상인 레코드를 찾으면 A 레코드의 IP 주소와 같이 해당되는 값으로 쿼리에 응답합니다. 다음 예제에서는 세 번째 레코드가 비정상적인 가중치 기반 레코드의 그룹을 보여 줍니다. 처음에 Route 53는 3개의 레코드 전체의 가중치를 기반으로 레코드를 선택합니다. 처음에 비정상적인 레코드를 선택하는 일이 발생하면 Route 53는 다른 레코드를 선택하지만 이번에는 세 번째 레코드의 가중치를 계산에서 제외합니다. + Route 53가 처음에 3개의 레코드 전체 중에서 선택할 때는 10/(10 \$1 20 \$1 20)이라는 시간의 약 20% 동안만 최초 레코드를 사용하여 요청에 응답합니다. + 이 세 번째 레코드가 비정상이라고 판단할 때는 10/(10 \$1 20)이라는 시간의 약 33% 동안만 최초 레코드를 사용하여 요청에 응답합니다. ![\[3개의 가중치 기반 레코드 및 해당 상태 확인. 세 번째 상태 확인이 비정상이기 때문에 Route 53은 연결된 레코드가 비정상이라 간주합니다.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png) 레코드 그룹에서 1개 이상의 레코드에 대한 상태 확인을 생략한 경우 Route 53가 해당 리소스의 상태를 확인할 방법이 없습니다. Route 53에서는 해당 레코드를 정상으로 취급합니다 ![\[3개의 가중치 기반 레코드, 그 중 둘만이 상태 확인 보유. Route 53은 항상 세 번째 레코드를 정상으로 간주합니다.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png) # 상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식 복잡한 구성에서 리소스의 상태를 확인하는 것은 단순한 구성에 이루어지는 방식과 상당 부분 같습니다. 그러나 복잡한 구성에서는 별칭 레코드(가중치 기반 별칭, 장애 조치 별칭 등)와 비 별칭 레코드의 조합을 사용하여 Route 53가 요청에 응답하는 방식을 더 잘 제어할 수 있게 해주는 판단 트리를 구축합니다. 예를 들어 지연 시간 별칭 레코드를 사용하여 사용자에게 가까운 리전을 선택하고 각 리전 내의 둘 이상의 리소스에 대한 가중치 기반 레코드를 사용하여 단일 엔드포인트 또는 가용 영역의 실패를 방지할 수 있습니다. 다음 다이어그램은 이 구성을 보여줍니다. ![\[지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png) Amazon EC2 및 Route 53가 구성되는 방법은 다음과 같습니다. 트리의 하단에서 시작합니다. 레코드를 생성하는 순서이기 때문입니다. + us-east-1 및 ap-southeast-2의 두 리전 각각에서 2개의 EC2 인스턴스를 갖습니다. Route 53가 정상 여부를 기반으로 EC2 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대해 상태 확인을 생성합니다. 각 상태 확인을 구성하여 상태 확인 요청을 해당 인스턴스의 탄력적 IP 주소에 있는 해당 인스턴스로 전송합니다. Route 53는 전역 서비스이므로 상태 확인을 생성하고자 하는 리전을 지정하지 않습니다. + 인스턴스 유형을 기반으로 각 리전에 있는 2개의 인스턴스로 트래픽을 라우팅하고자 하는 경우 각 인스턴스에 대한 가중치 기반 레코드를 생성하고 각 레코드에 가중치를 부여합니다. (이후 가중치를 변경하여 인스턴스로의 트래픽 라우팅을 늘리거나 줄일 수 있습니다.) 또한 해당 상태 확인을 각 인스턴스와 연결합니다. 레코드를 생성할 때 us-east-1-www.example.com 및 ap-southeast-2-www.example.com과 같은 이름을 사용합니다. 레코드에 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정하려면 트리 상단으로 이동할 때까지 기다립니다. + 사용자에 대해 가장 낮은 지연 시간을 제공하는 리전으로 트래픽을 라우팅하고자 하는 경우 트리 상단에서 레코드에 대한 지연 시간 [라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)을 선택합니다. 직접 각 리전의 *리소스*가 아니라 각 리전의 *레코드*로 트래픽을 라우팅하고자 합니다(이미 가중치 기반 레코드가 이를 수행하고 있음). 그 결과 지연 시간 [별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 생성합니다. 별칭 레코드를 생성할 때 사용자가 웹 사이트 또는 웹 애플리케이션에 액세스하는 데 사용하는 이름(예: example.com)을 지정합니다. 별칭 레코드는 example.com에 대한 트래픽을 us-east-1-www.example.com 및 ap-southeast-2-www.example.com 레코드로 라우팅합니다. 지연 시간 별칭 레코드 모두에 대해 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다. 이렇게 하면 Route 53는 트래픽 라우팅을 시도하기 전에 리전에 정상 리소스가 있는지 여부를 확인합니다. 정상 리소스가 없는 경우 Route 53는 다른 리전의 정상 리소스를 선택합니다. ![\[지연 시간 별칭 레코드와 가중치 기반 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png) 앞의 다이어그램에서는 이벤트들의 순서를 다음과 같이 보여줍니다. 1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다. 1. Route 53는 가중치를 기반으로 가중치 기반 레코드를 선택합니다. **대상 상태 평가(Evaluate Target Health)**는 지연 시간 별칭 레코드에 대해 **예(Yes)**이므로 Route 53는 선택한 가중치 기반 레코드의 상태를 확인합니다. 1. 상태 확인이 실패했으므로 Route 53는 가중치를 기반으로 다른 가중치 기반 레코드를 선택하여 그 상태를 확인합니다. 해당 레코드 역시 비정상입니다. 1. Route 53는 트리의 가지를 포기하고 차선의 지연 시간을 지닌 지연 시간 별칭 레코드를 찾아 ap-southeast-2에 대한 레코드를 선택합니다. 1. Route 53는 다시 가중치를 기반으로 레코드를 선택한 다음 선택한 리소스의 상태를 확인합니다. 리소스가 정상이므로 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다. **Topics** + [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](#dns-failover-complex-configs-hc-alias) + [상태 확인을 생략하면 어떻게 됩니까?](#dns-failover-complex-configs-hc-omitting) + [[Evaluate Target Health]를 [No]로 설정하면 어떻게 됩니까?](#dns-failover-complex-configs-eth-no) ## 상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까? [**Evaluate Target Health**]의 값을 [**Yes**]로 설정하는 작업 대신 또는 이 작업 외에 상태 확인을 별칭 레코드와 연결할 수 있습니다. 그러나 Route 53가 기본 리소스(별칭 레코드가 참조하는 HTTP 서버, 데이터베이스 서버, 및 기타 리소스)의 상태에 따라 쿼리에 반응한다면 대개의 경우 더 유용합니다. 예를 들어, 다음과 같은 구성을 가정해 봅시다. + 별칭 대상이 가중치 기반 레코드의 그룹인 지연 시간 별칭 레코드에 상태 확인을 할당합니다. + 지연 시간 별칭 레코드에 대해 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다. 이 구성에서는 Route 53가 가중치 기반 레코드에 해당하는 값을 반환하기 전에 다음 두 가지가 모두 참이어야 합니다. + 지연 시간 별칭 레코드와 연결된 상태 확인이 통과되어야 합니다. + 통과하는 상태 확인과 연결되어 있거나 상태 확인과 연결되어 있지 않기 때문에 한 개 이상의 가중치 기반 레코드가 정상 상태로 간주되어야 합니다. 후자의 경우 Route 53는 항상 가중치 기반 레코드를 정상 상태로 간주합니다. 다음 그림에서 왼쪽 상단에 있는 지연 시간 별칭 레코드에 대한 상태 확인이 실패했습니다. 그 결과 Route 53는 가중치 기반 레코드가 모두 정상인 경우에도 지연 시간 별칭 레코드가 참조하는 가중치 기반 레코드를 사용하여 쿼리에 응답하는 것을 중단합니다. Route 53는 지연 시간 별칭 레코드에 대한 상태 확인이 다시 정상인 경우에만 이러한 가중치 기반 레코드를 다시 고려하기 시작합니다. (예외 사항은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 단원을 참조하십시오.) ![\[두 Evaluate Target Health(대상 상태 평가)가 모두 예로 설정되어 있는 별칭 레코드와 별칭 레코드에 대한 상태 확인을 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png) ## 상태 확인을 생략하면 어떻게 됩니까? 복잡한 구성에서는 상태 확인을 비 별칭 레코드 전체에 연결하는 것이 중요합니다. 다음 예제에서 us-east-1 리전에서 가중치 기반 레코드 중 하나에 대한 상태 확인이 누락되었습니다. ![\[실패한 상태 확인 1개와 상태 확인이 없는 레코드 1개를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png) 이 구성에서 비 별칭 레코드에 대한 상태 확인을 생략할 때 발생하는 일은 다음과 같습니다. 1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다. 1. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상을 찾아서 해당 상태 확인의 상태를 확인합니다. 한 개의 가중치 기반 레코드에 대한 상태 확인이 실패했으므로 레코드는 고려 대상에서 생략됩니다. 1. us-east-1 리전에 대한 별칭 대상에서 기타 가중치 기반 레코드에는 상태 확인이 없습니다. 해당 리소스는 정상이거나 비정상이겠지만, 상태 확인이 없으면 Route 53는 알 방법이 없습니다. 리소스가 정상으로 가정하여 Route 53는 쿼리에 응답해 해당하는 값을 반환합니다. ## [Evaluate Target Health]를 [No]로 설정하면 어떻게 됩니까? 일반적으로 트리의 모든 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정해야 합니다. **대상 상태 평가(Evaluate Target Health)**를 **아니요(No)**로 설정한 경우 레코드에 대한 상태 확인이 실패하는 경우에도 Route 53는 계속해서 별칭 레코드가 참조하는 레코드로 트래픽을 라우팅합니다. 다음 예제에서는 가중치 기반 레코드 전체가 상태 확인과 연결되었지만 us-east-1 리전의 지연 시간 별칭 레코드에 대해 [**Evaluate Target Health**]가 [**No**]로 설정되어 있습니다. ![\[Evaluate Target Health(대상 상태 평가)가 아니요로 설정된 별칭 레코드를 포함하는 DNS 구성.\]](http://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png) 이 구성에서 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**No**]로 설정할 때 발생하는 일은 다음과 같습니다. 1. Route 53는 example.com에 대한 쿼리를 수신합니다. Route 53는 요청을 보내는 사용자의 지연 시간을 기반으로 us-east-1 리전에 대한 지연 시간 별칭 레코드를 선택합니다. 1. Route 53는 지연 시간 별칭 레코드에 대한 별칭 대상이 무엇인지 판단하여 해당 상태 확인을 확인합니다. 둘 다 실패합니다. 1. us-east-1 리전의 지연 시간 별칭 레코드에 대해 **대상 상태 평가(Evaluate Target Health)**의 값이 **아니요(No)**로 설정되어 있으므로 Route 53는 가지를 포기하고 ap-southeast-2 리전의 정상적인 레코드를 찾는 대신 이 가지에서 하나의 레코드를 선택해야 합니다. # 상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식 동일한 이름, 동일한 유형(예: A 또는 AAAA) 및 동일한 라우팅 정책(예: 가중치 또는 장애 조치)을 보유한 레코드 그룹의 모든 레코드에 대한 상태 확인을 구성한 경우 Route 53는 정상 레코드를 선택하고 해당 레코드로부터 해당되는 값을 반환함으로써 DNS 쿼리에 응답합니다. 예를 들어, 3개의 가중치 A 레코드를 생성하고 세 레코드 모두에 상태 확인을 할당한다고 가정합니다. 한 레코드의 상태 확인이 비정상인 경우 Route 53는 다른 2개 레코드의 IP 주소를 통해 DNS 쿼리에 응답합니다. 다음은 Route 53가 정상적인 레코드를 선택하는 방식입니다. 1. Route 53는 처음에 라우팅 정책과 각 레코드에 대해 지정한 값을 기반으로 레코드를 선택합니다. 예를 들어, 가중치 레코드의 경우 Route 53는 각 레코드에 대해 지정한 가중치를 기반으로 레코드를 선택합니다. 1. Route 53가 레코드가 정상이라 확인한 경우: + **상태 확인이 연결된 비 별칭 레코드** - 상태 확인과 비 별칭 레코드를 연결한 경우 Route 53는 상태 확인의 현재 상태를 확인합니다. Route 53는 상태 확인에 지정된 엔드포인트의 상태를 주기적으로 점검하는데, DNS 쿼리가 도착할 때는 상태 확인을 수행하지 않습니다. 상태 확인과 별칭 레코드를 연결할 수 있지만 상태 확인과 비 별칭 레코드만을 연결하는 것이 좋습니다. 자세한 내용은 [상태 확인을 별칭 레코드와 연결하면 어떻게 됩니까?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias) 섹션을 참조하세요. + **대상 상태 평가가 예로 설정된 별칭 레코드** - Route 53는 ELB 로드 밸런서 또는 동일한 호스팅 영역의 또 다른 레코드와 같이 별칭 레코드가 참조하는 리소스의 상태를 확인합니다. 1. 레코드가 정상인 경우 Route 53는 IP 주소와 같이 해당되는 값으로 쿼리에 응답합니다. 레코드가 비정상인 경우 Route 53는 동일한 기준을 사용하여 또 다른 레코드를 선택하고 정상 레코드를 찾을 때까지 프로세스를 반복합니다. Route 53는 레코드 선택 시 다음 기준을 사용합니다. **항상 정상인 상태 확인이 없는 레코드** 동일한 이름과 유형을 보유한 레코드 그룹의 레코드에 연결된 상태 확인이 없는 경우 Route 53는 항상 이를 정상으로 여기고 쿼리에 대한 가능한 응답에 항상 이를 포함시킵니다. **정상인 레코드가 없는 경우 모두 레코드가 정상임** 레코드 그룹의 레코드가 정상이 아닌 경우 Route 53는 DNS 쿼리에 대한 응답으로 무언가를 반환해야 하지만 한 레코드에 견주어 다른 레코드를 선택할 근거가 없습니다. 이런 상황에서 Route 53는 그룹의 레코드 전체를 정상으로 간주하고 라우팅 정책과 각 레코드에 지정한 값을 기반으로 하나의 레코드를 선택합니다. **가중치가 0인 가중치 기반 레코드** 가중치 기반 레코드의 그룹에서 레코드 전체에 상태 확인을 추가하지만 어떤 레코드에는 0이 아닌 가중치를 부여하고 또 다른 레코드에는 0인 가중치를 부여하는 경우 상태 확인은 모든 레코드의 가중치가 0일 때와 동일하게 작업합니다. 단, 다음 경우는 예외입니다. + Route 53는 처음에 0이 아닌 가중치 기반 레코드만을 고려합니다(해당되는 경우). + 0보다 큰 가중치를 지닌 레코드 전체가 비정상인 경우 Route 53는 0인 가중치 기반 레코드를 고려합니다. Route 53은 상황에 따라 가중치가 0인 레코드를 고려하므로 가중치가 0인 대상에도 DNS 쿼리에 대한 실행 가능한 응답이 있는지 확인하는 것이 중요합니다. 가중치 기반 레코드에 대한 자세한 내용은 [상태 확인 및 가중치 기반 라우팅](routing-policy-weighted.md#routing-policy-weighted-healthchecks)을 참조하십시오. **별칭 레코드** 각 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정함으로써 별칭 레코드에 대한 상태 확인을 구성할 수도 있습니다. 이로 인해 Route 53는 ELB 로드 밸런서 또는 동일한 호스팅 영역의 또 다른 레코드와 같이 레코드가 트래픽을 라우팅하는 리소스의 상태를 확인합니다. 예를 들어, 별칭 레코드에 대한 별칭 대상이 0이 아닌 가중치를 모두 지닌 가중치 기반 레코드의 그룹인 경우를 가정해 봅시다. + 하나 이상의 가중치 기반 레코드가 정상인 경우 Route 53는 별칭 레코드를 정상 상태로 간주합니다. + 가중치 기반 레코드가 정상이 아닌 경우 Route 53는 별칭 레코드를 비정상 상태로 간주합니다. + Route 53는 하나 이상의 가중치 기반 레코드가 다시 정상이 될 때까지 트리의 가지에 있는 레코드에 대한 판단을 중지합니다. 자세한 내용은 [상태 확인이 복잡한 Amazon Route 53 구성에서 작동하는 방식상태 확인이 복잡한 구성에서 작동하는 방식](dns-failover-complex-configs.md) 섹션을 참조하세요. **장애 조치 레코드** 장애 조치 레코드는 일반적으로 다른 라우팅 유형과 동일한 방식으로 작동합니다. 상태 확인을 생성하고 이를 비 별칭 레코드와 연결한 다음 별칭 레코드에 대해 [**Evaluate Target Health**]를 [**Yes**]로 설정합니다. 다음 사항에 유의하세요. + 기본 및 보조 레코드는 모두 비 별칭 레코드 또는 별칭 레코드일 수 있습니다. + 기본 및 보조 장애 조치 레코드와 상태 확인을 연결하는 경우 Route 53가 요청에 응답하는 방식은 다음과 같습니다. + Route 53가 기본 레코드를 정상 상태로 간주하는 경우(상태 확인 엔드포인트가 정상인 경우) Route 53는 DNS 쿼리에 대한 응답으로 기본 레코드만 반환합니다. + Route 53가 기본 레코드를 비정상 상태로 간주하고 보조 레코드를 정상 상태로 간주하는 경우 Route 53는 그 대신에 보조 레코드를 반환합니다. + Route 53가 기본 및 보조 레코드를 모두 비정상 상태로 간주하는 경우 Route 53는 기본 레코드를 반환합니다. + 보조 레코드를 구성할 때 상태 확인 추가는 선택 사항입니다. 보조 레코드에 대한 상태 확인을 생략하고 기본 레코드에 대한 상태 확인 엔드포인트가 비정상인 경우 Route 53는 항상 보조 레코드를 사용하여 DNS 쿼리에 응답합니다. 이는 보조 레코드가 비정상인 경우라 할지라도 그대로 적용됩니다. 자세한 내용은 다음 항목을 참조하세요. + [하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](dns-failover-types.md#dns-failover-types-active-passive-one-resource) + [여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources) # 액티브-액티브 및 액티브-패시브 장애 조치 Route 53 상태 확인을 사용하여 액티브-액티브 및 액티브-패시브 장애 조치 구성을 구성할 수 있습니다. 장애 조치를 제외한 모든 [라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)(또는 라우팅 정책의 조합)을 사용하여 액티브-액티브 장애 조치를 구성하고, 장애 조치 라우팅 정책을 사용하여 액티브-패시브 장애 조치를 구성합니다. **Topics** + [액티브-액티브 장애 조치](#dns-failover-types-active-active) + [액티브-패시브 장애 조치](#dns-failover-types-active-passive) ## 액티브-액티브 장애 조치 모든 리소스를 대부분의 시간 동안 사용 가능하도록 하려면 이 장애 조치 구성을 사용하십시오. 리소스를 사용할 수 없는 경우 Route 53가 비정상 상태임을 판별하여 쿼리에 응답할 때 해당 리소스를 포함하지 않습니다. 액티브-액티브 장애 조치에서 동일한 이름, 동일한 유형(예: A 또는 AAAA) 및 동일한 라우팅 정책(예: 가중치 또는 지연 시간)을 보유한 모든 레코드는 Route 53가 이를 비정상으로 간주하지 않는 이상 활성 상태입니다. Route 53는 정상 레코드를 사용하여 DNS 쿼리에 응답할 수 있습니다. ## 액티브-패시브 장애 조치 기본 리소스 또는 리소스 그룹이 대부분의 시간 동안 사용 가능하도록 하고 보조 리소스 또는 리소스 그룹은 기본 리소스가 사용 불가능할 경우를 대비해 대기 중에 있도록 하고 싶다면 이 장애 조치 구성을 사용하십시오. 쿼리에 응답할 때 Route 53는 정상적인 기본 리소스만을 포함합니다. 모든 기본 리소스가 비정상인 경우 Route 53는 DNS 쿼리에 응답할 때 정상적인 보조 리소스만을 포함시키기 시작합니다. **Topics** + [하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-one-resource) + [여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-multiple-resources) + [가중치 레코드를 사용하여 액티브-패시브 장애 조치 구성](#dns-failover-types-active-passive-weighted) ### 하나의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성 하나의 기본 레코드 및 보조 레코드를 사용하여 액티브-패시브 장애 조치를 생성하려면 레코드를 생성하고 라우팅 정책을 **장애 조치**로 지정합니다. 기본 리소스가 정상일 때 Route 53는 기본 레코드를 사용하여 DNS 쿼리에 응답합니다. 기본 리소스가 비정상일 때 Route 53는 보조 레코드를 사용하여 DNS 쿼리에 응답합니다. ### 여러 개의 기본 및 보조 리소스를 사용한 액티브-패시브 장애 조치 구성 여러 개의 리소스를 기본 레코드, 보조 레코드 또는 둘 모두에 연결할 수 있습니다. 이 구성에서 Route 53는 연결된 리소스 중 최소 하나가 정상인 한 기본 장애 조치 레코드를 정상으로 간주합니다. 자세한 내용은 [상태 확인 구성 시 Amazon Route 53의 레코드 선택 방식상태 확인 구성 시 Route 53의 레코드 선택 방식](health-checks-how-route-53-chooses-records.md) 섹션을 참조하세요. 기본 또는 보조 레코드에 대해 여러 리소스를 사용하여 액티브-패시브 장애 조치를 구성하려면 다음 작업을 수행합니다. 1. 데이터 센터의 EC2 인스턴스 또는 웹 서버와 같이 트래픽을 라우팅하고자 하는 각 리소스에 대한 상태 확인을 생성합니다. **참고** [별칭 레코드](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)를 생성할 수 있는 AWS 리소스로 트래픽을 라우팅하는 경우 해당 리소스에 대한 상태 확인을 생성하지 마십시오. 별칭 레코드를 생성할 때 대신 [**Evaluate Target Health**]의 값을 [**Yes**]로 설정합니다. 자세한 내용은 [상태 확인의 생성 및 업데이트](health-checks-creating.md) 섹션을 참조하세요. 1. 기본 리소스에 대한 레코드를 생성하고 다음 값을 지정합니다. + 각 레코드에 동일한 이름, 유형 및 라우팅 정책을 제공합니다. 예를 들어, 이름이 모두 failover-primary.example.com인 3개의 가중치 A 레코드를 생성할 수 있습니다. + 별칭 레코드를 생성할 수 있는 AWS 리소스를 사용하는 경우 대상 상태 평가에 **예를** 지정합니다. **** 별칭 레코드를 생성할 수 없는 리소스를 사용하는 경우 1단계의 해당 상태 확인을 각 레코드와 연결합니다. 자세한 내용은 [Amazon Route 53 콘솔을 사용하여 레코드 생성](resource-record-sets-creating.md) 섹션을 참조하세요. 1. 보조 리소스에 대한 레코드를 생성하고 해당되는 경우 다음 값을 지정합니다. + 각 레코드에 동일한 이름, 유형 및 라우팅 정책을 제공합니다. 예를 들어, 이름이 모두 failover-secondary.example.com인 3개의 가중치 A 레코드를 생성할 수 있습니다. + 별칭 레코드를 생성할 수 있는 AWS 리소스를 사용하는 경우 대상 상태 평가에 **예를** 지정합니다. **** 별칭 레코드를 생성할 수 없는 리소스를 사용하는 경우 1단계의 해당 상태 확인을 각 레코드와 연결합니다. **참고** 일부 고객은 웹 서버를 기본 리소스로 사용하고 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷을 보조 리소스로 사용합니다. S3 버킷에는 단순한 "temporarily unavailable" 메시지가 포함됩니다. 해당 구성을 사용하는 경우 이 단계를 건너뛰고 4단계의 보조 리소스에 대한 장애 조치 별칭 레코드를 생성합니다. 1. 2개의 장애 조치 별칭 레코드(하나는 기본, 다른 하나는 보조)를 생성하고 다음 값을 지정합니다. **기본 레코드** + **이름(Name)** - Route 53가 트래픽을 라우팅하고자 하는 도메인 이름(example.com) 또는 하위 도메인 이름(www.example.com)을 지정합니다. + **별칭(Alias)** - **예(Yes)**로 지정합니다. + **별칭 대상(Alias Target)** - 2단계에서 생성한 레코드의 이름을 지정합니다. + **라우팅 정책(Routing Policy)** - **장애 조치(Failover)**를 지정합니다. + **장애 조치 레코드 유형(Failover Record Type)** - **기본(Primary)**을 지정합니다. + **대상 상태 평가(Evaluate Target Health)** - **예(Yes)**를 지정합니다. + **상태 확인과 연결(Associate with Health Check)** - **아니요(No)**를 지정합니다. **보조 레코드** + **이름(Name)** - 기본 레코드에 대해 지정한 것과 동일한 이름을 지정합니다. + **별칭(Alias)** - **예(Yes)**로 지정합니다. + **별칭 대상(Alias Target)** - 3단계에서 보조 리소스에 대한 레코드를 생성한 경우 해당 레코드의 이름을 지정합니다. 보조 리소스에 대해 Amazon S3 버킷을 사용하는 경우 웹 사이트 엔드포인트의 DNS 이름을 지정합니다. + **라우팅 정책(Routing Policy)** - **장애 조치(Failover)**를 지정합니다. + **장애 조치 레코드 유형(Failover Record Type)** - **보조(Secondary)**를 지정합니다. + **대상 상태 평가(Evaluate Target Health)** - **예(Yes)**를 지정합니다. + **상태 확인과 연결(Associate with Health Check)** - **아니요(No)**를 지정합니다. ### 가중치 레코드를 사용하여 액티브-패시브 장애 조치 구성 경고를 포함하여 액티브-패시브 장애 조치에 대한 가중치 기반 레코드를 사용할 수도 있습니다. 일부 레코드에 대해 0이 아닌 가중치를 지정하고, 나머지 레코드에 대해 0의 가중치를 지정한 경우 Route 53는 0이 아닌 가중치를 가진 정상 레코드만을 사용하여 DNS 쿼리에 응답합니다. 0보다 큰 가중치를 지닌 레코드 전체가 비정상인 경우 Route 53는 가중치가 0인 레코드를 사용하여 쿼리에 응답합니다. **참고** Route 53가 가중치가 0인 레코드를 사용하여 DNS 쿼리에 응답하기 전에 가중치가 0이 아닌 모든 레코드가 비정상이어야 합니다. 다른 리소스를 사용할 수 없을 때 웹 서버와 같은 마지막 정상 리소스가 모든 트래픽을 처리할 수 없는 경우 이로 인해 웹 애플리케이션 또는 웹 사이트가 불안정하게 될 수 있습니다. # 프라이빗 호스팅 영역에서 장애 조치 구성 프라이빗 호스팅 영역에서 장애 조치 레코드를 생성하는 경우 다음에 유의하십시오. + Route 53 상태 확인은 VPC 외부에 있습니다. IP 주소별로 VPC 내에 있는 엔드포인트의 상태를 확인하려면 VPC의 인스턴스에 퍼블릭 IP 주소를 할당해야 합니다. + CloudWatch 지표를 생성하고 경보를 지표와 연결한 다음 경보의 데이터 스트림을 기반으로 하는 상태 확인을 생성할 수 있습니다. 예를 들어, EC2 `StatusCheckFailed` 지표의 상태를 확인하는 CloudWatch 지표를 생성하고 경보를 지표에 추가한 다음 경보의 데이터 스트림을 기반으로 하는 상태 확인을 생성하여 프라이빗 IP 주소만 가지는 Virtual Private Cloud(VPC) 내의 인스턴스를 확인할 수 있습니다. CloudWatch 콘솔을 사용한 CloudWatch 지표 및 경보 생성에 대한 정보는 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)를 참조하십시오. 자세한 내용은 [프라이빗 호스팅 영역 사용](hosted-zones-private.md) 및 [CloudWatch를 이용한 상태 확인 모니터링](monitoring-health-checks.md) 섹션을 참조하세요. # Amazon Route 53가 장애 조치 문제를 방지하는 방법 Route 53가 실행하는 장애 조치 알고리즘은 트래픽을 정상적인 엔드포인트로 라우팅할 뿐만 아니라 상태 확인 및 애플리케이션의 구성 오류, 엔드포인트 오버로드, 분할 오류 등으로 인해 재난 시나리오가 악화되는 것을 방지하기 위해 설계되었습니다. **Topics** + [Amazon Route 53가 Cascading 오류를 방지하는 방법](#dns-failover-cascading-failures) + [Amazon Route 53가 인터넷 분할을 다루는 방식](#dns-failover-internet-partitions) ## Amazon Route 53가 Cascading 오류를 방지하는 방법 Cascading 오류에 대한 1차 방어로, 각 요청 라우팅 알고리즘(가중치, 장애 조치 등)에는 최후의 수단 모드가 있습니다. 이 특수 모드에서 모든 레코드가 비정상 상태로 간주되는 경우 Route 53 알고리즘은 다시 모든 레코드를 정상 상태로 간주하기 시작합니다. 예를 들어 몇 개의 호스트 상에서 애플리케이션의 모든 인스턴스가 상태 확인 요청을 거부하면, Route 53 DNS 서버는 DNS 응답을 반환하지 않거나 NXDOMAIN(존재하지 않는 도메인) 응답을 반환하기보다는 어떻게든 하나의 응답을 선택하여 반환합니다. 애플리케이션은 사용자에게 응답할 수 있지만 여전히 상태 확인에 실패하므로, 이것은 구성 오류를 어느 정도 방지해 줍니다. 마찬가지로 애플리케이션이 오버로드되고 3개 중 1개의 엔드포인트가 상태 확인에 실패하여 Route 53 DNS 응답에서 제외되는 경우에 Route 53는 2개의 남은 엔드포인트 사이에 응답을 분산합니다. 남은 엔드포인트가 추가 로드를 다루지 못하여 실패하게 되면, Route 53는 요청을 다시 3개의 엔드포인트 전체로 분산하기 시작합니다. ## Amazon Route 53가 인터넷 분할을 다루는 방식 비록 흔하지는 않지만 때때로 심각한 인터넷 분할이 발생하는데, 이는 더 큰 지리 지역이 다른 지리 지역과 인터넷상에서 통신할 수 없는 상태를 뜻합니다. 이러한 분할 동안 Route 53 위치는 엔드포인트의 상태에 대해 서로 다른 결론에 도달하여 CloudWatch에 보고되는 상태와 다를 수 있습니다. 각 AWS 리전의 Route 53 상태 확인 프로그램은 상태 확인 상태를 모든 Route 53 위치로 지속적으로 전송합니다. 인터넷 분할이 일어나는 동안에 각 Route 53 위치는 보통 가장 가까운 리전에서 이러한 상태의 일부에만 액세스할 수 있습니다. 예를 들어 남아메리카를 오가는 연결에 영향을 미치는 인터넷 분할 동안 Route 53 남아메리카(상파울루) 위치의 Route 53 DNS 서버들은 남아메리카(상파울루) AWS 리전의 상태 확인 엔드포인트에는 접속이 양호할 수 있지만, 그 밖의 리전에 있는 엔드포인트에 대해서는 접속이 불량일 수 있습니다. 이와 동시에 미국 동부(오하이오)의 Route 53는 남아메리카(상파울루) 리전의 상태 확인 엔드포인트에 대해 접속이 불량하여 해당 레코드가 비정상이라는 결론을 내릴 수도 있습니다. 이와 같은 분할은 엔드포인트들의 국지적 가시성을 근거로 Route 53 위치가 엔드포인트들의 상태에 대해 서로 다른 결론을 내리는 상황을 야기할 수 있습니다. 이것이 바로 연결할 수 있는 상태 확인 프로그램 중 일부만이 엔드포인트를 정상이라고 여기면 각 Route 53 위치가 엔드포인트를 정상이라고 여기는 이유입니다. # 상태 확인에 대한 이름 및 태그 지정 Amazon Route 53 상태 확인에 태그를 추가할 수 있는데, 이를 통해 상태 확인 ID보다 더 이해하기 쉬운 이름을 상태 확인에 부여할 수 있습니다. 에서 AWS 청구서를 구성하기 위해 AWS 결제 및 비용 관리 제공하는 것과 동일한 태그입니다. 비용 할당 태그 사용에 대한 자세한 내용은 *AWS Billing 사용자 설명서*의 [사용자 정의 청구 보고서용 비용 할당 태그 사용](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/allocation.html)을 참조하세요. 각 태그는 사용자가 정의하는 키(태그의 이름)와 값으로 구성됩니다. 상태 확인에 태그를 추가할 때는 키와 값에 대해 다음 값을 가진 태그 하나를 추가하는 것이 좋습니다. + **키** - **이름** + **값** - 상태 확인에 지정하고자 하는 이름 **이름(Name)** 태그의 값은 Route 53 콘솔의 상태 확인 목록에 표시되어 상태 확인을 즉시 서로 구별할 수 있게 해줍니다. 상태 확인에 대한 다른 태그를 보려면 상태 확인을 선택한 다음 [**Tags**] 탭을 선택합니다. 태그에 대한 자세한 내용은 다음 주제들을 참조하십시오. + Route 53 콘솔에서 상태 확인을 추가하거나 편집할 때 **이름** 태그를 추가, 편집 또는 삭제하려면 [상태 확인의 생성 및 업데이트](health-checks-creating.md) 섹션을 참조하세요. + Route 53 리소스 태그 지정의 개요는 [Amazon Route 53 리소스 태그 지정](tagging-resources.md) 섹션을 참조하세요. ## 태그 제한 태그에 적용되는 기본 제한 사항은 다음과 같습니다. + 리소스당 최대 태그 수 - 새 콘솔의 경우 50개, 이전 콘솔의 경우 10개입니다. + 최대 **키** 길이 - 유니코드 128자 + 최대 **값** 길이 - 유니코드 256자 + **키** 및 **값**에 유효한 값 - UTF-8 문자 세트의 대문자 및 소문자, 숫자, 공백, 그리고 / = \$1 - 및 @ + 태그 키와 값은 대/소문자를 구분합니다 + 키 또는 값에 `aws:` 접두사를 사용하지 마세요. 전용입니다 AWS . ## 상태 확인에 대한 태그의 추가, 편집 및 삭제 다음 절차는 Route 53 콘솔에서 상태 확인에 대해 태그를 사용하는 방법을 보여줍니다. **참고** Route 53용 상태 확인 콘솔을 업데이트하고 있습니다. 전환 기간 동안에는 기존 콘솔을 계속 사용할 수 있습니다. 사용 중인 콘솔의 탭을 선택합니다. + [새로운 콘솔](#health-checks-tagging-new) + [이전 콘솔](#health-checks-tagging-old) ------ #### [ New console ] **상태 확인에 태그를 추가하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. 태그를 추가할 상태 확인의 연결된 ID를 선택합니다. 1. 하단 페이지에서 **태그** 탭을 선택하고 **관리**를 선택한 다음 **새 태그 추가**를 선택합니다. 1. **키** 필드에 태그 이름을 입력하고 **값** 필드에 값을 입력합니다. 1. **저장**을 선택합니다. **상태 확인에 대한 태그를 편집하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. 상태 확인의 연결된 ID를 선택합니다. 1. 하단 창에서 **태그** 탭을 선택한 다음 **관리**를 선택합니다. 1. 이제 태그를 편집하고 추가할 수 있습니다. 1. **저장**을 선택합니다. **상태 확인에 대한 태그를 삭제하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**을 선택합니다. 1. 상태 확인의 연결된 ID를 선택합니다. 1. 하단 창에서 **태그** 탭을 선택한 다음 **관리**를 선택합니다. 1. 삭제할 태그 옆에 있는 **제거**를 선택합니다. 1. **저장**을 선택합니다. ------ #### [ Old console ] **상태 확인에 태그를 추가하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 하나의 상태 확인을 선택하거나, 여러 개의 상태 확인을 선택해 같은 태그를 1개 이상의 상태 확인에 추가합니다. 1. 하단 창에서 [**Tags**] 탭을 선택한 다음, [**Add/Edit Tags**]를 선택합니다. 1. [**Add/Edit Tags**] 대화 상자에서, [**Key**] 필드에 태그 이름을 입력하고 [**Value**] 필드에 값을 입력합니다. 1. [**Apply changes**]를 선택합니다. **상태 확인에 대한 태그를 편집하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 상태 확인을 선택합니다. 같은 태그를 공유하는 여러 개의 상태 확인을 선택하는 경우에는 모든 태그를 동시에 편집할 수 없습니다. 그러나 태그가 있는 상태 확인과 태그가 없는 최소 1개의 상태 확인을 선택하면 여러 개의 상태 확인에 표시되는 태그의 값을 편집할 수 있다는 점에 유의하십시오. 예를 들어 **Cost Center** 태그가 있는 여러 개의 상태 확인과 그렇지 않은 것 한 개를 선택했다고 가정합시다. 태그를 추가하는 옵션을 선택하고 키에 **Cost Center**를, 값으로 **777**을 지정합니다. 이미 **Cost Center** 태그가 있는 상태 확인에 대해 Route53는 값을 **777**로 변경합니다. **Cost Center** 태그가 없는 상태 확인 1건에 대해 Route 53는 하나를 추가하고 값을 **777**로 변경합니다. 1. 하단 창에서 [**Tags**] 탭을 선택한 다음, [**Add/Edit Tags**]를 선택합니다. 1. [**Add/Edit Tags**] 대화 상자에서 값을 편집합니다. 1. **저장**을 선택합니다. **상태 확인에 대한 태그를 삭제하려면** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) Route 53 콘솔을 엽니다. 1. 탐색 창에서 **상태 확인**(Health Checks)을 선택합니다. 1. 하나의 상태 확인을 선택하거나, 여러 개의 상태 확인을 선택해 같은 태그를 1개 이상의 상태 확인으로부터 삭제합니다. 1. 하단 창에서 [**Tags**] 탭을 선택한 다음, [**Add/Edit Tags**]를 선택합니다. 1. [**Add/Edit Tags**] 대화 상자에서 삭제하고자 하는 태그 옆의 *X*를 선택합니다. 1. **저장**을 선택합니다. ------ # Amazon Route 53 API가 2012-12-12 이전 버전인 상태 확인 사용하기 상태 확인은 Amazon Route 53 API 2012-12-12 버전부터 지원됩니다. 호스팅 영역에 상태 확인이 구성된 레코드가 포함되어 있는 경우 2012-12-12 이후 버전의 API만 사용하는 것이 좋습니다. API가 이전 버전인 상태 확인을 사용할 경우에는 다음과 같은 제한이 있음을 유념하십시오. + `ChangeResourceRecordSets` 작업은 `EvaluateTargetHealth`, `Failover` 또는 `HealthCheckId` 요소를 포함하는 레코드를 생성 또는 삭제할 수 없습니다. + `ListResourceRecordSets` 작업은 이러한 요소를 포함하는 레코드를 나열할 수 있지만 요소는 출력에 포함되지 않습니다. 대신에 응답의 `Value` 요소는 레코드에 지원되지 않는 속성이 포함되어 있다는 메시지를 담고 있습니다.