Elastic Load Balancing의 작동 방식 - Elastic Load Balancing

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Elastic Load Balancing의 작동 방식

로드 밸런서는 클라이언트에서 들어오는 트래픽을 수락하고 요청을 하나 이상의 가용 영역에 등록된 대상(예: EC2 인스턴스)으로 라우팅합니다. 또한, 로드 밸런서는 등록된 대상의 상태를 모니터링하고 정상 대상으로만 트래픽이 라우팅되도록 합니다. 로드 밸런서가 비정상 대상을 감지하면, 해당 대상으로 트래픽 라우팅을 중단합니다. 그런 다음 대상이 다시 정상으로 감지되면 트래픽을 해당 대상으로 다시 라우팅합니다.

하나 이상의 리스너를 지정하여 들어오는 트래픽을 허용하도록 로드 밸런서를 구성합니다. 리스너는 연결 요청을 확인하는 프로세스입니다. 클라이언트와 로드 밸런서 간의 연결을 위한 프로토콜 및 포트 번호로 구성됩니다. 마찬가지로 로드 밸런서와 대상 간의 연결을 위한 프로토콜 및 포트 번호로 구성됩니다.

Elastic Load Balancing은 다음 유형의 로드 밸런서를 지원합니다.

  • Application Load Balancers

  • Network Load Balancer

  • Gateway Load Balancer

  • Classic Load Balancer

로드 밸런서 유형이 구성되는 방법에는 주요 차이점이 있습니다. Application Load Balancer, Network Load Balancer 및 Gateway Load Balancer를 사용하여 대상을 대상 그룹에 등록하고 트래픽을 대상 그룹에 라우팅합니다. Classic Load Balancer에서는 로드 밸런서에 인스턴스를 등록합니다.

가용 영역 및 로드 밸런서 노드

로드 밸런서에서 가용 영역을 활성화하면 Elastic Load Balancing이 해당 가용 영역에서 로드 밸런서 노드를 생성합니다. 가용 영역에 대상을 등록하지만 가용 영역은 활성화하지 않는 경우 이러한 등록된 대상은 트래픽을 수신하지 않습니다. 활성화된 각 가용 영역에 등록된 대상이 하나 이상 있는지 확인하는 경우에 로드 밸런서가 가장 효과적입니다.

모든 로드 밸런서에 대해 여러 가용 영역을 활성화하는 것이 좋습니다. 그러나 Application Load Balancer를 사용하여 최소한 둘 이상의 가용 영역을 활성화해야 합니다. 이 구성을 사용하면 로드 밸런서가 트래픽을 계속 라우팅할 수 있습니다. 가용 영역 하나가 사용할 수 없는 상태가 되거나 정상 상태 대상을 가지고 있지 않은 경우, 로드 밸런서가 다른 가용 영역에 있는 정상 상태의 대상으로 트래픽을 라우팅할 수 있습니다.

가용 영역을 비활성화해도 해당 가용 영역의 대상은 로드 밸런서에 등록된 상태로 남아 있습니다. 대상은 등록된 상태로 유지되지만 로드 밸런서는 트래픽을 해당 대상으로 라우팅하지 않습니다.

교차 영역 로드 밸런싱

로드 밸런서의 노드는 클라이언트로부터 요청을 가져와서 등록된 대상에 분산합니다. 교차 영역 로드 밸런싱을 활성화하면 각 로드 밸런서 노드가 활성화된 모든 가용 영역에 있는 등록된 대상 간에 트래픽을 분산합니다. 교차 영역 로드 밸런싱을 비활성화하면 각 로드 밸런서 노드가 해당 가용 영역에 있는 등록된 대상 간에만 트래픽을 분산합니다.

다음 다이어그램은 기본 라우팅 알고리즘으로서 라운드 로빈이 포함된 교차 영역 로드 밸런싱의 효과를 보여 줍니다. 활성화된 2개의 가용 영역이 있는데 가용 영역 A에는 2개의 대상이 있고 가용 영역 B에는 8개의 대상이 있습니다. 클라이언트는 요청을 보내며, Amazon Route 53은 로드 밸런서 노드 중 하나의 IP 주소를 통해 각 요청에 응답합니다. 라운드 로빈 라우팅 알고리즘에 따라 트래픽이 분산되므로 각 로드 밸런서 노드가 클라이언트가 보낸 트래픽의 50%를 수신하도록 트래픽이 분산됩니다. 각 로드 밸런서 노드는 공유 트래픽을 해당 범위의 등록된 대상에만 분산합니다.

