ELB 핵심 정리 — ALB·NLB·GWLB와 Auto Scaling

이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 세 번째 편입니다. EC2 한 대를 띄우는 건 사실 시작일 뿐이에요. 진짜 서비스에서는 트래픽이 늘면 인스턴스를 자동으로 늘리고 줄여야 하고, 그 여러 인스턴스 앞에는 트래픽을 골고루 나눠 주는 무언가가 있어야 합니다. SAA-C03에서 시나리오 문제로 가장 많이 나오는 영역이 바로 이 두 가지 — 로드 밸런서(ELB)와 Auto Scaling Group(ASG) 조합이에요.

처음 들으면 단어가 좀 무뚝뚝합니다. "Elastic Load Balancing"이라니요. 그런데 비유로 풀면 정말 단순해요. 회사 안내데스크와 차선 분배 같은 겁니다. 손님이 잔뜩 몰려오면 안내데스크에서 "1번 창구로 가세요, 2번 창구로 가세요" 하고 분배해 주는 거죠. 그 창구가 바빠지면 새 창구를 자동으로 더 여는 게 ASG고요.

이 글에서는 ELB 4종(CLB·ALB·NLB·GWLB)의 차이, ASG의 다섯 가지 스케일링 정책, 그리고 시험 단골인 Sticky Session·Cross-Zone Load Balancing·X-Forwarded-For까지 한 번에 묶어서 풀어 갑니다. 한 번에 다 외우려 하지 마시고, "왜 이렇게 설계됐는가" 만 머리에 들어와도 시나리오 문제는 거의 다 풀려요.

수직 확장·수평 확장·고가용성 — 단어부터 깔끔하게

본격적으로 ELB로 들어가기 전에, 시험에서 거의 매번 한 번씩 등장하는 용어 셋부터 정리하고 갑니다. 처음 들으면 다 비슷해 보이는데, 의미가 다 달라요.

개념	정의	방향	AWS 적용 예
수직 확장 (Vertical / Scale Up·Down)	인스턴스 사양(크기) 변경	위·아래	t2.micro → t2.large, RDS 클래스 변경
수평 확장 (Horizontal / Scale Out·In)	인스턴스 개수 변경	옆으로	EC2 수 늘리기, ASG + ELB
고가용성 (HA)	한 AZ 장애 시에도 서비스 유지	Multi-AZ	RDS Multi-AZ, Multi-AZ ASG

수직 확장은 한 마디로 "한 대를 더 좋은 사양으로 키우는 것"이에요. RDS·ElastiCache처럼 분산이 어려운 시스템에서 자주 씁니다. 다만 하드웨어에는 물리적 한계가 있으니까 무한정 키울 수는 없어요.

수평 확장은 "한 대를 더 좋게 만들지 말고, 같은 사양 여러 대를 옆으로 나란히 두자"는 발상입니다. 웹 앱·분산 시스템에 어울리고, 클라우드에서 가장 흔한 패턴이에요. ASG + ELB 조합은 정확히 이 수평 확장의 대표적인 그림입니다.

고가용성은 그 위에 얹는 개념이에요. 한 AZ(가용 영역)가 통째로 죽어도 서비스가 살아 있어야 한다는 요구사항. 두 갈래로 나뉘는데 — Active-Passive(평소엔 한쪽만 일하고 다른 쪽은 대기, 장애 시 전환 — RDS Multi-AZ가 이 모델)와 Active-Active(여러 AZ에서 동시에 트래픽 처리 — 수평 확장과 자연스럽게 결합)이 있습니다.

여기서 시험 함정이 하나 있어요. 시험 문제에서 키워드만 잘 보면 답이 거의 바로 나옵니다.

• "인스턴스 크기/DB 성능 향상" → 수직 확장
• "인스턴스 개수/Auto Scaling" → 수평 확장
• "AZ 장애 대비/Multi-AZ" → 고가용성

이 매칭만 머리에 있으면 관련 문제는 거의 다 풀려요.

