[AWS] CloudFront로 EC2 인스턴스를 HTTPS로 서비스하는 가장 간단한 방법

CloudFront로 EC2 인스턴스를 HTTPS로 서비스하는 가장 간단한 방법

AWS에서 CloudFront를 활용해 SSL 인증서 관리가 필요 없는 가장 간단한 EC2 호스팅 시스템을 구축해보자.

구상도

사이드 프로젝트, 빨리 올려보고 확인해야하는 상황(스타트업), 관리 리소스 최소화 등이 목적인 개발자를 대상으로 한다.

---

CloudFront의 다양한 Origin 유형 지원

CloudFront

CloudFront는 초기에 정적 파일을 전세계에 빠르게 제공하기 위한 CDN + 캐싱 서비스로 널리 알려져 있었다.

그렇기에 S3에 올라간 파일을 제공하는 사례가 대부분이지만, 사실 CloudFront는 동적 컨텐츠를 대상으로도 CDN을 적용할 수 있다.

 

실제로 CloudFront는 S3 뿐만 아니라 ELB, API Gateway 등 인터넷에서 접근 가능한 HTTP/HTTPS 서버라면 모두 Origin(프록시 대상)으로 사용할 수 있다.

---

HTTPS 서버 구축의 번거로움

직접 개발한 API 서버 등 WAS를 호스팅하려 할 때 개발자들이 항상 겪는 문제점은 HTTPS로 실행하기 위한 사전 절차와 비용이 너무 까다롭다는 것이다.

 

다음은 사용자가 많이 없는 서비스를 운영한다는 가정하에 자주 거론되는 방식들을 비교해 본 내용이다.

 

	EC2 + CloudFront + ACM SSL	EC2 + ELB + ACM SSL	EC2 + Let's Encrypt SSL
요금	EC2 활성 시간 만큼 청구, CloudFront 트래픽 만큼 청구	EC2 활성 시간 만큼 청구, ELB 활성 시간 만큼 청구(종류별 청구 기준 다름)	EC2 활성 시간 만큼 청구
SSL	무료, 관리 X	무료, 관리 X	무료, 3개월마다 갱신 및 인증 필요, WAS 부팅 옵션에 SSL 관련 설정 필요
장점	트래픽 낮을 시 사실상 CloudFront 무료, 트래픽 증가 시 ELB를 두어 부하 분산 가능, 방화벽으로 DDoS 방어 가능, 구축이 간단함	트래픽 증가 시 여러 EC2로 쉽게 부하 분산 가능	간단한 아키텍처
단점	트래픽 증가 시 비용 상승	트래픽 없어도 ELB 고정 비용 지출, ELB 구성을 위한 네트워크 사전 지식 필요 (VPC, subnet, CIDR)	확장성 제한 (단일 EC2 인스턴스), 주기적인 SSL 인증서 관리 부담

두 번째, 세 번째 방식은 구글링하면 많이 나오는 정석적인 방식인데, 두 번째 방식은 고정 지출 증가와 VPC 구축을 위한 네트워크 지식이 필요하다는 약간의 러닝커브가 있다. 세 번째 방식은 제일 간단한 아키텍처를 하고 있지만 3개월마다 인증서 갱신과 재인증이 필요하며 WAS를 실행할 때 옵션을 주어야해서 소스코드의 수정이 발생할 수 있다. (node.js = http.createServer(options), spring = application.yml)

 

하지만 첫 번째 방식을 사용하면 더 간단하고 저렴하고 주기적인 관리 없이 HTTPS를 호스팅 할 수 있다.

---

선행 작업

이 글은 프록시 대상이 될 EC2 인스턴스와 ACM SSL 인증서가 있어야 진행 가능하므로 아직 생성하지 않았다면 아래 링크에서 먼저 작업을 완료해야한다.

[AWS] EC2 인스턴스 구축하기

---

1. CloudFront를 EC2로 연결

CloudFront 배포 페이지에 접속하여 배포 생성 버튼을 클릭한다.

 

