🏝️ VPC란?

VPC(Virtual Private Cloud)의 정의는 가상의 네트워크 공간(컴퓨터들끼리 서로 통신하는 공간)이다. VPC를 사용하는 이유를 한 단어로 줄이면 “보안” 때문이다. VPC를 활용하면 외부에서 직접 접근할 수 없는 독립적인 네트워크 환경을 구성할 수 있어서, 보안적으로 안전하게 리소스(EC2, RDS 등)를 사용할 수 있다.

예를 들어, EC2 인스턴스 2대가 있다고 가정하자. 그런데 1대의 인스턴스는 인터넷에 자유롭게 접근하면서 사용하고 싶고, 나머지 1대는 좀 더 안전하고 비공개로 사용하고 싶을 수 있다. 이럴 때 VPC를 활용하면 된다.

VPC를 더 쉽게 이해하자면, 아래 그림과 같이 격자가 그려진 섬이라고 생각하면 된다.

섬의 각 구역에는 그 구역만의 주소(IP 주소)가 존재하고 VPC 안에는 여러 개의 IP 주소를 할당할 수 있다. 이후에 AWS에서 EC2를 생성하든, RDS를 생성하든, ELB를 생성하든 이 VPC 안에 아래와 같이 배치하는 것이다.

 

📝 CIDR 표기법

VPC의 크기를 정할 때는 IP 주소의 범위로 정한다. 위의 그림같이 크기로 정하려면 VPC의 IP 주소 범위를 10.10.0.0 ~ 10.10.0.31로 잡겠다고 설정하면 된다. 정확히 말하자면, 설정할 때 10.10.0.0/27의 범위로 VPC를 만들어야 한다.

이러한 표기법을 CIDR 표기 방식이라고 하는데, 특정 IP 주소의 범위를 나타내는 표기 방식이다. 실제 AWS에서 VPC를 만들 때는 CIDR 표기 방식을 활용해 입력해야 한다.

알다시피 IP 주소는 4개의 숫자로 구성되어 있고, 각 숫자는 0 ~ 255 범위의 값을 가진다.

ex) 127.23.150.11, 15.0.255.1

 

CIDR 표기법으로 표기된 값을 해석하는 방법은 아래 절차대로 진행하면 된다.

1. 10진수를 2진수로 바꾼다.
2. CIDR 슬래시 뒤에 있는 숫자를 활용해 2진수를 자른다.
3. 잘린 2진수의 왼쪽 값은 그대로 고정시키고, 잘린 2진수의 오른쪽 값에서 표현할 수 있는 최솟값과 최댓값을 구한다.
4. 2진수로 표현된 최솟값과 최대값을 10진수로 변환한다.

 

예를 들어, CIDR 표기법으로 표기된 13.25.82.0/24라는 값이 있다고 해보자.

1. 10진수로 표현된 각 숫자들을 2진수로 바꾼다.
   • 00001101.00011001.01010010.00000000
2. CIDR 슬래시 뒤에 있는 숫자를 활용해 2진수를 자른다.
   • 00001101.00011001.01010010 / 00000000
3. 잘린 2진수의 왼쪽 값은 그대로 고정시키고, 잘린 2진수의 오른쪽 값에서 표현할 수 있는 최솟값과 최댓값을 구한다.
   • 최소값 : 00001101.00011001.01010010 / 00000000
   • 최대값 : 00001101.00011001.01010010 / 11111111
4. 2진수로 표현된 최솟값과 최대값을 10진수로 변환한다.
   • 최솟값 : 13.25.82.0
   • 최댓값 : 13.25.82.255

즉, CIDR로 표기된 13.25.82.0/24의 IP 주소 범위는 13.25.82.0 ~ 13.25.82.255이라는 의미다. 이 과정을 이해하고 스스로 알아낼 수 있어야 한다.

 

🆚 Public IP vs Private IP

Public IP(공인 IP)란 외부 인터넷에서 접근할 수 있는 공식적인 주소를 말한다. 네이버에 “내 컴퓨터 ip 주소 확인” 이라고 검색하면 바로 확인할 수 있다.

