sehee

ALB는 여러 Listener를 가지며, 한 listener 당 한 가지 이상의 rule이 존재

e.g., Listener 1이 target group에 트래픽을 보내는 한 가지 규칙이 있을 때

target group은 여러 target을 갖고 있음 EC2 인스턴스나 health check 등

ALB는 TG에 등록된 target으로 요청을 라우팅하기 전에 사용자를 인증할 수 있음

ALB에 SSL, TLS, SSL 인증서를 로드할 수 있음

NLB는 두 AZ 사이에 있고, 클라이언트는 NLB에 연결되어 있음

NLB는 고정된 IP 주소가 있어서 고정 IP로 ENI에 연결됨

NLB는 AZ당 고정 IP가 하나 있어서 elastic IP를 할당할 수 있음

EC2 instance가 NLB의 다른 VPC에 있다면, 이 인스턴스를 NLB에 ID로 등록할 수 없음

ID로 인스턴스를 등록하거나 ECS 작업 내에서 자동으로 클라이언트의 IP는 보존되고 EC2 인스턴스는 클라이언트로부터 직접 발생하는 트래픽을 봄

NLB가 3개의 AZ로 활성화되어 있고 NLB DNS 이름에 대한 DNS 쿼리를 하면 3개의 IP를 갖게 됨, 활성화되어 있는 3개의 AZ와 부합함

NLB는 각 노드에 대해 DNS 이름을 갖고, 사용 가능한 AZ에 기반해 DNS name을 써서 IP 주소 하나만 확인할 수 있음

Connection Idle Timeout

client-ELB connection & ELB-target connection

NLB works without cookies

SSL - Server Name Indication (SNI): 다중 SSL 인증서를 하나의 웹 서버에 로딩하는 문제를 해결함 (다중 웹사이트와 도메인을 지원하는 서버)

Hands-on#01: ALB X-Forwarded Headers

1) create instance

instance user data

#!/bin/bash
# Use this for your user data (script without newlines)
# Installs httpd (Linux 2 version)
yum update -y
yum install -y httpd.x86_64
systemctl start httpd
systemctl enable httpd
echo "Hello World from $(hostname -f)" > /var/www/html/index.html

2) create ALB

- create TG

3) connect ssh

4) Edit the file httpd.conf, edit the LogFormat section with the following

sudo nano /etc/httpd/conf/httpd.conf

<IfModule log_config_module>

#

# The following ... a CustomLog directive (see below).

# 

>> LogFormat "%{X-Forwarded-For}i %{X-Forwarded-Proto}i %{X-Forwarded-Port}i ...

5) Reload Apache

sudo systemctl reload httpd

6) Run the following command to watch your Apache Access Logs

sudo tail -f /var/log/httpd/access_log

172.31.x.x - - [19/Jul/2024:09:26:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
172.31.y.y - - [19/Jul/2024:09:27:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
...
- - - 172.31.x.x - - [19/Jul/2024:09:28:59 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
- - - 172.31.y.y - - [19/Jul/2024:09:29:07 +0000] "GET / HTTP/1.1" 200 64 "-" "ELB-HealthChecker/2.0"
15.248.a.a http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
15.248.b.b http 80 172.31.x.x - - [19/Jul/2024:09:29:53 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- 기존에는 X-Forwarded 헤더가 없지만, ALB DNS name으로 접속(새로고침) 시 IP, protocol, port 정보 확인

Hands-on#02: NLB Proxy Protocol

1) create instance (same user data)

2) create NLB

- create TG

  - choose type IP addresses

  - VPC subnet: EC2 instance private addresses

3) repeat #01 6)

# public IP
15.248.a.a - - [19/Jul/2024:10:02:22 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
# NLB DNS
172.31.x.x - - [19/Jul/2024:10:02:28 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

4) edit TG attributes

- Traffic configuration: enable Proxy protocol v2, Preserve client IP addresses

5) Verify the module mod_remoteip loaded successfully

sudo /usr/sbin/httpd -M | grep -i remoteip

You'll have the following output

> remoteip_module (shared) - 원격 IP 모듈이 응답으로 공유되었다면 모듈이 성공적으로 로드됐다는 의미

6) edit the file

sudo nano /etc/httpd/conf/httpd.conf

Add this line to enable Proxy Protocol - Listen 80 다음 줄에 삽입

