Amazon ANS-C01: DNS 및 Route 53 — 학습 가이드

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Advanced Networking Specialty ANS-C01 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

핵심 개념

DNS는 사람이 읽기 쉬운 이름과 분산된 엔드포인트를 연결하는 접착제 역할을 하지만, AWS에서는 지연 시간 기반 라우팅, 상태 인식 장애 조치, 다중 계정 프라이빗 이름 확인을 위한 능동적인 제어 플레인이 됩니다. Amazon Route 53은 퍼블릭 호스팅 영역을 통해 신뢰할 수 있는(authoritative) 퍼블릭 DNS를, 프라이빗 호스팅 영역을 통해 VPC 범위의 확인을 위한 프라이빗 DNS를 지원합니다. 프라이빗 호스팅 영역은 하나 이상의 VPC와 연결되며, 해당 VPC 또는 Route 53 Resolver 인바운드 엔드포인트를 통해 시작된 쿼리에 대해서만 응답을 반환합니다. 이러한 스플릿 호라이즌(split-horizon) 동작(소스에 따라 동일한 이름에 대해 다른 응답을 갖는 것)을 통해 VPC 내에서는 동일한 이름을 프라이빗 IP로 확인하면서 인터넷 클라이언트에게는 퍼블릭 엔드포인트를 노출할 수 있습니다.

Route 53은 또한 라우팅 결정 로직과 능동적인 상태 확인을 DNS에 통합합니다. 라우팅 정책에는 Simple, Weighted, Latency, Failover(기본/보조), Geolocation, Multi-Value Answer, Traffic Flow(지리 근접성 및 복잡한 흐름)가 포함됩니다. CreateHealthCheck로 생성된 상태 확인을 통해 Route 53은 DNS 응답에서 비정상 엔드포인트를 제거하거나 장애 조치 레코드 세트를 구동할 수 있습니다. 상태 확인은 HealthCheckConfig 필드(예: Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval, FailureThreshold)로 구성할 수 있습니다. DNS는 리졸버와 클라이언트에 의해 캐시되므로, Route 53의 TTL과 빈번한 상태 확인 폴링(특정 설정 하에서 최소 10초)은 장애 조치 및 가중치 라우팅 변경에 대한 DNS 전파 동작과 균형을 이루어야 합니다.

주요 서비스 및 구성

AWS 리소스를 노출할 때는 지원되는 경우 별칭(Alias) 레코드를 사용하여 DNS가 AWS 리소스를 직접 가리키도록 하여 추가적인 홉이나 CNAME을 피해야 합니다. 별칭 레코드는 AWS 리소스의 호스팅 영역 ID와 DNS 이름(예: Elastic Load Balancer, API Gateway 사용자 지정 도메인, CloudFront 배포 또는 S3 웹사이트 엔드포인트)을 참조하는 AliasTarget을 사용합니다. 레코드 생성 또는 변경은 ChangeResourceRecordSets API를 통해 수행됩니다. 프로그래밍 방식의 워크플로우에서는 UPSERT/DELETE 작업과 라우팅 정책 식별을 위한 SetIdentifier와 함께 ChangeBatch를 사용합니다. 장애 조치를 위해서는 동일한 이름으로 두 개의 레코드를 생성하고 Failover를 PRIMARY 및 SECONDARY로 설정하며, 각 레코드는 CreateHealthCheck로 생성한 상태 확인을 HealthCheckId를 통해 참조합니다.

계정 간 및 하이브리드 DNS 확인을 위해 Route 53 Resolver는 CreateResolverEndpoint로 생성된 인바운드 및 아웃바운드 엔드포인트를 제공합니다. 인바운드 엔드포인트는 온프레미스 리졸버가 VPC로 쿼리를 전달할 수 있게 해주며(프라이빗 호스팅 영역을 확인하는 데 유용함), 아웃바운드 엔드포인트는 VPC 리소스가 온프레미스 DNS 서버나 다른 리졸버로 쿼리를 전달할 수 있게 합니다. Resolver 규칙(CreateResolverRule)을 사용하면 특정 도메인에 대한 쿼리를 IP 주소로 전달할 수 있으며, AssociateResolverRule을 사용하여 규칙을 VPC에 연결합니다. 중앙 DNS 아키텍처의 경우, 중앙 계정에 전달 규칙을 생성하고 다른 계정의 VPC와 AssociateResolverRule을 사용할 수 있으며, 선택적으로 AWS Resource Access Manager(RAM)와 PutResolverRulePolicy를 사용하여 연결을 제어할 수 있습니다.

