배포 - AWS 를 이용한 배포 연습(3-Tier Architecture)

백엔드(서버) 배포

서버 배포(EC2)

• EC2 콘솔을 통해 EC2 인스턴스를 생성해야 한다
• 간단한 서버 앱을 생성하고 EC2 인스턴스에 코드를 배포하는 작업
• 서버를 실행시키고(npm start), 브라우저에서 해당 서버에 접속할 수 있어야 함

EC2 인스턴스 생성 및 제어

EC2 인스턴스 생성

• AWS 메뉴에서 EC2 를 검색 → 인스턴스 시작 을 클릭
• step1: 그러면 출력되는 화면이 용도에 맞는 AMI 템플릿을 선택하는 화면이 뜬다
  → 반드시 프리티어 사용 가능(무료라는 뜻) 태그를 확인하여 템플릿을 선택하자
  → ubuntu 18버전을 사용한다고 가정하여 진행(ubuntu 18버전 선택)

• step2: 다음 출력 화면에서 인스턴스 유형을 선택
  → 프리터어 사용 가능 확인하여 인스턴스의 성능을 선택하는 부분(CPU, RAM, 용량 등)
  → 검토 및 시작을 눌러 진행

• step3: 그러면 다음 출력 화면에서, 기존 키 페어 선택 또는 새 키 페어 생성 창이 뜬다
  → 생성되는 인스턴스를 원격으로 제어하기 위해서는 SSH(22) 연결을 통한 원격 접속이 필요
  → 이에 대한 Key를 생성하고 다운로드하는 과정임
  → 지금은 아예 키가 없으니깐, 새 키 페어 생성 선택하여 키 페어 이름을 임의로 정한 후, 반드시 키 페어 다운로드를 통해 로컬에 다운(위치 기억)받고 인스턴스 시작 버튼 클릭

* SSH 프로토콜을 통한 원격접속과 키 페어
- SSH(Secure Shell) Protocol은 서로 다른 pc가 인터넷과 같은 pubilc network를 통해 
통신을 할 때 보안 상 안전하게 통신을 하기 위한 규약(프로토콜)
→ 주고 받는 데이터를 암호화해서 해당 키 페어를 가지지 않는 사람은 데이터를 알아볼 수 없게 하는 것

- 인스턴스 생성 마지막 단계에서 다운받은 파일이 키 페어 중 `private key`(개인키)
→ *.pem 확장자 파일
→ 해당 키 페어 파일은 EC2 인스턴스에 연결할 때, 사용하는 암호가 담긴 파일
→ 즉, 관리에 유의!

• 생성한 인스턴스를 확인(인스턴스 탭)
  → 인스턴스-인스턴스
  → 인스턴스 ID로 구별할 수 있지만 가독성이 떨어지므로, name 컬럼에서 이름지어주면 좋다

EC2 인스턴스 연결

이제 생성된 인스턴스를 어떻게 제어(사용)할 수 있는가?
→ 원격 접속(SSH)를 통해 접근할 수 있다; 이 때 필요한 게 아까 받은 private key 파일

 

• 인스턴스 탭에서 연결할 인스턴스 선택 후 연결 버튼 클릭
  → 연결하는 방법에 대한 설명이 나옴
  → 다양한 방법 중 SSH 연결(SSH 클라이언트) 방식을 써보자
• SSH 연결을 하기 위한 전제조건
  private key 파일에 대한 권한 변경이 필요: chmod 400 받은경로/내키페어이름.pem

→ 키를 공개적으로 볼 수 없도록 하기 위함
→ 권한을 소유자(owner)에 대해서만 읽기 권한(r:4)을 줌
→ 권한이 많은 경우 자체적으로 permission denied를 띄우므로, 반드시 설정 필요

 

• 파일 권한 설정이 완료되었다면, 화면에서 나오는 ssh 명령어 부분을 복사해서 접속하면 된다

## ex) 
ssh -i "파일경로/내키페어이름" ubuntu@해당 인스턴스의 퍼블릭DNS주소

## ssh 프로토콜을 통해
## 파일경로/내키페어이름 이라는 이름의 key를 가지고
## ubuntu 라는 사용자 이름으로(* 우분투 인스턴스를 생성한 경우 기본적으로 ubuntu라는 사용자이름 생성)
## 해당 인스턴스의 퍼블릭DNS주소 에 접속하겠다는 뜻

