21. Amazon VPC

Amazon VPC

Amazon Virtual Private Cloud, 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작 가능하게 하는 서비스

즉, Private Network를 활용하여 네트워크 망을 구성하고 내부에 각종 리소스를 탑재할 수 있는 서비스다.

대표적인 리소스들은 EC2, ELB, RDS, Security Group, Network ACL 등이 있다.

VPC에 들어가는 리소스들은 고유의 사설 IP와 Interface를 가지며, 외부에 공개되는 리소스라면 공인 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 넷마스크입니다.

 

일반적으로 전통적인 네트워크의 구조는 아래와 비슷하다고 할 수 있다.

사설 네트워크 안에 서브넷 A, 서브넷 B 같은 여러 서브넷들이 존재하고

그걸 라우터 등의 경로장비가 관리하며

인터넷 게이트웨이가 전체 사설 네트워크를 관리하는 전형적인 모습이다.

 

AWS라고 크게 달라지지 않는다.

AWS가 제공하는 사설 네트워크 안에 서브넷 A, 서브넷 B 같은 여러 서브넷들이 존재하고

그걸 라우터 등의 경로 장비가 관리하며

인터넷 게이트웨이가 전체 사설 네트워크를 관리한다.

 

단, AWS가 여러 서비스를 관리하고 있기 때문에,

"내가 어느 영역부터 어느 영역까지 사용하겠습니다"라는 사설 IP 대역을 정해줘야 AWS가 그걸 알아듣는다.

기존 인프라와 동일한 대역의 사설 IP를 사용할 수 있지만,

기존 사설 IP 대역과는 달리 /16~/28비트의 서브넷 마스크만 허용한다.

즉, VPC의 가장 큰 대역은 /16, 가장 작은 대역은 /28

 

CIDR 표기법

Classless Inter-Domain Routing, 즉 클래스 없는 도메인간 라우팅 기법이라는 뜻

본래 IP는 A,B,C,D 클래스로 나누어 사용 목적과 그 크기에 따라 클래스를 분류하였다.

하지만 폭발적으로 증가하는 인터넷 호스트의 양을 따라잡지 못했고,

결국 기존 IP 주소 클래스 체계보다 더 능동적이고 세부적인 주소 할당 방식이 필요해졌다.

이에 나온것이 CIDR 표기법

 

IP 주소의 클래스를 배울 때, 서브넷 개념을 같이 공부하게 된다.

호스트 주소와 서브넷 주소를 나누어 더 많은 IP 대역을 사용하게 하는 원리로,

이 서브네팅 과정과 매우 유사하다고 생각하면 된다.

 

통상적으로 서브네팅을 배울 때, 서브넷 마스크의 영역을 다음과 같이 표기한다

192.168.50.27/26

서브넷 마스크를 뒤에 적은 저 방법이 바로 CIDR 표기법으로,

저 숫자의 크기가 바로 네트워크 길이의 크기를 한 번에 나타낼 수 있는 것이다.

 

이 CIDR은 자신이 속한 네트워크의 서브넷의 범위를 정확하게 알려줄 수 있으며,

이는 서브넷 IP 재발급 및 네트워크 관리에 아주 유용하게 사용할 수 있다.

 

계산법은 간단하다. 위에 나온 192.168.50.27/26의 범위를 계산해보자.

 

서브넷 마스크가 26이므로,

11111111.11111111.11111111.11000000의 서브넷 마스크를 가진다.

즉 나머지 6비트가 호스트 ID로 할당되게 된다.

이는 10진법으로 192며,

서브넷 마스크는 255.255.255.192가 된다.

 

256 - 192 = 64,

이 때 맨 앞의 게이트웨이 IP와 맨 뒤의 브로드캐스트 IP를 제외하면 총 62개의 호스트를 가질 수 있다.

따라서 해당 IP 대역은 다음과 같은 정보를 가진다.

네트워크 1	192.168.50.0 ~ 192.168.50.63
네트워크 2	192.168.50.64 ~ 192.168.50.127
네트워크 3	192.168.50.128 ~ 192.168.50.191
네트워크 4	192.168.50.192 ~ 192.168.50.255

이로 인해, 해당 IP는 네트워크 2에 속해있으며,

해당 대역이 192.168.50.64 ~ 192.168.50.127라는 정보를 알 수 있다.

 

VPC 서브넷

VPC가 생성되면 여러 조각으로 쪼개어 관리하게 된다.

AWS는 여러 AZ를 가지고 있는데, 이 AZ를 가진 서브넷을 각각 배치하는 구조로 AWS가 동작한다.

이러한 구조는 왜 필요할까? 

이유는 서비스 별 필요로 하는 IP 대역이 다르기 때문이다.

 

EC2가 탑재되는 서브넷은 보통 다수의 EC2를 탑재하는 경향이 있다.

이말은 곧 다량의 사설 IP가 필요하다는 의미로, 서브넷을 크게 나누어 IP 공간을 많이 확보한다.

반면 RDS 같은 서비스는 서비스의 수가 그렇게 많지 않다.

때문에 IP가 많이 필요없으며, 서브넷을 작게 나누어 IP 공간을 절약한다.

한 서브넷 안에 있는 인스턴스들은 DHCP를 통해 IP가 자동으로 부여되며,

이 범위는 서브넷 범위를 넘어가지 않는다.

서브넷의 범위는 관리자가 설정할 수 있다.

 

---

실습

목표는 해당 네트워크 구성을 구축하는 것

VPC 생성

VPC 생성 완료

VPC 서브넷 생성 과정 (10.0.1.0/24)

us-east-2a AZ에 생성한 서브넷 목록

us-east-2c에 생성 또한 완료

인터넷 게이트웨이 생성

인터넷 게이트웨이 연결

게이트웨이 라우팅 편집

퍼블릭 서브넷을 퍼블릭 게이트웨이에 연결

동적 IP 할당을 위한 탄력 IP 할당 부여

NAT 게이트웨이 설정

새 라우팅 테이블 생성 후 NAT 게이트웨이 연결

프라이빗 서브넷을 프라이빗 게이트웨이에 연결

VPC 리소스 맵을 통해 정상적으로 연결된 것을 확인

---

만들어 둔 AWS 네트워크 환경에 웹 서버 인스턴스 생성 및 연결을 목표

EC2 제작 시 기존 VPC와 서브넷 할당

보안 규칙으로 HTTP(80), HTTPS(443) 허용

#!/bin/sh

amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
yum -y install httpd php-mbstring
echo "My home page Emma[myname]" >> /var/www/html/index.html
chkconfig httpd on
systemctl start httpd
yum -y update

사용자 데이터를 선입력

웹 페이지 접속 성공