AWS VPC 물리서버 기준 통신 원리
해당 내용의 글을 보고 내용을 한번 정리해보았습니다. 이때 추가적으로 나오는 궁금한 사항들을 포함해서 이어서 정리해보았습니다.
핵심 전제 — 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 |