상세 컨텐츠

본문 제목

AWS - DNS, Route 53

클라우드

by myeongjaechoi 2025. 10. 19. 19:38

본문

1️⃣ DNS란?

  • Domain Name System
  • 사람이 읽기 쉬운 도메인 이름 → IP 주소로 변환
  • 예:
    www.google.com → 142.250.xxx.xxx
  • 인터넷의 전화번호부 역할

2️⃣ DNS의 계층 구조

  • 루트 도메인 (.)
  • TLD (Top-Level Domain): .com, .org, .gov, .kr
  • 2단계 도메인 (Second-Level Domain): google.com, amazon.com
  • 서브 도메인 (Subdomain): www.google.com, api.example.com
  • FQDN (Fully Qualified Domain Name): 전체 도메인 이름
    예: api.www.example.com.
    • 마지막 “.” → 루트 도메인

3️⃣ DNS 주요 용어

용어설명
Registrar (레지스트라) 도메인을 등록하는 기관 (GoDaddy, Route 53 등)
Zone File (존 파일) 모든 DNS 레코드가 저장된 파일
Name Server (이름 서버) DNS 쿼리를 실제로 해결하는 서버
DNS Record 도메인과 IP, 또는 별칭 간의 매핑 정보
ㆍA Record 도메인 → IPv4 주소
ㆍAAAA Record 도메인 → IPv6 주소
ㆍCNAME 도메인 별칭(alias)
ㆍNS Record 네임 서버 정보

4️⃣ DNS 동작 원리

  1. 사용자가 브라우저에 example.com 입력
  2. 로컬 DNS 서버에 “example.com 아세요?” 질의
  3. 로컬 DNS 서버가 모를 경우 → 루트 DNS 서버에 요청
    • 루트 서버: “몰라요, 하지만 .com은 알아요. 여기 IP(1.2.3.4)로 가세요.”
  4. .com 네임서버에 질의
    • “example.com 아세요?”
    • 응답: “example.com은 몰라요, 하지만 그 서버는 5.6.7.8에 있어요.”
  5. example.com 네임서버(레지스트라 or Route 53)에 질의
    • 응답: “A 레코드 있어요. IP는 9.10.11.12입니다.”
  6. 로컬 DNS 서버는 이 IP를 캐싱
  7. 브라우저에 IP 전달 → 웹 서버에 접속 성공 ✅

5️⃣ 요약

  • DNS = 도메인 이름 → IP 주소 변환 시스템
  • 루트 → TLD → 도메인 → 서브도메인 순으로 탐색
  • 로컬 DNS 서버는 캐싱을 통해 성능 향상
  • 인터넷 접속 시 항상 DNS가 백그라운드에서 동작
  • 이 지식은 AWS Route 53 이해를 위한 필수 배경

1️⃣ 개요

  • Route 53:
    고가용성(High Availability), 확장성(Scalability), 완전 관리형(Managed), 권한 있는(Authoritative) DNS 서비스
  • Authoritative란?
    → 사용자가 직접 DNS 레코드를 생성·수정·삭제할 수 있다는 뜻
  • DNS 기반의 트래픽 라우팅을 완벽히 제어 가능

2️⃣ 기본 동작 예시

  • 클라이언트가 example.com 접근 시
    → Route 53 호스팅 존(Hosted Zone) 내의 레코드를 참조
    → 해당 도메인의 IP(54.22.33.44)를 반환
    → 클라이언트는 EC2 인스턴스로 접속

3️⃣ Route 53의 특징

항목설명
레지스트라 역할 도메인 등록 가능 (example.com 등)
100% SLA 가용성 AWS 서비스 중 유일
DNS 포트 번호 ‘53’ → Route 53 이름의 유래
리소스 상태 확인 가능 DNS Health Check 기능 지원
유료 서비스 호스팅 존당 월 0.50달러, 도메인 등록 연 12달러 정도

4️⃣ 주요 DNS Record 유형

레코드설명예시
A Record 도메인 → IPv4 주소 매핑 example.com → 1.2.3.4
AAAA Record 도메인 → IPv6 주소 매핑 example.com → 2400:cb00::1234
CNAME Record 도메인 → 다른 도메인(alias) 매핑 www.example.com → example.com
NS Record 네임 서버 정보 포함 ns-123.awsdns-45.com

📌 주의:

  • Zone Apex(최상위 도메인, 예: example.com)에는 CNAME 불가
  • 대신 서브도메인(www.example.com)에는 CNAME 사용 가능

5️⃣ 호스팅 존(Hosted Zone)

  • DNS 레코드의 컨테이너
  • 도메인/서브도메인의 트래픽 라우팅 방식 정의

🔹 퍼블릭 호스팅 존

  • 외부 인터넷 클라이언트의 DNS 쿼리에 응답
  • 예: application1.mypublicdomain.com → 54.22.33.44
  • 모든 사용자 접근 가능