• 터미널 창의 접속 pc명이 ubuntu@ip-내-가상의-ip-주소(숫자) 형태로 나온다면 정상적으로 ssh 원격 접속이 된 것

EC2 인스턴스 상에서 서버 실행

생성한 EC2 인스턴스를 이용하여 서버를 실행하고 접속해 보자

인스턴스에 개발 환경 구축하기

현재 생성한 EC2는 딱 OS 정도만 깔린 껍데기 컴퓨터이다
→ 즉, 개발에 필요한 프로그램 등 개발 환경을 구축을 해둬야 서버가 돌아간다

• 1. 패키지 정보 최신화(업데이트)

## 우분투이므로
sudo apt update

• 2. nvm 설치
     아래 공식 문서 내용을 참고하여 설치하였다
     https://github.com/nvm-sh/nvm#installing-and-updating

설치 코드는 아래와 같다

## curl 사용시
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

## wget 사용시
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash

## curl이나 wget 둘 중 하나의 코드로 설치 진행

## 환경 변수 설정
export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm

nvm 명령어가 먹히는 지 확인하자. nvm 명령어(command) 자체가 없다는 식으로 뜨면, 환경 변수 설정을 안한 것이므로 위의 환경 변수 설정 명령어를 복사 붙여넣기해주자

 

그 후, nvm --version 명령어가 정상 작동된다면 정상 설치된 것

• 3. node.js 설치

nvm install node

## 호환성 등의 문제로 node 버전을 다운그레이드해야 할 경우도 있다
## 그 경우 nvm install node v버전명     이런식으로 해당 버전을 받아서 바꿔쓰면 된다

nvm list 명령어로 node 버전을 확인 가능

• 4. npm 설치

npm 명령어도 사용해야 하니깐, npm도 설치하자

sudo apt install npm

→ 여기까지 진행하면, 기본적인 node.js 기반 서버를 실행하는 데 필요한 개발 환경이 구축됨

git을 통한 서버 코드 클론 받기

git clone 을 통해 서비스를 제공할 애플리케이션의 서버 코드의 클론을 받자

주의: 내 local에 받는 것이 아닌, EC2 인스턴스(가상 컴퓨터)에 클론을 받는 것이다
→ 최근의 git 정책에 의해서 (보안 상 정책 변경?) 기존 방식은 막혀서, ssh 이용한 clone 을 이용한다고 가정하면 github 에 ssh 공개키를 등록해주는 과정을 거쳐야 함

### 주의: EC2 인스턴스에서 진행하는 것이다

ssh-keygen            ## ssh 키 생성
## 엔터 쳐서 진행 완료

cat ~/.ssh/id_rsa.pub    ## ssh 공개키를 출력 후에 나오는 공개키 값을 복사할 것

## 복사한 키 값을 github 에서 내 프로필 – 설정(settings)- SSH and GPG keys 에서 New SSH key로 등록하는 절차를 거쳐야 함

위 과정이 완료되면 정상적으로 git clone이 실행될 것이고, 서버 코드 클론이 생성된다
→ npm install 을 통해 필요한 모듈을 설치

EC2 인스턴스에서 서버 실행하기

바로 npm start 를 해보면 오류 메시지가 뜬다

자세히 보면, 접근 권한과 관련한 거부인데 1024번 이하의 포트 번호(보통의 well-known port)를 사용하여 서버를 실행하려면 관리자 권한이 필요하기 때문
→ sudo npm start 로 실행

 

이제 서버는 정상적으로 실행되었고, 퍼블릭 IPv4 주소 또는 퍼블릭 IPv4 DNS를 통해서 해당 서버에 접속 가능하다
→ 그런데, 접속 시도하면 아직은 사이트 연결이 안될 것이다(ERR_CONNECTON_TIMED_OUT)
→ 보안 그룹(방화벽 정책) 설정이 안되었기 때문

Security Group(보안 그룹)

보안 그룹이란 AWS에서 사용자가 임대한 인스턴스의 가상 방화벽
인바운드(들어오는 트래픽)와 아웃바운드(나가는 트래픽)에 대한 규칙을 설정할 수 있다

• 인바운드(Inbound) 규칙
  → 인스턴스 생성 시 기본적으로 SSH 접속을 위한 규칙(port: 22)만 생성되어 있음
