TIL - 20260612

juni·2026년 6월 12일

목록 보기

377/468

0612 AWS 운영 실무 기초 (5/N): Route 53, DNS와 SSL 인증서 관리

✅ 1. 도메인이란 무엇인가?

도메인(Domain)은 사용자가 웹사이트에 접속할 때 입력하는 사람이 읽기 쉬운 주소입니다.
실제 서버는 IP 주소로 구분되지만, 사용자가 매번 IP를 기억하기 어렵기 때문에 도메인을 사용합니다.

서버 IP:
123.123.123.123

도메인:
www.example.com
api.example.com
admin.example.com

웹서비스 운영에서는 도메인을 프론트엔드, 백엔드 API, 관리자 페이지, CDN 등에 각각 연결할 수 있습니다.

➕ 1-1. 실무에서 자주 쓰는 도메인 구조

www.example.com      → 고객용 프론트엔드
api.example.com      → 백엔드 API 서버
admin.example.com    → 관리자 페이지
cdn.example.com      → 이미지/정적 파일 CDN

도메인을 잘 나눠두면 서비스 구조가 명확해집니다.
프론트엔드, API, 관리자, 이미지 서버의 역할을 분리해서 관리할 수 있습니다.

✅ 2. DNS란 무엇인가?

DNS(Domain Name System)는 도메인을 실제 서버 주소로 변환해주는 시스템입니다.
사용자가 www.example.com에 접속하면 브라우저는 DNS를 통해 이 도메인이 어느 서버를 가리키는지 확인합니다.

사용자 입력:
www.example.com

DNS 조회:
www.example.com은 123.123.123.123을 가리킴

브라우저:
123.123.123.123 서버로 접속

➕ 2-1. DNS가 중요한 이유

도메인과 서버를 연결합니다.
API 서버, 프론트엔드, 관리자 페이지를 각각 다른 서버나 서비스로 연결할 수 있습니다.
CloudFront, EC2, Load Balancer, 외부 호스팅 서비스와 연결할 수 있습니다.
메일 인증, 사이트 소유권 인증, SSL 인증서 검증에도 사용됩니다.

✅ 3. Route 53이란 무엇인가?

Route 53은 AWS에서 제공하는 DNS 관리 서비스입니다.
도메인을 AWS 리소스와 연결하거나, DNS 레코드를 관리할 때 사용합니다.
AWS에서 도메인을 직접 구매할 수도 있고, 외부에서 구매한 도메인을 Route 53으로 연결해서 관리할 수도 있습니다.

➕ 3-1. Route 53에서 하는 일

도메인 구매
DNS 레코드 관리
EC2, CloudFront, S3, Load Balancer 연결
서브도메인 관리
도메인 소유권 인증
헬스체크 기반 라우팅
장애 시 다른 서버로 트래픽 전환

✅ 4. Hosted Zone

Hosted Zone은 Route 53에서 특정 도메인의 DNS 설정을 관리하는 공간입니다.
예를 들어 example.com이라는 도메인을 Route 53에서 관리하려면 example.com에 대한 Hosted Zone이 필요합니다.

Hosted Zone:
example.com

관리 가능한 레코드:
www.example.com
api.example.com
admin.example.com
cdn.example.com

➕ 4-1. Hosted Zone 생성 후 확인할 것

NS 레코드가 생성되었는가?
SOA 레코드가 생성되었는가?
도메인 등록 업체의 네임서버가 Route 53 NS로 변경되었는가?
DNS 전파가 완료되었는가?

✅ 5. 네임서버란 무엇인가?

네임서버(Name Server)는 특정 도메인의 DNS 정보를 어디에서 관리하는지 알려주는 서버입니다.
외부 도메인 업체에서 도메인을 구매하고 Route 53에서 DNS를 관리하려면, 도메인 업체의 네임서버를 Route 53에서 제공하는 NS 값으로 변경해야 합니다.

도메인 구매처:
가비아, 카페24, 후이즈, GoDaddy 등

DNS 관리:
AWS Route 53

해야 할 일:
도메인 구매처의 네임서버를 Route 53 NS로 변경

➕ 5-1. 네임서버 변경 시 주의점

DNS 전파에는 시간이 걸릴 수 있습니다.
보통 몇 분에서 몇 시간, 길면 24~48시간까지 걸릴 수 있습니다.
전파 중에는 어떤 사용자는 새 서버로, 어떤 사용자는 이전 서버로 접속될 수 있습니다.
운영 중인 도메인의 네임서버를 바꿀 때는 기존 DNS 레코드를 Route 53에 미리 옮겨둬야 합니다.

