[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Hybrid Cloud DNS Options for Amazon VPC (2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 4부로 구성되어 있으며 이 글은 4부입니다.
1부 링크 : Amazon VPC용 하이브리드 클라우드 DNS 옵션 1/4
추가 고려 사항
DNS 로깅
DNS 로깅은 개별 호스트에서 특정 DNS 쿼리를 로깅하는 것을 말합니다. 일반적으로 이러한 로그는 보안 법의학 및 규정 준수를 위해 저장됩니다. GuardDuty는 로컬 VPC 리소스에서 발생하는 재귀 쿼리에 대한 머신 러닝 기반 법의학 및 이상 탐지를 제공합니다. 원시 기록 로깅이 필요하지 않은 경우 GuardDuty는 추가 부하 없이 요구 사항을 충족 할 수 있습니다.
Route 53은 퍼블릭 호스팅 영역에 대한 쿼리 로그를 제공합니다. 고객이 VPC 내의 리소스에서 발생하는 프라이빗 호스팅 영역 및 쿼리에 대한 로깅이 필요한 경우 Well-Architected Framework 및 DNS 모범 사례를 따르는 동안 몇 가지 옵션이 있습니다.
중앙 집중식 쿼리 로깅, 분산 (온-인스턴스) 쿼리 로깅 및 사용자 정의 도메인 화이트리스트를 기반으로 쿼리 비율을 로깅하는 하이브리드 방식은 오늘날 가장 널리 사용되는 확장 가능한 쿼리 로깅 방법 중 세 가지입니다.
중앙 쿼리 로깅
모든 쿼리가 Route 53 Resolver (Amazon 제공 DNS)가 아닌 리졸버로 전달 될 때 쿼리 로깅이 중앙 집중식으로 수행됩니다. 이 리졸버는 언 바운드로 실행중인 여러 인스턴스 또는 DX, VPN 또는 인터넷 게이트웨이를 통한 온-프레미스 리소스와 같은 VPC에 로컬 일 수 있습니다. 후자는 VPC 외부에 추가 대기 시간 및 종속성을 추가하므로 일반적으로 이러한 이유로 권장되지 않습니다. 중앙 집중식 또는 분산 시스템과 마찬가지로 장단점이 있습니다.
쿼리 로그를 중앙 집중화 하면 쉽게 집계하고 단일 평면을 통해 DNS 클라이언트 쿼리를 보고 구문 분석 할 수 있습니다. 중앙 집중화를 사용하면 리졸버 역할을 하는 인스턴스의 규모와 단일 인스턴스에 대한 쿼리 수에 대한 추가 주의가 필요합니다. 이러한 인스턴스는 단일 장애 지점이 되며 초당 DNS 패킷 제한으로 인해 장애가 될 수 있습니다. 각 EC2 인스턴스는 Route 53 Resolver (Amazon 제공 DNS)를 향한 DNS 쿼리에 대해 초당 1024 개의 패킷으로 제한됩니다. 고객 관리 형 인스턴스 기반 DNS 확인자에게 전송되는 요청이 효과적으로 배포되지 않고 캐싱 기술을 구현하지 않는 경우, 대량으로 DNS 인스턴스는 Route 53 Resolver DNS 확인자에 대해 초당 1024 개 인스턴스 패킷 제한을 초과 할 수 있습니다.
분산 쿼리 로깅
다른 방법은 인스턴스에서 분산 방식으로 DNS 쿼리를 로깅하는 것입니다. 이는 로깅이 필요한 각 인스턴스에서 언 바운드 또는 다른 로깅 가능 리졸버 또는 전달자를 실행하여 수행됩니다. 분산 DNS 쿼리 모델로 각 인스턴스는 로컬 확인자를 실행하여 각 인스턴스에서 로컬로 모든 DNS 쿼리를 캡처합니다. 그런 다음이 로그를 히스토리 수집 및 중앙 집중식 구문 분석을 위해 중앙 집중식 Amazon S3 버킷으로 집계 할 수 있습니다. 집계 프로세스에 따라 중앙 집중식 구문 분석 및 포렌식에 대한 지연된 기능이 생성 될 수 있지만 단일 장애 지점을 제거하고 주어진 업스트림 인스턴스 기반 리졸버 장애의 전체 폭발 반경을 줄입니다. 주문형 인스턴스 구문 분석이 필요한 경우 배달 창을 단축 할 수 있습니다. 운영 모델에 따라 온 박스 법의학 또는 외부 액세스를 허용하거나 허용하지 않을 수 있으므로 로깅 전달 일정을 고려해야합니다.
re : Inforce 2019에서 VPC 트래픽 미러링을 시작하면 지원되는 인스턴스 유형에 대해 대체 오프 인스턴스 분산 로깅 메커니즘을 구현할 수 있습니다. 현재 모든 AWS Nitro 기반 인스턴스는 VPC 트래픽 미러링을 지원합니다. 개별 인스턴스 ENI의 포트 53에서 TCP 및 UDP 기반 트래픽에 대한 트래픽 미러링을 활성화하면 PCAP 형식으로 DNS 요청을 캡처 할 수 있습니다. DNS 로그에 대한 트래픽 미러링은 다른 분산 방법과 유사한 가용성 및 확장 성 구성을 공유하지만 추가 DNS 논리를 통합하기 위해 애플리케이션 또는 Amazon 머신 이미지 (AMI)가 필요하지 않으므로 단순성과 유연성이 향상됩니다. 필요에 따라 트래픽 미러링 세션을 인스턴스 ENI에 연결하거나 분리 할 수 있습니다. 트래픽 미러링은 트래픽 미러링이 활성화 된 탄력적 네트워크 인터페이스 당 가격이 책정되며 고객은 트래픽 미러 대상을 구성하고 관리해야 합니다.
Amazon VPC 트래픽 미러링에 대한 자세한 내용은 트래픽 미러링 개념을 참조하십시오.
하이브리드 쿼리 로깅
세 번째 옵션은 필터링 되는 쿼리를 보다 세분화 할 수 있는 하이브리드 방식입니다. 이 방법은 회사가 “신뢰할 수 있는”영역과 “신뢰할 수 없는”영역을 정의 할 수 있을 때 바람직 할 수 있습니다.
신뢰할 수 있는 영역은 조직에 의해 승인되며 로깅이 필요하지 않을 수 있지만, 승인되지 않은 항목은 신뢰할 수 없는 범주에 속하고 응답의 블랙리스트와 같은 조치를 취합니다. 예를 들어 조직과 VPC 로컬 리소스가 소유하고 운영하는 모든 영역은 신뢰할 수 있으며 다른 모든 영역은 기록 및 제어됩니다. 영역별로 조건부 전달 규칙을 제공 할 수 있는 기능으로 인해 Amazon Route 53 Resolver Service가 출시되면서 이 하이브리드 방식이 가능해졌습니다. 이 접근 방식에서는 모든 로컬 VPC 리소스가 정상적으로 Route 53 Resolver (Amazon 제공 DNS)로 확인되지만 Amazon Route 53 Resolver 조건부 전달 규칙과 일치하는 신뢰할 수 없는 영역에 대한 쿼리가 수행되면 지정된 인스턴스로 전달되거나 위에서 언급 한 중앙 집중식 DNS 확인자와 같은 온-프레미스 기반 확인자 이 방법은 인스턴스를 수정할 필요가 없으며 모든 신뢰할 수 있는 영역에 대한 단일 실패 지점을 제거합니다.
맞춤형 EC2 DNS 리졸버
Route 53 Resolver를 사용하는 대신 퍼블릭 DNS 서버를 활용하여 재귀 퍼블릭 DNS 확인을 수행하는 Amazon EC2에서 사용자 지정 DNS 리졸버를 호스팅하도록 선택할 수 있습니다. 이것은 응용 프로그램의 특성과 DNS 환경에 대해 더 많은 제어 및 유연성을 가질 수 있는 능력 때문에 좋은 선택입니다. 네트워크 당 PPS 인터페이스 제한이 확장 능력에 방해가 되어 논의 된 솔루션 중 어느 것도 귀하의 요구에 맞지 않는 경우에도이를 수행 할 수 있습니다.
이 백서에서는 이러한 솔루션을 설계하는 데 대한 자세한 내용은 설명하지 않지만 이러한 시나리오에서 더 나은 계획을 세우는 데 도움이 되는 몇 가지 주의 사항을 지적하고자 했습니다. 다음 다이어그램은 Amazon EC2에 고유 한 DNS 확인자가 있는 하이브리드 VPC DNS 설정에 대한 접근 방식을 보여줍니다.
보안상의 이유로 온-프레미스 연결이 필요한 조건부 전달자 인스턴스는 VPC의 프라이빗 서브넷에 별도로 배치하는 것이 좋습니다. 사용자 지정 DNS 확인자는 퍼블릭 DNS 서버를 쿼리 할 수 있어야하므로 자체 VPC의 퍼블릭 서브넷에서 실행됩니다.
이상적으로는 사용자 지정 DNS 확인자를 실행하는 EC2 인스턴스에 보안 그룹 규칙이 있지만 이 사용자 지정 DNS 확인자에게 인터넷에 대한 높은 쿼리 속도가 있는 경우 연결에서 설명한대로 연결 추적 제한에 도달 할 가능성이 있습니다 추적 섹션. 따라서 이러한 시나리오가 발생하지 않도록 하려면 연결 추적 자체를 피해야하며 인바운드 및 아웃 바운드 보안 그룹 수준에서 모든 포트, TCP 및 UDP를 전 세계에 열어서 그렇게 할 수 있습니다.
이는 인스턴스 수준 보안 그룹에 허용 규칙을 부여하므로 다른 계층에서 인스턴스의 보안을 처리해야합니다. 최소한 NACL (Network Access Control List)을 사용하여 전체 퍼블릭 서브넷으로 들어오는 트래픽을 제어하여 인스턴스에 대한 액세스를 제한하거나 DNS에서 제공하는 액세스 제어와 같은 응용 프로그램 수준 제어 메커니즘을 사용할 것을 권장합니다.
사용자 지정 DNS 확인자는 인터넷에서 평판 업스트림을 개발할 수 있습니다. 인스턴스에 다른 고객에게 속한 동적 퍼블릭 IP 주소가 할당되고 이전에 평판이 좋지 않은 경우 업스트림 요청이 제한되거나 차단 될 수 있습니다. 스로틀링 또는 차단을 피하려면 이러한 리졸버 인스턴스에 탄력적 IP 주소를 할당하십시오. 이를 통해 업스트림 서버와 통신하는 이러한 IP 주소를 통해 시간이 지남에 따라 소유 및 유지 관리 할 수 있습니다. 포트 53에서 TCP 및 UDP 리스너로 구성된 NLB (Network Load Balancer) 뒤에 있는 DNS 서버 집합을 사용하면 확장 문제가 완화 될 수 있습니다.
Microsoft Windows 인스턴스
일반적으로 Microsoft Windows 인스턴스는 AD DS (Active Directory 도메인 서비스)를 사용하여 연결됩니다. Linux 리졸버와 달리 Amazon VPC DHCP 옵션 세트를 사용하는 시나리오에서는 4 개의 DNS 서버 전체를 설정할 수 있습니다. 앞에서 설명한 대체 옵션과 유사한 DHCP 제공 IP 주소와 독립적으로 DNS 서버를 설정할 수 있습니다. 이는 Active Directory 그룹 정책을 사용하거나 앞에서 언급한 Amazon EC2 Run Command 또는 AWS OpsWorks for Chef Automate와 같은 구성 관리 도구를 통해 수행 할 수 있습니다. 또한 Windows DNS 클라이언트를 사용하면 최근에 해결 된 쿼리를 캐시 할 수 있으므로 기본 DNS 서버에 대한 전반적인 수요가 줄어 듭니다.
Windows DNS 클라이언트 서비스는 IP 주소 정보가 변경되면 DNS 서버에서 동적으로 업데이트하도록 프롬프트 됩니다. 메시지가 표시되면 DNS 서버는 RFC 2136에 따라 해당 컴퓨터의 호스트 레코드 IP 주소를 업데이트합니다.
Microsoft DNS는 동적 업데이트를 지원하며 모든 Active Directory 통합 DNS 영역에서 기본적으로 활성화됩니다. Windows 인스턴스에 대해 언 바운드와 같은 경량 포워더를 사용하는 경우 이러한 동적 업데이트가 지원되지 않으며 RFC 2126을 지원할 수 없습니다. 이를 수행하려면 Microsoft DNS 서버를 기본 서버로 사용해야합니다.
언 바운드 — 추가 옵션
언 바운드는 TTL (Time To Live)이 만료 될 때까지 후속 쿼리에 대한 결과를 캐시 한 후 요청을 전달합니다. 언 바운드에서 프리 페치 옵션을 사용하면 캐시를 최신 상태로 유지하기 위해 자주 사용되는 레코드가 만료되기 전에 프리 페치 되도록 할 수 있습니다. 또한 캐시가 만료 될 때 온-프레미스 DNS 서버를 사용할 수 없는 경우 언바운드는 SERVFAIL을 반환합니다. 이러한 상황으로부터 자신을 보호하기 위해 실제 만료가 완료 될 때까지 기다리지 않고 응답 만료 시 TTL이 0 인 캐시에서 이전 응답을 제공하도록 serve-expired 옵션을 활성화 할 수 있습니다. 해결이 완료된 후 후속 사용을 위해 응답이 캐시 됩니다.
DNS Forwarder — Forward First
일부 DNS 서버 (특히 BIND)에는 기본적으로 활성화 된 첫 번째 전달 옵션이 포함되어 있어 서버가 전달자를 먼저 쿼리하고 응답이 없으면 인터넷 DNS 서버를 재귀적으로 다시 시도합니다. 이 시나리오의 개인 DNS 도메인의 경우 인터넷 DNS 서버는 존재하지 않는 인터넷 또는 인트라넷 도메인 이름 인 신뢰할 수 있는 NXDOMAIN을 반환하거나 공용 영역에 대해 수평 분할 DNS를 사용하는 경우 공용 주소를 반환합니다. 개인 IP 주소와 공용 IP 주소에 서로 다른 답변을 제공했습니다. 따라서 전달자에 대해 재시도를 수행하도록 지정하는 전달 전용 옵션을 지정하는 것이 중요합니다. 즉, 공용 이름 서버의 응답을 보지 않아도 됩니다. 언 바운드 DNS 서버에는 기본적으로 전달 우선 옵션이 비활성화되어 있습니다.
DNS 서버 복원력
이 백서의 솔루션은 기본 DNS 서버에 문제가 있는 경우 고 가용성을 제공하기 위한 것입니다. 그러나이 장애 조치 발생을 방지하거나 지연시킬 수 있는 요소가 있습니다. 이러한 요인에는 resolv.conf의 시간 초과 값, 대체 된 DNS의 구성 문제 또는 잘못된 DHCP 옵션 설정이 포함됩니다. 경우에 따라 이러한 요소는 이름 확인에 의존하는 응용 프로그램의 가용성에 영향을 줄 수 있습니다. 기본 하드웨어 또는 인스턴스 소프트웨어에 문제가 있는 경우 전달자의 탄력성을 보장하는 몇 가지 간단한 접근 방법이 있습니다. 이러한 접근 방식으로 잘 설계된 설계가 필요하지 않지만 솔루션의 전반적인 복원력을 높일 수 있습니다.
EC2 인스턴스 복구
DNS 전달자 인스턴스의 기본 하드웨어 오류가 발생한 경우 EC2 인스턴스 복구를 사용하여 새 호스트에서 인스턴스를 시작할 수 있습니다. 복구 된 인스턴스는 인스턴스 ID, 프라이빗 IP 주소, 탄력적 IP 주소 및 모든 인스턴스 메타 데이터를 포함하여 원래 인스턴스와 동일합니다. 이를 위해 EC2 인스턴스를 모니터링하고 손상된 경우 자동으로 복구하는 CloudWatch 경보를 생성 할 수 있습니다. CloudWatch 경보를 사용하여 네트워크 연결 손실, 시스템 전원 손실, 물리적 호스트의 소프트웨어 문제 또는 물리적 도달 범위에 영향을 미치는 물리적 호스트의 하드웨어 문제와 같은 문제를 모니터링 할 수 있습니다.
인스턴스 복구에 대한 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서의 인스턴스 복구를 참조하십시오. CloudWatch 경보를 사용하여 인스턴스를 복구하는 방법에 대한 단계별 지침은 Linux 인스턴스용 Amazon EC2 사용 설명서의 인스턴스를 중지, 종료, 재부팅 또는 복구하는 경보 생성을 참조하십시오.
보조 IP 주소
Amazon VPC에서 인스턴스는 양도 가능한 보조 IP 주소를 할당 할 수 있습니다. 인스턴스가 실패하면 보조 IP를 대기 인스턴스로 전송할 수 있으므로 모든 인스턴스가 확인자 IP 주소를 다시 구성 할 필요가 없습니다. 이 방법은 트래픽을 정상적인 인스턴스로 리디렉션하여 DNS 쿼리에 응답 할 수 있도록 합니다. 이 방법은 EC2 인스턴스 복구가 충분히 빠른 복구를 제공하지 않거나 적절하지 않은 시나리오 (예 : 운영 체제 결함 또는 소프트웨어 문제)에 적합합니다. 멀티 IP 주소 작업에 대한 자세한 내용은 Linux 인스턴스 용 Amazon EC2 사용 설명서의 멀티 IP 주소를 참조하십시오.
결론
온 프레미스 리소스가 있는 조직의 경우 클라우드 채택 프로세스에서 하이브리드 아키텍처로 운영해야 합니다. 이러한 전환을 간소화하는 아키텍처 패턴은 성공에 필수적입니다.
여기에 제공된 솔루션의 기본 빌딩 블록에 대한 이해를 높이고 워크로드에 가장 적합한 솔루션을 만드는 데 도움이 되는 제한 사항에 대한 개념과 제한 사항에 대해 논의했습니다. 제공된 솔루션에는 조건부 전달 규칙과 함께 Route 53 Resolver 엔드 포인트를 사용하는 방법, AWS Lambda 및 Route 53 프라이빗 호스팅 영역을 사용하여 Amazon VPC에서 보조 DNS를 설정하는 방법 및 언 바운드 DNS 서버를 사용하여 분산 포워더를 활용하는 솔루션이 포함되었습니다. 또한 원하는 워크로드에 적합한 솔루션을 선택하는 방법에 대한 지침도 제공했습니다. 마지막으로 다양한 워크로드 요구 사항, 빠른 장애 조치 및 향상된 DNS 서버 복원력에 맞게 솔루션을보다 잘 조정하는 데 도움이 되는 몇 가지 추가 고려 사항을 검토했습니다.
제공된 아키텍처를 사용하면 온 프레미스 환경과 Amazon VPC간에 가장 이상적인 프라이빗 DNS 상호 운용성을 달성 할 수 있습니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
