Development3 min read

ALB 대상이 unused일 때: Target.NotInUse의 리스너 규칙·가용 영역 점검

2026년 10월 30일3 min read작성자 Flature

Target.NotInUse가 표시되면 대상 그룹이 ALB 리스너 규칙에 연결되어 있는지, 대상의 가용 영역이 해당 ALB에서 활성화되어 있는지 확인해야 합니다. 두 조건을 순서대로 대조하는 예시와 수정 후 상태를 해석하는 기준을 설명합니다.

ALB 대상이 unused일 때: Target.NotInUse의 리스너 규칙·가용 영역 점검

ALB에 등록한 대상이 unused이고 이유 코드가 Target.NotInUse라면 두 가지를 확인해야 합니다. 해당 대상 그룹이 ALB의 리스너 규칙에서 트래픽 전달 대상으로 지정되어 있는지, 그리고 대상이 속한 가용 영역이 그 ALB에서 활성화되어 있는지 확인합니다.

unused 상태에서 이유 코드를 먼저 확인하는 이유

대상 등록만으로 헬스 체크의 전제 조건이 모두 갖춰지는 것은 아닙니다. ALB가 대상에 헬스 체크 요청을 보내려면 대상 등록 외에도 리스너 규칙의 대상 그룹 지정과 대상 가용 영역의 활성화가 필요합니다.

unused에는 여러 원인이 포함됩니다. 따라서 상태 이름만 보고 리스너 설정 문제로 단정하지 말고, 대상 상태의 이유 코드와 설명을 함께 확인해야 합니다.

  • Target.NotInUse: 대상 그룹의 트래픽 수신 설정 또는 ALB에서 활성화하지 않은 가용 영역을 확인합니다.
  • Target.NotRegistered: 해당 대상 그룹에 대상이 등록되어 있는지 확인합니다.
  • Target.InvalidState: 대상의 중지·종료 등 실행 상태를 확인합니다.

리스너 규칙 연결과 활성 가용 영역을 대조하는 순서

점검하려면 같은 AWS 계정과 리전에서 대상 상태, ALB의 리스너 규칙, 활성 가용 영역을 조회할 수 있어야 합니다. 대상 그룹 식별자와 대상 식별자, 대상이 속한 가용 영역을 먼저 준비합니다. 아래 절차는 가용 영역을 확인할 수 있는 인스턴스 대상을 기준으로 설명합니다.

  1. 대상 상태와 설명을 기록합니다. 문제 대상의 상태가 unused, 이유 코드가 Target.NotInUse인지 확인합니다. 설명이 대상 그룹 설정과 가용 영역 중 어느 쪽을 가리키는지도 기록합니다.
  2. 의도한 ALB의 리스너 규칙을 확인합니다. 규칙의 트래픽 전달 대상이 문제의 대상 그룹인지 식별자로 대조합니다. 대상 그룹이 존재하거나 대상이 등록되어 있다는 사실만으로 규칙 연결을 대신할 수는 없습니다.
  3. 대상의 가용 영역을 확인합니다. 대상 인스턴스가 속한 가용 영역을 ALB에서 활성화된 가용 영역 목록과 비교합니다. 대상이 위치한 영역이 목록에 포함되어 있어야 합니다.
  4. 누락된 조건을 수정하고 다시 조회합니다. 서비스 설계에 맞게 리스너 규칙의 전달 대상을 연결하거나 필요한 가용 영역을 활성화합니다. 한 조건을 수정했더라도 나머지 조건까지 충족했는지 확인합니다.

예시: 규칙을 연결했는데도 unused가 남는 경우

다음은 실제 실행 결과가 아닌 설명용 구성입니다. 인스턴스 대상 app-1은 대상 그룹 tg-api에 등록되어 있고, 상태는 unused, 이유 코드는 Target.NotInUse라고 가정합니다.

확인 항목 예시 구성 해석
대상이 등록된 그룹 tg-api 대상 등록은 되어 있음
ALB 리스너 규칙의 전달 대상 tg-web만 지정 tg-api를 사용하는 규칙이 없음
app-1의 가용 영역 ap-northeast-2c ALB의 활성 영역과 대조할 값
ALB의 활성 가용 영역 ap-northeast-2a, ap-northeast-2b app-1의 영역이 포함되지 않음

이 구성에는 두 조건이 모두 빠져 있습니다. API 요청을 tg-api로 전달하도록 리스너 규칙을 연결하더라도, app-1의 가용 영역이 비활성 상태라면 Target.NotInUse의 원인이 남습니다. 이 대상을 사용하려는 설계라면 해당 영역의 활성화도 함께 검토해야 합니다.

두 조건을 충족한 뒤에는 대상 상태와 이유 코드를 다시 확인합니다. 초기 헬스 체크가 진행 중이면 initial로 표시될 수 있고, 초기 헬스 체크를 통과하면 healthy가 됩니다. 설정 수정 직후 곧바로 정상 상태가 된다고 가정해서는 안 됩니다.

설정 수정 후에도 구분해야 할 한계

리스너 규칙 연결과 가용 영역 활성화는 헬스 체크를 위한 전제 조건입니다. 이를 충족했다고 애플리케이션 응답까지 정상이라는 뜻은 아닙니다. 이후 Target.ResponseCodeMismatch나 Target.Timeout이 나타나면 새 이유 코드에 따라 헬스 체크 실패를 별도로 진단해야 합니다.

또한 Target.NotInUse만으로 특정 요청이 의도한 리스너 규칙을 선택하는지까지 판단할 수는 없습니다. 대상 그룹 연결을 복구할 때는 실제로 전달하려는 요청 조건과 변경할 규칙이 일치하는지도 검토해야 합니다.

점검 기록에는 대상 그룹 식별자, 이를 사용하는 리스너 규칙, 대상의 가용 영역, ALB의 활성 가용 영역을 함께 남기세요. 수정 후 이유 코드를 다시 확인하면 남아 있는 설정 누락과 다음 진단 과제를 구분할 수 있습니다.

참고한 공식 문서

이어서 확인할 내용