✅ 6. DNS 레코드 종류

➕ 6-1. A Record

A 레코드는 도메인을 IPv4 주소에 연결합니다.
EC2 서버의 고정 IP인 Elastic IP에 연결할 때 자주 사용합니다.

Type: A
Name: api.example.com
Value: 123.123.123.123

예시:

api.example.com → EC2 Elastic IP

➕ 6-2. CNAME Record

CNAME 레코드는 도메인을 다른 도메인으로 연결합니다.
CloudFront 도메인, 외부 서비스 도메인에 연결할 때 자주 사용합니다.

Type: CNAME
Name: cdn.example.com
Value: d123abcd.cloudfront.net

예시:

cdn.example.com → CloudFront 도메인

➕ 6-3. Alias Record

Alias 레코드는 AWS 리소스에 도메인을 연결할 때 사용하는 Route 53 전용 기능입니다.
CloudFront, Load Balancer, S3 정적 웹사이트 엔드포인트 등에 연결할 수 있습니다.

www.example.com → CloudFront Distribution

CloudFront를 Route 53에서 연결할 때는 보통 CNAME보다 Alias를 사용하는 경우가 많습니다.

➕ 6-4. TXT Record

TXT 레코드는 텍스트 값을 DNS에 등록하는 레코드입니다.
도메인 소유권 인증, 이메일 보안 설정, 외부 서비스 인증에 자주 사용됩니다.

Type: TXT
Name: example.com
Value: "google-site-verification=xxxxxxxx"

사용 예시:
- Google Search Console 소유권 인증
- 네이버 서치어드바이저 소유권 인증
- SPF 설정
- DKIM 설정
- DMARC 설정

➕ 6-5. MX Record

MX 레코드는 이메일 서버를 지정하는 레코드입니다.
회사 메일, Google Workspace, Naver Works 같은 서비스를 사용할 때 필요합니다.

Type: MX
Name: example.com
Value: mail server address

웹서비스만 운영하더라도 회사 도메인 이메일을 쓴다면 MX 레코드를 건드릴 때 조심해야 합니다.
잘못 수정하면 이메일 수신이 안 될 수 있습니다.

✅ 7. 서브도메인 설계

서브도메인은 메인 도메인 앞에 붙는 이름입니다.

www.example.com
api.example.com
admin.example.com
cdn.example.com

➕ 7-1. 실무 서브도메인 예시

서브도메인	용도
`www.example.com`	고객용 웹사이트
`api.example.com`	백엔드 API
`admin.example.com`	관리자 페이지
`cdn.example.com`	이미지/정적 파일
`dev.example.com`	개발 서버
`staging.example.com`	운영 전 검증 서버

➕ 7-2. 서브도메인 설계 시 주의점

운영과 개발 도메인을 구분해야 합니다.
관리자 페이지는 검색엔진에 노출되지 않도록 해야 합니다.
API 도메인은 CORS 설정과 함께 관리해야 합니다.
CDN 도메인은 캐시 정책과 SSL 인증서를 함께 확인해야 합니다.

✅ 8. Elastic IP와 도메인 연결

EC2의 Public IP는 인스턴스를 중지하고 다시 시작하면 바뀔 수 있습니다.
운영 서버에서는 고정 IP인 Elastic IP를 연결하는 것이 좋습니다.

➕ 8-1. EC2 도메인 연결 흐름

EC2 생성
  ↓
Elastic IP 생성 및 EC2에 연결
  ↓
Route 53에서 A 레코드 생성
  ↓
api.example.com → Elastic IP
  ↓
Nginx에서 server_name 설정

➕ 8-2. Route 53 A 레코드 예시

Type: A
Name: api.example.com
Value: EC2 Elastic IP
TTL: 300

TTL은 DNS 캐시 유지 시간입니다.
변경이 잦은 초기에는 짧게, 안정화 후에는 길게 가져갈 수 있습니다.

✅ 9. CloudFront와 도메인 연결

CloudFront는 기본 도메인을 제공합니다.

d123abcd.cloudfront.net

하지만 실제 서비스에서는 보통 커스텀 도메인을 연결합니다.

www.example.com
cdn.example.com

➕ 9-1. CloudFront 커스텀 도메인 연결 흐름

1. ACM에서 SSL 인증서 발급
2. CloudFront Alternate Domain Name에 도메인 추가
3. CloudFront에 인증서 연결
4. Route 53에서 Alias 레코드 생성
5. 도메인 접속 테스트

➕ 9-2. 주의점

