본문 바로가기
Amazon Web Service Network 쉽게 이해하기

Virtual Private Cloud(VPC) 쉽게 이해하기 #1

by 네트워크 엔지니어 환영 2020. 3. 31.
반응형
VPC(Virtual Private Cloud)
Amazon Virtual Private Cloud(Amazon VPC)에서는 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

출처 : AWS VPC 설명서

AWS와 네트워크를 처음 접해보시는 분이 위의 정의를 접한다면 무슨 말인지 알쏭달쏭할 것 같습니다. 문서로 읽자니 답답하고 AWS Console을 통해 들어가 많은 옵션을 누르다 보면 지치기 마련이죠. 그렇다고 또 안 볼 수는 없습니다. 2011년 VPC 출시 이후 EC2-Classic Platform(VPC 출시 전의 네트워크)의 사용이 중단되고, VPC 사용이 의무화된 데다 대부분의 AWS 서비스가 VPC에 의존적이기 때문에 VPC에 대한 이해는 필수적입니다. 

<EC2-Classic Platform과 VPC의 차이(출처 : 44bits 기술블로그)>

이번 문서에서는 VPC가 도대체 무엇인지 또 우리가 사용 중인 네트워크와 무슨 관련이 있는지 알아보고자 합니다. VPC와 네트워크를 이해하지 않고서는 다른 서비스를 이해할 수 없고 나아가 서비스를 설계할 수 없죠. 이번 기회에 VPC에 대해 제대로 이해한다면 AWS를 다루는데 큰 도움이 되리라 생각합니다.

 

IP(Internet Protocol)

(IP가 무엇인지 어느정도 알고 있다는 전제를 깔고 시작합니다.)

 

IP는 크게 '공인 IP'와 '사설 IP'로 나누어 볼 수 있습니다. 공인 IP는 인터넷망에서 한 단말에서 한 단말로 접속할 수 있는 주소로 인터넷 망 내부에서 고유한 존재입니다. 즉 공인 IP는 어느 한 군데에서 사용 중이라면 다른 곳에서 사용할 수 없습니다. 공인 IP는 현재 IPv4의 경우, 총 42억 개를 사용할 수 있습니다. 인터넷 초창기에는 넉넉한 숫자였지만 요즘처럼 인터넷이 대중화된 시대에는 매우 부족한 숫자죠.

그래서 IP 주소의 낭비를 차단, 내부 자원 보호 등의 이유로 사설 IP를 사용하게 됩니다. 사설 IP는 공인 IP 대역 내 'Private Network'로 지정된 대역으로서, 공인 IP에서는 해당 대역을 사용하지 않고 오로지 외부 인터넷과 관련되지 않는 내부 사설 네트워크에서만 사용됩니다. 사설 IP로 지정된 대역은 다음과 같습니다.

10.0.0.0 ~ 10.255.255.255 - > A Class(10.0.0.0/8)
172.16.0.0 ~ 172.31.255.255 - > B Class(172.16.0.0/12)
192.168.0.0 ~ 192.168.255.255 - > C Class(192.168.0.0./16)

이 사설 IP는 공인 IP와는 다르게 중복하여 사용할 수 있습니다. 다시 말해 우리집 공유기에서 저 사설 IP를 사용한다고 해서 다른 집에서 저 사설 IP를 사용할 수 없는 것이 아닙니다. 우리 집 주소(아마존 아파트 103동 202호)가 전 세계에서 유일하며 고유한 주소이지만 '거실'이라고 하는 단어를 쓰는 공간은 어느 집이든 있지요. 도둑이 집을 털 때도 '아마존 아파트 103동 202호 거실을 털자'라고 해야 털 수 있지, '거실을 털자'라고 말을 한다면 어느 집 거실인지 모를겁니다. 그러므로 사설 IP는 어디서든 내부에서 마음껏 쓰고 외부망인 인터넷을 나갈 때는 고유 IP인 공인 IP를 가지고 나가게 됩니다.

 

Virtual Private Cloud(VPC)

Amazon Virtual Private Cloud(Amazon VPC)에서는 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 매우 유사합니다.

출처 : AWS VPC 설명서

Private Network를 활용하여 네트워크망을 구성하고 내부에 각종 Resource를 탑재할 수 있는 서비스를 VPC라 합니다. 대표적으로 EC2, ELB, RDS, Security Group, Network ACL 등이 있습니다. VPC에 들어 가는 Resource(EC2 등)들은 고유의 사설 IP와 Interface를 반드시 갖게 되며 외부에 공개될 Resource의 경우, 공인 IP를 보유할 수 있습니다. 그리고 AWS 사용자 정의 네트워크 VPC에서 사용하는 사설 IP에 대해 살펴보면 다음과 같습니다.

 

VPC를 생성하는 경우, 다음과 같이 /16RFC 1918:규격에 따라 프라이빗(비공개적으로 라우팅 가능) IPv4 주소 범위에 속하는 CIDR 블록( 또는 이하)을 지정하는 것이 좋습니다.

10.0.0.0 - 10.255.255.255 (10/8 접두사)
172.16.0.0 - 172.31.255.255 (172.16/12 접두사)
192.168.0.0 - 192.168.255.255 (192.168/16 접두사)

