Amazon ANS-C01: 로드 밸런싱 및 트래픽 관리 — 학습 가이드

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Advanced Networking Specialty ANS-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

핵심 개념

AWS의 로드 밸런싱은 두 가지 기본 계층인 L4(전송)와 L7(애플리케이션)에서 작동합니다. Network Load Balancer(NLB)는 L4(TCP/UDP/TLS) 분산을 제공하며 극도의 성능에 최적화되어 있습니다. 클라이언트 소스 IP를 보존하고 매우 낮은 지연 시간과 연결 변동(churn)으로 수백만 개의 동시 연결을 지원합니다. Application Load Balancer(ALB)는 L7(HTTP/HTTPS/WebSocket 및 HTTP/2/gRPC)에서 작동하며, 호스트 및 경로 기반 라우팅, 헤더 검사, HTTP 기반 상태 확인, 쿠키 고정성을 제공하고, ACM의 인증서로 구성 시 TLS 종료를 수행합니다. Gateway Load Balancer(GWLB)는 타사 가상 어플라이언스(방화벽, IDS/IPS)를 확장하기 위한 특수 목적의 로드 밸런서로, GENEVE 캡슐화와 Gateway Load Balancer 엔드포인트(GWLBe)를 사용하여 수동 어플라이언스 확장 없이 인라인 트래픽 검사를 가능하게 합니다.

리스너와 리스너 규칙은 프로토콜/포트를 대상 그룹에 매핑하는 L4/L7 진입점입니다. ALB의 리스너는 호스트, 경로, 헤더, 소스 IP CIDR을 검사하고 다른 대상 그룹으로 전달하는 복잡한 규칙을 가질 수 있습니다. 또한 ALB는 TLS를 오프로드(종료)하고 X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port 헤더를 대상에 제공할 수 있습니다. NLB 리스너는 일반적으로 페이로드를 파싱하지 않고 트래픽을 대상 그룹으로 전달하는 TCP/UDP/TLS 리스너입니다(NLB에서 TLS 종료를 활성화하지 않는 한). TCP 패스스루를 사용하면 종단 간 TLS가 보존되므로 백엔드는 상호 TLS(mTLS)를 위해 인증서를 제시하고 검증해야 합니다. 대상 그룹은 로드 밸런서 리스너와 엔드포인트(인스턴스, IP 또는 Lambda) 집합 간의 바인딩이며, 상태 확인 프로토콜/포트/경로, 등록 취소 지연(연결 드레이닝), 고정성 속성과 같은 속성을 노출합니다.

주요 서비스 및 구성

트래픽 특성과 보안 요구 사항에 맞는 올바른 밸런서를 선택하십시오. 호스트/경로 기반 라우팅, 애플리케이션 인식 라우팅을 사용하는 WebSockets 또는 HTTP/2/gRPC와 같은 HTTP/HTTPS 기능, 쿠키 기반 고정성이 필요할 때 ALB를 사용하십시오.

undefined

또는

undefined

를 통해 ALB 리스너를 구성하고, ACM의 인증서를 연결하고,

undefined

를 사용하여 조건(Field=path-pattern, host-header, http-header)과 함께 리스너 규칙을 설정하십시오. 로드 밸런서 생성 쿠키를 사용하려면

undefined

에서

undefined

및

undefined

을 설정하여 ALB 대상 그룹에 고정성을 활성화하십시오.

처리량이 높고 오래 지속되는 TCP 연결 및 백엔드에서 클라이언트 소스 IP 보존이 필요한 경우 NLB를 사용하십시오.

undefined

로 NLB를 생성하고

undefined

로 TCP 리스너를 추가하십시오. 패스스루 TLS 및 mTLS의 경우, TLS가 백엔드에서 종료되도록 NLB 리스너를 TCP로 구성하십시오. Kubernetes의 파드 IP를 등록할 때는 대상 그룹을 target-type ip로 설정하십시오.

undefined

를 사용하여

undefined

를 설정하여 연결 드레이닝을 허용하십시오. NLB의 경우 적절한 경우 소스 IP 선호도(대상 그룹 고정성)를 활성화할 수도 있습니다.

Gateway Load Balancer는

undefined

로 구성되며 어플라이언스 인스턴스(또는 오토 스케일링 그룹의 스케일 세트)의 대상 그룹에 의해 지원됩니다. 그리고 소비자 VPC의 Gateway Load Balancer 엔드포인트를 사용하여 서비스 VPC 어플라이언스로 트래픽을 유도합니다. 투명한 검사가 필요하고 트래픽에 따라 어플라이언스를 자동으로 확장하고 싶을 때 이 패턴을 사용하십시오. 포트 6081(GENEVE 캡슐화)에 리스너를 생성하고 GWLB 대상 그룹에 어플라이언스 ENI를 등록하십시오.