🔹 프라이빗 호스팅 존

  • VPC 내부 전용 DNS
  • 사내 내부망용 URL을 리졸브 (company.internal, db.example.internal)
  • 외부에서는 접근 불가
  • 예:
    • webapp.example.internal → 10.0.0.10
    • db.example.internal → 10.0.0.20

6️⃣ 요약

  • Route 53 = AWS의 완전관리형 권한 있는 DNS 서비스
  • 100% SLA, 도메인 등록 + 레코드 관리 + 트래픽 라우팅 가능
  • 주요 레코드: A / AAAA / CNAME / NS
  • 퍼블릭 존: 전 세계 접근 가능
  • 프라이빗 존: VPC 내부 전용
  • 유료 서비스 (도메인/호스팅존별 과금)
  • 이름의 유래: DNS 포트 53번 사용

1️⃣ TTL이란?

  • TTL(Time To Live):
    DNS 레코드가 **클라이언트(혹은 리졸버)**의 캐시에 저장되어 있는 유효 시간(초 단위)
  • DNS 응답에는 항상 A 레코드, IP 주소, 그리고 TTL 값이 포함됨
  • 예:→ 300초 동안 클라이언트는 이 정보를 캐시
  •  
    myapp.example.com → IP: 54.22.33.44, TTL: 300초

2️⃣ TTL 동작 원리

  1. 클라이언트가 myapp.example.com을 요청
  2. Route 53이 IP와 TTL(예: 300초)을 함께 반환
  3. 클라이언트는 300초 동안 DNS를 다시 조회하지 않음
  4. 같은 도메인 요청 시 캐시에 저장된 IP를 사용
  5. TTL이 만료되면 → 새 DNS 쿼리 발생

📌 효과:

  • DNS 요청 횟수 ↓
  • 응답 속도 ↑
  • 서버 부하 ↓

3️⃣ TTL 설정의 트레이드오프

TTL 설정장점단점
긴 TTL (예: 24시간) Route 53 트래픽 감소, 비용 절감 변경 반영 느림 (오래된 IP 유지 가능성)
짧은 TTL (예: 60초) 빠른 변경 반영 쿼리 트래픽 증가, 비용 상승

💡 운용 전략

  • 변경 전에는 TTL을 짧게 줄여서 빠르게 반영
  • 안정화 후에는 TTL을 다시 길게 늘려서 비용 절감

4️⃣ TTL 실습 (요약)

  • A 레코드 생성:
  •  
    demo.stephanetheteacher.com → EC2 인스턴스 IP TTL = 120초 (2분)
  • nslookup / dig 명령으로 확인 가능:→ TTL이 115초 남았다는 의미
  •  
    dig demo.stephanetheteacher.com ;; ANSWER SECTION: demo.stephanetheteacher.com. 115 IN A 54.22.33.44
  • TTL이 줄어드는 동안은 캐시된 IP로 계속 연결
  • TTL 만료 후, 새 DNS 쿼리 발생 → 새 IP로 갱신됨

5️⃣ TTL 실습 시나리오 예시

  1. 초기 레코드: eu-central-1 인스턴스 IP
  2. TTL 120초 동안은 캐시에 저장 → 여전히 eu-central-1 응답
  3. 120초 후 TTL 만료
  4. DNS가 새 IP(ap-southeast-1)를 반환 → 새 서버로 트래픽 이동

6️⃣ 요약 정리

  • TTL은 DNS 캐싱 수명(time limit)
  • 짧게 설정 → 빠른 변경 반영
  • 길게 설정 → 비용 절감 & 서버 부하 완화
  • 모든 레코드에 TTL 존재 (단, 별칭 레코드 Alias 제외)
  • TTL 값은 dig, nslookup으로 직접 확인 가능

💬 핵심 문장 요약:
“TTL은 DNS 캐시의 유효 시간이다. 짧게 설정하면 변경 반영이 빠르지만 비용이 늘고, 길게 설정하면 안정적이지만 갱신이 느리다.”

1. CNAME 레코드란?

Canonical Name Record의 약자로,
하나의 도메인 이름을 다른 도메인 이름으로 매핑할 때 사용합니다.

✅ 예시

 
app.mydomain.com → myapp.elb.amazonaws.com
  • 즉, app.mydomain.com을 입력하면 myapp.elb.amazonaws.com으로 이동합니다.
  • CNAME은 IP가 아니라 다른 도메인 이름으로 향해야 합니다.
  • 단, **루트 도메인(apex domain)**에는 사용할 수 없습니다.
    • ❌ mydomain.com → CNAME 설정 불가
    • ✅ www.mydomain.com, api.mydomain.com → 가능

🌟 2. 별칭(Alias) 레코드란?

Route 53 전용 확장 기능으로,
CNAME처럼 도메인 이름을 다른 리소스로 연결하지만,
AWS 리소스(ALB, CloudFront, API Gateway 등) 에 직접 매핑할 수 있습니다.