>> RemoteIPProxyProtocol On

7) repeat #01 5), 6)

# NLB DNS
15.248.a.a - - [19/Jul/2024:10:12:26 +0000] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"

- NLB와 EC2 instance 사이에 proxy protocol이 작동한다는 것을 증명

References

Udemy, Pass the AWS Certified Advanced Networking Specialty Certification ANS-C01. Taught by an AWS Networking and VPC Expert!, Section 18: Elastic Load Balancers

Vertical Scalability

수직 확장성, 인스턴스의 크기를 확장

Horizental Scalability

수평 확장, 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법, 분배 시스템

High Availability

수직 확장, 적어도 2 데이터 센터(AZ)에서 애플리케이션을 구동시키는 것

High Availability & Scalability For EC2

scale out / in

What is load balancing?

서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 instances 또는 서버들로 전달하는 역할
EC2 인스턴스가 3개, 인스턴스 앞에는 Load Balancer, 사용자는 ELB로 바로 연결됨

Why use a load balancer?

부하를 다수의 다운스트림 인스턴스로 분산하기 위해

Why use an Elastic Load Balancer?

a managed load balancer

다른 서비스들과 통합 가능

Health Checks

EC2 인스턴스가 잘 동작하는지 상태 확인, 포트와 라우트에서 이루어짐
e.g., protocol: HTTP, port: 4567, endpoint: /health -> 인스턴스 응답 200(OK)이 아니라면 unhealthy하다고 판단

Types of load balancer on AWS

Classic load balancer: HTTP, HTTPS, TCP, SSL (secure TCP), 현재는 AWS에서 지원하지 않음

Application Load Balancer(ALB): HTTP, HTTPS, WebSocket
Network Load Balancer(NLB): TCP, TLS (secure TCP), UDP
Gateway Load Balancer(GLB): Operates at layer 3 (Network layer)

Application Load Balancer (v2)

HTTP/2와 WebSocket이 가능
URL 대상 경로에 의한 라우팅이 가능함

Application Load Balancer (v2) Target Groups

EC2 인스턴스가 대상 그룹, ECS tasks, Lambda functions

Network Load Balancer (v2)

가용 영역별로 하나의 고정 IP를 갖는다는 점

Network Load Balancer - Target Groups

NLB를 ALB 앞에 배치하는 경우

NLB: 고정 IP 주소를 얻음, ALB: HTTP 유형의 트래픽을 처리하는 규칙을 얻음

Gateway Load Balancer

모든 로드밸런서보다 낮은 계층에서 동작

Users - GWLB - Target Group - GWLB - Application

uses the GENEVE protocol on port 6081

Sticky Sessions (Session Affinity)

고정성, 고정 세션을 실행, 1번째 클라이언트가 요청을 생성해 EC2에서 첫번째 인스턴스로 이동한다면, 새로운 요청을 했을 때에도 동일한 인스턴스로 이동하도록 함

Sticky Sessions - Cookie Names

고정 세션에는 2가지 유형의 쿠키가 있음, 애플리케이션 기반, 기간 기반 쿠키

Application-based Cookies

Logging IP traffic using Flow Logs

Target Group attributes stickiness 활성 시

Cross-Zone Load Balancing

EC2 인스턴스 2개짜리 로드 밸런서

Without Cross Zone Load Balancing: 각 가용영역 안에서 부하 분산됨

ALB의 Cross-zone LB는 항상 켜져 있음

SSL/TLS - Basics

SSL 인증서: 클라이언트와 로드 밸런서 사이 트래픽이 이동하는 동안 암호화, 전송 중(in-flight) 암호화

송신자-수신자 측에서만 복호화 가능

SSL: 보안 소켓 계층을 의미, 연결을 암호화하는데 사용
TLS: 새로운 버전의 SSL, 전송 계층 보안

퍼블릭 인증서는 인증 기관(CA)에서 발급, 인증 기관에는 Comodo, Symantec, GoDaddy, ...

Load Balancer - SSL Certificates

ACM: AWS Certificate Manager

SSL - Server Name Indication

SNI: 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트에 지원할 수 있게 해줌

What's an Auto Scaling Group?

자동화

ASG(Auto Scaling Group)의 목표: scale out - 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나, scale in - 감소한 로드에 맞춰 EC2 인스턴스를 제거하는 것

로드 밸런싱과 페어링하는 경우

