🧠 AWS 네트워킹 물리 플랜 vs 기능 플랜: 시니어 아키텍트가 남들이 놓친 문제를 해결한다.

Source: Dev.to

소개

VPN 터널은 UP 상태입니다. TGW attachment가 존재합니다. BGP도 설정되었습니다. 그런데 ping이 도착하지 않습니다.

이 상황에 30분 이상 머물렀다면, 문제는 링크에 있지 않았을 가능성이 높습니다— 잘못된 플레인을 보고 있었기 때문입니다.

클라우드 연결 설계, 아키텍처 리뷰, 그리고 뛰어난 기술팀과의 대화에서 지속적으로 나타나는 혼동이 있습니다: 물리 플레인과 기능 플레인을 섞어버리는 것. 이것은 사소한 혼동이 아니라, 잘못된 설계 결정, 몇 시간 걸리는 트러블슈팅, 그리고 “작동한다…until it doesn’t” 하는 아키텍처의 근본 원인입니다.

이전 포스트에서는 VPC 패턴(허브‑스포크, 메쉬, 멀티‑계정)에 대해 이야기했습니다. 오늘은 더 깊이 들어갑니다. 네트워크가 어떻게 구축됐는지와 그 네트워크가 무엇을 할 수 있는지를 의식적으로 구분하고, 그 구분이 설계 방식을 어떻게 바꾸는지 살펴보겠습니다.

---

🔴 서문

비공식적인 대화에서는 어느 정도 허용될 수 있는 이 모호함이, 실제 운영에서는 설계를 무너뜨립니다.

팀이 “아키텍처가 동작한다”는 것에 대해 몇 주 동안 논쟁할 수 있습니다. 왜냐하면 팀의 절반은 물리 토폴로지를, 나머지 절반은 기능 흐름을 생각하고 있기 때문입니다. 두 그룹 모두 같은 다이어그램을 보지만, 도출되는 결론은 다릅니다.

이때 물리 플레인과 기능 플레인의 구분이 학문적인 차원을 넘어선 실질적인 문제가 됩니다.

---

🗺️ 두 플레인: 운영 정의

다이어그램을 그리기 전에, 실제로 우리가 사용하는 정의는 다음과 같습니다:

물리 플레인(또는 인프라 플레인)

AWS가 프로비저닝하는 구성 요소, 그 사이의 물리·논리 연결, 그리고 플랫폼이 강제하는 제약 조건을 말합니다. 여기에는 포트, VLAN, VIF, attachment, 인스턴스, 네트워크 인터페이스가 포함됩니다. 이는 사실이며, 선택이 아닙니다.

[Image: Diagrama del plano físico]

이 다이어그램은 거의 모든 인증 교육 과정이 충분히 명확히 설명하지 않는 점을 보여줍니다: VPC는 케이블이 연결된 것이 아닙니다. VPC가 가지고 있는 것은 route table에 종료 컴포넌트에서 전파된 라우트일 뿐입니다.

이 사실은 전이성, 연결 장애, 보안 정책 적용 위치에 대한 사고 방식을 완전히 바꿔줍니다.

기능 플레인(무엇이 무엇과 통신할 수 있는가)

결과적인 동작—상위 추상화 레이어입니다. 물리 엔드포인트가 아니라 허용된 통신 흐름을 기술합니다. “서버 A가 서버 B에 도달할 수 있나요?”에 대한 답이며, “터널이 어디서 끝나는가?”에 대한 답이 아닙니다.

문제는 물리 플레인의 사실을 기능 플레인의 결정처럼 다루거나 그 반대로 생각할 때 발생합니다.

함정은 여기서: 물리 플레인이 기능 플레인을 보장하지는 않습니다.

VGW가 VPC에 연결돼 있다고 해서 트래픽이 흐르는 것은 아닙니다. 다음이 필요합니다:

• 올바른 라우트가 전파된 route tables
• 트래픽을 허용하는 Security Groups와 NACLs
• 서비스가 관여한다면 IAM 정책
• (선택) 비대칭 라우팅 설계 등

[Image: Ejemplo de capas funcionales]

대부분의 연결 장애는 여기서 시작됩니다: 물리 링크는 살아있고, VGW가 attachment 되었으며, TGW도 연결돼 있지만, 어느 하나의 기능 레이어가 트래픽을 차단하고 있기 때문입니다.

---

🔌 구체적인 사례: VPN 및 Direct Connect

혼동이 가장 자주 나타나는 예시입니다.

