EC2를 온프레미스 Active Directory에 도메인 참가시킬 때의 DNS 구성 3가지 비교

안녕하세요 클래스메소드의 이수재입니다.

이번 글에서는 Windows Server EC2를 기존 온프레미스 Active Directory에 도메인 참가시킬 때 필요한 DNS 역할을 살펴보고, DNS 구성 세 가지의 동작과 설정, 운영상 차이를 비교해보겠습니다.

도메인 참가에서 DNS는 어떤 역할을 할까

도메인 참가는 Windows 서버를 AD가 관리하는 컴퓨터로 등록해, 도메인 계정과 그룹 정책을 사용할 수 있도록 연결하는 작업입니다. EC2도 온프레미스의 도메인 컨트롤러(DC)와 필요한 통신이 가능하면 기존 AD에 참가할 수 있습니다.
AWS의 기존 AD 연동 설명

이 과정에서 EC2는 먼저 어느 DC와 통신해야 하는지 알아야 합니다. 관리자가 ad.example.com이라는 도메인명을 입력했다고 해서 Windows가 DC의 IP 주소를 이미 알고 있는 것은 아닙니다. 여기서 DNS를 통해 AD 서비스를 제공하는 서버를 찾습니다.

흐름을 단순화하면 다음과 같습니다.

1. DC 검색       EC2 → DNS 조회 → DC 후보의 이름과 주소 확인
2. 참가·인증     EC2 → 선택한 DC와 직접 통신
3. 참가 후 운영  EC2 → DNS와 DC를 이용해 인증·정책 처리

참가 후에도 인증과 정책 처리를 위해 DC와 관련 서비스를 계속 찾을 수 있어야 합니다. 도메인 참가 이후에도 AD 이름을 해석할 수 있는 DNS 구성이 필요한 이유입니다.
Microsoft DC 검색 과정

따라서 이 글에서 비교하는 세 방법은 AD 도메인에 참가하는 기능의 차이가 아니라, EC2가 AD의 이름을 해석하는 경로를 만드는 방법의 차이입니다.

왜 기본 설정으로는 안 되는가

예를 들어 EC2를 ad.example.com 도메인에 참가시키려면, 먼저 이 도메인의 DC를 찾아야 합니다.
이때 Windows는 DNS에 _ldap._tcp.dc._msdcs.ad.example.com이라는 이름의 SRV 레코드를 조회합니다.

이 조회는 쉽게 말해 “ad.example.com에서 DC 역할을 하는 서버는 어디인가요?”라고 묻는 과정입니다. 응답에는 LDAP 서비스를 제공하는 DC의 호스트명과 서비스 포트 등이 포함됩니다.

A 레코드가 호스트명에 대응하는 IPv4 주소를 알려준다면, SRV 레코드는 특정 서비스를 제공하는 호스트명과 포트 등을 알려줍니다.

따라서 SRV 레코드를 조회할 수 있는지와, 응답으로 받은 DC의 호스트명을 IP 주소로 해석할 수 있는지를 함께 확인해야 합니다.

사내 AD DNS 서버는 DC 검색에 필요한 레코드를 관리합니다. EC2가 기본 DNS인 AmazonProvidedDNS를 사용하는 경우, 사내 AD DNS로 DNS 요청을 전달하는 설정이 없으면 이러한 레코드를 조회할 수 없습니다.

VPC의 기본 DHCP 옵션에서 DNS 서버를 지정하는 항목을 보면 다음과 같습니다. domain-name-servers가 인스턴스에 배포할 DNS 서버를 정하는 항목입니다.

domain-name-servers : AmazonProvidedDNS

EC2가 사내 AD DNS로 직접 DNS 요청을 보내거나, AmazonProvidedDNS를 거쳐 요청을 전달하도록 구성하면 DC 검색에 필요한 레코드를 조회할 수 있습니다. 뒤에서 소개할 세 방법은 이 조회 경로를 만드는 방법입니다.
AWS의 AD·Route 53 연동 예시

세 가지 방법은 무엇을 바꾸는가

먼저 EC2가 DNS 요청을 처음 보내는 서버와 사내 AD 도메인과 AWS 내부 도메인의 조회를 각각 어디에서 처리하는지를 나누어 보면 이해하기 쉽습니다.

