[AWS Subnet] 서버 Private Subnet으로 옮기기(1)

이전 구성에서는 백엔드 소스와 노드를 실행하는 EC2가 Public Subnet에 생성되어 있었습니다. 이는 보안상 좋지 않은 구성이기 때문에 EC2를 Private Subnet으로 옮기는 작업을 수행해 보겠습니다.

 

이번 작업에서는 단순히 기존에 만들었던 리소스들을 수정해서 새롭게 구성을 할 수 없는 경우가 대부분이라 새로 생성하는 것들이 많았습니다... 실제 아키텍처를 구성할 때는 미리 구조를 잡고 리소스들을 만드는 것이 좋을 것 같습니다...ㅠ

 

1. EC2를 옮길 Private Subnet 생성

새로운 백엔드 서버를 실행할 EC2를 생성하기 전 해당 EC2들이 설치될 Private Subnet을 먼저 생성합니다.

 

기존 VPC 선택 후 서브넷 2개 생성

 

2. Private Subnet을 위한 라우팅 테이블 생성

Private Subnet으로 EC2를 이전한 뒤, EC2에서 인터넷 통신을 해야하기 때문에 이를 대비해서 먼저 Private Subnet을 위한 라우팅 테이블을 생성합니다.

 

 

라우팅 테이블 생성 후 서브넷 연결에서 위에서 생성한 Private Subnet을 연결합니다.

 

 

3. 새로운 EC2를 위한 보안 그룹 생성

새로운 EC2를 생성하기 전 해당 EC2들을 감싸는 보안 그룹을 생성합니다. 해당 보안 그룹은 서버에서 허용할 9090 포트와 ssh 접속을 허용하도록 합니다.

 

9090 포트와 ssh 접속을 허용하는 보안 그룹 생성

 

지금까지 변경된 구조를 보면 다음과 같습니다.

 

 

4. Private Subnet에 EC2 생성

기존 Public Subnet에서 실행되고 있는 EC2와 같은 EC2를 Private Subnet에 생성합니다. 같은 EC2를 생성하기 위해 먼저 기존 EC2를 선택하고 이미지를 생성하는 것이 좋습니다.

 

 

이미지 생성 후 해당 이미지를 가지고 새로운 인스턴스를 생성합니다. 두 개의 Private Subnet을 생성했기 때문에 각 서브넷에 EC2를 하나씩 생성합니다.

 

Private Subnet 선택 후 퍼블릭 IP는 비활성화

위에서 생성한 보안 그룹 선택

 

❗️EC2를 생성하고 난 뒤, 기존 EC2에 적용되어 있던 IAM 역할을 새로운 EC2에도 부여합니다. 이 역할은 EC2에 설치된 codedeploy-agent에서 CodeDeploy와 S3에 접근할 수 있는 권한을 가지고 있습니다.

 

5. DB의 보안 그룹 수정

위에서 새로 EC2를 생성하면서 새로운 보안 그룹을 적용했기 때문에 RDS로 접속할 수 있는 보안 그룹을 수정해주어야 합니다. RDS의 보안 그룹으로 들어가 인바운드 규칙을 수정합니다.

 

 

지금까지 구조를 살펴보면 다음과 같습니다.

 

 

6. 새로운 대상 그룹 생성

로드 밸런서를 위한 새로운 대상 그룹을 생성하고 대상 그룹에 위에서 생성한 Private Subnet의 EC2를 추가합니다.

 

서버의 9090 포트를 허용하고 기존 VPC 선택

Private Subnet의 EC2 추가

 

7. ELB 생성

새로운 ALB를 생성합니다. 기존 생성과 같지만 대상 그룹을 다르게 지정합니다. 대상 그룹이 되는 EC2들은 Private Subnet에 있지만, ALB의 경우는 Public Subnet에 생성하여 Internet Gateway를 통해 들어오는 요청을 ALB가 받아 Private Subnet의 EC2로 넘기도록 구성합니다.

 

 

위 설정에서 ELB를 생성할 Public Subnet을 2개 선택하였습니다. 이렇게 하면 ELB가 2개 생성됩니다.(보이기는 하나가 보이지만 2개 생성 - "nslookup NLB_DNS_이름" 명령으로 확인 가능) ELB의 경우 하나의 가용영역 당 하나의 서브넷을 선택하여 생성할 수 있고 해당 가용영역에 있는 EC2에 요청을 전달하게 됩니다. 따라서 우리 구조 상 EC2가 2a, 2c 가용영역에 각각 존재하기 때문에 각 가용영역에 ELB를 생성해야 합니다.

 

8. NAT 게이트웨이 생성

로드밸런서를 통해 웹 브라우저에서 오는 요청을 받을 수 있지만 Private Subnet에서 응답을 하기 위해서는 NAT 게이트웨이를 Public Subnet에 추가하고 라우팅 테이블을 수정하여야 합니다.

 

NAT 게이트웨이를 생성하기 전 NAT 게이트웨이를 위한 탄력적 IP를 생성합니다.

 

 

이제 NAT 게이트웨이를 생성합니다.

 

 

이후 Private Subnet에서 사용하는 라우팅 테이블을 수정하여 Private Subnet에 있는 EC2에서 NAT 게이트웨이로 응답을 보내고 NAT 게이트웨이에서 다시 인터넷 게이트웨이로 연결되도록 해야 합니다.

 

 

9. Front-end 소스 수정

위에서 새로운 로드 밸런서를 생성하였기 때문에 프론트엔드 소스에서도 접속할 url을 새로운 로드 밸런서의 DNS 이름으로 수정합니다.

 

import axios from "axios";

export default axios.create({
    baseURL: "http://새로운_ALB_DNS_이름/api",
    headers: {
        "Content-Type": "application/json"
    }
})

 

수정한 소스를 리포지토리로 push 하게 되면 자동 CI/CD를 통해 빌드된 소스가 S3에 저장되고 CloudFront를 통해 서비스됩니다. 백엔드 서버가 정상적으로 실행되고 있다면 이전에 볼 수 있었던 웹 서비스를 확인할 수 있을 것입니다.

 

지금까지 구조를 살펴보면 다음과 같습니다.

 

---

하지만 아마도 EC2를 새로 생성한 뒤, 서버를 실행하지 않았기 때문에 정상적인 데이터 저장 및 조회가 불가능할 것입니다. 기존에는 서버 실행을 위해 ssh 접속으로 직접 실행하거나, CodeDeploy를 통해 자동으로 소스를 배포 및 실행하였습니다.

 

아직 CI/CD 부분을 수정하지 않았기 때문에 ssh 접속을 하려고 보니 새로 생성한 EC2는 Public IP가 존재하지 않아 로컬에서는 접속이 불가능합니다. 이 문제를 해결하기 위해 Public Subnet에 새로운 EC2를 하나 생성하고 이 EC2를 통해 Private IP로 서버가 실행 중인 EC2에 접속해보겠습니다.