교차 영역 로드 밸런싱이 활성화된 경우 각 10개의 대상이 트래픽의 10%를 수신합니다. 이는 각 로드 밸런서 노드가 클라이언트 트래픽의 50%를 10개의 대상 모두에게 라우팅할 수 있기 때문입니다.

교차 영역 로드 밸런싱이 항상 활성화되어 있는 경우

교차 영역 로드 밸런싱이 비활성화되어 있는 경우:

  • 가용 영역 A의 두 대상이 각각 트래픽의 25%를 받습니다.

  • 가용 영역 B에 있는 8개의 대상은 각각 트래픽의 6.25%를 받습니다.

이는 각 로드 밸런서 노드가 클라이언트 트래픽의 50%를 가용 영역에 있는 대상에만 라우팅할 수 있기 때문입니다.

교차 영역 로드 밸런싱이 항상 비활성화되어 있는 경우

Application Load Balancer를 사용하면 로드 밸런서 수준에서 교차 영역 로드 밸런싱이 항상 사용됩니다. 대상 그룹 수준에서 교차 영역 로드 밸런싱을 비활성화할 수 있습니다. 자세한 내용은 Application Load Balancer 사용 설명서교차 영역 로드 밸런싱 해제를 참조하세요.

Network Load Balancer 및 Gateway Load Balancer를 사용하면 기본적으로 교차 영역 로드 밸런싱이 비활성화됩니다. 로드 밸런서를 생성한 후 언제든지 교차 영역 로드 밸런싱을 활성화하거나 비활성화할 수 있습니다. 자세한 내용은 Network Load Balancer 사용 설명서의 크로스 영역 로드 밸런싱을 참조하세요.

Classic Load Balancer를 생성하면 교차 영역 로드 밸런싱에 대한 기본값은 로드 밸런서 생성 방법에 따라 달라집니다. API 또는 를 사용하면 CLI기본적으로 교차 영역 로드 밸런싱이 비활성화됩니다. 를 사용하면 크로스 영역 로드 밸런싱 AWS Management Console을 활성화하는 옵션이 기본적으로 선택됩니다. Classic Load Balancer를 생성한 후 언제든지 교차 영역 로드 밸런싱을 활성화하거나 비활성화할 수 있습니다. 자세한 정보는 Classic Load Balancer 사용 설명서교차 영역 로드 밸런싱 활성화를 참조하세요.

영역 이동

영역 전환은 Amazon Application Recovery Controller(ARC)()의 기능입니다ARC. 영역 전환을 사용하면 한 번의 작업으로 손상된 가용 영역에서 로드 밸런서 리소스를 다른 곳으로 이동할 수 있습니다. 이러한 방법을 통해 AWS 리전의 다른 정상 가용 영역에서 계속 운영할 수 있습니다.

영역 전환을 시작하면 로드 밸런서가 해당 리소스에 대한 트래픽을 영향을 받는 가용 영역으로 보내는 것을 중단합니다. ARC 는 영역 전환을 즉시 생성합니다. 그러나 영향을 받는 가용 영역에서 진행 중인 기존 연결을 완료하는 데는 보통 몇 분 정도 소요될 수 있습니다. 자세한 내용은 Amazon Application Recovery Controller(ARC) 개발자 안내서영역 전환 작동 방식: 상태 확인 및 영역 IP 주소를 참조하세요.

영역 이동은 교차 영역 로드 밸런싱이 꺼진 상태에서 Application Load Balancer 및 Network Load Balancer에서만 지원됩니다. 교차 영역 로드 밸런싱을 켜면 영역 전환을 시작할 수 없습니다. 자세한 내용은 Amazon Application Recovery Controller(ARC) 개발자 안내서영역 이동에 지원되는 리소스를 참조하세요.

