VPC(Virtual Private Cloud)란?

VPC(Virtual Private Cloud)가 뭐지?

그대로 해석하면 가상의 사설 클라우드이며,

외부에서 접속이 불가능한, 클라우드 환경 내 논리적으로 격리된 네트워크를 뜻한다.

 

왜 필요할까?

예전엔 다른 고객과 공유하는 단일 네트워크에서 인스턴스가 실행되는 EC2-Classic을 사용했다.

이러한 상황에선 아래 두 가지 문제점이 존재한다.

1. 인스턴스가 외부에 노출되기 때문에 보안상 취약하다.

2. 단일 네트워크 내에 여러 인스턴스가 존재하기 때문에 인스턴스의 관리가 어렵다.

이로 인해 AWS 게정 내에 생성되는 리소스들의 격리된 네트워크를 만들어주는 서비스가 VPC이다.

 

직접 VPC를 구성해보자!

① VPC IP 대역 설정

먼저 VPC의 IP 주소는 사설망 대역으로 설정한다.

만약 공인 IP 대역을 사용할 경우 VPC 대역과 겹치는 공인 IP는 외부에서 접속이 불가능하기

때문에 사설망 대역의 사용을 권장한다. ex) 10.0.0.0/16

 

② 서브넷 설정

서브넷은 실제 리소스가 생성되는 가용 영역(AZ)과 연결된다.(반드시 하나의 AZ에 속해야 함)

서브넷은 각각 퍼블릭/프라이빗으로 나뉘어지며,

퍼블릭은 Internet Gateway를 통해 외부와 통신이 가능하여 주로 웹서버가 위치하고,

프라이빗은 외부와 통신이 차단된 곳으로 주로 DB가 위치하며 . (NAT Gateway)

 

③ 인터넷 게이트웨이 설정

Internet Gateway는 VPC 내 인스턴스와 외부와의 통신을 담당하는 역할을 수행한다.

IGW 생성 → VPC에 연결 → 라우팅 테이블에 추가

• 퍼블릭 서브넷은 외부와 통신하기 위해 라우팅 테이블에 Internet Gateway를 추가한다.

 

- 프라이빗 서브넷은 외부와 통신이 필요한 경우 Elastic IP를 할당받은

  NAT Gateway가 아웃바운드 트래픽을 전달 받아 Internet Gateway에 전송한다.

 

구성한 VPC의 Architecture는 아래와 같다.

 

IGW, NGW, VGW, CGW

Internet Gateway

-> VPC 내의 인스턴스와 외부와의 통신을 담당하는 역할

 

NAT Gateway

-> 프라이빗 서브넷이 외부와 통신이 필요할 경우 프라이빗 서브넷의 아웃바운드 트래픽을 전달받아 Internet Gateway로 전송하는 역할

 

Virtual Gateway, Client Gateway

-> AWS와 IDC를 함께 사용하는 경우에 사용한다.

Virtual Gateway는 원격 네트워크로 향하는 트래픽을 전송하며, vpn 터널 중 하나를 따라 라우팅된다.

Customer Gateway는 IDC의 vpn 장비의 ip이며, 공인 ip여야 한다.

 

 

Security Group, NACL

Security Group

인스턴스 레벨의 방화벽이며, 인바운드/아웃바운드 규칙을 통해 트래픽을 제어한다.

인바운드 규칙은 기본적으로 All Deny이며 allow할 트래픽을 설정하는 Whitelist 방식이고,

아웃바운드 규칙은 기본 All Allow이며 deny할 트래픽을 설정하는 Blacklist 방식이다.

 

NACL

서브넷 레벨의 방화벽이며, 동일하게 인바운드/아웃바운드 규칙을 통해 트래픽을 제어한다.

 

	Security Group	NACL
규칙 적용	모든 규칙이 한 번에 적용	규칙 번호가 낮은 것부터 우선 적용
권한 설정	허용할 것만 allow, 기본적으로 all deny	모든 규칙에 대해 allow/deny 설정 가능
통제 규모	개별 ip 대역 통제(소규모)	넓은 범위의 네트워크 대역 통제(해외 ip 차단 등에는 NACL을 사용)
통제 대상	개별 ip 대역 통제(소규모)	네트워크 대역의 인아웃바운드
요청 정보	Stateful → 요청 정보를 저장하여 응답하는 트래픽을 제어하지 않는다.	Stateless → 요청 정보를 저장하지 않기 때문에 응답하는 트래픽을 제어해줘야 한다.

예를 들어 Security Group1 -> Security Group2로 ping을 전송했을 때

Stateful은 요청에 대한 정보를 저장하기 때문에 SG1의 OutBound, SG2의 InBound 규칙만 정의해주면 된다.

반면, Stateless는 요청에 대한 정보를 저장하기 않기 때문에 SG1의 OutBound, InBound와 SG2의 OutBound, InBound 규칙 모두 정의해줘야 한다.