방법 A와 B는 EC2가 DNS 요청을 보내는 서버를 사내 DNS로 바꿉니다. A는 서버에서 직접 바꾸고, B는 AWS의 DHCP 설정으로 주소를 배포한다는 차이가 있습니다.

방법 C는 EC2가 사용하는 DNS를 AWS DNS로 유지하고, AWS 쪽에 AD 도메인의 DNS 요청을 전달할 경로를 추가합니다.

예를 들어 app-server-01만 참가시키고 싶다면 A로 해당 서버의 DNS를 지정할 수 있습니다. 같은 VPC에서 앞으로 만드는 서버에도 사내 DNS를 공통 적용하려면 B를 검토할 수 있습니다.
AWS의 Private Hosted Zone 등을 계속 사용하면서 AD 도메인의 DNS 요청만 사내로 보내고 싶다면 C가 후보가 됩니다.

아래 구성 예시는 VPC와 온프레미스가 Site-to-Site VPN으로 연결되어 있다고 가정합니다. AD 도메인은 ad.example.com, 사내 DNS 주소는 192.168.1.10과 192.168.1.11을 사용합니다.

실제 적용 전에는 AD 담당자에게 도메인 FQDN, DNS와 DC의 주소를 확인해야 합니다. DNS와 DC가 같은 서버일 수 있지만 반드시 같은 것은 아닙니다.

명령의 주소·리소스 ID는 각 환경에 맞게 바꾸고, AWS CLI 예시는 Bash 기준으로 실행합니다.

방법 A: 대상 EC2의 NIC에 AD DNS를 정적 지정

가장 단순한 방법입니다. 해당 서버의 네트워크 어댑터에 사내 DNS 서버 주소를 직접 지정합니다.

기존 VPC의 기본 DNS 설정을 유지하면서 선택한 서버만 변경할 수 있어, 일부 서버를 먼저 적용하고 확인하기 좋습니다. 대신 이후 서버를 교체하거나 추가할 때도 동일한 설정을 반영하도록 관리해야 합니다.

동작 원리

NIC에서 "다음 DNS 서버 주소 사용"으로 정적 지정하면, DHCP가 배포한 DNS 서버 주소는 그 어댑터에서 무시됩니다. DHCP 옵션은 "자동으로 DNS 서버 주소 받기" 상태일 때만 사용되기 때문입니다.

즉 VPC의 DHCP 옵션 세트가 AmazonProvidedDNS인 채로 두어도 충돌이 일어나지 않습니다. IP 주소는 계속 DHCP로 받고 DNS만 정적으로 지정하는 형태이므로, EC2의 IP 관리 방식도 바뀌지 않습니다.

VPC DHCP 옵션: AmazonProvidedDNS 유지
    ├─ DNS를 수동 지정한 EC2 → VPN → 사내 DNS
    └─ DNS를 자동으로 받는 EC2 → AWS 제공 DNS

AWS Directory Service의 AWS Managed Microsoft AD 수동 참가 절차에서도 NIC에 DNS 주소를 지정하는 방식을 안내합니다. 온프레미스 AD에 연결할 때는 통신 가능한 사내 AD DNS 주소를 지정합니다.

설정 방법

DNS 주소는 PowerShell 명령으로 변경할 수 있습니다. 관리자 권한으로 실행하고, 먼저 실제 어댑터 이름과 기존 DNS 설정을 확인해 기록해둡니다. 아래 IP와 도메인명은 예시이며, Ethernet도 실제 어댑터 이름으로 바꿔야 합니다.

# 현재 설정 확인
Get-DnsClientServerAddress -AddressFamily IPv4

# AD DNS 서버로 변경
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("192.168.1.10","192.168.1.11")

# 확인
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.example.com
nltest /dsgetdc:ad.example.com

Resolve-DnsName에서는 SRV 응답에 예상한 DC의 호스트명이 포함되는지 확인합니다. nltest /dsgetdc는 Windows가 DC를 찾을 수 있는지 확인하는 명령입니다. 참가 후 동작과 기존 서비스의 확인 항목은 마지막 검증 절에서 다룹니다.

