Engineering Note

Appearance

VPC, Subnet, AZ 관계 정리 ​

0. 읽기전에 ​

  • CIDR 표기법, 데이터센터, 리전의 관계가 어떻게 되는지 이런 초보적인 내용은 다 안다고 가정하고 작성된 글 입니다.

1. VPC와 Subnet, AZ의 관계 ​

  • VPC는 Region 단위의 논리적인 네트워크이다.
  • Subnet은 VPC의 IP 대역을 나눈 단위이다.
  • AZ(Availability Zone)는 서로 독립된 물리 데이터센터이다.

가장 중요한 규칙은 다음과 같다.

하나의 Subnet은 반드시 하나의 AZ에만 속한다.

즉, 하나의 Subnet이 여러 AZ를 걸칠 수는 없다.

예시

Region

└── VPC (10.0.0.0/16)
    ├── Subnet 10.0.1.0/24 → AZ-a
    ├── Subnet 10.0.2.0/24 → AZ-b
    ├── Subnet 10.0.3.0/24 → AZ-c
    └── Subnet 10.0.4.0/24 → AZ-d

실무에서는 AZ마다 Public/Private Subnet을 하나씩 두는 구성이 일반적이다.

VPC 10.0.0.0/16

AZ-a
 ├── Public  10.0.1.0/24
 └── Private 10.0.11.0/24

AZ-b
 ├── Public  10.0.2.0/24
 └── Private 10.0.12.0/24

AZ-c
 ├── Public  10.0.3.0/24
 └── Private 10.0.13.0/24

2. VPC는 무엇인가? ​

처음에는 VPC가 "데이터센터를 초월하는 존재"처럼 느껴질 수 있다.

실제로도 개념적으로는 비슷하다.

다만 정확히는 Region 전체에 걸쳐 AWS가 제공하는 논리적인 L3 네트워크이다.

Region

├── AZ-a
│     └── Subnet
│
├── AZ-b
│     └── Subnet
│
├── AZ-c
│     └── Subnet
│
└── VPC
      ↑
      Region 전체를 하나의 네트워크처럼 묶는 논리적 네트워크

덕분에 서로 다른 AZ에 존재하는 EC2들도 같은 사설 IP로 자유롭게 통신할 수 있다.

개발자는 데이터센터가 다르다는 사실을 거의 의식하지 않아도 된다.

3. 같은 VPC 내부 통신 ​

예를 들어

10.0.1.10  → 10.0.2.20

VPC의 Route Table에는 기본적으로

10.0.0.0/16 → local

이라는 규칙이 존재한다.

즉,

10.0.0.0/16 대역은 VPC 내부에서 처리한다.

라는 의미이다.

4. 다른 VPC와 통신 ​

예를 들어

VPC-A 10.0.0.0/16

VPC-B 172.16.0.0/16

여기서

10.0.1.10 → 172.16.1.20

으로 패킷을 보내려면 두 VPC를 연결해야 한다.

대표적인 방법

  • VPC Peering
  • Transit Gateway
  • VPN
  • Direct Connect

VPC Peering ​

VPC-A
10.0.0.0/16

      │
      │ Peering
      │

VPC-B
172.16.0.0/16

Route Table에는

172.16.0.0/16 → Peering Connection

을 추가한다.

패킷은 그대로

Source      10.0.1.10
Destination 172.16.1.20

형태로 전달된다.

NAT은 발생하지 않는다.

Transit Gateway ​

  • 주로 TGW 를 많이 사용하는데, AWS 처럼 글로벌 CSP 에서는 자사 VPC Peering 이 지원되는데, 모든 회사가 AWS 를 쓸수 있는건 아니다.. 😭
  • VPC Peering
VPC-A
10.0.0.0/16
      │
      │
Transit Gateway
      │
      │
VPC-B
172.16.0.0/16
      │
VPC-C
192.168.0.0/16

각 VPC의 Route Table이 Transit Gateway를 바라보도록 설정하면 된다.

역시 패킷의 Source/Destination IP는 변경되지 않는다.

토막상식 : VPC Peering VS Transit Gateway ​

  • 두 컴포넌트가 기능은 유사한데, 서로 추구하는"모델" 이 다르다
    • VPC Peering : end-to-end 모델
      • 이동포털 : 각 목적지마다 딱 그곳만 갈수 있는 이동포탈 (정확히는 이동포털 "대역" 으로 분리)
    • Transit Gateway : Hub & Spoke 모델
      • 비유하자면 대중교통 통합 환승센터 : 여기서 알아서 환승해서 목적지 찾아가세요
항목VPC Peering (피어링)Transit Gateway (TGW)
네트워크 구조end-to-end 구조 (각각의 VPC를 개별적으로 1:1 연결)허브 앤 스포크(Hub & Spoke) (중앙의 TGW 허브에 모든 VPC를 연결)
전이적 라우팅 (Transitive)불가능 (A-B, B-C가 연결되어도 A-C는 통신 불가)가능 (TGW를 거쳐서 모든 VPC가 서로 자유롭게 통신)
확장성VPC가 많아질수록 연결선이 복잡해짐 (관리 포인트 급증)VPC가 아무리 많아도 TGW 하나로 깔끔하게 통합 관리
온프레미스 연동각 VPC마다 VPN이나 Direct Connect를 따로 연결해야 함TGW에 VPN/DX를 한 번만 연결하면 모든 VPC가 공유 가능
비용연결 자체는 무료 (VPC 간 이동하는 데이터 전송 비용만 발생)기본 요금 있음 (TGW 시간당 유지 비용 + 데이터 처리 요금)

5. 왜 VPC간 연결에서 IP가 겹치면 안될까? ​

  • VPC간 통신을 하더라도 IP가 겹치면 통신이 불가능하다
  • 예를 들어
VPC-A
10.0.0.0/16

VPC-B
10.0.0.0/16

이라면

  • 10.0.1.10 라는 주소는 어느 VPC에 있는 주소인지 라우터가 구분할 수 없다.
    • 마치 학교에 왔는데 이름이 "홍길동" 인 사람이 2명 (동명이인) 인데 선생님이 출석 부를때 "홍길동" 이라고 하면 어떤 홍길동인지 모르기때문
  • 그래서 VPC Peering과 Transit Gateway는 중복 CIDR을 허용하지 않는다. 그래서 실무에서는 처음부터 CIDR을 계획한다.
  • 사실 근데 멀쩡한 회사라면 VPC 를 하나만 두고 Subnet 으로 잘 쪼개서 사용한다

예시 : VPC 하나에서 서브넷 쪼개서 활용하기 ​

Prod   10.0.0.0/16
Dev    10.1.0.0/16
Stage  10.2.0.0/16
Shared 10.3.0.0/16
VPN IP

16비트를 마음대로 사용할 수 있습니다. ​

핵심 요약 ​

  • VPC는 Region 전체를 아우르는 논리적인 IP 네트워크
  • Subnet은 VPC를 나눈 IP 대역
  • 하나의 Subnet은 반드시 하나의 AZ에만 속함
  • 같은 VPC 내부는 local Route로 통신함
  • VPC 간 통신도 IP 기반이며, VPC Peering이나 Transit Gateway가 라우팅을 담당
  • VPC 간 CIDR이 겹치면 직접 연결할 수 없음