20241223 TIL: api gateway에서 custom domain을 사용해서 porkbun 도메인과 연결하기 [진행중]

현재까지 내가 이해한 상황은 다음과 같다. 

여기서 API gateway 이후의 작업은 현재 상황에서는 일단은 동작하는 것으로 이해했다. 그렇다면 그 이전의 작업인 '우리 서버 도메인 엔드포인트로 요청을 보냈을 때 API gateway를 찾아내는 작업'을 해 주면 되겠다. 

 

즉 지금은 api gateway에 기본으로 할당된 길고 이상한 도메인 주소를 입력하면 연결은 되는데, 그걸 바라지는 않는다. 간결하고 깔쌈한 도메인 주소를 입력했을 때 연결이 되도록 바꿔보자. 

 

원래는 route53이라는 aws의 호스팅 서비스를 사용하려고 했다. 다만 기존에 porkbun이라는 사이트에서 구매해 둔 도메인 레코드가 있어서 그걸 쓰려고 하는데, 이걸 route53과 연결하면 되지 않을까? 라는 생각이 들었다. 

 

다만 기존과는 상황이 좀 달라진 게, 기존에는 route53에 ALB 레코드를 연결해서 사용했었다. 그런데 이제는 lambda를 사용하기 때문에 이 lambda를 호출하는 일종의 프록시 역할을 해 주는 api gateway를 route53과 연결해야 한다고 이해했었다. 

 

그런데 또 찾아보니 api gateway에는 custom domain(사용자 지정 도메인 이름)이라는 기능이 있었다. 이를 통해서 내가 원하는 도메인 이름을 지정한 다음에, 그 도메인 이름을 내가 갖고 있는 api gateway의 api와 연결시킬 수 있었다. 

 

물론 당연히 아무 이름이나 연결하면 바로 사용할 수 있는 것은 아니었다. 사용하려는 도메인 이름을 입력한 다음에는 그 이름을 사용할 수 있음을 입증하는 aws certificate manager의 인증서가 필요했다. 이 인증서는 또 어떻게 발급받을 수 있냐 하면, aws certificate manager 서비스로 이동해서 인증서를 만든다. 여기에는 옵션으로 'DNS 인증'과 '이메일 인증'이 있는데, 본인이 도메인을 직접 타 혹은 aws route53 사이트 등에서 구매했다면 DNS 인증을 누르면 된다. 그리고 그냥 완료를 누르면 인증서가 생성된다. 

 

다만 이 인증서는 처음에 생성되었을 경우에는 '검증 대기 중'일 것이다. 정확히 어떤 검증 과정이 일어나는지는 모르지만(모르니까 일단은 블랙 박스로 가정하고 넘어가자), 검증이 완료되면 'issued(발급됨)' 이라고 뜬다. 이렇게 말이다. 

 

물론 아무것도 안 하고 마법처럼 발급이 되는 것은 아니다. 나의 경우 porkbun이라는 외부 사이트를 사용했는데, 이처럼 외부 사이트를 사용한 경우에 대해서만 간단하게 기록해 보겠다. 

 

우선 인증서가 발급이 완료되면 'cname 레코드'라는 것이 생성된다.

 

이 키-값 형태의 레코드를 가지고 porkbun이나 기타 본인이 등록한 외부 사이트에 로그인해서 내가 구매한 레코드의 편집 화면으로 가 보자. 나의 경우는 다음과 같다. 

 

여기서 레코드에 상세 정보 등을 보면 NS 또는 DNS 레코드를 편집할 수 있다. (porkbun의 경우는 있다.) 이런 화면에서 DNS 레코드를 추가해 준다. 이때 cname 타입의 레코드를 추가하고, host name과 value의 값을 입력해야 한다. 이 값은 위에서 aws certificate manager 인증서를 발급했을 때 나온 키와 값을 그대로 적어주면 된다. 그리고 기다리면 된다. 

 

이 기다리는 과정이 제법 난관이었던 것이, 몇 초만에 반영이 되는 게 아니고 최대 24시간을 기다려야 한다. 물론 대부분은 몇 분 이내 발급된다. 그러나 몇 분이 애매하게 지나면 아직 발급이 안 된 건지 아니면 내가 뭘 잘못 작성한건지 싶어서 조금씩 손을 보게 된다. 나도 10분 이상은 기다린 것 같은데, 대략 10분 정도가 넘었는데 별 소식이 없다면 한 번쯤 잘못 작성한 부분이 있나 점검해보는 것도 좋을 것 같다. 

 

암튼 이렇게 해서 api gateway의 custom domain 설정을 위한 aws certificate manager의 인증서를 발급받았다. 이제 이 인증서를 사용해 주자. api gateway 서비스의 '사용자 지정 도메인 이름'으로 들어가서 '도메인 이름 추가'를 눌러주자. 

 

그러면 총 6가지를 선택하라고 나온다. 사실 정답은 없지만 나의 경우 두 가지만 직접 설정해주면 되고 나머지 기본으로 되어있는 옵션은 그대로 둬 봤다. 

• 도메인 이름: 연결하고 싶은, 정확히는 아까 aws 외부/내부에서 등록했던 도메인의 이름을 적는다. 
• 도메인 퍼블릭/프라이빗 여부: 공용에서 접근할 수 있는 것을 원한다면 기본값인 퍼블릭으로 두면 되겠다. 
• api 엔드포인트 유형: 나는 권장하는 옵션인 '리전별(권장)'으로 두었다. 
• 최소 TLS 버전: 기본값인 1.2를 그대로 두었다. 
• 상호 TLS 인증 사용: 안 사용하는 기본값으로 두었다. 
• ACM 인증서: 방금 전 발급받은 certificate manager의 인증서를 넣어주자. 