ELB가 도대체 왜 필요한가요

ELB(Elastic Load Balancing) 가 해결하는 문제를 한 번 천천히 풀어 봅니다. 회사로 치면 — 손님이 1명일 때는 직원 한 명이 다 받아도 됩니다. 그런데 손님이 1,000명으로 늘어나면? 직원도 여러 명 둬야 하고, 누가 어느 손님을 받을지 정리해 주는 안내데스크도 필요해져요. 그 안내데스크가 ELB입니다. 더 깊이 파고들 때는 ELB 사용자 가이드 공식 문서 를 옆에 두고 보면 좋아요.

ELB가 해 주는 일은 다섯 가지로 정리됩니다.

• 들어오는 트래픽을 여러 백엔드 EC2로 고르게 분산
• 단일 엔드포인트(DNS) 제공 → 클라이언트가 개별 EC2 IP를 알 필요 X
• Health Check로 비정상 인스턴스로의 트래픽 자동 차단
• SSL Termination — HTTPS 복호화를 ELB가 대신 처리 (EC2 부담 줄임)
• AWS 관리형 서비스 — 유지보수·고가용성을 AWS가 알아서 챙김

여기서 잠깐, Health Check가 뭔지 짚고 갈게요. ELB는 등록된 인스턴스가 살아 있는지 주기적으로 확인합니다. 어떻게? 특정 포트와 경로(예: HTTP, 4567 포트, /health)로 요청을 보내고 — HTTP 200 OK 응답이 오면 정상, 200이 아니면 비정상으로 판정해서 트래픽을 끊어요. 그 인스턴스가 회복해서 다시 200을 보내기 시작하면 자동으로 트래픽을 다시 받게 됩니다. 회사로 치면 직원이 자리에 앉아서 인사하면 손님 보내고, 자리 비우면 안 보내는 식이에요.

여기서 시험 함정이 하나 있어요. ELB 보안 그룹과 EC2 보안 그룹의 관계가 시험에 정말 자주 나옵니다.

회사 비유로 — "정문에는 누구나 들어올 수 있지만, 사무실 문은 정문 카드를 통과한 사람만 열린다"는 식이에요. 이 패턴이 시험 답으로 자주 등장합니다.

ALB — Layer 7, HTTP/HTTPS 고급 라우팅

이제 ELB의 종류를 하나씩 봅니다. 가장 많이 쓰이는 게 Application Load Balancer(ALB)예요. 이름 그대로 애플리케이션 계층(OSI 7계층) 에서 동작하는 LB로, HTTP·HTTPS·WebSocket 전용입니다.

ALB는 고정 IP가 아니라 고정 DNS Name을 제공해요. "왜 IP가 아니지?" 싶을 수 있는데, AWS가 내부적으로 ALB 노드를 자유롭게 늘리고 줄이기 때문이에요. IP는 변할 수 있지만 DNS는 변하지 않습니다. 그리고 LB 수준에서 HTTP → HTTPS 자동 리디렉션도 가능해요.

ALB의 구성 요소는 셋입니다.

• 리스너(Listener) — 어떤 포트에서 요청을 받을지 (예: 80, 443)
• 대상 그룹(Target Group) — 트래픽을 보낼 백엔드 묶음, Health Check도 이 단위로 동작
• 리스너 규칙(Rules) — 조건에 따라 어디로 보낼지

ALB의 진짜 강점은 라우팅 규칙이에요. 다섯 가지 조건으로 분기할 수 있습니다.

• 경로 기반 — example.com/users → 그룹 A, example.com/posts → 그룹 B
• 호스트 기반 — api.example.com → 그룹 A, web.example.com → 그룹 B
• 쿼리 문자열 기반 — ?platform=mobile → 모바일 서버
• HTTP 헤더 기반, HTTP 메서드 기반, 소스 IP 기반

