[네트워크] VPC 이해하기 (feat VPC 아키텍처)

들어가며

아키텍처를 설계하면서, 견고한 아키텍처를 설계하려면 어떻게 해야 할까 늘 고민하고 있습니다. 아키텍처의 네트워크 환경을 잘 구축하려면 어떻게 해야 할까 고민하던 중, VPC 개념에 대해 알 수 있었습니다. 이번 기회에 VPC를 적용해서 더 나은 서버구조를 설계하고 싶었습니다. 이 글을 시작으로 VPC에 대해 정리합니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

VPC

VPC란 Virtual Private Cloud의 약자로, 가상으로 존재하는 데이터 센터라고 할 수 있습니다. AWS에서는 VPC를 아래와 같이 소개하고 있습니다.

 

 

 

Amazon Virtual Private Cloud(VPC)를 사용하면 AWS 클라우드에서 논리적으로 격리된 공간을 프로비저닝 하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 완벽하게 제어할 수 있습니다. VPC에서 IPv4와 IPv6를 모두 사용하여 리소스와 애플리케이션에 안전하고 쉽게 액세스 할 수 있습니다. – AWS -

 

 

 

VPC를 사용하면, 클라우드에서 논리적으로 격리된 공간을 프로비저닝 하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 활용할 수 있습니다. 만약 EC2, RDS 등 AWS의 리소스를 만든다고 생각해 보겠습니다. 개인적으로 AWS 리소스를 만들 땐 리소스를 빨리 만들어서 어떻게 활용해야 할지에 집중했었습니다. 하지만 AWS는 사용자를 위해 AWS 리소스들을 생성할 때 자동으로 격리된 네트워크 환경에 리소스를 구성해두고 있었습니다. 그래서 다른 사람들은 우리 리소스에 접근하지 못하도록 설정해주고 있었습니다. 이 처럼, 하나의 계정에서 생성하는 AWS 리소스들만의 격리된 네트워크 환경을 만들어주는 기능이 VPC입니다. 

 

 

 

 

 

 

VPC를 구성한다면

만약 여러분들이 AWS 계정이 있다면, AWS에서는 기본적인 VPC 환경을 구축해 줍니다. Default VPC에 AWS 환경을 구축하면, 모든 서브넷의 인터넷 접근이 가능합니다. Default VPC를 확인하고 싶다면, VPC 대시보드에서 '_'라는 이름으로 확인이 가능합니다. Default VPC를 삭제할 순 있지만, 한 번 삭제하면, 복구하기가 어렵기 때문에, 삭제하지 않는 것이 좋습니다. 

 

 

 

 

 

 

서로 다른 VPC가 소통하려면

만약 여러 개의 VPC를 구성해서 인스턴스를 실행했는데, VPC안에 있는 인스턴스끼리 소통해야 한다면 어떻게 해야 할까요? 이때는 두 VPC 사이의 네트워크 연결(VPC Peering)이 가능합니다. VPC Peering을 구성한다면, 서로 다른 VPC에 존재하는 인스턴스가 서로 통신할 수 있습니다. 

 

이 글을 시작으로, VPC를 제대로 알아보기 위해 Default VPC를 활용하는 것이 아닌, Custom VPC를 구축해서, 활용하고자 합니다. Custom VPC란, 말 그대로 VPC를 새롭게 만들어서 활용하는 것을 뜻합니다. 그럼 이런 VPC를 왜 구축해야 할까요? 이에 대해 알아보겠습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

Why VPC?

VPC는 VPN, 하드웨어 또는 물리적 데이터 센터 없이도 AWS 클라우드에서 가상 네트워크를 구축할 수 있도록 해줍니다. 만약 외부에서 접근해서는 안 되는 AWS 리소스 같은 경우, 외부에서 접근하지 못하도록 제어할 수도 있습니다. VPC를 통해 네트워크 공간을 정의할 수 있고, AWS 자원들을 안전하게 관리할 수 있습니다. 

 

 

 

VPC를 통해 네트워크를 구성하는 방식은 개발 조직별로 다르겠지만, 아키텍처 패턴에는 아래와 같은 패턴들이 있을 수 있습니다.

 

 

 

1. 단일 VPC: 기존 단일 데이터센터를 VPC로 구현한 것이라고 보면 된다. 여러 조직이 VPC를 사용함에 따라 보안적인 측면 등 복잡도가 높다. 또 VPC가 제공하는 각 리소스의 limit에 걸릴 확률도 높아진다.
2. 보안 수준별 VPC 분리: 보안적인 데이터 분류에 따라 VPC를 분리한다. 여전히 여러 조직이 사용하며, 여전히 개발/운영 환경은 분리되어 있지 않다. 
3. 애플리케이션별 VPC 분리: 새로운 애플리케이션이 추가될 때마다 VPC를 추가한다. 따라서 변경 작업 시 영향도가 줄어든다. 다만 피어링 복잡도가 증가할 수 있다.
4. 운영 환경별 VPC 분리: 개발, 운영 등 환경에 따라 분리한다. 환경에 따른 보안 통제가 가능하다는 점이 장점이다. 단일 VPC를 여러 조직이 사용하게 됨에 따른 보안적 고려 사항이 발생하고, VPC가 제공하는 각 리소스의 limit에 걸릴 확률도 높아지는 등의 문제도 존재한다. 
5. 멀티 어카운트 & 애플리케이션별 VPC 분리: 3에 어카운트에 분리가 적용된 것이다.

 

 

 

 

 

 

 

 

 

 

 

만약 VPC를 구축할 때 단일 VPC에 모든 자원을 넣는다면, 해커가 네트워크에 접근했을 때, 자원이 모두 노출됩니다. 이를 보완하기 위해 서브넷으로 다중 계층 VPC 아키텍처를 만들어 방어 계층을 이룰 수 있습니다. 위의 그림처럼, VPC를 구성할 때 3 계층으로 나눠서 관리하는 방식도 존재합니다. 웹 서버, WAS, DB 3개로 나눠서 구축할 수 있습니다. 이렇게 한다면, 각 계층들은 서로 독립적이므로 서로 영향을 끼치지 않습니다. 

 

 

 

 

이런 VPC를 활용하기 위해서는 서브넷, 라우팅, 게이트웨이, CIDR 등을 설정해줘야 합니다. 다음 글에서는 VPC에 활용하는 리소스들을 살펴보도록 하겠습니다. 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

마치며

네트워크에 대해 조금씩이라도 지식을 쌓아가고 싶습니다. 기본을 꾸준히 쌓을 수 있는 개발자가 되겠습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

출처

VPC는 Sims같아요. (AWS 강의실 - VPC 개념)

[ AWS ] VPC 생성하기

[AWS] 가장쉽게 VPC 개념잡기

만들면서 배우는 아마존 VPC(Amazon VPC) 입문: AWS 네트워크의 기초

Amazon VPC란 무엇인가?

3-Tier VPC Architecture with Terraform

[AWS] AWS로 구축하는 3티어 아키텍처