[AWS] VPC구성하기(퍼블릭 서브넷, 프라이빗 서브넷)

aws를 사용하면서 사실 VPC가 뭔지도 몰랐고 몰라도 사용하는데 문제가 없었다 그때는 그냥 서비스만 이용하느라 핵심만 빠르게 배우기 바빴다 이번에 제대로 다시 공부하려는 마음에 시작하려는데 처음이 VPC... 이 글을 쓰기 전 자료 찾아봐도 이해가 되지 않았다... CIDR인가... 아무튼 aws를 시작할 때 먼저 시작해볼 VPC에 대해 알아보자

VPC가 무엇인가

VPC는 프라이빗 클라우드를 만드는 데 가장 기본이 되는 리소스이다. VPC는 논리적인 독립 네트워크를 로 이름과 IPv4 CIDR 블록을 필수적으로 가지게 된다. CIDR 블록은 IP의 범위를 지정하는 방식인데. CIDR 블록은 IP 주소와 슬래시(/) 뒤에 따라오는 넷마스크 숫자로 구성되어 있다. 이 숫자는 IP 범위를 나타내며 이 숫자가 32이면 앞에 기술된 IP 정확히 하나를 가리키게 된다. 예를 들어 192.168.0.0/32는 192.168.0.0을 가리킨다. 범위는 지정된 IP부터 2^(32-n) 개가 된다. 예를 들어 뒤의 숫자가 24라면, 2^(32-24)=256개의 IP 주소를 의미한다. 예를 들어 192.168.0.0/24는 192.168.0.0에서 192.168.1.255까지의 IP를 의미한다.

 

 

IPv4 VPC CIDR 블록

VPC를 만들 때 VPC의 IPv4 CIDR 블록을 지정해야 하는데 허용된 블록 크기는 /16 넷마스크 (IP 주소 65,536개)~/28 넷마스크(IP 주소 16개)이다. VPC 생성을 마쳤으면 추가 IPv4 CIDR 블록을 VPC에 연결할 수 있다. 자세한 정보는 추가 IPv4 CIDR 블록을 VPC와 연결을 참조하자.

VPC를 생성하는 경우, 다음과 같이 RFC 1918 규격에 따라 프라이빗 IPv4 주소 범위에 속하는 CIDR 블록을 지정하는 것이 좋다.

RFC 1918 범위	CIDR 블록의 예
10.0.0.0 - 10.255.255.255 (10/8 접두사)	10.0.0.0/16
172.16.0.0 - 172.31.255.255 (172.16/12 접두사)	172.31.0.0/16
192.168.0.0 - 192.168.255.255 (192.168/16 접두사)	192.168.0.0/16

RFC 1918에 지정된 프라이빗 IPv4 주소 범위에 속하지 않는 공개적으로 라우팅 가능한 CIDR 블록을 사용하여 VPC를 생성할 수 있다. 하지만 이 설명서에서는 프라이빗 IP 주소는 VPC의 CIDR 범위 내에 있는 프라이빗 IPv4 주소를 말한다.

명령줄 도구 또는 Amazon EC2 API를 사용하여 VPC를 생성하면 CIDR 블록이 표준 형식으로 자동 수정된다. 예를 들어 CIDR 블록에 100.68.0.18/18을 지정하면 100.68.0.0/18의 CIDR 블록이 생성된다.

 

 

서브넷(Subnet)

VPC는 다시 한번 CIDR 블록을 가지는 단위로 나눠진다. 서브넷은 실제로 리소스가 생성되는 물리적인 공간인 가용존 Available Zone과 연결된다. VPC가 논리적인 범위를 의미한다면, 서브넷은 VPC 안에서 실제로 리소스가 생성될 수 있는 네트워크라고 생각할 수 있다. 다른 서비스의 리소스를 생성할 때 VPC만 지정하는 경우는 없다. VPC와 서브넷을 모두 지정하거나 서브넷을 지정하면 VPC는 자동적으로 유추되기도 한다.

하나의 VPC는 N개의 서브넷을 가질 수 있는데 서브넷의 최대 크기는 VPC의 크기와 같다. VPC와 동일한 크기의 서브넷을 하나만 만드는 것도 가능하다. 서브넷을 만들지 않을 수도 있지만, 이 경우 VPC로 아무것도 할 수 없다. 일반적으로 사용할 수 있는 가용존을 고려해서 적절한 크기의 서브넷들을 가용존 수만큼 생성해서 사용한다. N가용존만큼 서브넷을 만들어 리소스를 분산하면 재해 대응 측면에서도 유리하다.