회사 비유로 — 안내데스크에서 "복지 서류는 3층, 회계 서류는 5층, 모바일로 오신 분은 별도 창구로" 하고 분류해 주는 거예요. 마이크로서비스 환경에서 정말 강력합니다. CLB는 앱마다 LB를 따로 만들어야 하는데, ALB 하나로 여러 앱 트래픽을 처리할 수 있다는 점이 핵심이에요.

리스너 규칙의 작업(Action)은 세 가지입니다 — Forward(특정 대상 그룹으로 전달), Redirect(다른 URL이나 프로토콜로 전환, HTTP→HTTPS), Fixed Response(ALB가 직접 응답, 예: 404 커스텀 페이지). 우선순위는 숫자가 작을수록 먼저 적용(1이 가장 높음, 최대 50,000)이에요.

대상 그룹에 들어갈 수 있는 건 — EC2, ECS Task(컨테이너), Lambda 함수, 프라이빗 IP(온프레미스 포함). 여기서 시험 함정 — S3 버킷은 ALB 대상 그룹으로 못 씁니다. "ALB로 S3에 직접 라우팅" 같은 보기는 무조건 오답.

X-Forwarded-For — 클라이언트 IP를 어떻게 알아내요?

ALB 뒤에 EC2가 있을 때 정말 자주 나오는 질문이 — "EC2 입장에서 클라이언트의 진짜 IP를 어떻게 알지?"입니다. 잠깐, 이 부분이 헷갈릴 수 있어요.

ALB는 클라이언트와의 연결을 자기 선에서 끊고, 자기의 프라이빗 IP로 EC2와 새 연결을 맺어요. 그래서 EC2 입장에서는 보이는 IP가 ALB의 IP일 뿐, 클라이언트의 진짜 IP가 아닙니다.

해결책은 HTTP 헤더 X-Forwarded-For 예요. ALB가 친절하게도 클라이언트의 실제 IP를 이 헤더에 넣어서 보내 주거든요. 같은 식으로 포트는 X-Forwarded-Port, 프로토콜은 X-Forwarded-Proto에 들어옵니다.

> 시험에 "ALB 뒤에서 클라이언트 IP를 확인하려면?" 묻는 문제의 정답은 무조건 X-Forwarded-For 입니다.

NLB — Layer 4, 초저지연·고정 IP

Network Load Balancer(NLB)는 OSI 4계층(전송)에서 동작하고 TCP·UDP·TLS를 지원합니다. 초당 수백만 건을 처리할 수 있고, 초저지연이 특징이에요.

ALB와 비교하면 — ALB는 HTTP 헤더를 들여다보고 똑똑하게 라우팅하는 대신 좀 무겁고, NLB는 패킷을 빠르게 전달만 하는 대신 라우팅이 단순합니다(IP+포트 기반). 게임·금융처럼 밀리초가 중요한 곳에서는 NLB를 씁니다.

여기서 NLB의 가장 큰 차별점이 나와요.

리스너는 TCP, UDP, TCP_UDP, TLS 네 가지를 지원해요. 대상 그룹은 EC2 인스턴스 / 프라이빗 IP(온프레미스 하이브리드 LB) / ALB까지 받을 수 있습니다.

마지막 항목이 흥미로워요 — NLB → ALB 구조. NLB로 고정 IP를 확보하면서, 그 뒤에 ALB를 두고 HTTP 고급 라우팅을 같이 쓰는 패턴이에요. 시험에 "고정 IP가 필요한데 동시에 HTTP 경로 기반 라우팅도 써야 한다"는 시나리오가 나오면 답은 이 구조입니다.

함정 하나 — NLB의 IP 대상은 반드시 프라이빗 IP여야 해요. 퍼블릭 IP는 못 씁니다. Health Check는 TCP·HTTP·HTTPS 셋 다 지원하고요.

GWLB — Layer 3, 방화벽·IDS/IPS 가상 어플라이언스

