[도서] Amazon VPC - 1장: AWS 네트워킹 개념

AWS가 VPC를 만든 배경

클라우드의 슬로건은 늘 "빠르고 쉽게"였는데, 기업 입장에서는 그게 마냥 달갑지 않았던 것 같다. 대규모 컴퓨팅 자원을 클라우드로 옮기려면 기존에 온프레미스에서 쓰던 것처럼 프라이빗 전용 네트워크도 있어야 하고, 용도별로 구분된 소규모 공간도 있어야 하고, 방화벽이나 백본 라우터 같은 통신 장비도 필요하다. 서비스 접근 제어는 또 어떻게 하고. 근데 그냥 "필요할 때 쓰세요" 방식으로는 이런 걸 제공할 수가 없다.

그래서 AWS가 꺼낸 카드가 Amazon VPC다. 온프레미스 느낌을 최대한 살리면서, 클라우드답게 쉽게 관리할 수 있는 네트워크 플랫폼. 기존 환경을 최소한으로 바꾸면서 마이그레이션할 수도 있고, 아예 클라우드에 최적화된 구조로 새로 설계할 수도 있다. 어느 쪽이든 AWS가 지원하는 방향으로 설계된 것이다.

AWS 서비스를 네트워킹 기준으로 나누면?

AWS 전체 서비스를 VPC 사용 여부로 분류하면 두 갈래로 나뉜다. VPC 네트워킹 필수 서비스, 그리고 VPC 네트워킹 선택 가능 서비스. 전자는 EC2나 RDS처럼 반드시 VPC 안에 배치되는 것들이고, 후자는 Amazon Redshift처럼 VPC에 넣을 수도 있고 안 넣을 수도 있는 서비스들이다.

근데 이 두 유형을 가르는 기준이 있다. 네트워크 인터페이스, 정확히는 Elastic Network Interface(ENI)가 붙느냐 안 붙느냐다. A 유형 서비스는 ENI가 반드시 연결되고, B 유형은 사용자 선택에 따라 연결되거나 안 되거나 한다. 결국 ENI가 달려있으면 "이 서비스는 VPC 위에 있다"고 보면 된다.

VPC 네트워킹의 진짜 시작점은 네트워크 인터페이스

처음엔 그냥 "인스턴스를 서브넷에 넣으면 되는 거 아닌가" 싶었는데, 구조를 따라가 보면 순서가 명확하다. 네트워크 인터페이스가 보안 그룹을 전제로 하고, 그 네트워크 인터페이스는 서브넷 안에 있어야 생성된다. 서브넷은 VPC 안에 있어야 하고. 그러니까 인스턴스가 서브넷 공간에 놓인 것처럼 보이는 게 사실 네트워크 인터페이스의 존재를 생략해서 표현한 결과다. 네트워크 인터페이스 없이는 서브넷 자체에 존재할 수가 없다.

거기다 서브넷이 생성되는 순간 Route Table과 Network ACL이 자동으로 붙는다. 기본 라우팅 테이블, 기본 Network ACL이 연결되고, 필요하면 나중에 교체할 수 있다. 그래서 어떤 서비스든 네트워크 인터페이스를 달고 VPC 안에 들어오는 순간, 보안 그룹과 Network ACL, Route Table이라는 세 가지 통제 레이어가 자동으로 씌워지는 구조가 된다.

사실 이 흐름을 이해하고 나면 VPC 네트워킹 전체가 훨씬 단순하게 보인다. "ENI가 붙는다 = VPC 통제를 받는다"는 등식 하나로 AWS 서비스의 네트워크 위치를 판단할 수 있으니까. 리전에 네트워크 인터페이스가 하나도 없다면, 그 리전은 VPC 네트워킹을 전혀 쓰지 않는 것이고, 콘솔에서 서비스 > EC2 > 네트워크 인터페이스 목록을 보면 그게 바로 확인된다.