VPC, Private Subnet, Pubilc Subnet

VPC (Virtual Private Cloud)

VPC는 논리적으로 격리된 사용자 전용 가상 네트워크이다. 복수의 AZ (Availibity Zone, 가용영역 ≒ 데이터센터) 걸친 형태로 생성 할 수 있다. 쉽게 말하면 AWS의 리소스들이 위치할 네트워크 망이다.

프로젝트에 사용되는 리소스 (EC2, RDS, S3 등등)이 물리적으로 하나의 데이터센터에만 위치해있다면 해당 데이터 센터에 문제가 생긴다면 서비스가 전체적으로 다운으 되는 문제가 발생 한다.

하지만 가상네트워크를 이용하여 물리적으로는 다른곳에 위치하지만, 같은 사설망 IP 대역에 위치하게 만들어서 리소스들끼리 통신할 수 있게 만들어주는 기술이다.

처음에 AWS 계정을 생성하면 기본적 VPC가 잡혀있지만 다양한 필요에 의해 직접 VPC를 생성하여 리소스들을 위치시킬 수 있다.

Subnet

Subnet은 VPC의 영역안에서 네트워크 망을 더 쪼개는 행위라고 볼 수 있다.

하지만 VPC와는 달리 지역적으로 나누기때문에 여러 AZ에 있지 않고 단일 AZ에 존재 한다.

대표적으로 보안과 네트워크의 브로드캐스트의 영역을 축소시켜 통신 성능을 올리기 위함이다.

Public Subnet

간단하게 외부에서 접근이 가능한 네트워크영역이라고 볼 수 있다.

구체적으로는 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 라우팅 테이블과 연결되는 경우 퍼블릭 서브넷이라고 한다.

인터넷 게이트웨이(igw)는 VPC의 구성요소로써 VPC와 인터넷간에 통신을 할 수 있게 만들어주는 역할을 한다.

서브넷이 바라보는 라우팅 테이블에 인터넷 게이트웨이가 등록 되어 있으면 Public Subnet 이라고 볼 수 있다.

방법론적으로 설명하면, 서브넷이 바라보는 라우팅테이블에 인터넷게이트웨이가 등록 되어 있으면 Public Subnet 이라고 볼 수 있다. 그리고 해당 퍼블릭 서브넷은인터넷과 연결이 가능하므로 퍼블릭 서브넷에 위치한 리소스들은 공인IP를 가질 수 있다.

Private Subnet

간단하게 말하면 외부에서 다이렉트로 접근이 불가능한 네트워크 영역이라고 볼 수 있다.

프라이빗 서브넷의 라우팅 테이블에 인터넷게이트웨이가 등록되어있지 않으므로, 해당 서브넷에 위치한 리소스들은 외부와의 연결이 불가능하다.

하지만 해당 서브넷에 DB가 있다고 가정하면, DB버전을 업그레이드하기위해서 인터넷 연결이 필요할 수 있다.

이때 NAT 게이트웨이를 이용하여, 내부에서 외부로만 접근이 가능하게 만들어 줄 수 있다.

하지만 외부에서 NAT 게이트웨이를 이용하여 프라이빗 서브넷으로 접근하는것을 불가능 하다.

여기서 말하는 외부란, VPC영역이 다른것을 의미한다. 같은 VPC영역에 있으면 private IP로 접근이 가능하다.

NAT 게이트웨이 설정 방법은 퍼블릭 서브넷에 NAT 게이트웨이에 EIP를 할당하고 생성 후 프라이빗 서브넷의 라우팅 테이블에 등록해주면 접근이 가능하다.

즉, 프라이빗 서브넷에서 라우팅 테이블을 보고 인터넷으로 나가는 규칙 (0.0.0.0)에 대해서는 NAT 게이트웨이를 타고 EIP(공인 IP)로 변환 후 igw를 통해 인터넷으로 나가는것이다.

 

이렇게 불편하게 프라이빗 서브넷을 사용하는 이유는, 엄격하게 다뤄야할 리소스들을 안전하게 관리하기 위함이다.

만약, DB를 프라이빗 서브넷에 위치시킨다던가, ELB만 퍼블릭영역에 두고 실제 WAS는 프라이빗영역에 배치하여 보다 안전하게 관리할 수 있다.

 

추가적으로, 초기환경 구축을 위해 로컬에서 접속을 한다면 당연히 접속할 수 없다. 외부에서 다이렉트로 접속할 공인IP가 할당이 안되어있기 때문이다. 따라서 ssh 터널링 방법 및 Bastion host EC2 등을 사용하여 같은 vpc 에있는 퍼블릿 서브넷을 통해 접속 할 수 있다.