1. 개요 및 아키텍쳐

기업 환경에서 On-Premise 시스템과 AWS 클라우드가 VPN 또는 Direct Connect로 연결되어 있을 때, On-Premise 사용자가 AWS VPC 내부의 Private ALB(Application Load Balancer)에 사설 도메인 이름으로 접근해야 하는 경우가 빈번합니다.

이때 핵심이 되는 서비스가 바로 AWS Route 53 Resolver 와 Private Hosted Zone입니다. 이 조합을 사용하면 On-Premise DNS 서버가 AWS 내부 도메인을 질의할 수 있게 되어, 퍼블릭 인터넷을 거치지 않고도 사설 네트워크 내에서 도메인 기반 통신이 가능해집니다.

본 문서에서는 HTTP(80 포트) 기반 통신을 기준으로 설명하며, HTTPS 인증서 설정 관련 내용은 별도로 다루지 않습니다. 또한 On-Premise와 AWS 간의 VPN/DX 연결 및 방화벽 설정은 이미 완료되어 있다는 전제하에 작성하였습니다.  
 

2. 환경 구성 안내 (On-Premise 시뮬레이션)

본 가이드에서는 실제 물리적 On-Premise 장비 대신,
AWS Common 계정의 EC2 인스턴스에 Windows DNS 서버를 구축
하여 On-Premise 환경을 시뮬레이션합니다. 이 Windows DNS 서버가 On-Premise 측 DNS 서버 역할을 담당하며, 별도의
AWS Workload 계정 에 위치한 애플리케이션(Private ALB 뒤의 EKS/EC2)으로의 연결을 구성합니다.

즉, 본 블로그에서 "On-Premise"라고 지칭하는 환경은 실제로는 AWS Common 계정의 EC2 Windows 서버이지만, 네트워크 구성과 DNS 동작 원리는 실제 On-Premise 환경과 동일합니다. 실제 운영 환경에서는 이 Windows DNS 서버가 사내 데이터센터의 AD DNS 서버에 해당합니다.



                        [그림1] AWS Common에 있는 Window DNS Server를 On-Premise DNS 서버라 가정합니다.


 

3. Step 1 — Route 53 Private Hosted Zone 생성

AWS 콘솔에서 Route 53 → Hosted zones → Create hosted zone으로 이동합니다. Domain name에 사용할 도메인(예: dev.company.com)을 입력하고, Type을 Private hosted zone으로 선택합니다.  
 

1) Private Hosted Zone 생성 화면  

                                                                                                  [그림 3] Private Hosted Zone에 VPC 연결 — 연결 대상 애플리케이션이 위치한 VPC 선택

4. Step 2 — VPC 연결 (Associate)

Private Hosted Zone은 특정 VPC와 연결(Associate)되어야만 해당 VPC 내부에서 도메인 해석이 가능합니다. 연결 대상 애플리케이션이 위치한 VPC를 선택합니다.  
 

2) VPC 연결 설정

애플리케이션이 배포된 VPC를 선택하여 연결합니다. 
VPC의 enableDnsHostnames와 enableDnsSupport가 true로 설정되어 있어야 합니다.


                                                                                                                                               [그림 2] Route 53에서 Private Hosted Zone 생성 — 도메인: dev.company.com, Type: Private hosted zone   
 

5. Step 3 — DNS 레코드 생성 (도메인 ↔ ALB 매핑)  

Private Hosted Zone이 생성되면, 기본적으로 NS(Name Server)와 SOA 레코드만 존재합니다. 여기에 애플리케이션 도메인과 Private ALB를 연결하는 레코드를 추가합니다.  
 

3) 레코드 목록 및 생성 버튼  

Hosted zone 상세 화면에서 Create record 버튼을 클릭하여 새 레코드를 생성합니다.  

                                                                                                                                                                                                     [그림 3] dev.company.com Hosted Zone — Create record 클릭

 

4) CNAME 레코드로 ALB 매핑  