✅ 특징

항목CNAMEAlias
대상 다른 도메인 이름 AWS 리소스
루트 도메인 사용 ❌ 불가 ✅ 가능
비용 유료(쿼리당 요금 발생) ✅ 무료
TTL 설정 직접 설정 자동 관리(Route 53이 결정)
상태 확인(Health Check) ❌ 불가능 ✅ 가능
예시 대상 - ALB, CloudFront, S3 웹사이트, API Gateway, Beanstalk 등

🧩 3. 예시로 보는 차이

시나리오                                                                             사용할 레코드                     이유
app.mydomain.com → ALB 연결 CNAME or Alias 둘 다 가능 (CNAME은 루트 아님)
mydomain.com → ALB 연결 Alias 루트 도메인은 CNAME 불가
app.mydomain.com → CloudFront Alias AWS 리소스 대상
www.mydomain.com → example.com CNAME 단순 도메인 간 연결

🧠 4. Route 53 콘솔에서의 실습 요약

  1. CNAME 생성
    • 이름: myapp
    • 유형: CNAME
    • 값: myapp-alb.amazonaws.com
    • 결과: myapp.mydomain.com으로 접속 시 ALB로 연결됨
    • 단, 루트 도메인에는 생성 불가 ❌
  2. Alias 생성
    • 이름: myalias
    • 유형: A (IPv4)
    • Alias 체크 후 → 대상 리소스로 ALB 선택
    • 상태 확인 자동 적용
    • 비용 없음, 루트 도메인에도 적용 가능
    • 결과: myalias.mydomain.com 또는 mydomain.com으로 접속 가능 ✅

💡 5. 핵심 정리 요약표

구분                                            CNAME                                     Alias
목적 도메인 → 도메인 도메인 → AWS 리소스
루트 도메인 적용 ❌ ✅
대상 타입 도메인 이름 ALB, CloudFront, API Gateway 등
TTL 설정 수동 자동
비용 유료 무료
헬스 체크 불가 가능
관리 주체 DNS 표준 Route 53 전용

 

💬 정리 문장:
CNAME은 단순히 "도메인 → 도메인" 매핑,
Alias는 "도메인 → AWS 리소스" 매핑이며,
루트 도메인까지 지원하고 쿼리 비용이 무료라는 점이 가장 큰 차이입니다.

1. Route 53의 라우팅 정책이란?

Route 53의 라우팅 정책(Routing Policy) 은
“DNS 쿼리에 어떻게 응답할지”를 결정하는 규칙입니다.

즉,

  • 트래픽을 직접 라우팅하는 게 아니라
  • DNS 쿼리에 어떤 IP나 리소스를 응답할지 결정하는 방식이에요.

클라이언트는 DNS의 응답을 받은 뒤,
그 IP로 직접 HTTP 요청을 보내게 됩니다.

🧭 2. Route 53이 지원하는 라우팅 정책 종류

정책 이름설명
단순(Simple) 단일 리소스에 트래픽 전달 (가장 기본적인 방식)
가중치 기반(Weighted) 비율(가중치)에 따라 여러 리소스로 트래픽 분배
장애 조치(Failover) 주 리소스 장애 시 보조 리소스로 자동 전환
지연 시간 기반(Latency-based) 사용자와 지리적으로 가까운 리전에 라우팅
지리적(Geolocation) 사용자의 위치(국가/대륙)에 따라 다른 리소스로 응답
지리 근접(Geoproximity) 지리적 거리 + 가중치 기반으로 세밀하게 제어
다중 값 응답(Multi-value answer) 여러 IP를 반환해 클라이언트가 직접 선택하게 함

⚙️ 3. 단순(Simple) 라우팅 정책

가장 기본적인 형태로,
하나의 도메인 → 하나의 리소스(IP) 를 연결합니다.

✅ 예시

 
foo.example.com → 13.125.11.24
  • 클라이언트가 foo.example.com에 접속하면
    Route 53은 해당 IP를 반환합니다.
  • 이후 클라이언트는 해당 IP로 직접 HTTP 요청을 전송합니다.
  • Route 53은 트래픽을 “보내는” 것이 아니라, “경로를 알려주는 것”이에요.

🔹 여러 IP를 지정할 수도 있음

A 레코드에 여러 IP를 지정하면,
Route 53은 DNS 응답에 여러 IP를 모두 반환합니다.

예:

 
A foo.example.com: 13.125.11.24 3.99.111.87

→ 클라이언트는 응답받은 IP 중 하나를 무작위로 선택해 접속합니다.

이건 단순한 부하 분산의 효과를 줄 수 있지만,
진짜 부하 분산은 아니에요 (DNS가 랜덤하게 응답할 뿐).

⚠️ 단순 정책의 제한

항목설명
상태 확인(Health Check) ❌ 불가능
여러 리소스 간 트래픽 제어 ❌ 불가능
복잡한 로드 밸런싱 ❌ 불가능
단일 리소스에만 지정 가능 ✅ 가능

