AWS 호스팅 및 메일 설정기

최근 AWS 인프라를 직접 구성하기 시작하면서 여러 서비스들을 이용하고 있는데, 그 중 Route53을 이용한 호스팅 서비스와 메일 서비스를 사용하게 되었다. 전자의 경우는 다른 AWS 서비스들과 호환성이 좋은 관계로 사용하기로 결정했고, 후자의 경우는 비슷한 이유로 자연스럽게 따라오게 되었다 (…) 이건 이후에 더 설명.

참고로 여기서는 아래와 같은 인프라 구조를 만들었다.

• A 호스팅(네임서버)에서, B 호스팅(네임서버)로 라우팅하도록 DNS 설정하기
• https 통신하도록 하기
• TLS 메일서버 구축

🤔 이전에는 어떻게 했나?

저거 구축하려면 아마 아래처럼 했어야 됐을 것이다.

• A 인스턴스에서 nginx에서 리퀘스트 받고, domain명 확인 후 B 인스턴스로 proxy 해버리기
  • 이건 정말 비효율의 극치 😳 어플리케이션단에서 라우팅할 이유가 하나도 없다
• nginx에 SSL 정보 설정하기
  • 어딘가에서 cert 받아와야 하고, 꾸준히 갱신해줘야 함
• sendmail + TLS 구축
  • 이것도 cert 동일

이거 다 하는거 엄청 짜증난다! 그리고 꼭 하다 보면 한두개씩 문제가 생겨서 제대로 안 돌아감. 그때마다 문제 생긴 서버 정보 찾아서 ssh 들어가서, 뭐가 문제인지 확인하고, 고치고 하는 것 또한 일이다.

서로 다른 AWS 계정에서 서브도메인 공유하기

사실 공유 개념이 아니라 그냥 호스팅 넘겨주는 거였다 😅

1. A 계정에서 루트 도메인에 대해서 호스팅 존을 만들고, 거기에서 서브도메인을 만든다.
2. 이후 B 계정에서 그 “서브 도메인"에 대해서 호스팅 존을 만든다.
3. 다시 A 계정의 서브 도메인에서, routing에서 NS(네임서버) 설정하고, B 계정의 호스팅 존에 써진 네임서버를 복사/붙여넣기 하면 된다.

그러니까, 그냥 네임서버를 설정을 통해서 호스팅 존을 보도록 하게 하면 된다. 도메인 소유권 상관 할 필요가 없음. 이건 AWS 간 서비스 말고 다른 vendor간에서 DNS 설정할때도 동일하게 할 수 있음.

dig 명령어로 제대로 적용이 되었는지 확인 가능하다. DNS 캐시를 안 타기 때문에 브라우저에 치는 것보다 정확함. 생각보다 DNS 변경사항 적용이 아주 오래 걸리지는 않더라… 길어야 10분?

ACM으로 도메인 인증받고 https 연결 설정하기

레코드를 추가해야 인증서가 나온다?

인증서를 발급하기 위해서는 그 호스팅(네임서버)을 반드시 가지고 있어야 함을 증명할 수 있어야 한다. 증명서는 호스팅명 기반으로 만들어지니까…

그런데 재미있는 게 AWS는 아래와 같은 논리로 이 과정을 자동화했다. “너 이 호스팅이 너꺼 맞아? 그러면 너의 호스팅에 레코드를 추가할 수 있겠지? 이 레코드 추가해봐!” 하면서 추가해야 할 레코드를 준다.

이를테면 [api.test.com](http://api.test.com) 이라는 호스팅존을 가지고 있고, *.api.test.com 에 대해 인증서 발급을 요청하면? _abcdefghijk.api.test.com 에다가 _blahblahblah.acm-validation.aws CNAME 레코드를 추가해 보라는 것이다.

제대로 설정하면 10분? 20분? 이면 금방 처리가 완료된다. 심지어 Route53에 도메인이 있으면 자동으로 추가까지 해준다. 그리고… 결정적으로 ACM의 인증서(private pem)는 반출이 안 된다. AWS 내 서비스에서 자체 연결이 되서 사용할 수 있는 방식이다.

이래서 AWS에 한번 엮이면 벗어날 수가 없다!

인증서와 호스팅을 들고 LB에 연결하기

호스팅에서 A 레코드로 LB에 연결하도록 하고, ACM ARN을 LB에 설정해주면 https 연결이 완료된다.

그럼 로드밸런서가 단순 부하 컨트롤만 해주는 것이 아니라, 인증서를 기반으로 https ⇒ http 트래픽으로 바꿔서 내부 서비스로 보내주는 역할도 해준다. 사실 nginx가 해주는 일을 대신 해준다고 볼 수 있음.

그래도 역시 좋은 건… 민감한 인증서 보안키 파일을 이리 들고 저리 들고 할 필요 없이 AWS에서 알아서 잘 관리해 준다는 점인것 같음.

AWS로 이메일 서비스 설정하기 — AWS SES

TLS 통신도 구조상 SSL과 비슷하다. 인증서가 필요하다. 인증서가 필요하다는 말은 호스팅(도메인)이 필요하다는 이야기로 또 연결된다. 그래서 ACM과 똑같이 도메인을 집어넣어야 한다!

인증되면 이메일 서비스를 사용할 수 있다! 단 기본적으로 sandbox 모드라서 아무데나 막 보낼 수는 없고…

심지어 MAIL FROM 도메인 세팅을 위한 값도 자동으로 보여주고, 버튼 한번 클릭하면 Route53 호스팅에 알아서 추가해준다! 편해도 너무 편함. 이러니 AWS 서비스 한번 쓰면 못 벗어나는게 아닐까….

• 어차피 나는 donotreply 용도로 쓰는거라 MX/TXT 레코드 딱히 필요없긴 한데 …

개인적으로 AWS 메일서버는 꽤 혜자인 편이라고 생각된다. 보낸만큼 비용청구하는것도 그렇고, 직접 메일서버 구성하는 게 상당히 까다로운 점과 메일서버 켜놓고 유지하는데만 드는 비용도 꽤 든다는 것을 감안하면…

이외에도 …

• Terraform으로 쉽게 인스턴스 및 서비스 설정이 가능한 것은 덤이다. 쓰고 있으면 On-demand 플랫폼에서 설정 만지는 듯한 기분이 들기도 하고
• 마냥 장점만 있는 건 아닌데, provider에 따른 제약이 있기도 하다. 일례로 AWS SES같은 경우는 sandbox 모드로 서비스가 기본 제공되고, 이걸 해제하려면 사유를 첨부하여 별도 신청을 또 해야 한다. 그래도 이게 이유가 없는 것도 아니고(스팸메일 방지), ISP 자체에서 막는 것도 있다는 걸 감안하면 타사 대비 도찐개찐이지 않나…
• 궁금한 게, 도메인 인증하는 취지는 좋은데 왜 CNAME 을 저렇게 여러개를 가져다 쓰라고 나오지? 인증 서버 부하를 분산하기 위해서? 아니면 다른 이유가 있나... 그냥 궁금하네.