그러면 이런 기쁜 소식을 접할 수 있다. 

 

그래서 나는 다 된 줄로만 알았다. 호기롭게 postman에 새로 발급받은 도메인을 입력해 보았을 때 말이다. 그런데 안 되는 게 아닌가. http로 연결하면 기본 주소로 돌아오고, https로 연결하면 '지원되지 않은 프로토콜을 사용한다'고 떠서 추가적인 처리가 필요하다고 생각했다. 

 

GPT 질의로 간단하게 알아볼 수 있겠지만 우선 혼자서 생각해 봤다. 뭐가 더 필요할까?

1. HTTP로 연결하면 기본 주소로 돌아오는 경우, route53 등의 aws 서비스에 추가적인 연결이 필요할 수도 있겠다. 왜냐하면 현재는 porkbun의 레코드로 호스팅이 되는 상태이고, 그런데 정확히는 porkbun의 ns(name server) 레코드 값으로 route53에서 새로 호스팅 영역을 생성했을 때 받은 기본 ns 레코드의 값을 넣어 주었다. 그러니까 현재는 아마도 해당 도메인으로 연결이 들어오면 'DNS 서버 -> porkbun -> route53' 식으로 요청이 전달된다고 나는 이해했는데, 이 route53과 api gateway의 custom domain을 별도로 연결해 준 적이 없어서 aws lambda로 요청이 전달되지 않는다고 볼 수도 있겠다. 
2. HTTPS로 연결하면 '지원하지 않는 프로토콜'이라고 뜨는 경우, 도메인 그 자체보다는 프로토콜의 문제이므로 ACM 인증서와 관련된 문제일 것이라고 추측했다. 

이제 이 답을 가지고 GPT 질의를 해 보자. 

[문제 상황]과 [문제 상황에 대한 추측]을 바탕으로 [문제 상황에 대한 추측]이 적절한지 알려주고 만약 아니라면 다른 해결책을 제시해줘

[문제 상황]
현재 porkbun이라는 외부 사이트에서 도메인을 하나 구입하고, route53에서 호스팅 영역을 하나 생성한 뒤 기본으로 생성된 ns 레코드의 값을 porkbun에서 구매한 도메인의 ns 레코드 값으로 넣어 주었다. 또한 api gateway의 api에서 이 도메인을 사용하는 것이 목표였으므로 api gateway의 api에 대해서 custom domain 레코드를 만들어 주었다. 이를 위해서 porkbun 도메인에 대한 acm 인증서도 만들어 주었다. 

그러나 postman에 새로 발급받은 도메인을 입력해 보았을 때, http로 연결하면 기본 주소로 돌아오고, https로 연결하면 '지원되지 않은 프로토콜을 사용한다'는 문제가 발생하여 추가적인 처리가 필요하다고 생각했다. 

[문제 상황에 대한 추측]
1. HTTP로 연결하면 기본 주소로 돌아오는 경우, route53 등의 aws 서비스에 추가적인 연결이 필요할 수도 있겠다. 왜냐하면 현재는 porkbun의 레코드로 호스팅이 되는 상태이고, 그런데 정확히는 porkbun의 ns(name server) 레코드 값으로 route53에서 새로 호스팅 영역을 생성했을 때 받은 기본 ns 레코드의 값을 넣어 주었다. 그러니까 현재는 아마도 해당 도메인으로 연결이 들어오면 'DNS 서버 -> porkbun -> route53' 식으로 요청이 전달된다고 나는 이해했는데, 이 route53과 api gateway의 custom domain을 별도로 연결해 준 적이 없어서 aws lambda로 요청이 전달되지 않는다고 볼 수도 있겠다. 
2. HTTPS로 연결하면 '지원하지 않는 프로토콜'이라고 뜨는 경우, 도메인 그 자체보다는 프로토콜의 문제이므로 ACM 인증서와 관련된 문제일 것이라고 추측했다. 

 

답으로는 1번, 2번의 추측 모두 상당히 가능성이 높다는 평을 받았다. GPT가 제시한 방법도 모두 1번, 2번에 해당하는 방법들이었다. 이 정도면 나름의 신빙성을 1차로 확보한 셈이니 우선 이 방법들을 실행해 보기로 했다. 

 

우선 1번부터 실행해 보자. Route53 서비스에 A(alias)타입 레코드를 생성하고, '별칭'을 활성화시켜서 api gateway에서 등록한 custom domain 레코드를 등록해 주었다. 

 

그런데 좀 이따 깜빡한 것 하나를 알았다. api gateway의 custom domain 페이지로 가 보면 아래 'api 매핑'이라는 것이 있는데 이걸 안 해줬다. 즉 custom domain 레코드를 생성한 다음에 api gateway의 api와 매핑을 해 주었어야 했다. 나는 이걸 깜빡했어서 뒤늦게 추가해 주었다. 

 

그런데도 안 된다. 현재까지 내가 이해한 연결 과정을 정리해보고, 빠뜨린 부분이 있는지를 찾아보자. 

✅ 궁금한 점

1. aws certificate manager 서비스에서는 어떤 과정을 거쳐서 인증서를 검증할까?
2. api gateway의 custom domain은 무슨 역할을 하는 서비스이며, route53 서비스와는 어떤 차이점이 있을까?