[AWS] EC2에 https 적용하기 (with. ALB)

부제: [프로젝트 배포 도전기 with AWS 프리티어]

(왜 했나요?)

얼마 전, 설득력있는 포트폴리오를 만들자는 취지로 ㅋ 과거 프로젝트 웹 배포를 진행했습니다.

AWS 프리티어의 EC2를 이용해 배포한 것인데요!!

 

구체적으로는, 클라이언트(React.js 프로젝트)는 GitHub Pages를 이용해 배포했고

API를 AWS EC2에서 배포하려고 했습니다.

(지금 생각하니 React 프로젝트도 그냥 한 서버에서 배포해볼 걸 그랬나 싶은데요?)

 

그러던 중, 이런 에러를 마주하게 된 것인데요..

HTTPS(보안 연결) 페이지에서 HTTP(비보안 연결)에 네트워크 요청을 보내는 게 이상하다고 합니다.

웹 브라우저가 보안을 위해 이런 Mixed Content 요청을 차단하기도 한다니.. 몰랐네요..

React에서 API를 호출할 때, API 주소를 http://EC2퍼블릭IP 이런 형식으로 바로 전달해 줬거든요..

 

Mixed Content가 안전하지 않은 이유는 다음과 같습니다.

• HTTPS 페이지는 웹 서버와의 연결이 TLS로 암호화되므로, 대부분의 중간자 공격으로부터 보호된다.
• 그런데, Mixed Content는 부분적으로만 암호화가 된 것이다!! → 공격자가 암호화되지 않은 컨텐츠에 접근할 가능성이 있다.
• 그런 페이지는 안전하지 않은 페이지이다.

 

그렇다면 이제 어떻게 할 것이냐?

1. 클라이언트도 HTTP 연결로 퇴화시키기 (😥 우우~)
2. API에서 HTTPS 연결로 바꿔줌으로써 보안을 강화하기 (😍 우와^^)

좋아보이는 게 하나 있죠?

 

그래서 인프라 공부도 할 겸, 시작하게 되었습니다.

 

1. Route 53

(1) AWS 콘솔 > Route 53 > 도메인 - 등록된 도메인 > 도메인 등록

 

 

 

(2) 도메인 검색 (표준 요금을 확인해 보세요!) > 선택

 

저는 제일 저렴한 .click 으로 선택했습니다.

3.00 USD로 1년간 사용할 수 있다니..^^

 

 

(3) 결제 진행..

자동 갱신은 비활성화 했습니다..

 

 

(4) 정보 입력

마지막으로 넘어가면 결제와 연락을 위해 필요한 정보를 입력하는 페이지가 나옵니다.

 

 

(5) 짜잔.. 생겼습니다.

 

(+) 도메인 이메일 인증

도메인을 생성하고 나면 @registrar.amazon 에서 메일이 와 있을 것입니다.

이메일에 첨부된 링크를 통해 이메일 인증을 해야 하며,

기간 내에 인증을 하지 않으면 도메인이 일시 중지될 것이라는 내용입니다.

저는 이걸 모르고 있어서 잠시 도메인이 suspend 되는 불미스러운 일이 발생했는데요^^

메일은 꼬박꼬박 확인하는 편인데, 이게 스팸 메일함에 들어가있어서 몰랐습니다..

 

2. 인증서 발급하기

그럼 이제 인증서를 발급받아야 합니다.

보안 연결이란 그런 것이니까..

 

(1) Certificate Manager > 인증서 > 인증서 요청 > 퍼블릭 인증서 요청

 

 

(2) 완전히 정규화된 도메인 이름 작성

Route 53에서 등록했던 도메인을 작성해주면 됩니다.

와일드 카드 문자(*)를 넣어 *.도메인.com와 같은 형식으로 작성해줄 수도 있는데요,

이것으로 해당 도메인의 모든 하위 도메인에 인증서가 적용되도록 할 수 있다고 합니다.

 

와일드 카드 추가 버전만 작성하면 그건 인식을 못하더라구요..

따라서, 기본ver도 와일드카드ver도 모두 사용하고 싶다면

'이 인증서에 다른 이름 추가'를 통해 별개의 도메인 이름으로 값을 포함해줘야 합니다.

 

 

(3) 검증 방법 설정

저는 권장되는 방법 & 널리 사용되는 방법을 택했습니다.

 

 

(4) 요청 완료 후, 해당 인증서 선택 > Route 53에서 레코드 생성

 

 

(5) Route 53에서 등록했던 도메인 선택 > 레코드 생성

 

(6) 인증서가 발급되기를 기다리기

저는 10분 이내로 발급 완료되었습니다.

 

근데 잠깐만요!!! 이것 보고 가세요

https://aws.amazon.com/ko/about-aws/whats-new/2024/02/aws-free-tier-750-hours-free-public-ipv4-addresses/

AWS 프리 티어, 이제 퍼블릭 IPv4에 대한 요금이 부과됨에 따라 750시간의 무료 퍼블릭 IPv4 주소 사

 

