AWS Network Load Balancer, 가용 영역 제거 기능 지원

2025년 2월 13일부로 AWS NLB의 가용 영역 제거 기능이 출시되었다는 소식 전해드리며, 이번 글에서는 해당 기능이 출시된 이유를 고민해보고, 직접 간단히 테스트해본 경험을 공유하려고 합니다.

1. 왜 이런 기능이 출시 되었을까요?

이전에는 네트워크 로드 밸런서(NLB)에 새로운 가용 영역(AZ)을 추가할 수는 있었지만, 한 번 추가한 AZ를 제거하는 것은 불가능했습니다. 회사가 인프라를 정리하거나 변경해야 할 때, 필요 없는 AZ를 없앨 방법이 없어서 불편함이 많았죠.

하지만 이제는 기존 NLB에서 불필요한 AZ를 손쉽게 제거할 수 있어 운영이 훨씬 유연해졌습니다.

이 기능이 필요한 이유는 여러가지입니다. 예를 들어, 기업이 합병이나 매각을 하면 기존 시스템을 조정해야 하는데, 특정 AZ를 유지할 필요가 없을 수도 있습니다. 또 어떤 기업은 법적인 이유로 특정 지역에만 데이터를 저장해야 하는데, 이제는 NLB 설정을 변경해 쉽게 이를 준수할 수 있습니다.

또 다른 이유는 AWS의 서버 자원이 지역마다 다를 수 있기 때문입니다. 가끔 특정 AZ에서 서버 공간이 부족하면 새로운 인스턴스를 만들기 어려울 수 있는데, 이럴 때 해당 AZ를 제거하고 더 적절한 곳으로 옮길 수 있는 옵션이 생긴 것입니다.

2. 이전에는 왜 없었을까요?

과거에는 AWS에서 네트워크 로드 밸런서(NLB)를 설정하면, 프로비저닝된 서브넷에 자동으로 네트워크 인터페이스(ENI)가 할당되었습니다. 하지만 한 번 생성된 ENI를 제거하면 기존에 연결된 트래픽이 끊길 위험이 있었기 때문에, AZ를 추가하는 것은 가능했지만 제거하는 것은 지원되지 않았습니다.

또한, NLB는 특정 AZ에서 고정된 IP 주소를 사용했기 때문에, 만약 AZ를 제거하면 해당 IP 주소가 사라지고 일부 요청이 실패할 가능성이 있었습니다. 특히, 고객이 특정 IP 주소를 직접 사용하고 있는 경우, 갑작스럽게 IP가 변경되면 장애가 발생할 위험이 있었습니다. 이러한 이유로 AWS는 NLB의 IP 주소를 유지하는 방법을 마련하기 전까지 AZ 제거 기능을 제공하지 않았던 것으로 판단됩니다.

3. 그렇다면 이제는 어떻게 가능해졌을까요?

블로그 글에 따르면, 이번에 AWS는 SetSubnets API를 추가하면서 ENI와 서브넷을 보다 유연하게 관리할 수 있도록 개선했다고 합니다. 이 API를 통해 기존 NLB를 그대로 유지하면서도 특정 AZ를 제거할 수 있는 기능이 제공되는 것이지요. 기존에는 ENI가 특정 AZ에 영구적으로 고정되었지만, 이제는 필요하면 제거 할 수 있도록 기능 개선을 한 것이라고 이해하면 될 것 같습니다. 하기 표도 참고해주세요!

이전(❌ 불가능)	지금(✅ 가능)
NLB가 특정 AZ에서 ENI를 할당받으면, 그 AZ를 제거할 방법이 없었음.	ENI를 유연하게 관리할 수 있게 되면서, 특정 AZ를 제거하는 게 가능해짐.
특정 서브넷을 제거하려면, AZ 전체를 삭제해야 했음.	SetSubnets 기능으로 특정 서브넷만 제거 가능.
AZ를 변경하려면 새로운 NLB를 만들어야 했음.	기존 NLB를 유지하면서 특정 AZ만 제거 가능.

4. 테스트를 해봅시다!

테스트는 비교적 간단합니다.
1. 우선 NLB를 프로비저닝 하고, 이 때 두 가용 영역을 선택합니다.

NLB 뒷 단에 웹서버 인스턴스 두 대를 타겟으로 띄워둡니다.

☑️ 여기서 잠시! 하단 옵션은 NLB의 특징 중 하나인 [ 교차 영역 로드 밸런싱 ] 옵션인데요,
NLB AZ를 제거할 때 Best Practice는 해당 옵션을 비활성화한 상태로 두는 것이라고 합니다.
해당 옵션을 살펴보고 가겠습니다.