반면, Private IP(사설 IP)는 외부 인터넷과 직접 연결되지 않고, 내부 네트워크에서만 사용되는 주소를 뜻한다. Private IP의 특징은 동일한 네트워크 환경에서만 서로 통신할 수 있다는 것이다. 여기서 "동일한 네트워크” 라는 뜻은 같은 공유기(와이파이)를 사용하고 있는 경우, 혹은 같은 VPC인 경우라고 생각하면 된다.

전세계에 딱 하나뿐인 Public IP와는 다르게 Private IP는 네트워크 환경마다 독립적으로 사설 IP를 사용할 수 있다. 한 마디로 사설 IP는 각자의 네트워크 환경에서만 사용하는 IP이다. 예를 들어, A라는 네트워크 환경에서 10.0.0.0이라는 사설 IP를 쓰고 있다고 하더라도, B라는 네트워크 환경 에서도 10.0.0.0을 별개로 사용할 수 있다는 말이다.

Private IP의 범위는 IETF라는 국제 인터넷 표준화 기구에서 아래와 같이 정해놓았다.

위의 3가지 범위에 속한 IP 주소로 통신하면 컴퓨터들은 무조건 Private IP로 인식한다.

실습을 진행해보자. EC2 하나를 생성하고 Nginx를 설치해준다. 그리고 EC2가 가지고 있는 Public IP에 접속하면 Nginx가 정상적으로 동작하는 것을 확인할 수 있다.

이렇게 Public IP 주소로 응답이 잘 날라왔다는 것은 Public IP 주소를 활용해서 Nginx가 실행되고 있는 컴퓨터 인스턴스에 접근할 수 있다는 의미다.

 

이번엔 Private IP 주소로 요청을 보내보자. 어떻게 될까?

보다시피 아무런 반응이 없다. 아까 말했듯이 Private IP는 동일한 네트워크 환경에서만 통신할 수 있는 주소라고 했다. 하지만 지금은 내 로컬 컴퓨터의 네트워크 환경과 AWS의 VPC에서 실행되고 있는 EC2 인스턴스의 네트워크 환경이 서로 다르기 때문에 접속되지 않는 것이다. 그럼 네트워크 환경을 동일하게 맞춰주면 되는거 아닌가? 한번 실험해보자.

먼저 Nginx가 실행되고 있는 EC2가 어떤 VPC(현재는 기본값)를 쓰고 있는지 확인해야 한다.

확인 후, 동일한 VPC(기본값)을 사용하도록 하고 보안 규칙을 추가 후 인스턴스를 생성해보자.

현재 같은 VPC를 사용 중인 인스턴스 2대가 있는 상황이다.

이제 새로 만든 web-server2에서 Nginx가 실행되고 있는 web-server에 Private IP로 통신을 시도해보자.

보다시피 동일한 VPC를 사용하고 있기 때문에 Private IP로 요청을 보내도 정상적으로 응답 받을 수 있는 것을 확인할 수 있다.

이번에는 VPC를 직접 생성해보도록 하자.

IP 주소의 범위는 CIDR 표기법으로 10.0.0.0/16으로 설정했다. 이렇게 설정한 이유는 IP 범위를 정할 때 Private IP 범위에 포함되어야 하기 때문이다. 이제 이렇게 직접 설정해서 생성한 VPC에 EC2 인스턴스를 생성해서 배치해보자.

근데 EC2를 생성하려고 보니까 서브넷을 찾을 수 없다는 문구가 나온다. 서브넷에 대해 알아보도록 하자.

 

🗃️ Subnet이란?

서브넷(Subnet)은 하나의 큰 네트워크를 작은 네트워크 단위로 쪼갠 것을 말한다. 하나의 VPC는 여러 개의 서브넷으로 나뉘어진다. 위에서 접한 그림에서 서브넷을 표현해보자면 아래와 같이 표현할 수 있다.

이렇게 여러 서브넷으로 쪼개는 특별한 이유가 뭘까? 바로 “용도에 따라 네트워크를 분리해서 사용하고 싶기 때문” 이다. 예를 들어, 하나의 VPC에서 데이터베이스끼리만 모아놓은 네트워크와 백엔드 서버끼리만 모아놓은 네트워크를 분리해서 관리하고 싶을 수 있다. 이럴 때 서브넷을 활용하는 것이다.