GUI로 하실 경우 ncpa.cpl → 어댑터 우클릭 → 속성 → IPv4 → "다음 DNS 서버 주소 사용"입니다.

원래 DNS를 자동으로 받던 서버라면, 되돌릴 때 "자동으로 DNS 서버 주소 받기"로 변경하거나 다음 명령을 실행합니다. 기존에도 DNS를 수동 지정했다면 기록해둔 원래 주소로 복구합니다.

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses

주의점

별도의 DNS 정책이 없다면, 변경한 어댑터를 사용하는 Windows의 일반적인 DNS 조회는 사내 DNS를 경유합니다. 따라서 사내 DNS가 AD 도메인 외에 어떤 이름을 해석할 수 있는지도 확인해야 합니다.

AWS 내부 이름 조회

Private Hosted Zone이나 인터페이스형 VPC 엔드포인트의 프라이빗 DNS를 사용 중이라면, 사내 DNS에서도 그 이름을 조회할 수 있는지 확인합니다. 사내 DNS에 조회 경로가 없다면 DNS 변경 후 이름 해석이 실패할 수 있습니다.

이 경우 사내 DNS에 조건부 전달을 설정해, 지정한 도메인의 DNS 요청만 Route 53 Resolver 인바운드 엔드포인트로 보낼 수 있습니다. 인바운드 엔드포인트는 사내 DNS에서 보낸 요청을 받아 VPC Resolver로 전달하는 진입점입니다. AWS의 하이브리드 DNS 문서

EC2 → 사내 DNS
        ├─ AD 도메인 → 자체 응답
        └─ AWS 내부 도메인 → 인바운드 엔드포인트 → VPC Resolver

인바운드 엔드포인트를 사용하는 VPC에서 필요한 Private Hosted Zone이나 인터페이스형 VPC 엔드포인트의 프라이빗 DNS 이름이 해석되도록 구성해야 합니다.

인바운드 엔드포인트를 새로 만들면 별도 비용이 발생합니다. 또한 EC2의 DNS 요청이 먼저 사내 DNS로 가기 때문에, 이 구성을 추가해도 사내 DNS와 VPN에 대한 의존성은 남습니다.

인터넷 이름 조회

DNS 서버는 자기가 관리하는 존에 답하거나, 포워더 또는 루트 힌트를 이용해 외부 이름을 해석할 수 있습니다. 포워더가 없다는 이유만으로 외부 이름 해석이 실패하는 것은 아닙니다. 다만 재귀 조회나 외부 통신을 제한해 사내 이름만 조회할 수 있도록 운영하는 환경도 있습니다.
Microsoft DNS 전달 설명

대상 EC2에서 각 사내 DNS를 지정해 외부 도메인 조회가 가능한지 확인합니다. 사내 PC에서의 성공만으로는 EC2 출발지의 방화벽이나 DNS 접근 정책까지 확인할 수 없습니다.

nslookup www.google.com 192.168.1.10
nslookup www.google.com 192.168.1.11

이는 외부 조회의 간단한 확인 예시입니다. 실제 사용하는 AWS 서비스 주소, AD SRV 레코드와 DC 호스트명, AWS 내부 도메인도 각각 확인해야 합니다.

방법 B: 커스텀 DHCP 옵션 세트를 VPC에 연결

VPC 레벨에서 인스턴스에 배포할 DNS 서버 주소를 지정하는 방법입니다. DNS를 자동으로 받는 인스턴스라면 OS에서 주소를 개별 지정할 필요가 없습니다. NIC에 DNS를 수동 설정한 서버는 별도로 확인해야 합니다.

방법 A와 실제 DNS 경로는 같습니다

커스텀 DHCP 옵션은 AWS DHCP가 인스턴스에 전달하는 네트워크 설정 묶음입니다. 사내 DHCP 서버에서 EC2의 IP를 받도록 바꾸거나, DHCP가 DNS 요청을 대신 처리하도록 만드는 기능은 아닙니다.
AWS DHCP 옵션 개념

설정 배포: AWS DHCP → EC2에 사내 DNS 주소 전달
이름 조회: EC2 → VPN → 사내 DNS