Gateway Load Balancer(GWLB)는 좀 특이한 LB예요. 이건 사용 사례가 워낙 특수해서, 한 번 짚어 두면 시험에서 키워드 매칭만으로 풀립니다.

GWLB는 타사 가상 어플라이언스(Third-party Virtual Appliances) — 방화벽, 침입 탐지·방지(IDS/IPS), 심층 패킷 검사 — 를 배포·확장·관리할 때 씁니다. 모든 트래픽이 애플리케이션에 도달하기 전에 보안 검사를 거치게 강제하는 게 목적이에요. 회사 비유로 — 사옥에 들어오는 모든 손님이 보안 검색대를 한 번 거쳐야 사무실에 들어갈 수 있게 하는 식이에요.

기술적 특징이 시험에 그대로 출제됩니다.

• Layer 3(네트워크 계층)에서 IP 패킷 단위로 처리
• GENEVE 프로토콜, 포트 6081
• 트래픽의 출발지·목적지를 변경하지 않고 투명하게 작동
• 투명한 게이트웨이 + 로드 밸런서 두 역할 결합

흐름은 — 사용자 트래픽이 VPC로 들어오면 라우팅 테이블이 GWLB로 보내고, GWLB가 가상 어플라이언스에 분산해서 검사받게 한 뒤, 정상 트래픽만 최종 목적지로 전달합니다.

키워드 매칭 — Third-party appliance, Firewall, IDS/IPS, GENEVE, Layer 3가 보이면 답은 GWLB.

Connection Draining vs Deregistration Delay — 같은 기능, 다른 이름

여기서 시험 함정이 하나 있어요. 이름만 다른 같은 기능입니다.

LB에서 인스턴스가 등록 취소(Deregister)되거나 비정상 상태로 바뀔 때, 진행 중이던 요청을 갑자기 끊지 않고 유예 시간을 주는 기능이 있어요. 회사로 치면 — 직원이 퇴근하기 전에 "지금 응대 중인 손님은 끝까지 처리하고 가세요" 하는 식.

문제는 LB 종류에 따라 이름이 다르다는 거예요.

• CLB: Connection Draining (연결 드레이닝)
• ALB·NLB: Deregistration Delay (등록 취소 지연)

기능은 똑같습니다. 기본 300초(5분), 1초~3,600초(1시간) 사이로 설정 가능. 여기서 또 함정 — 0으로 설정하면 비활성화 되고, 진행 중인 연결이 즉시 종료돼요. 시험에 "Deregistration Delay = 0"이 나오면 답은 항상 "진행 중 연결 즉시 종료"입니다.

실무 팁 — 짧은 API 호출 위주의 서비스는 30초 정도로 낮춰서 인스턴스 교체를 빠르게 하고, 긴 파일 업로드가 많은 서비스는 높게 잡아야 사용자 작업이 끊기지 않아요.

Sticky Session — 같은 클라이언트는 같은 인스턴스로

Sticky Sessions(세션 선호도)는 클라이언트의 첫 요청을 처리한 EC2로 이후 모든 요청을 계속 보내는 기능입니다. 회사 비유로 — "이 손님은 김 대리님이 처음부터 응대했으니까, 다음 방문에도 김 대리님께 가세요" 하는 거예요.

왜 필요하냐면 — 로그인 정보·장바구니 같은 세션 데이터를 인스턴스 메모리에 보관하는 옛날 스타일 앱이라면, 다른 인스턴스로 가는 순간 로그인이 풀려 버리거든요. ALB·CLB·NLB 모두 지원합니다.

작동 방식은 단순해요. LB가 클라이언트에 만료일 있는 쿠키를 발급하고, 다음 요청부터 그 쿠키를 보고 같은 인스턴스로 라우팅합니다.

여기서 시험에 자주 나오는 단점 — 특정 인스턴스에 부하 집중 → 로드 불균형(Load Imbalance) 이 일어나요. 인기 사용자가 한 인스턴스에 몰리면 그쪽만 바빠지는 식이에요. 그래서 가능하면 세션 데이터를 ElastiCache 같은 외부 저장소로 빼는 게 좋습니다.