영역 전환을 사용하기 전에 다음을 검토하세요.

  • 영역 이동에서는 교차 영역 로드 밸런싱이 지원되지 않습니다. 이 기능을 사용하려면 교차 영역 로드 밸런싱을 꺼야 합니다.

  • Application Load Balancer를 AWS Global Accelerator에서 액셀러레이터 엔드포인트로 사용할 때는 영역 전환이 지원되지 않습니다.

  • 특정 로드 밸런서에 대한 영역 전환은 단일 가용 영역에 대해서만 시작할 수 있습니다. 여러 가용 영역에 대한 영역 전환은 시작할 수 없습니다.

  • AWS 여러 인프라 문제가 서비스에 영향을 미칠 DNS 때 에서 영역 로드 밸런서 IP 주소를 사전에 제거합니다. 영역 전환을 시작하기 전에 항상 현재 가용 영역 용량을 확인하세요. 로드 밸런서의 교차 영역 로드 밸런싱이 꺼져 있으며 영역 전환을 사용하여 영역 로드 밸런서 IP 주소를 제거하는 경우, 영역 전환의 영향을 받는 가용 영역도 대상 용량을 잃게 됩니다.

  • Network Load Balancer의 대상인 Application Load Balancer는 항상 Network Load Balancer에서 영역 이동을 시작하세요. Application Load Balancer에서 영역 전환을 시작하는 경우 Network Load Balancer는 이동을 인식하지 못하고 Application Load Balancer로 트래픽을 계속 전송합니다.

자세한 지침 및 정보는 Amazon Application Recovery Controller(ARC) 개발자 안내서 Route 53 ARC 영역 이동 모범 사례를 참조하세요.

라우팅 요청

클라이언트가 로드 밸런서에 요청을 전송하기 전에 도메인 이름 시스템(DNS) 서버를 사용하여 로드 밸런서의 도메인 이름을 확인합니다. 로드 밸런서가 amazonaws.com 도메인에 있으므로 Amazon에서 DNS 항목을 제어합니다. Amazon DNS 서버는 클라이언트에 하나 이상의 IP 주소를 반환합니다. 이 주소는 로드 밸런서에 대한 로드 밸런서 노드의 IP 주소입니다. Network Load Balancer에서 Elastic Load Balancing은 활성화된 각 가용 영역에 대해 네트워크 인터페이스를 생성하고 이를 사용하여 정적 IP 주소를 가져옵니다. Network Load Balancer를 생성할 때 필요에 따라 탄력적 IP 주소 하나를 각 네트워크 인터페이스에 연결할 수 있습니다.

시간이 지남에 따라 애플리케이션 트래픽이 변경되면 Elastic Load Balancing은 로드 밸런서를 조정하고 DNS 항목을 업데이트합니다. 또한 이 DNS 항목은 (TTL)를 time-to-live 60초로 지정합니다. 이렇게 하면 트래픽 변화에 따라 IP 주소를 신속하게 다시 매핑할 수 있습니다.

클라이언트는 로드 밸런서로 요청을 전송하는 데 사용할 IP 주소를 결정합니다. 요청을 수신한 로드 밸런서 노드는 등록된 대상 중 상태가 양호한 대상을 선택하고 프라이빗 IP 주소를 사용하여 해당 대상으로 요청을 전송합니다.

자세한 내용은 Amazon Route 53 개발자 안내서 ELB 로드 밸런서에 트래픽 라우팅을 참조하세요.

라우팅 알고리즘

Application Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

  1. 적용할 규칙을 결정하기 위해 우선 순위에 따라 리스너 규칙을 평가합니다.

  2. 대상 그룹에 대해 구성된 라우팅 알고리즘을 사용하여 규칙 조치에 대한 대상 그룹에서 대상을 선택합니다. 기본 라우팅 알고리즘은 라운드 로빈입니다. 대상이 여러 개의 대상 그룹에 등록이 된 경우에도 각 대상 그룹에 대해 독립적으로 라우팅이 수행됩니다.

Network Load Balancer에서 연결을 수신하는 로드 밸런서 노드는 다음 프로세스를 사용합니다.

  1. 흐름 해시 알고리즘을 사용하여 기본 규칙에 대한 대상 그룹에서 대상을 선택합니다. 알고리즘은 다음을 기반으로 합니다.

    • 프로토콜

    • 소스 IP 주소 및 소스 포트

    • 대상 IP 주소 및 대상 포트

    • TCP 시퀀스 번호

  2. 연결 수명 동안 각 개별 TCP 연결을 단일 대상으로 라우팅합니다. 클라이언트의 TCP 연결에는 소스 포트와 시퀀스 번호가 다르며 다른 대상으로 라우팅할 수 있습니다.

