🤔 VPC를 왜 설계해요?
일단 config 서버를 구성하기 이전에 AWS를 효율적으로 사용하기 위해 VPC부터 설계를 하도록 하겠습니다.
제가 VPC를 설계하는 이유는 다음과 같습니다.
- 위드마켓에서 사용되는 모든 Back-End 서비스를 구조적으로 관리하기 위함이다.
- 위드마켓 Back-End 서비스에는 외부에서 사용해도 되는 서비스가 있고, 내부적으로만 사용해야만하는 서비스가 존재한다. 이러한 서비스들을 격리적으로 관리하는 정책을 이용하기위해 VPC를 설계한다.
따라서 지금부터 VPC를 설계해보도록 하겠습니다.
🔥 VPC를 하나 만들어봅시다
우선 VPC 생성부터 진행하겠습니다.
VPC 생성에서 중요한 것은, IPv4 CIDR 블록을 어떻게 잡느냐입니다.
저는 고전적인 방식인 Classical IP 관리법에 따라서 class B IP를 가져가도록 하겠습니다. (믈론 class를 나눠서 IP를 나누지 않으셔도 됩니다. 그저 이건 제 취향입니다)
따라서 저는 10.1.0.0/16 같이 10.1.xxx.xxx IP만 사용하도록 VPC를 구성하였습니다.
다음으로, VPC를 만들었으니 subnet을 만들도록 하겠습니다.
🔥 이제 VPC를 구성하는 서브넷을 만들어보도록 하겠습니다
제가 만들 subnet은 총 4가지입니다. 그 중에서 public subnet은 2개, private subnet은 2개를 만들어둘 생각입니다.
각각의 subnet 목적은 다음과 같습니다.
- public subnet : external api service를 운영하기 위한 subnet으로 활용한다
- private subnet : internal api service 혹은 config server를 운영하기 위한 subnet으로 활용한다
따라서 AWS의 VPC 서비스로 들어가서 서브넷 생성을 해줍시다
우선 저는 이전에 만들었던 vpc를 선택하고 서브넷 설정을 하겠습니다.
여기서 중요한 것은 가용 영역 설정과 Ipv4 CIDR 블록 설정 입니다.
가용영역 설정의 경우, AWS 서울 리전의 경우 ap-northeast-2a, b, c로 세 가지의 AZ(Available Zone)이 존재합니다.
여기서 중요한 것은, public subnet 1, 2, private subnet 1, 2 끼리 가용영역을 맞춰야한다는 것입니다.
예를들어, public subnet 1을 ap-northeast-2a 에서 운용한다고 하면, private subnet 1을 ap-northeast-2a에서 운용을 해야한다는 것입니다.
이유는 간단합니다. 만일 public subnet1에서 bastion host를 운용한다고 하면 private subnet에서는 public subnet1의 bastion host를 이용해서 외부와 통신을 해야하는데 만일 둘의 AZ가 다르다면 NAT Gateway를 통해서 private subnet에서 외부와 통신을 하지 못하기 때문입니다.
따라서 저는 아래와 같이 설정을 해주었습니다.
subnet의 이름, 가용영역, IPv4 CIDR 순서로 적었습니다
- public-subnet-1 : ap-northeast-2a, 10.1.0.0/24
- public-subnet-2 : ap-northeast-2c, 10.1.1.0/24
- private-subnet-1 : ap-northeast-2a, 10.1.100.0/24
- private-subnet-2 : ap-northeast-2c, 10.1.101.0/24
다음으로, VPC에 Internet gateway를 연결하고 각각의 subnet에 routing table을 만들어주도록 하겠습니다
🔥 라우팅 테이블을 작성합시다
우선 라우팅 테이블을 작성하기 이전에, VPC의 구성요소들이 외부와 통신하기 위해서 internet gateway를 생성하고 이를 vpc에 연결하도록 하겠습니다
🔨 Internet gateway를 생성합시다
가상프라이빗 클라우드에서 인터넷 게이트웨이 를 클릭하여 인터넷 게이트웨이를 생성해줍시다.
여기서 이름만 간단하게 작성하고 생성을 하시면 되는데, 초기에 생성하면 internet gateway의 상태가 Detached 라고 뜹니다.
이는 아직 internet gateway가 vpc에 연결이 되지 않았다는 뜻이므로, 이를 저희가 만들었던 vpc에 연결을 해주면됩니다.
🔨 이제 routing table을 작성합시다
우선 가상 프라이빗 클라우드 메뉴에서 라우팅 테이블로 들어가서 라우팅 테이블을 생성하겠습니다.
라우팅 테이블을 생성하시면 초기에는 이렇게 뜨는데, 이를 각각의 서브넷의 정책에 맞게 설정을 해주시면 됩니다.
저는 라우팅 테이블을 아래와같이 설정을 해주었습니다.
- public subnet : 10.1.0.0/16 -> local, 0.0.0.0/0 -> internet gateway
- private subnet : 10.1.0.0/16 -> local
우선 저희는 NAT Gateway를 설정하지 않았기 때문에 private subnet은 10.1.0.0/16에서 들어온 트래픽은 무조건 local로 돌리게 라우팅 테이블을 작성했습니다.
그리고 이렇게 라우팅 테이블의 작성이 끝났다면, 각각의 라우팅 테이블을 subnet에 연결을 해주면됩니다.
다음으로, NACL(Network ACL)을 설정하겠습니다.
🔥 NACL을 설정합시다
NACL은 특정한 프로토콜, 특정 포트, 특정 IP로 들어오는 트래픽을 제어하는 일종의 보안 방화벽 역할을 수행합니다.
따라서 저는 아래와 같이 NACL을 설정해주었습니다.
🔨 public subnet의 NACL 설정
Inbound Rules
- 80(HTTP)번 포트로 0.0.0.0/0에서 들어오는 요청은 Allow
- 443(HTTPS)번 포트로 0.0.0.0/0에서 들어오는 요청은 Allow
- 22(SSH)번 포트로 개발 환경의 IP에서 들어오는 요청은 Allow
- 1024~65535번 포트로 0.0.0.0/0에서 들어오는 요청은 Allow
- 그 외의 요청은 모두 Deny
Out bound rules
- 80(HTTP)번 포트로 0.0.0.0/0으로 보내는 요청은 Allow
- 443(HTTPS)번 포트로 0.0.0.0/0으로 보내는 요청은 Allow
- 22(SSH)번 포트로 0.0.0.0/0으로 보내는 요청은 Allow
- 1024~65535번 포트로 0.0.0.0/0으로 보내는 요청은 Allow
- 그 외의 요청은 모두 Deny
🔨 private subnet의 NACL 설정
Inbound Rules
- 22(SSH)번 포트로 10.1.0.0/16에서 들어오는 요청은 Allow
- 그 외의 요청은 모두 Deny
Outbound Rules
- 1024~65535번 포트로 0.0.0.0/0으로 보내는 TCP 요청은 모두 Allow
- 그 외의 요청은 모두 Deny
이렇게 설정을 해주시면 private subnet은 무조건 외부와 통신을 하기 위해서는 Bastion Host를 탈수밖에 없고, public subnet은 별도의 제약 없이 외부와 통신이 가능하지만, SSH 접속을 위해서는 무조건 허가된 IP로만 접속해야할 것입니다.
그리고 각각의 NACL을 subnet에 연결을 해주시면 됩니다.
다음으로, NAT Gateway를 생성하도록 하겠습니다.
🔥 NAT Gateway를 설정하도록 하겠습니다
NAT Gateway를 설정하기 위해서는 우선 Elastic IP 하나를 할당해야합니다.
일단, 탄력적 IP를 먼저 할당을 해줍시다.
🔨 Elastic IP를 하나 할당합시다
EC2에서 탄력적 IP 주소로 들어가보시면, IP 주소를 하나 할당할 수 있습니다.
여기서는 별도의 입력 없이 태그만 달아서 잘 할당을 해주면 되겠습니다.
🔨 다음으로 NAT Gateway를 할당합시다
VPC의 가상 프라이빗 클라우드에서 NAT 게이트웨이로 들어가서 NAT Gateway를 하나 생성합시다.
여기서 중요한 점은, private subnet 1을 외부와 통신을 시키기 위해서는 public subnet 1에 NAT Gateway를 위치시켜야 한다 라는 것입니다. 왜냐하면, 저희는 애초에 설정을 할때부터 subnet마다 가용영역을 달리하였기 때문에 서로 가용영역을 맞춰주어야 NAT Gateway가 잘 작동합니다
따라서 서브넷은 위와 같은 방식으로 설정을 하고, 이전에 할당하였던 탄력적 IP를 NAT Gateway에 붙여줍니다.
그리고 private subnet의 라우팅 테이블에 아래와 같이 추가해줍니다.
0.0.0.0/0으로 들어오는 요청은 모두 NAT Gateway로 보낸다
이렇게만 작성을 해주시면, 위드마켓에서 사용할 VPC의 설정은 모두 끝나게됩니다. (추가 설정을 할게 필요할 때마다 포스트를 추가하겠습니다)
🌲 글을 마치며
이번 포스트에서는 위드마켓의 Back-End 서비스를 배치하게 위한 VPC를 설정해보았습니다.
다음 포스트에서는, private subnet에 config server를 배치하여 여러가지 필요한 설정 정보들을 안전하게 프로젝트에서 가져올 수 있도록 하는 방법에 대해서 포스트를 해보겠습니다.
다음 포스트에서 뵙겠습니다. 감사합니다!
