포스트

AWS VPC를 이해해보자

게시 업데이트
By Jeongyun Lee
12 분읽는 시간

AWS를 사용하여 어플리케이션을 배포할 때 VPC의 사용은 거의 필수적이다.
이번 포스팅은 “내가 이해한” VPC와 그 안에서 사용되는 개념들을 정리하고 기록해보려고 한다.

picture 5

AWS에 접속하고 VPC 페이지에 들어가면 아래와 같은 많은 서비스들이 있는 것을 볼 수 있다.
지금은 여기서 Virtual Private Cloud 섹션이 있는 것들 중 내가 개발에 사용한 몇가지만 살펴본다.

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

VPC (Virtual Private Cloud)

AWS 안에서 사용하는 내부망이라고 생각하면 된다.
이 내부망 안에서 여러개의 애플리케이션(서버)들이 배치가 될 것이고
그 어플리케이션은 VPC 위에서 서로 통신을 하게 된다.

좀 더 자세한 내용을 위해 VPC를 생성해보자.

VPC 생성

picture 7
VPC를 생성할 때 생성할 리소스 섹션에서 VPC 등을 선택했을 때의 화면이다.
VPC만 생성한다 해도 제대로 쓸거면 어차피 다른것들을 기본적으로 다 설정해야한다.
사실상 이곳에 기본적인 구조가 모두 나타나 있는데, 하나하나 살펴보도록 하자.
이름은 운영 환경에 대한 VPC를 생성한다고 보고, 임의로 production 이라고 지어봤다.

IPv4 CIDR 블록