Record name에 서브도메인(예: main.dev.company)을 입력하고, Record type을 CNAME으로 선택한 뒤, Value에 Private ALB의 DNS 이름을 입력합니다.  


                                                                                                                                          [그림 5] CNAME 레코드 생성 — main.dev.company.com → ALB DNS  

※ 단, CNAME보다 Alias 레코드를 추천합니다 본 예시에서는 CNAME 레코드를 사용했지만, 실제 운영 환경에서는
Alias 레코드 사용을 권장합니다. Alias 레코드는 CNAME과 달리 추가 DNS 질의가 필요 없어 응답 속도가 빠르고, Route 53에서 ALB 대상 Alias 쿼리에 대해서는 추가 비용이 발생하지 않습니다.  


 

6. Step 4 — Route 53 Resolver Inbound Endpoint 생성

5) Inbound Endpoint 기본 설정  

콘솔에서 Route 53 → Resolver → Inbound endpoints 경로로 들어가  엔드포인트를 생성합니다. Endpoint 이름, VPC, 보안그룹, 프로토콜 등을 설정합니다.   


                                                                                                                          [그림 6] Inbound Endpoint 생성  

6) Inbound Endpoint IP 주소 설정 (Multi-AZ)

가용성 확보를 위해 서로 다른 두 개의 가용영역(AZ)에 각각 Inbound Endpoint IP를 생성합니다. 각 AZ의 Private Subnet을 선택하면, 해당 서브넷 대역에서  설정에 따라 자동 또는 수동으로 IP가 할당됩니다.


                                                                                                                             [그림 6] 두 개 AZ(ap-northeast-2a, 2c)에 Inbound Endpoint IP 구성

7. Step 5 — Inbound Endpoint 보안그룹 설정

Inbound Endpoint의 보안그룹에는 On-Premise 네트워크 대역에서 DNS 포트(TCP/UDP 53)로의 인바운드 트래픽을 허용해야 합니다. On-Premise 측 CIDR 대역 모두를 등록합니다.


                                                                                                                                  [그림 7] Inbound Endpoint 보안그룹 — On-Premise CIDR 대역에서 TCP/UDP 53 허용  
 

8. Step 6 — Inbound Endpoint IP 확인

Endpoint 생성이 완료되면 Status가 Operational로 변경되고, 각 AZ별로 할당된 IP 주소를 확인할 수 있습니다. 이 IP 주소가 On-Premise DNS 서버의 조건부 전달자(Conditional Forwarder)에 등록할 대상입니다.


                                                                                                                    [그림 8] Inbound Endpoint IP 확인  
 

9. Step 7 — On-Premise DNS 조건부 전달자 설정

이제 On-Premise 역할을 하는 Windows DNS 서버(AWS Common 계정 EC2)에서 조건부 전달자(Conditional Forwarder)를 설정합니다. 특정 도메인에 대한 DNS 질의를 Route 53 Resolver Inbound Endpoint IP로 포워딩하는 설정입니다.  
 

7) Windows DNS Manager — 조건부 전달자 설정

DNS Manager에서 Conditional Forwarders를 우클릭하고 New Conditional Forwarder를 선택합니다. DNS Domain에 포워딩할 도메인(예: dev.company.com)을 입력하고, 앞서 확인한 Inbound Endpoint IP 두 개를 등록합니다.

                                     [그림 9] Windows DNS Manager — 조건부 전달자에 Inbound Endpoint IP 등록

※ IP 옆 X 표시(유효성 검증 실패)에 대하여
조건부 전달자에 Inbound Endpoint IP를 등록하면, IP 옆에 빨간 X 표시
가 나타날 수 있습니다. 이는 Windows DNS 서버가 해당 IP에 대해 역방향 조회(Reverse Lookup) 등의 유효성 검증을 시도하는데, AWS Route 53 Resolver Inbound Endpoint는 일반 Windows DNS 서버가 아니기 때문에 검증에 실패하는 것입니다.
이 X 표시는 실제 DNS 포워딩 동작에는 영향을 주지 않으며, 정상적으로 DNS 질의가 전달됩니다.

