SOA-C03 14/16 — DNS 라우팅과 콘텐츠 전달

정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.

1. 이름 해석과 실제 요청 전달을 나눈다

사용자가 URL을 열면 DNS는 이름에 대한 응답을 제공하고, 클라이언트는 그 결과를 사용해 연결한다. Route 53 routing policy는 DNS 응답을 선택한다. CloudFront는 HTTP 콘텐츠 전달과 cache에 관여하며, Global Accelerator는 지원 endpoint로 가는 네트워크 경로를 개선한다.

hostname 질의 → DNS 응답·client cache
                       ↓
              선택한 endpoint에 연결
                       ↓
       edge / accelerator / load balancer
                       ↓
                  origin·application

이 층을 분리하면 “DNS 변경 완료”, “새 endpoint 연결”, “정상 콘텐츠 수신”을 각각 검증할 수 있다. DNS가 기대한 주소를 반환해도 TLS 인증서와 backend가 틀리면 요청은 실패한다.

2. Hosted zone·record·위임을 연결한다

Public hosted zone에 record를 생성했다고 인터넷의 resolver가 그 zone을 바로 사용하는 것은 아니다. 도메인의 위임 경로가 올바른 authoritative name server를 가리켜야 한다. 같은 이름의 zone이 여러 개라면 실제 위임된 zone과 수정한 zone을 구분한다.

구성	의미
A	IPv4 주소 응답
AAAA	IPv6 주소 응답
CNAME	다른 DNS 이름으로 연결
Route 53 alias	지원 AWS 대상 등에 연결하는 Route 53 기능
TTL	resolver가 응답을 재사용할 시간에 영향

CNAME은 zone apex에 만들 수 없지만 Route 53 alias는 지원 대상에 대해 apex에서도 사용할 수 있다. Alias가 모든 임의 도메인의 CNAME 대체물은 아니다. Record types와 alias

Private hosted zone은 연결된 VPC 등의 정해진 DNS 해석 경로에서 사용하는 기록이다. 같은 이름이라도 외부와 내부가 다른 결과를 얻을 수 있다. 내부 record를 만들었다고 인터넷에서 해석되거나 네트워크 접근이 허용되는 것은 아니다. Private hosted zones

3. Resolver endpoint의 방향은 DNS query 기준이다

현재 문서의 Route 53 VPC Resolver는 계획의 Route 53 Resolver에 해당하는 VPC의 DNS 해석 기능이다. Public name, VPC 전용 이름, private hosted zone 등의 질의를 처리한다.

Inbound endpoint: 온프레미스 등에서 VPC 쪽 이름을 해석하도록 질의를 받는다.
Outbound endpoint: VPC 쪽 질의를 온프레미스 등의 resolver로 보낸다.
Forwarding rule: 어떤 domain의 질의를 어느 DNS 서버로 보낼지 정하고 VPC와 연결한다.

Resolver

예를 들어 VPC의 앱이 사내 DNS가 관리하는 corp.example 이름을 찾으면 해당 domain의 forwarding rule과 outbound endpoint를 사용한다. 반대로 사내 앱이 AWS private zone을 찾으려면 사내 DNS가 inbound endpoint로 질의를 전달하는 경로를 확인한다.

Endpoint 주소까지의 VPN·Direct Connect 등 연결, route, SG·NACL과 DNS의 UDP/TCP 요구를 함께 본다. DNS 질의가 성공해도 반환된 애플리케이션 IP까지의 경로가 없으면 실제 접속은 실패한다. 양쪽에서 같은 suffix를 서로에게 계속 전달하는 forwarding loop도 피한다.

4. Routing policy는 요구사항의 차이로 선택한다

정책	선택 기준	주의할 해석
Simple	단순한 단일 기능의 대상	health 기반 failover 정책과 구분
Weighted	지정 비율로 DNS 응답 선택	개별 HTTP 요청의 정확한 비율 보장 아님
Latency	적합한 지연의 Region 선택	지리적으로 가장 가까운 위치와 같지 않음
Failover	active·passive 전환	health·TTL·기존 연결 고려
Geolocation	사용자 위치 기준 응답	latency 최적화와 다른 요구
Geoproximity	자원 위치와 bias로 영역 조절	단순 국가별 매핑과 다름
IP-based	출발 IP 대역에 따른 응답	CIDR·사용자 위치 정보 관리 필요
Multivalue answer	여러 healthy record 응답	ELB의 연결 관리 대체 아님

Routing policies

Weighted 90:10을 적용해도 resolver cache와 재사용된 연결 때문에 앱 로그의 요청 비율이 즉시 정확히 90:10이 되지는 않는다. 낮은 TTL은 변경 반영을 돕지만 이미 cache된 응답의 남은 수명을 소급해서 없애지 못한다.

Health check는 실제 고객 기능을 대표하는지 확인한다. DNS가 standby를 알려 주더라도 standby의 데이터·용량·권한이 준비되지 않았다면 서비스 복구는 실패다. 06의 endpoint health와 07의 복구 준비를 같이 적용한다.