Classic Load Balancer에서 요청을 수신하는 로드 밸런서 노드는 다음과 같이 등록된 인스턴스를 선택합니다.

  • TCP 리스너에 라운드 로빈 라우팅 알고리즘 사용

  • HTTP 및 HTTPS 리스너에 대해 미해결 요청 라우팅 알고리즘을 사용합니다.

HTTP 연결

Classic Load Balancer는 사전 개방 연결을 사용하지만 Application Load Balancer는 그렇지 않습니다. Classic Load Balancer와 Application Load Balancer는 모두 연결 멀티플렉싱을 사용합니다. 즉, 여러 프런트 엔드 연결에 있는 여러 클라이언트의 요청을 단일 백엔드 연결을 통해 지정된 대상으로 라우팅할 수 있습니다. 연결 멀티플렉싱은 지연 시간을 최소화하고 애플리케이션의 로드를 줄입니다. 연결 다중화를 방지하려면 HTTP 응답에서 HTTP keep-alive 헤더를 설정하여 Connection: close 헤더를 비활성화합니다.

Application Load Balancer 및 Classic Load Balancer는 프런트 엔드 연결HTTP에서 파이프라인을 지원합니다. 백엔드 연결HTTP에서 파이프라인을 지원하지 않습니다.

Application Load Balancer는 GET, , , HEAD, POSTPUT, DELETE및 HTTP 요청 메서드를 지원합니다OPTIONSPATCH.

Application Load Balancer는 프런트엔드 연결에서 HTTP/0.9, HTTP/1.0, HTTP/1.1 및 HTTP/2 프로토콜을 지원합니다. HTTPS 리스너에서만 HTTP/2를 사용할 수 있으며 HTTP/2 연결을 사용하여 최대 128개의 요청을 병렬로 전송할 수 있습니다. Application Load Balancer는 에서 HTTP로 연결 업그레이드도 지원합니다 WebSockets. 그러나 연결 업그레이드가 있는 경우 Application Load Balancer 리스너 라우팅 규칙 및 AWS WAF 통합이 더 이상 적용되지 않습니다.

Application Load Balancer는 기본적으로 백엔드 연결(등록된 대상에 대한 로드 밸런서)에서 HTTP/1.1을 사용합니다. 그러나 프로토콜 버전을 사용하여 HTTP/2 또는 g를 사용하여 대상에 요청을 보낼 수 있습니다RPC. 자세한 내용은 프로토콜 버전을 참조하세요. keep-alive 헤더는 기본적으로 백엔드 연결에서 지원됩니다. 호스트 헤더가 없는 클라이언트의 HTTP/1.0 요청의 경우 로드 밸런서는 백엔드 연결에서 전송된 HTTP/1.1 요청에 대한 호스트 헤더를 생성합니다. 호스트 헤더에는 로드 밸런서의 DNS 이름이 포함되어 있습니다.

Classic Load Balancer는 프런트 엔드 연결(클라이언트에서 로드 밸런서로)에서 HTTP/0.9, HTTP/1.0 및 HTTP/1.1과 같은 프로토콜을 지원합니다. 백엔드 연결(등록된 대상에 로드 밸런서)에 HTTP/1.1을 사용합니다. keep-alive 헤더는 기본적으로 백엔드 연결에서 지원됩니다. 호스트 헤더가 없는 클라이언트의 HTTP/1.0 요청의 경우 로드 밸런서는 백엔드 연결에서 전송된 HTTP/1.1 요청에 대한 호스트 헤더를 생성합니다. 호스트 헤더에는 로드 밸런서 노드의 IP 주소가 포함되어 있습니다.

HTTP 헤더

Application Load Balancer와 Classic Load Balancer는 X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port 헤더를 요청에 자동으로 추가합니다.

Application Load Balancer는 대상에 보내기 전에 호스트 헤더의 HTTP 호스트 이름을 소문자로 변환합니다.

HTTP/2를 사용하는 프런트엔드 연결의 경우 헤더 이름은 소문자로 표시됩니다. HTTP/1.1을 사용하여 대상에 요청을 전송하기 전에 X-Forwarded-For , X-Forwarded-Proto , X-Forwarded-Port , 호스트 , X-Amzn-Trace-Id , 업그레이드연결 과 같은 헤더 이름이 혼합된 사례로 변환됩니다. 기타 모든 헤더 이름은 소문자입니다.