같은 사내 DNS 주소를 지정했다면 A와 B가 DNS 요청을 보내는 서버는 같습니다. 차이는 설정을 서버별로 관리할지, VPC의 기본값으로 배포할지입니다. 그래서 사내 DNS에서 외부 이름이나 AWS 내부 이름을 해석할 수 있어야 한다는 주의점도 동일하게 적용됩니다.

예를 들어 일부 Windows만 AD에 참가시키려는데 같은 VPC에 Linux 배치 서버도 있다면, 방법 B는 그 서버의 DNS 설정에도 영향을 줄 수 있습니다. AD 참가 대상만 세기보다 해당 VPC에서 DNS를 자동으로 받는 서버와 그 서버가 조회하는 이름을 함께 확인해야 합니다.

설정 방법

DHCP 옵션 세트를 새로 만들고 VPC에 연결합니다. VPC당 하나의 옵션 세트만 연결할 수 있으며, 서브넷별로 다른 세트를 적용할 수는 없습니다.

# 1. DHCP 옵션 세트 생성
aws ec2 create-dhcp-options \
  --dhcp-configurations \
    "Key=domain-name-servers,Values=192.168.1.10,192.168.1.11" \
    "Key=domain-name,Values=ad.example.com"

# 2. VPC에 연결
aws ec2 associate-dhcp-options \
  --dhcp-options-id dopt-xxxxxxxxxxxxxxxxx \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx

예시의 domain-name은 DNS 검색 접미사입니다. 이 값을 설정한다고 AD에 자동 가입되지는 않습니다. 기존 접미사와 NTP 등 다른 DHCP 옵션도 확인하고 필요한 값을 새 세트에 반영합니다.

첫 번째 명령의 결과에서 새 DhcpOptionsId를 확인하고 두 번째 명령에 사용합니다. 원복할 기존 옵션 세트 ID도 함께 기록합니다. 새 옵션 세트를 생성하는 것만으로는 인스턴스 설정이 바뀌지 않으며, 두 번째 명령으로 VPC에 연결해야 적용됩니다.

알아두어야 할 제약

1. 생성 후 수정할 수 없습니다

Important: You can't modify the DHCP options set after you create the set. To modify your DHCP options set, create a new DHCP options set with the correct parameters and associate it with your VPC.

— Why aren't the configuration parameters of my DHCP options set passed to instances in the VPC?

DNS 서버를 변경하려면 새로 만들어서 VPC에 다시 연결해야 합니다. 기존 옵션 세트를 지우지 않고 남겨두면 원복 시 다시 연결할 수 있습니다. 다만 원복도 각 인스턴스의 DHCP 갱신 시점에 따라 반영되므로 시간이 걸릴 수 있습니다.

2. AmazonProvidedDNS와 사내 DNS의 혼용은 권장되지 않습니다

You can enter either the AmazonProvidedDNS or custom domain name servers. Using both might cause unexpected behavior. Therefore, it's a best practice to use either AmazonProvidedDNS, or a custom domain name server.

DHCP 옵션의 DNS 서버 목록만으로 "AD 도메인만 사내 DNS, 나머지는 AWS DNS" 같은 분기를 구현할 수는 없습니다. 이름별 전달이 필요하다면 방법 A에서 설명한 사내 DNS의 조건부 전달을 사용합니다. AWS DHCP 옵션 설정 안내

3. 반영 타이밍

재부팅은 필요하지 않습니다. DHCP 리스가 자동 갱신될 때 반영됩니다. 빠른 반영이 필요하면 OS에서 수동 갱신합니다.

ipconfig /renew
ipconfig /all

ipconfig /all에서 대상 어댑터의 DNS 서버 목록이 바뀌었는지 확인합니다. VPC의 연결 변경 직후에는 임대 갱신 시점 차이로 기존 DNS를 사용하는 서버와 새 DNS를 사용하는 서버가 섞일 수 있습니다. 대표 서버 한 대의 성공만으로 전체 반영이 끝났다고 판단하지 않는 것이 좋습니다.

또한 DNS를 두 대 지정해도 두 서버가 모두 같은 VPN 경로에 의존한다면, 회선 장애는 함께 영향을 줍니다. DNS 서버 수와 통신 경로의 가용성을 따로 살펴봐야 합니다.

