[AWS] VPC(Virtual Private Cloud)란 무엇일까?

AWS VPC(Virtual Private Cloud)란 무엇일까?

이번 글에서는 AWS VPC에 대해서 정리해보겠습니다. Amazon VPC 서비스는 EC2의 네트워크 계층이며, EC2 인스턴스를 비롯한 여러 AWS 서비스에 네트워크 리소스를 담을 수 있는 가상 네트워크입니다.

 

글로만 보면 정확하게 이해가 되지 않습니다. 그래서 만약 EC2 인스턴스들을 VPC를 적용하지 않고 서비스를 한다고 가정해보겠습니다.

VPC를 사용하지 않고 여러 EC2 인스턴스를 사용하면 위와 같은 상황일 것입니다. 뭔가 그림으로만 봐도 복잡해보이고 서로 거미줄처럼 엉켜있는 듯한 느낌을 받을 수 있을 것입니다.

 

지금은 6개 정도의 인스턴스여서 그렇지 나중에 인스턴스가 엄청나게 많아지면 정말 관리하기 쉽지 않을 것이고 하나의 인스턴스 정보를 수정했다가 전체 네트워크 환경에 영향을 미치는 엄청난 일이 발생할 수도 있을 것입니다. 그래서 현재 AWS에서는 VPC를 적용을 필수로 해야 합니다.

 

위의 그림은 VPC를 적용한 그림입니다. 한 눈에 보아도 VPC를 적용하지 않은 것보다 깔끔하고 관리하기 수월해보입니다. 즉, VPC를 적용하면 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있습니다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동하게 됩니다.

 

현재 AWS VPC는 필수이기 때문에 위와 같이 Default VPC가 설정되어 있습니다. 정말 그런지 EC2와 RDS 인스턴스를 만들 때 확인해보겠습니다.

 

 

 

위와 같이 EC2, RDS 인스턴스를 만들 때 Default로 VPC 설정이 되어 있는 것을 볼 수 있습니다. 지금까지 EC2, RDS를 만들 때 VPC를 생각하지 않고 만들었어도 default VPC로 설정되어 있는 것을 사용했던 것입니다.

 

 

 

Default VPC는 어떤 것일까요?

 

Default VPC를 들어가보면 위와 같이 설정이 되어 있는 것을 볼 수 있습니다.

• IPv4 CIDR
• 라우팅 테이블
• 네트워크-ACL
• 서브넷
• 인터넷 게이트웨이
• 보안 그룹

 

많은 VPC 설정들이 있지만 이번 글에서는 위의 내용들에 대해서 집중적으로 정리를 할 것입니다. 가장 먼저 IPv4 CIDR에 대해서 알아보겠습니다.

 

 

 

IPv4 CIDR 블록

기존 네트워크와 마찬가지로 VPC는 하나 이상의 연속적 IP 주소 범위로 구성되며, CIDR(Classless Inter Domain Routing) 블록으로 표시합니다. VPC 내 인스턴스를 비롯한 리소스에 할당되는 IP 주소는 CIDR 블록으로 결정됩니다.

 

CIDR 블록은 IP의 범위를 지정하는 방식입니다. CIDR 블록은 IP 주소와 슬래시(/) 뒤에 따라오는 넷마스크 숫자로 구성되어있습니다.

이 숫자는 IP 범위를 나타냅니다. 이 숫자가 32이면 앞에 기술된 IP 정확히 하나를 가리킵니다. 예를 들어 192.168.0.0/32는 192.168.0.0을 가리킵니다. (IP 주소는 32비트인데 32비트를 모두 네트워크 ID로 할당했기 때문)

범위는 지정된 IP부터 2^(32-n)개가 됩니다. 예를 들어 뒤의 숫자가 24라면, 2^(32-24)=256개의 IP 주소를 의미합니다. 예를 들어 192.168.0.0/24는 192.168.0.0에서 192.168.1.255까지의 IP를 의미합니다.

• CIDR를 정확하게 이해하기 위해서는 IP 주소의 2진수 표기와 서브넷 마스크와 같은 개념을 알아야합니다.
• 즉, 넷마스크 숫자와 IP 주소 수는 반비례합니다. (넷마스크 숫자가 클수록 네트워크 ID는 커지고 호스틑 ID는 줄어들기 때문입니다.)
• VPC CIDR 접두사 길이는 /16부터 /28 까지 입니다.

 

 

VPC를 만들 때 고려해야 할 점

IP는 Internet Protocol 버전 4 또는 IPv4의 축악어로 유효한 넷마스크 숫자는 /0 ~ /32 입니다. 어떠한 유효 IP 범위로 VPC CIDR을 지정할 수 있지만, 퍼플릭 인터넷 주소와 충돌을 피하려면 RFC 1918 범위에서 사용하는 것이 좋습니다.(즉, 공인 IP가 아닌 사설 IP를 사용해야 한다는 뜻입니다.)