• 아웃바운드(Outbound) 규칙
  → 인스턴스 생성 시 기본적으로 EC2에서 나가는 모든 트래픽을 허용해주고 있음
• 인스턴스가 어떤 보안 그룹에 속하는 지 확인?
  → 인스턴스 탭의 우측에서 보안 그룹 이름 컬럼을 확인하면 된다
• 보안 그룹 설정
  → 좌측 네트워크 및 보안 - 보안 그룹 탭에서 해당 보안 그룹을 선택하면 그 그룹의 규칙을 설정 가능
  → 여기서는 인바운드 규칙 설정을 해보자
• 인바운드 규칙 편집
  → 인바운드 규칙 탭 - 인바운드 규칙 편집 - 규칙 추가 버튼을 통해 규칙을 추가 후 규칙 저장

* http (port: 80)에 대한 인바운드 규칙을 생성하는 경우
→ 유형에서 HTTP를 선택하고, 소스: anywhere(IPv4)(모든 IP에 대한 접속 허용)로 하여 생성
→ 80 포트에서 실행되는 웹서버에서 모든 주소에 대한 요청을 받을 수 있도록 규칙 생성하는 것

이 작업이 완료되었으면, 위의 안되었던(Timeout) 서버가 정상적으로 응답함을 알 수 있다(hello world)

PM2

백그라운드(bg)에서도 계속 프로세스가 돌아가도록 해주기 위해 PM2를 이용하자

일반적으로 열려있는 터미널(CLI)를 강제 종료하는 경우(그냥 끄는 경우)의 생기는 일

* 1. 로컬의 ssh 프로세스가 강제 종료됨
* 2. (ssh 프로세스가 종료되면) EC2상의 node 프로세스가 강제 종료됨
* 3. (node 프로세스가 종료되면) node로 작동 중인 웹 서버도 종료됨

→ 즉, 로컬에 있는 CLI를 끄더라도, EC2상의 node 프로세스는 강제 종료되지 않도로 해 줘야 함(항상 실행)
→ 프로세스를 백그라운드 실행되게 하면 됨

일반적인 백그라운드 실행 키워드

특정command &        ## 특정 커맨드 뒤에 `&`를 붙이면 백그라운드(bg)에서 실행한다는 뜻
[1] PID        ## output으로 출력되는 PID 값

이를 통해 fg PID(포어그라운드로 불러옴) , kill PID(프로세스 강제 종료)등도 가능
그런데 이런 명령어로 계속 관리하기엔 불편한데, 대신 해주는 프로세스 관리 프로그램: PM2
기본적으로 Hot Reload(변경시 자동 재시작), 로그 관리 용이 등 다양한 기능을 지원해 준다

PM2 설치 및 사용법

PM2는 프로세스를 관리해주는 도구라고 보면 된다
→ PM2를 사용해서 다중 프로세스를 돌릴 수도 있고, 백그라운드로 돌아가게 하는 등 프로세스에 대한 다양한 컨트롤이 가능하다

## pm2 설치(전역 설정 옵션으로 설치해주자)
npm install pm2 -g

기본 명령어는 다음과 같다

pm2 start 파일명        ## 프로세스 시작
pm2 stop 파일명        ## 프로세스 중지
pm2 restart 파일명        ## 프로세스 재시작
pm2 ls            ## 프로세스 목록
pm2 log            ## 프로세스 로그
pm2 delete 파일명        ## 프로세스 삭제

그리고 1024 포트 이하의 포트를 통해 접근 시에는 관리자 권한이 필요하므로, pm2에도 관리자 권한을 부여해줘야 한다
→ authbind 패키지 추가 설치하여 사용

authbind 설치 및 사용

아래의 명령어를 통해 설치 및 환경 설정해 준다

sudo apt-get update 
sudo apt-get install authbind 
sudo touch /etc/authbind/byport/80 
sudo chown ubuntu /etc/authbind/byport/80 
sudo chmod 755 /etc/authbind/byport/80 
authbind --deep pm2 update

혹시나 설치를 완료한 후에 authbind를 설치 전에 pm2 프로세스 리스트에 등록해 둔 것이 없는 지 확인하자. 기존에 등록된 거에 대해서는 소급 적용이 안되기 때문에 클린하게 다 제거 후 다시 돌리는 게 좋다

pm2 ls
pm2 delete 해당파일들