CIDR은 간단하게 *.*.*.*/* 형태로 “아이피의 범위”를 나타내는 표기법이다.
사진과 같이 10.0.0.0/16 으로 지정하면, 10.0.0.0 부터 10.0.255.255 까지 65536개의 아이피를 이 VPC에서 할당할 수 있다는 의미이다.
/ 뒤에 붙는 숫자는 맨 앞부터 고정할 자리의 개수(2진법)를 나타내기 때문에 숫자가 커질수록 VPC 내에서 할당할 수 있는 아이피의 개수가 줄어든다.
위의 범위에서 10.0 부분이 고정되어있기 때문에 그 부분이 16이라고 보면 된다.
앞으로도 계속 나올테니 이해하고 넘어가자.

가용 영역(AZ) 수

사용 가능한 영역을 뜻하는데, 앞으로 무중단 서비스 같은 것을 구현하려면 최소 2개의 가용 영역이 필요하다.
내가 이해하기로는 하나의 영역이 모종의 이유로 죽으면 다른 가용 영역으로 바로 갈아탈 수 있도록 하기 위함인 것 같다.
사진에서 다이어그램을 보면 ap-northeast-2a와 ap-northeast-2b로 두개의 가용 영역이 나눠진 것을 볼 수 있다.

퍼블릭 서브넷 수 / 프라이빗 서브넷 수

서브넷은 아까 말했던 아이피의 범위를 쪼갠 것이라고 보면 된다.
서브넷이 총 4개라고 한다면 65536개를 4로 나눠서 16384개씩 나눠서 각자 다른 처리를 할 수 있도록 한 것이다.

가용 영역 마다 퍼블릭 서브넷과 프라이빗 서브넷을 둘 수 있다.
사진에서 가용 영역마다 두개의 서브넷이 있는 것을 볼 수 있는데, 각각 퍼블릭과 프라이빗 서브넷이다.

퍼블릭 서브넷은 인터넷 게이트웨이를 통해서 인터넷에 공개적으로 접근할 수 있는 영역이다.
인터넷 게이트웨이는 그냥 인터넷과 연결하는 문이라고 보면 된다.
사진에서 네트워크 연결 영역에 igw로 끝나는 것이다. 반면에 프라이빗 서브넷은 인터넷 게이트웨이에 연결되지 않아서 인터넷에 공개적으로 접근할 수 없는 영역이다.

보통 AWS에 애플리케이션을 배포할 때 애플리케이션들을 프라이빗 서브넷에 위치시켜서 외부에서 직접 접근할 수 없도록 한다.
그리고 외부에서 프라이빗 서브넷에 있는 애플리케이션에 접근해야 할 때 퍼블릭 서브넷을 통해서 허용된 곳에서만 접근할 수 있도록 한다고 보면 된다.

NAT 게이트웨이

위에서 프라이빗 서브넷은 인터넷과 단절된 상태라고 설명했는데, 애플리케이션을 배포하다보면 라이브러리 파일을 다운로드 하는 등 애플리케이션 내부에서 인터넷을 사용해야 할 때가 있다.
내부에서 외부로 요청을 하는 것이기 때문에 이는 아웃바운드 요청이라고 하는데, NAT 게이트웨이는 이것을 처리해주는 역할을 한다.
만약 애플리케이션이 모든 파일을 가지고 있고 인터넷으로부터 가져올 것이 없다고 하면 설정하지 않아도 되긴 하다.
NAT 게이트웨이는 인터넷 게이트웨이를 통해서 인터넷에 연결해주는 것이기 때문에 기본적으로 퍼블릭 서브넷에 위치해있어야 한다.
NAT 게이트웨이를 활성화 하면 그것을 위해서 인스턴스를 따로 생성하며, 가격이 상당히 비싸다.
정말 필요할 때만 쓰고, 만약 가격이 부담될 것 같으면 프라이빗 서브넷에 인터넷 게이트웨이를 연결하는 방법도 있다.

VPC 엔드포인트 - S3 게이트웨이

이것도 프라이빗 서브넷이 인터넷과 단절되어있기에 필요한데, 프라이빗 서브넷에서 S3 리소스에 직접 접근할 수 있도록 해준다.
S3에는 보통 용량이 좀 되는 것들이 들어가있을텐데, 그것들까지 NAT 게이트웨이를 통해서 접근하다보면 비용이 훨씬 많이 나올테니, 따로 접근할 수 있는 엔드포인트를 만들어주는 것 같다.
어차피 AWS의 리소스이니 가능한 기능인 것 같다.

완료

여기까지 보고 VPC 생성버튼을 누르면 지금까지 생성한 것들을 차례로 생성해준다.
이 아래에서는 추가적으로 알면 좋은 개념을 정리하겠다.

라우팅 테이블

라우팅 테이블은 VPC 내에서 “이 주소로 접근하면 어디로 보내면 되는지”를 나타낸다.

아래 사진은 public 서브넷에 연결되어있는 라우팅 테이블을 조회한 것이다.
picture 8
picture 9
public1 서브넷과 public2 서브넷이 0.0.0.0/0 영역대로 요청할 시 igw(인터넷 게이트웨이)로 연결되는 것을 볼 수 있다.
외부 인터넷에 연결되어있는 것이다.

반면에 private 서브넷에 연결되어있는 라우팅 테이블을 조회하면 아래와 같다. picture 10
picture 11 private1 서브넷 하나가 연결되어있고, S3로 연결되는 vpce(VPC 엔드포인트)와 0.0.0.0/0 영역대로 요청할 시 nat(NAT 게이트웨이)로 연결되는 것을 볼 수 있다.
이와 동일하게 private2에 대한 라우팅 테이블도 있을 것이다.

네트워크 ACL(Access Control List)

네트워크 ACL은 “서브넷”에 연결하는 규칙을 설정하는 곳이다.

picture 12
picture 13 picture 14

사진과 같이 하나의 네트워크 ACL에 여러개의 서브넷에 대한 인바운드/아웃바운드 규칙이 정의되어있는 것을 볼 수 있다.
현재는 모든 아이피, 프로토콜, 포트에 대해서 허용을 해둔 상태인데,
물론 프라이빗은 인터넷 게이트웨이에 연결되어있지 않기 때문에 허용이 되어있다고 해도 외부에서 접근할 수 없다.

보안 그룹

보안 그룹은 ACL과 같이 인바운드/아웃바운드 규칙을 설정하는 곳인데,
그 대상이 서브넷이 아닌 서비스 또는 애플리케이션 단위이다.
만약 특정 IP에서만 허용할 서비스가 있다면 이것으로 설정해줄 수 있다.

여기까지 VPC 설정에 대해서 아주 간단하게 알아보았다.
다음에는 이렇게 생성한 VPC와 Elastic Beanstalk을 사용하여 애플리케이션 배포하는 방법도 포스팅 해볼까 생각중이다.

개발
AWS
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.