그림을 보면서 이해해보겠습니다. 예를 들어 3.36.208.0/16을 CIDR 블록으로 지정한 경우를 생각해보겠습니다. 이 VPC에서 3.36.208.0/16로 접속하는 트래픽은 VPC 내부로 라우트 됩니다. 그런데 이 범위의 IP는 인터넷에서 사용할 수 있는 IP입니다.
그래서 그림에서 보는 것처럼 인터넷 IP와 VPC IP가 같은 것을 볼 수 있습니다. 이런 경우는 어떻게 될까요?

VPC에서는 3.36.208.0/16에 속한 인터넷 IP에 접근하는 것이 원천적으로 불가능합니다. 따라서 인터넷 연결이 필요한 경우 반드시 사설망 대역을 사용해야 하며, 인터넷 연결이 필요하지 않더라도 가능하면 사설망 대역을 사용하는 것을 권장합니다.

 

정리하면 아래와 같습니다.

• VPC를 온프레미스 네트워크나 다른 VPC 등 다른 네트워크에 연결하려면 사용할 VPC CIDR이 다른 네트워크에서 이미 사용하는 주소와 중복되지 않도록 해야합니다.
• VPC CIDR은 사설망 대역을 사용하는 것을 권장합니다.
• 기본 CIDR 블록은 변경할 수 없으므로 VPC를 만들기 전에 주소 요구 사항을 신중히 검토해야 합니다.

 

 

VPC에서 사용하는 사설망 대역

• 10.0.0.0 - 10/255.255.255(10.0.0.0/8)
• 172.16.0.0 - 172.31.255.255(172.16.0.0/12)
• 192.168.0.0 - 192.168.255.255(192.168.0.0/16)

 

VPC는 독립된 네트워크 환경으로 구성되기 때문에 CIDR이 같거나 겹치더라도 생성하는 것이 가능합니다. 하지만 추후에 다수의 VPC를 함께 사용하는 경우 IP 대역이 겹치면 문제가 발생할 수 있습니다. VPC를 만드는 것은 쉽습니다만 한 번 만들고 나면 기존 CIDR을 변경하는 것은 불가능합니다.

 

문제가 생겨서 VPC 내부의 모든 자원을 이동하는 건 쉽지 않습니다. 따라서 프로덕션 환경을 구축할 때는 VPC 제약사항들을 충분히 이해하고 CIDR을 정하는 것이 좋습니다.

 

 

 

서브넷(subnet) 이란?

서브넷은 VPC 내 논리 컨테이너로서 EC2 인스턴스를 배치하는 장소입니다. 또한 서브넷을 통해 인스턴스를 서로 격리합니다. 즉, 서브넷은 기존 네트워크의 가장 LAN의 개념과 유사합니다.

 

인스턴스는 서브넷 안에 있어야 합니다. 그리고 알아두어야 할 점은 한번 서브넷에 인스턴스를 생성하면 다른 서브넷으로 옮길 수 없지만, 인스턴스를 종료하고 다른 서브넷에 새 인스턴스로 만들 수는 있습니다. 즉, 한 VPC에서 다른 VPC로 옮길 수 없다는 의미입니다.

 

 

참고로 EC2를 만들 때 위와 같이 해당 인스턴스는 어떤 서브넷으로 할당할 지도 정할 수 있습니다.

 

 

 

서브넷 CIDR 블록

서브넷의 CIDR은 VPC CIDR의 일부이면서, VPC 내에서 고유해야 합니다. 예를들어 VPC CIDR이 172.16.0.0/16 일 때 서브넷의 CIDR은 172.16.100.0/24가 될 수 있습니다.

 

이렇게 되면 서브넷의 CIDR이 /24 이므로 172.16.100.0 - 172.16.100.255로 IP 주소는 256개를 확보할 수 있습니다. AWS에서 모든 서브넷에서 처음 4개 IP 주소와 마지막 IP 주소를 예약하며 이 주소는 인스턴스에 할당할 수 없습니다. 서브넷 CIDR이 172.16.100.2/24 라면 아래의 주소가 예약됩니다.

• 172.16.100.0 - 172.16.100.3
• 192.16.100.255

 

서브넷의 CIDR 접두사의 길이 제한은 VPC CIDR과 같으며, 한 VPC 내에서 서브넷 CIDR 블록들은 겹칠 수 없고 서브넷에 CIDR을 할당하고 나면 변경할 수도 없습니다.

실제로 Default VPC에는 위와 같이 Default 서브넷이 적용되어 있는 것을 볼 수 있습니다.

 

 

 

가용 영역

서브넷은 하나의 가용 영역 내에서만 존재할 수 있습니다. 가용 영역은 상대적으로 작은 지리적 위치, 데이터 센터 등과 비슷한 개념입니다. AWS 리전의 가용 영역들은 서로 private 하게 연결되어 있으며, 한 가용 영역에 장애가 발생하더라도 다른 영역에 장애의 영향이 미치지 않도록 설계되어 있습니다.

 