깔끔하게 리스트가 정리되었으면, 이제 pm2에 관리자 권한을 붙여서 실행하도록 하자
명령어는 다음과 같다

authbind --deep pm2 start 해당파일명        ## authbind --deep 을 붙이는게 핵심

프론트엔드(클라이언트) 배포

S3 호스팅

간단히 말하면 이 과정은 AWS의 S3 버킷을 이용하여 정적 웹 사이트 호스팅을 하는 과정이다

 

정적 웹사이트 호스팅 과정은 다음의 4단계로 요약할 수 있다

1. 정적 웹 페이지 빌드
2. 버킷 생성 및 정적 웹 사이트 호스팅 용으로 구성
3. 빌드된 정적 웹 페이지 업로드
4. 퍼블릭 액세스 차단 해제 및 정책 생성

위 과정이 끝나면 다른 사용자들이 버킷에 업로드된 정적 웹 페이지에 접근할 수 있게 된다

정적 웹 페이지 빌드

먼저, 빌드 과정을 거쳐야 하는데 local에 있는 파일들(클라이언트 파일)을 빌드해서 S3 버킷에 담는 구조이므로, local에 있는 내 코드에서 빌드 작업을 하도록 하자

 

중요한 점은 환경 변수 설정을 해줘야 하는데, .env 파일을 생성 후에 환경 변수 필드와 환경 변수 값을 설정해 줘야 한다.
주로 서버 URL을 환경변수화하여 사용하는데, 이 경우에 서버의 주소를 환경 변수에 담을 때는 필히 'http://' 나 'https://'를 포함해야 한다

//ex: (나의 로컬 컴퓨터 .env 파일 내에서)

REACT_APP_API_URL=http://내 EC2인스턴스의 퍼블릭 IP DNS 주소

환경 변수 설정이 완료되었다면, npm run build를 통해서 간단히 빌드가 마무리 된다
→ build 폴더가 생성되고 하위에 빌드 파일들이 생성됨을 알 수 있다

버킷 생성 및 정적 웹 사이트 호스팅 용으로 구성

AWS → S3 검색하여 S3 메인화면에 접속 → 버킷 만들기 클릭 → 버킷 이름 입력(각 리전에서 고유한 이름) 및 리전 선택 → 하단의 버킷 만들기 로 완료

• 이렇게 버킷이 생성되면 해당 버킷을 정적 웹 사이트 호스팅 용으로 수정하는 작업을 진행:
  해당 버킷 클릭 → 속성 탭 → 하위의 정적 웹 사이트 호스팅 편집 → 비활성화(기본값)를 활성화로 변경 → 인덱스 문서 지정(보통 index.html 사용) 및 변경사항 저장
• 정적 웹 사이트 호스팅 구성 작업이 완료되면, 속성 메뉴에서 하단에 버킷 웹사이트 엔드포인트 부분이 생성됨을 확인 가능
  → 이 엔드포인트 주소가 클라이언트 메인화면 주소라고 보면 된다
  → 그런데, 바로 접속하면 에러 메시지가 뜬다(403 forbidden)
  → 아직 버킷에 파일 업로드 작업 및 보안 관련 설정을 안했기 때문

빌드된 정적 웹 페이지 업로드

해당 버킷의 객체 메뉴로 이동 → 업로드 클릭 → build 디렉토리 안에 있는 정적 파일들 업로드(드래그 앤 드랍)

주의: build 폴더가 아닌 그 안에 있는 전체 파일들(및 폴더)을 업로드해야 한다!

퍼블릭 액세스 차단 해제 및 정책 생성

퍼블릭 액세스가 가능하게 하기 위해 설정을 해 주고, 권한 및 접근에 대한 정책 설정을 해주는 부분

• 퍼블릭 액세스 차단 해제
  해당 버킷의 권한 메뉴로 이동 → 퍼블릭 액세스 차단(버킷 설정) 옵션 부분을 편집 → 모든 퍼블릭 액세스 차단(기본값) 체크를 해제 후 변경 사항 저장
• 정책 생성
  다시 권한 메뉴에서 버킷 정책 부분 편집 → 정책 생성기 클릭하고 아래를 참고하여 작성

 

* principal: 권한을 적용할 대상. * 은 모두(전체)