복잡한 분산이나 장애 전환은 Failover, Weighted, Latency 기반 정책에서 수행합니다.

🧪 4. 실습 요약

  1. 단순 A 레코드 생성
    • 이름: simple.stephanetheteacher.com
    • 타입: A
    • 값: ap-southeast-1 리전의 EC2 IP
    • TTL: 20초
    • 라우팅 정책: Simple
  2. DNS 확인→ 결과: IP와 TTL(20초) 출력됨
  3.  
    dig simple.stephanetheteacher.com
  4. 여러 IP 추가
    • ap-southeast-1 + us-east-1 IP 두 개 입력
    • TTL 만료 후 dig 재실행 → IP 2개 표시됨
    • 웹에서 새로고침 시 두 리전 중 랜덤하게 연결

💡 5. 핵심 요약

항목설명
이름 단순(Simple) 라우팅 정책
역할 단일 리소스에 DNS 응답 반환
상태 확인 불가능
TTL 직접 설정 가능
부하 분산 제한적 (클라이언트 측 랜덤 선택)
사용 예시 단일 웹 서버, 테스트용 레코드, 기본 설정
시험 포인트 “Simple Policy는 Health Check 불가, 하나의 대상만 지정 가능”

🧠 핵심 문장 요약:
단순 라우팅 정책은 Route 53이 DNS 쿼리에 단일 리소스의 IP만 응답하는 가장 기본적인 방식입니다.
상태 확인(Health Check)은 불가능하며, 복잡한 분산은 지원하지 않습니다.

Route 53 — 가중치 기반 라우팅 정책 (Weighted Routing Policy)

개념

  • 요청 트래픽을 가중치(Weight) 비율에 따라 여러 리소스로 분산하는 방식
  • 각 리소스(예: EC2 인스턴스)에 상대적인 가중치 값을 부여
  • DNS 응답 시, 트래픽이 가중치 비율에 맞게 분배됨

동작 원리

  • 예시:
    • EC2 인스턴스 3개에 각각 가중치 70, 20, 10
    • 총합이 100이 아니어도 됨 (비율로 계산)
    • Route 53은 전체 가중치 중 비율로 트래픽 분배
      • 예: 70/(70+20+10) = 70% → 첫 번째 인스턴스로 트래픽
  • DNS 레코드는 동일한 이름과 유형(A, CNAME 등)을 가져야 함
  • 상태 확인(Health Check) 과도 연동 가능
    • 비정상 리소스는 자동으로 트래픽 분배 대상에서 제외

설정 예시

리전                                                                 IP                          가중치           레코드 ID                                              TTL
ap-southeast-1 (IP1) 10 SOUTHEAST 3초
us-east-1 (IP2) 70 US EAST 3초
eu-central-1 (IP3) 20 EU 3초
  • 동일한 이름(weighted.example.com)으로 3개의 레코드 생성
  • TTL을 짧게 설정하면 가중치 효과를 실시간으로 확인 가능

특징

  • 가중치 합 = 100일 필요 없음 (비율로만 계산)
  • 가중치 0으로 설정하면 해당 리소스로 트래픽이 가지 않음
    • 단, 모든 가중치가 0이면 동일 비율로 재분배됨
  • 트래픽 비율
특정 레코드로 가는 비율 = 해당 레코드 가중치 / 전체 가중치 합

사용 사례

  1. 리전 간 부하 분산 (Global Load Balancing)
    • 여러 리전의 리소스에 비율 기반으로 트래픽 분배
  2. 신규 애플리케이션 테스트
    • 기존 리소스 90, 새 리소스 10 → 점진적 트래픽 이동
  3. 일시적 트래픽 차단
    • 특정 리소스의 가중치를 0으로 변경하여 트래픽 중단

실습 결과 예시

  • weighted.example.com 접속 시
    • 대부분 us-east-1(70%) 응답
    • 간헐적으로 eu-central-1(20%), ap-southeast-1(10%) 응답
  • TTL(3초) 후 새 DNS 요청 시 다른 IP가 반환되기도 함

요약

항목설명
핵심 기능 트래픽을 가중치 비율로 분산
장점 세밀한 트래픽 제어 및 점진적 배포 가능
설정 조건 동일한 이름/유형의 DNS 레코드 필요
주의점 TTL이 너무 짧으면 요청이 자주 바뀜
대표 사용처 글로벌 부하 분산, 새 버전 테스트

Route 53 — 지연 시간 기반 라우팅 정책 (Latency-based Routing Policy)

개념

  • 지연 시간(latency) 이 가장 짧은 리소스로 사용자를 연결하는 정책
  • 유저의 위치에 따라 가장 빠르게 응답할 수 있는 AWS 리전의 리소스로 트래픽을 전달
  • 전 세계에 애플리케이션을 배포했을 때 성능 최적화에 유리

동작 원리

  • Route 53은 사용자 위치와 각 리전 간의 네트워크 지연 시간을 지속적으로 측정
  • 사용자의 DNS 요청이 들어오면
    → 가장 짧은 지연 시간을 제공하는 리전의 레코드(IP)로 응답
  • “가까운 리전”이 아니라, “가장 빠른 리전” 이라는 점이 핵심
    • 예: 독일 유저가 미국 리전(us-east-1)의 지연 시간이 더 짧다면 → 미국 리전으로 연결

설정 예시

리전IP 주소라우팅 정책레코드 IDTTL
ap-southeast-1 (싱가포르) (IP1) 지연 시간 기반 ap-southeast-1 기본값
us-east-1 (버지니아) (IP2) 지연 시간 기반 us-east-1 기본값
eu-central-1 (프랑크푸르트) (IP3) 지연 시간 기반 eu-central-1 기본값
  • 모든 레코드의 이름(latency.example.com) 과 유형(A 레코드 등) 은 동일해야 함
  • Route 53 콘솔에서 리전(region)을 직접 지정해야 함 (IP만으로는 리전 정보 알 수 없음)
  • 상태 확인(Health Check)도 연결 가능 (추후 학습 예정)

특징

  • 사용자의 지리적 위치 + 네트워크 상태 기반으로 라우팅
  • 항상 동일한 리전으로 연결되지 않음 (위치/VPN/네트워크 상황에 따라 달라짐)
  • TTL(캐시 시간)이 짧을수록 변경이 빠르게 반영됨
  • 가중치 기반 정책과 달리, 명시적 비율이 아닌 “성능 기반”으로 트래픽 분배

사용 예시

  1. 글로벌 웹 애플리케이션 성능 향상
    • 예: 유럽 사용자는 프랑크푸르트, 아시아 사용자는 싱가포르 리전으로 연결
  2. 지연 시간 민감 서비스 (게임, 실시간 스트리밍, 거래 플랫폼 등)
  3. VPN을 통한 테스트 가능
    • 다른 국가 VPN으로 접속 시, 가장 가까운 리전 IP로 자동 연결됨

실습 결과 예시

  • 유럽에서 접속 → eu-central-1 인스턴스 응답
  • 캐나다에서 접속 → us-east-1 인스턴스 응답
  • 홍콩에서 접속 → ap-southeast-1 인스턴스 응답
  • TTL 짧게 설정 시 새로 고침마다 다른 리전 응답 가능

요약

항목설명
핵심 기능 지연 시간이 가장 짧은 리전으로 트래픽 라우팅
기준 사용자 위치 및 네트워크 지연 시간
장점 전 세계 사용자에게 빠른 응답 제공
주의점 동일 이름/유형의 레코드 필요, 리전 명시 필수
대표 사용처 글로벌 서비스, 지연 시간 민감 애플리케이션

Route 53 — 상태 확인 (Health Check)

개념

  • 리소스의 정상/비정상 상태를 감지하는 기능
  • DNS 장애 조치를 자동화하거나 트래픽 라우팅 결정에 활용
  • 공용 리소스뿐 아니라 개인 리소스 상태 확인도 가능

동작 원리

  1. Route 53 상태 확인은 대상 리소스(ALB, EC2 등)에 주기적으로 요청을 보냄
    → 200 OK 또는 정의된 응답 코드 수신 시 정상
  2. 전 세계 여러 위치에서 상태 확인 요청이 이루어짐
    → 일반적으로 15개 정도의 글로벌 체크
  3. 일정 비율 이상 정상 응답 시, 리소스 정상으로 간주
    → 예: 18% 이상이 정상 응답이면 정상으로 판단
  4. 상태 확인 주기 설정 가능
    • 30초 (기본)
    • 10초 (빠른 상태 확인, 비용 증가)
  5. 지원 프로토콜: HTTP, HTTPS, TCP 등
  6. 텍스트 기반 응답 확인 가능
    → 응답 첫 5,120바이트 내 특정 문자열 존재 여부 체크

설정 예시

유형            설명
대상 공용 엔드포인트(ALB 등) 또는 개인 리소스(CloudWatch 알람 사용)
연결 Route 53 레코드와 연결 가능 (DNS 장애 조치)
위치 상태 확인 수행할 글로벌 위치 지정 가능
조건 정상: 응답 코드 2xx/3xx 수신, 비정상: 응답 없음 또는 다른 코드

계산된 상태 확인 (Calculated Health Check)

  • 여러 하위 상태 확인을 조합하여 상위 상태 확인 생성
  • 논리 연산 가능: OR, AND, NOT
  • 최대 256개의 하위 상태 확인 포함 가능
  • 상위 상태 확인 통과 조건 설정 가능 (예: n개 이상 정상)

개인 리소스 모니터링

  • 공용 인터넷에서 접근 불가한 VPC, 온프레미스 리소스는 직접 상태 확인 불가
  • 해결 방법: CloudWatch 메트릭 + CloudWatch 알람 활용
    1. 개인 리소스 상태 모니터링
    2. 이상 발생 시 CloudWatch 알람 ALARM 상태
    3. Route 53 상태 확인과 연동 → 자동으로 비정상 처리
  • 이를 통해 개인 리소스 상태 확인 구현 가능

특징

  • DNS 장애 조치(Health-based Routing) 자동화 가능
  • 글로벌 및 지역별 상태 확인 모두 지원
  • 텍스트 응답 체크, 상태 확인 주기 설정 등 유연한 옵션 제공
  • 개인 리소스 모니터링 시 CloudWatch 연동 필요

대표 사용 사례

  • 다중 지역 고가용성 웹사이트
  • 트래픽을 정상 리소스로 자동 라우팅
  • VPC 내부 EC2 인스턴스 모니터링
  • 계산된 상태 확인을 활용한 복합 상태 모니터링

단계별 생성 과정

  1. Health Checks 메뉴 이동
    • Route 53 콘솔 왼쪽에서 Health Checks 선택
  2. 개별 EC2 상태 확인 생성
    • us-east-1 인스턴스
      • IP 주소 입력
      • 포트: 80 (HTTP)
      • 경로: / (실제 환경에서는 /health 권장)
      • 상태 확인 간격: 30초 (기본)
      • 고급 옵션 대부분 기본값 유지
    • ap-southeast-1, eu-central-1 인스턴스
      • 동일한 방식으로 각각 상태 확인 생성
  3. 상태 확인 테스트
    • 인스턴스 보안 그룹에서 HTTP(80번) 포트 차단
      → 상태 확인 결과 비정상으로 변경
    • 다른 인스턴스는 정상 상태 유지
  4. 상세 정보 확인
    • 마지막 확인 시간, 상태, 오류 메시지 확인 가능
    • 장애 발생 시 연결 시간 초과 등 정보 확인
  5. 계산된 상태 확인(Calculated Health Check)
    • 여러 하위 상태 확인을 OR, AND, NOT 조합 가능
    • 예: 모든 상태 확인이 정상일 때만 상위 상태 확인 정상으로 설정
    • 복잡한 모니터링 규칙 구현 가능
  6. CloudWatch 알람 연동
    • 개인 VPC/온프레미스 리소스 모니터링 가능
    • CloudWatch 알람 상태를 상태 확인과 연결
    • 알람이 ALARM 상태이면 상태 확인 비정상으로 자동 반영

Route 53 — 장애 조치 라우팅 정책 (Failover Routing Policy)

개념

  • 기본 리소스가 비정상일 경우 자동으로 보조 리소스로 트래픽 전환
  • DNS 수준에서 장애 조치(Failover) 자동화
  • 상태 확인(Health Check)과 연동 필수

동작 원리

  • 기본 레코드와 보조 레코드 각각 생성
  • 기본 리소스 상태가 정상 → 기본 레코드 응답
  • 기본 리소스 상태가 비정상 → Route 53이 자동으로 보조 레코드 응답
  • 클라이언트는 항상 정상 상태 리소스로 연결됨

설정 예시

레코드 IP 주소 라우팅 정책 TTL 장애 조치 유형 상태 확인 연결 레코드 ID
failover 3.70.14.253 (eu-central-1) 장애 조치 60초 기본 eu-central-1 상태 확인 EU
failover (us-east-1) 장애 조치 60초 보조 연결하지 않아도 가능 US
  • 기본 레코드: 상태 확인과 연결 필수
  • 보조 레코드: 상태 확인 연결 선택 가능
  • TTL 짧게 설정 → 장애 조치 반영 빠름

실습 결과

  • eu-central-1 기본 리소스 정상 → 접속 시 eu-central-1 응답
  • eu-central-1 상태 확인 비정상 (보안 그룹 차단 등) → 접속 시 자동으로 us-east-1 응답
  • 상태 회복 시 → 기본 리소스로 자동 복귀

특징

  • 기본/보조 구조로 간단하게 장애 대응 가능
  • 상태 확인과 연동 필수
  • TTL 짧게 설정하면 장애 발생 시 빠른 전환 가능
  • CloudWatch 알람과 연동하여 개인 리소스 장애 감지도 가능

사용 사례

  • 다중 지역 고가용성 웹사이트
  • 재해 복구(Disaster Recovery) 구성
  • 장애 발생 시 자동 트래픽 전환 필요 서비스

Route 53 — 지리 위치 라우팅 정책 (Geolocation Routing Policy)

개념

  • 사용자의 실제 위치(대륙, 국가, 주 등) 기반으로 트래픽 라우팅
  • 지연 시간과 관계없이 지정된 위치의 IP로 연결
  • 일치하는 위치가 없으면 기본 레코드(Default Record) 사용
  • 상태 확인(Health Check)과 연결 가능

