AWS VPC 기본 개념 정리 - VPC를 구성하는 기본 원리

선수 지식

VPC를 이해하기 위해서 선수 지식이 좀 필요한데 아주 간단하게만 보고 가겠습니다.

 

IP주소는 32자리 2진수인데 총 개수는약 40억개정도 됩니다. 그리고 (네트워크 주소 + 호스트 주소) 로 구성이 됩니다. 네트워크 주소는 아파트 주소, 호스트 주소는 호수로 이해하면 알기 쉽습니다. 정확한 주소로 찾아가려면 일단 아파트 주소로 가서 구체적인 호수를 찾아야겠죠.

 

출처) http://korean-daeddo.blogspot.com/2015/12/ip.html

IP 주소를 8비트로 4등분을 한다면 각각을 옥탯이라 부릅니다. 각 옥탯별로 0~255개의 범위이므로 총 256개가 들어간다는걸 알 수 있습니다. 그리고 이 옥탯 별로 IP의 클래스를 A,B,C로 나눌 수 있습니다.

 

위에서 언급한 A 클래스는 Octet1이 네트워크 아이디입니다. 그리고 나머지 옥탯들을 호스트의 아이디로 사용합니다. B 클래스는 Octet2 까지를 네트워크 아이디로 사용합니다. 그리고 C 클래스는 Octet3까지 사용합니다.

결과적으로 A 클래스는 네트워크 아이디 하나당 1677만여개의 아이피를 가질 수 있습니다. B 클래스는 6만5천여개를 가질 수 있고 C 클래스는 256개를 가집니다. C를 쓰기엔 적고 B를 쓰기엔 많은 경우가 생겼기 때문에 이 클래스별로 아이피를 할당하는 방법은 예전에 없어졌습니다.

 

그 이후 문제를 해결하기 위해 서브넷 마스크를 사용하였는데 마스크라는 단어처럼 아이피주소를 가리는 역할을 합니다. A 클래스는 이 CIDR 블록에서 /8에 해당합니다. B 클래스는 /16 , C 클래스는 /24 에 해당합니다.

CIDR (사이더)

CIDR은 급격히 부족해지는 IPv4 주소를 보다 효율적으로 사용하게 합니다. 표현형식은 xxx.xxx.xxx.xxx/yy 형태로 표시를 하게 됩니다. 맨 뒤의 yy는 서브넷 마스크를 2진수로 바꾸었을 때 1의 개수입니다. 위에서 언급했듯이 기본적으로 C 클래스는 24개의 1로 아이피를 가려버립니다. 가린 이후의 자릿수부터 사용할 수 있게 됩니다.

 

예를들어, 255.255.255.0을 2진수로 바꾸면 11111111.11111111.11111111.00000000 이 되는데 1이 24개이므로 CIDR 표기법으로 xxx.xxx.xxx.xxx/24 가 됩니다. (참고로 서브넷 마스크는 1이 연속되어 나와야 합니다)

192.168.0.0/24 라면 192.168.0.1 부터 192.168.0.254 까지입니다. 192.168.0.0은 네트워크이고 192.168.0.255는 브로드캐스트라 제외입니다. (자세한 내용은 네트워크 개념 검색을 통해 보면 됩니다)

 

이제 VPC에 대해서 알아볼까요.

Amazon VPC의 작동방식

VPC는 사용자 AWS 계정 전용 가상 네트워크 입니다. VPC의 IP 범위 주소는 서브넷입니다. 이 둘은 CIDR 표기법을 따릅니다.

기본 VPC 구성 요소 단계

• IPv4 CIDR /16 블록에 해당하는 VPC를 만듭니다 (172.31.0.0/16) 요런식으로 만들면 65536개의 프라이빗 IPv4 주소를 제공받게 됩니다.
• 각 가용영역에 크기 /20의 기본 서브넷을 설정합니다.
• 인터넷 게이트웨이를 만들어 기본 VPC에 연결합니다.
• 네트워크 엑세스제어목록 (ACL)을 생성하여 기본 VPC에 연결합니다.
• AWS 계정에서 설정된 기본 DHCP 옵션을 기본 VPC에 연결합니다.

공식문서에서 제공하는 가이드인데요. 정말 먼 소린지 5번을 읽어도 먼 소린지 몰랐어요. 왜냐면 용어를 모르기 때문이죠. 각 단계를 조금 더 자세히 살펴볼게요.

VPC 만들기

첫 번째 항목에서 VPC를 만드는데 왜 저런 아이피를 사용했을까요. 바로 인터넷의 연결여부 때문입니다. RFC1918 규약에 따르면 사설망은 다음과 같은 대역을 사용하라고 합니다.

 

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

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

 