※ 서브도메인 구조에서 조건부 전달자 생성 시 오류가 발생하는 경우



                                            [그림 10] 서브도메인 구조에서 조건부 전달자 생성 시 오류  


만약 On-Premise AD DNS 서버에서 상위 존(예: company.com)을 이미 호스팅하고 있는 상태에서, 그 하위 도메인(예: dev.company .com)을 조건부 전달자로 추가하려고 하면 [그림] 10 같은 오류가 발생할 수 있습니다.   
 

원인: 상위 존을 해당 DNS 서버가 직접 호스팅하고 있을 때, 동일 서버에서 하위 도메인을 조건부 전달자로 생성하면 Windows DNS가 존 구성 충돌로 인식합니다.
 

해결 방법:
① 먼저 부모 존(company.com)에서 서브도메인에 대한 Delegation(위임)
을 생성합니다. DNS Manager에서 Forward Lookup Zones → company .com을 우클릭하여 New Delegation
을 선택하고, 위임할 도메인명(예: dev)을 입력합니다.  
 

② 이후 Conditional Forwarders 에서 해당 도메인(예: dev. company  .com)에 대한 조건부 전달자를 생성합니다.
등록이 되지 않는 경우 하단의 "Store this conditional forwarder in Active Directory"
옵션을 체크하고 복제 범위를 환경에 맞게 선택하면 해결될 수 있습니다.  
 

10. Step 8 — ALB 리스너 규칙 설정 (Host Header 기반 라우팅)

Route 53 Private Hosted Zone에 도메인 레코드를 등록하고, On-Premise DNS에서 조건부 전달자까지 설정했다면, 이제 마지막으로 ALB(Application Load Balancer)가 도메인별로 올바른 백엔드 서비스로 트래픽을 라우팅하도록 리스너 규칙을 설정해야 합니다.

하나의 Private ALB에 여러 서비스(ArgoCD, Jenkins, Airflow 등)가 연결되어 있는 경우, 각 서비스별로 고유한 도메인을 사용하고, ALB가 HTTP 요청의 Host Header 값을 기준으로 적절한 Target Group으로 분기하는 방식입니다.  
 

8)  ALB HTTP:80 리스너 규칙 설정

EC2 → Load Balancers에서 해당 ALB의 HTTP:80 리스너로 이동합니다. 아래 화면과 같이 리스너 규칙(Listener Rules)이 Host Header 조건에 따라 각각 다른 Target Group으로 포워딩되도록 구성합니다.  



                                                                                                                                                                [그림 10] ALB HTTP:80 리스너 규칙 — Host Header 기반으로 서비스별 Target Group 라우팅

 

※ 리스너 규칙 구성 상세
위 화면에서 확인할 수 있는 주요 구성 내용은 다음과 같습니다.

• Default Action (기본 동작): 어떤 규칙에도 매칭되지 않는 요청은 404 고정 응답(Return fixed response)을 반환합니다. 이를 통해 등록되지 않은 도메인으로의 접근을 차단합니다.
• Rule 1: Host Header 값이 main.dev.company.com이고 Path가 /*인 요청 → Main Target Group으로 100% 포워딩
• Rule 2: Host Header 값이 jenkins. dev.company.com이고 Path가 /*인 요청 → Jenkins Target Group으로 100% 포워딩
  이와 같은 패턴으로, Private Hosted Zone에 등록한 모든 서비스 도메인에 대해 각각의 리스너 규칙을 추가하면 됩니다. 새로운 서비스가 추가될 때에도 ALB에 리스너 규칙을 추가하고, Route 53 Private Hosted Zone에 CNAME(또는 Alias) 레코드만 등록하면 바로 On-Premise에서 접근이 가능해집니다.  

 

11. 최종 결과 확인

모든 구성이 완료되면, On-Premise 클라이언트에서 AWS 내부 애플리케이션에 사설 도메인으로 접근할 수 있습니다. 아래는 dev.company.com/login에 정상적으로 접속된 화면입니다.

이제까지 On-Premise 환경에서 AWS VPC 내부의 Private ALB에 사설 도메인 기반으로 접근하는 방법에 대해서  알아보았습니다.