쿠키는 두 종류로 나뉩니다.

구분	Application-based	Duration-based
생성 주체	애플리케이션 (또는 ALB가 대신)	로드 밸런서
만료 기준	애플리케이션 정의	LB 지정 기간 (1초~7일)
ALB 쿠키 이름	AWSALBAPP (ALB 생성 시)	AWSALB
CLB 쿠키 이름	-	AWSELB
사용자 지정	가능	불가

여기서 시험 함정이 하나 — AWSALB, AWSALBAPP, AWSALBTG는 예약어라 직접 쓰면 안 됩니다. "쿠키 이름을 AWSALB로 직접 지정한다" 같은 보기는 오답이에요.

Cross-Zone Load Balancing — 기본값이 LB마다 달라요

여러 AZ에 인스턴스가 있을 때 LB 노드가 어떻게 분산하느냐를 결정하는 옵션이에요. 처음엔 좀 헷갈리는데 그림으로 풀면 단순합니다.

활성화(ON) — 모든 AZ의 모든 인스턴스에 균등 분산. AZ1에 2대, AZ2에 8대 있으면 총 10대가 각각 10%씩 받아요.

비활성화(OFF) — LB 노드가 자기 AZ 인스턴스에만 분산. AZ별로 50% 트래픽이 가니까 AZ1 각 인스턴스 25%, AZ2 각 인스턴스 6.25% → 불균형.

여기서 시험 함정 — LB 유형별 기본값과 비용이 다릅니다.

LB 유형	기본값	Cross-Zone 데이터 전송
ALB	활성화 (ON)	무료
NLB	비활성화 (OFF)	유료 (활성화 시 AZ 간 전송 비용)
GWLB	비활성화 (OFF)	유료
CLB	비활성화 (OFF)	무료

요점만 외우면 — ALB만 기본 활성화 + 무료, NLB·GWLB는 기본 비활성화이고 켜면 유료. 이 한 줄로 시험에서 80%는 풀려요.

SSL/TLS와 SNI — 다중 도메인 처리

ELB의 SSL/TLS 영역에서 시험에 가장 자주 나오는 게 SNI(Server Name Indication) 입니다. 이름이 어렵게 들리는데 풀어 보면 단순해요.

SNI가 해결하는 문제 — 하나의 LB에서 여러 도메인을 서비스할 때 어떤 SSL 인증서를 써야 할지. 예를 들어 한 ALB가 shop.example.com도 서비스하고 blog.example.com도 서비스한다면 SSL 인증서가 둘 다 필요한데, LB가 어떻게 둘 중 맞는 걸 골라 쓸까요?

SNI 작동 원리 — 클라이언트가 SSL 핸드셰이크할 때 "나 shop.example.com에 접속하려고요" 하고 호스트 이름을 명시적으로 알려 줘요. LB는 그 이름을 보고 알맞은 인증서로 응답합니다.

LB 유형	인증서 지원	SNI 지원	다중 도메인 방법
CLB	리스너당 1개	미지원	도메인마다 별도 CLB 필요
ALB	여러 개	지원 (HTTPS 리스너)	하나의 ALB에 여러 인증서
NLB	여러 개	지원 (TLS 리스너)	하나의 NLB에 여러 인증서

CloudFront도 SNI를 지원해요. 시험 함정 — CLB는 SNI 미지원이라 다중 도메인 시 도메인마다 별도 CLB를 만들어야 합니다. "하나의 CLB에 여러 인증서를 붙인다" 같은 보기는 오답.

리스너 명칭 차이도 시험에 자주 나와요 — ALB는 HTTPS 리스너, NLB는 TLS 리스너. 인증서 관리는 AWS Certificate Manager(ACM) 가 Best Practice입니다.

SSL Termination이 뭐죠?