프로그래밍 방식으로 제어해야 하는 운영 설정에는 교차 영역 로드 밸런싱, 등록 취소 지연(연결 드레이닝), 상태 확인 튜닝이 포함됩니다. 교차 영역 로드 밸런싱을 위해 로드 밸런서에 속성을 설정하여(

undefined

) AZ별 용량에 치우치지 않고 여러 AZ에 걸쳐 트래픽이 분산되도록 하십시오. 오토 스케일링 이벤트 중 플래핑(flapping)을 방지하기 위해 대상 그룹에 상태 확인 간격, 시간 초과, 정상/비정상 임계값을 설정하십시오.

설계 패턴 및 트레이드오프

트래픽을 계속 암호화해야 하고 백엔드에 클라이언트 인증서를 제시해야 하는 종단 간 TLS 및 상호 TLS(mTLS)의 경우, TCP 리스너를 사용하는 NLB를 통한 L4 패스스루를 선호합니다. 이렇게 하면 TLS 세션이 그대로 유지되어 백엔드가 클라이언트 X.509 인증서를 검증할 수 있습니다. 대상 그룹이 IP 대상을 사용하도록 구성하여 Kubernetes 파드 IP를 직접 등록하고 AWS Load Balancer Controller가 대상 수명 주기를 관리하도록 할 수 있습니다. 단점은 로드 밸런서 계층에서 호스트/경로 기반 라우팅, Web Application Firewall 통합, 네이티브 HTTP 쿠키 고정성과 같은 ALB L7 기능을 사용할 수 없다는 것입니다.

콘텐츠 기반 라우팅, TLS 종료, 고급 HTTP 기능이 필요한 경우 ALB를 사용하고 ALB에서 TLS를 종료합니다(ACM 관리형 인증서 사용). 로깅 및 WAF 규칙을 위해 클라이언트 IP를 유지하려면 ALB가 채우는 X-Forwarded-For 헤더를 읽거나 원본 클라이언트 IP를 헤더에 주입하는 계층을 사용합니다. 백엔드 OS/네트워크 스택이 소켓 수준에서 클라이언트 IP를 확인해야 하는 경우 NLB를 사용하거나 Proxy Protocol을 활성화하여 원본 IP를 전달합니다. 단, 대상 그룹에서 Proxy Protocol을 활성화해야 하며 애플리케이션 또는 프록시(예: Envoy)가 이를 파싱해야 한다는 점에 유의해야 합니다.

오토스케일링 환경에서 고정 세션을 처리하려면 신중한 고려가 필요합니다. ALB 쿠키 고정성은 일정 기간 동안 클라이언트를 특정 대상에 바인딩할 수 있으며, 세션 트래픽이 많을 경우 파드 간의 균형 잡힌 스케일링을 저해할 수 있습니다. 대안 패턴으로는 단기 고정성을 ElastiCache(Redis) 또는 DynamoDB로의 세션 상태 외부화와 결합하거나, 사이드카 프록시(Envoy)를 사용하여 일관된 해싱으로 세션 어피니티를 처리하는 방법이 있습니다. 연결 드레이닝(등록 취소 지연)은 정상 종료에 매우 중요합니다. 파드 종료 중 갑작스러운 종료와 클라이언트 오류를 방지하려면 deregistration_delay.timeout_seconds를 가장 긴 RPC/HTTP 요청보다 긴 시간으로 설정하세요. Kubernetes preStop 후크를 구성하여 파드 수명 주기를 등록 취소와 조율합니다.

GWLB는 여러 VPC에 걸쳐 확장 가능한 인라인 검사가 필요하고 중앙 집중식 보안 제어를 원할 때 적합한 패턴입니다. 필요에 따라 GWLB를 Transit Gateway 또는 VPC 피어링 아키텍처와 결합하세요. 어플라이언스 관리의 비용과 운영 복잡성은 AWS Network Firewall과 같은 관리형 서비스를 사용하는 것과 비교했을 때의 트레이드오프입니다.

일반적인 함정과 결정 기준

클라이언트 인증이나 원본 소스 IP에 대한 다운스트림의 요구사항을 고려하지 않고 ALB에서 TLS를 종료하는 것은 흔한 실수입니다. 백엔드가 TCP 계층에서 클라이언트 인증서나 실제 소스 IP를 (로깅 또는 권한 부여를 위해) 필요로 하는 경우, NLB 패스스루를 통해 백엔드에서 TLS를 종료하거나 Proxy Protocol을 사용하고 애플리케이션이 이를 파싱하도록 해야 합니다. 또 다른 흔한 함정은 Horizontal Pod Autoscaler를 사용하면서 외부 세션 스토리지 없이 고정 세션을 활성화하는 것입니다. 파드가 스케일 아웃 또는 인될 때 고정 선호도(sticky affinity)로 인해 핫스팟이 발생하고 용량이 낭비될 수 있습니다. 상태 비저장(stateless) 백엔드를 사용하거나 세션 상태를 외부화하는 것이 좋습니다.

