vpc,igw,nat-gw, ec2, sg,eip 직접 구성 - 2(sequence diagram)

AWS 네트워크 트래픽 흐름 — 시나리오 15종 모음 (상세 해설)

My-VPC 실습 구성 기준. 각 시나리오는 시퀀스 다이어그램(mermaid) + 단계별 해설 + 핵심 포인트 + OSI 계층으로 정리.

구성 요약 (공통 전제)

• VPC My-VPC 10.9.0.0/16
• Public-subnet 10.9.1.0/24 (az-2d) → Public-RT(0.0.0.0/0 → IGW)
• Private-Subnet 10.9.2.0/24 (az-2c) → Private-RT(0.0.0.0/0 → NAT-GW)
• PublicEC2 10.9.1.44 / 공인 3.35.195.121, SG=Public-Web-SSH-SG (Bastion 겸용)
• Private-EC2 10.9.2.240 / 공인 없음, SG=Private-SSH-SG
• NAT GW 10.9.1.37 / EIP 13.209.158.80 (Public-subnet)
• IGW My-IGW, NACL My-VPC-ACL (현재 IN/OUT ALL ALLOW)

두 방화벽의 통과 순서 (가장 중요)

방향	1차 관문	2차 관문
인바운드(들어옴)	NACL (서브넷, Stateless)	SG (인스턴스, Stateful)
아웃바운드(나감)	SG (인스턴스, Stateful)	NACL (서브넷, Stateless)

시나리오 목록

#	시나리오	유형	핵심 계층
1	외부 → 웹서버 (HTTP 80)	성공	L3/L4/L7
2	Private-EC2 → 인터넷 (NAT)	성공	L3/L4
3	Bastion SSH (2단계)	성공	L7/L3
4	ping + DNS	성공	L3(ICMP)/L4(UDP)
5	같은 서브넷 통신	성공	L2/L4
6	서브넷 간 통신	성공	L3
7	HTTPS / TLS 핸드셰이크	심화	L4/L6/L7
8	TCP 3-way / 4-way	심화	L4
9	ARP	심화	L2
10	DHCP IP 할당	심화	L2/L3
11	외부 직접접속 차단	실패	L3/L4
12	NACL 아웃바운드 DENY	실패	L4
13	SG 인바운드 미허용	실패	L4
14	IGW 경로 누락	실패	L3
15	NAT GW 경로 누락	실패	L3

---

A. 성공 흐름

1. 외부 → 웹서버 (HTTP 80)

외부 클라이언트가 PublicEC2의 웹 서비스에 접속하는 가장 기본 흐름.

 

해설: 외부에서 들어올 때 IGW가 공인 IP를 사설 IP(10.9.1.44)로 변환합니다(인스턴스는 사설 IP만 인식). 이후 NACL(서브넷)→SG(인스턴스) 순으로 통과합니다. 응답은 반대로 SG→NACL을 거치며, SG는 Stateful이라 자동 허용되지만 NACL은 Stateless라 아웃바운드 임시포트(1024–65535) 허용이 필요합니다. 마지막에 IGW가 출발지를 공인 IP로 복원합니다.

핵심: NAT 변환은 IGW에서 / 인바운드 NACL→SG, 아웃바운드 SG→NACL (역순).

---

2. Private-EC2 → 인터넷 (NAT GW)

비공개 서버가 패키지 다운로드처럼 "내가 먼저 나가는" 통신을 하는 흐름.

 

 

해설: 출발지 IP 변환(SNAT)이 IGW가 아니라 NAT GW에서 일어나는 것이 1번과의 결정적 차이입니다. NAT GW는 연결 상태를 기억해 응답을 원래 사설 IP로 되돌립니다. 외부에서 먼저 시작하는 연결은 거부하므로(아웃바운드 전용), 비공개 서버는 외부로 나갈 수만 있고 노출되지 않습니다.

핵심: 변환 지점 = NAT GW / NAT GW는 단방향(아웃바운드 전용).

---

3. Bastion SSH (관리자 → PublicEC2 → Private-EC2)