VPC 생성시 허용되는 블록 크기는 /28 넷마스크 ~ /16 넷마스크입니다. 

출처 : AWS VPC 설명서

AWS VPC는 On-premise(전통적인 인프라)와 동일한 대역의 사설 IP를 사용할 수 있으며 모든 AWS 계정은 위의 사설 IP 대역을 사용할 수 있습니다. 다만 다른 점이 있다면 원래 규정된 사설 IP 범위와는 다르게 /16 ~ /28비트의 서브넷 마스크만을 허용한다는 것이 있습니다. 즉 VPC를 생성할 수 있는 가장 큰 대역은 /16이며, 가장 작은 대역은 /28입니다.

 

아래 그림은 VPC를 /16로 생성하고 난 후 Subnet을 생성한 것의 예시입니다. 최대 크기인 /16로 설정하였군요. (Subnet은 다음 항목에서 설명합니다)

<VPC의 예시 (출처: AWS 설명서)>

위의 그림에서 보면 알 수 있듯이 AWS Cloud 내에는 IDC의 집합인 'Region'이 존재하며 Region은 IDC인 다수의 'Availability Zone(AZ)'으로 이루어집니다. 그중에서 VPCRegion에 상응하는 규모의 네트워크를 뜻한다는 것을 알 수 있습니다.

반응형

 

Subnet

(Subnet Mask와 broadcast에 대한 기본 이해가 꼭 필요합니다.)

 

여러분이 케이크를 하나 구매했고 이를 집에 가져왔습니다. 그리고 엄마, 아빠, 나, 동생이 공평하게 한 조각씩 잘라 맛있게 먹습니다. 동생은 다이어트 중이라 조금만 먹어도 된다고 하네요. 각자 자신에게 배분받은 케이크 조각을 먹고 다른 사람의 케이크는 탐내지 않았습니다. 자신의 것을 다 먹고 다른 사람 것을 탐내면 싸움이 나겠죠?

 

Subnet도 이와 동일합니다. VPC 내에서 다시 크기를 쪼개서 알맞게 사용하게 되는데 VPC를 쪼갠 조각들을 Subnet이라고 합니다. 그리고 하나의 Subnet은 하나의 AZ(Availability Zone)에 할당됩니다. 서울 Region의 경우 AZ가 3개인데, 각기 다른 AZ를 가진 서브넷을 최소 3개 이상 만들 수 있다는 뜻이 됩니다. 아래 그림을 보시면 AZ에 상응하는 Subnet의 존재를 확인하실 수 있습니다.

 

좌측은 Region과 AZ만을 표현한 것이고 우측은 VPC(Region)과 Subnet(AZ)까지 표현한 것입니다.

<Availability Zone(좌측)과 Subnet 추가된 Availability Zone(우측)>

예시로 다시 돌아와 VPC(케이크)를 Subnet(케이크 조각)으로 나눕니다. EC2가 탑재되는 Subnet인 10.0.1.0/24와 10.0.2.0/24은 EC2 다수를 탑재해야하니 다수의 사설 IP 필요하므로 Subnet을 크게 나눕니다. Subnet으로 정해진 네트워크는 다른 네트워크의 IP를 포함하지 않습니다. 10.0.3.0/25과 10.0.4.0/26은 RDS와 같은 소수의 서비스를 탑재하므로 많이 필요하지 않습니다.

VPC(케이크) : 10.0.0.0/16

Subnet(케이크 조각) : 10.0.1.0/24(아빠), 10.0.2.0/24(엄마), 10.0.3.0/25(나), 10.0.4.0/26(동생)

-VPC와 Subnet의 예시-

 

또한 각 서브넷은 동일한 네트워크 내에서 통신시 Routing Table을 필요로 하지 않습니다. 그리고 AWS가 관리용으로 사용하는 IP도 존재합니다.  아래에 서술한 IP들은 AWS의 관리 IP로서 사용자가 사용할 수 없는 AWS의 예약 주소입니다.

10.0.1.0: 네트워크 주소. (Network ID)
10.0.1.1: AWS에서 VPC 라우터용으로 예약한 주소(Default Gateway).
10.0.1.2: AWS에서 예약한 주소 DNS 서버의 IP 주소는 기본 VPC 네트워크 범위에 2를 더한 주소입니다. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치합니다.
10.0.1.3: AWS에서 앞으로 사용하려고 예약한 주소.
10.0.1.255: 네트워크 브로드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않으므로, 이 주소를 예약합니다.

출처 : AWS VPC 설명서

 

위 설명을 토대로 VPC와 Sunbet을 생성하면 다음과 같습니다. 차례로 VPC와 Subnet입니다. VPC는 10.0.0.0/16이며 Subnet은 각각 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/25, 10.0.4.0/25입니다.

 

<VPC의 예시>

 

<Subnet의 예시>

이것을 VPC 이미지로 다시 표현하면 다음과 같습니다. VPC와 VPC 내 존재하는 4개의 Subnet을 확인할 수 있습니다.

<Cake VPC, Subnet의 구성도>

VPC와 Subnet에 대한 설명을 마쳤습니다! 다음 문서에서는 Routing Table과 Internet Gateway는 다음 문서에서 알아보도록 하겠습니다.

반응형

댓글