누군가 AWS에서 Site‑to‑Site VPN을 프로비저닝하면 자연스러운 설명은 “내 데이터센터를 VPC에 연결했다”가 됩니다. 기능적으로는 맞지만, 물리적으로는 아닙니다.

실제로 일어난 일:

1. AWS가 Virtual Private Gateway (VGW) 를 생성합니다—VGW는 VPC를 위한 IPsec 터널 종료를 집계하는 관리형 엣지 컴포넌트입니다. 이는 서브넷 CIDR 안에 존재하지 않으며, VPC의 암묵적 라우팅 시스템에 논리적 target 으로 주입됩니다.
2. VGW가 VPC에 연결됩니다.
3. Route propagation 을 활성화하면 온프레미스 측 라우트가 서브넷 route tables 에 나타납니다.
4. 트래픽이 VGW로 들어오면 AWS가 내부적으로 인스턴스로 라우팅합니다.

VPC는 VPN을 ‘보지’ 못합니다. 라우트만 봅니다. 이 구분이 중요합니다.

Direct Connect 의 경우 한 단계가 더 추가됩니다: DX는 물리적으로 콜로케이션 위치에 종단됩니다. 그곳에서 Virtual Interface (VIF)—Private, Public, Transit 중 하나—가 VGW 혹은 TGW 에 연결됩니다. VIF가 물리 플레인에서 AWS 논리 플레인으로 넘어가는 객체입니다.

[Image: Flujo real de una conexión híbrida]

---

🚫 왜 VPN과 Peering은 전이적이지 않은가—그리고 왜 정확히 이해해야 하는가

플레인 혼동이 실제 설계 오류를 일으키는 지점입니다.

• VPC Peering 은 데이터 플레인 설계상 전이적이지 않으며, 임의의 제한 때문이 아니라 설계 자체 때문입니다. VPC A의 인스턴스가 VPC B를 거쳐 VPC C에 도달하려 하면, AWS 라우팅 인프라가 해당 트래픽을 버립니다. Peering은 구성된 페어 간 직접 라우트만 허용합니다.

• VPN 역시 전이적이지 않습니다. 여러 VGW/TGW 를 거치도록 하려면 route propagation 과 static routes 를 명시적으로 설정해야 합니다.

물리 플레인은 링크 존재만 보장하고, 기능 플레인은 라우트, 정책, 보안 제어를 통해 구축되어야 한다는 이해는 “모두 연결돼 있는데도 작동하지 않는다”는 상황을 방지합니다.

---

빠른 요약

구분을 명확히 하면 설계가 훨씬 예측 가능해집니다.

AWS N (하이퍼바이저 매핑 서비스) 가 패킷을 평가한다

Peering 의 캡슐화는 해당 VPC들 간 점‑대‑점 으로만 이루어지기 때문에, 데이터 플레인은 두 번째 Peering 홉을 재캡슐화하거나 체인화하는 것을 허용하지 않아 패킷 루프 를 방지합니다. 패킷은 원본에서 바로 폐기됩니다.

VPN도 마찬가지입니다: VGW 가 해당 VPC 안에서 종료됩니다. 다른 Peered VPC 로 재전송할 가시성이나 능력이 없습니다. VPN을 통해 들어온 트래픽은 오직 그 VPC 내부에서만 존재합니다.

하지만 이 제한은 물리 플레인(AWS 데이터 플레인)에 존재하고, 기능 플레인에는 없습니다.
핵심 포인트: VPC 안에 3계층 장비(예: 어플라이언스, NVA, IP 포워딩 가능한 인스턴스)를 두면, 그 장비가 트래픽을 받아 직접 전달할 수 있습니다. 이는 AWS 규칙을 위반하는 것이 아니라, 다른 플레인에서 동작하는 것입니다.

참고

Source/Destination Check 를 어플라이언스 ENI에서 비활성화해야 합니다. 그렇지 않으면 하이퍼바이저가 원본·목적지 IP가 ENI와 일치하지 않는 패킷을 폐기해 기능 플레인이 완전히 무너집니다. 이는 두 플레인이 어떻게 상호작용하는지 보여주는 대표적인 예입니다.

---

세 번째 다이어그램 — 물리 전이성 vs. 기능 전이성

아키텍처 설계에서 중요한 기술적 뉘앙스

특히 주목할 점: 허브‑스포크 아키텍처에서 TGW 는 물리 플레인을 해결합니다—VPC 간 및 온프레미스 간 라우팅을 중앙화하지만, 트래픽을 검사하지는 않습니다. 이를 위해서는 Security VPC 와 같은 별도 레이어가 필요합니다.