서브넷의 넷마스크 범위는 16(65535개)에서 28(16개)을 사용할 수 있으며, VPC CIDR 블록 범위에 속하는 CIDR 블록을 지정할 수 있다. 하나의 서브넷은 하나의 가용존과 연결된다. 리전에 따라서 사용가능한 가용존의 개수는 다르다. 따라서 재해 대응을 위해 가용존만큼 서브넷을 나누는 경우 특정 리전에서 사용가능한 가용존의 개수를 미리 확인할 필요가 있다. 모든 가용존을 사용하지 않더라도 2개 이상의 가용존을 사용하는 게 일반적이다. 기본 VPC에서는 가용존 개수만큼 넷마스크 20의 서브넷들을 자동적으로 생성한다.

 

 

라우트 테이블(Route Table)

라우트 테이블은 서브넷과 연결되어있는 리소스이다. 서브넷에서 네트워크를 이용할 때는 이 라우트 테이블을 사용해서 목적지를 찾게 되는데 라우트 테이블은 서브넷과 연결되어있지만 VPC를 생성할 때 만들어지고 VPC에도 연결되어 있다. 이 라우트 테이블은 VPC에 속한 서브넷을 만들 때 기본 라우트 테이블로 사용된다.

하나의 라우트 테이블은 VPC에 속한 다수의 서브넷에서 사용할 수 있다. 자동 생성되는 라우트 테이블에는 한 가지 룰만이 정의되어 있다. VPC의 CIDR 블록을 목적지로 하는 경우 타깃이 local인 규칙이다. 예를 들어 VPC의 CIDR 블록이 172.31.0.0/16일 때 이 네트워크 안에서 목적지가 172.31.0.0/16 범위에 있는 리소스를 찾는다면 VPC 내부에서 찾게 된다. 이 규칙은 삭제할 수 없으며 인터넷을 연결하거나 다른 VPC와 통신하기 위해서는 라우트 테이블에 라우트 규칙을 추가적으로 정의해한다.

 

인터넷 게이트웨이(Internet Gateway)

VPC는 기본적으로 격리되 네트워크 환경이다. 따라서 VPC에서 생성된 리소스들은 기본적으로 인터넷을 사용할 수가 없다. 인터넷에 연결하기 위해서는 인터넷 게이트웨이가 필요하다. 라우팅 테이블에 인터넷 게이트웨이를 향하는 적절한 규칙을 추가해주면 특정 서브넷이 인터넷과 연결된다. 하지만 서브넷과 인터넷 게이트웨이를 연결하는 것만으로는 인터넷을 사용할 수 없는데 인터넷을 사용하고자 하는 리소스는 퍼블릭 IP를 가지고 있어야 한다.

 

 

 

VPC구성하기

이 정도 VPC의 기본적인 구성의 개념을 알았다면 직접 VPC를 구성하는 데는 문제없을 거라 생각이 들기 때문에 한번 직접 VPC를 구성해보겠다 아래의 아키텍처는 이번에 구성할 VPC구성이다

먼저 VPC 생성을 위해 이름을 정해주고 CIDR을 할당하는데 VPC를 생성할 때 지정해야 할 값은 4가지가 있는데 필수적으로 입력해야 하는 값은 IPv4 CIDR 블록 하나이다. 이 값을 지정할 때는 특별한 이유가 없다면 반드시 사설망 대역 범위 내에서 지정하면 된다.

사설 IP로 지정된 대역은 위에 설명해놨으니 까먹었다면 다시 위에서 확인해 보자

 

생성하면 내가 만든 VPC가 생성된 걸 확인할 수 있다

서브넷 생성

VPC는 위에서 생성한 VPC에 서브넷을 생성하면 된다 서브넷 IP 대역은 VPC의 IP범위 내에서 설정하면 된다

여기까지 퍼블릭 서브넷을 VPC내부에 구성을 해줬다

확인해보면 사용 가능한 IPv4주소가 있는데 2^(32-24) = 251 이기 때문에 251개의 주소가 사용이 가능하다 

이번에는 프라이빗 서브넷을 만들어주겠다 

여기까지 모든 서브넷을 생성하고 VPC기준으로 필터링을 하게 되면 서브넷이 생성된 걸 확인할 수 있다

지금까지 정리해보면 서울 리전에 VPC minhyeok-VPC를 구성했고 서울 리전에 존재하는 AZ에 

AZ(ap-northeast-2a): my-public-subnet-1 / my-private-subnet-1