즉, 서로 다른 가용 영역에 서브넷을 하나씩 만든 다음 인스턴스를 각각 서브넷에 분산해서 만들면, 애플리케이션은 복원성을 확보할 수 있습니다.

위와 같이 VPC 내부에 서로 다른 가용 영역 안에 만들어 주는 것이 좋습니다. 위의 예시처럼 서브넷 A(가용영역 us-east-1a)에서 장애가 발생하더라도 서브넷 B(가용영역 us-east-1b)에 영향을 미치지 않기 때문입니다.

 

 

현재 저는 위의 가용 영역을 사용할 수 있습니다.

 

 

라우팅 테이블

네트워크 요청이 발생하면 데이터는 우선 라우터로 향하게됩니다. 서브넷에서 네트워크를 이용할 때는 이 라우팅 테이블을 사용해서 목적지를 찾게 됩니다. 라우트 테이블은 서브넷과 연결되어있지만 VPC를 생성할 때 만들어지고 VPC에도 연결되어 있습니다.

하나의 라우트 테이블은 VPC에 속한 다수의 서브넷에서 사용할 수 있습니다. 서브넷 A의 라우팅 테이블은 172.31.0.0/16 즉 VPC안의 네트워크 범위를 갖는 네트워크 요청은 로컬에서 찾도록 되어있습니다.

현재 제가 EC2 인스턴스를 이미 만들어놓았기 때문에 라우팅 테이블에는 위와 같이 2가지가 설정되어 있는 것을 알 수 있습니다.

• 172.31.0.0/16: VPC Default CIDR (대상이 Local인 것을 볼 수 있습니다. 즉, VPC 내부에서 사용하는 IP 입니다.)
• 0.0.0.0./0: 인터넷상의 모든 호스트 IP 주소를 허용한다는 뜻입니다.

 

하지만 이것으로는 외부로 통하는 트래픽을 처리할 수 없습니다. 외부와 네트워크 연결을 하기 위해서는 인터넷 게이트웨이를 사용합니다.

 

 

인터넷 게이트웨이

인터넷 게이트웨이는 퍼블릭 IP 주소를 할당받은 인스턴스가 인터넷과 연결되어서 인터넷으로부터 요청을 수신하는 기능을 제공합니다.

VPC에는 하나의 인터넷 게이트웨이만 연결할 수 있습니다. 라우팅 테이블에 인터넷 게이트웨이를 향하는 적절한 규칙을 추가해주면 특정 서브넷이 인터넷과 연결됩니다. 하지만 서브넷과 인터넷 게이트웨이를 연결하는 것만으로는 인터넷을 사용할 수 없습니다. 인터넷을 사용하고자 하는 리소스는 퍼블릭 IP를 가지고 있어야합니다.(EC2와 EIP 연결을 통해 Public IP가 있으면 됩니다.)

 

또한 위의 서브넷을 보면 프리이빗 서브넷, 퍼블릿 서브넷이 존재합니다.

• 프리이빗 서브넷: VPC 내부에서만 사용하기 위한 서브넷입니다. 따라서 라우팅 테이블에도 로컬 CIDR만 등록되어 있습니다.
• 퍼블릿 서브넷: VPC 내부와 외부 인터넷과 연결하기 위한 서브넷입니다. 따라서 라우팅 테이블에 로컬, 외부 CIDR이 등록되어 있습니다.

 

 

네트워크 ACL과 보안 그룹

네트워크 ACL은 인바운드, 아웃바운드 트래픽을 제어하는 가상 방화벽입니다. 서브넷단위로 적용되며 리소스별로는 설정할 수 없습니다. 하나의 네트워크 ACL은 다수의 서브넷에서 재사용할 수 있습니다. 시큐리티 그룹은 EC2 인스턴스의 트래픽을 제어하는 가상 방화벽인 반면, 네트워크 ACL은 서브넷의 트래픽을 제어하는 방화벽 역할을 합니다. 따라서 네트워크 ACL의 규칙을 통과하더라도 시큐리티 그룹의 규칙을 통과하지 못 하면 인스턴스와는 통신하지 못 할 수 있습니다.

 

현재 저의 EC2 보안그룹을 보면 위와 같이 설정되어 있습니다. 즉, 해당 EC2에 접속을 하려면 보안그룹에서 열어놓은 포트만 접근할 수 있다는 뜻입니다.

 

 

 

반면 네트워크 ACL에서의 디폴트 설정은 위와 같이 모두 열려있습니다. 한마디로 위의 상황들로 요약하면 서브넷에 들어올 때는 네트워크 ACL의 영향을 받아 모든 포트가 열려있고, 서브넷 안에 EC2에 들어올 때는 보안 그룹에서 열려있는 포트로만 들어올 수 있습니다.

• 네트워크 ACL: 서브넷의 방화벽
• 보안그룹: EC2 인스턴스의 방화벽

 

 

Reference

• https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098
• https://www.44bits.io/ko/post/understanding_aws_vpc