추가로 짚어 둘 게 — SSL Termination(SSL 종료) 입니다. 클라이언트 → LB까지는 HTTPS(암호화)로 오고, LB에서 복호화해서 LB → EC2(VPC 내부)는 HTTP(비암호화)로 보내는 패턴이에요. VPC 내부는 사설 네트워크라 안전하다고 간주하고, EC2의 SSL 부담을 LB가 대신 져 주는 거죠.

세 가지 LB 한 번에 비교 — 시험 직전 표

항목	ALB (Application)	NLB (Network)	GWLB (Gateway)
OSI 계층	Layer 7	Layer 4	Layer 3
프로토콜	HTTP, HTTPS, WebSocket	TCP, UDP, TLS	IP (GENEVE / 6081)
성능	일반	초고성능, 초저지연	어플라이언스용
고정 IP	미지원 (DNS Name)	지원 (AZ당 1개, EIP 가능)	-
SNI	지원	지원	-
라우팅 방식	경로/호스트/헤더/쿼리	IP/포트	VPC 라우팅 테이블
대상 그룹	EC2, ECS, Lambda, 프라이빗 IP	EC2, 프라이빗 IP, ALB	EC2, 프라이빗 IP
Cross-Zone 기본값	활성화 (무료)	비활성화 (유료)	비활성화 (유료)
사용 사례	웹 앱, MSA, 컨테이너	게임·금융·고정 IP	방화벽·IDS/IPS

이 표 한 장만 머리에 있으면 ELB 시나리오 문제는 거의 다 풀려요.

Auto Scaling Group — 인스턴스를 알아서 늘리고 줄이기

이제 ASG로 넘어갑니다. 한 줄로 풀면 — 부하 변화에 따라 EC2 인스턴스 수를 자동으로 조절하는 서비스예요. 회사 비유로 — 손님이 늘면 알바를 더 부르고, 한가해지면 알바를 보내는 매니저 역할이에요. 옵션과 동작 원리를 더 자세히 보고 싶다면 Auto Scaling 사용자 가이드 가 정답지에 가깝습니다.

좋은 소식 하나 — ASG 자체는 무료입니다. 생성된 EC2·EBS 같은 기본 리소스만 비용이 발생해요.

용량 설정은 셋으로 나뉩니다.

• Minimum Capacity — 항상 실행되어야 하는 최소 인스턴스 수
• Desired Capacity — 평상시 ASG가 유지하려는 목표 수
• Maximum Capacity — 부하와 무관하게 절대 넘지 않는 최대

비유하자면 — 식당에 "최소 직원 2명은 항상 있어야 하고, 평소엔 5명 정도 유지하지만, 아무리 손님이 많아도 10명은 넘기지 마세요" 하는 식이에요.

새 인스턴스를 만들 때 사용하는 '설명서'가 시작 템플릿(Launch Template) 입니다. 옛날에 쓰던 시작 구성(Launch Configuration)을 대체한 거예요. 시작 템플릿에 들어가는 내용은 — AMI ID, 인스턴스 유형, User Data, EBS 볼륨, 보안 그룹, SSH 키 페어.

여기서 시험 함정 — 서브넷 정보는 시작 템플릿에 안 들어갑니다. "어느 AZ·서브넷에 띄울지"는 ASG 설정 단계에서 따로 지정해요. 이걸 헷갈리는 보기가 시험에 자주 나옵니다.

ELB와 묶을 때 핵심 — ASG에 ALB 대상 그룹을 연결하고, ELB 상태 검사를 활성화해 두면 자가 치유(Self-Healing) 패턴이 완성돼요. ELB가 비정상 인스턴스를 감지하면 ASG가 자동으로 종료하고 새 인스턴스를 띄워서 대상 그룹에 등록합니다. 사람 손이 안 가는 자동 복구.

ASG 스케일링 정책 5종 — 시험 핵심

ASG에서 가장 시험에 많이 나오는 게 스케일링 정책입니다. 다섯 종류가 있어요. 한 번 천천히 풀어 갑니다.