Route 53 Resolver DNS Firewall은 도메인 기반 필터링 및 로깅을 제공합니다. CreateFirewallDomainList로 도메인 목록을, CreateFirewallRuleGroup으로 규칙 그룹을 생성한 다음, AssociateFirewallRuleGroup을 VPC에 연결하여 규칙을 적용합니다. 방화벽 규칙은 응답을 BLOCK, ALLOW 또는 OVERWRITE 할 수 있으며, 평가 결과를 CloudWatch Logs나 S3에 기록할 수 있습니다. CreateFirewallRule 및 PutFirewallRuleGroupPolicy를 사용하여 관리하고 우선순위가 지정된 규칙을 적용하며, 특히 DNS를 통한 데이터 유출을 제한하거나 VPC에 연결된 리소스에서 악성 도메인을 차단하는 데 사용합니다.

설계 패턴 및 트레이드오프

고가용성의 전역적으로 분산된 서비스의 경우, 지연 시간 기반 또는 지역 기반 라우팅을 사용하여 클라이언트를 가장 가까운 정상 엔드포인트로 안내하고, 상태 확인과 함께 사용하여 비정상적인 리전 엔드포인트를 제거합니다. 지연 시간 라우팅은 Route 53의 리전별 지연 시간 테이블에 의존하며 다중 리전 액티브-액티브 설계에 적합합니다. 장애 조치 라우팅은 한 번에 하나의 리전만 트래픽을 받아야 하는 액티브-패시브 재해 복구에 더 적합합니다. 가중치 라우팅은 레코드에 가중치 값을 할당하고 ChangeResourceRecordSets로 이를 변경하여 점진적인 트래픽 전환(블루-그린 또는 카나리 배포)을 지원합니다. 다중 값 응답 라우팅은 클라이언트 측 부하 분산을 위해 여러 IP를 반환할 수 있으며, 정상적인 IP만 반환되도록 상태 확인이 필요합니다.

프라이빗 호스팅 영역과 리졸버 엔드포인트는 다중 계정, 다중 VPC 이름 확인을 위한 표준 패턴입니다. 많은 사업부의 경우, 프라이빗 호스팅 영역이나 리졸버 엔드포인트를 호스팅하는 중앙 공유 서비스 VPC가 관리를 단순화합니다. 프라이빗 호스팅 영역을 생성하고 AssociateVPCWithHostedZone을 사용하여 서비스 VPC들을 연결하거나, Route 53 Resolver 아웃바운드/인바운드 엔드포인트와 전달 규칙을 실행하여 각 계정이 중앙 DNS 정책에 의존하면서도 VPC 격리를 유지하도록 할 수 있습니다. 단점은 많은 VPC와 연결된 프라이빗 호스팅 영역이 IAM 및 변경 제어를 복잡하게 만들고, 계정 간 연결에는 승인 단계가 필요하다는 것입니다. 리졸버 전달은 중앙 운영 오버헤드를 발생시키지만, 모든 VPC를 모든 호스팅 영역에 직접 연결할 필요 없이 리졸버 규칙을 연결하므로 확장성이 좋습니다.

엄격한 액세스 경로(예: 트래픽이 Global Accelerator를 통해서만 흐르도록 요구)를 강제할 때는 보안 그룹과 네트워크 제어를 DNS와 일치하도록 설계해야 합니다. Route 53은 가속기의 고정 IP 주소로 A 레코드를 생성하거나 가속기가 관리하는 도메인에 CNAME을 사용하여 Global Accelerator를 가리킬 수 있지만, 강제 적용은 ALB 보안 그룹 및 네트워크 ACL 계층에서 수행됩니다. ALB 보안 그룹은 Global Accelerator 고정 IP 주소로부터의 인그레스만 허용해야 합니다. Global Accelerator는 해당 고정 IP가 들어오는 트래픽의 소스가 될 것을 보장하므로, 인그레스를 제한하면 ‘가속기를 통해서만 액세스’라는 요구 사항이 유지됩니다.

일반적인 함정과 결정 기준

흔한 함정 중 하나는 Route 53 상태 확인이 엔드포인트를 즉시 제거한다고 가정하는 것입니다. DNS 캐싱(TTL)과 클라이언트 리졸버 동작으로 인해 장애 조치가 즉각적으로 이루어지지는 않습니다. 중요한 장애 조치 이름에는 TTL을 낮게 유지하되, TTL이 낮을수록 쿼리 볼륨과 비용이 증가한다는 점을 기억해야 합니다. 또 다른 흔한 실수는 VPC 연결을 이해하지 못한 채 퍼블릭 및 프라이빗 호스팅 영역에 걸쳐 이름을 중복으로 사용하는 것입니다. 퍼블릭 호스팅 영역과 이름이 같은 프라이빗 호스팅 영역은 연결된 VPC에서 시작된 쿼리에 대해 퍼블릭 응답을 가리게(shadow) 되는데, 이는 일반적으로 스플릿 호라이즌(split-horizon)에 바람직하지만 문서화되지 않았다면 예상치 못한 결과를 초래할 수 있습니다.

