AWS Load Balancer, Route53 로 서브도메인 https 적용

새로운 프로젝트를 만들었는데 이 프로젝트의 도메인을 따로 사기 보다는 기존에 갖고 있는 도메인의 서브도메인을 만들기로 했다.

 

목표를 달성하기 위해 aws load balanacer, route 53, target group 등을 공부하면서 내가 이해한 내용을 정리했다.

 

 

목표

1. 현재 나는 'sehyun-portal.com' 이라는 도메인을 squarespace 에서 구매해서 소유하고 있다.

https://www.squarespace.com

 

2. 이번에 만든 웹어플리케이션 instawebv2 는 aws ec2 인스턴스의 8080 번 포트를 사용하고 있다.

 

3. sehyun-portal.com 의 서브도메인 'instawebv2.sehyun-portal.com' 에 접근시 웹어플리케이션에 https 로 접근하도록 하고 싶다.

 

 

sehyun-portal.com 이 aws route53 가르키도록 하기

 

우선 https://www.sehyun-portal.com/ 이라는 도메인은 이미 내가 사용하고 있다.

해당 웹은 heroku 에 등록되어 있는 상태다.

서브 도메인 instawebv2.sehyun-portal.com 과는 별개로 이건 유지가 되어야하는데 instawebv2 는 aws ec2 에 있기 때문에 우선 sehyun-portal.com 의 네임서버가 aws route53 으로 오도록 할 것이다.

 

따라서 아래와 같은 흐름이 되도록 한다

1. 웹 브라우저가 'sehyun-portal.com' 을 네임서버에 요청한다
2. 최종적으로 route 53 에 나와있는 네임서버에 도달하도록 한다 

 

Route53을 DNS 서비스로 구성

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/dns-configuring.html

Amazon Route 53을 DNS 서비스로 구성 - Amazon Route 53

 

호스팅 영역을 생성한다. 

호스팅 영역의 이름은 도메인이랑 정확히 같아야 한다.

 

 

호스팅 영역을 생성하면 NS(네임서버) 와 SOA(도메인과 도메인에 속한 영역에 대한 정보를 제공하는 기본 dns 레코드) 레코드가 기본으로 생성되어 있다.

 

 

이 NS 를 domain provider, 나 같은 경우 squarespace 에게 알려주면 'sehyun-portal.com' 이라는 도메인이 실제 ip 주소를 찾을때 이 ns 에게 쿼리를 날릴수 있게 된다.

 

그리고 아래와 같이 CNAME 으로 heroku 의 dns target 을 설정해줬다.

 

 

그럼 이제 sehyun-portal.com 이 aws route53 이랑 연결된 것이고

실제 웹 어플리케이션도 CNAME 으로 연결해준 것이다.

 

 

 

 

서브도메인 생성

아래처럼 instawebv2.sehyun-portal.com 레코드를 만들어서 간단하게 서브 도메인을 생성할수 있다.

값에 실제 ip 를 넣어주거나, heroku 같은 곳에 배포했다면 레코드 유형을 CNAME 으로 해서 heroku 에서 주는 값을 넣어주면 된다.

 

그런데 나는 https 를 적용할 것이기 때문에 로드 밸런서를 경유해서 오도록 해야 한다.

 

Application Load Balancer 란 무엇입니까?

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

Application Load Balancer란 무엇입니까? - Elastic Load Balancing

 

 

로드 밸런서, 대상 그룹

로드 밸런서는 클라이언트에 대한 단일 접점 역할을 수행한다.

 

Target: EC2 인스턴스

Target group: 지정한 프로토콜과 포트 번호를 사용하여 등록된 하나 이상의 Target 으로 요청을 라우팅한다

Listener: 리스너에 규칙을 정하는데, 규칙에 따라 어떤 대상 그룹으로 요청이 라우팅 될지가 결정된다.

 

정리하자면 instawebv2.sehyun-portal.com 에 요청이 오면 먼저 로드밸런서를 거치는데,로드밸런서의 리스너에 정의된 규칙에 따라 target group 중 하나에 요청이 라우팅 되고,target group 중 target (ec2 instance) 1개에 최종적으로 라우팅 된다.

 

 

대상 그룹 설정

 