정책	트리거	키워드	사용 사례
Scheduled Scaling	특정 시간/일정	"알려진 이벤트", "특정 시간"	매주 금요일 저녁 트래픽 급증
Predictive Scaling	ML 기반 예측	"머신 러닝", "과거 데이터"	반복적 주기 패턴
Target Tracking	지표 목표값 이탈	"CPU 40% 유지", "가장 간단"	평균 사용률 유지 목표
Simple Scaling	CloudWatch 경보 1개	"단순 단계"	기본 경보 기반
Step Scaling	경보 + 단계	"70%면 +1, 90%면 +10"	트래픽 급증 정도별 대응

하나씩 비유로 풀면 —

• Scheduled Scaling 은 "매주 금요일 저녁 7시에 알바 5명 더 부르세요" 하고 미리 정해 두는 거예요. 트래픽 패턴을 정확히 알 때 씁니다.
• Predictive Scaling 은 "지난 3개월 패턴을 보니까 다음 주 화요일 오전에 손님이 몰릴 것 같네요, 미리 준비할게요" 하는 ML 기반 예측. 반복적인데 시점이 정확히 떨어지지 않을 때 유용해요.
• Target Tracking 은 "CPU 평균 40%만 유지해 주세요" 하고 목표값을 던지면 ASG가 알아서 조정. 가장 간단하고 실무에서 가장 자주 씁니다.
• Simple Scaling 은 "CPU 80% 넘으면 한 대 추가" 같은 단순 규칙. 작업이 끝날 때까지 다음 조정 안 해요.
• Step Scaling 은 "70% 넘으면 +1, 90% 넘으면 +10" 식으로 단계별 다른 대응. 트래픽 급증 정도에 따라 유동적이에요.

주요 스케일링 지표는 다음 넷 — CPU 사용률(가장 일반적), RequestCountPerTarget(ALB 연결 시 인스턴스당 요청 수), 평균 네트워크 I/O, 사용자 지정 지표(CloudWatch에 직접 푸시).

여기서 시험 단골 — Target Tracking의 내부 동작입니다. 정책을 만들면 AWS가 스케일 아웃·인을 위한 CloudWatch 경보를 자동으로 생성해요. 별도로 만들 필요가 없어요. "Target Tracking 정책을 만들 때 CloudWatch 경보를 따로 생성해야 한다" 같은 보기가 나오면 무조건 오답.

Cooldown / Lifecycle Hooks / Instance Refresh

ASG의 추가 기능 셋을 한 번에 짚고 갑니다.

Cooldown Period(휴지기) 는 스케일링 작업 완료 후 새로운 지표가 안정화될 때까지 추가 스케일링을 안 하는 대기 시간이에요. 기본 300초(5분). 왜 필요하냐면 — 인스턴스가 막 떠서 부팅 중일 때 CPU가 높게 측정될 수 있는데, 그 순간 또 스케일 아웃하면 무한 폭주가 일어나거든요.

Best Practice는 미리 구성된 Golden AMI(부팅 즉시 동작 가능한 AMI)를 써서 부팅 시간을 줄이고, 그만큼 휴지기를 짧게 잡아 ASG가 빠르게 반응하게 하는 거예요. 시험에 "휴지기를 줄이려면?" 묻는 문제의 정답이 보통 Golden AMI 사용입니다.

Lifecycle Hooks(수명 주기 후크) 는 인스턴스 시작·종료 과정에서 사용자 지정 작업을 끼워 넣을 수 있게 일시 중지하는 기능이에요.

• 시작 시 Pending 상태 — 소프트웨어 설치, 로그 설정 같은 초기화 작업
• 종료 시 Terminating 상태 — 로그 저장, 연결 종료, 데이터 백업 같은 정리 작업

회사 비유로 — 신입이 출근하면 "장비 세팅하고 교육 받고 그다음에 자리 앉으세요", 퇴사하면 "인수인계 마치고 자료 백업하고 그다음에 나가세요" 하는 식이에요.