CloudFront에 연결하는 ACM 인증서는 보통 us-east-1 리전에서 발급해야 합니다.
인증서 도메인과 CloudFront에 추가하는 도메인이 일치해야 합니다.
Route 53 레코드만 만들고 CloudFront에 Alternate Domain Name을 추가하지 않으면 정상 연결되지 않을 수 있습니다.

✅ 10. SSL 인증서란 무엇인가?

SSL/TLS 인증서는 HTTPS 통신을 가능하게 하는 인증서입니다.
사용자의 브라우저와 서버 사이의 데이터를 암호화합니다.
로그인, 상담 신청, 결제, 관리자 페이지처럼 개인정보를 다루는 서비스에서는 HTTPS가 필수입니다.

➕ 10-1. HTTPS가 필요한 이유

로그인 정보 보호
개인정보 보호
관리자 페이지 보안
중간자 공격 방지
브라우저 보안 경고 방지
SEO와 사용자 신뢰도 향상
Secure Cookie 사용 가능

HTTP:
데이터가 암호화되지 않음

HTTPS:
브라우저와 서버 사이 통신이 암호화됨

✅ 11. ACM이란 무엇인가?

ACM(AWS Certificate Manager)은 AWS에서 SSL/TLS 인증서를 발급하고 관리하는 서비스입니다.
CloudFront, Load Balancer, API Gateway 등에 SSL 인증서를 연결할 때 자주 사용합니다.
ACM 인증서는 자동 갱신이 가능해서 운영 관리가 편리합니다.

➕ 11-1. ACM 인증서 발급 방식

DNS 검증
이메일 검증
실무에서는 보통 DNS 검증을 사용합니다.
Route 53을 쓰고 있다면 ACM에서 제시하는 CNAME 레코드를 Route 53에 추가해서 인증할 수 있습니다.

✅ 12. ACM 인증서 발급 흐름

ACM 접속
  ↓
인증서 요청
  ↓
도메인 입력
  ↓
DNS 검증 선택
  ↓
CNAME 검증 레코드 생성
  ↓
Route 53에 검증 레코드 추가
  ↓
인증서 발급 완료

➕ 12-1. 인증서 도메인 예시

example.com
www.example.com
api.example.com
cdn.example.com
*.example.com

*.example.com은 와일드카드 인증서입니다.
api.example.com, admin.example.com, cdn.example.com 같은 1단계 서브도메인에 사용할 수 있습니다.

➕ 12-2. 와일드카드 인증서 주의점

*.example.com 적용 가능:
api.example.com
admin.example.com
cdn.example.com

*.example.com 적용 불가:
v1.api.example.com
dev.admin.example.com

와일드카드는 한 단계 서브도메인까지만 커버합니다.
더 깊은 서브도메인이 필요하면 별도 인증서나 추가 도메인이 필요할 수 있습니다.

✅ 13. EC2 + Nginx에서 HTTPS 적용

EC2에서 직접 Nginx를 운영하는 경우에는 보통 Let's Encrypt와 Certbot을 많이 사용합니다.
ACM은 CloudFront나 Load Balancer에는 쉽게 붙일 수 있지만, EC2 내부 Nginx에 직접 설치하는 방식과는 다릅니다.

➕ 13-1. Certbot 사용 예시

sudo apt install -y certbot python3-certbot-nginx

sudo certbot --nginx -d api.example.com

여러 도메인을 한 번에 발급할 수도 있습니다.

sudo certbot --nginx -d www.example.com -d api.example.com

➕ 13-2. 인증서 갱신 테스트

sudo certbot renew --dry-run

인증서 자동 갱신이 실패하면 어느 날 갑자기 사이트에 보안 경고가 뜰 수 있습니다.
운영자는 인증서 만료와 갱신 상태를 주기적으로 확인해야 합니다.

✅ 14. DNS 전파와 캐시

DNS 설정을 바꿨다고 해서 전 세계에서 즉시 반영되는 것은 아닙니다.
DNS는 여러 서버와 브라우저, 운영체제, 통신사 캐시에 저장될 수 있습니다.

➕ 14-1. DNS 전파가 필요한 상황

네임서버 변경
A 레코드 IP 변경
CNAME 변경
CloudFront 연결
TXT 인증 레코드 추가
MX 레코드 변경

➕ 14-2. 전파 중 나타날 수 있는 현상

내 PC에서는 접속됨
다른 사람 PC에서는 접속 안 됨

모바일 데이터에서는 접속됨
회사 와이파이에서는 접속 안 됨

www는 되는데 api는 안 됨

이 경우 서버 문제가 아니라 DNS 전파 또는 캐시 문제일 수 있습니다.

✅ 15. TTL이란 무엇인가?

