클라우드 네트워크 인프라의 기초 이해: VPC와 Subnet
VPC
VPC는 가상 사설 클라우드(Virtual Private Cloud)의 약자로, AWS 계정 전용 가상 네트워크이다.
다른 가상 네트워크와 분리된 상태로 아마존 EC2 인스턴스와 같은 AWS 리소스를 실행할 수 있으며, 쉽게 말하면 VPC는 가상 데이터 센터이다.
이는 외부와 격리된 네트워크 단위로, 원하는 대로 사설 네트워크를 구축하고 IP 대역을 분할하여 사용할 수 있다.
VPC는 EC2, RDS 등의 AWS 컴퓨팅 서비스를 실행하거나, 보안 설정이 가능하여 다양한 가상의 데이터 센터를 구축할 수 있게 해준다.
일반적으로 우리는 퍼블릭 인터넷을 통해 넷플릭스, 깃허브, 네이버와 같은 웹사이트를 이용하게 되는데
AWS 클라우드 또한 마찬가지로, 퍼블릭 인터넷을 통해 다이나모DB, S3, 클라우드워치 등의 다양한 서비스를 사용하는 것이 일반적이다.
그러나 VPC는 원칙적으로 퍼블릭 인터넷에서 접근이 불가능하며, 다른 AWS 서비스들은 퍼블릭 엔드포인트를 가지고 있으나 VPC는 그러하지 않다.
또한, VPC에 속해있는 서비스는 같은 AWS 내부에서도 원칙적으로는 바로 내부 AWS 서비스(같은 VPC에 속해있지 않은)에 접근할 수 없으며(관련 인프라 도움 없이는), 일단 나갔다가 퍼블릭 인터넷을 통해 AWS 서비스에 들어와야 하는 방식을 따르게된다.
VPC의 구성요소
VPC 구성 요소로는 서브넷, 인터넷 게이트웨이, NACL, 보안 그룹, 라우팅 테이블, NAT 인스턴스 등이 있다.
Subnet
서브넷은 VPC의 하위 단위로, VPC에 할당된 IP를 더 작은 단위로 분할한 개념이며, 중요한 사실은 하나의 서브넷이 반드시 하나의 가용 영역(AZ, Availability Zone) 안에 위치한다는 점이다.
가용 영역(AZ)은 AWS 리전 내에 물리적으로 분리된 데이터 센터로, 각 가용 영역은 독립적인 전력, 냉각 및 네트워크 연결을 갖추고 있어 고가용성을 제공한다.
- VPC: 10.0.0.0/16
- 서브넷 A: 10.0.1.0/24 (가용 영역: us-east-1a)
- 서브넷 B: 10.0.2.0/24 (가용 영역: us-east-1b)
위 예시에서 서브넷 A는 us-east-1a 가용 영역에 위치하고, 서브넷 B는 us-east-1b 가용 영역에 위치한다.
서브넷 A와 서브넷 B는 서로 다른 가용 영역에 위치하므로, 각 서브넷 내의 리소스는 해당 가용 영역 내에서만 동작하게 된다. 동일한 서브넷 내의 리소스들은 동일한 데이터 센터에서 동작하게 된다는 뜻이다.
여러 가용 영역에 서브넷을 분산 배치함으로써, 하나의 가용 영역에 장애가 발생하더라도 다른 가용 영역의 서브넷과 리소스는 영향을 받지 않도록 설계할 수 있는 것이다.
따라서, 서브넷은 논리적으로 IP 주소를 분리하는 개념이지만, 하나의 서브넷이 반드시 하나의 가용 영역(Availability Zone) 안에만 위치하게 함으로써 물리적으로도 분리된다고 볼 수 있다.
컴퓨터 20대를 수용할 수 있는 사무실을 서울에 배치할지, 부산에 배치할지 정하는 것이다.. 클라우드의 마법이다.
서브넷은 또한 외부에서의 접근 가능여부에 따라 두가지로 나뉜다.
- 퍼블릭 서브넷: 외부에서 인터넷을 통해 연결할 수 있는 서브넷
- 인터넷 게이트웨이(IGW)를 통해 외부의 인터넷과 연결되어 있음
- 안에 위치한 인스턴스에 퍼블릭 IP 부여 가능
- 웹서버, 어플리케이션 서버 등 유저에게 노출되어야 하는 인프라
- 프라이빗 서브넷: 외부에서 인터넷을 통해 연결할 수 없는 서브넷
- 외부 인터넷으로 경로가 없음
- 퍼블릭 IP 부여 불가능
- 데이터베이스, 로직 서버 등 외부에 노출 될 필요가 없는 인프라등에 사용
퍼블릭 서브넷은 인터넷 게이트웨이로 가는 경로가 있고, 프라이빗 서브넷은 그러한 경로가 아예 존재하지 않는다.
AWS Subnet의 IP개수
Subnet은 CIDR 블록을 사용하여 IP 주소를 지정할 수 있으며, AWS 서버에서 사용 가능한 IP 개수는 5개를 제외하고 계산해야 한다.
Subnet을 생성할때 AWS가 기본적으로 점유하는 IP가 있기때문인데, 해당 IP는 다음과 같다.
예: 10.0.0.0/24라면
- 10.0.0.0: 네트워크 어드레스
- 10.0.0.1: VPC Router
- 10.0.0.2: DNS Server
- 10.0.0.3: 미래에 사용을 위해 남겨 둠
- 10.0.0.255(마지막 번호): 네트워크 브로드캐스트 어드레스(단, 브로드캐스트는 지원하지 않음)
따라서, 총 사용 가능한 IP 개수는 256개에서 5개를 빼서 251개가된다.
Route Table
서브넷은 가용 영역에 위치하며 그 안에는 EC2와 RDS 등 다양한 자원이 포함되어 있어 네트워크 트래픽을 올바른 목적지로 라우팅해주어야 하는데,
라우터 테이블은 트래픽이 어디로 가야 할지를 알려주는 이정표로, VPC 생성 시 기본으로 제공된다.
라우터 테이블의 요청이 들어오면 가장 구체적인 목적지 목록에서 매칭하여 정보를 전달한다.
특히, IP 매칭 시 숫자가 가장 큰 것이 가장 구체적(CIDR Notation의 네트워크 주소 표기 bit가 가장큰)이며, 이들의 범위는 여러 서브넷 블록과 IP범위에 포함될 수 있다.
말로만 들으면 이해가 잘 되지 않으니 예시로 설명해자면
- 10.0.0.0/16 - local
- 0.0.0.0/0 - igw3402
위와 같은 route table이 있다면
10.0.1.23에 대한 요청은 10.0.0.0/16 에도 속할 수 있고, 0.0.0.0/0 에도 속할 수 있지만 10.0.0.0/16의 네트워크 주소 bit가 16으로 더 구체적이므로 local로 요청을 라우트 하게된다.
Internet Gateway
VPC가 외부의 인터넷과 통신할 수 있도록 경로를 만들어주는 리소스로, 기본적으로 확장성과 고가용성이 확보되어 있다.
- IPv4, IPv6 지원
- IPv4의 경우 NAT 역할
- Route Table에서 경로 설정 후에 접근 가능
- 무료
VPC 구조
그림을 보며 VPC 구조에 대해 이해해보자.
Q, Subnet A의 EC2에서 IP 8.8.8.8으로 요청을 보낸다면?
라우트 테이블에서 8.8.8.8의 경로는 10.0.0.0/16에 포함되지 않아 로컬로 갈 수 없으므로 해당 라우트 테이블에 속하지 않은 나머지 트래픽은 인터넷 게이트웨이, 즉, IGW로 전송된다.
Subnet A는 라우트 테이블에 의해서 인터넷 게이트웨이에 트래픽을 보낼 수 있고, 외부 인터넷과 통신이 가능해 보이므로 Public Subnet 이라고 유추해볼 수 있고,
그림에서 알 수 있듯이 트래픽이 인터넷 게이트로 들어갈 수 있는 라우트 테이블이 붙어 있는 서브넷을 퍼블릭 서브넷이라고 한다.
8.8.8.8 트래픽은 로컬이 아니므로 인터넷 게이트웨이로 보내야 하며, 이 인터넷 게이트웨이는 외부 퍼블릭 인터넷으로 트래픽을 전송한다.
인터넷 게이트웨이가 트래픽을 수신하여 원래 보낸 곳에 다시 응답을 보내며, 이는 NAT(네트워크 주소 변환)의 역할과도 유사하게 보인다.
출처
https://www.youtube.com/watch?v=WY2xoIClOFA