Auto Scaling - CloudWatch Alarms & Scaling

CloudWatch 기반으로 ASG를 스케일 인 및 아웃할 수 있음

지표(metric), ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스가 필요 -> 지표에 따라 경보가 울림 -> 경보가 ASG의 스케일링 활동을 유발함 -> 오토 스케일링 그룹이라고 불림 (경보에 의해 내부에서 자동적인 스케일링이 이루어짐)

Auto Scaling Groups - Dynamic Scaling Policies

세 가지 유형

Target Tracking Scaling(대상 추적 스케일링): 기본 기준선을 기준으로 상시 사용이 가능하도록
Simple / Step Scaling: CloudWatch 알람으로 CPU 사용률에 따라 유닛 하나를 추가/제거하는 설정 가능
Scheduled Actions

Auto Scaling Groups - Predictive Scaling

CPU 사용량, 인스턴스 요청이 갈 때마다 연산이 수행되어야 하므로
EC2 인스턴스를 갖는 오토스케일링 그룹, e.g., 요청 수 지표는 3
애플리케이션이 네트워크에 연결된 경우 평균 네트워크 입출력량을 기반으로 스케일링을 수행해서 임계값에 도달할 때 스케일링ㅇ을 수행하도록 설정
직접 CloudWatch에서 애플리케이션 별 지표를 설정하고 이를 기반으로 스케일링 정책을 변경

Auto Scaling Groups - Scaling Cooldowns

EC2 인스턴스 구성 시간을 단축하고 요청을 속히

search > install stress amazon linux 2

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

stress -c 4

[Quiz#05]

1) EC2 인스턴스를 r4.large에서 r4.4xlarge로 확장하는 것은 수직 확장성

2) EC2 인스턴스 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 수평 확장성

3) ELB는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함
- AWS 기반 인프라가 변경되어도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유

4) Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요? - ELB가 고정 세션을 활성화하지 않은 것
- ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줌.(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줌

5) ALB
- X-Forwarded-Port: 클라이언트의 요청 포트를 가져오기 위해 사용
- X-Forwarded-Proto: 클라이언트의 요청 프로토콜을 가져오기 위해 사용

- X-Forwarded-For: (웹사이트로 연결된) 클라이언트의 IP 주소를 포함하는 헤더

6) Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?

- ELB 상태 확인 활성화 -> ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됨

7) NLB: 가장 높은 성능, 가장 낮은 지연 시간

8) ALB 지원 프로토콜: HTTP, HTTPS, WebSocket / NLB: TCP, UDP

9) ALB는 트래픽을 다른 대상 그룹으로 라우팅할 수 있음 - 기반: 요청 URL 경로, 호스트 이름, HTTP 헤더, 쿼리 문자열, 소스 IP 주소

10) ALB 대상 그룹에 등록된 대상: EC2 인스턴스, 사설 IP 주소, Lambda 함수 등 (NLB는 등록된 대상이 될 수 없음)

11) ALB에 탄력적 IP를 연결할 수 없음, NLB는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있음. ALB와 CLB를 정적 DNS 이름으로 사용할 수 있음

12) ELB가 선점하고 있는 쿠키 이름: AWSALB, AWSALBAPP, AWSALBTG

13) 영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됨

14) ALB 기능 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 기능: 서버 이름 표식(SNI)

15) 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 ALB에서 각 호스트 이름에 HTTPS를 구성하려고 할 때 ALB에 서버 이름 표식(SNI)을 사용함

16) 오토 스케일링 그룹은 스케일 아웃 시, 구성된 최대 용량을 넘어설 수 없음

17) Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?
- 오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있음. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행함

18) 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링할 때: 백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않기에 CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 함
- CloudWatch 사용자 지정 지표를 생성한 후 ASG를 스케일링하기 위한 CloudWatch 경보를 생성

19) ALB의 크기를 수동으로 조정해 EC2 인스턴스의 평균 연결 개수를 약 1,000개가 되도록 조정 정책을 정의하려고 할 때, 대상 추적 조정 정책을 수행함
- ALB만이 EC2 인스턴스로 액세스할 수 있게 하는 가장 안전한 방법임. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙⭐️

