AWS VPC 물리서버 기준 통신 원리

2026. 6. 1. 20:42·Network

AWS VPC 물리서버 기준 통신 원리

https://gasidaseo.notion.site/AWS-VPC-1f7cdcb19a784e2b97fa73466d269053#a5da4600197f438ea28970580e348c09

해당 내용의 글을 보고 내용을 한번 정리해보았습니다. 이때 추가적으로 나오는 궁금한 사항들을 포함해서 이어서 정리해보았습니다.

 

핵심 전제 — AWS 네트워크 3대 원칙

1. 브로드캐스트/멀티캐스트 전면 차단

온프레미스에서는 모르는 MAC 주소를 찾기 위해 ffff:ffff:ffff로 브로드캐스트를 뿌린다.
AWS 데이터센터에는 수십만 고객의 EC2가 공존하므로 이를 허용하면 전체 망이 마비된다.

클라우드 3사 모두 동일: AWS(유니캐스트만), GCP(유니캐스트만), Azure(멀티캐스트/브로드캐스트 차단)

영향 받는 온프레미스 기술들 (클라우드에서 그대로 못 씀):

  • HSRP / VRRP (라우터 이중화)
  • Tomcat Clustering
  • Oracle WebLogic Clustering
    → 클라우드에서는 유니캐스트 기반 이중화로 대체 필요

2. 매핑 서버 (Mapping Service / SDN 컨트롤러)

브로드캐스트 없이 주소를 찾기 위한 AWS의 핵심 인프라.
전 세계 EC2의 주민등록 DB 역할:

보유 정보:
  VPC ID + 가상 IP + 가상 MAC + 물리 서버 실제 IP
  • 하이퍼바이저가 ARP 브로드캐스트를 가로채고 → 매핑 서버에 유니캐스트로 질의
  • 권한 없는 통신 차단: 매핑 서버가 보안 그룹(Security Group) / NACL 규칙을 검증(Validation)하여 허용되지 않은 트래픽 차단
  • 결과를 하이퍼바이저 매핑 캐시에 저장 → 이후 통신은 캐시 활용 (매핑 서버 재질의 불필요)

3. 오버레이 네트워크 (Overlay Network)

EC2가 보는 세계 (가상):          실제 물리 세계:
  src: 10.1.1.1 / aa11             src: 192.168.0.1
  dst: 10.1.1.2 / aa12      →      dst: 192.168.0.2
                                    (+ 가상 패킷 캡슐화)

EC2는 가상 IP/MAC만 보고, 하이퍼바이저가 물리 주소로 캡슐화(Encapsulation)하여 실제 전송.
수신 측 하이퍼바이저가 디캡슐화(Decapsulation)하여 EC2에 전달.

캡슐화 프로토콜: Geneve 또는 VXLAN (AWS 내부 구현)

ENI (Elastic Network Interface) — 가상 랜카드

EC2에 붙는 가상 네트워크 인터페이스.

EC2
 └── ENI (가상 랜카드)
       ├── 가상 IP (Private IP)
       ├── 가상 MAC
       ├── 보안 그룹 적용 지점  ← 패킷이 ENI를 통과할 때 SG 검사
       └── EIP 연결 가능
  • 보안 그룹은 ENI 단위로 적용됨
  • EC2에 ENI 여러 개 붙이기 가능 (멀티홈 구성)

1. 동일 VPC — 동일 서브넷 — EC2 간 통신

상황: 서로 다른 물리 서버에 있는 EC2-1(10.1.1.1) → EC2-2(10.1.1.2) 최초 통신

ARP 단계 (가상 ARP를 유니캐스트로 처리)

EC2-1
 → ARP Request 브로드캐스트 발송
    ↓
 하이퍼바이저가 가로챔 (브로드캐스트 외부 차단)
    ↓
 매핑 캐시 확인 → 없음
    ↓
 매핑 서버에 유니캐스트 질의
 ("vpcA의 10.1.1.2 MAC과 물리 서버 위치는?")
    ↓
 매핑 서버 응답: MAC=aa12, 물리서버=192.168.0.2
    ↓
 매핑 캐시에 저장
    ↓
 EC2-1에 가짜 ARP Response 전달 → aa12 학습 완료

실제 데이터 전송 단계 (캡슐화 통신)