별칭(Alias) 레코드와 CNAME 레코드 중에서 신중하게 선택해야 합니다. ELB 및 CloudFront에 대한 별칭 레코드는 추가적인 DNS 조회를 피하고 Route 53의 변경 전파 로직에 의해 지원되므로 선호됩니다. 하지만 이는 AWS 리소스 호스팅 영역 ID에 연결되어 있으며 임의의 외부 엔드포인트에는 사용할 수 없습니다. 교차 계정 DNS를 설계할 때, 규모나 관리 경계가 우려되는 경우 많은 VPC를 단일 프라이빗 호스팅 영역에 직접 연결하는 것보다 리졸버 규칙과 엔드포인트를 사용하는 것이 좋습니다. 리졸버 규칙은 더 세분화된 제어를 제공하며 CloudTrail로 감사하기가 더 쉽습니다.

실제 문제: 사용 사례 시나리오

회사: NimbusPay — 과제: 상호 TLS를 사용하는 TLS 기반의 안전하고 지연 시간이 짧은 gRPC 서비스를 EKS 백엔드에 제공하고, 웹 프런트엔드에 대한 액세스는 Global Accelerator를 통해서만 가능하도록 강제하며, 여러 계정에 걸친 여러 사업부 VPC가 중앙 집중식 DNS 제어를 통해 공유 데이터 서비스를 사용할 수 있도록 허용합니다.

상호 인증을 통한 종단 간 TLS와 수천 개의 동시 연결이 필요한 gRPC 서비스의 경우, 대상 유형을 ip로 사용하는 포트 443의 TCP 리스너를 갖춘 Network Load Balancer(NLB)를 배포하여 파드(pod) IP가 직접 등록되도록 합니다. AWS Load Balancer Controller 어노테이션 service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"를 구성하고 대상 그룹 프로토콜을 TCP로 설정합니다. NLB에서 TLS를 종료하지 않도록(TLS 리스너 없음) 하여 상호 TLS가 파드 컨테이너로 전달되고, 여기서 서버 인증서 및 클라이언트 인증서 확인이 강제되도록 합니다. ChangeResourceRecordSets를 통해 NLB를 가리키는 Route 53 A 레코드(별칭)를 사용합니다. 신속한 장애 조치가 필요한 경우에만 낮은 TTL을 선호하고, 그렇지 않으면 DNS 안정성을 위해 보수적인 TTL을 유지합니다.
웹 프런트엔드 ALB가 Global Accelerator로부터의 트래픽만 수락하도록 보장하기 위해, 액셀러레이터를 프로비저닝하고 두 개의 고정 IP 주소를 NimbusPay에 할당합니다. 퍼블릭 이름을 액셀러레이터 IP로 확인하도록 Route 53 퍼블릭 레코드를 구성합니다(고정 IP를 사용하는 A 레코드). ALB에서는 보안 그룹 인그레스 규칙을 설정하여 해당 고정 IP 주소만 허용하고 0.0.0.0/0은 차단합니다. 이는 액셀러레이터 고정 IP에서 오는 트래픽만 ALB에 도달할 수 있도록 강제합니다. CloudWatch Logs와 VPC Flow Logs를 사용하여 수신 소스 IP를 검증하고 액셀러레이터를 통하지 않는 트래픽이 차단되는지 감사합니다.
여러 계정에 걸쳐 있는 여러 사업부 VPC가 공유 서비스에 액세스해야 하는 경우, 공유 서비스 계정에 CreateResolverEndpoint를 사용하여 중앙 Route 53 Resolver 아웃바운드/인바운드 엔드포인트 쌍을 배포하고 엔드포인트를 프라이빗 서브넷에 배치합니다. 공유 계정에서 공유 서비스 도메인에 대한 전달 규칙(CreateResolverRule)을 생성하고, AWS RAM을 사용하여 규칙을 공유하거나 PutResolverRulePolicy를 사용하여 연결을 허용합니다. 각 사업부는 리졸버 규칙을 자신의 VPC에 연결(AssociateResolverRule)하여, 모든 VPC를 프라이빗 호스팅 영역에 직접 연결하지 않고도 이름 확인을 활성화합니다. 민감한 제어를 위해, Route 53 Resolver DNS Firewall 규칙 그룹(CreateFirewallRuleGroup 및 AssociateFirewallRuleGroup)을 공유 VPC에 연결하여 원치 않는 데이터 유출을 차단하거나 도메인 허용 목록을 강제합니다. 근거: NLB TCP 패스스루는 상호 TLS를 보존하고 많은 동시 연결로 확장되며, ALB 인그레스를 Global Accelerator 고정 IP로 제한하면 액셀러레이터를 통해서만 액세스하도록 강제합니다. 또한 중앙에서 관리되는 규칙이 있는 리졸버 엔드포인트는 계정별 IAM 경계와 감사를 보존하면서 계정 간 DNS 확인을 확장합니다.