방법 C: Route 53 Resolver 아웃바운드 엔드포인트 + 전달 규칙

AWS 제공 DNS를 그대로 사용하면서, VPC Resolver에서 특정 도메인의 DNS 요청만 사내 DNS로 전달하는 방법입니다.

예를 들어 ad.example.com에 대한 규칙이 있다면 DC 검색용 이름인 _ldap._tcp.dc._msdcs.ad.example.com도 전달 대상에 포함됩니다. AD DNS에서 받은 결과는 Resolver를 통해 EC2에 돌아옵니다.

다른 규칙이 없는 일반 외부 도메인이나 VPC에 연결된 Private Hosted Zone의 조회는 기존 AWS DNS 구성을 이용합니다. AWS 아웃바운드 전달 설명

EC2 → AWS 제공 DNS (VPC+2 리졸버)
        ├─ ad.example.com 조회 → 아웃바운드 엔드포인트 → VPN → 사내 DNS
        └─ 그 외 도메인 조회   → AWS 제공 DNS가 그대로 처리

구성 요소

1. 아웃바운드 엔드포인트 — 서로 다른 AZ의 서브넷 2개 이상에 ENI를 생성합니다. 전용 보안 그룹이 필요하며, 사내 DNS 방향으로 TCP/UDP 53 아웃바운드를 허용합니다
2. 전달 규칙(Forwarding Rule) — 대상 도메인명과 전달할 DNS 서버 IP를 지정합니다
3. 규칙과 VPC 연결

각 요소의 역할을 나누면, 엔드포인트는 DNS 요청이 사내 DNS로 나가는 네트워크 경로이고, 규칙은 어떤 도메인의 요청을 전달할지 정하는 조건이며, VPC 연결은 그 규칙의 적용 대상을 정하는 설정입니다. 엔드포인트만 생성하거나 규칙만 만든 상태로는 원하는 VPC의 DNS 요청이 자동으로 전달되지 않습니다.

방법 C에서 전달된 DNS 요청은 아웃바운드 엔드포인트의 IP 주소에서 출발합니다. 따라서 온프레미스 방화벽에서 아웃바운드 엔드포인트의 IP를 출발지로 하는 DNS 통신도 허용되어 있는지 확인합니다. 엔드포인트가 위치한 서브넷의 라우팅과 NACL, 사내 DNS의 응답이 돌아오는 경로도 함께 확인합니다.

설정 방법

콘솔에서는 Route 53 → 아웃바운드 엔드포인트 → 생성 → 규칙 생성 순서입니다. CLI라면 다음과 같습니다.

1. 아웃바운드 엔드포인트 생성

서로 다른 AZ의 서브넷 2개 이상을 지정합니다.

aws route53resolver create-resolver-endpoint \
  --name ad-outbound \
  --direction OUTBOUND \
  --creator-request-id ad-outbound-001 \
  --security-group-ids sg-xxxxxxxxxxxxxxxxx \
  --ip-addresses SubnetId=subnet-aaaaaaaaaaaaaaaaa SubnetId=subnet-bbbbbbbbbbbbbbbbb

응답으로 받은 엔드포인트 ID를 다음 단계의 --resolver-endpoint-id에 넣습니다.

2. 엔드포인트 상태 확인

aws route53resolver get-resolver-endpoint \
  --resolver-endpoint-id rslvr-out-xxxxxxxxxxxxxxxxx \
  --query 'ResolverEndpoint.Status' \
  --output text

엔드포인트 생성은 비동기로 진행됩니다. 상태가 CREATING이면 기다렸다가 다시 확인하고, OPERATIONAL이 되면 다음 단계로 진행합니다. AWS Endpoint 상태 조회

3. 전달 규칙 생성

1단계에서 받은 엔드포인트 ID와 사내 DNS의 IP 주소를 지정합니다.

aws route53resolver create-resolver-rule \
  --name forward-ad-domain \
  --creator-request-id ad-rule-001 \
  --rule-type FORWARD \
  --domain-name ad.example.com \
  --resolver-endpoint-id rslvr-out-xxxxxxxxxxxxxxxxx \
  --target-ips "Ip=192.168.1.10" "Ip=192.168.1.11"