저렇게 사설 대역을 약속을 해놓는다면 사설 아이피에서 인터넷 연결가능한 아이피 대역으로 설정하여 문제가 생기는 일을 방지할 수 있기 때문입니다. 예를들어 140.x.x.x 의 아이피를 사설로 만든다고 칩시다. 저 아이피는 실제로 인터넷에서 사용할 수 있는 아이피입니다. 사설망내부에서 인터넷 연결을 하지 않고 저 아이피를 사용할 수는 있지만 공통의 규약을 따르는게 헷갈림과 문제를 방지할 수 있습니다.

가용영역

두 번째 항목에서 가용영역을 설정하라고 합니다. AWS 는 세계각지에서 호스팅이 되고 있습니다. 각 지역을 리전이라고 부릅니다. 이 리전안에서 가용영역이라는 격리된 위치가 여러 개 있습니다. 그렇기 때문에 각 리전에서도 한쪽 가용영역이 문제가 생겼을 때 다른한쪽의 도움을 받을 수 있는 구조입니다. ELB (로드밸런서) 를 붙여서 각 가용역역으로 트래픽을 분배해 줄 수 도 있습니다.

인터넷 게이트웨이

세 번째 항목에서 인터넷 게이트웨이가 나옵니다. 인터넷 게이트웨이는 VPC의 인스턴스와 인터넷간에 통신을 할 수 있게 해줍니다. 인터넷으로 데이터를 보내야한다면 당연히 인터넷 게이트웨이로 트래픽을 전달해야 합니다.

그러러면 이 라우팅을 서브넷의 라우팅 테이블에 추가를 해야 합니다. 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 경우 퍼블릭 서브넷이라고 부릅니다. 반대로 어떤 서브넷이 인터넷 연결을 할 필요가 없다면 이 서브넷은 프라이빗 서브넷이라고 합니다.

 

이 VPC의 서브넷 1은 퍼블릭 서브넷입니다. 10.0.0.6으로 오면 로컬에서 찾겠지만 모든 인터넷 트래픽 0.0.0.0/0 은 인터넷 게이트웨이로 가라고 테이블에 매핑되어있습니다. 그리고 Elastic IP 가 지정되어 있어 인터넷과 통신이 가능합니다. 저 주소를 할당하지 않고 인터넷과 통신을 하려면 NAT 를 사용합니다.

 

NAT를 쓰게되면 프라이빗 서브넷의 인스턴스를 인터넷에 연결을 시킬 수 있지만 인터넷에서 해당 인스턴스로 접근하지 못하게 할 수 있습니다. NAT 게이트웨이를 만드려면 이 게이트웨이가 속할 퍼블릭 서브넷을 만들어야 합니다. 그리고 NAT 게이트웨이와 연결할 Elastic IP도 지정해야 합니다. 그리고 프라이빗 서브넷과 연결된 라우팅 테이블을 NAT 게이트웨이를 바라보게 해야합니다.

 

참고로 여러 가용영역에 NAT 게이트웨이를 하나를 공유하게 되면 NAT 게이트웨이 가용영역이 문제가 생겼을 때 다른쪽도 영향을 받습니다. 이에 따라 가용영역 당 NAT 게이트웨이를 만들어야 합니다.

 

 

그림을 보면 우측 하단의 Main route table이 있습니다. 이이 테이블은 Private Subnet 에서 인터넷 요청이 필요한 경우 (0.0.0.0/0) 모두 nate-gatway-id 즉 NAT 게이트웨이로 보냅니다. 그리고 Elastic IP 가 할당된 NAT는 그 요청을 받아 인터넷 게이트웨이로 보냅니다.

 

참고로 네트워크 ACL을 사용하여 NAT 게이트웨이가 있는 서브넷에서 주고 받는 트래픽을 제어할 수 있습니다.

네트워크 액세스(ACL) 제어목록

네 번째 항목에서 네트워크 액세스(ACL) 제어목록이 나옵니다. ACL은 1개 이상의 서브넷 내부와 외부 트래픽을 제어하기 위한 방화벽 역할을 합니다. EC2에서도 보안그룹(Security Group)을 생성할 수 있듯이 VPC에서도 보안을 생성할 수 있습니다. 그것이 ACL 입니다.

그럼 그 둘이 차이는 간단하게 보자면,

 

보안그룹 (Security Group)

 

• 인스턴스 레벨에서 운영
• 허용 규칙만 지원 (어떤 ip 대역을 허용할지)
• 인스턴스 시작시 지정하거나 보안그룹을 나중에 인스턴스와 연결해야 적용됨

네트워크 ACL

 

• 서브넷 레벨에서 운영

• 허용 규칙과 거부 규칙 지원

• 연결된 서브넷의 모든 인스턴스에 자동 적용

   

 

위 그림과 같이 기본적인 인스턴스 보안그룹 위에 추가적으로 서브넷을 방어하는 네트워크 ACL을 추가구성할 수 있습니다.

