#개발 #기술블로그 #백엔드 #인프라 #AWS #Route53 ![](https://d2908q01vomqb2.cloudfront.net/7b52009b64fd0a2a49e6d8a939753077792b0554/2025/12/03/Route-53-Resolver-1.png) AWS에서 도메인을 붙일 때 Route53은 거의 기본처럼 사용된다. EC2 띄우고, 도메인 연결하고, 브라우저에서 접속되면 일단 끝난다. 문제는 여기까지가 전부 "작동은 하는데 이해는 못한 상태^^"라는 점이다 😅 여러 프로젝트를 하면서 딱히 Route53을 제대로 이해한 적은 없었다... 쓴 횟수는 10번이 넘어가는 것 같은데... 그래서 이번 주차 스터디에는 VPC + DNS 관련 서비스 중 Route53을 다뤄보려고 한다! --- ## Route53은 DNS 이상의 트래픽 제어 레이어 Route53은 기본적으로 DNS 서비스다. 즉, 도메인 이름을 IP 주소로 변환해준다. 하지만 실제로 써보면 단순 변환 이상의 역할을 한다. - 어떤 서버로 트래픽을 보낼지 결정 - 여러 서버 중 어디로 보낼지 분산 - 장애가 발생했을 때 우회 즉, 단순 네임서버가 아니라 **트래픽을 제어하는 레이어**에 가깝다. ## 내가 했던 작업을 다시 보면 Route53을 사용할 때 했던 작업은 결국 이것이다. - 도메인 등록 or 연결 - Hosted Zone 생성 - 레코드 추가 (A 레코드) - EC2 IP 연결 이걸 당시에는 “도메인 붙이기”라고 생각했는데, 사실은 DNS 레코드를 직접 구성하고 있었던 것이다. 특히 Hosted Zone은 그냥 메뉴 하나가 아니라 “도메인에 대한 모든 라우팅 규칙이 모여있는 공간”이다. ## DNS 요청은 생각보다 복잡하게 흐른다 도메인을 입력하면 바로 서버로 가는 게 아니다. 요청 흐름은 대략 다음과 같다. - 사용자가 도메인 입력 - DNS 서버에 IP 요청 - 여러 DNS 계층을 거쳐 IP를 찾음 - 해당 IP로 HTTP 요청 이 과정에서 Route53은 **최종적으로 IP를 알려주는 역할**을 한다. 즉, Route53은 서버가 아니라 “서버 위치를 알려주는 시스템”이다. ## 레코드 설정이 곧 서비스 구조다 Route53을 제대로 이해하려면 레코드 개념이 중요하다. 레코드는 “이 도메인으로 들어온 요청을 어디로 보낼지” 정의한다. 예를 들어: - A 레코드 → EC2 IP로 연결 - CNAME → 다른 도메인으로 연결 - Alias → AWS 리소스로 연결 이걸 단순 설정이라고 생각하면 안 된다. 이건 곧, 사용자의 요청을 어디로 보낼지 결정하는 로직이다. ## 라우팅 정책 = 그냥 옵션이 아니라 설계다 처음에는 라우팅 정책을 거의 건드리지 않는다. 하지만 옵션을 보면 다음과 같은 것들이 있다. - 가중치 기반 - 지연 시간 기반 - 장애 조치 - 지리적 라우팅 Route53은 단순 DNS가 아니라 **트래픽 분산 전략을 정의하는 도구**기에, 비즈니스 로직과 인프라 설계를 생각하면서 설정해야 한다... ## 비용 구조도 생각보다 중요하다 그리고 매번 돈 나갈 때마다 깨닫지만... Route53은 무료가 아니다.... - Hosted Zone 생성 시 비용 발생 - DNS 조회(Query)마다 비용 발생 즉, 사용자가 도메인으로 접속할 때마다 DNS 요청이 발생하고 비용이 쌓인다. 규모가 커지면 이 부분도 고려해야 한다... ++ 더 공부해볼 것 [AWS 한국 블로그 - Route53 카테고리](https://aws.amazon.com/ko/blogs/korea/category/networking-content-delivery/amazon-route-53/)에서 더 확인해보자~