잘못 구성된 상태 확인 및 등록 취소 지연으로 인해 스케일링 중 요청이 유실되는 운영상의 오류도 발생합니다. 항상 애플리케이션 워밍업을 반영하도록 상태 확인 경로와 임계값을 설정하고, deregistration_delay.timeout_seconds를 사용하여 오래 지속되는 연결이 정상적으로 드레이닝(소진)되도록 하십시오. 교차 영역 로드 밸런싱은 의도적으로 설정해야 합니다. 이를 활성화하면 테일 레이턴시(꼬리 지연 시간)가 줄고 부하가 균등해지지만, AZ 간 데이터 전송 비용이 증가할 수 있습니다. AZ 용량 및 트래픽 패턴에 따라 평가해야 합니다. 마지막으로, GWLB는 캡슐화(GENEVE) 및 어플라이언스 관리 오버헤드를 발생시킵니다. AWS API(CreateTargetGroup/RegisterTargets)를 사용하여 어플라이언스 등록을 자동화하고, CloudWatch 지표로 계측하여 오토스케일링 정책을 구동하십시오.

실제 문제: 사용 사례 시나리오

회사: Acme Telemetry. 과제: Amazon EKS 클러스터에 배포된 gRPC 서비스(TCP 포트 443에서 TLS를 통한 gRPC)에 대해 종단 간 암호화를 제공하고, 수천 개의 동시 장기 연결을 지원하며, Kubernetes Cluster Autoscaler 및 HPA를 사용하고, 클라이언트 인증서가 백엔드에서 검증되도록(즉, 트래픽이 중간 로드 밸런서에 의해 복호화되어서는 안 됨) 상호 TLS(mTLS)를 요구합니다.

사용 사례 구현 접근 방식: TCP 포트 443에 TCP 리스너를 가진 Network Load Balancer와 파드 IP를 가리키는 ‘ip’ 유형의 대상 그룹을 프로비저닝합니다. aws elbv2 create-load-balancer --name acme-nlb --type network --subnets <subnet-ids>로 NLB를 생성하고, aws elbv2 create-target-group --name tg-grpc --protocol TCP --port 443 --target-type ip --vpc-id <vpc-id>로 대상 그룹을 생성합니다. Kubernetes용 AWS Load Balancer Controller 어노테이션(service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip")을 통해 컨트롤러가 파드 IP를 자동으로 등록하도록 대상을 등록하고, aws elbv2 create-listener --load-balancer-arn <arn> --protocol TCP --port 443 --default-actions Type=forward,TargetGroupArn=<tg-arn>로 리스너를 생성합니다. aws elbv2 modify-target-group-attributes를 사용하여 대상 그룹 속성 deregistration_delay.timeout_seconds를 적절한 값(예: 300)으로 설정하여 정상적인 드레이닝을 활성화합니다.
백엔드 TLS 및 mTLS 구성: 파드 계층에서 TLS를 종료하고 상호 TLS를 수행합니다. Envoy 사이드카를 배포하거나 gRPC 서버가 직접 TLS를 수락하도록 하고, 서버 인증서와 CA 번들을 Kubernetes Secrets에 저장하여 파드에 마운트합니다. 백엔드가 CA에 대해 클라이언트 인증서를 검증하도록 구성하고, 로드 밸런서에서 TLS가 종료되는 것을 피하기 위해 상태 확인에 TCP를 사용하도록 구성합니다. 파드가 종료되기 전에 드레이닝을 완료할 수 있도록 하는 preStop 훅을 구현하여 HPA 및 Cluster Autoscaler 라이프사이클 훅이 대상 그룹 등록 취소와 조율되도록 합니다.
확장성 및 운영 제어: 필요한 경우 aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn> --attributes Key=load_balancing.cross_zone.enabled,Value=true를 사용하여 NLB에서 교차 영역 로드 밸런싱을 활성화하여 AZ 전반에 걸쳐 연결을 고르게 분산합니다. CloudWatch 지표(NLB의 경우 NetworkPackets, ActiveFlowCount)로 동시 연결 및 플로우 속도를 모니터링하고, 어플라이언스(사이드카를 사용하는 경우)와 워커 노드에 대한 오토스케일링 정책을 설정합니다. 연결 드레이닝을 위해 ModifyTargetGroupAttributes를 사용하고, 플래핑(불안정한 상태 변화) 없이 더 빠른 장애 감지를 위해 상태 확인 간격을 조정합니다. 마지막으로, AWS Secrets Manager와 Kubernetes cert-manager 통합을 사용하여 인증서 교체를 자동화합니다.

AWS의 논리적 근거: TCP 모드의 NLB는 TLS 세션을 종단 간에 보존하므로 백엔드가 mTLS 검증을 수행할 수 있습니다. NLB의 L4 아키텍처는 수백만 개의 동시 플로우와 장기 연결을 위해 구축되었으며, ‘ip’ 대상 유형을 사용하면 AWS Load Balancer Controller가 파드 IP를 직접 등록할 수 있어 HPA/Cluster Autoscaler가 투명하게 확장할 수 있습니다. 연결 드레이닝(deregistration_delay)과 상태 확인은 파드 종료 중 요청 손실을 방지하고, 교차 영역 로드 밸런싱은 성능을 위해 AZ 간 전송 비용을 감수하는 대신 AZ 전반에 걸쳐 균등한 분배를 보장합니다.

← DNS 및 Route 53 · 모든 도메인 · 네트워크 보안 및 규정 준수 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →