Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
일 월 화 수 목 금 토
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags more
Archives
Today
Total
관리 메뉴

개발공부기록

ELB(Elastic Load Balancer), SSL, Route53, IPv4, IPv6, 레코드 타입, TTL 본문

인프라/AWS

ELB(Elastic Load Balancer), SSL, Route53, IPv4, IPv6, 레코드 타입, TTL

소소한나구리 2025. 5. 7. 23:33
728x90

ELB(Elastic Load Balancer)

확장성(Scalability) vs 고가용성(Availability)

확장성, 고가용성 모두 분산 시스템에서 중요한 개념이지만 서로 다른 개념이다

 

확장성은 시스템이 커지거나 작아질 수 있는 능력을 의미한다.

사용자 수, 데이터 양, 처리량 등이 증가할 때 시스템의 성능과 처리 능력을 유지하거나 향상시키는 것을 말하며 이를 위해서는 확장성 있는 시스템 디자인과 구현이 필요하다

 

수평정 확장과 수직적 확장이 있는데 수평적 확장은 AWS내에서 인스턴스를 여러개 늘리는 것과 같은 행위를 말하며 수직적 확장은 하나의 인스턴스의 성능을 높이는 것을 말한다.

 

고가용성은 시스템이 정상적으로 작동하고 사용 가능한 상태를 유지하는 능력을 의미한다.

즉, 사용자가 요청하는 서비스를 항상 이용 가능한 상태로 유지하는 것을 뜻하는데 이를 위해서는 시스템의 안정성을 높이고 장애 대응 능력을 강화하는 것이 중요하다

 

따라서 확장성은 시스템의 성능과 처리 능력을 유지하거나 향상시키는 능력을 의미하고, 고가용성은 시스템의 안정성과 사용 가능한 상태를 유지하는 능력을 의미하며 분산 시스템을 설계하고 구현할 때 둘 다 고려해야하는 중요한 개념이다

 

ELB의 개념

AWS에서 제공하는 로드 밸런싱 서비스로 다수의 EC2 인스턴스를 사용하여 트래픽을 분산시키는 역할을하여 고가용성과 확장성을 제공한다

 

또한 Route 53과 연동하여 단일 액세스 포인트를 공개할 수 있고, 인스턴스에 대한 헬스 체크도 할 수 있으며 ACM과 연동화여 HTTPS를 제공할 수도 있으며 공개 트래픽과 내부 트랙픽을 분리하여 관리할 수 있어 보안도 챙길 수 있다.

 

다양한 유형의 로드 밸런서가 있으며 각각의 특징은 아래와 같다

  • Application Load Balancer
    • OSI 모델 7계층에서 동작하며 HTTP/HTTPS 트래픽을 처리한다
    • 컨테이너화된 애플리케이션과 연동하여 사용할 수 있으며 대부분의 개발자가 가장 많이 사용하게 될 로드 밸런서이다
    • HTTP/2와 웹소겟도 지원하며 HTTPS로 리다이렉트를 지원한다.
    • URL, hostname, query string, header에 기반하여 다른 타깃 그룹(EC2 그룹)으로 보낼 수 있다.
  • Network Load Balancer
    • OSI 모델 4계층에서 동작하며 TCP/UDP 트래픽을 처리한다
    • 높은 처리량을 필요로 하는 애플리케이션에 적합하다
  • Classic Load Balancer - deprecated
    • OSI 모델 4 ~ 7계층에서 동작하며 HTTP/HTTPS, TCP/UDP 트래픽을 처리하며 가장 오래된 형태의 로드 밸런서이다.
    • 대부분의 경우 위 두가지의 로드 밸런서를 용도에 맞게 사용하는 것을 권장한다
  • Gateway Load Balancer
    • 방화벽이나 서드파티의 Application을 사용할 때 사용하는 로드 밸런서이다

로드 밸런서에도 보안그룹을 따로 적용할 수 있어 여러 유저와 로드 밸런서 사이에 접근할 수 있는 보안그룹과, 로드 밸런서와 EC2들 사이에 적용할 수 있는 보안그룹을 각각 분리해서 관리할 수 있다.

 

모는 사용자에게는 Http/Https 모두를 공개하고, EC2는 로드밸런서에 적용된 보안그룹을 대상으로 허용하는 형태로 설정을 하게 된다.

 

각각의 로드 밸런서는 다양한 기능과 구성을 제공하며 선택적으로 사용할 수 있는데 예를 들어 Application Load Balancer는URL 경로 라우팅, 호스팅 기반 라우팅 등 다양한 라우팅 정책을 제공한다.

로드 밸런서는 고가용성과 확정성을 제공하므로 인스턴스의 장애와 부하 분산에대한 대응을 용이하게 해준다.

 

Application Load Balancer 사용해보기

실습을 위한 EC2를 2개를 생성하여 로드 밸런서를 사용해 볼 예정이다.

 

AMI는 ubuntu로 하고 보안 그룹은 인바운드 규칙에서 http/https 요청이 모두 허용되는 보안그룹을 적용한 다음 사용자 데이터에 아래의 명령어를 입력해준 상태로 EC2 두 개를 생성한다.

#!/bin/bash
apt-get update
apt-get install -y nginx
cat <<EOF > /var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
<title>Welcome to Nginx</title>
</head>
<body>
<h1>Hello World!</h1>
<p>AWS deployed by Me!</p>
<p>private ip is $(hostname -f)</p>
</body>
</html>
EOF
sudo systemctl start nginx

 

해당 명령어를 입력해두면 EC2를 생성할 때 자동으로 apt-get을 update해주고 nginx를 설치해준 HTML 파일을 작성한 경로의 index.html로 저장하고 nginx를 키는 것까지 실행된다.

 

 

2 개의 인스턴스를 생성하고 인스턴스 상태가 실행 중이 될 때까지 기다린다음 각각의 인스턴스이 퍼블릭 IP 주소로 접속해보면 서버의 nginx가 켜져있어 EC2를 생성할 때 만들어둔 html 파일이 보이는 것을 확인할 수 있다.

 

 

EC2 카테고리 하단에 보면 로드 밸런싱 - 로드 밸런서가 있는데 여기에 접근하여 로드 밸런서를 생성할 수 있다.

상단의 로드 밸런서를 클릭하면 여러 종류의 로드 밸런서를 선택할 수 있는 창이 뜨는데 여기서 Application Load Balancer를 선택해 주면 된다.

 

이후 생성할 로드 밸런서의 이름을 입력하고 스키마는 인터넷 경계(Internet_facing)로 IP 유형은 IPv4로 VPC 기본값으로 설정해 준 다음 네트워크 매핑은 모든 가용영역을 체크해준다.

 

 

그 다음 로드 밸런서의 보안 그룹을 새로 생성해 주는데 아웃 바운드 규칙은 그대로 두고 인바운드 규칙에서 http만 허용하도록 설정하여 보안그룹을 생성한다

생성한 보안그룹을 만들어줄 로드밸런서의 보안 그룹에 적용하면 외부에서는 HTTP (80)번으로 오는 모든 요청을 받을 수 있는 보안그룹이 적용된 로드 밸런서가 된다.

 

보안 그룹을 만드는 방법은 아래의 링크의 EC2 다루기 게시글에 작성 되어 있다.

2025.05.06 - [인프라/AWS] - Elastic Cloud Computing(EC2), 인스턴스 다루기, SSH 접속, EBS, AMI

 

그 다음 리스터 및 라우팅에서 80번 요청을 받았을 때 타겟 그룹(EC2들)으로 보낼 것인가를 설정할 수 있다.

지금은 아무런 그룹이 없기 때문에 대상 그룹을 새로 생성해 주면 된다

 

 

여러 설정들을 할 수 있지만 지금은 초기 설정이므로 그룹 이름과 프로토콜과 포트를 HTTP : 80 으로 설정하고 그룹을 생성해주면 해당 그룹에 등록이 가능한 인스턴스 목록들이 보이게 된다.

 

 

그룹에 담을 인스턴스들을 선택하고 아래에 보류 중인 것으로 포함을 하게 되면 그룹에 담을 인스턴스들이 그룹에 추가가 되고, 대상 그룹 생성 버튼을 누르게 되면 타겟 그룹이 생성이 된다.

생성된 타겟 그룹은 EC2 로드 밸런싱 카테고리에 대상 그룹(target group)에 들어가면 볼 수 있다.

 

 

이후 로드밸런서에서 생성한 타겟 그룹을 지정해 준 다음 로드 밸런서를 생성버튼을 클릭하면 로드 밸런서가 생성이 되고 목록에서도 생성된 로드 밸런서를 확인할 수 있다.

 

지금은 실습이기 때문에 위처럼 간단하게 적용했지만 원하는 상황에 맞춰서 설정값들은 변경해주면 되며 전체적으로 로드밸런서를 생성하는 프로세스가 이러한 플로우를 가지고 있다고 보면 된다.

 

로드 밸런서를 처음 만들게 되면 로드 밸런서의 상태가 프로비저닝 중 이라고 뜨게 되고 시간이 지나면 활성화가 된다

 

 

로드 밸런서의 상태가 활성화가 된 다음 로드 밸런서에 적용된 DNS 이름을 복사해서 접속해보면 EC2에 만들어둔 HTML 파일이 나타나는 것을 확인할 수 있다.

해당 로드밸런서의 주소로 계속 새롭게 접속을 시작해보면 내용이 바뀌게 되는데, 로드 밸런서가 동작하면서 자동으로 트래픽을 분산하여 타겟 그룹에 있는 EC2들 중 하나에 붙여주고 있는 것을 확인할 수 있다

 

여기서 임의로 타겟 그룹의 인스턴스들 중 하나를 종료시킨다고 해도 로드 밸런서를 통해 접속한 유저는 타겟 그룹 중 살아 있는 인스턴스에 접속하게 됨으로서 고가용성을 확보할 수 있게 된다.

 

 

타겟 그룹에 들어가서 해당 타겟 그룹의 상세정보로 들어가보면 타겟 그룹의 인스턴스 들의 상태들을 한눈에 확인할 수 있는데, EC2 하나를 종료했기 때문에 1개는 정상 1개는 사용되지않음으로 표시되고 있음을 바로 알 수 있어 빠른 모니터링이 가능하여 바로바로 대처할 수 있게 된다.

 

지금 상태에서는 각 EC2의 퍼블릭 아이피로도 접근을 할 수 있고 로드 밸런서의 DNS IP로도 접근할 수 있으므로 로드 밸런서를 사용한다면 EC2의 IP에는 직접 접근하지 못하도록 막는 것이 좋다.

 

 

그러기 위해서 EC2에 적용할 보안 그룹을 추가로 생성할 때 인바운드 규칙의 유형을 HTTP, 소스를 사용자 지정(Custom)으로 설정한 다음 로드 밸런서에 적용한 보안 그룹으로 지정해두면 해당 로드 밸런서로 오는 HTTP 요청만 허용하는 인바운드 규칙이 만들어 진다.

 

이렇게 생성한 보안 그룹을 로드 밸런서의 타겟 그룹인 인스턴스들에 모두 적용해주면 해당 인스턴스들은 외부에서 직접 접근하지 못하고 로드 밸런서를 통해서만 EC2에 접근할 수 있어 보안도 강화되고 단일 도메인으로 여러 서버에 트래픽을 분산하여 접근할 수 있게 된다.

 

EC2의 퍼블릭 IP로 접근을 시도해보면 무한 로딩이 되면서 접근이 막혀져 있고, 로드 밸런서를 통해서만 EC2에 접속이 되는 것도 직접 확인이 가능하다.

 

SSL과 HTTPS

SSL(Secure Sockets Layer)

  • 인터엣 상에서 정보를 안정하게 전송하기 위한 프로토콜
  • SSL은 클라이언트와 서버 사이에 안전한 접속을 만들어주며 전송되는 데이터를 암호화 하여 정보의 안정성을 보장한다

TLS(Transport Layer Security)

  • SSL을 보완한 기술로 현재는 사실 SSL을 사용하는 것이 아니라 TLS 기술을 사용하고 있지만 모두가 아직까지 SSL이라고 부르고 있다.

HTTPS

  • SSL(TLS)가 적용이 된 HTTP 통신 방식이 HTTPS 이다
  • HTTP는 SSL이 적용되지 않았기 때문에 누구나 중간에서 통신을 감청하거나 조작이 가능하여 위험하지만 HTTPS는 이러한 행위가 모두 불가능하다
  • HTTPS의 동작 방식을 만화로 잘 설명한 링크가 있다고 하니 자세한 동작 방법은 해당 링크에 접속하여 확인하면 된다.  https://howhttps.works/ko/
  • 해당 링크의 내용을 간단히 축약해서 설명하면 아래와 같다
    1. 초기에는 클라이언트와 서버가 같은 키를 가지고 사용하는 대칭키를 사용했는데 대칭 키를 클라이언트에서 서버로 보낼 때 탈취되는 문제가 있어서 이를 보완하기 위해 비대칭 키가 개발되었다.
    2. 비대칭 키는 암호화를 할 수 있는 공개키와 복호화를 할 수 있는 비공개 키(개인 키)로 구성되어있어 클라이언트에서 공개키로 데이터를 암호화하여 서버에 보내면 서버는 서버만 가지고 있는 비밀키로 데이터를 열어서 볼 수 있는 방식이다
    3. 비대칭 키는 안정성이 좋지만 단순한 대칭키에 비해 리소스를 매우 많이 소모하는 방식이므로 새로운 방식인 SSL(TLS)가 등장했는데 이것이 현재 사용하는 HTTPS 동작 방식이다.
    4. 브라우저가 서버에게 요청을 보내면 인증기관(CA)에서 발급한 인증서와 함깨 공개키를 브라우저에게 보낸다
    5. 회신을 받은 브라우저가 생성한 세션 키(대칭 키)를 파생하기 위한 사전-마스터키를 생성(대칭키가 될 시드값)하고 서버가 보내준 공개 키로 사전-마스터 키를 암호화하여 서버에 보낸다.
    6. 서버에서는 비공개 키를 통해서 암호화된 사전 마스터키를 복호화 하여 얻은 시드값으로 대칭 키(세션 키)가 파생 된다.
    7. 즉, 처음 사전 마스터 키(Pre-Master Key)를 서버에 전송할 때에만 안전한 비공개 키 방식으로 소통하고 그 이후에는 더 빠르고 효율적인 대칭 키로 암호화를 사용하게 된다.
    8. TLS 1.3 방식에서는 공개키 기반 키 교환 방식이 조금 달라 졌다고 한다.

로드 밸런서와 EC2 사이에서는 HTTP로 통신하고 있는데 로드 밸런서와 EC2 사이의 통신은 가상 사설망에서 통신하기 때문에 외부에서 접근할 수 없으므로 암호화가 되어있지 않아도 안전하다.

 

로드 밸런서에 SSL 적용하기

이를 적용하기 전에 만약 로드 밸런서에 적용된 보안 그룹에 HTTPS 요청으로도 접근이 가능하도록 인바운드 규칙이 빠져있다면 HTTPS 요청이 와도 로드 밸런서에서 막아버리기 때문에 보안그룹을 추가하고 진행해 주어야 한다.

 

 

생성한 로드 밸런서의 상세 정보를 들어가보면 우측 상단에 작업 - 리스너 추가를 누르면 리스너를 추가로 구성할 수 있는데 여기에서 프로토콜을 HTTPS로 설정해주면 자동으로 포트가 443으로 적용된다

 

 

보안 정책은 기본값으로 설정해주면 되고 ACM(AWS Certificate Manager)을 추가해주면 되는데 처음에는 없으므로 만들어서 등록해주면 된다.

하지만 개인 도메인 이름이 있어야 ACM을 발급 받을 수 있으므로 개인 도메인을 발급 받은 후 ACM을 등록해주면 된다.

 

Route 53에서구입한 도매인이다 다른 곳에서 구입한 도메인이 있다면 새 ACM 인증서 요청을 클릭한 후 인증서 요청을 해주면 된다

 

 

쭉 넘어가다 보면 도메인 이름을 입력하는 곳이 나오는데, 원하는 도메인만 적용할 경우 해당 도메인을 정확하게 입력해주면 되고, 다양한 서브 도메인에서 접속하게 등록하고 싶다면 서브 도메인 부분에 와일드 카드(*)를 적용하여 등록해주면 된다

 

아래 접은 글은 AWS 공식 사이트 적혀있는 도메인 이름을 입력하는 방법이다.

더보기

완전히 정규화된 도메인 이름(FQDN)은 인터넷 상의 조직 또는 개인의 고유한 이름입니다.

.com 또는 .org와 같은 최상위 도메인 확장명이 마지막에 위치합니다. SSL/TLS 인증서로 보호하려는 사이트의 정규 도메인 이름을 입력합니다(예: www.example.com). 동일한 도메인으로 여러 사이트를 보호하기 위해 와일드카드 인증서를 요청하려면 별표(*)를 사용합니다.

예를 들어, *.example.com은 www.example.com, site.example.com 및 images.example.com을 보호합니다.

 

이후 요청을 완료 하면 인증서에도 Route 53에서 CNAME 레코드를 생성하여 리다이렉트 해주도록 해야한다.

이미지의 Route 53에서 레코드 생성 버튼을 눌러서 레코드를 생성해주면 되는데 Route 53에 해당 도메인들이 등록되어 있다면 자동으로 연동되어 편리하게 레코드를 생성할 수 있다.

 

 

레코드를 생성한 후에 인증서가 검증이 될 때까지 기다려 주면 상태가 발급됨으로 변경되면서 인증서 발급이 완료된다.

 

 

이후 리스너 추가 페이지로 다시 넘어와서 새로고침 버튼을 눌러주면 활성화된 인증서를 선택할 수 있게 된다.

 

 

해당 인증서를 선택한 후에 추가 버튼을 누르게 되면 추가된 리스너가 정상적으로 등록된 것을 확인할 수 있다.

 

 

정상적으로 리스너 등록이 완료되었으므로 https://nagul2.store, https://test.nagul2.store 에 접속해보면 모두 정상적으로 로드 밸런서를 통해 인스턴스에 접근하는 것을 확인할 수 있다.

Route53

DNS란

Domain Name System의 약어로 인터넷에서 사용되는 컴퓨터나 기기들의 주소를 인터넷 사용자가 쉽개 이해하고 기억할 수 있는 도메인 이름으로 변환해주는 시스템이다.

 

인터넷에 연결된 모든 기기들은 IP 주소를 가지고 있지만 IP 주소는 외우기도 힘들뿐 아니라 변경될 수 있으므로 쉽게 이해하고 기억할 수 있고 변경되지 않는 고유의 이름으로 변환해 주는 것이 DNS의 역할이다

 

DNS는 인터넷에서 매우 중요한 역할을 하며 사용자가 웹 사이트를 방문하거나 이메일을 보내는 등의 모든 인터넷 활동에서 사용된다.

 

 

mac의 기준으로 nslookp 명령어를 활용하면 실제 사이트의 도메인이 어떤 IP인지 확인할 수 있다.

 

DNS는 계층 구조로 되어있는데 Root Level Domain, Top Level Domain, Domain Name, SubDomain, Protocol 순으로 되어있다.

 

https://www.google.com을 기준으로 Root  Level은 도메인 전체를,  Top Level은 .com, Domain(2nd Level)은 google, Subdomain(3rd level)은 www가 되며 그 앞에 HTTP/HTTPS와 같은 프로토콜이 오게 된다. 

 

Subdomain은 다른형태로 변경될 수도 있는데 모바일 기기 처럼 접속했을 때 m.naver.com  처럼 접속되는 것이 그 예시이다.

 

DNS 서비스는 계층적으로 분산 시스템으로 이루어져 있으며 이 계층 구조에서는 Root DNS Server, TLD DNS Server, SLD DNS Server가 각각의 역할을 수행한다

 

Root DNS Server

  • DNS 계층 구조에서 가장 상위에 위치한 DSN 서버이며 모든 DNS 쿼리는 먼저 Root DNS Server에 도착하여 해당 도메인의 TLD(Top-Level Domain) DNS Server의 주소를 알아내야 한다
  • Root DNS Server는 인터넷 상에서 전 세계에 총 13개가 운영되고 있으며 이들은 전 세계의 인터넷 서비스 제공 업체들에 의해 운영된다

TLD DNS Server

  • 도메인 이름의 최상위 레벨에 해당하는 .com, .net, .org, .kr, .io 등의 TLD를 관리하는 DNS 서버이다
  • 모든 도메인 이름은 하나 이상의 TLD에 속하며 TLD DNS Server는 해당 도메인 이름이 속한 SLD(Second-Level Domain)DNS Server의 주소를 알려준다

SLD DNS Server

  • SLD DNS Server는 도메인 이름 중간 레벨에 해당하는 DNS 서버이다
  • 도메인 이름의 중간 레벨에 해당하는 부분은 일반적으로 사용자가 만든 이름이며 SLD DNS Server는 해당 도메인 이름에 대한 IP 주소를 반환해준다.

 

해당 이미지를 토대로 순서를 설명해보면 아래와 같다

  1. 브라우저에서 naver.com을 최초 입력했을 때 브라우저에서 naver.com이 어떤 IP인지 모르는 상황이라면 Local DNS에 naver.com의 IP가 무엇인지 물어보기 위해 쿼리를 날린다.
  2. Local DNS란, 사용자의 요청을 가장 먼저 처리하는 DNS 서버로, 보통 인터넷을 제공하는 ISP(통신사)가 관리하며 각 LocalDNS에서 도메인에 대한 주소록을 가지고 있다고 보면 된다.
  3. 만약 로컬 DNS 서버가 물어본 naver.com의 IP 주소를 가지고 있다면 바로 IP 주소를 돌려주지만 가지고 있지 않다면 Root DNS 서버에 물어보게 된다.
  4. Root DNS Server는 모든 DNS 요청을 거쳐야 하며 Root DNS Server는  TLD(.com)을 보고 해당 TLD를 가지고 있는 TLD DNS Server의 IP 주소를 알려준다.
  5. 해당 정보를 받은 로컬 DNS는 TLD DNS Server에게 다시한번 요청하게 되고 여기에서 Domain을 보고 어떤 SLD DNS 서버에서 관리되고 있는지에 대한 IP주소를 알려준다
  6. 로컬 DNS가 SLD DNS Server에 naver.com 도메인의 IP주소를 물어보면 이제야 비로소 naver.com의 IP주소를 반환 받게되고 이 정보를 브라우저에게 전달해준다
  7. 브라우저는 전달받은 IP 주소로 웹서버와 연결하게 된다

이렇게 도메인을 통해 DNS를 찾는 과정은 매우 복잡하기 때문에 수많은 요청에 대해 모두 DNS서버를 찾아본다면 수 많은 통신이 발생하여 어마어마한 비효율이 발생하게 될 것이다

그렇기 때문에 Local DNS 뿐만 아니라 실제 요청을 보내는 브라우저에서도 캐싱이 되어 도메인에 대한 주소를 브라우저나 로컬 DNS가 이미 가지고 있다면 바로 IP 주소를 바로 반환해준다

 

IPv4, IPv6, 레코드 타입, TTL

IPv4, IPv6

  • 인터넷 프로토콜 주소 체계이다
  • IPv4는 32 비트로 구성된 주소체계로 192.168.0.1 과 같은 형태로 되어있다.
  • 최대 약 43억개의 IP 주소를 사용할 수 있지만 인터넷 사용자의 증가로 인해 IPv4 주소가 부족해지는 문제가 발생했다.
  • 이에 대응하기 위해 IPv6가 등장하였는데 128 비트로 구성되어있어 약 340경개의 IP 주소를 사용할 수 있다
  • 2001:0db8:85a3:0000:0000:8a2e:0370:7334 과 같은 형태로 되어있으며 주소 고갈 문제를 해결함과 동시에 보안성과 기능 면에서도 개선이 되었다
  • 참고로 중간에 v5도 있었는데 아무도 쓰지 않아서 바로 사장되고 v6로 바로 넘어오게 되었다고 한다

DNS 레코드 타입

  • 전화번호의 종류라고 생각하면 되며 아래의 레코드 타입이 있다
    • A 레코드: 호스트네임과 IPv4 주소를 연결한다
    • AAAA 레코드: 호스트네임과 IPv6 주소를 연결한다
    • CNAME 레코드: 호스트네임을다른 호스트네임과 연결하며, 다른 호스트네임은 반드시 A 혹은 AAAA 레코드가 있어야 한다.
    • NS 레코드: 호스트존의 네임서버를 지정한다
    • SOA 레코드: 메타 데이터 정보를 지정한다.
  • 호스트존은 도메인 네임의 IP 주소를 가리키는 public 호스트존과 사설망 내부에서 사용되는 private 호스트존이 있다.

CNAME vs Alias

  • CNAME과 Alias는 DNS 레코드의 유형인데 모두 호스트 이름을 다른 호스트 이름에 매핑하는데 사용되지만 서로 다른 용도를 가지고 있다.
  • CNAME 레코드는 호스트 이름을 다른 호스트 이름으로 매핑할 때 이전에 정의된 호스트 이름의 모든 레코드를 복사하여 새 호스트 이름에 할당하여 호스트 이름이 변경되었거나 호스트 이름이 서로 다른 IP 주소를 가리키도록 하려는 경우에 유용하다.
  • CNAME은 루트 도메인이 아닌 경우에만 적용이 가능하다
    • 예를 들어 app.mydomain.com 처럼 루트 도메인이 아닌 경우에는 CNAME을 적용할 수 있지만 mydomain.com 처럼 루트 도메인인 경우에는 CNAME 적용이 불가능하다
  • Alias 레코드는 호스트 이름을 Amazon S3 버킷, Elastic Load Balancer 또는 Amazon CloudFront 처럼 분산된 웹 사이트와 같은 AWS 리소스에 매핑한다.
  • 즉, AWS가 만들어 준 AWS 리소스에 도메인을 매핑하는 것이며 Alias 레코드는 Amazon Route 53에서만 지원된다.
    • Elastic Load Balancer, Cloudfront, API Gateway, Elastic Beanstalk, S3, VPC Interface Endpoints는 Alias가 가능하고 EC2는 Alias가 불가능하다.

TTL

  • TTL은 Time to Live의 약어로 DNS 레코드가 캐싱될 수 있는 최대 시간을 나타내는 값이다.
  • TTL이 높을 수록 DNS 레코드가 캐싱될 수 있는 시간이 더 길어지므로 캐시 효율성은 높아진다
  • 일반적으로 TTL은 몇분에서 몇 시간까지로 설정된다.
  • TTL이 너무 높으면 캐싱이 깨졌을 때 반영되는 것이 느려지므로 적절한 시간을 지정하는 것이 좋다.

 

Route 53 등록해보기

Route 53을 등록하기 위해선 도메인을 구입해서 등록하는 것이 원칙이지만, 지금은 연습이기 때문에 무료 도메인을 사용하여 등록할 예정이다

 

AWS에 접속하여 Route 53을 검색한 후 시작하기 버튼을 누르면 Route 53을 등록할 수 있다.

 

 

시작하기 화면으로 가면 Route53에서 도메인 등록을 통해 원하는 도메인을 직접 생성할 수도 있고 기존의 도메인 이전을 통해 다른 곳에서 사용하던 도메인을 AWS Route53이 관리하도록 이전할 수도 있다.

 

다른 곳에서 구입한 도메인을 Route53에 등록하려면 호스팅 영역 생성으로 Route53을 시작해주면 된다.

 

가비아에서 직접 도메인을 구입하여 Route53에 등록하는 방법으로 진행해 보겠다.

 

가비아에 회원 가입 후 구입할 도메인을 검색해보면 다양한 TLD가 적용된 도메인과 금액이 나오는데, 나는 연습용으로 구매할 것이기 때문에 가장 저렴한 nagul2.store를 선택했다.

 

 

결제에 필요한 정보를 입력한 후 결제를 진행하고 몇분 기다리다보면 구매한 도메인을 서비스 관리에서 확인할 수 있다

 

 

구입한 도메인을 Route 53에 등록하기 위해 호스팅 영역 생성을 선택하고 시작하기 버튼을 누르면 도메인 이름을 입력할 수 있는 창이 뜨는데 여기에 구입한 도메인 이름을 입력해주고 호스팅 영영 생성을 선택하면 Route 53에 도메인이 등록이 된다.

 

 

등록이 되면 NS, SOA 레코드가 자동적으로 생성 되는데 고가용성을 위해 4개의 네임서버가 NS 레코드에 등록되어있는 것을 확인할 수 있다.

 

Route 53에서 직접 도메인 구입한 경우라면 바로 추가 레코드를 생성해도 되지만 지금은 다른 사이트에서 구입한 도메인을 Route 53에 등록했기 때문에 Route 53에서 네임서버를 관리하도록 추가 설정을 해주어야 한다.

 

 

이미지상에서 보이는 NS 레코드의 값/트래픽 라우팅 대상의 값에 적혀있는 4개의 DNS 서버를 각각 복사하여 도메인을 구입한 사이트의 네임서버 설정에 전부 입력하고 소유자 인증을 한 후 적용 버튼을 눌러주면 된다.

이때 AWS 레코드에 적혀있는 가장 마지막에 있는 .은 포함되지 않도록 입력해야 된다.

 

다른 도메인 업체에서도 도메인 네임서버 설정하는 위치만 다를 뿐 방법은 동일하므로 생성된 NS 레코드의 값을 각 사이트에서 제공하는 도메인 네임서버 설정에 등록해주면 된다.

 

 

이제 구입한 도메인이 정상적으로 Route 53이 관리하고 있는지 확인해 보기 위해 상단의 AWS에서 레코드 생성을 눌러서 새로운 레코드를 생성한다.

 

이전에 등록했던 로드 밸런서를 등록할 예정이므로 로드 밸런서의 DNS 이름을 복사한 뒤 서브 도메인 이름을 지정하고 레코드 유형을 CNAME으로 설정한 다음 복사한 로드 벨런서의 DNS를 값에 붙혀 넣어주고 TTL값도 적당히 입력한 다음 레코드를 생성해준다.

 

서브 도메인 이름을 지정했기 때문에 루트 도메인에 지정할 수 없는 CNAME 레코드로 생성할 수 있다.

 

 

등록한 test.nagul2.store를 브라우저에 입력해보면 정상적으로 인스턴스에 접속할 수 있는 것을 확인할 수 있으며 로드 밸런서를 통해 접근했으므로 새로고침을 하면 계속 접근하는 인스턴스가 변경되어 private ip 주소가 바뀌어 출력되는 것을 확인할 수 있다.

 

Mac의 경우 터미널에서 nslookup 키워드를 통해 등록한 test.nagul2.store를 입력해보면 CNAME 레코드로 생성한 로드벨런서의 DNS와 IP주소가 출력되는 것을 확인할 수 있다

 

 

레코드를 생성할 때 서브 도메인 입력 없이 Apex Domain으로 적용하게 된다면 CNAME이아닌 Alias 레코드로 생성해 주기 위해 레코드 유형을 A로 설정해주면 된다.

 

그 다음 별칭을 활성화 해주고 트래픽 라우팅 대상을 지정해주면 되는데, 현재는 적용할 대상이 Load Balancer이므로 Application/Classic Load Balancer로 선택하여 리전과 로드 밸런서의 DNS를 선택해주면 된다

 

Alias를 사용할 때에는 TTL이 자동으로 적용되므로 별도로 입력해주지 않아도 된다.

 

Alias 레코드가 생성되어 Apex Domain으로 접속해 보면 정상적으로 인스턴스에 접근이 되는 것을 확인할 수 있다.

728x90

'인프라 > AWS' 카테고리의 다른 글

S3(Simple Storage Service), CloudFront, Elastic Beanstalk  (0) 2025.05.08
RDS(Relational Database Service), VPC(Virtual Private Cloud)  (0) 2025.05.08
Elastic Cloud Computing(EC2), 인스턴스 다루기, SSH 접속, EBS, AMI  (1) 2025.05.07
AWS 소개, IAM(Identity and Access Management)  (0) 2025.05.06
'인프라/AWS' Related Articles more