[AWS] 배포 자동화: Route53 활용 + 도메인 HTTPS 적용

이번 포스트에서는 구매한 도메인을 Routh 53을 활용하여 도메인 HTTPS 적용까지 적용한 내용을 기술 하려고 합니다. 

이 글은 공부를 하면서 알게 된 내용들을 기록하는 글입니다. 오류나 고쳐야 할 사항들이 있다면 지적 부탁드립니다.

 

가비아 도메인 구매 및 연결

가비아에서 도메인 구매는 아래 글을 참고 했습니다.

https://this-circle-jeong.tistory.com/179

[Server] 가비아 도메인 구매 및 연결

 

구매한 도메인을 AWS Route53 서비스를 통해 주소를 연결하는 방법을 알아보도록 하자. 

---

Route 53

1. AWS Route 53에 접속 - 호스팅 영역 -  호스팅 영역 생성 (호스팅 영역 이름에 구매한 도메인 입력)

2. 레코드 중 유형이 NS인 것을 확인할 수 있는데 거기에서 “값/트래픽 라우팅 대상”이 4개 생긴것을 확인할 수 있음

---

Gabia

1. My 가비아 -> 서비스 관리 -> 도메인 통합 관리툴

2. 도메인 정보 변경 -> 네임 서버 설정

3. Route 53 레코드의 NS에 해당하는 4개의 값을 차례대로 입력한다. 이 때 마지막에 .은 제외하고 입력한다.

---

AWS Certificate Manager (ACM)

1. AWS Certificate Manager(ACM)에 접속 후, 퍼블릭 인증서 요청 클릭

 

2. 완전히 정규화된 도메인 이름에는 구매한 도메인의 이름을 작성한 이후 요청

ex) *. 도메인 주소

 

 

3. 생성한 인증서 ID를 클릭 -> Route 53에서 인증서 생성 클릭 -> 아까 생성했던  호스팅 그룹?이 있으면 선택 후 레코드 생성

 

대략 10분 후에 인증서 발급 완료

---

AWS Load balancer 적용

1. EC2 - 로드 밸런싱 - 대상 그룹 - 대상 그룹 생성

 

2. 대상 그룹 생성에 필요한 데이터 입력

대상 그룹 이름에는 자신이 원하는 이름을, 대상 유형은 인스턴스, 포트는 8080으로 설정

 

프로토콜 버전 설정에 대해 비교한 내용은 다음과 같습니다. 

버전	전송 방식	주요 특징	장점	단점
HTTP/1.1	TCP	요청마다 연결 생성, 순차 처리	구현 간단, 널리 사용됨	느린 속도, 연결 낭비
HTTP/2	TCP	멀티플렉싱(Multiplexing), 헤더 압축	한 연결로 여러 요청 처리 가능	TCP 기반 → 지연 가능성
HTTP/3	UDP (QUIC)	HTTP/2의 단점 개선, 더 빠른 연결 성능	지연 최소화, TLS 기본 포함	최신 기술, 지원 미비 가능성
gRPC	HTTP/2 위	이진 데이터 (Protocol Buffers) 사용	빠름, 서비스 간 통신에 최적화	브라우저 직접 호출 어려움

 

3. 상태 검사 등록 : 프로토콜 HTTP, 상태 검사 경로 /api/health-check (해당 컨트롤러가 있다는 가정)

4. 생성된 대상 그룹을 누르고 하단에 “대상” 선택 -> 대상 등록 -> 원하는 EC2 인스턴스 선택

인스턴스의 상태가 unhealthy인 경우, 하단의 “상태 검사” 탭 클릭 -> 편집 ->  200을 뱉어내는 임의의 API를 생성한 후 등록합니다

임의의 API 과정은 3번

 

4. 로드밸런서 탭 클릭 -> 로드밸런서 생성 버튼 클릭

5. 로드 밸런서 유형 Application Load Balancer 선택

6. 로드 밸런서 이름은 원하는 이름으로 선택, 체계는 인터넷 경계(Internet-facing), IP 주소 유형은 IPv4로 선택

7. 매핑에서 가용영역 선택 시 2개 이상 선택하되 반드시 EC2가 있는 가용영역은 포함할 것