Instance Refresh(인스턴스 갱신) 는 시작 템플릿을 업데이트한 뒤 기존 인스턴스를 새 템플릿 기반 인스턴스로 점진적으로 교체하는 기능입니다. 한꺼번에 다 바꾸면 서비스가 죽으니까, 조금씩 굴려 가면서 바꾸는 거예요.

핵심 설정이 최소 정상 비율(Minimum Healthy Percentage) — 60%로 잡으면 갱신 중에도 60%는 유지하고 40%씩 교체합니다. AMI 업데이트나 User Data 변경 같은 시작 템플릿 변경에 자주 써요.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 ELB·ASG 영역의 핵심이에요. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요. 시험 전날 이 부분만 한 번 더 읽으면 거의 다 떠오릅니다.

• HTTP/HTTPS 고급 라우팅·MSA·컨테이너 → ALB
• TCP/UDP·초저지연·초당 수백만 요청·고정 IP → NLB
• 타사 방화벽·IDS/IPS 가상 어플라이언스 → GWLB
• 고정 IP + HTTP 라우팅 동시 필요 → NLB → ALB 구조
• ALB 뒤 EC2에서 클라이언트 IP 확인 → X-Forwarded-For (포트는 X-Forwarded-Port, 프로토콜은 X-Forwarded-Proto)
• 하나의 ALB/NLB에서 여러 도메인 SSL → SNI (CLB는 미지원)
• Deregistration Delay = 0 → 진행 중 연결 즉시 종료
• ALB Cross-Zone LB 기본 활성화 + 무료, NLB·GWLB 기본 비활성화 + 활성화 시 유료
• NLB에 Elastic IP 할당 가능 (ALB 불가)
• ALB는 HTTPS 리스너, NLB는 TLS 리스너
• ELB SSL 인증서 관리 Best Practice → ACM
• 보안 그룹 참조 — EC2 인바운드 소스를 ALB SG로 설정 → 직접 접근 차단
• ASG + ELB Health Check 활성화 → 자가 치유 (Self-Healing)
• Target Tracking → CloudWatch 경보 자동 생성 (별도로 만들 필요 X)
• Predictive Scaling → ML 기반, 반복 패턴
• Sticky Session 단점 → 로드 불균형 (특정 인스턴스 부하 집중)
• ALB 대상 그룹에 S3 버킷 불가, NLB IP 대상은 프라이빗 IP만
• GWLB → GENEVE 프로토콜 · 포트 6081 · Layer 3
• Connection Draining(CLB) ↔ Deregistration Delay(ALB·NLB) — 같은 기능, 이름만 다름
• 시작 템플릿에는 서브넷 정보 X — ASG 설정 단계에서 서브넷 지정
• 휴지기 단축 비결 → Golden AMI 사용으로 부팅 시간 줄이기
• 사용자 지정 쿠키 이름에 AWSALB, AWSALBAPP, AWSALBTG 사용 금지 (예약어)

여기까지가 SAA-C03 고가용성·스케일링 영역의 전부예요. ELB 셋(ALB·NLB·GWLB)의 차이와 ASG 정책 다섯이 머리에 박혀 있으면 시나리오 문제 대부분이 키워드 매칭으로 풀립니다. 표를 직접 손으로 다시 그려 보면서 차이를 머리에 새겨 두면, 다음 단원부터 훨씬 가볍게 갈 수 있어요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — IAM
• 2편 — EC2 / Storage
• 3편 — ELB · ASG (현재 글)
• 4편 — S3 (스토리지)
• 5편 — Databases
• 6편 — Networking
• 7편 — Messaging
• 8편 — Containers · Serverless
• 9편 — Monitoring
• 10편 — Analytics · ML
• 11편 — Security
• 12편 — DR · Migration
• 13편 — Architectures
• 14편 — Exam Prep (완)