AZ(ap-northeast-2c): my-public-subnet-2 / my-private-subnet-2

 

  VPC와 Subnet을 구성할 때는 반드시 CIDR을 설정해야 하는데, 위 VPC 경우에는 10.10.0.0/16으로 생성하였다. Subnet CIDR은 당연히 VPC에 포함되도록 해야 한다. 각 subnet의 CIDR은 아래와 같이 설정해 보았다.

• my-public-subnet-1 : 10.10.1.0/24
• my-public-subnet-2 : 10.10.2.0/24, 
• my-private-subnet-1 : 10.10.101.0/24
• my-private-subnet-2 : 10.10.102.0/24 

 

Public / Private network 존 구분

데이터 센터를 디자인할 때 네트워크단에서 반드시 고려하는 것이 Public / Private network 존을 나누는 것이다.

서비스를 구축할 때 외부와 통신이 직접적으로 필요한 Web 서버 같은 Front-end layer의 경우, Public 존에 위치하도록 한다. 하지만 Back-end나 DB의 경우 외부와의 통신이 직접적으로 필요하지 않으며, 단지 Public 존에 위치한 Front-end 서버와의 통신만 필요로 하는 경우가 많다. 이런 경우에는 외부와의 통신이 제한된 Private 존에 위치하도록 한다. 이는 보안상 부적절한 접근을 네트워크 레벨에서 원천적으로 차단하기 위함이다. 

 public subnet과 private subnet도 각각의 AZ에 분산해서 배포하였다.

 그리고 my-public-subnet-1과 2에는 외부와 통신이 필요한 Web 서버만 배포하도록 정책을 세우고, my-private-subnet-1과 2 에는 외부와 통신이 제한되는 DB 서버만 배포하도록 정책을 세우면 된다. 

이제 실제적으로 my-public-subnet-1과 my-public-subnet-2가 외부와 통신을 하기 위한 추가적인 설정을 해야 한다. 

VPC를 생성하면 기본적으로 외부 통신과 단절된 상태로 생성된다. 또한 모든 network가 private IP로 설정되어 있기 때문에 외부로 통신이 불가한 상태다. 이때 외부로 통신하기 위해 VPC에서는 Internet Gateway라는 기능을 제공한다. 

 

 

Internet Gateway 생성

VPC에서 제공되는 Internet Gateway라는 기능을 이용하면 원하는 Subnet을 외부 통신이 되도록 설정이 가능하다.

먼저 외부 통신을 위한 Internet Gateway (이하 IGW)를 생성한 후, 생성된 IGW를 VPC에 Attach 한다. 참고로 하나의 VPC 에는 하나의 IGW 만 attach 할 수 있다.  그리고 route table을 생성한 후, 외부 통신을 위한 my-public-subnet-1과 2에 route table을 assign 한다.

 

인터넷 게이트웨이를 생성했다면 VPC와 연결해 보자

생성을 했으면 VPC와 연결하기 위해 오른쪽 상단 작업을 눌러서 VPC에 연결을 클릭하자

클릭을 했다면 위에서 만들었던 VPC에 연결해주면 된다

연결을 하고 확인해보면 좀 전에 인터넷 게이트웨이만 만들었을 때는 VPC ID를 할당받지 못했는데 VPC와 연결하니 ID가 할당되어 연결이 잘된 걸 확인할 수 있다 지금까지 VPC를 인터넷 게이트웨이와 연결을 했지만 외부에서 서브넷에 아직 접근을 하지 못한다 이제 접근할 수 있게 퍼블릭 서브넷 전용 라우팅 테이블을 생성해서 인터넷 게이트웨이로 통해 들어온 트래픽을 퍼블릭 서브넷으로 연결해 보겠다

라우팅 테이블도 우리가 생성한 VPC를 선택하면 된다

라우팅 테이블을 생성했으면, 해당 라우팅 테이블은 어떤 서브넷이 사용할 건지 연결해줘야 한다.
라우팅 테이블 목록에서, 라우팅 테이블 체크하고 하단에 서브넷 연결 메뉴의 서브넷 연결 편집 버튼을 클릭하자.

퍼블릭 서브넷만 외부와 통신하기 위해 위에서 생성해놓은 public 서브넷만 선택하고 라우팅 해주자

라우팅을 했다면 다시 라우팅 한 테이블을 선택하고 하단에 라우팅을 클릭하고 오른쪽에 라우팅 편집을 클릭하자 

현재 기본 설정되어있는 라우팅은 VPC대역대에 있는 IP들은 local, 즉 VPC 내부의 사설 IP(private IP)를 서로 알고 있게끔 기본 설정되어있는 것이다. 위에서 IGW와 퍼블릭 서브넷과 라우팅을 했지만 여전히 내부와 통신을 할 수없기 때문에 대상을 0.0.0.0/을 입력하고, 대상에 우리가 만든 인터넷 게이트웨이를 지정해 준다. 즉, 위치 무관 아무나 들어올 수 있음을 의미한다.

 