비공개 서버에 안전하게 접속하기 위해 공개 서버를 점프 서버로 거치는 흐름.

해설: 1차는 외부→공개 서버(IGW 경유), 2차는 공개→비공개(VPC 내부 local 경로로 IGW·NAT 미경유, IP 변환 없음)입니다. Private-SSH-SG가 소스를 IP가 아닌 Public-Web-SSH-SG(보안 그룹) 로 지정했기에, 공개 서버에서 온 SSH만 허용됩니다.

핵심: 비공개 서버 접근은 반드시 Bastion 경유 / 2차 구간은 VPC 내부 통신.

---

4. ping + DNS

도메인 이름 해석(DNS) 후 도달성 확인(ping)을 하는 흐름. 프로토콜·계층 차이가 핵심.

해설: ping은 TCP가 아니라 ICMP(L3) 입니다. 그래서 HTTP(L4 TCP)가 열려 있어도 ICMP가 막히면 ping은 실패할 수 있습니다. DNS는 보통 UDP 53(L4) 을 씁니다. SG·NACL·NAT GW가 해당 프로토콜을 허용해야 하며, NAT GW는 TCP·UDP·ICMP를 모두 지원합니다.

핵심: ping=ICMP(L3), DNS=UDP(L4) / 프로토콜별 허용 필요.

---

5. 같은 서브넷 내 통신

동일 서브넷의 두 인스턴스 간 통신. NACL을 거치지 않는 점이 핵심.

해설: 같은 서브넷(브로드캐스트 도메인) 내 통신은 L2 스위칭으로 처리되어 VPC 라우터를 거치지 않고, NACL도 적용되지 않습니다(NACL은 서브넷 경계에서만 동작). 오직 인스턴스 단위 SG만 통제합니다.

핵심: 동일 서브넷 = NACL 미적용, SG만 통제.

---

6. 서브넷 간 통신 (Public ↔ Private 내부)

다른 서브넷의 인스턴스 간 통신(예: 웹 서버 → 내부 DB).

해설: 서브넷이 다르면 VPC 라우터의 local 경로로 전달되며, 출발 서브넷의 NACL(아웃바운드)과 도착 서브넷의 NACL(인바운드)을 각각 거칩니다. IGW·NAT는 거치지 않아 IP 변환이 없습니다.

핵심: 서브넷이 다르면 양쪽 NACL을 각각 통과.

---

B. 프로토콜·계층 심화

7. HTTPS / TLS 핸드셰이크

암호화 통신이 계층적으로 어떻게 수립되는지.

해설: 먼저 L4에서 TCP 연결을 맺고, 그 위에서 L6 TLS로 암호화를 협상(인증서로 서버 신원 확인 + 세션키 생성)한 뒤, 비로소 L7 HTTP 데이터가 암호화되어 오갑니다. 계층이 아래에서 위로 순서대로 쌓이는 전형적 예입니다.

핵심: L4 연결 → L6 암호화 → L7 데이터.

---

8. TCP 3-way / 4-way 핸드셰이크

연결형 프로토콜의 수립·종료 과정 (전송계층).

해설: 출발지(임시포트)·목적지(80) 포트로 프로세스를 구분하고, 시퀀스(seq)/확인(ack) 번호로 순서·신뢰성을 보장합니다. 앞선 시나리오들의 "연결 수립"은 모두 이 3-way가 내부에서 일어난 것입니다. NACL 아웃바운드가 막히면 2단계(SYN-ACK)에서 실패합니다(시나리오 12 참고).

핵심: 포트=프로세스 구분, seq/ack=신뢰성.

---

9. ARP (IP → MAC 해석)

같은 서브넷 내에서 L3 주소를 L2 주소로 변환.

해설: IP만으로는 실제 프레임을 보낼 수 없어, 같은 서브넷(브로드캐스트 도메인)에서 ARP로 대상의 MAC 주소를 알아냅니다. 결과는 ARP 캐시에 저장됩니다. 다른 서브넷으로 갈 때는 대상이 아니라 기본 게이트웨이(VPC 라우터)의 MAC을 찾습니다.