* actions: GetObject
## 버킷에 접근하는 모든 사용자가 버킷 내에 저장된 객체데이터를 읽기 가능 
## 버킷을 웹 사이트 용도로 구성할 때 선택

작성이 완료되면 generate policy 를 클릭하고 생성된 정책을 복사하여 버킷 정책에 붙여넣기
→ 이제 엔드포인트 주소로 접속하면 정상적으로 화면이 출력됨

데이터베이스(DB) 연결

RDS 인스턴스 생성 및 연결

AWS에서 mySQL 데이터베이스 엔진을 사용하는 DB 인스턴스를 생성하고, local에서 mysql 클라이언트(cli mysql 명령어)를 통해 AWS의 RDS 인스턴스에 접속하는 과정

인스턴스 생성하는 리전이 자동으로 바뀌지 않았는지 수시로 확인해야 한다! 필자는 서울 리전이 자꾸 오하이오로 돌아가는 증상을 겪어서 오하이오에 RDS를 까는 삽질을 하였다. 중요한 건 RDS 과금 정책? 때문에 잘못하면 과금이 생기므로, 절대적으로 확인을 잘하자!(EC2도 자꾸 오하이오로 바뀌는 증상이 있으니 항상 유의!)

RDS 인스턴스 생성

RDS 검색하여 RDS 메인화면 이동 → 데이터베이스 생성 클릭

→ 엔진 옵션: MySQL → 템플릿 옵션: 프리 티어(무료)

→ 연결 옵션에서 DB 클러스터 식별자 이름 작성(계정 내 고유한 이름), 마스터 사용자 이름, 비번을 설정

→ 연결 옵션에서 퍼블릭 액세스 가능 부분 변경(예)

→ 보안 그룹 확인(default 맞는지) 및 포트 번호 수정(선택사항 3306 → 13306 등)

→ 추가 구성 토글을 열어 초기 데이터베이스 이름 지정(서버 코드가 test 라는 db 기준으로 작성되었음)

→ 데이터베이스 생성 클릭하여 생성 작업

DB 생성하는 작업은 생각보다 시간이 오래 걸리므로 (약 20분이상?) 상당히 기다려야 한다는 점을 유의

데이터베이스 연결

MySQL 클라이언트(로컬 CLI의 mysql)을 통해서 RDS의 DB 인스턴스에 연결하기 위해서는 3가지 정보를 알아야 한다

1. DB 인스턴스 생성 시 기재한 마스터 이름, 마스터 비밀번호
2. 포트 번호
3. 생성한 DB 인스턴스의 엔드포인트 주소
## DB의 엔드포인트 주소는 생성한 DB의 상세 내용 란에서 `연결 & 보안` 메뉴 → `엔드포인트` 부분

위 정보들을 가지고 RDS의 DB 인스턴스에 접근하는 명령어는 다음과 같다

## 나의 local의 CLI 창에서

mysql -u [마스터 이름] --host [엔드포인트 주소] -P 13306(포트번호) -p
## 혹시나 접근 거부가 되거나 접속이 hang-up 된다면 정책에 인바운드 규칙을 추가해주자(tcp 해당 포트)

서버(EC2) 환경 설정

RDS(데이터베이스) 인스턴스가 정상 생성되고 로컬에서 연결 테스트가 잘 되었다면, 이제 EC2 인스턴스 서버와 RDS(데이터베이스) 인스턴스 간의 연결해 주는 작업을 해야 한다
→ 서버쪽의 환경 설정을 통해서 서버가 RDS 인스턴스에 접속하고 클라우드 DB(RDS)를 사용할 수 있게 되는 것

서버 코드에 저장된 .env 파일 환경 변수 설정

• 먼저 EC2 인스턴스에서 서버가 실행되고 있다면 서버 종료(pm2 stop id값 )
• .env 파일을 생성 또는 파일명 변경
  → touch 명령어로 적정경로에 생성 또는 mv 명령어로 파일명 변경
  (mv .env.example .env)
• 해당 경로에서 파일을 nano 에디터로 수정(nano .env)

## 파일 내용 예시

DATABASE_HOST=생성한 DB 인스턴스의 엔드포인트 주소
## 엔드포인트를 기입할때는 http:// 붙이면 안된다

DATABASE_USER=마스터 사용자 이름
DATABASE_PASSWORD=마스터 암호
DATABASE_PORT=DB 인스턴스의 port 번호