응답으로 받은 규칙 ID를 다음 단계의 --resolver-rule-id에 넣습니다.

4. 규칙을 VPC에 연결

전달 규칙을 적용할 VPC의 ID를 지정합니다.

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-xxxxxxxxxxxxxxxxx \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --name assoc-ad-rule

방법 C를 검증할 EC2는 VPC의 DHCP 옵션으로 배포된 AmazonProvidedDNS를 사용해야 합니다. NIC에 사내 DNS를 수동 지정했다면 DNS 요청이 VPC Resolver를 거치지 않으므로, 먼저 EC2가 사용하는 DNS 서버 주소를 확인합니다.

AD 연동 시에는 정방향 존과 함께 애플리케이션이나 운영 도구에서 사용하는 역방향 조회(in-addr.arpa)도 검토합니다. 모든 도메인 참가에 역방향 전달 규칙이 필수인 것은 아닙니다.

역방향 전달 규칙을 추가할 경우 필요한 주소 범위와 VPC의 자동 정의된 역방향 규칙 간 우선순위도 확인합니다. AWS 블로그의 AD·Route 53 연동 예시에 구체적인 구성이 정리되어 있습니다.

비용

아웃바운드 엔드포인트에는 사용 시간과 처리한 DNS 쿼리 수에 따른 요금이 발생합니다.

엔드포인트는 IP 주소(ENI)가 최소 2개 필수입니다. ENI 2개를 월 730시간 사용하면 2 × $0.125 × 730 = $182.50입니다. 실제 사용 시간과 ENI 수에 따라 달라지며, 엔드포인트를 통과하는 DNS 쿼리 요금은 별도입니다. AWS 공식 요금표

되돌리기

특정 VPC에 적용한 전달 설정을 원복할 때는 해당 VPC와 규칙의 연결을 해제하거나 기존 규칙 연결로 복구합니다. 공유 중인 엔드포인트나 규칙을 삭제하면 다른 VPC에도 영향을 줄 수 있으므로, 우선 대상 VPC의 연결을 기준으로 작업합니다. AWS 규칙 연결 해제 안내

규칙 연결만 해제하면 엔드포인트 비용은 계속 발생합니다. 비용까지 정리하려면 다른 규칙과 VPC에서 사용하지 않는지 확인한 뒤 불필요한 규칙과 엔드포인트를 삭제합니다. 이미 AD에 참가한 서버가 있다면 원복 후에도 필요한 AD 이름 해석이 가능한지 함께 확인합니다.

3가지 비교

A·B의 장애 영향은 표의 적용 대상이 사용하는 사내 DNS에 모두 접근할 수 없는 경우를 뜻합니다. A의 NIC 설정과 B의 DHCP 옵션 자체에는 도메인별 분기 기능이 없으며, 사내 DNS에 조건부 전달을 추가해야 합니다.

A·B의 추가 요금 없음은 DNS 주소 설정에 대한 설명입니다. 인바운드 엔드포인트를 새로 만들면 별도 비용이 발생합니다. C의 월 비용 예시는 ENI 2개를 730시간 사용하는 기준입니다.

B를 되돌릴 때는 기존 DHCP 옵션 세트를 다시 연결하고 인스턴스의 DHCP 갱신을 확인합니다. C는 대상 VPC의 규칙 연결을 해제하거나 기존 연결로 복구하며, 공유 엔드포인트를 삭제할 필요는 없습니다.

어떤 기준으로 고를까

대상이 소수의 서버뿐이라면 방법 A를 먼저 검토할 수 있습니다. 기존 사내 DNS로 필요한 이름이 모두 해석된다면, 대상 서버의 NIC 설정만으로 적용할 수 있습니다. 변경할 서버를 한정할 수 있어 일부 서버부터 적용하기에도 편합니다.

VPC 내 다수 인스턴스가 공통으로 사내 DNS를 사용해야 한다면 방법 B가 관리상 편합니다. DNS를 자동으로 받는 신규 인스턴스에도 적용되므로 대수가 늘어날수록 유리합니다. 다만 지정한 사내 DNS에 모두 접근할 수 없게 되면, 해당 설정을 사용하는 인스턴스들의 일반적인 이름 조회에 영향을 줄 수 있습니다.