우선 CloudFront에서 Origin으로의 연결을 설정해야한다.

 

Origin 설정

Origin Type으로 Other를 선택, Custom Origin에는 WAS가 실행되고 있는 EC2의 public 도메인 주소를 입력한다.

 

Origin 설정

 

EC2에서 실행중인 서버의 HTTP 포트 번호를 입력한다.

 

CloudFront로의 Request가 발생하면 CloudFront는 해당 EC2의 포트 번호로 접속을 시도하게 될 것이다.

 

CloudFront 설정

다음으로 CloudFront 자체의 프로토콜 선택 및 캐싱 정책을 설정해야한다.

 

API처럼 항상 최신 데이터를 요청해야하는 경우 캐싱 정책은 CachingDisabled, 원본 요청 정책은 AllViewer로 설정한다.

 

WAF 설정

CloudFront에 WAF 방화벽을 설정하여 DDoS로부터의 공격을 막아낼 수도 있으나, 기본 요금이 월 8달러부터 시작하므로 요청량이 낮은 프로젝트에는 비활성화를 추천한다.

 

마지막으로 설정을 검토하고 Create distribution을 클릭하여 배포를 생성한다.

 

CloudFront는 전 세계의 단위로 배포되기 때문에 각 거점에 배포 완료되기까지 시간이 10~15분정도 걸릴 수 있다.

 

배포 완료 후 대시보드에 표시된 도메인으로 접속하면 EC2에 올려둔 페이지로 접속이 성공하는 것을 볼 수 있다. 이때 CloudFront가 생성해준 도메인은 SSL 인증서가 기본으로 적용되어 바로 HTTPS 접속을 할 수 있다.

---

2. (별도 도메인을 사용할 경우) CloudFront에 대체 도메인과 인증서 등록

CloudFront는 기본 도메인을 제공하지만 본인 소유의 도메인을 등록하여 사용할 수도 있다. 이것을 대체 도메인이라고 한다.

 

CloudFront 배포 대시보드에서 Add domain을 클릭한다.

 

사용할 도메인을 입력한다.

 

ACM으로 발급한 SSL 인증서도 선택한다.

 

마지막으로 설정을 검토하고 Add domains을 클릭하여 도메인을 등록을 완료한다.

 

CloudFront에서 해야할 설정은 완료했다.

 

이제 대체 도메인으로 접속된 트래픽을 CloudFront 도메인으로 안내하는 DNS 라우팅 설정을 해야한다.

 

CloudFlare의 DNS 관리 메뉴

각자 본인이 사용중인 DNS 관리 서비스(Route 53 등)에 들어가서 본인 소유의 도메인이 CloudFront의 도메인을 향하도록 CNAME 형식으로 설정해주면 된다.

 

이제부터는 본인 소유의 도메인으로 접속하면 CloudFront 도메인으로 연결된다.

---

발생 가능한 오류들

다음은 구축 과정에서 발생했던 오류 목록이다.

504 Gateway Timeout ERROR

The request could not be satisfied.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront) HTTP3 Server Request ID: Z9-RABPlJ63LCmG4vAirwXeg6ChJ1HHYBUZD6uBXK1PMudZF2ePGRw==

 

CloudFront에서 Origin으로의 연결 설정이 제대로 되지 않은 경우 504 오류가 발생할 수 있다.

대표적인 실수로는 올바르지 않은 EC2 포트 번호로 안내했다거나, EC2의 Security Group에서 인바운드 트래픽을 허용하지 않았거나, EC2에서 서버 프로그램이 실행 중이 아닌 경우가 있다.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

인증서 불일치 오류

SSL 인증서를 등록하고 DNS 라우팅까지 설정했어도 CloudFront에 대체 도메인 등록을 누락했다면 ERR_SSL_VERSION_OR_CIPHER_MISMATCH 오류가 발생한다.

 

다만, 대체 도메인 등록과 SSL 인증서를 동시에 선택하도록 AWS가 CloudFront를 개편했기 때문에 글 내용을 잘 따라했다면 이 오류는 발생하지 않을 것이다.