AWS VPC 환경 구축해보기

Notice

Recent Posts

Recent Comments

Link

« 2024/05 »
일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

Tags more

Archives

Today

Total

관리 메뉴

고딩왕 코범석

AWS VPC 환경 구축해보기 본문

Infra/AWS

AWS VPC 환경 구축해보기

고딩왕 코범석 2021. 11. 25. 23:11

안녕하세요! 이번 포스팅에서는 AWS VPC 환경을 구축해보겠습니다. 먼저 이번 포스팅 진행 순서는

VPC 개념
VPC 구축

의 순서로 진행해보겠습니다.

VPC 개념

VPC(Virtual Private Cloud) 개념

VPC는 사용자가 정의하는 가상 네트워크 입니다. 만약, EC2를 VPC 없이 생성하게 된다면 구분 없는 연결로 인해 복잡도가 늘어나며 비효율적일 것입니다.

만약 이 VPC를 통해 하나의 네트워크 공간에 묶어서 자원들을 할당한다면 묶은 네트워크 공간을 구분할 수 있고, 이 공간에 따라 설정할 수 있을 것입니다. 그림으로 표현해보면 아래와 같습니다.

이 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는 하나의 리전에 종속되며, 이 서로 다른 VPC들은 완전히 독립적이어서 이들 간의 통신이 필요하다면 VPC Peering을 고려해볼 수 있습니다. 그리고 x.x.x.x / x 의 형태(CIDR 표기)는 바로 뒤에 설명드릴 서브넷과 같이 설명드리겠습니다.

서브넷(Subnet)

서브넷은 저렇게 나뉘어진 VPC 공간을 잘게 쪼개는 과정입니다. 이 서브넷의 범위는 당연히 VPC보다 범위가 작아질 것입니다.

서브넷의 예를 들어보겠습니다. 우선, 10.0.0.0/16 이라는 CIDR로 VPC를 생성했다고 가정해보았을 때, 저 CIDR로 표기된 IP 주소를 4옥텟으로 볼 때,

00001010(10) . 00000000(0) . 00000000(0) . 00000000(0)

과 같이 표현됩니다. 이 때 저 뒤에 /16 의 의미는 4옥텟에서 앞 부터 16자리 수 까지는 고정 값이며, 뒤의 나머지 16자리들에 대해 자원을 할당할 수 있다. 라는 의미로 볼 수 있습니다.

따라서 위의 예제는 2 ** 16 = 65,536 가지의 IP (10.0.0.0 ~ 10.0.255.255)에 자원을 할당할 수 있는 것을 확인할 수 있습니다. 그리고 서브넷 생성시에도 이 65,536 가지를 넘지 않아야 합니다.

서브넷을 10.0.1.0/24 CIDR 로 생성 시에는 10.0.1.0 ~ 10.0.1.255 까지 IP 범위인 총 256 가지의 IP에 자원을 할당할 수 있습니다.

또한 이 서브넷을 public으로 공개할 수 있으며, private으로 외부 통신을 막을 수 있습니다. 이에 대한 설명은 인터넷 게이트웨이에서 설명드리겠습니다.

라우팅(Routing)

네트워크에 요청이 발생하면, 데이터는 우선 라우터로 향하게 됩니다. 이 라우터는 종착지를 뜻하고 설정된 라우팅 테이블에 따라 움직이게 됩니다. 또한 서브넷이 여러개 만들어 졌을 경우 각각의 서브넷끼리 통신을 해야하는데, 이 라우팅 테이블을 보고 트래픽이 전달되는 위치를 제어할 수 있습니다.

현재 그림에서 VPC는 172.31.0.0/16 으로 설정되어 있고, 서브넷 A에 설정된 라우팅 테이블은 172.31.0.0/16 입니다. 따라서 이 서브넷 A 네트워크에 전달될 수 있는 범위는 자신이 속한 VPC 전체를 의미합니다. 하지만, 이 외의 트래픽 즉, 외부로 통하는 트래픽은 처리할 수 없습니다. 이 때, 인터넷 게이트웨이를 이용합니다.

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

인터넷 게이트웨이는 VPC와 인터넷을 연결해주는 통로입니다. 앞에서 말씀드렸듯, 외부와의 통신을 할 수 있는 유일한 관문입니다.

또한 그림을 보면 서브넷 B는 라우팅 테이블에 0.0.0.0/0 인터넷 게이트웨이 A 라고 표기되어 있습니다. 서브넷 B에서 네트워크 트래픽을 처리할 때 위에 적혀있는 172.31.0.0/16 을 확인하고 여기에 포함되지 않는다면 모든 트래픽을 인터넷 게이트웨이 A에 보낸다 라고 이해하시면 될 것 같습니다.