TTL(Time To Live)은 DNS 레코드가 캐시에 얼마나 오래 남을지 정하는 값입니다.
TTL이 길면 DNS 조회가 줄어들어 안정적이지만, 변경 반영이 늦을 수 있습니다.
TTL이 짧으면 변경 반영이 빠르지만 DNS 조회가 더 자주 발생합니다.

TTL 300초:
5분 캐시

TTL 3600초:
1시간 캐시

TTL 86400초:
24시간 캐시

➕ 15-1. 실무 기준

도메인 전환 전: TTL을 짧게 설정
안정화 후: TTL을 적당히 길게 설정
운영 중 서버 IP 변경 예정: 미리 TTL을 낮춤

✅ 16. 도메인 연결 문제 해결 순서

➕ 16-1. 접속이 안 될 때 확인할 것

도메인 오타가 없는가?
Route 53 Hosted Zone이 올바른가?
네임서버가 Route 53으로 연결되어 있는가?
A/CNAME/Alias 레코드가 올바른가?
EC2 Elastic IP가 맞는가?
보안 그룹에서 80/443이 열려 있는가?
Nginx server_name이 도메인과 일치하는가?
CloudFront Alternate Domain Name에 도메인이 추가되어 있는가?
SSL 인증서 도메인이 일치하는가?
DNS 전파 시간이 충분히 지났는가?

✅ 17. HTTPS 문제 해결 순서

➕ 17-1. 인증서 오류가 날 때 확인할 것

인증서가 발급 완료 상태인가?
인증서에 현재 접속 도메인이 포함되어 있는가?
CloudFront에 올바른 ACM 인증서가 연결되어 있는가?
EC2/Nginx에서는 Certbot 인증서가 정상 적용되어 있는가?
인증서 만료일이 지나지 않았는가?
HTTP에서 HTTPS로 리다이렉트가 정상인가?
브라우저 캐시나 HSTS 영향은 아닌가?

✅ 18. 실무 체크리스트

➕ 18-1. 도메인 설정 체크리스트

도메인 구매처와 DNS 관리 위치를 알고 있는가?
Route 53 Hosted Zone이 생성되어 있는가?
네임서버가 올바르게 연결되어 있는가?
www, api, admin, cdn 서브도메인이 정리되어 있는가?
A, CNAME, Alias 레코드 역할을 구분하고 있는가?
MX/TXT 레코드를 수정할 때 메일 서비스 영향 여부를 확인하는가?

➕ 18-2. SSL 체크리스트

고객용 사이트에 HTTPS가 적용되어 있는가?
API 도메인에 HTTPS가 적용되어 있는가?
관리자 페이지에 HTTPS가 적용되어 있는가?
CloudFront용 ACM 인증서가 올바른 리전에 있는가?
Certbot 자동 갱신이 정상인지 확인했는가?
HTTP 접속 시 HTTPS로 리다이렉트되는가?
쿠키 인증을 쓴다면 Secure 옵션을 사용할 수 있는가?

➕ 18-3. 운영 변경 전 체크리스트

기존 DNS 레코드를 백업했는가?
네임서버 변경 전 기존 레코드를 Route 53에 옮겼는가?
TTL을 미리 낮췄는가?
변경 시간을 트래픽이 적은 시간대로 잡았는가?
변경 후 PC/모바일/다른 네트워크에서 접속 테스트를 했는가?
롤백할 기존 IP나 설정을 기록해두었는가?

✅ 19. AI를 활용해 DNS/SSL 문제를 해결할 때 질문법

DNS와 SSL 문제는 도메인, Route 53, CloudFront, EC2, Nginx, 인증서가 모두 연결됩니다.
AI에게 질문할 때는 도메인 구조와 현재 연결 방식을 같이 알려줘야 합니다.

➕ 19-1. 좋은 질문 예시

AWS Route 53 + CloudFront + S3로 React 프론트엔드를 배포했는데 www.example.com 접속 시 SSL 오류가 발생해.

상황:
1. 도메인은 외부 업체에서 구매함
2. 네임서버는 Route 53으로 변경함
3. S3에 React build 파일을 업로드함
4. CloudFront 배포를 생성함
5. Route 53에서 www.example.com을 CloudFront Alias로 연결함
6. ACM 인증서는 발급 완료 상태임
7. 그런데 브라우저에서 인증서 도메인이 맞지 않는다는 오류가 나옴

확인해야 할 순서를 알려줘.
특히 CloudFront Alternate Domain Name, ACM 리전, 인증서 도메인 포함 여부를 기준으로 설명해줘.

➕ 19-2. AI 답변 검증 기준