** 가용영역 확인하는 방법 - EC2에서 조회

8. 보안그룹은 대상 EC2에서 사용하고 있는 보안그룹 선택 혹은 보안그룹 생성 및 선택(HTTPS, HTTP 둘 다 오픈)

9. 리스너 및 라우팅에서 리스너 추가 (포트 80, 443 추가, 대상 그룹은 생성한 것으로 설정)

10. HTTP로 접속 시, HTTPS로 리다이렉트 되도록 설정

---

Rout 53 라우팅 설정

1. 레코드 생성 - 단순 라우팅 선택 (빠른 생성 전환으로 되어 있을 수 있음)

2. 루트 도메인 혹은 하위 도메인으로 레코드 이름 설정

단, ACM 과 동일한 도메인 설정이어야 합니다. 

항목	CASE 1: 도메인.dev 루트 도메인 접속	CASE 2: api.도메인.dev 서브 도메인 접속
1. 도메인 유형	루트 도메인 (naked domain)	서브 도메인
2. ACM 인증서	도메인.dev 또는 *.도메인.dev에 포함되어야 함	*.도메인.dev로 충분함 (api.도메인.dev 포함됨)
3. Route 53 레코드	A 레코드 또는 ALIAS로 도메인.dev → ALB 연결	A 레코드 또는 ALIAS로 api.도메인.dev → ALB 연결
4. ALB 리스너 인증서	도메인.dev 포함된 인증서가 등록되어야 함	*.도메인.dev 인증서만으로 충분 (하위 도메인 포함됨)
5. 정상 접속 조건	인증서와 Route 53 레코드 모두 도메인.dev에 명확히 지정돼야 함	하위 도메인이므로 상대적으로 단순, 대부분 자동 처리됨
6. 흔한 실수	*.도메인.dev 인증서만 발급하고 루트 도메인을 포함 안함	Route 53에 레코드 추가 안 했거나 오타 문제

 

 

Route 53과 ACM은 프리티어 내에서도 사용할 수 있지만, Route 53의 Hosted Zone에는 월 $0.50의 비용이 발생합니다.

그럼에도 불구하고 많은 사용자들이 Route 53을 선택하는 이유는 무엇일까?

 

사용 이유	설명
통합된 AWS 인프라 관리	Route 53 + ACM + CloudFront + ALB 구성 시 모든 것이 AWS 내에서 자동화되고 통일성 있음
ACM 인증서 자동 갱신	AWS Certificate Manager(ACM) 사용 시 인증서 자동 갱신 가능 (단, ALB/CloudFront에서만 사용 가능)
고가용성 & 복잡한 트래픽 관리	가중 라우팅, 헬스체크, 지역 기반 라우팅 등 고급 DNS 기능
DevOps 자동화	IaC(Terraform/CDK) 등에서 Route 53 리소스와 연동하기 쉬움
CloudFront 연동 최적화	CloudFront에서 맞춤 오리진 도메인을 Route 53에서 쉽게 연결 가능

 

반면, Rout 53 없이 HTTPS 연결은 가비아 도메인 + EC2 + Nignx + 무료 인증서만으로도 충분히 가능합니다. 

단, 인증서 갱신은 수동 또는 별도 스크립트를 통한 자동화가 필요합니다.

---

[참고] Nignx 로 연동 방법

앞에서는 AWS 기반 설정(Route 53 + ACM + ALB)을 중심으로 설명했지만,
꼭 AWS 서비스만 사용하는 건 아닙니다.

직접 EC2에 Nginx를 설치하고 인증서(Let's Encrypt 등)를 적용해 HTTPS 리버스 프록시를 설정하는 방식도 널리 사용되니,

운영 환경이나 예산, 학습 목적에 따라 적절한 방식을 선택하면 됩니다.

 

https://ye5ni.tistory.com/132

[ec2 2탄] 가비아에서 도메인 구매 후 연결하기 & HTTPS 적용하기

https://growing-nyang.tistory.com/75

nginx / nginx 환경설정 및 도메인(domain) 변경 방법

---

참고자료

https://m42-orion.tistory.com/141

[AWS] Domain & HTTPS 적용하기