TL; DR
VPN 설정도 같이 봐요
읽을 때 도움이 될 용어 설명
•
CIDR(Classless Inter-Domain Routing, 사이더): IP 클래스가 없는 '도메인 간 라우팅'. 1993년에 도입된 최신 IP 주소 할당 기법. ip 주소 class로 감당할 수 없을만큼 많아진 ip 주소의 요구를 충족시키기 위해 나왔다. 지역번호 02, 042처럼 네트워크 접두어를 통해 네트워크를 식별하고, 나머지 비트를 호스트 주소로 본다.
•
subnetting: 부분망. IP 주소를 네트워크 내부에서 분할하여 다수의 하위 네트워크로 나눠 사용
•
public subnet: 인터넷 게이트웨이로 트래픽이 라우팅되는 서브넷
•
pribate subnet: 인터넷 게이트웨이로 트래픽이 라우팅되지 않는 서브넷
•
internet gateway: 인터넷과 VPC 간의 통신을 가능케 하는 게이트웨이. 인터넷에서 요청이 오면 VPC의 ACL로 전달
•
ACL(Access Control List): network 앞단에서 VPC 내부/외부의 트래픽를 제어하는 방화벽 역할
•
라우팅 테이블: VPC의 트래픽을 전달할 위치를 결정하는 데 사용하는 트래픽 라우팅 규칙 리스트. 서브넷을 특정 라우팅 테이블과 명시적으로 연결하여 public, private 라우팅 테이블을 따로 지정할 수 있다.
•
보안 그룹: 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할. ACL이 네트워크 수준의 방화벽이라면, 보안그룹은 인스턴스 수준의 방화벽.
DB Private Access로 설정해야 하는 이유
기업에서 사용하는 DB에는 고객 정보나 결제 정보 등 민감한 데이터가 담긴다. DB를 Public Access로 놓으면 보안을 위협하는 요청을 포함해 외부 인터넷에서 오는 모든 요청을 받을 수 있다. 또한 퇴사자가 DB 정보를 알고 있거나 환경변수가 담긴 소스코드가 노출되는 등 DB 정보가 유출되면 어디에서든지 DB에 접근할 수 있는 문제가 있다.
아직 운좋게 DB가 털리지 않았다면 다행이지만 DB를 퍼블릭 액세스로 설정하는 것은 금고를 집 밖에 내놓은 행위와도 같다. 따라서 AWS에서 DB를 안전하게 관리하기 위해서는 퍼블릭 액세스 가능 여부를 기본값인 아니요 로 선택하고 같은 VPC 내의 인스턴스에서만 접근 가능하도록 변경해주어야 한다.
VPC 구성
VPC(Virtual Private Cloud)란?
VPC는 사용자 전용의 가상 네트워크를 의미한다. VPC는 다른 가상 네트워크와 분리되어 있고, VPC에 클라우드 리소스(EC2, RDS 등)를 연결하고 리소스에 들어오는 요청을 관리할 수 있다.
각각의 VPC로 분리된 인스턴스들
VPC 구성하기
VPC를 새로 만들 경우 인터넷 게이트웨이와 연결하고 VPC의 IP를 CIDR 주소를 설정해줘야 한다. 하지만 2013년 12월 이후 생성한 계정일 경우 각 가용 영역에 기본 VPC가 제공된다. 이 포스트에서는 기본 VPC를 사용하고, 대신 VPC 내에서 서브넷과 보안 그룹, 클라우드 리소스를 어떻게 구성해야할 지를 다룬다.
source: AWS
먼저, VPC 내 같은 리전에 퍼블릭 서브넷과 프라이빗 서브넷을 두어 서버와 DB 트래픽을 분리해야 한다.
•
퍼블릭 서브넷 - EC2 서버 인스턴스 연결: 서버에서 인터넷의 모든 요청을 받을 수 있게 함
•
프라이빗 서브넷 - DB를 연결: 퍼블릭 서브넷의 요청만 받을 수 있게 하여 외부 접근 차단
이해하기 쉽게 그림을 보자.
source: AWS
Availability Zone(가용 영역)
AWS에서는 정전이나 자연재해 등으로 인해 서비스가 마비되는 일을 막기 위해 지역을 몇 개의 구획으로 나누어 가용 영역으로 설정한다. 다른 지역이 서비스 불능 상태가 되어도 다른 지역에서 서비스할 수 있도록 하는 것이다. 가용 영역은 지역별로 A-Z까지 있는데, 서울 리전에서는 a,b,c,d 4개의 zone(ap-northeast-2a/2b/2c/2d)이 존재한다.
FTS(Fault Tolerance System, 장애 허용 시스템)은 위키에 따르면 시스템을 구성하는 부품의 일부에서 결함이 발생해도 정상적으로 기능을 수행하는 시스템을 말한다. AWS에서는 각각의 가용 영역에 기본 서브넷을 제공하며 서비스의 고가용성을 위해 영역 별로 인스턴스 실행을 권장한다. 이는 선택사항이며 인스턴스는 필요한 만큼만 만들자.
My VPC
우측 하단 My VPC 를 보면 VPC의 CIDR 주소가 보인다. 10.0.0.0/16 에서 16은 주소의 앞 16비트는 네트워크 접두어를 가리키고 나머지 16비트가 호스트 주소라는 것을 의미한다. 즉 16비트, 2**16개의 호스트 주소를 만들 수 있다. 만약 10.0.0.0/24인 경우 8비트, 2**8개(256개)의 호스트 주소를 만들 수 있다.
이때 VPC에 2개 이상의 서브넷을 만드는 경우 각 서브넷의 CIDR 블록이 겹쳐서는 안된다. 256개를 둘로 나눠 128개씩 블록을 나눠야 한다.
ex) 한 서브넷은 10.0.0.0/25 CIDR 블록(10.0.0.0 ~ 10.0.0.127)
다른 서브넷은 10.0.0.128/25 CIDR 블록(10.0.0.128 ~ 10.0.0.255) 사용
Public Subnet
인터넷으로부터 요청을 받을 인스턴스를 퍼블릭 서브넷에서 실행시킨다. 예를 들면 서버 인스턴스. Security Group을 통해 트래픽을 제어한다.
Private Subnet
서버 인스턴스의 요청을 받을 DB 인스턴스를 프라이빗 서브넷에 둔다. 기존 VPC에서 프라이빗 서브넷을 추가하는 경우 연결하고자 하는 퍼블릭 서브넷과 같은 존에 둔다. Security Group을 통해 트래픽을 제어한다.
Private DB 생성하기
private DB 설정 시, github action 같은 CI가 안돌아므로 웬만하면 Test DB로 먼저 진행해볼 것을 권장. 1. Private Subnet 생성하기
1.
AWS - VPC - 서브넷 생성
2.
기본 VPC 선택
3. 서브넷 설정
•
가용 영역: 서버 인스턴스의 public subnet과 같은 영역으로 선택(따로 만들지 않아도 영역별로 기본 서브넷이 만들어져 있을 것이다)
•
CIDR 블록: 'Subnet Sizing' AWS 문서를 참고해 CIDR 블록을 선택한다. 프라이빗 서브넷을 사용하므로 10.0.0.0/17 또는 10.0.0.0/19(여러 가용 영역 사용하는 경우) 사용
참고 이미지(서브넷 크기)
2. Private 보안 그룹 설정
•
인바운드 규칙: DB 인스턴스에서 요청을 받을 수 있는 리스트.
◦
서버의 EC2 인스턴스가 연결된 보안 그룹을 소스에서 선택해주면 된다.
•
아웃바운드 규칙: DB가 응답을 보낼 수 있는 리스트. '모든 트래픽'으로 설정.
3. DB 서브넷 그룹 생성
•
RDS - 서브넷 그룹 - 생성
•
VPC의 셀렉트 인풋을 클릭해줘야 '서브넷 추가' 섹션이 활성화된다.(버그인가)
•
서브넷 추가
◦
가용 영역: 서브넷을 만들어둔 가용 영역들을 선택한다.
◦
서브넷: 각 영역에서 프라이빗 서브넷을 선택한다.
4. Private DB 생성
•
DB가 서버 EC2 인스턴스와 같은 가용 영역에 있는지 확인할 것•
VPC: 기본 VPC 사용
•
서브넷 그룹: 3번에서 만든 private db subnet group 선택
•
퍼블릭 액세스 가능: '아니요'
•
VPC 보안 그룹: 기존 VPC 보안 그룹 - 2번에서 만든 private 보안그룹 선택
연결 체크
테스트 서버 요청
테스트 사이트로 접속했을 때 private 설정이 된 DB의 데이터를 잘 가져온다면 성공.
로컬에서 접속
설정이 끝났다면 mysql workbench 같은 DB client로 RDS에 접속해서 로컬에서 접속이 되는지 확인한다.
private DB로 설정했기 때문에 로컬 컴퓨터로는 접속되서는 안된다.
로컬에서 접속이 안된다면 개발, 디버깅할 때 필시 불편한 사항이 생길 것이다. 특정 클라이언트 컴퓨터에서도 DB에 접근할 수 있도록 다음에는 VPN 설정을 해보자.
references
•
[AWS 문서] AWS의 VPC 아키텍처 예시
•
[AWS 문서] aws db에 사용할 VPC 생성 자습서
•
[AWS 미디엄 블로그] Practical VPC Design