DNS 전파 시간을 고려하는가?
Route 53 레코드와 네임서버를 구분하는가?
A, CNAME, Alias 차이를 설명하는가?
CloudFront 인증서 리전을 확인하는가?
인증서에 접속 도메인이 포함되어 있는지 확인하는가?
EC2/Nginx와 CloudFront SSL 적용 방식을 구분하는가?
MX 레코드 변경 시 이메일 영향까지 주의시키는가?

📌 요약

도메인은 사용자가 접속하는 웹사이트 주소이고, DNS는 도메인을 실제 서버나 AWS 리소스에 연결하는 시스템입니다.
Route 53은 AWS의 DNS 관리 서비스이며, Hosted Zone 안에서 A, CNAME, Alias, TXT, MX 같은 레코드를 관리합니다.
EC2에는 보통 Elastic IP를 연결한 뒤 A 레코드로 도메인을 연결합니다.
CloudFront에는 커스텀 도메인, ACM 인증서, Route 53 Alias 레코드를 함께 설정해야 합니다.
SSL/TLS 인증서는 HTTPS 통신을 가능하게 하며, 개인정보와 로그인 정보 보호에 필수입니다.
CloudFront용 ACM 인증서는 보통 us-east-1 리전에서 발급해야 합니다.
EC2 + Nginx 구조에서는 Let's Encrypt와 Certbot을 이용해 HTTPS를 적용하는 경우가 많습니다.
DNS 변경은 즉시 반영되지 않을 수 있으며, TTL과 DNS 전파 시간을 고려해야 합니다.
운영 도메인을 변경할 때는 기존 레코드 백업, TTL 조정, 변경 후 접속 테스트, 롤백 계획이 필요합니다.

juni

이전 포스트

TIL - 20260611

다음 포스트

TIL - 20260612

TIL

0612 AWS 운영 실무 기초 (5/N): Route 53, DNS와 SSL 인증서 관리

✅ 1. 도메인이란 무엇인가?

➕ 1-1. 실무에서 자주 쓰는 도메인 구조

✅ 2. DNS란 무엇인가?

➕ 2-1. DNS가 중요한 이유

✅ 3. Route 53이란 무엇인가?

➕ 3-1. Route 53에서 하는 일

✅ 4. Hosted Zone

➕ 4-1. Hosted Zone 생성 후 확인할 것

✅ 5. 네임서버란 무엇인가?

➕ 5-1. 네임서버 변경 시 주의점

✅ 6. DNS 레코드 종류

➕ 6-1. A Record

➕ 6-2. CNAME Record

➕ 6-3. Alias Record

➕ 6-4. TXT Record

➕ 6-5. MX Record

✅ 7. 서브도메인 설계

➕ 7-1. 실무 서브도메인 예시

➕ 7-2. 서브도메인 설계 시 주의점

✅ 8. Elastic IP와 도메인 연결

➕ 8-1. EC2 도메인 연결 흐름

➕ 8-2. Route 53 A 레코드 예시

✅ 9. CloudFront와 도메인 연결

➕ 9-1. CloudFront 커스텀 도메인 연결 흐름

➕ 9-2. 주의점

✅ 10. SSL 인증서란 무엇인가?

➕ 10-1. HTTPS가 필요한 이유

✅ 11. ACM이란 무엇인가?

➕ 11-1. ACM 인증서 발급 방식

✅ 12. ACM 인증서 발급 흐름

➕ 12-1. 인증서 도메인 예시

➕ 12-2. 와일드카드 인증서 주의점

✅ 13. EC2 + Nginx에서 HTTPS 적용

➕ 13-1. Certbot 사용 예시

➕ 13-2. 인증서 갱신 테스트

✅ 14. DNS 전파와 캐시

➕ 14-1. DNS 전파가 필요한 상황

➕ 14-2. 전파 중 나타날 수 있는 현상

✅ 15. TTL이란 무엇인가?

➕ 15-1. 실무 기준

✅ 16. 도메인 연결 문제 해결 순서

➕ 16-1. 접속이 안 될 때 확인할 것

✅ 17. HTTPS 문제 해결 순서

➕ 17-1. 인증서 오류가 날 때 확인할 것

✅ 18. 실무 체크리스트

➕ 18-1. 도메인 설정 체크리스트

➕ 18-2. SSL 체크리스트

➕ 18-3. 운영 변경 전 체크리스트

✅ 19. AI를 활용해 DNS/SSL 문제를 해결할 때 질문법

➕ 19-1. 좋은 질문 예시

➕ 19-2. AI 답변 검증 기준

📌 요약

TIL - 20260611

TIL - 20260615

0개의 댓글