20) 한 웹 사이트가 애플리케이션 로드 밸런서 뒤에 있는 오토 스케일링 그룹의 EC2 인스턴스에서 호스팅되고 있습니다. 현재 HTTP로 서비스 중인 웹 사이트를 HTTPS로 바꾸는 작업을 진행하고 있습니다. ACM 인증서를 발급받아 애플리케이션 로드 밸런서에 적용한 상태입니다. 사용자들이 HTTP가 아닌 HTTPS를 사용해 웹 사이트에 접속하게 하려면 어떻게 해야 합니까?
- 애플리케이션 로드 밸런서가 HTTP를 HTTPS로 리디렉션하도록 설정함

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 8

ELB (Elastic Load Balancing)

0. 로드밸런서의 탄생

VPC 내 단일 서버를 통한 서비스를 구성해서 사용자가 접근하는 환경에서는, 단일 서버가 장애가 발생되면 서비스를 받을 수 없다.

지속적인 서비스 제공을 위해 서버를  다중화 구성해서 서비스의 연속성을 보장하는 고가용성 구성이 필요하다.

다수의 서버를 구성해서 서비스를 제공하면, 인스턴스 하나의 장애가 발생하더라도 다른 인스턴스로 서비스를 받을 수 있다.

하지만 서비스 타깃을 사용자 입장에서 일일이 지정해줘야 하는데,
사용자 입장에서 장애를 인지하여 타깃을 변경하기 전까지는 서비스를 받을 수 없을 것이고 이러한 환경은 서비스 연속성을 보장하는 고가용성 구성이라고 할 수 없을 것이다.

이러한 문제를 해결하기 위해 부하 분산 기술인 로드 밸런서(Load Balancer)가 존재한다.

1. 웹 트래픽 증가에 대한 처리 방식

1) Scale-up

CPU, 메모리, 디스크 등의 기능을 업그레이드 하는 방식

기존보다 높은 성능을 보유한 서버로 시스템을 업그레이드함으로써 문제를 해결하는 방식으로,

필요로 하는 성능이 높아질수록 비용이 기하급수적으로 늘어나는 단점이 있다.

또한 하나의 서버에서 웹 서비스를 제공하여 서버 중지 및 장애로 인해 웹 서비스 가용성에 문제가 발생할 수 있다.

2) Scale-out

저렴한 노드 여러 개를 하나의 Cluster로 구성하는 방식

Cluster 내 하나의 노드에 문제가 발생해도 웹 서비스가 중단되지 않으므로 가용성이 높은 웹 서비스를 구성할 수 있다.

로드 밸런싱은 Scale-out 방식의 웹 서비스 구성에 주로 사용되고, 트래픽을 분산 처리함으로써 높은 가용성과 부하 분산을 통한 고효율 웹 서비스를 제공한다.

2. ELB 정의

EC2(Elastic Compute Cloud) 인스턴스의 상태를 확인하고 데이터를 분산해서 전달하는 단일 접점 역할을 수행한다.

* EC2: 컴퓨팅 리소스를 제공하는 서비스

로드 밸런서는 크게 자신이 서비스하는 대상을 정의하는 리스너(Listener)와 부하 분산 대상을 정의하는 대상 그룹(Target Group)으로 이루어져 있다.

- 리스너: 부하 분산 처리를 위한 서비스 정의

프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스, 로드 밸런서에서 서비스하고자 하는 프로토콜과 포트를 지정하는 규칙을 생성(TCP, TLS, UDP, HTTP(S) 등)

- 대상 그룹: 부하 분산 대상 그룹 정의

 하나 이상의 대상을 라우팅하여 부하 분산을 하는 데 사용됨. 대상 그룹(target group)에 속한 대상에 대해 주기적으로 확인하는 프로세스(keepalive)를 통해 상태 확인(health check)을 수행한다.

3. 로드 밸런싱 방식

Round Robin

Real 서버의 Session 연결을 순차적으로 맺어주는 방식

연결되어 있는 Session 수에 상관 없이 순차적으로 연결시키는 방식으로 Session에 대한 보장을 제공하지 않는다.

Hash

hash 알고리즘을 이용한 로드 밸런싱 방식

Client와 Server 간에 연결된 Session을 계속 유지해 주는 방식으로 Client가 특정 Server로 연결된 이후 동일 서버로만 연결되는 구조로 Session에 대한 보장을 제공한다.

Least Connection

Session 수를 고려하여 가장 작은 Session을 보유한 서버로 Session을 맺어주는 연결 방식

