Amazon EC2
AWS 클라우드
Elastic Load Balancing 시작하기


  • 일반

    Q: 내 애플리케이션에 맞는 로드 밸런서는 어떻게 결정합니까?

    Elastic Load Balancing은 3가지 유형의 로드 밸런서를 지원합니다. 애플리케이션 필요에 따라 적절한 로드 밸런서를 선택할 수 있습니다. 유연한 애플리케이션 관리와 TLS 종료가 필요한 경우 Application Load Balancer를 사용하는 것이 좋습니다. 애플리케이션에 탁월한 성능 및 고정 IP가 필요한 경우 Network Load Balancer를 사용하는 것이 좋습니다. 애플리케이션이 EC2 Classic 네트워크에서 구축된 경우 Classic Load Balancer를 사용해야 합니다.

    Q: 퍼블릭 IP를 사용하지 않고도 내 Amazon Virtual Private Cloud(VPC)에서 Elastic Load Balancing API에 비공개로 액세스할 수 있습니까?

    예. VPC 엔드포인트를 생성하면 Amazon Virtual Private Cloud(VPC)에서 Elastic Load Balancing API에 비공개로 액세스할 수 있습니다. VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 게이트웨이 또는 VPN 연결을 사용할 필요 없이 AWS 네트워크에서 VPC와 Elastic Load Balancing API 간 라우팅을 처리합니다. Elastic Load Balancing이 사용하는 최신 세대 VPC 엔드포인트는 AWS PrivateLink에서 제공합니다. 이는 Elastic Network Interface(ENI)를 사용하는 AWS 서비스와 VPC 내 프라이빗 IP 간에 프라이빗 연결을 지원하는 AWS 기술입니다. AWS PrivateLink에 대해 자세히 알아보려면 AWS PrivateLink 설명서로 이동하십시오.
     

  • Application Load Balancer

    Q: 애플리케이션 로드 밸런서가 지원하는 운영 체제는 무엇입니까?
    애플리케이션 로드 밸런서는 Amazon EC2 서비스가 현재 지원하는 모든 운영 체제에서 대상을 지원합니다.

    Q: Application Load Balancer가 지원하는 프로토콜은 무엇입니까?
    Application Load Balancer는 HTTP 및 HTTPS(보안 HTTP) 프로토콜을 사용하는 애플리케이션의 로드 밸런싱을 지원합니다.

    Q: Application Load Balancer에서 HTTP/2가 지원됩니까?
    예. 애플리케이션 로드 밸런서에서 HTTP/2는 기본적으로 지원됩니다. HTTP/2를 지원하는 클라이언트는 TLS를 통해 애플리케이션 로드 밸런서와 연결할 수 있습니다.

    Q: 어떤 TCP 포트를 사용하여 로드 밸런싱할 수 있습니까?
    다음과 같은 TCP 포트에 대해 로드 밸런싱을 수행할 수 있습니다. 1-65535

    Q: 애플리케이션 로드 밸런서에서 웹 소켓이 지원됩니까?
    예. 애플리케이션 로드 밸런서에서는 웹 소켓 및 보안 웹 소켓 지원이 기본적으로 제공되며 사용할 준비가 되어 있습니다.

    Q: Application Load Balancer에서 요청 추적이 지원됩니까?
    예. Application Load Balancer에서는 요청 추적 기능이 기본적으로 활성화되어 있습니다.

    Q: 기존 로드 밸런서(클래식 로드 밸런서)가 애플리케이션 로드 밸런서와 동일한 기능 및 혜택을 가집니까?
    일부 기능이 중복되기는 하지만 AWS는 두 로드 밸런서 유형 간의 기능 패리티를 유지할 계획이 없습니다. 애플리케이션 로드 밸런서는 AWS의 향후 애플리케이션 계층 로드 밸런싱 플랫폼의 토대입니다.

    Q: Amazon EC2 인스턴스를 애플리케이션 로드 밸런서의 트래픽만 허용하도록 구성할 수 있습니까?
    예.

    Q: 애플리케이션 로드 밸런서의 프런트 엔드에 사용할 보안 그룹을 구성할 수 있습니까?
    예.

    Q: 클래식 로드 밸런서와 함께 사용하는 기존의 API를 애플리케이션 로드 밸런서와 함께 사용할 수 있습니까?
    아니요. 애플리케이션 로드 밸런서는 새로운 API 세트가 필요합니다.

    Q: Application Load Balancer와 Classic Load Balancer는 어떻게 동시에 관리합니까? 
    ELB 콘솔을 사용하면 동일한 인터페이스에서 애플리케이션 및 클래식 로드 밸런서를 관리할 수 있습니다. CLI 또는 SDK를 사용하는 경우 애플리케이션 로드 밸런서에 대해서는 다른 ‘서비스’를 사용해야 합니다. 예를 들어 CLI에서는 클래식 로드 밸런서를 `aws elb describe-load-balancers`로 설명하고, 애플리케이션 로드 밸런서는 `aws elbv2 describe-load-balancers`로 설명합니다.

    Q: 클래식 로드 밸런서를 애플리케이션 로드 밸런서로(또는 그 반대로) 전환할 수 있습니까?
    아니요. 한 로드 밸런서 유형을 다른 유형으로 전환할 수 없습니다.

    Q: 애플리케이션 로드 밸런서로 마이그레이션하는 방법은 무엇입니까?
    클래식 로드 밸런서와 애플리케이션 로드 밸런서 모두에 동일한 백엔드 인스턴스를 동시에 연결합니다. 그러면 기존 스택을 변경하지 않고 트래픽을 한 엔드포인트에서 다른 엔드포인트로 마이크레이션할 수 있습니다. DNS가 애플리케이션 로드 밸런서를 가리키도록 변경하기 전에 새 플랫폼에서 애플리케이션의 비헤이비어를 테스트해야 합니다.

    Q: 애플리케이션 로드 밸런서를 4계층 로드 밸런서로 사용할 수 있습니까?
    아니요. 4계층 기능이 필요한 경우 Network Load Balancer를 사용해야 합니다.

    Q: 단일 애플리케이션 로드 밸런서를 사용해 HTTP 및 HTTPS 요청을 처리할 수 있습니까?
    예. 단일 애플리케이션 로드 밸런서에 HTTP 포트 80과 HTTPS 포트 443에 대한 리스너를 추가할 수 있습니다.

    Q: 보안 분석 및 운영 문제 해결 목적으로 내 계정에서 이루어진 애플리케이션 로드 밸런싱 API 호출 기록을 얻을 수 있습니까?
    예. 계정에서 이루어진 애플리케이션 로드 밸런서 API 호출 기록을 얻으려면 AWS CloudTrail을 사용합니다.

    Q: 애플리케이션 로드 밸런서는 HTTPS 종료를 지원합니까?
    예. 애플리케이션 로드 밸런서에서 HTTPS 연결을 종료할 수 있습니다. SSL 인증서를 로드 밸런서에 설치해야 합니다. 로드 밸런서는 이 인증서를 사용하여 연결을 종료한 후, 클라이언트의 요청을 복호화하여 대상으로 전송합니다.

    Q: SSL 인증서를 받으려면 어떻게 해야 합니까?
    AWS Certificate Manager를 사용하여 SSL/TLS 인증서를 프로비저닝할 수 있습니다. 또는 인증서를 요청하고 요청한 인증서에 CA의 서명을 받은 후, AWS Certification Manager 또는 AWS Identity and Access Management(IAM) 서비스를 사용하여 인증서를 업로드하여 다른 곳에서 인증서를 확보할 수도 있습니다.

    Q: 애플리케이션 로드 밸런서는 AWS Certificate Manager(ACM)와 어떻게 통합됩니까?
    애플리케이션 로드 밸런서는 AWS Certificate Management(ACM)와 통합됩니다. ACM과 통합되면서 아주 간단하게 인증서를 로드 밸런서에 연결할 수 있게 되어 전체 SSL 오프로드 프로세스가 매우 간편해졌습니다. SSL/TLS 인증서를 구매, 업로드 및 갱신하는 작업은 시간이 소모되고 복잡한 수동 프로세스입니다. ACM이 애플리케이션 로드 밸런서와 통합되면서 이러한 전체 프로세스가 단축되어, 신뢰할 수 있는 SSL/TLS 인증서를 요청하고 ACM 인증서를 선택하기만 하면 로드 밸런서에 인증서를 프로비저닝할 수 있습니다.

    Q: 애플리케이션 로드 밸런서에서 백엔드 서버 인증이 지원됩니까?
    아니요. 애플리케이션 로드 밸런서를 사용하는 백엔드에 대해서는 암호화만 지원됩니다.

    Q: 내 Application Load Balancer에 SNI(서버 이름 표시)를 활성화하려면 어떻게 해야 합니까?
    하나 이상의 TLS 인증서를 로드 밸런서의 동일한 보안 리스너에 연결하면 SNI가 자동으로 활성화됩니다. 이와 마찬가지로 하나의 인증서만 보안 리스너에 연결하는 경우 보안 리스너에 대한 SNI 모드가 자동으로 비활성화됩니다.

    Q: 같은 도메인용 인증서 여러 개를 보안 리스너에 연결할 수 있습니까?
    예. 같은 도메인용 인증서 여러 개를 보안 리스너에 연결할 수 있습니다. 예를 들면, 다음 인증서를 연결할 수 있습니다.
    (a) ECDSA 및 RSA 인증서
    (b) 키 크기가 서로 다른(예: 2K, 4K) SSL/TLS 인증서
    (c) 단일 도메인, 멀티 도메인(SAN) 및 와일드카드 인증서

    Q: Application Load Balancer에서 IPv6를 지원합니까?
    예. Application Load Balancer에서 IPv6를 지원합니다.

    Q: 애플리케이션 로드 밸런서에 대한 규칙은 어떻게 설정합니까?
    로드 밸런서용으로 구성하는 각 리스너에 대해 규칙을 구성할 수 있습니다. 규칙에는 조건과 해당 조건 시 작업이 포함됩니다. 조건은 서비스의 URL 경로(예: /img)이고 작업은 전달입니다. 규칙 설정되면 로드 밸런서가 규칙을 사용하여 요청을 라우팅할 서비스를 결정합니다.

    Q: 애플리케이션 로드 밸런서용 리소스에는 제한이 있습니까?
    AWS 계정은 애플리케이션 로드 밸런서에 대해 다음의 제한이 있습니다.

    Q: Load Balancer 뒤쪽의 웹 애플리케이션을 웹 공격으로부터 보호하려면 어떻게 해야 합니까?
    Application Load Balancer를 AWS WAF와 통합할 수 있습니다. AWS WAF는 IP 주소, HTTP 헤더 및 사용자 정의 URI 문자열을 기반으로 규칙을 구성함으로써 웹 공격으로부터 웹 애플리케이션을 보호하는 웹 애플리케이션 방화벽입니다. AWS WAF에서는 이러한 규칙을 사용하여 웹 애플리케이션에 대한 웹 요청을 차단, 허용 또는 모니터링(계수)할 수 있습니다. 자세한 내용은 AWS WAF Developer Guide를 참조하십시오.

    Q: 원하는 임의 IP 주소로 로드 밸런싱 할 수 있습니까?
    로드 밸런서의 VPC 내에 있는 대상에는 로드 밸런서의 VPC CIDR의 모든 IP 주소를 사용할 수 있고, 로드 밸런서의 VPC 외부에 위치한(예를 들어 AWS Direct Connect 또는 VPN 연결을 통해 액세스할 수 있는 피어링된 VPC, EC2-Classic 및 온프레미스 위치) 대상에는 RFC 1918 범위(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16) 또는 RFC 6598 범위(100.64.0.0/10)의 모든 IP 주소를 사용할 수 있습니다.

    Q: VPC와 온프레미스 위치에 배포된 애플리케이션을 로드 밸런싱하려면 어떻게 해야 합니까?
    하이브리드 로드 밸런싱을 실현할 수 있는 다양한 방법이 있습니다. 애플리케이션이 VPC와 온프레미스 위치 간에 배포된 여러 대상에서 실행된다면, 대상의 IP 주소를 사용하여 대상을 같은 대상 그룹에 추가할 수 있습니다. 애플리케이션에 영향을 주지 않고 AWS로 마이그레이션하기 위해서는 점진적으로 VPC 대상을 대상 그룹에 추가하고 대상 그룹에서 온프레미스 대상을 제거합니다. 예를 들어 한 애플리케이션의 대상은 VPC에 있고 다른 애플리케이션의 대상은 온프레미스 위치에 있는 서로 다른 애플리케이션을 보유한 경우, VPC 대상을 한 대상 그룹에 넣고 온프레미스 대상을 또 다른 대상 그룹에 넣은 후 콘텐츠 기반 라우팅을 사용하여 트래픽을 각 대상 그룹으로 라우팅할 수 있습니다. 또한, VPC와 온프레미스 대상에 별개의 로드 밸런서를 사용하고 DNS 가중치를 사용하여 VPC와 온프레미스 대상 간에 가중치 기반 로드 밸런싱을 실현할 수 있습니다.

    Q: EC2-Classic 인스턴스로 로드 밸런싱하려면 어떻게 해야 합니까?
    인스턴스 ID를 대상으로 등록하는 경우에는 EC2-Classic 인스턴스로 로드 밸런싱할 수 없습니다. 하지만 ClassicLink를 사용하여 이러한 EC2-Classic 인스턴스를 로드 밸런서의 VPC에 연결하고 해당 EC2-Classic 인스턴스의 프라이빗 IP를 사용하면, EC2-Classic 인스턴스로 로드 밸런싱할 수 있습니다. 현재 Classic Load Balancer를 통해 EC2-Classic 인스턴스를 사용하고 있는 경우, 손쉽게 Application Load Balancer로 마이그레이션할 수 있습니다.

    Q: Application Load Balancer는 어떻게 과금됩니까?
    Application Load Balancer가 실행된 시간 또는 부분 시간 그리고 시간당 사용된 로드 밸런서 용량 단위(LCU)에 대해 요금이 부과됩니다.

    Q: 로드 밸런서 용량 단위(LCU)란 무엇입니까?
    LCU는 애플리케이션 로드 밸런서 요금을 결정하기 위한 새로운 측정치입니다. LCU는 애플리케이션 로드 밸런서가 트래픽을 처리하는 차원(새 연결, 활성 연결 및 대역폭) 중 하나에서 최대로 소비된 리소스를 정의합니다.

    Q: Classic Load Balancer는 LCU를 기준으로 과금됩니까?
    아니요. Classic Load Balancer는 계속해서 대역폭 및 사용 시간을 기준으로 요금이 부과됩니다.

    Q: Application Load Balancer가 사용 중인 LCU는 어떻게 확인합니까 ?
    CloudWatch를 통해 LCU에 기여하는 네 차원 모두의 사용량을 확인합니다.

    Q: 모든 차원이 LCU 기준으로 과금됩니까?
    아니요. 시간당 LCU는 LCU를 구성하는 세 차원 중에서 소비된 최대 리소스를 기준으로 결정됩니다.

    Q: 부분 LCU도 과금됩니까?
    예.

    Q: 새 AWS 계정 Application Load Balancer 프리 티어가 제공됩니다?
    예. 새 AWS 계정에는 Application Load Balancer 프리 티어로 750시간 및 15LCU가 제공됩니다. 이러한 프리 티어 혜택은 AWS 신규 고객에게만 제공되며 AWS 가입일로부터 12개월 동안 유효합니다.

    Q: 프리 티어로 Application Load Balancer와 Classic Load Balancer를 동시에 사용할 수 있습니까?
    예. 클래식 및 Application Load Balancer 모두 15GB 및 15 LCU를 각각 사용할 수 있습니다. 로드 밸런서 사용 시간 750시간은 Classic Load Balancer와 Application Load Balancer가 합산됩니다.

    Q: 규칙 평가란 무엇입니까?
    규칙 평가는 처리된 규칙 수와 한 시간 동안의 평균 요청 속도의 곱으로 정의됩니다.

    Q: 인증서 유형 및 키 크기가 서로 다를 경우 LCU는 어떻게 청구됩니까?
    인증서 키 크기는 청구를 위한 LCU 계산에서 초당 새로 연결된 수에만 영향을 미칩니다.
    아래 표에는 RSA 및 ECDSA 인증서의 서로 다른 키 크기에 대한 해당 차원의 값이 나열되어 있습니다. 

    RSA 인증서        
    키 크기 <=2K  <=4K  <=8K  >8K 
    새로운 연결/초 25 5 1 0.25
    ECDSA 인증서        
    키 크기  <=256 <=384 <=521 >521 
    새로운 연결/초 25 5 1 0.25
  • Network Load Balancer

    Q: 내 Network Load Balancer 리스너에 대해 TCP(4계층)를 생성할 수 있습니까?

    예. Network Load Balancer는 TCP(4계층) 리스너만 지원합니다.

    Q: Network Load Balancer에서 사용 가능한 주요 기능은 무엇입니까?

    Network Load Balancer는 TCP(4계층) 로드 밸런싱을 제공합니다. Network Load Balancer는 초당 수백만 개의 요청과 갑작스럽고 변덕스러운 트래픽 패턴을 처리하도록 설계되었으며 매우 짧은 지연 시간을 제공합니다. 또한 Network Load Balancer는 클라이언트의 소스 IP를 유지하고 안정적인 IP 지원과 영역 격리를 제공합니다. WebSocket 유형 애플리케이션에 매우 유용한 장기간 연결도 지원합니다.

    Q: Network Load Balancer를 Classic Load Balancer의 TCP 리스너에서 얻은 것과 비교하려면 어떻게 해야 합니까?

    Network Load Balancer는 Classic Load Balancer에서는 유지하지 않는 클라이언트의 소스 IP를 유지합니다. 고객은 Classic Load Balancer에서 프록시 프로토콜을 사용하여 소스 IP를 얻을 수 있습니다. Network Load Balancer는 로드 밸런서에 가용 영역당 고정 IP를 자동으로 제공하며 로드 밸런서에 가용 영역당 탄력적 IP도 할당할 수 있습니다. 이는 Classic Load Balancer에서는 지원되지 않습니다. Classic Load Balancer는 Network Load Balancer에서는 사용할 수 없는 SSL 종료를 제공합니다.

    Q: Classic Load Balancer에서 Network Load Balancer로 마이그레이션하려면 어떻게 해야 합니까?

    Classic Load Balancer와 Network Load Balancer 모두에 동일한 백엔드 대상을 동시에 연결합니다. 그러면 기존 스택을 변경하지 않고 트래픽을 한 엔드포인트에서 다른 엔드포인트로 마이크레이션할 수 있습니다. DNS가 Network Load Balancer를 가리키도록 변경하기 전에 새 플랫폼에서 애플리케이션의 비헤이비어를 테스트해야 합니다.

    Q: Network Load Balancer용 리소스에는 제한이 있습니까?

    예. 자세한 내용은 Network Load Balancer 제한 설명서를 참조하십시오.

    Q: AWS Management Console을 사용하여 내 Network Load Balancer를 설정할 수 있습니까?

    예. AWS Management Console, AWS CLI 또는 API를 사용하여 Network Load Balancer를 설정할 수 있습니다.

    Q: 내 Network Load Balancer에 기존 Classic Load Balancer의 API를 사용할 수 있습니까?

    아니요. Classic Load Balancer를 생성하려면 2012-06-01 API를 사용합니다. Network Load Balancer 또는 Application Load Balancer를 생성하려면 2015-12-01 API를 사용합니다.

    Q: 단일 가용 영역에서 내 Network Load Balancer를 생성할 수 있습니까?

    예. 로드 밸런서 생성 시 단일 서브넷을 제공하면 단일 가용 영역에서 내 Network Load Balancer를 생성할 수 있습니다.

    Q: Network Load Balancer는 DNS 리전 및 영역 장애 조치를 지원합니까?

    예. Amazon Route 53 상태 확인 및 DNS 장애 조치 기능을 사용하면 Network Load Balancer 뒤에서 실행되는 애플리케이션의 가용성을 높일 수 있습니다. Route 53 DNS 장애 조치를 사용하면 여러 AWS 가용 영역에서 애플리케이션을 실행할 수 있으며 장애 조치를 위한 대체 로드 밸런서를 여러 리전에 지정할 수도 있습니다. 여러 AZ에 대해 Network Load Balancer를 구성한 경우 해당 가용 영역에 대한 로드 밸런서에 등록된 정상적인 EC2 인스턴스가 없거나 지정된 영역에 있는 로드 밸런서 노드가 정상이 아니면 R-53이 다른 정상 가용 영역에 있는 로드 밸런서 노드를 대체할 수 없습니다.

    Q: ELB-제공 IP와 탄력적 IP가 혼합되었거나 프라이빗 IP가 할당된 Network Load Balancer를 사용할 수 있습니까?

    아니요. Network Load Balancer의 주소는 사용자 또는 ELB가 완벽하게 제어해야 합니다. 이렇게 해야만 Network Load Balancer에서 탄력적 IP를 사용할 때 클라이언트가 알고 있는 모든 주소가 변경되지 않습니다.

    Q: 각 서브넷에서 내 NLB에 하나 이상의 EIP를 할당할 수 있습니까?

    아니요. NLB가 있는 연결된 각 서브넷의 경우 NLB는 단일 공용/인터넷 IP 주소만 지원할 수 있습니다.

    Q: Network Load Balancer를 제거/삭제할 경우 연결되어 있던 탄력적 IP 주소는 어떻게 됩니까?

    로드 밸런서에 연결되어 있던 탄력적 IP 주소는 할당된 풀로 반환되어 나중에 사용할 수 있습니다.

    Q: NLB는 내부 로드 밸런서를 지원합니까?

    NLB는 Application Load Balancer 및 Classic Load Balancer에서 가능했던 것처럼 인터넷 로드 밸런서 또는 내부 로드 밸런서로 설정할 수 있습니다.

    Q: 내부 Network Load balancer는 각 서브넷에서 하나 이상의 프라이빗 IP를 지원합니까?

    아니요. 로드 밸런서가 있는 연결된 각 서브넷의 경우 NLB는 단일 프라이빗 IP만 지원할 수 있습니다.

    Q: 내 Network Load Balancer에서 웹 소켓을 설정할 수 있습니까?

    예. 웹 소켓 프로토콜을 구현하는 대상으로 트래픽을 라우팅하는 TCP 리스너를 구성합니다(https://tools.ietf.org/html/rfc6455). 웹 소켓은 7계층 프로토콜이고 Network Load Balancer는 4계층에서 운영되기 때문에 Network Load Balancer에서 웹 소켓이나 다른 더 높은 수준의 프로토콜을 위한 특별한 처리 방법은 존재하지 않습니다.

    Q: 원하는 임의 IP 주소로 로드 밸런싱을 할 수 있습니까?

    로드 밸런서의 VPC 내에 있는 대상에는 로드 밸런서의 VPC CIDR의 모든 IP 주소를 사용할 수 있고, 로드 밸런서의 VPC 외부에 위치한(예를 들어 AWS Direct Connect를 통해 액세스할 수 있는 EC2-Classic 및 온프레미스 위치) 대상에는 RFC 1918 범위(10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16) 또는 RFC 6598 범위(100.64.0.0/10)의 모든 IP 주소를 사용할 수 있습니다.

    Q: 인스턴스 ID가 아니라 IP 주소를 사용하여 로드 밸런서 뒤에 있는 컨테이너를 대상으로 하면 어떤 이점이 있습니까?

    인스턴스상의 각 컨테이너는 이제 자체 보안 그룹을 가질 수 있고 다른 컨테이너와 보안 규칙을 공유할 필요가 없습니다. 보안 그룹을 ENI에 연결할 수 있고 인스턴스의 각 ENI는 서로 다른 보안 그룹을 가질 수 있습니다. 컨테이너를 특정 ENI의 IP 주소에 매핑하여 컨테이너별로 보안 그룹을 연결할 수 있습니다. IP 주소를 사용해 로드 밸런싱하면 한 인스턴스에서 실행되는 여러 컨테이너가 같은 포트(예를 들어 포트 80)를 사용할 수 있습니다. 여러 컨테이너에서 같은 포트를 사용할 수 있는 기능 덕분에 한 인스턴스의 컨테이너들이 임의 포트가 아니라 잘 알려진 포트를 통해 서로 통신할 수 있습니다.

    Q: VPC와 온프레미스 위치에 배포된 애플리케이션을 로드 밸런싱하려면 어떻게 해야 합니까?

    하이브리드 로드 밸런싱을 실현할 수 있는 다양한 방법이 있습니다. 애플리케이션이 VPC와 온프레미스 위치 간에 배포된 여러 대상에서 실행된다면, 대상의 IP 주소를 사용하여 대상을 같은 대상 그룹에 추가할 수 있습니다. 애플리케이션에 영향을 끼치지 않고 AWS로 마이그레이션하려면 먼저 VPC 대상을 대상 그룹에 점증적으로 추가하고 난 후 온프레미스 대상을 대상 그룹에서 제거하는 것이 좋습니다. 또한 VPC와 온프레미스 대상에 각각 별도의 로드 밸런서를 사용하고, DNS 가중치를 사용하여 VPC와 온프레미스 대상 사이에 가중치가 반영된 로드 밸런싱을 구현할 수도 있습니다.

    Q: EC2-Classic 인스턴스로 로드 밸런싱하려면 어떻게 해야 합니까?

    인스턴스 ID를 대상으로 등록하는 경우에는 EC2-Classic 인스턴스로 로드 밸런싱할 수 없습니다. 하지만 ClassicLink를 사용하여 이러한 EC2-Classic 인스턴스를 로드 밸런서의 VPC에 연결하고 해당 EC2-Classic 인스턴스의 프라이빗 IP를 사용하면, EC2-Classic 인스턴스로 로드 밸런싱할 수 있습니다. 현재 Classic Load Balancer를 통해 EC2-Classic 인스턴스를 사용하고 있는 경우, 손쉽게 Network Load Balancer로 마이그레이션할 수 있습니다.

    Q: Network Load Balancer는 어떻게 과금됩니까?

    Network Load Balancer가 실행된 시간 또는 부분 시간 그리고 시간당 Network Load Balancer에서 사용된 로드 밸런서 용량 단위(LCU)에 대해 요금이 부과됩니다.

    Q: 로드 밸런서 용량 단위(LCU)란 무엇입니까?

    LCU는 Network Load Balancer 요금을 결정하기 위한 새로운 측정치입니다. LCU는 Network Load Balancer가 트래픽을 처리하는 차원(새 연결/흐름, 활성 연결/흐름 및 대역폭) 중 하나에서 최대로 소비된 리소스를 정의합니다.

    Q: 초당 새 연결/흐름은 초당 요청과 동일합니까?

    아니요. 단일 연결에서 여러 요청을 보낼 수 있습니다.

    Q: Classic Load Balancer는 LCU를 기준으로 과금됩니까?

    아니요. Classic Load Balancer는 계속해서 대역폭 및 시간 요금을 기준으로 요금이 부과됩니다

    Q: Network Load Balancer가 사용 중인 LCU는 어떻게 확인합니까 ?

    LCU를 구성하는 3개 차원의 사용량은 모두 Amazon CloudWatch를 통해 공개됩니다.

    Q: 모든 차원이 LCU 기준으로 과금됩니까?

    아니요. 시간당 LCU는 LCU를 구성하는 세 차원 중에서 소비된 최대 리소스를 기준으로 결정됩니다.

    Q: 부분 LCU도 과금됩니까?

    예.

    Q: 새 AWS 계정 Network Load Balancer 프리 티어가 제공됩니다?

    예. 새 AWS 계정에는 Network Load Balancer 프리 티어로 750시간 및 15LCU가 제공됩니다. 이러한 프리 티어 혜택은 AWS 신규 고객에게만 제공되며 AWS 가입일로부터 12개월 동안 유효합니다.

    Q: 프리 티어로 Network Load Balancer와 Classic Load Balancer를 동시에 사용할 수 있습니까?

    예. Application Load Balancer 및 Network Load Balancer는 각각 15LCU, 그리고 Classic Load Balancer는 각각 15GB를 사용할 수 있습니다. 로드 밸런서 사용 시간 750시간은 애플리케이션, Network 및 Classic Load Balancer가 합산됩니다.

  • Classic Load Balancer

    Q: Classic Load Balancer가 지원하는 운영 체제는 무엇입니까?

    Classic Load Balancer는 Amazon EC2 서비스가 현재 지원하는 모든 운영 체제에서 Amazon EC2 인스턴스를 지원합니다.

    Q: Classic Load Balancer가 지원하는 프로토콜은 무엇입니까?
    클래식 로드 밸런서는 HTTP, HTTPS(보안 HTTP), SSL(보안 TCP) 및 TCP 프로토콜을 사용하여 애플리케이션의 로드 밸런싱을 지원합니다.

    Q: 어떤 TCP 포트를 로드 밸런싱할 수 있습니까?
    다음과 같은 TCP 포트에 대해 로드 밸런싱을 수행할 수 있습니다.

    • [EC2-VPC] 1-65535
    • [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

    Q: Classic Load Balancer는 IPv6 트래픽을 지원합니까?
    예. 각 클래식 로드 밸런서에는 관련 IPv4, IPv6 및 dualstack(IPv4와 IPv6) DNS 이름이 있습니다. VPC에서 IPv6는 지원되지 않습니다. VPC에서 네이티브 IPv6를 사용하기 위해 Application Load Balancer를 사용할 수 있습니다.

    Q: Amazon EC2 인스턴스가 클래식 로드 밸런서의 트래픽만 허용하도록 구성할 수 있습니까?
    예.

    Q: 클래식 로드 밸런서의 프런트 엔드에 사용할 보안 그룹을 구성할 수 있습니까?
    Amazon Virtual Private Cloud를 사용하는 경우 클래식 로드 밸런서의 프런트 엔드에 사용할 보안 그룹을 구성할 수 있습니다.

    Q: 단일 클래식 로드 밸런서를 사용해 HTTP 및 HTTPS 요청을 처리할 수 있습니까?
    예. HTTP 포트 80과 HTTPS 포트 443을 단일 클래식 로드 밸런서에 매핑할 수 있습니다.

    Q: 로드 밸런싱한 Amazon EC2 인스턴스가 각 Classic Load Balancer에서 트래픽을 허용하려면 얼마나 많은 연결이 필요합니까?
    클래식 로드 밸런서는 로드 밸런싱한 Amazon EC2 인스턴스와의 연결을 구성하기 위해 시도할 수 있는 최대 연결 횟수에 제한을 두지 않습니다. 따라서 동시 HTTP, HTTPS 또는 SSL 요청 수나 클래식 로드 밸런서가 수신하는 동시 TCP 연결 수에 맞춰 이 수치가 늘어날 수 있습니다.

    Q: 유료 AMI를 사용해 실행한 Amazon EC2 인스턴스를 로드 밸런싱할 수 있습니까?
    AWS Marketplace의 유료 AMI를 사용하여 실행된 Amazon EC2 인스턴스는 로드 밸런싱할 수 있습니다. 하지만 Amazon DevPay 사이트의 유료 AMI로 시작된 인스턴스는 클래식 로드 밸런서가 지원하지 않습니다.

    Q: Amazon Virtual Private Cloud에서 클래식 로드 밸런서를 사용할 수 있습니까?
    예. Elastic Load Balancing 웹 페이지를 참조하십시오.

    Q: 보안 분석 및 운영 문제 해결 목적으로 내 계정에서 이루어진 클래식 로드 밸런서 API 호출 기록을 얻을 수 있습니까?
    예. 계정에서 이루어진 클래식 로드 밸런서 API 호출 기록을 수신하려면 AWS Management Console에서 CloudTrail을 활성화하면 됩니다.

    Q: 클래식 로드 밸런서는 SSL 종료를 지원합니까?
    예. 클래식 로드 밸런서에서 SSL을 종료할 수 있습니다. SSL 인증서를 각 로드 밸런서에 설치해야 합니다. 로드 밸런서는 이 인증서를 사용하여 연결을 종료한 후, 클라이언트의 요청을 복호화하여 백엔드 인스턴스로 전송합니다.

    Q: SSL 인증서를 받으려면 어떻게 해야 합니까?
    AWS Certificate Manager를 사용하여 SSL/TLS 인증서를 프로비저닝할 수 있습니다. 또는 인증서를 요청하고, 요청한 인증서에 CA의 서명을 받은 후, AWS Identity and Access Management(IAM)를 사용하여 인증서를 업로드하여 다른 곳에서 인증서를 확보할 수도 있습니다.

    Q: Classic Load Balancer는 AWS Certificate Manager(ACM)와 어떻게 통합됩니까?
    클래식 로드 밸런서는 이제 AWS Certificate Manager(ACM)와 통합됩니다. ACM과 통합되면서 아주 간단하게 인증서를 각 로드 밸런서에 연결할 수 있게 되어 전체 SSL 오프로드 프로세스가 매우 간편해졌습니다. 일반적으로 SSL/TLS 인증서를 구매, 업로드 및 갱신하는 작업은 시간이 소모되고 복잡한 수동 프로세스입니다. ACM이 클래식 로드 밸런서와 통합되면서 이러한 전체 프로세스가 단축되어, 신뢰할 수 있는 SSL/TLS 인증서를 요청하고 ACM 인증서를 선택하기만 하면 각 로드 밸런서에 인증서를 프로비저닝할 수 있습니다.