[도서] Amazon VPC - 2장: VPC 네트워킹 구성 요소의 역할 분류

VPC라는 동네

AWS 공부를 하다 보면 VPC 구조가 처음엔 그냥 추상적인 개념들의 나열처럼 느껴진다. 근데 이걸 동네에 비유해서 설명하는 방식이 있는데, 읽고 나서 "아, 그렇구나" 싶었다.

비유는 이렇다. 우리 집은 인스턴스, 마을은 서브넷, 동네 전체는 VPC다. 집에서 나오는 패킷은 나, 초등학교와 중학교는 인스턴스와 통신할 대상 서비스, 그리고 도로가 통신이다. 같은 마을 안에 있는 초등학교에 가려면 굳이 큰 길을 건널 필요가 없다. 서브넷 내부 통신에는 별도 Route Table 설정이 필요 없다는 얘기랑 정확히 대응된다. 반면 중학교는 다른 동네에 있으니까 도로나 철도, 즉 VPC 피어링이나 전송 게이트웨이를 타야 한다.

이 비유가 그냥 재미있는 수준이 아니라, 실제로 AWS 동작 방식을 꽤 정확하게 반영하고 있어서 놀랐다. AWS에서는 local 라우팅으로 VPC 내부의 모든 통신이 된다. 다른 VPC로 넘어가려면 그때부터 연결 요소가 필요해지고, 서브넷 라우팅 등록도 따로 해줘야 한다.

 

VPC의 공간, 연결, 컴퓨팅

VPC를 처음 배울 때 제일 헷갈리는 게, 이것저것 개념이 너무 많이 나온다는 거다. Internet Gateway도 있고, Subnet도 있고, EC2도 있고. 근데 이걸 세 가지 역할로 분류하면 생각보다 깔끔하게 정리된다.

• 공간 요소: 서비스를 올려놓을 물리적(논리적) 공간. VPC와 Subnet이 여기 해당한다.
• 연결 요소: 공간 사이를 이어주는 도로 역할. VPC 피어링, 전송 게이트웨이 같은 것들.
• 컴퓨팅 요소: 연결을 활용해서 실제로 트래픽을 처리하는 서비스. EC2 인스턴스 같은 것들.

이 세 가지를 한 문장으로 묶으면 이렇게 된다. "공간을 만들고, 그 공간 사이에 네트워킹 연결을 구축하면 컴퓨팅 서비스가 통신할 수 있는 기반이 마련된다." 읽고 나서 굉장히 깔끔하다고 느꼈는데, 사실 AWS 콘솔에서 작업할 때 순서 자체가 이미 이렇게 흘러가더라. Subnet 먼저 만들고, 게이트웨이 붙이고, 그다음에 인스턴스 올리는 식으로.

서비스와 리소스

사소해 보이는데 생각보다 중요한 개념이 하나 있었다. AWS에서 말하는 서비스와 리소스의 차이다. 서비스는 AWS가 제공하는 기능 자체고, 리소스는 그 서비스 메뉴에서 실제로 생성한 개별 객체다. VPC 피어링 서비스를 쓴다고 하면 그게 서비스이고, 실제로 만들어진 피어링 연결 하나하나가 리소스인 거다.

객체 지향 언어에 비유하면 서비스가 클래스, 리소스가 인스턴스. 그냥 쓰다 보면 혼용하게 되는데, AWS 문서나 콘솔 UI에서 둘을 구분해서 표현하는 경우가 꽤 있어서, 이 차이를 모르면 맥락을 잘못 읽는 순간이 생긴다. 특히 비용 관련해서 Billing 메뉴 볼 때 리소스 단위로 과금되는 구조를 이해하는 데 이 구분이 도움된다.