로드 밸런서의 리스너 규칙에 의해 라우팅이 전파될 대상그룹을 만든다.

내 웹 어플리케이션은 8080 포트를 사용하고 있기 때문에 대상 그룹의 포트는 8080이다.

 

로드 밸런서의 포트 vs 대상그룹의 포트

로드 밸런서 리스너의 포트랑 햇갈릴수 있는데 로드 밸런서 리스너의 포트는 로드 밸런서가 listen 하는 (요청을 받아들이는) 포트를 말한다.

 

대상그룹의 포트는 로드 밸런서에 의해 해당 대상그룹으로 요청이 라우팅되서 왔을때, 대상 그룹에 등록되어 있는 인스턴스의 몇 번 포트로 전달할지이다.

 

예를들어 로드 밸런서의 리스너 포트가 80 이고 대상 포트가 8080인 대상 그룹이 있다.

이 경우 로드 밸런서는 80 포트 에서 들어오는 요청을 수신 대기하고 8080 포트의 대상 그룹에 있는 인스턴스에 해당 요청을 전달한다.

 

ACM (Amazon Certificate Manager)

로드 밸런서를 만들때 https 를 사용하려면 인증서가 필요하다.

 

*.sehyun-portal.com 에 대한 인증을 받았다.

* 을 사용하면 모든 하위 도메인에 대해 허용한다는 뜻이다.

ex) instawebv2.sehyun-portal.com, abc.sehyun-portal.com

 

하지만 abc.def.sehyun-portal.com 처럼 하위의 하위 까지 허용하지는 않는다.

 

인증서를 받으려면 해당 도메인이 나의 소유라는 것을 인증해야 한다.

나는 위에서 route 53 에 도메인의 호스팅 영역을 생성했다.

그러면 그냥 route 53 에서 레코드 생성을 누르면 aws 가 알아서 인증을 받아준다.

 

로드 밸런서 설정 

로드 밸런서의 리스너는 아래와 같이 http:80 과 https:443 을 추가한다.

 

여기서 포트 번호가 의미하는 것은 로드 밸런서로 요청이 들어오는 포트 번호를 의미한다.

즉 80번 포트로 들어오는 요청은 어떤 식으로 처리하고, 443 포트로 들어오는 요청은 어떤식으로 처리하라고 내가 규칙을 정해주면 된다.

 

80번 포트는 http 기본 포트이고 뒤에 : 로 포트번호를 붙여 주지 않으면 기본적으로 80 번 이된다.

따라서 80번 포트로 오는 요청은 443 으로 리다이렉션 시켜준다.

 

443 포트로 오는 요청은 대상그룹으로 전달해주면 된다.

 

 

Route53 레코드 설정

 

instawebv2.sehyun-portal.com 서브 도메인에 대한 레코드를 생성해주면 된다.

여기서 별칭으로 로드 밸런서를 정해줄수 있다.

즉 해당 서브도메인으로 오는 요청을 내가 만든 로드 밸런서로 넘겨 주는 것이다.

 

 

전체 흐름

instawebv2.sehyun-portal.com 요청 -> 로드 밸런서 80번 포트로 들어오면 -> https 443 으로 리다이렉트 -> 443 포트로 들어오는 요청은 -> instawebv2 대상 그룹으로 전달 -> instawebv2 대상 그룹은 인스턴스의 8080 포트로 전달 

 

instawebv2.sehyun-portal.com 요청 -> 로드 밸런서 443번 (https) 포트로 들어오면 -> instawebv2 대상 그룹으로 전달 -> instawebv2 대상 그룹은 인스턴스의 8080 포트로 전달 

 

요약

Route 53 에 도메인을 등록하고

로드 밸런서를 만들어서 도메인에 오는 요청을 로드 밸런서가 받아서

내가 정한 규칙에 따라 내가 원하는 대상 그룹과 인스턴스에 라우팅시킨다 

 

 

 

이번에 aws ec2, route 53, load balancer 를 써보면서 왜 다들 AWS 를 사용하는지 일부나마 알게 됐다.

난 기존에 웹 어플리케이션을 배포하는데 heroku 를 썼었는데, aws 를 써보니 heroku 는 aws 에 비해 사실 별로 장점이 없는 것 같다. 배포 하나는 정말 정말 쉽다는 점 정도?