Application Load Balancer와 Classic Load Balancer는 클라이언트로 다시 응답을 프록시한 후에 들어오는 클라이언트 요청에서 연결 헤더를 인식합니다.

HTTP/1.1을 사용하는 Application Load Balancer 및 Classic Load Balancer가 Expect: 100-Continue 헤더를 수신하면 콘텐츠 길이 헤더를 테스트하지 않고 HTTP/1.1 100 Continue로 즉시 응답합니다. Expect: 100-Continue 요청 헤더는 대상으로 전달되지 않습니다.

HTTP/2를 사용하는 경우 Application Load Balancer는 클라이언트 요청에서 Expect: 100-Continue 헤더를 지원하지 않습니다. Application Load Balancer는 HTTP/2 100으로 응답하지 않습니다. 이 헤더를 계속하거나 대상에 전달합니다.

HTTP 헤더 제한

Application Load Balancer에 대한 다음 크기 제한은 변경할 수 없는 하드 제한입니다.

  • 요청 라인: 16K

  • 단일 헤더: 16K

  • 전체 응답 헤더: 32K

  • 전체 요청 헤더: 64K

로드 밸런서 체계

로드 밸런서를 생성할 때 로드 밸런서를 내부 로드 밸런서 또는 인터넷 경계 로드 밸런서로 생성할지 여부를 선택해야 합니다.

인터넷 경계 로드 밸런서의 노드는 퍼블릭 IP 주소를 가집니다. 인터넷 연결 로드 밸런서의 DNS 이름은 노드의 퍼블릭 IP 주소에서 공개적으로 확인할 수 있습니다. 따라서 인터넷 경계 로드 밸런서는 인터넷을 통해 클라이언트의 요청을 라우팅할 수 있습니다.

내부 로드 밸런서의 노드는 오직 프라이빗 IP 주소만 가집니다. 내부 로드 밸런서의 DNS 이름은 노드의 프라이빗 IP 주소에서 공개적으로 확인할 수 있습니다. 따라서 내부 로드 밸런서는 로드 밸런서에 VPC 대한 에 액세스할 수 있는 클라이언트의 요청만 라우팅할 수 있습니다.

인터넷 경계 및 내부 로드 밸런서는 모두 프라이빗 IP 주소를 사용하여 대상으로 요청을 라우팅합니다. 따라서 대상이 퍼블릭 IP 주소 없이도 내부 또는 인터넷 경계 로드 밸런서에서 요청을 수신할 수 있습니다.

애플리케이션에 여러 계층이 있는 경우 내부 및 인터넷 경계 로드 밸런서를 모두 사용하는 아키텍처를 설계할 수 있습니다. 예를 들어, 애플리케이션이 인터넷에 연결되어야 하는 웹 서버와 웹 서버에만 연결되는 애플리케이션 서버를 사용하는 경우에 해당됩니다. 인터넷 경계 로드 밸런서를 생성하고 여기에 웹 서버를 등록합니다. 내부 로드 밸런서를 생성하고 여기에 애플리케이션 서버를 등록합니다. 웹 서버는 인터넷 경계 로드 밸런서에서 요청을 수신하고 애플리케이션 서버에서 내부 로드 밸런서로 요청을 전송합니다. 애플리케이션 서버는 내부 로드 밸런서에서 요청을 수신합니다.

IP 주소 유형

로드 밸런서에 지정하는 IP 주소 유형은 클라이언트가 로드 밸런서와 통신하는 방법을 결정합니다.

  • IPv4 전용 - 클라이언트는 퍼블릭 및 프라이빗 IPv4 주소를 사용하여 통신합니다. 로드 밸런서에 대해 선택한 서브넷에는 IPv4 주소 범위가 있어야 합니다.

  • 듀얼 스택 - 클라이언트는 퍼블릭 및 프라이빗 IPv4 및 IPv6 주소를 사용하여 통신합니다. 로드 밸런서에 대해 선택한 서브넷에는 IPv4 및 IPv6 주소 범위가 있어야 합니다.

  • 퍼블릭이 없는 듀얼스택 IPv4 - 클라이언트는 퍼블릭 및 프라이빗 IPv6 주소와 프라이빗 IPv4 주소를 사용하여 통신합니다. 로드 밸런서에 대해 선택한 서브넷에는 IPv4 및 IPv6 주소 범위가 있어야 합니다. 이 옵션은 internal 로드 밸런서 체계에서는 지원되지 않습니다.