다음에 해당한다면 방법 C를 검토할 가치가 있습니다.

• Private Hosted Zone이나 VPC 엔드포인트를 사용하며, AWS 내부 이름 조회를 사내 DNS에 의존시키지 않고 유지하려는 경우
• 사내 DNS 장애 시 DNS 영향을 전달 대상 도메인으로 제한하고 싶은 경우
• 여러 VPC에서 동일한 AD 이름 해석이 필요한 경우 (엔드포인트 공유로 비용 분산)

사내 DNS에서 AWS 내부 이름을 조회하는 경로가 이미 있다면 A·B에서 활용할 수 있습니다. 새로 구성해야 한다면 인바운드 엔드포인트를 추가하는 비용과 C의 아웃바운드 엔드포인트 비용을 비교하고, AWS 내부 이름 조회도 VPN과 사내 DNS를 거치게 할지 함께 판단하면 됩니다.

적용 후에는 무엇을 확인해야 할까

세 방법 중 무엇을 선택하든, 사내 DNS에 직접 보내는 조회와 EC2에 설정된 DNS를 사용하는 조회를 나누어 확인하면 문제를 찾기 쉽습니다.

아래는 대상 EC2에서 실행하는 읽기 전용 예시입니다.

# 사내 DNS 자체가 AD 레코드에 응답하는지 확인
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -Server 192.168.1.10
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -Server 192.168.1.11

# 현재 EC2의 DNS 설정을 이용해 같은 이름 확인
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV

-Server를 지정하면 지정한 DNS 서버에서 레코드를 조회합니다. 이를 생략하면 인터페이스에 설정된 DNS를 이용하므로 A·B에서는 사내 DNS 설정을, C에서는 VPC Resolver를 통한 전달 구성을 확인하는 데 사용할 수 있습니다. Microsoft Resolve-DnsName 설명

단, 방법 C에서 사내 DNS를 직접 조회하는 검사는 EC2에서 사내 DNS로 TCP/UDP 53 통신이 허용된 경우에 의미가 있습니다. 실제 전달 경로는 아웃바운드 엔드포인트에서 출발하므로, 직접 조회의 성공이나 실패만으로 C의 동작을 결론 내리지는 않습니다.

확인 대상은 AD 이름에만 한정하지 않습니다. 변경 전에 정상 동작하던 애플리케이션의 접속 대상과 AWS 내부 이름도 같은 조건으로 비교합니다.

이 표는 원인을 확정하는 진단표가 아니라, 다음 확인 범위를 좁히기 위한 출발점입니다. 도메인 참가 실패 시에는 Windows의 C:\Windows\Debug\NetSetup.log도 함께 확인할 수 있습니다. Microsoft 도메인 참가 문제 해결 안내

운영 작업이라면 원복 판단 시점도 정해두는 편이 좋습니다. DNS 변경 후 AD뿐 아니라 기존 서비스의 이름 해석까지 확인하고, 참가와 재부팅을 진행한 뒤에는 로그인과 업무 서비스 동작을 다시 확인합니다. DNS 설정을 되돌리는 작업과 AD 도메인에서 탈퇴하는 작업은 별개이므로, 이미 참가한 서버의 복구 범위는 따로 정해야 합니다.

마무리

DNS 구성을 선택할 때는 "이름 해석의 분기를 어디에서 관리할 것인가" 와 **"변경과 장애의 영향 범위를 어디까지 허용할 것인가"**를 먼저 살펴보면 좋습니다. 기존 DNS 구성을 활용할 수 있는지와 추가 비용도 함께 비교해야 합니다.

Private Hosted Zone과 엔드포인트 등 AWS 측 구성은 콘솔에서 확인하고, 사내 DNS의 재귀 조회·조건부 전달 설정은 담당자와 함께 확인하면 됩니다.

작업 전에 사전 확인 항목을 정리해두면 당일에 당황할 일이 줄어듭니다. 이 글이 그 판단에 도움이 되었으면 좋겠습니다.

읽어주셔서 감사합니다. 궁금하신 점이나 다른 의견이 있으시면 must01940 지메일로 연락주시면 감사합니다.