[프로젝트] AWS 계정 이전하기 & EC2, S3, CloudFront, Route 53 복습 적용

1. 새 AWS 계정 생성하기

새로 AWS 계정을 생성하려면 이메일 아이디가 있어야 하는데 나는 이 블로그 아이디와 동기화하여 사용하기로 했다.

새로 아이디를 가입할 때의 장저은 12개월 동안 프리티어로 AWS를 사용할 수 있다는 점이다.

VISA 카드 정보와 번호를 등록하고 인증을 하면 가입이 끝난다.

2. 이전 AWS 계정 정리

이전에 AWS에서 사용하던 것들을 정리하고 하나씩 옮겨보려고 한다.

사용하던 제품들은 아래와 같다.

1) EC2

2) S3

3) CloudFront

4) Route53

하나하나씩 옮기는 과정을 작성하려고 한다.

3. EC2 이전하기

Elastic Block Store > 스냅샷에서 스냅샷 생성을 선택한다.

인스턴스 선택 후 이전하려는 EC2 인스턴스를 선택한다.

스냅샷 상태가 생성 완료로 바뀔 때까지 기다린다. 3분 정도 걸리는 거 같다.

우클릭 후 스냅샷에서 이미지 생성을 선택한다.

그리고 이미지 > AMI로 이동하면 생성된 이미지를 확인할 수 있는데 작업 > AMI 권한 편집을 선택한다.

그리고 공유 계정에 공유할 AWS 계정 ID를 입력해야한다.

그리고 이전할 계정으로 로그인 후 EC2 인스턴스 생성 클릭 후 AMI 선택 시 아래와 같이 나와 공유된 AMI를 확인할 수 있다.

달라진 것은 프리 티어 내 인스턴스를 돌리기 위해서 t2.micro로 변경하게 되었다.

깔끔하게 이전되었고 나머지 미리 등록해놓은 EC2 github 설정을 변경하려고 한다.

확인해보니 인바운드 규칙은 새로 설정해주어야 할 거 같다.

4. S3 이전하기

S3 권한 변경하는 부분도 있긴한데 S3는 처음부터 복습하는 겸 생성해보려고 한다.

기존 S3를 지워야 같은 이름으로 버킷을 사용할 수 있다.

삭제를 해도 삭제까지 시간이 걸리기 때문에 그냥 기존 버킷이름2로 지어주었다.

5. CloudFront 이전하기

CloudFront 역시 복습 겸 새로 만들어주려고 한다.

원본은 S3 버킷을 설정해주고 Enable Origin Shield는 No로 선택하였다.

대체 도메인으로 가비아에서 구매한 도메인을 입력해준다.

다시 오래 걸리는 ACM 인증서 요청을 진행해주어야 한다.

퍼블릭 인증서 요청으로 인증서 유형은 선택하고 완전히 정규화된 도메인 이름에는 구입한 도메인 이름을 입력하고 DNS 권장을 선택한다.

요청을 하면 도메인에서 검증 대기 중이 뜨는데 Route53에서 레코드를 생성해야 한다.

CloudFront > ACM > Route53으로 인증하고 다시 역순으로 돌아오도록 하겠다.

그러면 Route 53 이전, 생성하기 단계를 먼저 진행하자.

순서대로 따라하다보면 전부 등록할 수 있으니 순서대로 글을 따라와주시길 바랍니다.

6. Route53 이전하기

Route 53 호스팅 영역 생성을 선택한다.

도메인 이름을 입력하고 퍼블릭 호스팅 영역으로 선택한다.

그러면 레코드에 NS 유형의 값/트래픽 라우팅 대상 4개를 확인할 수 있는데 이 값을 구매한 도메인과 연결해주어야 한다.

나는 가비아에서 도메인을 구매했기 때문에 가비아에 해당 값을 등록해주어야 한다.

가비아에 접속하여 홈 > 전체도메인 > 도메인 상세 페이지로 이동한 후 네임서버 설정을 선택한다.

1차, 2차는 가비아 관련 네임서버가 설정되어 있는데 4개를 추가해서 ns-어쩌구저쩌구.에서 .을 제외하고 복사해서 붙여준다.

 

그리고 다시 route53으로 돌아와서 Route53에서 레코드 생성을 누르면 조회가 가능하다.

레코드 생성을 완료하면 Route53에 CNAME이 추가된 것을 확인할 수 있다.

그리고 다시 CloudFront로 돌아오면 인증서 상태가 검증 대기 중인 것을 확인할 수 있는데 30분 정도 기다리면 발급 완료로 변경되니 천천히 기다리자.

4시에 발급 요청하였는데 4시 30분에 발급이 완료되었다.

다시 CloudFront로 돌아와서 ACM을 등록해주고 보안 정책은 권장으로 설정하였다.

그리고 기존에 CloudFront와 Route53에서 사용하던 연결 관계를 전부 삭제해야 새 CloudFront가 생성이 가능하다.

 

그리고 CloudFront에서 이 S3 버킷은 S3 웹 사이트로 구성됩니다. 이 배포를 웹 사이트로 사용하려는 경우 버킷 엔드포인트 대신 S3 웹 사이트 엔드포인트를 사용하는 것이 좋습니다. 라고 뜨는데 이 버튼을 누르지 않고 원본 액세스 제어 설정할 경우 OAC를 생성해야 한다.

이 정책을 복사해서 S3로 이동한 후 버킷 > S3 버킷명 선택 > 버킷 권한 > 버킷 정책 편집을 통해 복사한 버킷 정책을 추가하자.

 

그리고 Route53으로 돌아가서 A record를 추가해주도록 하자.

나는 백엔드용 서브도메인 api로 하나 더 등록하였다.

백엔드용 레코드는 EC2의 public IP를 입력해주었다.

7. Github AWS 내용 갱신하기

기존에 백엔드에서 사용하던 EC2_SSH_KEY와 프론트에서 사용하던 AWS_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID를 바꾼 EC2 정보로 바꾸려고 한다.

EC2_SSH_KEY에는 생성한 ACCESS_KEY .pem 을 등록하였고 프론트에는 AMI 사용자 권한이 필요한데 이 부분은 수동으로 옮겨주었다.

또한 S3_BUCKET_NAME이 2가 붙어서 변경하였다.