기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Classic Load Balancer 구성
Classic Load Balancer를 생성한 후 구성을 변경할 수 있습니다. 예를 들어 로드 밸런서 속성, 서브넷 및 보안 그룹을 업데이트할 수 있습니다.로드 밸런서 속성
[연결 드레이닝](config-conn-drain.md)
활성화할 경우, 로드 밸런서가 등록 취소된 또는 비정상 백엔드 인스턴스에 대한 트래픽을 차단하기 전에 기존 요청을 완료할 수 있게 해줍니다.
[교차 영역 로드 밸런싱](enable-disable-crosszone-lb.md)
활성화할 경우, 로드 밸런서는 가용 영역과 상관없이 요청 트래픽을 모든 인스턴스에 균일하게 라우팅합니다.
[비동기화 완화 모드](config-desync-mitigation-mode.md)
애플리케이션에 보안 위험을 초래할 수 있는 요청을 로드 밸런서에서 처리하는 방법을 결정합니다. 가능한 값은 `monitor`, `defensive` 및 `strictest` 입니다. 기본값은 `defensive`입니다.
[유휴 제한 시간](config-idle-timeout.md)
활성화할 경우, 로드 밸런서에서 지정된 시간 동안 연결을 유휴 상태(연결을 통해 데이터를 전송하지 않는 상태)로 유지하도록 허용합니다. 기본값은 60초입니다.
[고정 세션](elb-sticky-sessions.md)
Classic Load Balancer는 기간 기반 세션과 애플리케이션 기반 세션의 고정성을 모두 지원합니다.로드 밸런서 세부 정보
[보안 그룹](elb-vpc-security-groups.md)
로드 밸런서의 보안 그룹은 리스너 및 상태 확인 포트에서 트래픽을 허용해야 합니다.
[서브넷](elb-manage-subnets.md)
로드 밸런서의 기능을 추가 서브넷까지 확장할 수 있습니다.
[프록시 프로토콜](enable-proxy-protocol.md)
활성화된 경우 인스턴스로 전송되는 연결 정보가 포함된 헤더를 추가합니다.
[Tags](add-remove-tags.md)
태그를 추가하여 로드 밸런서를 분류할 수 있습니다.
# Classic Load Balancer에 대한 유휴 연결 제한 시간 구성
클라이언트가 Classic Load Balancer를 통해 생성하는 각 요청에 대해 로드 밸런서는 두 가지 연결을 유지합니다. 프런트 엔드 연결은 클라이언트와 로드 밸런서 사이에 있습니다. 백엔드 연결은 로드 밸런서와 등록된 EC2 인스턴스 사이에 있습니다. 로드 밸런서에 해당 연결에 적용되는 유휴 제한 시간 기간이 구성되어 있습니다. 유휴 제한 시간이 경과할 때까지 데이터가 전송되거나 전송 또는 수신되지 않으면 로드 밸런서는 프런트 엔드 연결을 종료합니다. 파일 업로드 같이 시간이 오래 걸리는 작업이 완료될 수 있도록 시간 여유를 두려면 유휴 제한 시간이 지나기 전에 최소 1바이트의 데이터를 전송하고 필요에 따라 유휴 제한 시간의 길이를 늘립니다.
HTTP 및 HTTPS 리스너를 사용하는 경우에는 인스턴스에 대해 HTTP 연결 유지 옵션을 활성화하는 것이 좋습니다. 연결 유지는 인스턴스의 웹 서버 설정에서 활성화할 수 있습니다. 연결 유지를 활성화하면 연결 유지 제한 시간이 만료될 때까지 로드 밸런서가 백엔드 연결을 다시 사용할 수 있습니다. 로드 밸런서가 인스턴스에 대한 연결을 종료할 책임이 있는지 확인하고 싶다면 HTTP 연결 유지 시간 동안 설정된 값이 로드 밸런서에 구성된 유휴 제한 시간 설정보다 큰지 확인합니다.
TCP 연결 유지 프로브는 페이로드에 데이터를 전송하지 않기 때문에 로드 밸런서에서 연결이 종료되지 않도록 방지합니다.
**Topics**
+ [콘솔을 사용하여 유휴 제한 시간 구성](#config-idle-timeout-console)
+ [를 사용하여 유휴 제한 시간 구성 AWS CLI](#config-idle-timeout-awscli)
## 콘솔을 사용하여 유휴 제한 시간 구성
기본적으로 Elastic Load Balancing은 로드 밸런서의 유휴 시간 초과를 60초로 설정합니다. 다른 유휴 제한 시간 값을 설정하려면 다음 절차를 따르십시오.
**콘솔을 사용하여 로드 밸런서에서 유휴 제한 시간 설정을 구성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **트래픽 구성** 섹션에서 **유휴 제한 시간** 값을 입력합니다. 유휴 제한 시간의 범위는 1 \$1 4,000초입니다.
1. **변경 사항 저장**을 선택합니다.
## 를 사용하여 유휴 제한 시간 구성 AWS CLI
로드 밸런서에서 유휴 제한 시간을 설정하려면 아래 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":30}}"
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"ConnectionSettings": {
"IdleTimeout": 30
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Classic Load Balancer에서 교차 영역 로드 밸런성을 구성
*교차 영역 로드 밸런싱*을 사용하면 Classic Load Balancer에 대한 각각의 로드 밸런서 노드가 활성화된 모든 가용 영역에 있는 등록된 인스턴스 간에 요청을 균등하게 분산합니다. 교차 영역 로드 밸런싱이 비활성화된 경우에는 각각의 로드 밸런서 노드가 해당 가용 영역에만 있는 등록된 인스턴스 간에 요청을 균등하게 분산합니다. 자세한 내용은 *Elastic Load Balancing 사용 설명서*의 [교차 영역 로드 밸런싱](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)을 참조하세요.
교차 영역 로드 밸런싱을 사용하면 활성화된 각 가용 영역에 동일한 수의 인스턴스를 유지할 필요가 없으며, 애플리케이션이 보다 효과적으로 하나 이상의 인스턴스 손실을 처리할 수 있습니다. 하지만 내결함성을 높이기 위해서는 활성화된 각 가용 영역에서 인스턴스 수를 대략적으로 동일하게 유지하는 것이 좋습니다.
클라이언트가 DNS 조회를 캐싱하는 환경에서는 들어오는 요청이 가용 영역 중 하나를 선호할 수 있습니다. 교차 영역 로드 밸런싱을 사용하면 요청 로드의 이러한 불균형을 리전의 모든 가용 인스턴스로 분산시켜서 클라이언트 작동에 문제가 있을 때 그 영향을 줄일 수 있습니다.
Classic Load Balancer를 생성하면 교차 영역 로드 밸런싱에 대한 기본값은 로드 밸런서 생성 방법에 따라 달라집니다. API 또는 CLI에서는 교차 영역 로드 밸런싱이 기본적으로 비활성화되어 있습니다. AWS Management Console를 사용하면 교차 영역 로드 밸런싱을 활성화하는 옵션이 기본적으로 선택됩니다. Classic Load Balancer를 생성한 후 언제든지 교차 영역 로드 밸런싱을 활성화하거나 비활성화할 수 있습니다.
**Topics**
+ [교차 영역 로드 밸런싱 활성화](#enable-cross-zone)
+ [교차 영역 로드 밸런싱 비활성화](#disable-cross-zone)
## 교차 영역 로드 밸런싱 활성화
Classic Load Balancer에서 언제든지 교차 영역 로드 밸런싱을 활성화할 수 있습니다.
**콘솔을 사용하여 교차 영역 로드 밸런싱을 활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **가용 영역 라우팅 구성** 섹션에서 **교차 영역 로드 밸런싱**을 활성화합니다.
1. **변경 사항 저장**을 선택합니다.
**를 사용하여 교차 영역 로드 밸런싱을 활성화하려면 AWS CLI**
1. 다음 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하여 로드 밸런서의 `CrossZoneLoadBalancing` 속성을 `true`로 설정하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":true}}"
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": true
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (선택 사항) 로드 밸런서에서 교차 영역 로드 밸런싱이 활성화되었는지 확인하려면 아래 [describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": true
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
## 교차 영역 로드 밸런싱 비활성화
로드 밸런서에서의 언제든지 교차 영역 로드 밸런싱 옵션을 비활성화할 수 있습니다.
**콘솔을 사용하여 교차 영역 로드 밸런싱을 비활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **가용 영역 라우팅 구성** 섹션에서 **교차 영역 로드 밸런싱**을 비활성화합니다.
1. **변경 사항 저장**을 선택합니다.
교차 영역 로드 밸런싱을 비활성화하려면 로드 밸런서의 `CrossZoneLoadBalancing` 속성을 `false`로 설정합니다.
**를 사용하여 교차 영역 로드 밸런싱을 비활성화하려면 AWS CLI**
1. 아래 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":false}}"
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": false
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (선택 사항) 로드 밸런서에서 교차 영역 로드 밸런싱이 비활성화되었는지 확인하려면 아래[describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": false
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
# Classic Load Balancer에서 Connection Draining 구성
기존 연결이 열려 있는 상태에서 Classic Load Balancer가 등록 취소 중이거나 비정상 상태인 인스턴스로의 요청 전송을 중지하도록 하려면 *Connection Draining*을 사용하세요. 이렇게 하면 로드 밸런서가 등록 취소 중이거나 비정상 상태인 인스턴스로 진행 중인 요청을 완료합니다.
Connection Draining을 활성화하면 로드 밸런서가 인스턴스의 등록 취소를 보고하기 전에 연결을 유지할 수 있는 최대 시간을 지정할 수 있습니다. 최대 제한 시간 값의 범위는 1 \$1 3,600초입니다(기본은 300초). 최대 제한 시간에 도달하면 로드 밸런서는 등록 취소 중인 인스턴스로의 연결을 강제로 종료합니다.
등록을 취소하는 인스턴스에 진행 중인 요청이 없고 활성 연결이 없는 경우 Elastic Load Balancing은 등록 취소 프로세스를 즉시 완료합니다.
진행 중인 요청이 처리되는 동안 로드 밸런서는 등록 취소 중인 인스턴스의 상태를 `InService: Instance deregistration currently in progress`로 보고합니다. 등록 취소 중인 인스턴스가 진행 중인 모든 요청의 처리를 완료하거나 최대 제한 시간에 도달하면 로드 밸런서는 인스턴스 상태를 `OutOfService: Instance is not currently registered with the LoadBalancer`로 보고합니다.
인스턴스가 비정상 상태가 되면 로드 밸런서는 인스턴스 상태를 `OutOfService`로 보고합니다. 비정상 상태의 인스턴스로의 요청이 진행 중인 경우에는 해당 요청이 완료됩니다. 최대 제한 시간은 비정상 상태의 인스턴스에 대한 연결에는 적용되지 않습니다.
인스턴스가 Auto Scaling 그룹의 일부이고 로드 밸런서에 대해 Connection Draining이 활성화된 경우 Auto Scaling은 조정 이벤트 또는 상태 확인 교체로 인해 인스턴스를 종료하기 전에 진행 중인 요청이 완료되거나 최대 시간 초과가 만료될 때까지 기다립니다.
로드 밸런서가 등록 취소 중이거나 비정상 상태가 된 인스턴스에 대한 연결을 즉시 종료하도록 하고 싶은 경우에는 Connection Draining을 비활성화할 수 있습니다. Connection Draining이 비활성화되면 등록 취소 중이거나 비정상 상태인 인스턴스로 진행 중인 요청이 완료되지 않습니다.
**Topics**
+ [Connection Draining 활성화](#enable-conn-drain)
+ [Connection Draining 비활성화](#disable-conn-drain)
## Connection Draining 활성화
언제든지 로드 밸런서에 대한 Connection Draining을 활성화할 수 있습니다.
**콘솔을 사용하여 Connection Draining을 활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **트래픽 구성** 섹션에서 **Connection Draining 활성화**를 선택합니다.
1. (선택 사항) **제한 시간(드레이닝 간격)**에 1\$13,600초 범위 내에서 값을 입력합니다. 그러지 않으면 기본값인 300초가 사용됩니다.
1. **변경 사항 저장**을 선택합니다.
**를 사용하여 연결 드레이닝을 활성화하려면 AWS CLI**
아래 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":true,\"Timeout\":300}}"
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": true,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
## Connection Draining 비활성화
언제든지 로드 밸런서에 대한 Connection Draining을 비활성화할 수 있습니다.
**콘솔을 사용하여 Connection Draining을 비활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **트래픽 구성** 섹션에서 **Connection Draining 활성화**를 선택 취소합니다.
1. **변경 사항 저장**을 선택합니다.
**를 사용하여 연결 드레이닝을 비활성화하려면 AWS CLI**
아래 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":false}}"
```
다음은 응답의 예입니다.
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Classic Load Balancer를 위한 고정 세션 구성
기본적으로 Classic Load Balancer는 로드가 가장 적은 등록 인스턴스에 각 요청을 독립적으로 라우팅합니다. 한편, *고정 세션* 기능(*세션 어피니티*라고도 함)을 사용해 로드 밸런서가 사용자의 세션을 특정 인스턴스에 바인딩하도록 할 수 있습니다. 이렇게 하면 세션 중에 사용자로부터 들어오는 모든 요청이 동일한 인스턴스로 전송됩니다.
고정 세션 관리에서 핵심은 로드 밸런서가 얼마나 오랫동안 동일한 인스턴스로 사용자 요청을 일관되게 라우팅하도록 하느냐입니다. 애플리케이션이 자체 세션 쿠키를 가지고 있는 경우에는 세션 쿠키가 애플리케이션의 세션 쿠키에 지정된 기간을 따르도록 Elastic Load Balancing을 구성할 수 있습니다. 애플리케이션이 자체 세션 쿠키를 가지고 있지 않은 경우에는 자체 고정 기간을 지정하여 세션 쿠키를 생성하도록 Elastic Load Balancing을 구성할 수 있습니다.
Elastic Load Balancing은 인스턴스로 세션을 매핑하는 데 사용되는 AWSELB라는 쿠키를 생성합니다.
**요구 사항**
+ HTTP/HTTPS 로드 밸런서입니다.
+ 각 가용 영역에 있는 하나 이상의 정상 상태 인스턴스입니다.
**호환성**
+ 쿠키의 경로 속성에 대한 RFC는 밑줄을 허용합니다. 한편 Elastic Load Balancing URI는 밑줄 문자를 `%5F`로 인코딩합니다. Internet Explorer 7 같은 일부 브라우저들이 밑줄을 `%5F`로 인코딩된 URI로 예상하기 때문입니다. 현재 작동 중인 브라우저에 영향을 미칠 가능성이 있기 때문에 Elastic Load Balancing은 밑줄 문자를 계속 URI로 인코딩합니다. 예를 들어 쿠키가 `path=/my_path` 속성을 가지고 있으면 Elastic Load Balancing은 `path=/my%5Fpath`로 전송된 요청에서 이 속성을 변경합니다.
+ 기간 기반의 고정 쿠키에서는 `secure` 플래그나 `HttpOnly` 플래그를 설정할 수 없습니다. 그러나 이들 쿠키는 민감한 데이터를 포함하고 있지 않습니다. 애플리케이션이 제어하는 세션 고정 쿠키에서 `secure` 플래그나 `HttpOnly` 플래그를 설정하면 AWSELB 쿠키에서도 그렇게 설정이 됩니다.
+ 애플리케이션 쿠키의 `Set-Cookie` 필드에 후행 세미콜론이 있으면 로드 밸런서는 이 쿠키를 무시합니다.
**Topics**
+ [기간 기반 세션 고정](#enable-sticky-sessions-duration)
+ [애플리케이션 제어 세션 고정](#enable-sticky-sessions-application)
## 기간 기반 세션 고정
로드 밸런서는 각 리스너에 대한 요청에서 인스턴스를 추적하기 위해 특별한 쿠키인 AWSELB를 사용합니다. 로드 밸런서는 요청을 받으면 가장 먼저요청에 쿠키가 있는지 여부를 확인합니다. 쿠키가 있으면 해당 요청이 쿠키에 지정된 인스턴스에 전송됩니다. 쿠키가 없는 경우에는 로드 밸런서가 기존 로드 밸런싱 알고리즘을 기반으로 인스턴스를 선정합니다. 동일한 사용자의 후속 요청이 계속 해당 인스턴스에 바인딩되도록 쿠키가 응답에 삽입됩니다. 고정 정책 구성에서 각 쿠키의 유효 기간을 설정하는 쿠키 만료 시한을 정의합니다. 로드 밸런서는 쿠키 만료 시간을 새로 고침하지 않으며 쿠키가 사용 전에 만료되었는지 여부를 확인하지 않습니다. 쿠키가 만료된 후에는 세션이 더 이상 고정 상태가 아닙니다. 클라이언트는 쿠키가 만료되면 쿠키 저장소에서 쿠키를 제거해야 합니다.
CORS(Cross-Origin Resource Sharing) 요청의 경우 고정을 활성화하려면 `SameSite=None; Secure`가 필요합니다. 이 경우 Elastic Load Balancing은 두 번째 고정 쿠키인 AWSELBCORS를 생성합니다. 이 쿠키에는 원래 고정 쿠키와 동일한 정보와 `SameSite` 속성이 포함되어 있습니다. 클라이언트는 두 쿠키를 모두 수신합니다.
인스턴스가 실패하거나 비정상 상태가 되면 로드 밸런서는 해당 인스턴스로의 요청 라우팅을 중지하고 기존 로드 밸런싱 알고리즘을 기반으로 정상 상태의 인스턴스를 새로 선정합니다. 마치 쿠키가 없고 세션이 더 이상 고정 상태가 아닌 것처럼 새 인스턴스로 요청이 라우팅됩니다.
클라이언트가 다른 백엔드 포트를 가진 리스너로 전환되면 고정성이 손실됩니다.
**콘솔을 사용하여 로드 밸런서에 대한 기간 기반 고정 세션을 활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **리스너** 탭에서 **리스너 관리**를 선택합니다.
1. **리스너 관리** 페이지에서 업데이트할 리스너를 찾고 **쿠키 고정**에서 **편집**을 선택합니다.
1. **쿠키 고정 설정 편집** 팝업에서 **로드 밸런서에서 생성됨**을 선택합니다.
1. (선택 사항) **만료 기간**에 쿠키 만료 기간(초)을 입력합니다. 만료 기간을 지정하지 않은 경우에는 브라우저 세션 기간 동안 고정 세션이 지속됩니다.
1. **변경 사항 저장**을 선택하여 팝업 창을 닫습니다.
1. **변경 사항 저장**을 선택하여 로드 밸런서 세부 정보 페이지로 돌아갑니다.
**를 사용하여 로드 밸런서에 대한 기간 기반 고정 세션을 활성화하려면 AWS CLI**
1. 쿠키 만료 기간을 60초로 설정해서 로드 밸런서가 쿠키 고정 정책을 생성하도록 하려면 아래 [create-lb-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-lb-cookie-stickiness-policy.html) 명령을 사용하세요.
```
aws elb create-lb-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-duration-cookie-policy --cookie-expiration-period 60
```
1. 지정된 로드 밸런서에서 세션 고정을 활성화하려면 아래 [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) 명령을 사용하세요.
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-duration-cookie-policy
```
**참고**
`set-load-balancer-policies-of-listener` 명령은 지정된 로드 밸런서 포트에 연결된 현재의 정책 세트를 대체합니다. 이 명령을 사용할 때마다 활성화할 모든 정책의 목록을 표시하도록 `--policy-names` 옵션을 지정합니다.
1. (선택 사항) 정책이 활성화되었는지 확인하려면 아래 [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) 명령을 사용하세요.
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
응답에는 다음과 같이 지정된 포트의 리스너에 대해 정책이 활성화되었음을 보여주는 정보가 포함되어 있습니다.
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-duration-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
],
...
"Policies": {
"LBCookieStickinessPolicies": [
{
"PolicyName": "my-duration-cookie-policy",
"CookieExpirationPeriod": 60
}
],
"AppCookieStickinessPolicies": [],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
## 애플리케이션 제어 세션 고정
로드 밸런서는 특별한 쿠키를 이용하여 최초 요청을 처리한 인스턴스에 세션을 연결하지만, 정책 구성에 지정된 애플리케이션 쿠키의 사용 기간이 적용됩니다. 로드 밸런서는 애플리케이션 응답에 새 애플리케이션 쿠키가 포함되어 있는 경우에만 새 고정 쿠키를 삽입합니다. 로드 밸런서 고정 쿠키는 요청이 있을 때마다 업데이트되지 않습니다. 애플리케이션 쿠키가 명백하게 제거되거나 만료되면 새 애플리케이션 쿠키가 발급될 때까지 세션에서 고정 상태가 중지됩니다.
백엔드 인스턴스에서 설정한 속성(`path`, `port`, `domain`, `secure`, `httponly`, `discard`, `max-age`, `expires`, `version`, `comment`, `commenturl` 및 `samesite`)이 쿠키의 클라이언트로 전송됩니다.
인스턴스가 실패하거나 비정상 상태가 되면 로드 밸런서는 해당 인스턴스로의 요청 라우팅을 중지하고 기존 로드 밸런싱 알고리즘을 기반으로 정상 상태의 인스턴스를 새로 선정합니다. 로드 밸런서는 새로운 정상 상태 인스턴스에 "고정"된 것으로 세션을 처리하고 실패한 인스턴스가 작동을 재개한 경우라도 해당 인스턴스로 계속해서 요청을 라우팅합니다.
**콘솔을 사용하여 애플리케이션 제어 세션 고정을 활성화하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **리스너** 탭에서 **리스너 관리**를 선택합니다.
1. **리스너 관리** 페이지에서 업데이트할 리스너를 찾고 **쿠키 고정**에서 **편집**을 선택합니다.
1. **애플리케이션에서 생성**을 선택합니다.
1. [**Cookie Name**]에 애플리케이션 쿠키의 이름을 입력합니다.
1. **변경 사항 저장**을 선택합니다.
**를 사용하여 애플리케이션 제어 세션 고정을 활성화하려면 AWS CLI**
1. 로드 밸런서가 쿠키 고정 정책을 생성하도록 하려면 아래 [create-app-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-app-cookie-stickiness-policy.html) 명령을 사용하세요.
```
aws elb create-app-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-app-cookie-policy --cookie-name my-app-cookie
```
1. 로드 밸런서에서 세션 고정을 활성화하려면 아래 [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) 명령을 사용하세요.
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-app-cookie-policy
```
**참고**
`set-load-balancer-policies-of-listener` 명령은 지정된 로드 밸런서 포트에 연결된 현재의 정책 세트를 대체합니다. 이 명령을 사용할 때마다 활성화할 모든 정책의 목록을 표시하도록 `--policy-names` 옵션을 지정합니다.
1. (선택 사항) 고정 정책이 활성화되었는지 확인하려면 아래 [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) 명령을 사용하세요.
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
1. 응답에는 다음과 같이 지정된 포트의 리스너에 대해 정책이 활성화되었음을 보여주는 정보가 포함되어 있습니다.
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-app-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
{
"Listener": {
"InstancePort": 80,
"LoadBalancerPort": 80,
"Protocol": "TCP",
"InstanceProtocol": "TCP"
},
"PolicyNames": []
}
],
...
"Policies": {
"LBCookieStickinessPolicies": [],
"AppCookieStickinessPolicies": [
{
"PolicyName": "my-app-cookie-policy",
"CookieName": "my-app-cookie"
}
],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
# Classic Load Balancer에 대한 동기화 해제 완화 모드 구성
Desync Mitigation Mode는 HTTP Desync로 인한 문제로부터 애플리케이션을 보호합니다. 로드 밸런서는 위협 수준에 따라 각 요청을 분류하고 안전한 요청을 허용한 다음 지정한 완화 모드에서 지정한 대로 위험을 완화합니다. Desync Mitigation Mode는 Monitor, Defensive 또는 Strictest 모드입니다. 기본값은 Defensive 모드입니다. 이 모드는 애플리케이션의 가용성을 유지하면서 HTTP Desync에 대한 지속적인 완화를 제공합니다. 애플리케이션에서 RFC 7230을 준수하는 요청만 수신하도록 Strictest 모드로 전환할 수 있습니다.
http\$1desync\$1guardian 라이브러리는 HTTP Desync 공격을 방지하기 위해 HTTP 요청을 분석합니다. 자세한 내용은 github의 [HTTP Desync Guardian](https://github.com/aws/http-desync-guardian)을 참조하십시오.
**Topics**
+ [분류](#desync-mitigation-classification)
+ [Modes](#desync-mitigation-modes)
+ [Desync Mitigation Mode 수정](#update-desync-mitigation-mode)
**작은 정보**
이 구성은 Classic Load Balancer에만 적용됩니다. Application Load Balancer에 적용되는 자세한 내용은 [Application Load Balancers에 대한 동기화 해제 완화 모드](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#desync-mitigation-mode)를 참조하세요.
## 분류
분류는 다음과 같습니다.
+ 규정 준수 - 요청이 RFC 7230을 준수하며 알려진 보안 위협이 없습니다.
+ 허용 가능 - 요청이 RFC 7230을 준수하지 않지만 알려진 보안 위협이 없습니다.
+ 모호 - 요청이 RFC 7230을 준수하지 않지만 다양한 웹 서버와 프록시가 다르게 처리할 수 있으므로 위험을 초래합니다.
+ 심각 - 요청이 높은 보안 위험을 초래합니다. 로드 밸런서는 요청을 차단하고 클라이언트에 대해 400 응답을 제공하고 클라이언트 연결을 종료합니다.
다음 목록에서는 각 분류에 대한 문제를 설명합니다.
**허용 가능**
+ 헤더에 비 ASCII 또는 제어 문자가 포함되어 있습니다.
+ 요청 버전에 잘못된 값이 포함되어 있습니다.
+ GET 또는 HEAD 요청에 대한 값이 0인 Content-Length 헤더가 있습니다.
+ 요청 URI에 URL이 인코딩되지 않은 공백이 포함되어 있습니다.
**모호**
+ 요청 URI에 제어 문자가 포함되어 있습니다.
+ 요청에 Transfer-Encoding 헤더와 Content-Length 헤더가 모두 포함되어 있습니다.
+ 값이 동일한 Content-Length 헤더가 여러 개 있습니다.
+ 헤더가 비어 있거나 공백만 있는 줄이 있습니다.
+ 일반적인 텍스트 정규화 기술을 사용하여 Transfer-Encoding 또는 Content-Length로 정규화할 수 있는 헤더가 있습니다.
+ GET 또는 HEAD 요청에 대한 Content-Length 헤더가 있습니다.
+ GET 또는 HEAD 요청에 대한 Transfer-Encoding 헤더가 있습니다.
**심각**
+ 요청 URI에 null 문자 또는 캐리지 리턴이 포함되어 있습니다.
+ Content-Length 헤더에 구문 분석할 수 없거나 유효한 숫자가 아닌 값이 포함되어 있습니다.
+ 헤더에 null 문자 또는 캐리지 리턴이 포함되어 있습니다.
+ Transfer-Encoding 헤더에 잘못된 값이 포함되어 있습니다.
+ 요청 메서드의 형식이 잘못되었습니다.
+ 요청 버전의 형식이 잘못되었습니다.
+ 값이 서로 다른 Content-Length 헤더가 여러 개 있습니다.
+ 여러 Transfer-Encoding이 있습니다: chunked 헤더.
요청이 RFC 7230을 준수하지 않는 경우 로드 밸런서는 `DesyncMitigationMode_NonCompliant_Request_Count` 지표를 증가시킵니다. 자세한 내용은 [Classic Load Balancer 지표](elb-cloudwatch-metrics.md#loadbalancing-metrics-clb) 단원을 참조하십시오.
## Modes
다음 표에서는 Classic Load Balancer가 모드 및 분류를 기준으로 요청을 처리하는 방법에 대해 설명합니다.
| Classification | Monitor 모드 | Defensive 모드 | Strictest 모드 |
| --- | --- | --- | --- |
| 규정 준수 | Allowed | 허용됨 | Allowed |
| 허용 가능 | Allowed | Allowed | 차단됨 |
| 모호 | Allowed | 허용¹ | 차단됨 |
| 심각 | Allowed | 차단됨 | 차단됨 |
¹ 요청을 라우팅하지만 클라이언트 연결과 대상 연결을 종료합니다.
## Desync Mitigation Mode 수정
**콘솔을 사용하여 Desync Mitigation Mode를 업데이트하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **속성** 탭에서 **편집**을 선택합니다.
1. **로드 밸런서 속성 편집** 페이지의 **트래픽 구성**에서 **방어적 - 권장**,**가장 엄격함** 또는 **모니터링**을 선택합니다.
1. **변경 사항 저장**을 선택합니다.
**를 사용하여 비동기화 완화 모드를 업데이트하려면 AWS CLI**
`elb.http.desyncmitigationmode` 속성을 `monitor`, `defensive` 또는 `strictest`로 설정하여 [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) 명령을 사용하세요.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-load-balancer --load-balancer-attributes file://attribute.json
```
다음은 `attribute.json`의 내용입니다.
```
{
"AdditionalAttributes": [
{
"Key": "elb.http.desyncmitigationmode",
"Value": "strictest"
}
]
}
```
# Classic Load Balancer에 프록시 프로토콜 구성
프록시 프로토콜은 연결을 요청하는 소스에서 연결이 요청된 대상으로 연결 정보를 전달하는 데 사용되는 인터넷 프로토콜입니다. Elastic Load Balancing은 사람이 읽을 수 있는 형식의 헤더를 가진 프록시 프로토콜 버전 1을 사용합니다.
기본적으로 프런트 엔드 및 백 엔드 연결 모두에서 TCP(Transmission Control Protocol)를 사용하면 Classic Load Balancer는 요청 헤더를 변경하지 않고 인스턴스로 요청을 전달합니다. 프록시 프로토콜을 활성화하면 사람이 읽을 수 있는 형식의 헤더가 소스 IP 주소, 대상 IP 주소, 포트 번호와 같은 연결 정보를 포함하는 요청 헤더에 추가됩니다. 이렇게 하면 헤더가 요청의 일부로 인스턴스에 전송됩니다.
**참고**
AWS Management Console 는 프록시 프로토콜 활성화를 지원하지 않습니다.
**Topics**
+ [프록시 프로토콜 헤더](#proxy-protocol)
+ [프록시 프로토콜을 활성화하기 위한 사전 조건](#proxy-protocol-prerequisites)
+ [를 사용하여 프록시 프로토콜 활성화 AWS CLI](#enable-proxy-protocol-cli)
+ [를 사용하여 프록시 프로토콜 비활성화 AWS CLI](#proxy-protocol-disable-policy-cli)
## 프록시 프로토콜 헤더
프록시 프로토콜 헤더는 백엔드 연결에 TCP를 사용하는 로드 밸런서를 가지고 있을 때 클라이언트의 IP 주소를 식별하는 데 도움을 줍니다. 로드 밸런서가 클라이언트와 인스턴스 간의 트래픽을 가로채기 때문에 인스턴스의 액세스 로그에 발원 클라이언트가 아닌 로드 밸런서의 IP 주소가 포함됩니다. 요청의 첫 번째 줄을 분석해서 클라이언트의 IP 주소와 포트 번호를 알아낼 수 있습니다.
IPv6를 위한 헤더의 프록시 주소가 로드 밸런서의 퍼블릭 IPv6 주소가 됩니다. 이 IPv6 주소는 로드 밸런서의 DNS 이름에서 확인할 수 있는 IP 주소와 일치하며 `ipv6` 또는 `dualstack`으로 시작됩니다. 클라이언트가 IPv4에 연결되면 헤더의 프록시 주소는 로드 밸런서의 프라이빗 IPv4 주소가 되고, DNS 조회를 통해 확인할 수 없습니다.
프록시 프로토콜 줄은 캐리지 리턴과 라인 피드(`"\r\n"`)로 끝나는 단일 줄이며 다음의 형식을 가지고 있습니다.
```
PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"
```
**예제: IPv4**
다음은 IPv4를 위한 프록시 프로토콜 줄의 예제입니다.
```
PROXY TCP4 198.51.100.22 203.0.113.7 35646 80\r\n
```
## 프록시 프로토콜을 활성화하기 위한 사전 조건
시작하기 전에 다음을 수행하십시오.
+ 로드 밸런서가 프록시 프로토콜이 활성화된 프록시 서버를 지원하지 않는지 확인합니다. 프록시 서버와 로드 밸런서 모두에서 프록시 프로토콜이 활성화된 경우에는 로드 밸런서가 프록시 서버에서 이미 헤더를 가지고 있는 요청에 또 다른 헤더를 추가합니다. 인스턴스의 구성 방법에 따라 이러한 중복이 오류를 일으킬 수 있습니다.
+ 인스턴스가 프록시 프로토콜 정보를 처리할 수 있는지 확인합니다.
+ 리스너 설정이 프록시 프로토콜을 지원하는지 확인합니다. 자세한 내용은 [Classic Load Balancer의 리스너 구성](using-elb-listenerconfig-quickref.md) 단원을 참조하십시오.
## 를 사용하여 프록시 프로토콜 활성화 AWS CLI
프록시 프로토콜을 활성화하려면 `ProxyProtocolPolicyType` 유형의 정책을 생성한 다음 인스턴스 포트에서 정책을 활성화해야 합니다.
다음 단계를 통해 `ProxyProtocolPolicyType` 유형의 로드 밸런서를 위한 새 정책을 생성하고 새롭게 생성된 정책을 포트 `80`의 인스턴스로 설정한 다음, 정책이 활성화되었는지 확인합니다.
**로드 밸런서에 대한 프록시 프로토콜을 활성화하려면**
1. (선택 사항) Elastic Load Balancing이 지원하는 정책의 목록을 확인하려면 아래 [describe-load-balancer-policy-types](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-policy-types.html) 명령을 사용하세요.
```
aws elb describe-load-balancer-policy-types
```
응답에는 지원되는 정책 유형의 이름과 이에 대한 설명이 포함되어 있습니다. 다음은 `ProxyProtocolPolicyType` 유형에 대한 출력을 보여줍니다.
```
{
"PolicyTypeDescriptions": [
...
{
"PolicyAttributeTypeDescriptions": [
{
"Cardinality": "ONE",
"AttributeName": "ProxyProtocol",
"AttributeType": "Boolean"
}
],
"PolicyTypeName": "ProxyProtocolPolicyType",
"Description": "Policy that controls whether to include the IP address and port of the originating
request for TCP messages. This policy operates on TCP/SSL listeners only"
},
...
]
}
```
1. 프록시 프로토콜을 활성화하는 정책을 생성하려면 아래 [create-load-balancer-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-policy.html) 명령을 사용하세요.
```
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer --policy-name my-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
```
1. 새로 생성된 정책을 지정된 포트에서 활성화하려면 아래 [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) 명령을 사용하세요. 이 명령이 현재 활성화된 정책 세트를 대체합니다. 따라서 `--policy-names` 옵션을 통해 목록에 추가 중인 정책(예: `my-ProxyProtocol-policy`)과 현재 활성화된 정책(예: `my-existing-policy`) 모두를 지정해야 합니다.
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-ProxyProtocol-policy my-existing-policy
```
1. (선택 사항) 프록시 프로토콜이 활성화되어 있는지 확인하려면 아래 [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) 명령을 사용하세요.
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
응답에는 다음과 같이 `my-ProxyProtocol-policy` 정책이 포트 `80`에 연결되었음을 보여주는 정보가 포함되어 있습니다.
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [
{
"InstancePort": 80,
"PolicyNames": [
"my-ProxyProtocol-policy"
]
}
],
...
}
]
}
```
## 를 사용하여 프록시 프로토콜 비활성화 AWS CLI
인스턴스에 연결된 정책을 비활성화한 다음, 나중에 활성화를 할 수 있습니다.
**프록시 프로토콜 정책을 비활성화하려면**
1. `--policy-names` 옵션에서 이를 생략하고 활성화된 상태를 유지하는 다른 정책(예: `my-existing-policy`)을 포함시켜 프록시 프로토콜 정책을 비활성화하려면 아래 [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) 명령을 사용하세요.
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-existing-policy
```
활성화할 다른 정책이 없는 경우에는 다음과 같이 `--policy-names` 옵션을 통해 빈 문자열을 지정합니다.
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names "[]"
```
1. (선택 사항) 정책이 비활성화되었는지 확인하려면 아래 [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) 명령을 사용하세요.
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
응답에는 다음과 같이 정책에 연결된 포트가 없음을 보여주는 정보가 포함되어 있습니다.
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [],
...
}
]
}
```
# Classic Load Balancer에 대한 태그 지정
태그는 용도, 소유자, 환경 등 다양한 방식으로 로드 밸런서를 분류할 수 있도록 해줍니다.
각 Classic Load Balancer에 여러 태그를 추가할 수 있습니다. 태그 키는 각 로드 밸런서에 대해 고유해야 합니다. 로드 밸런서에 이미 연결된 키를 통해 태그를 추가하면 해당 태그의 값이 업데이트됩니다.
태그 사용을 마치면 로드 밸런서에서 이를 제거할 수 있습니다.
**Topics**
+ [태그 제한](#tag-restrictions)
+ [태그 추가](#add-tags)
+ [태그 제거](#remove-tags)
## 태그 제한
태그에 적용되는 기본 제한은 다음과 같습니다.
+ 리소스당 최대 태그 수 - 50개
+ 최대 키 길이 - 유니코드 문자 127자
+ 최대 값 길이 - 유니코드 문자 255자
+ 태그 키와 값은 대소문자를 구분합니다. 허용되는 문자는 UTF-8로 표현할 수 있는 문자, 공백 및 숫자와 특수 문자 \$1 - = . \$1 : / @입니다. 선행 또는 후행 공백을 사용하면 안 됩니다.
+ 태그 이름 또는 값에 `aws:` 접두사는 AWS 사용하도록 예약되어 있으므로 사용하지 마십시오. 이 접두사가 지정된 태그 이름이나 값은 편집하거나 삭제할 수 없습니다. 이 접두사가 지정된 태그는 리소스당 태그 수 제한에 포함되지 않습니다.
## 태그 추가
언제라도 로드 밸런서에 태그를 추가할 수 있습니다.
**콘솔을 사용하여 태그를 추가하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **태그** 탭에서 **태그 관리**를 선택합니다.
1. **태그 관리** 페이지에서 각 태그에 대해 **새 태그 생성**을 선택한 다음 키와 값을 지정합니다.
1. 태그 추가를 완료하면 **변경 사항 저장**을 선택합니다.
**를 사용하여 태그를 추가하려면 AWS CLI**
지정된 태그를 추가하려면 아래 [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/add-tags.html) 명령을 사용하세요.
```
aws elb add-tags --load-balancer-name my-loadbalancer --tag "Key=project,Value=lima"
```
## 태그 제거
태그 사용을 마칠 때마다 로드 밸런서에서 태그를 제거할 수 있습니다.
**콘솔을 사용하여 태그를 제거하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **태그** 탭에서 **태그 관리**를 선택합니다.
1. **태그 관리** 페이지에서 제거할 각 태그 옆의 **제거**를 선택합니다.
1. 태그 제거를 완료하면 **변경 사항 저장**을 선택합니다.
**를 사용하여 태그를 제거하려면 AWS CLI**
지정된 키를 통해 태그를 제거하려면 아래 [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/remove-tags.html) 명령을 사용하세요.
```
aws elb remove-tags --load-balancer-name my-loadbalancer --tag project
```
# Classic Load Balancer에서 서브넷 구성
로드 밸런서에 서브넷을 추가하면 Elastic Load Balancing이 해당 가용 영역에서 로드 밸런서 노드를 생성합니다. 로드 밸런서 노드는 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 정상 상태의 등록 인스턴스로 요청을 전달합니다. 최소 두 개의 가용 영역에 대해 가용 영역당 하나의 서브넷을 추가하는 것이 좋습니다. 이렇게 하면 로드 밸런서의 가용성이 향상됩니다. 로드 밸런서에 대한 서브넷을 언제든지 수정할 수 있습니다.
인스턴스와 동일한 가용 영역에서 서브넷을 선택합니다. 로드 밸런서가 인터넷 경계 로드 밸런서인 경우에는 퍼블릭 서브넷을 선택해야만 백엔드 인스턴스가 로드 밸런서에서 오는 트래픽을 수신할 수 있습니다(백엔드 인스턴스가 프라이빗 서브넷에 있다 하더라도). 로드 밸런서가 내부 로드 밸런서인 경우에는 프라이빗 서브넷을 선택하는 것이 좋습니다. 로드 밸런서용 서브넷에 대한 자세한 내용은 [VPC 관련 권장 사항](elb-backend-instances.md#set-up-ec2)를 참조하십시오.
서브넷을 추가하려면 가용 영역의 인스턴스를 로드 밸런서에 등록한 다음, 해당 가용 영역의 서브넷을 로드 밸런서에 연결합니다. 자세한 내용은 [Classic Load Balancer에 인스턴스 등록](elb-deregister-register-instances.md) 단원을 참조하십시오.
서브넷을 추가하고 나면 로드 밸런서가 해당 가용 영역의 등록 인스턴스로 요청을 라우팅하기 시작합니다. 기본적으로 로드 밸런서는 서브넷에서 가용 영역 전반에 균등하게 요청을 라우팅합니다. 서브넷에서 가용 영역의 등록 인스턴스에 균등하게 요청을 라우팅할 수 있도록 교차 영역 로드 밸런싱을 활성화합니다. 자세한 내용은 [Classic Load Balancer에서 교차 영역 로드 밸런성을 구성](enable-disable-crosszone-lb.md) 단원을 참조하십시오.
정상 상태의 등록 인스턴스가 없거나 등록 인스턴스에서 문제 해결 또는 업데이트를 원할 경우에 일시적으로 로드 밸런서에서 서브넷을 제거하고 싶을 수 있습니다. 서브넷을 제거하고 나면 로드 밸런서는 이 가용 영역의 등록 인스턴스로의 요청 라우팅은 중지하되, 나머지 서브넷에서 가용 영역의 등록 인스턴스로 계속해서 요청을 라우팅합니다. 서브넷을 제거해도 해당 서브넷의 인스턴스들은 로드 밸런서에 등록된 상태로 남아 있다는 점에 유의하세요. 원할 경우 인스턴스의 등록을 취소할 수 있습니다. 자세한 내용은 [Classic Load Balancer에 인스턴스 등록](elb-deregister-register-instances.md) 단원을 참조하십시오.
**Topics**
+ [요구 사항](#elb-subnet-requirements)
+ [콘솔을 사용하여 서브넷 구성](#add-remove-subnets-console)
+ [CLI를 사용하여 서브넷 구성](#add-remove-subnets-cli)
## 요구 사항
로드 밸런서에 대한 서브넷을 업데이트할 때는 다음 요구 사항을 반드시 충족해야 합니다.
+ 로드 밸런서가 언제나 서브넷을 하나 이상 가지고 있어야 합니다.
+ 가용 영역당 서브넷을 한 개 이상 추가할 수 있습니다.
+ 로컬 영역 서브넷은 추가할 수 없습니다.
로드 밸런서에서 서브넷을 추가 및 제거하기 위한 별도의 API가 있기 때문에 이러한 요구 사항을 충족하기 위해 현재 서브넷을 새로운 서브넷으로 바꿀 때는 작업 순서를 세심하게 고려해야 합니다. 또한 로드 밸런서에 대한 모든 서브넷을 바꿔야 하는 경우에는 또 다른 가용 영역에서 나온 서브넷을 일시적으로 추가해야 합니다. 예를 들어 로드 밸런서가 단일 가용 영역을 가지고 있고 현재 서브넷을 또 다른 서브넷으로 바꿔야 하는 경우에는 두 번째 가용 영역에서 나온 서브넷을 먼저 추가해야 합니다. 그런 다음 원래 가용 영역에서 서브넷을 제거하고(서브넷을 한 개 이하로 변경하지 않음), 원래 가용 영역에서 새로운 서브넷을 추가한 다음(가용 영역당 하나 이상으로 서브넷 수를 초과하지 않음), 두 번째 가용 영역에서 서브넷을 제거할 수 있습니다(오직 교체가 필요한 경우).
## 콘솔을 사용하여 서브넷 구성
다음 절차에 따라 콘솔을 사용하여 서브넷을 추가하거나 제거합니다.
**콘솔을 사용하여 서브넷을 구성하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **네트워크 매핑** 탭에서 **서브넷 편집**을 선택합니다.
1. **서브넷 편집** 페이지의 **네트워크 매핑** 섹션에서 필요에 따라 서브넷을 추가하거나 제거합니다.
1. 작업을 마쳤으면 **변경 사항 저장**을 선택합니다.
## CLI를 사용하여 서브넷 구성
다음 예제를 따라 AWS CLI를 사용하여 서브넷을 추가하거나 제거합니다.
**CLI를 사용하여 로드 밸런서에 서브넷을 추가하려면**
로드 밸런서에 두 개의 서브넷을 추가하려면 아래 [attach-load-balancer-to-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/attach-load-balancer-to-subnets.html) 명령을 사용하세요.
```
aws elb attach-load-balancer-to-subnets --load-balancer-name my-load-balancer --subnets subnet-dea770a9 subnet-fb14f6a2
```
응답에는 해당 로드 밸런서에 대한 모든 서브넷이 나열됩니다. 예제:
```
{
"Subnets": [
"subnet-5c11033e",
"subnet-dea770a9",
"subnet-fb14f6a2"
]
}
```
**를 사용하여 서브넷을 제거하려면 AWS CLI**
지정된 로드 밸런서에서 지정된 서브넷을 제거하려면 아래 [detach-load-balancer-from-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/detach-load-balancer-from-subnets.html) 명령을 사용하세요.
```
aws elb detach-load-balancer-from-subnets --load-balancer-name my-loadbalancer --subnets subnet-450f5127
```
응답에는 해당 로드 밸런서에 대한 나머지 서브넷들이 나열됩니다. 예제:
```
{
"Subnets": [
"subnet-15aaab61"
]
}
```
# Classic Load Balancer 보안 그룹 구성
AWS Management Console 를 사용하여 로드 밸런서를 생성할 때 기존 보안 그룹을 선택하거나 새 보안 그룹을 생성할 수 있습니다. 기존 보안 그룹을 선택하는 경우에는 반드시 로드 밸런서를 위한 리스너 포트 및 상태 확인 포트로의 양방향 트래픽을 허용해야 합니다. 보안 그룹을 생성하기로 한 경우에는 콘솔이 이들 포트에서 모든 트래픽을 허용하는 규칙을 자동으로 추가합니다.
[기본이 아닌 VPC] AWS CLI 또는 API를 사용하여 기본이 아닌 VPC에서 로드 밸런서를 생성하지만 보안 그룹을 지정하지 않으면 로드 밸런서가 VPC의 기본 보안 그룹과 자동으로 연결됩니다.
[기본 VPC] AWS CLI 또는 API를 사용하여 기본 VPC에서 로드 밸런서를 생성하는 경우 로드 밸런서에 대한 기존 보안 그룹을 선택할 수 없습니다. 대신에 Elastic Load Balancing이 로드 밸런서를 위해 지정된 포트에서 모든 트래픽을 허용하는 규칙을 보안 그룹에 제공합니다. Elastic Load Balancing은 default\$1elb\$1*id* 형식의 이름으로 AWS 계정당 이러한 보안 그룹을 하나만 생성합니다(예: `default_elb_fc5fbed3-0405-3b7d-a328-ea290EXAMPLE`). 이후에 기본 VPC에서 생성되는 로드 밸런서는 이 보안 그룹도 사용합니다. 새로운 로드 밸런서의 리스너 포트와 상태 확인 포트에서 트래픽을 허용하는지 보안 그룹 규칙을 확인해야 합니다. 로드 밸런서를 삭제해도 이 보안 그룹은 자동 삭제되지 않습니다.
기존 로드 밸런서에 리스너를 추가하는 경우에는 보안 그룹이 새로운 리스너 포트에서 양방향 트래픽을 허용하는지 확인해야 합니다.
**Topics**
+ [로드 밸런서 보안 그룹을 위한 권장 규칙](#recommended-sg-rules)
+ [콘솔을 사용하여 보안 그룹 할당](#assign-sg-console)
+ [를 사용하여 보안 그룹 할당 AWS CLI](#assign-sg-cli)
## 로드 밸런서 보안 그룹을 위한 권장 규칙
로드 밸런서를 위한 보안 그룹은 인스턴스와의 통신을 허용해야 합니다. 권장 규칙은 로드 밸런서의 유형(인터넷 경계 또는 내부)에 따라 다릅니다.
**인터넷 경계 로드 밸런서**
다음 표에는 인터넷 경계 로드 밸런서를 위한 권장 인바운드 규칙이 나와 있습니다.
| 소스 | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *리스너* | 로드 밸런서 리스너 포트에서 모든 인바운드 트래픽을 허용 |
다음 표에는 인터넷 경계 로드 밸런서를 위한 권장 아웃바운드 규칙이 나와 있습니다.
| Destination | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *인스턴스 보안 그룹* | TCP | *인스턴스 리스너* | 인스턴스 리스너 포트의 인스턴스로 아웃바운드 트래픽을 허용합니다 |
| *인스턴스 보안 그룹* | TCP | *상태 확인* | 상태 확인 포트의 인스턴스로 아웃바운드 트래픽을 허용합니다 |
**내부 로드 밸런서**
다음 표에는 내부 로드 밸런서를 위한 권장 인바운드 규칙이 나와 있습니다.
| 소스 | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *리스너* | 로드 밸런서 리스너 포트에서 VPC CIDR에서 오는 인바운드 트래픽을 허용 |
다음 표에는 내부 로드 밸런서를 위한 권장 아웃바운드 규칙이 나와 있습니다.
| Destination | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *인스턴스 보안 그룹* | TCP | *인스턴스 리스너* | 인스턴스 리스너 포트의 인스턴스로 아웃바운드 트래픽을 허용합니다 |
| *인스턴스 보안 그룹* | TCP | *상태 확인* | 상태 확인 포트의 인스턴스로 아웃바운드 트래픽을 허용합니다 |
## 콘솔을 사용하여 보안 그룹 할당
다음 절차를 사용하여 로드 밸런서에 연결된 보안 그룹을 변경합니다.
**콘솔을 사용하여 로드 밸런서에 할당된 보안 그룹을 업데이트하려면**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창의 **Load Balancing** 아래에서 **로드 밸런서**를 선택합니다.
1. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.
1. **보안** 탭에서 **편집**을 선택합니다.
1. **보안 그룹 편집** 페이지의 **보안 그룹**에서 필요에 따라 보안 그룹을 추가 또는 제거합니다.
최대 5개의 보안 그룹을 추가할 수 있습니다.
1. 작업을 마쳤으면 **변경 사항 저장**을 선택합니다.
## 를 사용하여 보안 그룹 할당 AWS CLI
다음 [apply-security-groups-to-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elb/apply-security-groups-to-load-balancer.html) 명령을 사용하여 보안 그룹과 로드 밸런서를 연결합니다. 지정된 보안 그룹은 이전에 연결된 보안 그룹을 재정의합니다.
```
aws elb apply-security-groups-to-load-balancer --load-balancer-name my-loadbalancer --security-groups sg-53fae93f
```
다음은 응답의 예입니다.
```
{
"SecurityGroups": [
"sg-53fae93f"
]
}
```
# Classic Load Balancer에서 네트워크 ACL 구성
VPC의 기본 네트워크 액세스 제어 목록(ACL)은 인바운드 트래픽과 아웃바운드 트래픽을 모두 허용합니다. 사용자 지정 네트워크 ACL을 생성하는 경우에는 로드 밸런서 및 인스턴스의 통신을 허용하는 규칙을 추가해야 합니다.
로드 밸런서 서브넷을 위한 권장 규칙은 로드 밸런서의 유형(인터넷 경계 또는 내부)에 따라 다릅니다.
**인터넷 경계 로드 밸런서**
다음은 인터넷 경계 로드 밸런서를 위한 권장 인바운드 규칙입니다.
| 소스 | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *리스너* | 로드 밸런서 리스너 포트에서 모든 인바운드 트래픽을 허용 |
| *VPC CIDR* | TCP | 1024-65535 | 휘발성 포트에서 VPC CIDR에서 오는 인바운드 트래픽을 허용 |
다음은 인터넷 경계 로드 밸런서를 위한 권장 아웃바운드 규칙입니다.
| Destination | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *인스턴스 리스너* | 인스턴스 리스너 포트에서 모든 아웃바운드 트래픽을 허용 |
| *VPC CIDR* | TCP | *상태 확인* | 상태 확인 포트에서 모든 아웃바운드 트래픽을 허용 |
| 0.0.0.0/0 | TCP | 1024-65535 | 휘발성 포트에서 모든 아웃바운드 트래픽을 허용 |
**내부 로드 밸런서**
다음은 내부 로드 밸런서를 위한 권장 인바운드 규칙입니다.
| 소스 | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *리스너* | 로드 밸런서 리스너 포트에서 VPC CIDR에서 오는 인바운드 트래픽을 허용 |
| *VPC CIDR* | TCP | 1024-65535 | 휘발성 포트에서 VPC CIDR에서 오는 인바운드 트래픽을 허용 |
다음은 내부 로드 밸런서를 위한 권장 아웃바운드 규칙입니다.
| Destination | 프로토콜 | 포트 범위 | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *인스턴스 리스너* | 인스턴스 리스너 포트에서 VPC CIDR로 가는 아웃바운드 트래픽을 허용 |
| *VPC CIDR* | TCP | *상태 확인* | 상태 확인 포트에서 VPC CIDR로 가는 아웃바운드 트래픽을 허용 |
| *VPC CIDR* | TCP | 1024-65535 | 휘발성 포트에서 VPC CIDR로 가는 아웃바운드 트래픽을 허용 |
# Classic Load Balancer에 대한 사용자 지정 도메인 이름을 구성합니다.
각 Classic Load Balancer는 기본 DNS(도메인 이름 시스템) 이름을 수신합니다. 이 DNS 이름에는 로드 밸런서가 생성되는 AWS 리전의 이름이 포함됩니다. 예를 들어 미국 서부(오레곤) 리전에서 `my-loadbalancer`라는 이름의 로드 밸런서를 생성하면 로드 밸런서가 `my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com` 같은 DNS 이름을 수신합니다. 인스턴스에서 웹 사이트를 액세스하려면 웹 브라우저의 주소 필드에 DNS 이름을 붙여넣습니다. 그러나 이 DNS 이름은 고객들이 쉽게 기억하고 사용할 수 없습니다.
로드 밸런서에서 기본 DNS 이름 대신 `www.example.com` 같이 친숙한 DNS 이름을 사용하려면 사용자 지정 도메인 이름을 생성하고 이를 로드 밸런서의 DNS 이름에 연결할 수 있습니다. 클라이언트가 이러한 사용자 지정 도메인 이름을 사용해 요청을 하면 DNS 서버는 이를 로드 밸런서의 DNS 이름으로 해석합니다.
**Topics**
+ [사용자 지정 도메인 이름을 로드 밸런서 이름에 연결](#dns-associate-custom-elb)
+ [로드 밸런서에 대한 Route 53 DNS 장애 조치 사용](#configure-dns-failover)
+ [로드 밸런서에서 사용자 지정 도메인 이름의 연결 해제](#dns-disassociate-custom-elb)
## 사용자 지정 도메인 이름을 로드 밸런서 이름에 연결
먼저, 아직 등록을 하지 않았다면 도메인 이름부터 등록합니다. 국제인터넷주소관리기구(ICANN)가 인터넷 도메인 이름을 관리합니다. 도메인 이름 등록을 관리하는 ICANN 인증 조직인 *도메인 이름 등록 대행자*를 이용해 도메인 이름을 등록합니다. 등록 대행자 웹 사이트는 도메인 이름 등록에 대한 자세한 지침과 요금 정보를 제공합니다. 자세한 내용은 다음 자료를 참조하세요.
+ Amazon Route 53을 사용하여 도메인 이름을 등록하려면 *Amazon Route 53 개발자 안내서*의 [Route 53을 사용하여 도메인 이름 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)을 참조하세요.
+ 인증된 등록 대행자의 목록은 [List of Accredited Registrar](https://www.icann.org/en/accredited-registrars)를 참조하세요.
다음으로 CNAME 레코드를 생성하여 쿼리를 로드 밸런서로 라우팅하려면 도메인 등록 대행자와 같은 DNS 서비스를 사용하면 됩니다. 자세한 내용은 DNS 서비스에 대한 설명서를 참조하십시오.
또는 DNS 서비스로 Route 53을 사용할 수도 있습니다. 도메인을 위해 인터넷에서 트래픽을 라우팅하는 방법이 포함된 *호스팅 영역*과 로드 밸런서로 도메인 이름에 대한 쿼리를 라우팅하는 *별칭 리소스 레코드 세트*를 생성합니다. Route 53은 별칭 레코드 세트에서 DNS 쿼리에 요금을 부과하지 않기 때문에 도메인의 zone apex(예: `example.com`)에서 별칭 리소스 세트를 사용하여 로드 밸런서로 DNS 쿼리를 라우팅할 수 있습니다. 기존 도메인의 DNS 서비스를 Route 53로 전송하는 방법에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [DNS 서비스로 Route 53을 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html) 섹션을 참조하세요.
Route 53을 사용하여 도메인에 대한 호스팅 영역과 별칭 레코드를 생성하려면 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [로드 밸런서로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)을 참조하세요.
## 로드 밸런서에 대한 Route 53 DNS 장애 조치 사용
Route 53을 사용하여 로드 밸런서에 DNS 요청을 라우팅하는 경우, Route 53을 사용하여 로드 밸런서에 대한 DNS 장애 조치를 구성할 수도 있습니다. 장애 조치 구성에서 Route 53은 로드 밸런서에서 등록 EC2 인스턴스의 상태를 확인하여 가용 여부를 결정합니다. 로드 밸런서에 정상 상태의 EC2 인스턴스가 등록되어 있지 않거나 로드 밸런서 자체가 정상 상태가 아니면 Route 53은 정상 상태 로드 밸런서나 Amazon S3의 정적 웹 사이트 같은 또 다른 가용 리소스로 트래픽을 라우팅합니다.
예를 들어 `www.example.com`에 대한 웹 사이트가 있고 서로 다른 리전에 상주하는 두 개의 로드 밸런서에서 중복 인스턴스를 실행하고 싶다고 가정합시다. 한 리전의 로드 밸런서에 트래픽을 주로 라우팅하고 다른 리전의 로드 밸런서는 장애 시 백업으로 사용하고 싶을 수 있습니다. DNS 장애 조치를 구성하면 주 및 보조(백업) 로드 밸런서를 지정할 수 있습니다. Route 53은 주 로드 밸런서가 사용 가능한 상태일 때는 여기로 트래픽을 라우팅하고, 그러지 않으면 보조 로드 밸런서로 라우팅합니다.
**대상 상태 사용**
+ Classic Load Balancer의 별칭 레코드에서 대상 상태 평가가 `Yes`로 설정된 경우 Route 53은 `alias target` 값으로 지정된 리소스의 상태를 평가합니다. Classic Load Balancer 경우 Route 53은 로드 밸런서와 연결된 인스턴스 상태 확인을 사용합니다.
+ Classic Load Balancer에 등록된 인스턴스 중 하나 이상이 정상인 경우 Route 53은 별칭 레코드를 정상 상태로 표시합니다. 그러면 Route 53은 라우팅 정책에 따라 레코드를 반환합니다. 장애 조치 라우팅 정책을 사용하는 경우 Route 53는 기본 레코드를 반환합니다.
+ Classic Load Balancer에 등록된 모든 인스턴스가 비정상이면 Route 53은 별칭 레코드를 비정상으로 표시합니다. 그러면 Route 53은 라우팅 정책에 따라 레코드를 반환합니다. 장애 조치 라우팅 정책을 사용하는 경우 Route 53은 보조 레코드를 반환합니다.
자세한 내용은 *Amazon Route 53 개발자 안내서의*의 [DNS 장애 조치 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)을 참조하세요.
## 로드 밸런서에서 사용자 지정 도메인 이름의 연결 해제
호스팅 영역에서 먼저 리소스 레코드 세트를 삭제한 다음 호스팅 영역을 삭제하면 로드 밸런서 인스턴스에서 사용자 지정 도메인 이름의 연결을 해제할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [레코드 편집](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html) 및 [퍼블릭 호스팅 영역 삭제](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DeleteHostedZone.html)를 참조하세요.