EC2-1
 → ping 패킷 (src: 10.1.1.1/aa11, dst: 10.1.1.2/aa12)
    ↓
 하이퍼바이저: 매핑 캐시 조회 → 캡슐화
 [물리 헤더: src 192.168.0.1, dst 192.168.0.2]
 [VPC ID: vpcA]
 [가상 패킷: 10.1.1.1 → 10.1.1.2]
    ↓
 물리 스위치: FCS(CRC) 에러 검사 → 정상 패킷만 통과
    ↓
 물리서버(192.168.0.2) 도착
    ↓
 하이퍼바이저: 디캡슐화 → VPC ID 확인 → 보안 그룹 검증
    ↓
 EC2-2의 ENI에 최종 전달

FCS (Frame Check Sequence): 물리 장비(광케이블, 스위치) 통과 시 CRC 계산으로 비트 오류 검출.
오류 있으면 패킷 드롭. 물리 계층(L1/L2) 무결성 보장.

이후 통신: 매핑 캐시 활용 → 매핑 서버 재질의 없이 캡슐화 고속 통신 반복

2. 동일 VPC — 다른 서브넷 — EC2 간 통신

상황: 10.1.1.2(EC2-1) → 10.1.2.2(EC2-3) (다른 서브넷)

핵심 차이: L3 라우팅 필요

같은 서브넷은 L2(MAC)로 직접 통신 가능.
다른 서브넷은 라우터(L3)를 경유해야 한다.

EC2-1 (10.1.1.2)
 → 서브넷 마스크 계산: 목적지(10.1.2.2)는 다른 대역
 → 직접 ARP 하지 않고, 기본 게이트웨이(가상 라우터 10.1.1.1)로 전송
    ↓
 AWS 가상 라우터 수신
 → VPC 라우팅 테이블 확인:
   10.1.0.0/16 → Local (VPC 내부)
    ↓
 L2 헤더 변경 (라우터를 경유했으므로 MAC 주소 변경)
    ↓
 하이퍼바이저: 매핑 서버 조회 → EC2-3의 물리 서버(192.168.1.2) 확인
 → 캡슐화하여 물리망 전송
    ↓
 물리서버(192.168.1.2) 도착 → 디캡슐화 → EC2-3 전달

라우팅 테이블 기반 단번 이동: 라우터는 모든 곳을 탐색하지 않고 CIDR 이정표를 보고 목적지를 단번에 결정한다.

3. VPC → (Edge 장비) → 외부 통신

VPC 사설 대역을 벗어날 때는 AWS Edge 장비 (Blackfoot Edge Device)를 무조건 경유.
라우팅 테이블에 전용 가상 장치를 명시적으로 연결해야 통신 성립.

3.1 인터넷 게이트웨이 (IGW) → 일반 인터넷

EC2 (10.1.1.2)
 → 목적지 8.8.8.8
 → 라우팅 테이블: 0.0.0.0/0 → IGW
 → 하이퍼바이저: IGW(Edge 장비, 192.168.0.100)로 캡슐화 전송
    ↓
 IGW(Edge 장비)
 → 캡슐 제거 → VPC ID 검증
 → EC2의 사설 IP(10.1.1.2) → EIP(59.1.1.2)로 NAT 수행
 → 인터넷으로 발송

EIP(탄력적 IP)가 없으면: 인터넷 통신 불가. EC2에 EIP 또는 Public IP 할당 필수.

3.2 관리형 VPN (Virtual Private Gateway) → 온프레미스 본사

EC2 → 온프레미스 사설 대역(172.30.0.0/16)
 → 라우팅 테이블: 172.30.0.0/16 → VGW
 → Edge 장비에서 IPSec 암호화 터널링
 → 인터넷 공용망을 통해 본사 VPN 장비에 안전하게 전달

IPSec: 공용 인터넷을 통해 데이터를 암호화하여 마치 전용선처럼 안전하게 통신.

3.3 다이렉트 커넥트 (Direct Connect) → 본사 물리 전용선

  VPN Direct Connect
경로 인터넷 공용망 물리 전용선
보안 IPSec 암호화 전용선 자체가 격리
속도/안정성 인터넷 품질에 의존 보장된 대역폭
비용 저렴 고가

 