조금만 더 자세히 볼까요.

 

 

상단 네모칸은 네트워크 ACL 설정입니다. 이 Rule을 보니 172.31.1.2/32 라는 특정 ip만 제외하고 다른 모든 트래픽은 막아놓았습니다. 즉 저 서브넷은 한 ip만이 접근가능합니다. 아웃바운드 규칙도 보니 그 ip를 제외하고는 트래픽이 나갈수조차 없습니다.

 

이에 반해 인스턴스의 보안그룹 규칙 (하단 네모칸)을 보면 SSH 연결은 그 ip가 허용이 되어있고 모든 트래픽이 허용이 되어있네요. 즉 저 서브넷 안에서 누구와도 통신이 가능한것으로 보이네요. 다시말해 서브넷 내부와 자유롭게 통신을 할 수 있고 외부는 원천차단하는(한 ip제외) 그림입니다.

DHCP

마지막 다섯 번째로 DHCP연결이 나옵니다.

 

DHCP란 Dynamic Host Configuration Protocol 의 약자로 동적 호스트 설정 프로토콜입니다. IP를 필요로 하는 컴퓨터에게 자동으로 할당해주고 사용하지 않으면 반환해서 다른 컴퓨터가 사용할 수 있게 해줍니다.

DHCP가 IP를 할당해주는것을 임대(Lease)라고 합니다. 기본적으로 8일이라고 합니다. 그런데 사람들이 많이있는 지역에서는 8일로 한다면 금방 동나버리기 때문에 2~3시간정도로 한다고 하네요. 그리고 계속 쓰고있는데 반환해버리면 비효율적이기 때문에 갱신(Renewal)을 지원합니다. 임대기간이 50%남았을 때 그리고 87.5%남았을 때 이렇게 두 번씩 시도를 한다고 합니다. 다시말해 IP를 계속 사용중이라면 임대기간을 자동으로 갱신해주고 그렇지않다면 반환하는 것입니다. (출처: 나무위키)

 

AWS에서는 최대 4개의 자체 DNS 서버를 사용할 수 있습니다. 그렇게 하려면 VPC와 함께 사용할 DHCP 옵션을 지정해야 합니다.

domain-name-servers, domain-name, ntp-servers, netbios-name-servers, netbios-note-type 라는걸 지정할 수 있다고하는데 일반적으로 기본값을 그대로 사용합니다. 더 자세한 설정이 필요하다면 공식문서를 참고하세요.

VPC 피어링 (Peering)

피어링 개본 개념

VPC 피어링은 두 VPC 간에 트래픽을 라우팅할 수 있도록 만듭니다. 동일한 네트워크에 속하는 경우, 혹은 다른 리전간의 VPC 에서도 피어링이 가능합니다.

 

 

게이트웨이나 VPN 커넥션과 상관이 없고 Single Point of Failure나 대역폭 병목도 문제없습니다.

AWS 계정이 두 개 이상인 경우 두 계정 리소스간 통신이 필요한 경우 사용할 수 있습니다.

 

• 요청자 VPC가 수락자 VPC에게 피어링 연결을 요청합니다. (요청자 VPC의 CIDR 블럭과 중첩되는 CIDR 블럭은 사용할 수 없습니다)
• 수락자 VPC의 소유자가 피어링 연결을 수락합니다.
• 프라이빗 IP 주소를 사용해서 피어링 하는 경우 각 VPC 소유자가 다른 VPC의 IP 를 가리키는 경로를 하나 이상의 VPC 라우팅 테이블에 수동으로 추가해야 합니다.
• VPC에서 주고받는 트래픽이 제한이 되는경우 인스턴스의 보안그룹(Security Group)을 업데이트합니다.

다음 그림은 피어링 연결 수명주기입니다.

 

처음에 initiating request 로 피어링 연결 요청을 시작합니다. 실패하거나 우측의 pending acceptance 상태로 갑니다. Pending acceptance 상태에서는 보내는 사람이나 받는 사람이 취소할 수 있습니다. 아무런 조치를 취하지않으면 7일 후에 expired 됩니다.

Provisioning은 수락자가 수락한 경우입니다. 잠시 후 Active 액티브 상태가 됩니다. Active 상태에서는 요청자 수락자가 아무나 연결을 끊을 수 있습니다.

참고로 여러 피어링을 연결할 때 한쪽을 거쳐갈 수는 없습니다.

 

다음 그림처럼 B는 A 와 피어링이 되어있는데 그걸이용해서 C와 피어링을 할 수는 없습니다.

 

참고)

https://docs.aws.amazon.com/vpc/index.html

https://ko.wikipedia.org/wiki/사이더_(네트워킹)

http://korean-daeddo.blogspot.com/2015/12/ip.html

https://tools.ietf.org/html/rfc1918

https://namu.wiki/w/DHCP