교차 영역 로드 밸런싱을 비활성화하면 NLB는 각 AZ의 리스너 ENI를 통해 그 AZ에 있는 Target 으로만 요청을 전달합니다. 즉, 특정 AZ의 IP로 접근하면 그 IP가 속한 AZ에 있는 Target만 사용됩니다.

위의 이미지에서처럼, 두 개의 퍼블릭 IP를 가지고 있는 NLB에 각각 요청을 보내면, 각 퍼블릭 IP가 속한 AZ에 위치한 서버만 응답을 하게 됩니다. 이는 교차 영역 로드 밸런싱이 비활성화되어 있기 때문인데요, 이 설정에서는 요청이 들어온 퍼블릭 IP가 소속된 AZ의 Target만 요청을 처리하게 됩니다.

예를 들어, 3.34.74.92 IP로 요청을 보내면 항상 web 1 서버(AZ 1a)에서 응답하며,
13.124.183.48 IP로 요청을 보내면 항상 web 2 서버(AZ 1c)에서 응답하는 것을 확인할 수 있습니다.

즉, 퍼블릭 IP마다 고정된 AZ와 Target이 묶여 있고, 트래픽이 다른 AZ로 전달되지 않는다는 것을 알 수 있습니다.

교차 영역 로드 밸런싱을 활성화하면, NLB는 어느 AZ의 IP로 들어오더라도 모든 AZ의 Target 으로 요청을 분산시킵니다. 즉, A AZ의 퍼블릭 IP로 접근해도 B AZ의 Target으로 트래픽이 전달될 수 있습니다.

위의 이미지처럼 3.34.74.92라는 특정 퍼블릭 IP로만 요청을 보냈음에도, 응답은 web 1과 web 2가 번갈아 나타나는 것을 볼 수 있습니다. 이는 요청이 IP가 속한 AZ를 넘어서 다른 AZ의 서버로도 분산 처리되고 있다는 뜻입니다. 즉, 퍼블릭 IP에 상관없이 모든 Target이 요청을 받을 수 있게 되는 것이죠.

테스트는 하기와 같이 진행했습니다.

교차 영역 로드밸런싱을 활성화 / 비활성화 한 상태에서 AZ를 삭제 및 추가하는 테스트를 진행합니다.
NLB의 퍼블릭 DNS를 대상으로 dig 요청을 반복 실행하여 AZ 삭제 및 추가 시 ENI 상태를 확인합니다.
NLB의 퍼블릭 DNS를 대상으로 curl 요청을 반복 실행하여 어디로 트래픽을 전달하는지 확인합니다.

1️⃣ 교차 영역 로드 밸런싱 ON 상태에서 AZ 삭제 및 추가

테스트 조건	테스트 결과
AZ 삭제 시	ENI가 삭제된 후에야 한쪽 서버로만 트래픽이 집중됨
AZ 추가 시	LB ENI가 할당되기 전에도 트래픽이 즉시 분산됨 (반영 속도 빠름)

2️⃣ 교차 영역 로드 밸런싱 OFF 상태에서 AZ 삭제 및 추가

테스트 조건	테스트 결과
AZ 삭제	콘솔에서 AZ 삭제하는 즉시 트래픽이 한쪽으로 이동함
AZ 추가	ENI가 할당된 후에도 두 리전으로 트래픽이 반영되기까지 지연이 있음

교차 영역 로드 밸런싱을 비활성화하는 것이 Best Practice로 권장되는 이유를 고민하며 테스트를 진행한 결과, 다음과 같은 결론을 도출할 수 있었습니다.

처음에는 AZ를 추가할 때 반영 속도가 빠른 ON 상태가 더 좋아보였습니다.
하지만 실제 운영 상황에서는 AZ를 제거할 때의 안정성이 더 중요하다는 점을 테스트를 통해 체감할 수 있었고, 특히 교차 영역 로드 밸런싱을 OFF한 상태에서는 AZ 삭제 시 트래픽이 즉시 정리되어 예측 가능한 형태로 동작한다는 점에서 보다 안전하고 안정적인 운용이 가능할 것이라는 결론에 도달했습니다.

개인적인 테스트였기에 내용이 조금 미흡할 수 있는 점 양해 부탁드리며,
앞으로도 AWS의 기능들을 테스트해보고 공유드리는 시간을 가지도록 하겠습니다!
긴 글 읽어주셔서 감사합니다.

참고 문서

[1] AWS Network Load Balancer, 가용 영역 제거 기능 지원

[2] Exploring new subnet management capabilities of Network Load Balancer