## `=` 사이에 공백이 없도록 하여 작성하자
## 작성 내용은 따옴표 같은 감싸는 문자열 없이 작성할 것

파일 저장 후 다시 서버를 실행하면 데이터베이스와 서버가 연결된다

sudo npm start ## 또는
authbind --deep pm2 start 파일명    ## pm2 이용하여 프로세스 실행

서버를 키고 다시 S3 버킷의 엔드포인트 주소로 접속하여 연결이 되는지 확인하면 완료!

 

 

---

클라우드 서비스와 AWS에 대한 보충 내용

클라우드 서비스

클라우드 서비스의 제공 범위에 따라 서비스의 유형이 나뉜다
→ IasS, PaaS, SaaS

서비스를 피자로 표현한 아래 사진을 보면 직관적으로 이해할 수 있다

클라우드 vs. 온프레미스

        클라우드                    온프레미스
======================================================
비용        사용한 만큼+초기비용x    유지비용+초기비용
확장성            유리                    불리(제약 존재)
구축시간    빠름(짧음)                좀 오래 걸림

EC2

availability zone

• 가용성을 위해 가용 영역을 나눠두는 것
  → 특정 리전에서 어느 한 영역(데이터센터?)가 죽어도 서비스에 지장 없도록 다른 영역을 나눠 둠

VPC(Virtual Private Cloud)

• 아마존에서 EC2를 보관해 두는 공간
  → 외부와 격리된 사설 공간 같은거

Public IP, Private IP

• EC2는 VPC 안에서 각각의 고유한 프라이빗 IP을 가짐
  → 사설 IP(내부에서 소통할 때 사용)
• 외부에 소통할 때는 IPv4 퍼블릭 IP로 소통함
  → 이 퍼블릭 IP에 도메인 네임을 붙인게, 퍼블릭 DNS(IPv4)
• 주의: EC2를 중지 후 재시작하면 IP가 변경될 수 있다
  (매번 바뀌므로, 다시 주소를 매핑해줘야 한다는 것!)
  → EC2를 중지한다는 의미는 EC2 컴퓨터를 아예 버린다는 개념이라 보면 된다
  → 재시작하는 거는 다시 EC2 컴퓨터를 사오는 개념

보안 그룹

EC2의 방화벽이라 보면 된다
→ 여기서 방화벽 정책(규칙) 설정을 해주면 됨

 

보통 아웃바운드는 다 허용, 인바운드는 허용할 애들만 허용 설정
(기본적으로 모든 인바운드 트래픽을 차단, 기본적으로 모든 아웃바운드 트래픽을 허용)

S3

버킷

• 버킷의 이름은 고유해야 함(버킷이 속한 리전 내에서)
• 빌드를 새로 할 때마다 다시 빌드한 내용을 버킷에 담아줘야 한다(다시 업로드)

버킷 정책

버킷에 접근하는 사용자들, 권한 등에 대한 정책을 설정해 주는 부분

RDS

aws의 데이터베이스 관련 부분

결제 대시보드

가장 중요한 부분이다!(비용 관련)

• 여기서 사용량에 따른 비용 청구서를 볼 수 있다
• cost management → cost explorer 를 통해서 효과적인 비용 관리?를 할 수 있다
• EC2 인스턴스를 계속 연결해두면 서버가 계속 돌아가는 것이므로, 프리티어의 한계량을 초과시 비용이 발생 할 수 있다 → 인스턴스를 더이상 사용하지 않으면 해당 인스턴스를 종료 하거나 더 걱정되면 삭제하는 것도 좋다

AWS의 아키텍쳐 구조

EC2, S3, RDS를 사용해서 만들었을 경우 보통, 아래와 같은 구조로 된다

HTTPS 적용 방법

• route 53에서 인증받은 도메인을 가지고(ACM; 아마존 증명 관리자를 통해서 인증을 받아야 함)
  → ELB(로드 밸런싱) 를 통해서 EC2→ RDS 에 접근한다

https 인증서→ route53 → ELB→ EC2

• S3에 접근할 때도(클라이언트) route 53을 통해서 접근하는데, 먼저 cloudfront(CDN)에 캐싱된 데이터가 있는지 먼저 확인하고 없으면 CDN → S3 로 접근하는 구조라고 보면 된다

https 인증서→ route53 → cloudfront→ S3