다음 표에서는 각 로드 밸런서 유형에 지원되는 IP 주소 유형을 설명합니다.

로드 밸런서 유형 IPv4 만 듀얼 스택 퍼블릭이 없는 듀얼 스택 IPv4
Application Load Balancer
Network Load Balancer 아니요
Gateway Load Balancer 아니요
Classic Load Balancer 아니요 아니요

대상 그룹에 지정하는 IP 주소 유형에 따라 로드 밸런서가 대상과 통신하는 방법이 결정됩니다.

  • IPv4 전용 - 로드 밸런서는 프라이빗 IPv4 주소를 사용하여 통신합니다. 대상 그룹에 IPv4 주소를 사용하여 IPv4 대상을 등록해야 합니다.

  • IPv6 전용 - 로드 밸런서는 IPv6 주소를 사용하여 통신합니다. 대상 그룹에 IPv6 주소를 사용하여 IPv6 대상을 등록해야 합니다. 대상 그룹은 듀얼 스택 로드 밸런서와 함께 사용해야 합니다.

다음 표에서는 각 대상 그룹 프로토콜에 지원되는 IP 주소 유형을 설명합니다.

대상 그룹 프로토콜 IPv4 만 IPv6 만
HTTP 및 HTTPS
TCP
TLS
UDP 및 TCP_UDP 아니요
GENEVE - -

로드 밸런서MTU용 네트워크

최대 전송 단위(MTU)는 네트워크를 통해 전송할 수 있는 가장 큰 패킷의 크기를 바이트 단위로 결정합니다. 연결MTU의 가 클수록 단일 패킷으로 전달할 수 있는 데이터가 더 많습니다. 이더넷 프레임은 패킷 또는 전송 중인 실제 데이터와 이를 둘러싼 네트워크 오버헤드 정보로 구성됩니다. 인터넷 게이트웨이를 통해 전송되는 트래픽MTU의 는 1500입니다. 즉, 패킷이 1500바이트를 초과하면 여러 프레임을 사용하여 전송되도록 프래그먼트화되거나 Don't Fragment이(가) IP 헤더에 설정되면 패킷을 삭제합니다.

로드 밸런서 노드의 MTU 크기는 구성할 수 없습니다. 점보 프레임(9001MTU)은 Application Load Balancer, Network Load Balancer 및 Classic Load Balancer의 로드 밸런서 노드에서 표준입니다. Gateway Load Balancer는 8500 을 지원합니다MTU. 자세한 내용은 Gateway Load Balancer 사용 설명서최대 전송 단위(MTU)를 참조하세요.

경로MTU는 발신 호스트와 수신 호스트 간의 경로에서 지원되는 최대 패킷 크기입니다. 경로 MTU 검색(PMTUD)은 두 디바이스 MTU 간의 경로를 결정하는 데 사용됩니다. 경로 MTU 검색은 클라이언트 또는 대상이 점보 프레임을 지원하지 않는 경우 특히 중요합니다.

호스트가 경로를 따라 수신 호스트MTU의 보다 크거나 디바이스MTU의 보다 큰 패킷을 전송하면 수신 호스트 또는 디바이스가 패킷을 삭제한 다음 라는 ICMP 메시지를 반환합니다Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Type 3, Code 4). 이렇게 하면 전송 호스트에 페이로드를 여러 개의 작은 패킷으로 분할한 다음 다시 전송하도록 지시합니다.

클라이언트 또는 대상 인터페이스 MTU 크기보다 큰 패킷이 계속 삭제되는 경우 경로 MTU 검색(PMTUD)이 작동하지 않을 수 있습니다. 이를 방지하려면 경로 MTU 검색이 엔드 투 엔드로 작동하고 클라이언트 및 대상에서 점보 프레임을 활성화했는지 확인합니다. 경로 MTU 검색 및 점보 프레임 활성화에 대한 자세한 내용은 Amazon EC2 사용 설명서경로 MTU 검색을 참조하세요.