동작 원리

  • 사용자의 IP를 기반으로 지정된 지리 레코드를 확인
  • 위치 일치 → 해당 위치의 레코드 응답
  • 위치 불일치 → 기본 레코드 응답
  • 웹사이트 현지화, 콘텐츠 제한, 지역별 로드 밸런싱에 적합

설정 예시

레코드 IP 주소 라우팅 정책 위치 지정 상태 확인 레코드 ID
geo ap-southeast-1 지리 위치 아시아 전체 선택 가능 Asia
geo us-east-1 지리 위치 미국 전체 선택 가능 US
geo eu-central-1 지리 위치 기본(Default) 선택 가능 Default EU
  • 아시아 사용자는 ap-southeast-1 연결
  • 미국 사용자는 us-east-1 연결
  • 나머지 지역 사용자는 eu-central-1 기본 레코드 연결

실습 결과

  • 미국 외 지역 접속 → eu-central-1 (기본 레코드) 응답
  • 인도(VPN) 접속 → ap-southeast-1 응답
  • 미국(VPN) 접속 → us-east-1 응답
  • 멕시코 접속 → 기본 레코드(eu-central-1) 응답

특징

  • 실제 위치 기반 트래픽 분배
  • 위치 일치하지 않을 경우 기본 레코드 필요
  • 상태 확인 연결 가능 → 리소스 장애 시 대응 가능
  • 웹사이트 현지화, 지역 제한 콘텐츠, 국가별 로드 밸런싱에 유용

사용 사례

  • 특정 국가/대륙 사용자에게 맞춤 콘텐츠 제공
  • 국가별 로컬 서버 연결
  • 글로벌 서비스에서 지역별 트래픽 관리

Route 53 — 지리 근접 라우팅 정책 (Geoproximity Routing Policy)

개념

  • 사용자와 리소스의 지리적 위치 기반으로 트래픽 라우팅
  • 편향(Bias) 값을 사용해 특정 리전에 트래픽을 더 많이 또는 적게 보낼 수 있음
  • 글로벌 서비스에서 트래픽 분산 조절, 특정 리전 트래픽 집중/제한에 유용
  • AWS 리소스는 리전 지정, 온프레미스 리소스는 위도/경도로 위치 지정 필요

동작 원리

  • 기본적으로 사용자 위치와 가장 가까운 리전으로 라우팅
  • 편향값 0 → 거리 기준으로 단순 라우팅
  • 편향값 양수 → 특정 리전으로 트래픽 증가
  • 편향값 음수 → 특정 리전으로 트래픽 감소
  • AWS 트래픽 플로우 기능 사용 시 편향값 조정 가능

설정 예시

리소스 리전/위치 편향걊 트래픽 경향
Resource A us-west-1 0 거리 기준 사용자 이동
Resource B us-east-1 0 거리 기준 사용자 이동
Resource B us-east-1 +50 us-east-1로 더 많은 트래픽 집중
Resource A us-west-1 -50 us-west-1 트래픽 감소 가능
  • 편향값에 따라 미국 전역 사용자가 두 리전 중 어느 곳으로 연결될지 결정
  • 편향값이 높을수록 해당 리전으로 더 많은 사용자가 이동
  • 거리 기준 라우팅과 편향 조정을 통해 유연한 트래픽 제어 가능

특징

  • 사용자 위치 + 편향값 기반 트래픽 제어
  • 트래픽을 특정 리전으로 집중시키거나 분산 가능
  • AWS 리소스 또는 온프레미스 리소스 모두 지원
  • 고급 Route 53 트래픽 플로우 활용

사용 사례

  • 특정 리전에 더 많은 트래픽을 유도하고자 할 때
  • 글로벌 분산 애플리케이션에서 트래픽 균형 조절
  • 재해 복구 및 리전별 리소스 부하 관리

Route 53 — IP 기반 라우팅 정책 (IP Address Routing Policy)

개념

  • 클라이언트 **IP 주소(CIDR 범위)**를 기반으로 트래픽 라우팅
  • 미리 정의한 IP 범위에 따라 특정 리소스로 요청 전달
  • 성능 최적화 및 네트워크 비용 절감 가능
  • ISP나 조직별 IP 범위를 알고 있을 때 유용

동작 원리

  • Route 53에서 CIDR 목록 정의
  • 각 CIDR 블록에 연결할 로케이션(리소스) 지정
  • 사용자의 IP가 어느 CIDR에 속하는지 확인 후 해당 리소스로 라우팅
  • CIDR 범위를 정확히 정의하면 특정 트래픽을 원하는 엔드포인트로 유도 가능

설정 예시

로케이션 CIDR 범위 연결 리소스
Location 1 203.0.113.0/24 EC2 인스턴스 IP1, IP2, IP3, IP4
Location 2 200.0.113.0/24 EC2 인스턴스 IP5, IP6, IP7, IP8
  • 사용자 A가 Location 1 CIDR에 속하면 IP1~IP4로 라우팅
  • 사용자 B가 Location 2 CIDR에 속하면 IP5~IP8로 라우팅