EC2 → 본사 전용선
 → Edge 장비에서 Q-in-Q VLAN 태깅 (이중 VLAN 헤더 추가)
 → AWS ↔ 기업 간 물리 광케이블 전용선으로 전송

3.4 게이트웨이 엔드포인트 → S3 / DynamoDB

EC2 → S3 버킷
 → 라우팅 테이블: S3 prefix list → Gateway Endpoint
 → Edge 장비: VPC Endpoint ID를 헤더에 추가
 → AWS 내부 백본망으로 고속 전달 (인터넷 미경유)

장점: 인터넷을 타지 않으므로 더 안전하고 빠름. NAT Gateway 비용 절감.

Gateway Endpoint vs Interface Endpoint 비교

Gateway Endpoint Interface Endpoint (PrivateLink)

대상 서비스 S3, DynamoDB만 나머지 모든 AWS 서비스
구현 방식 라우팅 테이블 기반, Edge 장비 경유 ENI로 VPC 안에 프라이빗 IP 생성
내부 처리 Edge 장비 + Endpoint ID 치환 Hyperplane 인스턴스 경유
비용 무료 시간당 + 데이터 전송 요금

Hyperplane: AWS가 만든 가상 라우팅 칩셋. Interface Endpoint, NAT Gateway, NLB 등의 내부 처리를 담당하는 AWS 내부 분산 시스템.

전체 흐름 요약

[같은 서브넷] EC2 → 하이퍼바이저 ARP 프록시 → 매핑 서버 → 캡슐화 → 물리망 → 디캡슐화 → EC2
[다른 서브넷] EC2 → 가상 라우터 → L2 헤더 교체 → 캡슐화 → 물리망 → EC2
[인터넷]      EC2 → IGW(Edge) → NAT(사설→공인 IP) → 인터넷
[VPN]         EC2 → VGW(Edge) → IPSec 암호화 → 인터넷 터널 → 본사
[전용선]      EC2 → DX(Edge) → Q-in-Q VLAN → 광케이블 → 본사
[S3/DynamoDB] EC2 → Gateway Endpoint(Edge) → AWS 백본 → S3
[기타 AWS 서비스] EC2 → Interface Endpoint(Hyperplane) → AWS 서비스

 

'Network' 카테고리의 다른 글

Docker란?  (0) 2026.06.01
진짜 공격인 줄 알았는데 우리가 만든 장애였다  (0) 2026.04.02
AWS SAA-CO3 합격 후기  (0) 2026.03.07
Terraform으로 EC2 관리하면서 겪은 AMI 필터링과 SSM 연결 이슈  (0) 2026.02.25
Kind 클러스터에서 SandboxChanged 에러 해결하기: systemd와 containerd의 갈등 해소  (1) 2026.01.20
'Network' 카테고리의 다른 글
  • Docker란?
  • 진짜 공격인 줄 알았는데 우리가 만든 장애였다
  • AWS SAA-CO3 합격 후기
  • Terraform으로 EC2 관리하면서 겪은 AMI 필터링과 SSM 연결 이슈
Ry-
Ry-
  • Ry-
    developer_Ryu
    Ry-
  • 전체
    오늘
    어제
    • 분류 전체보기 (97) N
      • AI (14)
      • DB (3)
      • Book (6)
      • Development Environment (2)
        • Mac (2)
      • Frontend (8)
        • Flutter (6)
        • React (1)
        • React-Native (1)
      • Backend (19)
        • Spring (14)
        • Java (1)
        • Node.js (4)
      • Computer Science (27)
        • PS (20)
        • CS (7)
      • Network (12)
      • 이것저것 (3) N
  • 블로그 메뉴

    • 링크

    • 공지사항

    • 인기 글

    • 태그

      오블완
      종만북
      java
      스프링
      Kakao
      mysql
      redis
      최대 힙
      database
      mongodb
      node.js
      chatgpt api
      aop
      몽고디비
      flutter
      구글 로그인
      백준
      티스토리챌린지
      Baekjoon
      BOGGLE
      spring
    • 최근 댓글

    • 최근 글

    • hELLO· Designed By정상우.v4.10.6
    Ry-
    AWS VPC 물리서버 기준 통신 원리
    상단으로

    티스토리툴바