Summary

  • AWS Organizations 안에서 소유 계정이 서브넷을 공유하면 참여 계정은 그 안에 자신의 EC2, RDS, Redshift, Lambda 자원을 둘 수 있다. 참여자는 해당 앱 자원과 AWS가 지정한 가용 영역 간·피어링·인터넷 게이트웨이·Direct Connect 전송비를 낸다.
  • VPC 소유 계정에는 공유 VPC에서 쓰는 공인 IPv4와 NAT 게이트웨이, PrivateLink, 엔드포인트 등 중앙 네트워크 요금이 붙는다. 공유를 끊어도 참여자의 기존 자원은 계속 실행되며, 그 자원이 남아 있으면 소유자는 서브넷이나 VPC를 삭제할 수 없다.

같은 주소에 사는 두 개의 원가표

AWS는 한 계정이 VPC를 관리하고 같은 조직의 다른 계정들이 공유 서브넷에서 서비스를 실행하게 한다. 계정 분리는 접근 권한과 청구를 분리하는 수단이다. 하지만 분리는 서버 단위로 끝나지 않는다. AWS의 공유 VPC 청구 문서에서 EC2 인스턴스와 RDS 데이터베이스 같은 앱 자원은 참여자의 몫이다. 그 네트워크에서 쓰는 공인 IPv4 주소는 VPC 소유자의 몫이다. 서버를 소유한 팀의 보고서에서 주소 비용을 찾으려 하면 애초에 다른 장부를 뒤지는 셈이다.

데이터 전송도 양쪽으로 나뉜다. AWS는 참여자에게 가용 영역 간 전송, VPC 피어링, 인터넷 게이트웨이와 Direct Connect 게이트웨이 관련 전송 요금을 매긴다고 적는다. NAT 게이트웨이, 가상 프라이빗 게이트웨이, Transit Gateway, PrivateLink와 VPC 엔드포인트에 대한 해당 시간·처리·전송 요금은 소유자가 낸다. 앱 하나의 통신이 참여자 쪽 전송 항목과 소유자 쪽 게이트웨이 항목을 동시에 움직일 수 있다. 인스턴스 월간 비용만 줄였다고 서비스의 네트워크 원가가 줄었다고 말할 수 없는 이유다.

반대로 같은 가용 영역 안에서는 AZ ID가 같을 때 계정 소유와 관계없이 전송이 무료라고 AWS는 설명한다. 따라서 요금 변화를 읽을 때는 패킷이 어느 영역과 장치를 통과했는지 살펴야 한다. 공개 규칙만으로 특정 기업의 실제 비용을 산출할 수는 없다. 두 계정의 사용량과 경로가 있어야 청구서를 맞춰 볼 수 있다.

네트워크 열쇠는 누구 손에 있나

VPC 소유자가 서브넷, 라우팅 테이블, NAT 게이트웨이, 엔드포인트를 관리한다. 참여자는 자신이 만든 네트워크 인터페이스와 보안 그룹을 다룰 수 있지만 공유 서브넷의 NAT 게이트웨이를 생성하거나 삭제하거나 조회할 수 없다. 중앙 네트워크 팀이 장치를 바꾸고 그 비용도 받는 구조다. 문제는 참여 팀의 앱이 그 장치를 얼마나 쓰는지 자체 청구서만으로 파악하기 어렵다는 데 있다. 권한과 소비량을 한 표에 놓아야 내부 가격을 정할 수 있다.

공인 IPv4는 작은 항목처럼 보이지만 경계를 또렷하게 보여 준다. AWS의 일반 VPC 가격표에는 사용 중이거나 유휴 상태인 공인 IPv4가 주소당 시간당 미화 0.005달러로 적혀 있다. 초 단위로 계산하고 최소 60초를 청구한다. 공유 VPC 문서는 그곳에서 쓰는 공인 주소 비용을 소유자에게 배정한다. 주소 몇 개를 어느 참여자가 차지하는지 따로 기록하지 않으면 소유자만 늘어나는 총액을 본다. 특정 고객의 주소 수나 청구액을 보여 주는 공개 자료는 없다.

공유 종료 버튼은 철거 버튼이 아니다

소유자가 서브넷 공유를 중단하면 참여자는 새 자원을 만들 수 없다. 이미 배치한 자원은 계속 돌아가고 참여자는 그것을 수정하거나 삭제할 수 있다. 참여자의 자원이 남은 동안 소유자는 공유 서브넷이나 VPC를 삭제할 수 없다. 소유자가 네트워크를 통제하면서도 퇴거 일정은 혼자 결정하지 못하는 셈이다.

이 구조는 사내 거래 조건을 요구한다. 새 팀을 공유 서브넷에 들이기 전에 공인 주소와 공용 게이트웨이 비용을 어떻게 귀속할지, 사용량 기록은 누가 보관할지, 종료 때 누가 자원을 치울지 정해야 한다. 나중에 두 팀이 서로 다른 청구서를 들고 다투면 둘 다 숫자는 맞을 수 있다. 빠진 것은 공동의 비용 규칙이다.

자료 출처