저는 이걸 몰라서 요금을 더 내게 된 것 같습니다.

(현재 25년 6월 4일, 아직 확실한 건 아니고 의심중)

 

혹시 이 글을 보면서 설정하고 계신 분이 계시다면

cloud front를 이용한 방법을 찾아보시기를 추천드립니다!! (저도 다시 시도할 예정!!)

 

(25년 6월 5일, CloudFront 적용 & 게시글 추가 작성 완)

https://ywwwon01.tistory.com/32

[AWS] EC2에 https 적용하기 (with. CloudFront)

 

 

3. 로드 밸런서

Elastic Load Balancing(ELB)은 하나 이상의 가용 영역(AZ)에 있는 여러 대상 및 가상 어플라이언스에서 들어오는 애플리케이션 트래픽을 자동으로 분산합니다.

 

잠깐! 이렇게 생각하실 수 있을 것 같습니다.

님은 단일 EC2에서 소규모로 배포할 뿐이신데 로드 밸런서까지 설정하시는 이유가 뭐죠?

(네, 사실 제가 의문이었어요,)

 

SSL 인증서를 EC2 인스턴스에 직접 설치하는 방법도 있지만,

일반적으로는 로드 밸런서에 설치하는 경우가 많더라고 합니다.

 

로드 밸런서는 본래 목적대로 여러 EC2 인스턴스에 트래픽을 분산시키는 용도로도 사용하고,

따라서 HTTPS 트래픽을 처리할 때도 유리한 것인데요

 

뭐가 유리하다는 건데요?

• (로드 밸런서 본래 목적대로) 여러 EC2 인스턴스를 사용할 경우 효과적임
  • 보안 설정 및 트래픽 제어를 로드 밸런서에서 일괄 관리 가능
• EC2 인스턴스 각각에서 SSL 관련 설정을 직접 관리할 필요가 없음
  • 인증서 관리 간소화!!
  • 개발자가 신경 써야 할 많은 부분들을 AWS가 해결해주는 것.. 많은 사람들이 AWS를 사용하는 가장 핵심적인 이유라고 생각합니다.

 

AWS 프리 티어를 사용해 무료로 Elastic Load Balancing을 시작해보세요. 가입 시 AWS 신규 고객은 Classic 및 Application Load Balancer 간에 공유되는 750시간, Classic Load Balancer의 데이터 처리 15GB, Application Load Balancer 15 LCU와 같은 혜택을 받을 수 있습니다.

게다가 프리티어에서 매월 750시간은 무료로 사용할 수 있다고 하니

안 써볼 수가 있나요?!

 

훗.. 떠납시다..

 

(1) EC2 > 로드 밸런서 > 로드 밸런서 생성

 

 

(2) ALB 선택

 

 

(3) 로드 밸런서 이름 작성 > 체계 - 인터넷 경계 > 로드 밸런서 IP 주소 유형 - IPv4

 

 

(4) VPC 선택 > 가용 영역 및 서브넷 선택

이 가용 영역 설정은 매우 중요한 단계입니다..

 

이렇게 설정한 이유는:

1. 최소 2개 이상의 가용 영역(AZ)를 선택함으로써 고가용성 확보
   • AWS는 가용 영역 별 독립적인 전원 & 네트워크 인프라를 갖추고 있다!
   • 한 가용 영역에 문제가 생겨도 다른 가용 영역에서 서비스 유지가 가능
2. 로드 밸런서는 퍼블릭 서브넷에 있어야 외부 인터넷에서 접근 가능
   • 내 인스턴스의 가용 영역이 포함되도록 선택 必

입니다. 사실 4개를 모두 선택했어도 됐던 것이죠..

 

 

(+) 인스턴스 가용 영역 확인

 

 

(5) 리스너 및 라우팅 > 기본 작업 > 대상 그룹 생성

(HTTP, HTTPS 리스너 설정)

 

제 프로젝트는 nginx를 통해 실행시킬 예정이므로

포트 80번으로 설정하였습니다.

 

 

'아래에 보류 중인 것으로 포함' 해주고, 우측 하단에서 '등록 완료'

 

 

(6) 보안 리스너 설정

 

까지 됐다면, 이제 '로드 밸런서 생성' 버튼으로 완료할 수 있습니다.

 

 

(7) Route 53 > 유형 A인 레코드 선택 > 레코드 편집 > 방금 만든 로드밸런서 선택

 

 

4. 보안 그룹 편집

이제 거의 다 됐습니다!!

로드 밸런서에 연결한 보안 그룹의 인바운드 규칙에

처음부터 HTTPS를 포함시켜두셨다면,

위 단계 직후부터 바로 HTTPS가 적용됐을 것 같습니다.

 

(1) EC2 > 인스턴스 > 인스턴스 선택 > 보안 탭에서 보안 그룹 선택 > 인바운드 규칙 편집

 

 

(2) 확인

훗..

이렇게 Mixed Content 문제도 해결 완료 했습니다.

 

부제: [프로젝트 배포 도전기 with AWS 프리티어] 끝!!

 

감사합니다.