Sesison에 대한 보장을 제공하지 않는다.

4. ELB 종류

Application Load Balancer, Network Load Balancer, Classic Load Balancer 3가지 유형

ALB

HTTP나 HTTPS와 같이 웹 애플리케이션에 대한 분산 처리를 제공(7계층)

URL 경로 기반 라우팅, 호스트 기반 라우팅, HTTP 헤더 기반 라우팅 등과 같이 다양한 규칙을 생성하여

포워드, 리다이렉션, 지정 HTTP 응답 등의 작업 수행 가능

NLB

TCP나 UDP, TLS 프로토콜에 대한 포트 정보를 정의하여 네트워크 기반의 분산 처리를 제공(4계층)

가장 빠른 처리 속도가 가능하고 고정 IP나 탄력적 IP를 보유할 수 있다.
* 탄력적 IP: 동적 클라우드 컴퓨팅을 위해 고안된 정적 IP주소, AWS 계정에 할당되고 릴리스할 때까지 할당된 상태로 유지된다.

CLB

VPC의 예전 버전인 EC2-Classic에 대해서도 분산 처리를 제공, 이전 세대의 로드 밸런서

3-4계층에서 작동, EC2-Classic 네트워크 내에 구축된 애플리케이션을 대상으로 제공

5. ELB 통신 방식

인터넷 연결 (Internet Facing Load Balancer)

퍼블릭 주소를 보유해서, 인터넷을 통해 요청을 로드 밸런서에 등록된 EC2 인스턴스로 라우팅한다.

내부 (Internal Load Balancer)

프라이빗주소를 보유해서, 로드 밸런서를 위한 VPC 내부에 액세스하여 등록된 EC2 인스턴스 등 컴퓨팅 자원으로 라우팅한다.

6. ELB 특징

1) 상태 확인 서비스(Health Check)

대상 그룹에 대한 Keepalive를 통해 주기적으로 상태를 확인한다.

ELB와 연결된 인스턴스의 연결 상태를 수시로 체크해서, 연결 장애나 서비스 가능 여부에 대한 Health Check를 지속적으로 수행한다.

Health Check가 실패하는 경우 해당 인스턴스로 트래픽을 전달하지 않는다.

(이를 위해 HTTP, HTTPS 상태 확인 빈도, 실패 임계치, 성공 시 응답 코드로 임의 설정)

HTTP나 HTTPS 방식은 특정 웹 페이지의 접속 시도에 따른 응답 코드(200)가 정상 반환 여부를 확인해서 Health Check 성공/실패 여부를 판단한다.

2) Sticky Session

처음 연결된 Client에 별도의 HTTP 기반의 쿠키 값을 생성해서 다음 번 연결 요청에 대해 처음 접속했던 서버로 계속 연결하도록 트래픽을 처리한다.

∵ ELB로 트래픽을 부하 분산하는 경우 기본적으로는 Round Robin 방식으로 트래픽을 분산하면 한 번 연결된 Session이 다음 연결 시 그대로 연결되지 않고 다른 인스턴스로 연결될 수 있어 애플리케이션의 Session을 유지할 수 없게 된다.(웹 사이트의 로그인/인증 정보 유지X)

3) 고가용성 구성

ELB로 인입되는 트래픽을 다수의 대상으로 분산하여 고가용성(High Availability)을 유지한다.

고가용성 구성을 위해 Route 53와 같은 AWS의 다른 서비스와의 연계를 통해 가용성 서비스를 제공할 수 있다.

4) 보안 기능

보안 옵션을 부여할 수 있다. (NLB는 보안 그룹이 적용되지 않는다.)

ELB의 SSL Termination 기능을 사용하면 개별 인스턴스에 SSL 인증서를 직접 설치할 필요가 없다.

- 웹 사이트에 SSL 인증서를 적용하여 HTTPS와 같은 방식으로 암호화 통신을 하기 위해서는 개별 웹 서버에 별도의 공인인증서를 구매 후 적용해야 한다.

5) 4계층/7계층 로드밸런싱: 각 계층의 로드 밸런싱을 사용할 수 있음(HTTP/HTTPS: 7계층, TCP/UDP: 4계층)

6) 운영 모니터링: ELB 애플리케이션 성능을 실시간으로 모니터링한다.

References

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK

권영환, 아마존 웹 서비스(AWS Discovery Book), 정보문화사