근데 한 가지 중요한 궁금증이 있다.

“서브넷을 어떤 기준으로 나눠야 하는거지?”

이때 가장 많이 활용하는 기준이 외부에서 접근 가능한 네트워크(Public Subnet)로 할지, 외부에서 접근이 불가능한 네트워크(Private Subnet)로 할지다. 위에서 생성해놓은 VPC의 서브넷을 만들어보자.

👌🏻 Public Subnet 생성

🚫 Private Subnet 생성

이제 EC2를 하나 생성해서 외부에서 접근 가능하도록 기존에 만들어놓은 VPC의 Public Subnet에 배치해놓자. HTTP 80번 포트에 대해 모든 IP에서 접속 가능하도록 설정했다.

그리고 EC2를 연결하려고 했는데…

인스턴스가 Public Subnet에 없다는 문구와 함께 서브넷을 Public Subnet으로 만들기 위해서는 서브넷 라우팅 테이블의 경로를 인터넷 게이트웨이에 추가해야 한다고 되어 있다. 분명히 Public Subnet으로 설정해줬는데 이게 어떻게 된 일일까?

우려한대로 접속이 되지 않는다. 접속이 안 되는 이유는 VPC의 외부 인터넷과 소통할 수 있는 출입구를 세팅해주지 않았기 때문이다. 이 출입구가 바로 인터넷 게이트웨이(Internet Gateway)다. 출입구를 VPC에 달아주도록 하자.

 

🚪Internet Gateway란?

인터넷 게이트웨이(Internet Gateway)란 VPC와 외부 인터넷 간에 통신할 수 있게 해주는 장치를 뜻한다.

이제 인터넷 게이트웨이를 직접 만들고 VPC에 달아주도록 하자.

근데 외부 인터넷과 VPC 내부에 있는 EC2 인스턴스랑 통신이 되게 하기 위해서는 한 가지 더 세팅을 해야 한다. 바로 라우팅 테이블(Routing Table)이다.

 

🔀 Routing Table이란?

라우팅 테이블(Routing Table)은 트래픽을 어디로 전송해야 하는 지 경로를 알려주는 테이블을 의미한다. 왜 필요할까?

아래 그림을 보자.

VPC 내부에 EC2 인스턴스가 있고, 이 인스턴스가 VPC 외부에 있는 특정 컴퓨터와 통신을 하고 싶다고 가정해보자. 그럼 EC2 인스턴스 입장에서는 외부 인터넷에 있는 컴퓨터와 통신을 하기 위해 인터넷 게이트웨이를 거쳐가야 하는데 문제는 인터넷 게이트웨이로 가는 방법 자체를 모른다는 것이다.

즉, EC2 인스턴스가 특정 컴퓨터로 통신을 보내려고 해도 어떤 방향으로 트래픽을 보내야 하는 지 모른다는 뜻이다. 그래서 EC2 인스턴스가 어떤 경로로 트래픽을 전송해야 되는 지 라우팅 테이블을 통해 알려줘야 하는 것이다.

라우팅 테이블을 만들고, Public Subnet만 연결해놓도록 하자. 그리고 라우팅 편집에서 몇 가지 설정을 해야 하는데,

첫 번째 설정은 VPC 내부에서 10.0.0.0/16으로 보내는 트래픽은 local로 보내라는 뜻이다. 여기서 local로 보낸다는 것은 Private IP를 활용해서 네트워크 내부에서만 통신하라는 의미다.

바로 아래 설정에서 0.0.0.0/0은 모든 IPv4 주소를 의미하는데, VPC 내부에서 모든 IPv4 주소로 보내는 트래픽은 인터넷 게이트웨이로 보내라는 의미다.

근데 뭔가 모순적이지 않나? 만약 10.0.0.5 같은 주소로 보내려면 어떻게 되는걸까? local로 보내야 할까, 인터넷 게이트웨이로 보내야 할까? 다행스럽게도 AWS 공식문서에 이에 대해 IP 주소 범위가 더 구체적인 조건을 우선 적용한다고 나와 있다. 즉, 10.0.0.5 트래픽은 local로 보내게 되는 것이다.

여기까지 설정을 마치고, EC2에 접속해보면 정상적으로 접속되는 것을 볼 수 있다.