클라우드를 공부할 때 가장 먼저 마주치는 개념 중 하나가 바로 VPC(Virtual Private Cloud)입니다. AWS에는 수많은 서비스가 있지만, 그 모든 서비스들이 제대로 작동하기 위해서는 ‘안전한 네트워크 공간’이 필요합니다. 마치 우리가 집을 짓기 전에 먼저 땅을 마련해야 하는 것처럼, AWS에서도 서비스들을 올려두기 위해 가장 먼저 마련해야 하는 공간이 바로 VPC입니다.
VPC는 이름 그대로 가상의 사설 네트워크라고 할 수 있습니다. AWS가 거대한 도시라면, VPC는 그 도시 안에서 내가 소유한 하나의 땅(구역)입니다. 이 땅 안에서는 집(서버), 창고(스토리지), 상점(애플리케이션)을 자유롭게 세울 수 있고, 담장(보안 규칙)을 쳐서 외부와 차단하거나, 대문(인터넷 게이트웨이)을 열어 외부와 소통할 수도 있습니다.
이러한 VPC의 개념은 단순히 인프라 담당자만 알아야 하는 지식이 아닙니다. 개발자라면 내가 만든 애플리케이션이 어떤 네트워크 환경에서 동작하는지 이해할 수 있고, 기획자라면 서비스 구조를 설계할 때 현실적인 제약을 고려할 수 있으며, 보안 담당자라면 방화벽 규칙과 접근 제어가 어떻게 이루어지는지 감을 잡을 수 있습니다.
저처럼 개발에 대해 전혀 배경 지식이 없는 분들도 AWS의 구조를 보다 쉽게 이해할 수 있도록, 이번 글에서는 AWS VPC를 직접 생성해 보면서 각 단계에서 어떤 개념이 등장하고 왜 필요한지 차근차근 살펴보려고 합니다.
1. VPC 대시보드
가장 먼저 검색창에 VPC를 검색하고 검색창에 나타난 보라색 아이콘의 VPC를 클릭해서 VPC 메뉴로 이동합니다. 처음 메뉴로 들어가면 보게되는 화면이 VPC 대시보드 입니다. VPC 대시보드는 VPC를 생성하거나 관리할 때 가장 먼저 접하게 되는 화면입니다. 현재 계정과 리전에 생성된 VPC 개수, 서브넷 수, 라우팅 테이블, 인터넷 게이트웨이 등의 리소스 현황을 한눈에 볼 수 있습니다. 처음 들어가 보면 VPC를 생성한 적이 없지만 디폴트로 생성된 VPC가 있기 때문에 “1”로 표기된 것을 볼 수 있습니다.
2. Create 대시보드 클릭
AWS에서 네트워크를 직접 설계한다면 일반적으로 VPC를 생성 후 인터넷 게이트웨이를 연결하고 필요하다면 NAT게이트웨이를 생성합니다. 그리고 서브넷을 생성하고 라우팅 테이블 구성 및 연결을 해줘야하는 복잡한 과정을 거치게 됩니다. 그러나, Creat VPC 버튼을 클릭해 VPC를 생성하게 되면, 빠르게 기본 VPC 환경을 세팅하고 생성할 수 있습니다. 즉, Create VPC 버튼은 AWS가 제공하는 빠른 시작 가이드 같은 기능입니다.
3. VPC and more 옵션 선택
Create VPC 버튼을 클릭하면 가장 먼저 선택해야하는 옵션은 VPC Only와 VPC and more 옵션입니다.
VPC는 순수하게 VPC만 생성하는 옵션입니다. 따라서 네트워크 공간만 비워 놓은 상태로, 서브넷, 인터넷 게이트웨이, 라우팅 테이블 등 사용자가 직접 하나하나 리소스를 생성하고 연결해야하는 옵션입니다. VPC and more 옵션은 기본적인 네트워크 구성 요소를 함께 자동으로 생성해주는 옵션입니다. VPC Only는 네트워크를 처음부터 끝까지 직접 설계하고 싶은 경우, 또는 보안과 구조를 매우 세밀하게 통제해야 하는 경우에 적합합니다. 예를 들어, 실제 운영 환경에서 특정 보안 규칙을 엄격하게 적용하거나 특수한 네트워크 구조가 필요한 경우입니다.
VPC and more는 학습이나 실습을 목적으로 빠르게 네트워크를 구성하고 싶은 경우에 적합합니다. 기본적인 구성 요소가 자동으로 만들어지기 때문에 초보자도 부담 없이 시작할 수 있습니다.
따라서 앞으로 블로그 시리즈에서는 서브넷, NAT 게이트웨이, 라우팅 테이블 등 다양한 네트워크 요소들을 직접 살펴보고 실습할 예정이므로 VPC and more 옵션으로 선택해 생성해줍니다.
4. 이름 태그와 사이더 블록 선택
이름은 아무거나 원하시는 것을 넣어주면 되며, CIDR 블록은 디폴트 값을 그대로 설정합니다. 여기서 서브넷 개념을 조금 알아야 이해할 수 있는데, 기본 설정인 16을 24로 변경해주면 256개의 IP를 사용할 수 있는 크기 대역이 설정되는 것을 볼 수 있습니다. 저는 기본 설정값을 우선 그대로 두었습니다.
5. 가용 영역(AZ)과 퍼블릭 서브넷과 프라이빗 서브넷 설정
여기서 Availability Zone(AZ)는 AWS 리전(Region) 안에 있는 독립적인 데이터 센터 구역을 의미합니다. 하나의 리전은 여러개의 AZ로 구성되어 있으며, 각 AZ는 전력, 네트워크, 보안 인프라가 독립적으로 운영됩니다. 하지만 같은 리전 안의 AZ들은 고속 네트워크로 연결되어 있고 서로 다른 AZ에 있는 리소스끼리도 빠르게 통신할 수 있습니다.
VPC를 하나의 가상 네트워크로 생각하면, AZ는 그 안에서 리소스를 실제로 배치할 수 있는 구역입니다. 예를 들어, 리전을 “도시”로 비유하면, AZ는 도시 안에 있는 서로 다른 “건물”입니다. 각 건물은 전력과 설비가 독립적이라, 한 건물에 문제가 생겨도 다른 건물은 정상적으로 운영됩니다. 따라서 VPC 안에 리소스를 만들 때 어떤 AZ에 배치할지를 선택하게 되며, 이를 통해 서비스 안정성을 높일 수 있습니다.
VPC를 생성할 때 Availability Zone을 하나만 선택하는 것도 가능하지만, 이번 실습에서는 두 개의 AZ를 선택했습니다. 그 이유는 앞으로 진행할 다양한 실습에서 고가용성과 분산 구조를 다루기 위함입니다.
만약 하나의 AZ만 사용한다면, 모든 리소스가 같은 구역 안에 집중되게 되고, 해당 AZ에 장애가 발생하면, 그 안에 배치된 서버, 데이터베이스, 애플리케이션이 모두 영향을 받아 서비스 전체가 중단될 수 있습니다. 하지만 두 개의 AZ를 사용하면 상황이 달라집니다. 리소스를 서로 다른 AZ에 분산해 두었기 때문에, 한쪽 AZ에 문제가 생겨도 다른 AZ에서 서비스가 정상적으로 유지될 수 있습니다.
또한 오토스케일링이나 로드 밸런싱과 같은 기능을 실습할 때도 두 개 이상의 AZ가 필요합니다. 트래픽이 한쪽에만 집중되지 않고 여러 구역에 걸쳐 고르게 분산되기 때문에 안정적이고 유연한 아키텍처를 직접 경험할 수 있습니다. 데이터베이스 역시 다중 AZ 배포를 통해 한쪽에 문제가 생겨도 다른 쪽에서 자동으로 동작을 이어받는 구조를 확인할 수 있습니다.
이와 같은 맥락에서, 이번 실습에서는 퍼블릭 서브넷과 프라이빗 서브넷도 각각 두 개씩 생성하는 것으로 선택합니다. 퍼블릭 서브넷은 인터넷 게이트웨이를 통해 외부와 직접 연결되는 공간으로, 웹 서버나 로드 밸런서처럼 외부에서 접근 가능한 자원을 배치하는 데 사용됩니다. 반면 프라이빗 서브넷은 외부와 직접 연결되지 않는 공간으로, 데이터베이스나 내부 전용 애플리케이션처럼 보안이 중요한 자원을 배치하는 데 적합합니다.
퍼블릭과 프라이빗 서브넷을 두 개씩 만드는 이유는 앞서 Availability Zone을 두 개로 설정한 것과 같은 맥락으로 만약 퍼블릭 서브넷이나 프라이빗 서브넷이 한쪽 AZ에만 존재한다면, 해당 AZ에 장애가 발생했을 때 서비스가 중단될 위험이 큽니다. 반대로 두 개의 AZ에 걸쳐 각각 퍼블릭과 프라이빗 서브넷을 하나씩 배치해두면, 한쪽이 중단되더라도 다른 쪽에서 서비스를 이어갈 수 있습니다. 이는 서비스의 안정성을 높이는 기본적인 설계 원칙이기도 합니다.
따라서 이번 실습에서는 Availability Zone을 2개로 설정하고, 퍼블릭 서브넷과 프라이빗 서브넷 역시 각각 2개를 선택하여 실제 운영 환경에서 요구되는 고가용성과 안정성을 직접 체험할 수 있는 구조를 만들어보겠습니다.
6. NAT 게이트웨이와 VPC 엔드포인트 설정
VPC를 구성할 때, 퍼블릭 서브넷과 프라이빗 서브넷을 분리해서 만드는 이유는 보안과 안정성 때문입니다. 퍼블릭 서브넷은 인터넷과 직접 연결되어 외부에서 접근할 수 있지만, 프라이빗 서브넷은 외부에서 직접 접근할 수 없도록 차단되어 있습니다. 이렇게 하면 데이터베이스와 같은 민감한 자원을 안전하게 보호할 수 있습니다.
그러나 프라이빗 서브넷에 있는 자원들이 인터넷과 전혀 통신하지 못한다면 문제가 됩니다. 예를 들어 데이터베이스 서버가 보안 패치를 다운로드하거나, 애플리케이션 서버가 외부 API를 호출해야 하는 상황이 있을 수 있습니다. 이런 경우를 위해 사용하는 것이 바로 NAT 게이트웨이(Network Address Translation Gateway)입니다. NAT 게이트웨이는 프라이빗 서브넷에 있는 인스턴스들이 인터넷으로 나가는 통신은 가능하게 하되, 외부에서 직접 들어오는 연결은 차단하는 일종의 중계 역할을 합니다.
이번 실습에서는 NAT 게이트웨이를 생성할 때 “In 1 AZ” 옵션을 선택합니다. 이 옵션은 말 그대로 하나의 Availability Zone에만 NAT 게이트웨이를 배치하는 방식으로 AWS에서는 고가용성을 위해 각 AZ마다 하나씩 NAT 게이트웨이를 두는 “1 per AZ” 구성을 권장하지만, NAT 게이트웨이는 비용이 발생하는 리소스이기 때문에 굳이 여러 개를 둘 필요가 없습니다. 따라서 이번 실습에서는 비용을 최소화하면서 NAT 게이트웨이의 역할을 이해하는 데 집중하기 위해 “In 1 AZ” 옵션을 선택해줍니다.
다음으로 VPC 엔드포인트는 None으로 설정해줍니다. VPC 엔드포인트는 VPC 내부의 리소스가 인터넷 게이트웨이나 NAT 게이트웨이를 거치지 않고도 AWS의 다른 서비스(S3, DynamoDB 등)와 직접 연결할 수 있게 해주는 통로입니다. 즉, 인터넷을 경유하지 않고 AWS 내부 네트워크를 통해 안전하고 빠르게 서비스에 접근할 수 있는 기능입니다.
간단히 예를 든다면, 프라이빗 서브넷에 있는 인스턴스가 S3 버킷에 접근해야 한다면, 원래는 NAT 게이트웨이를 통해 인터넷을 거쳐야 합니다. 하지만 S3에 대한 VPC 엔드포인트를 만들어두면, 인터넷을 거치지 않고 바로 S3에 접속할 수 있습니다. 이렇게 하면 비용 절감과 보안성 강화라는 두 가지 효과를 얻을 수 있습니다. 그러나 아직 S3나 다른 서비스와의 직접 연결에 대한 것은 고려하고 있지 않아 None으로 설정해줍니다
7. 프리뷰를 통한 확인과 최종 생성
이렇게 설정을 마치고 나면, 옆에 프리뷰를 통해 구성한 내용을 볼 수 있습니다. 왼쪽부터 VPC가 생성되어 있고 그 안에 설정한 4개의 서브넷, 그리고 라우트 테이블 3개, NAT와 외부 인터넷과 연결할 수 있는 인터넷 게이트웨이(IGW)가 있는 것을 볼 수 있습니다. 여기서 라우트 테이블은 3개가 생성된 이유를 알아본다면, Public 라우트 테이블은 퍼블릭 서브넷 2개가 공통으로 연결된 라우트 테이블이고 외부 인터넷으로 나가는 기본 경로가 인터넷 게이트웨이를 통해 연결되어 있습니다. 퍼블릭 서브넷은 인터넷에 직접 연결되어야 하므로 두 서브넷이 같은 테이블을 공유합니다. 그리고 두개의 프라이빗 서브넷은 개별마다 라우트 테이블을 가지기 때문에 2개가 생성되어 있습니다.
이렇게 프리뷰를 모두 확인한 후 생성 버튼을 눌러줍니다.
생성 버튼을 누르면 VPC를 생성하는 것을 볼 수 있고 5분정도 기다리면 생성이 완료됩니다.
결론. 생성된 VPC 확인
이제 왼쪽메뉴의 Your VPCs 메뉴로 들어가면, 위에서 만들어준 VPC가 있는 것을 확인할 수 있습니다. 이름이 없는 VPC는 디폴트로 생성되어 있는 VPC입니다. 또한 Subnet 메뉴를 통해서도 만들어진 4개의 퍼블릭과 프라이빗 서브넷을 확인할 수 있습니다. 다만, 이때 저는 생성된 후 메뉴에 들어가도 만들어진 서브넷이 보이지 않았는데 전체 새로고침을 하니 생성된 서브넷이 보였습니다.
오늘은 이렇게 VPC를 생성하는 과정과 그 과정에서 필요한 개념들은 간략하게나마 정리해보았습니다. 저처럼 처음 시작하는 분들께 많은 도움이 되었으면 좋겠습니다.