핵심: L3 IP → L2 MAC, 같은 서브넷 내에서만.

---

10. DHCP — 부팅 시 IP 자동 할당

인스턴스가 사설 IP를 받는 과정.

해설: 인스턴스는 IP를 스스로 정하지 않고 DHCP(DISCOVER→OFFER→REQUEST→ACK, 일명 DORA)로 받습니다. 이때 서브넷 마스크, 기본 게이트웨이(서브넷의 .1=VPC 라우터), DNS 서버 정보도 함께 받습니다.

핵심: 사설 IP는 DHCP로 자동 수령(DORA).

---

C. 실패·차단 사례 (왜 안 되는가)

11. 외부에서 Private-EC2 직접 접속 시도 (차단)

해설: ① 사설 IP는 인터넷에서 라우팅 불가, ② NAT GW의 EIP로 접근해도 NAT GW는 외부 시작 연결을 거부, ③ 설령 도달해도 Private-SSH-SG가 소스를 Public SG로 제한. 세 겹으로 막혀 외부 직접 접근이 불가능합니다.

핵심: 라우팅 불가 + NAT 단방향 + SG 소스 제한 = 3중 방어.

---

12. NACL 아웃바운드 DENY → 응답 차단

My-VPC-ACL을 아웃바운드 전체 거부로 연결했을 때.

 

해설: 인바운드는 통과하지만, NACL이 Stateless라 응답(아웃바운드)을 별도로 허용해야 합니다. 아웃바운드가 전부 거부면 SYN-ACK이 못 나가 TCP handshake가 2단계에서 실패 → 클라이언트는 timeout. 살리려면 아웃바운드에 임시포트(1024–65535) ALLOW가 필요합니다.

핵심: 막힌 원인은 인바운드가 아니라 Stateless NACL의 아웃바운드 미허용.

---

13. SG 인바운드 미허용 → 차단

해설: NACL(서브넷)을 통과해도 인스턴스 앞의 SG에서 막힙니다. SG는 허용 규칙만 가지므로 80 허용이 없으면 묵시적으로 거부됩니다. 2중 관문(NACL→SG) 중 어느 하나라도 막으면 통신 불가입니다.

핵심: NACL 통과 ≠ 접속 성공. SG에서도 허용돼야 함.

---

14. Public-RT에 IGW 경로 누락 → 차단

해설: 공인 IP가 할당돼 있어도, 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 없으면 패킷이 나갈 길이 없습니다. 즉 "퍼블릭 서브넷"의 조건은 공인 IP가 아니라 IGW로 향하는 경로입니다.

핵심: 공인 IP ≠ 퍼블릭. IGW 경로가 있어야 퍼블릭.

---

15. Private-RT에 NAT GW 경로 누락 → 차단

해설: NAT GW를 생성·EIP 부착까지 해도, Private-RT에 0.0.0.0/0 → NAT-GW 경로를 추가하지 않으면 비공개 서버는 여전히 인터넷에 못 나갑니다. NAT GW 생성과 라우팅 추가는 항상 짝으로 해야 합니다.

핵심: NAT GW 생성 ≠ 동작. Private-RT에 경로 추가 필수.

---

종합 정리 — 통신이 되려면 모두 충족해야 하는 체크리스트

1. 라우팅(L3): 출발 서브넷의 RT에 목적지로 가는 경로가 있는가? (local / IGW / NAT-GW)
2. NACL(L3/L4·Stateless): 인바운드·아웃바운드 양방향 규칙이 모두 허용인가? (임시포트 포함)
3. SG(L3/L4·Stateful): 인스턴스 인바운드 규칙에 해당 포트/소스가 허용인가?
4. 주소(L3): 외부 통신이면 공인 IP(직접) 또는 NAT(대리)가 있는가?
5. 프로토콜(L3/L4): TCP / UDP / ICMP 중 실제 쓰는 프로토콜이 위 모든 단계에서 허용인가?

하나라도 빠지면 통신이 실패하며, 실패 사례(11~15)는 각각 위 체크리스트의 한 항목이 빠진 경우입니다.