5. DNS 로그는 관찰 위치를 표시한다

Public DNS query logging은 Route 53 authoritative 측에 도착한 질의를 기록한다. Recursive resolver가 cache로 답한 요청까지 전부 보이는 것은 아니다. 따라서 DNS 로그 수를 웹 방문 수나 API 요청 수로 계산하지 않는다. Public query log의 CloudWatch Logs 위치에는 US East (N. Virginia) 조건이 있다. Public query logging

Resolver query logging은 VPC의 Resolver 경계에서 domain·type·응답·원천 같은 정보를 조사하는 데 사용한다. 수집 설정과 연결 VPC, destination·권한을 확인하며 cache 때문에 기록되지 않는 질의가 있을 수 있음을 고려한다. Resolver query logging

같은 hostname이 외부에서는 정상이고 VPC 안에서만 실패한다면 public zone만 반복 수정하지 않는다. Private zone, forwarding rule, DNS Firewall, 질의가 도착하는 resolver를 비교한다.

6. CloudFront cache key는 같은 응답을 재사용할 기준이다

Cache behavior는 요청 path 등에 따라 origin과 처리 정책을 선택한다. Cache policy는 어떤 header·cookie·query string을 cache key에 포함할지와 TTL 관련 설정을 정의한다. Cache key

예를 들어 언어별 페이지가 query string lang에 따라 달라지는데 lang을 key에서 빼면 서로 다른 언어 응답을 같은 객체로 취급할 수 있다. 반대로 결과에 영향이 없는 추적용 query를 모두 넣으면 불필요한 cache 변형이 늘어 hit rate가 떨어질 수 있다.

Origin request policy는 cache key에 추가하지 않고도 필요한 정보를 origin에 전달할 수 있다. 그러나 origin에 전달한다는 사실과 응답을 그 값별로 격리한다는 사실은 다르다. 사용자별 응답에서는 인증·cache key·cache 비활성화 요구를 함께 결정한다. Origin request policy

TTL은 cache policy와 origin의 Cache-Control·Expires 관계로 읽는다. Minimum TTL이 양수이면 origin의 no-cache·no-store·private보다 우선해 일정 시간 cache될 수 있으므로 민감 응답의 정책을 별도로 검토한다. Expiration

새 정적 파일을 배포할 때 version을 포함한 이름을 쓰면 새 URL이 새 객체를 가리킨다. 같은 URL의 기존 CloudFront 객체를 제거하려면 invalidation을 사용할 수 있다. Invalidation으로 브라우저나 사내 proxy의 모든 cache까지 제거되는 것은 아니다. Invalidation과 versioned filenames

7. Global Accelerator와 CloudFront의 선택 경계

Global Accelerator는 static anycast IP와 AWS 글로벌 네트워크를 이용해 지원 endpoint로 트래픽을 보낸다. Standard accelerator의 listener·endpoint group·health와 트래픽 제어를 연결한다. HTTP 객체를 cache하는 CDN과 목적이 다르다. Global Accelerator

요구	중심 후보
웹 객체를 edge에서 재사용·origin 부하 감소	CloudFront
DNS 응답을 Region·health·비율로 선택	Route 53
고정 anycast IP·TCP/UDP 애플리케이션 경로 개선	Global Accelerator

서비스는 요구에 따라 조합할 수 있다. 어느 하나를 쓰면 DNS·TLS·origin의 정상 상태가 자동으로 보장되는 것은 아니다. 지원 endpoint와 protocol, Region, 실제 비용은 구성 시점 문서로 확인한다.

8. 완성된 운영 적용 — 새 배포가 일부 사용자에게만 안 보인다

사용자가 해석한 DNS 결과와 실제 연결 endpoint를 확인한다.
새 DNS record가 authoritative zone에 있고 resolver cache가 남았는지 본다.
CloudFront distribution·behavior·origin이 기대한 대상으로 연결되는지 확인한다.
같은 URL의 cache hit·Age·응답 헤더와 origin의 실제 파일 version을 비교한다.
Cache key에 콘텐츠를 나누는 값이 포함됐는지 확인한다.
새 version URL 또는 필요한 invalidation을 적용하고 여러 경로에서 응답을 검증한다.
고객 오류·origin 부하·cache 효율을 확인한다.

이 사례에서 origin 배포 성공, DNS 변경, edge 반영, client 수신은 각각 다른 증거다. 시험에서는 이름 해석·라우팅·배포 기능을 요구에 연결하고, 운영에서는 각 관찰 경계의 결과를 확인한다. 범위: Domain 5 Task 5.2.

계획과 연결

ID: 14-dns-routing-and-content-delivery
의존: 13-vpc-connectivity-protection-and-cost
결정 축: 이름 해석, DNS routing policy, endpoint health, edge caching과 anycast 경로를 요구사항에 맞게 분리한다.
범위: Route 53 Resolver, Route 53 routing policies·configuration·query logging, CloudFront, Global Accelerator.
시험 매핑: Domain 5, Task 5.2.
학습 안내
전체 계획

DanzzaN

탐색기