특징

  • 클라이언트 IP 기반 정확한 라우팅 가능
  • ISP, 조직, 데이터센터별 트래픽 제어 가능
  • 글로벌 분산 환경에서 특정 트래픽 최적화 가능
  • 설정이 단순하고 명확함

사용 사례

  • 특정 ISP 사용자 트래픽을 특정 리전으로 라우팅
  • 온프레미스 또는 글로벌 고객별 트래픽 제어
  • 트래픽 최적화 및 비용 절감

Route 53 — 다중 값 라우팅 정책 (Multi-Value Answer Routing Policy)

개념

  • 트래픽을 여러 리소스로 라우팅할 때 사용
  • Route 53이 **다중 리소스(IP 등)**를 클라이언트에 반환
  • 상태 확인과 연결하면 반환되는 리소스 중 정상 상태 확인된 리소스만 제공
  • 클라이언트 측에서 로드 밸런싱처럼 동작

동작 원리

  • 각 다중 값 쿼리에 최대 8개의 정상 레코드 반환
  • 클라이언트는 반환된 레코드 중 하나를 선택하여 사용
  • 상태 확인과 결합하면 안전하게 정상 리소스만 선택 가능
  • 단순 라우팅과 달리, 비정상 리소스가 포함될 위험이 없음

설정 예시

레코드 이름 값(IP) 라우팅 정책 상태 확인 레코드 ID TTL
multi us-east-1 IP 다중 값 us-east-1 US 60초
multi ap-southeast-1 IP 다중 값 ap-southeast-1 Asia 60초
multi eu-central-1 IP 다중 값 eu-central-1 EU 60초
  • 상태 확인이 비정상으로 바뀌면 해당 리소스는 반환되지 않음
  • 예: eu-central-1 상태 확인이 비정상 → 클라이언트는 us-east-1, ap-southeast-1 중 하나 선택

특징

  • 최대 8개의 정상 리소스 반환
  • 클라이언트 측 로드 밸런싱 지원
  • 상태 확인과 결합하면 안정적인 트래픽 분배 가능
  • 단순 라우팅보다 비정상 리소스 포함 위험이 적음

사용 사례

  • 글로벌 여러 리전에서 동일한 서비스 제공
  • 클라이언트 측 로드 밸런싱 필요 시
  • 상태 확인과 결합해 고가용성 트래픽 분배

도메인 이름 레지스트라와 DNS 서비스

개념

  • 도메인 이름 레지스트라: 원하는 도메인을 구매하고 매년 갱신하는 서비스
  • DNS 서비스: 도메인 이름과 IP 주소를 연결하고, DNS 레코드를 관리하는 서비스
  • 레지스트라에서 도메인을 구매하면 대부분 DNS 서비스도 함께 제공

구분

  • 레지스트라 예시: Amazon, GoDaddy, Google Domains 등
  • DNS 서비스 예시: Route 53, GoDaddy DNS, Google Domains DNS 등
  • 도메인 등록과 DNS 서비스는 별도로 선택 가능
    • 예: GoDaddy에서 도메인 구매 + Route 53에서 DNS 관리 가능
    • Amazon에서 도메인 구매 + Route 53에서 DNS 관리 가능

설정 예시 (타사 도메인 + Route 53)

  1. Route 53에서 공용 호스팅 영역 생성
  2. 호스팅 영역 상세에서 이름 서버(NS) 확인 (4개 서버)
  3. 타사 도메인 등록 대행사(예: GoDaddy)에서 사용자 정의 이름 서버 지정
  4. GoDaddy의 도메인에 NS를 Route 53의 이름 서버로 업데이트
  5. 이후 Route 53에서 DNS 레코드 직접 관리 가능

특징

  • 도메인 이름과 DNS 서비스는 독립적으로 구성 가능
  • DNS 기능은 레지스트라마다 일부 제공하지만,
    전문 관리가 필요한 경우 Route 53과 같은 별도 DNS 서비스 사용 권장
  • 이 조합을 통해 글로벌 트래픽 관리, 라우팅 정책 적용 등 가능

사용 사례

  • 도메인 구매는 저렴한 레지스트라에서,
    DNS 관리 및 라우팅 정책 적용은 Route 53 활용
  • 기존 도메인을 AWS로 이전하지 않고도 Route 53으로 트래픽 관리 가능

'클라우드' 카테고리의 다른 글

AWS - S3  (1) 2025.10.21
AWS - 세 개의 아키텍처 예시 및 Beanstalk  (0) 2025.10.21
AWS - RDS, Aurora, ElastiCache  (0) 2025.10.18
AWS - Load Balancer  (0) 2025.10.17
AWS - EBS, AMI, EFS  (0) 2025.10.15

관련글 더보기

티스토리툴바