이 때, 서브넷 A는 172.31.0.0/16 만 라우팅 테이블에 표기되어 있습니다. 이렇게 라우팅 테이블에 모든 요청에 대해 인터넷 게이트웨이를 가리키지 않는 서브넷은 프라이빗 서브넷(Private Subnet) 이라고 하며, 서브넷 B의 경우는 *퍼블릭 서브넷(Public Subnet) *이 됩니다.

NAT 게이트웨이 (Network address translation Gateway)

프라이빗 서브넷에서도 외부와의 통신이 필요한 경우가 있습니다. 이 때는 이 NAT 게이트웨이를 이용해 아웃바운드를 외부로 설정할 수 있습니다.

이 때, 프라이빗 서브넷에서 외부와 통신할 경우 퍼블릭 서브넷에 위치한 NAT 게이트웨이를 통해 같은 가용 영역의 퍼블릭 서브넷으로 보내고, 퍼블릭 서브넷과 연결된 인터넷 게이트웨이를 통해 외부와 통신합니다.

VPC 구축

이제 본격적으로 VPC 환경을 구축해보겠습니다. 우선 AWS에 접속 후 VPC 대시보드에 들어갑니다.

VPC 생성

VPC 생성을 누르고 필요한 정보를 입력해줍니다.

VPC의 이름과 CIDR 값을 입력해줍니다. 위에서 설명드린 것 처럼 저는 10.0.0.0/16으로 표기했습니다.

서브넷 생성

VPC 생성 후에 왼쪽 대시보드 창에서 서브넷을 들어가보겠습니다. 서브넷의 경우, 퍼블릭 서브넷 두 개와 프라이빗 서브넷 두 개를 생성해 볼 예정입니다. 우측 상단에 서브넷 생성을 누르면

먼저, 아까 만들었던 VPC와 VPC를 만들 때 설정했던 CIDR 값도 확인한 다음 밑에

다음과 같이 설정합니다. 서브넷은 총 4개를 만들어야 합니다. 각각 만들때

서브넷 이름

example-vpc-pub1-2a (이름-vpc-{pub/pri}-가용영역)
example-vpc-pub2-2c
example-vpc-pri1-2a
example-vpc-pri2-2c

CIDR 블록

example-vpc-pub1-2a : 10.0.1.0/24
example-vpc-pub2-2c : 10.0.2.0/24
example-vpc-pri1-2a : 10.0.3.0/24
example-vpc-pri2-2c : 10.0.4.0/24

와 같이 설정해주세요. 설정 후 대시보드를 들어가서 서브넷 검색 필터에 아까 만들었던 VPC로 필터를 하시면

위와 같이 4개의 서브넷이 생성된 것을 알 수 있습니다. 참고로 사용 가능한 IPv4의 갯수가 251개인 이유는 256개에서 5개는 아래와 같은 예약된 IP 주소가 있기 때문입니다. 참고

10.0.0.0 : 네트워크 주소
10.0.0.1 : VPC 라우터용 예약 주소
10.0.0.2 : AWS에서 예약한 DNS 주소
10.0.0.3 : AWS에서 향후 사용을 위한 예약 주소
10.0.0.255 : 브로드캐스트 주소

인터넷 게이트웨이 생성

이제 VPC와 인터넷 통신을 위한 통로인 인터넷 게이트웨이를 설정해보겠습니다. 왼쪽 대시보드에서 인터넷 게이트웨이를 누르고 생성 버튼을 눌러줍시다.

다 만들어졌다면, VPC와 연결시켜야 합니다. 방금 만든 인터넷 게이트웨이를 선택 후 작업을 누르면 VPC에 연결할 수 있습니다.

인터넷 게이트웨이의 상태가 VPC에 붙었음을 확인할 수 있습니다.

NAT 게이트웨이 생성

프라이빗 서브넷이 아웃바운드로 외부에 인터넷과 통신할 수 있게 도와주는 NAT 게이트웨이를 설정해보겠습니다. 왼쪽 대시보드에서 NAT 게이트웨이를 누르고 생성 버튼을 누르면

우선, NAT 게이트웨이는 퍼블릭 영역에 있어야 합니다. 그래야 인터넷 게이트웨이와 닿아 외부로 아웃바운드 트래픽을 보낼 수 있기 때문입니다. 또한, 가용 영역별로 NAT 게이트웨이를 만들어줘야 하는데 이유는 특정 가용 영역이 다운되면 다른 가용 영역에 위치한 리소스들도 인터넷에 트래픽 이동이 되지 않습니다. 가용 영역과 독립적인 아키텍처를 만들기 위해 각 가용 영역 마다 NAT 게이트웨이를 생성해주어야 합니다.

또한 외부에 트래픽을 보낼 때는, 가상의 주소가 아닌 실제 주소가 필요하기 때문에 해당 NAT 게이트웨이에 탄력적 IP를 부여했습니다. 그래서 저희가 만들 NAT 게이트웨이는