10.10.0.0/16에 속하지 않은, 제3자의 IP가 현재 public-subnet에 위치한 리소스에 접근하고자 한다면 인터넷 게이트웨이를 통해 접근할 수 있도록 라우팅을 추가해주는 것이다.

지금 까지 VPC를 생성하고 퍼블릭 서브넷 2개와 프라이빗 서브넷 2개를 생성했으며 인터넷 게이트웨이를 생성해서 라우팅 테이블을 통해서 퍼블릭 서브넷과 라우팅을 했다 이제 프라이빗 서브넷끼리 라우팅을 해주자 위에서 했던 방식이기 때문에 어려운 점은 없을 거다

 

프라이빗 서브넷 라우팅

위에서 했던 방식으로 이번에는 프라이빗 서브넷을 위한 라우팅 테이블을 생성해주자 VPC도 앞에서 생성한 VPC를 선택하면 되겠다

라우팅 테이블을 생성했다면 다시 라우팅 테이블로 돌아와서 하단에 서브넷 연결을 클릭해서 서브넷 연결 편집을 클릭하자

프라이빗 서브넷을 선택해서 라우팅 해주자

퍼블릭 서브넷은 이미 앞에서 설정한 라우팅 테이블에 라우터 된걸 다시 한번 확인할 수 있다

이제 구성했던 아키텍처를 구성했으니 각각 퍼블릭 서브넷과 프라이빗 서브넷 안에 EC2를 생성해서 통신을 해보고 어떻게 통신이 이루어지는지 확인해보자

 

서브넷에 EC2 생성

EC2 생성화면으로 이동하자

'네트워크 설정'에서 앞서 만든 VPC를 지정하고, 앞에서 생성한 public 서브넷을 선택하자. 또한 이 인스턴스에 외부에서 접속을 하려면 퍼블릭 아이피를 할당할 필요가 있기 때문에 '퍼블릭 IP 자동할당'을 '활성'으로 지정한다

여기서 OS는 ubuntu이며 인스턴스 유형은 기본 프리티어인 t2.micro이다

 

NAT 게이트웨이 생성

프라이빗 서브넷의 EC2는 인터넷과 연결되어 있지 않다.

그러나 소프트웨어 업그레이드 혹은 인터넷 서비스에 액세스 하기 위해 EC2 가 인터넷과 통신해야 하는 경우가 있다.

인터넷에 대한 아웃바운드 연결을 EC2에 제공하지만, 인바운드 연결로부터는 EC2가 보호된다.

이를 구성하는 방법은 퍼블릭 서브넷에서 NAT 게이트웨이를 구성하면 된다.

 

NAT 게이트웨이는 퍼블릭 서브넷과 외부와의 통신 매개체 이기 때문에 외부에 접근할 수 있어야 하기 때문에 서브넷을 꼭 러블릭 서브넷으로 할당해야 한다.

라우팅 추가를 통해 다음 내용을 추가한다. 0.0.0.0/0 즉 모든 패킷을 nat로 보내라는 테이블을 추가한다. 이렇게 설정하면 내부가 아닌 외부로 향하는 트래픽은 모두 NAT Gateway로 보내지도록 설정된다. 

프라이빗 서브넷도 NAT Gateway와 라우팅이 되었으니 프라이빗 서브넷 내부에 ec2를 할당해 보겠다

퍼블릭 서브넷에 ec2를 할당한 것처럼 똑같이 설정하는데 프라이빗 서브넷에 있는 ec2라 퍼블릭 IP는 할당할 필요가 없다

인스턴스도 할당을 했다면 먼저 퍼블릭 인스턴스에 접속을 하고 vi <설정한. pem> 명령어로 프라이빗 인스턴스에 접속하기 위해 키를 복사한다 복사를 했다면 아래의 명령어로 접근할 수 있다

$ chmod 666 <설정한.pem> #권한을 주기위한
$ ssh -i <설정한.pem> ubuntu@<프라이빗IP> #퍼블릭 IP가아니다 어차피 퍼블릭 IP는 할당되어있지않다

ssh로 접속한 후 ping 8.8.8.8을 통해서 인터넷에 잘 연결되었는지 확인해 보자 (ip 8.8.8.8 은 구글이다. 구글과 잘 연결이 된다는 건 인터넷이 잘 된다는 것이다.)

 

마지막으로 꼭 NAT gateway를 종료해주길 바란다 과금이발생활 수도 있다...