VPC는 독립적인 가상의 네트워크 공간으로 사용자의 설정에 따라 자유롭게 구성할 수 있는 공간을 의미합니다. 따라서 사용자는 서브넷 생성, 라우팅 테이블, 네트워크 게이트웨이 구성 등 네트워킹 환경을 사용자가 원하는 대로 완벽하게 제어할 수 있습니다.
서브넷 : IP 주소에서 네트워크 영역을 부분적으로 나눈 부분 네트워크
라우팅 테이블 : 컴퓨터 네트워크에서 목적지 주소를 목적지에 도달하기 위한 네트워크 노선으로 변환시키는 목적으로 사용
네트워크 게이트웨이 : 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 포인트
만약 VPC가 없다면 AWS Cloud 안의 리소스들을 연결하기 위해 추가적인 작업들이 많이 생길 것입니다. 그렇게 되면 시스템 복잡성이 높아질 것입니다. 그러나 VPC를 이용하면 같은 VPC를 묶어서 리소스를 쉽게 관리할 수 있다.
VPC에서 사용하는 사설 IP대역
- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)
- 172.16.0.0 ~ 172.31.255.255(182.16/12 prefix)
- 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)
서브넷이란 앞서 설정한 VPC를 잘게 쪼개는 과정이라고 생각할 수 있습니다. VPC 단 안에서 더 많은 네트워크 망을 구성하기 위해 설정하는 단계입니다.
서브넷은 가용 영역이라고 하는 Availability Zone(AZ) 여러 개에 걸쳐서 설정할 수 없으며 하나의 가용 영역 안에서 존재해야 한다는 특징을 가지고 있습니다.
이렇게 생성한 서브넷 안에 AWS의 여러 리소스들을 위치시킬 수 있습니다.
네트워크 요청이 발생하면 데이터는 라우터로 향하게 되고 라우팅 테이블에 따라 네트워크 요청이 작동됩니다.
이때 필요한 라우팅 테이블이란 네트워크 트래픽을 어디로 전송할지 결정하는 데 사용되는 규직 집합. 즉, 목적지에 대한 이정표라고 할 수 있습니다.
기본적으로 VPC에 기본 Route table이 존재하지만 서브넷마다 다른 Route table을 할당할 수 있습니다.
또한, 하나의 Route table을 여러 서브넷과 연결하는 것도 가능합니다.
위의 그림 각각의 서브넷에 Route table을 설정한 모습입니다.
Subnet1의 Route table은 10.0.0.0/16에 해당하는 네트워크 트래픽을 로컬로 향하도록 설정되어 있습니다. 반대로 말하면 그 이외의 트래픽은 허용되지 않는다는 것을 의미합니다.
Subnet2의 Route table은 10.0.0.0/16에 해당하는 네트워크 트래픽은 로컬로 보내지지만 그 외의 모든 트래픽에 대해서는 인터넷과 연결시켜주는 관문이라고 할 수 있는 인터넷 게이트웨이(Internet Gateway)로 향하도록 설정한 모습입니다.
이때 인터넷 게이트웨이와 연결하는 Route table을 갖는 서브넷을 ‘Public Subnet’이라 하고, 인터넷 게이트웨이와 연결하는 Route table을 갖지 않는 서브넷을 ‘Private Subnet’이라고 합니다.
Network Access Control List(NACL)과 Security Group(보안 그룹)은 방화벽과 같은 역할을 하며 인바운드 트래픽과 아웃바운드 트래픽 보안 정책을 설정할 수 있습니다.
Security Group과 NACL의 특징은 아래의 표와 같습니다.
Security Group은 필요한 트래픽만 허용하는 것을 정책이라면, NACL은 불필요한 트래픽을 차단하는 것을 적용하는 정책이라고 이해할 수 있다.
만약, NACL과 Security Group이 충돌하는 상황에서는 Security Group가 더 높은 우선순위를 갖습니다.
Private 서브넷이 인터넷과 통신하기 위해서는 Private 서브넷에서 외부로 요청하는 아웃바운드 트래픽을 받아 소스 IP 주소를 변환해 인터넷 게이트웨이로 트래픽을 보내는’ NAT 서비스’가 필요합니다.
NAT 서비스를 구현하는 방법은 크게 두 가지가 있습니다. 하나는 AWS의 NAT Gateway를 이용하는 방법이 있고, 다른 하나는 EC2를 NAT 용으로 사용하는 방법이 있습니다.
NAT Gateway 또는 NAT 인스턴스는 Public 서브넷에서 동작해야 하며, Private 서브넷에서 외부로 요청하는 아웃바운드 트래픽 받을 수 있도록 Route table을 설정합니다.
다른 VPC와 연결하기 위해서는 VPC Peering은 두 VPC 간에 트래픽을 라우팅할 수 있도록 서로 다른 VPC 간의 네트워크 연결을 제공합니다.
동일한 네트워크에 속한 것처럼 서로 다른 VPC의 인스턴스 간의 통신이 가능합니다.
다른 Region, 다른 AWS 계정의 VPC Peering 연결도 가능합니다. 단, 연결할 VPC 간의 IP 범위가 겹치는 것은 불가능합니다.
VPC Peering 연결 순서는 아래와 같습니다.
피어링 요청 → 피어링 요청 수락 → Route table 및 Security group 내 피어링 경로 업데이트
VPC Peering의 또 다른 특징으로는 전이성 피어링이 불가능하다는 것입니다.
VPC A – VPC B, VPC B – VPC C 간의 피어링 연결이 되어있다고 해도 VPC A – VPC C 간의 연결은 안 된다는 의미입니다.
따라서 VPC A와 VPC C와의 연결을 원할 경우 따로 피어링 연결을 해주어야 합니다.
기존 온프레미스와의 연결을 통해 하이브리드 환경 구성이 가능합니다.