콘솔에서 AWS Client VPN 청구서를 추정하는 방법

AWS Client VPN 추정 절차: 연결을 세고, 세션 로그에서 연결 시간을 도출한 뒤 엔드포인트 요금 밖의 비용을 더합니다.

지난달 나는 스프레드시트로 Client VPN 견적을 만들고 고객에게 보낸 뒤 두 번 고쳤다—한 번은 연결 수를 서브넷 수로 곱했고, 또 한 번은 세션 데이터 대신 인원수를 썼기 때문이다. 검토를 통과한 버전은 두 개의 시간 미터와 짧은 부대 비용 목록에 기대고 있다. 콘솔과 로그 내보내기 한 번으로 요금 계산기 없이 다시 만들 수 있다.

두 개의 미터, 그리고 엔드포인트에는 다른 것이 없다

AWS는 Client VPN 엔드포인트를 연결-시간과 세션-시간으로 청구한다. 연결-시간은 엔드포인트에 붙은 모든 대상 네트워크에 대해 누가 접속하든 말든 하루 종일 흐른다. 세션-시간은 접속한 클라이언트마다 그 세션이 유지되는 동안 흐른다.

MeterWhat increments itWhat does not change it
Association-hoursEach associated subnet or Transit Gateway attachment, per hour, 24/7 while attachedNumber of users, traffic volume
Connection-hoursEach active client session, per hourHow many subnets that client can reach

그 표에서 두 가지 결과가 바로 나온다. 아무도 없는 엔드포인트도 비용이 들고, 한 사람이 노트북과 휴대폰을 동시에 쓰면 연결이 두 개 생긴다.

콘솔에서 연결을 세고, VPC의 서브넷은 세지 않는다

VPC를 열고, Client VPN endpoints, 내 엔드포인트, Associations 탭 순서로 간다. 그곳의 각 행이 서브넷 연결이고, 그 행 수가 연결 배수다. VPC 뒤에 있는 애플리케이션 서브넷 수와는 무관하다.

엔드포인트 경로와 승인 규칙이 목적지를 덮으면 연결 하나로 승인된 VPC 네트워크에 닿는다. 추가 연결은 추가 도달 범위가 아니라 가용 영역 장애에 대한 복원력을 산다. 따라서 두 AZ 설계는 연결-시간을 두 배로 만들고, 여덟 서브넷 애플리케이션 VPC는 무엇도 여덟 배로 만들지 않는다.

그 페이지에 있는 동안 연결 유형을 보라. VPC 서브넷 연결과 Transit Gateway 직접 연결은 청구 항목이 다른 별개 구성이므로 한 모델을 다른 쪽 견적에 옮기지 마라. 그리고 수를 확인하려고 무언가를 분리하지 마라—마지막 대상 네트워크를 제거하면 활성 세션이 종료되고, 다시 연결될 때까지 새 연결이 차단된다.

세션 데이터에서 연결-시간을 도출한다

인원수는 잘못된 입력이고 양방향으로 틀린다. 각자 기기 세 대를 연결해 두는 열 명은 서른 개 연결이다. 하루 이십 분씩 접속하는 백 명은 백 개 동시 세션과 거리가 멀다.

Client VPN 연결 로그는 클라이언트별 연결과 해제 이벤트를 기록하며, 그것이 바로 필요한 짝이다—대표적인 일주일을 내보내고 이벤트를 맞춘 뒤 시간을 합산한다.

connection-hours = sum of (disconnect_time - connect_time) per session
sessions         = one per client connection, not per person

그다음 두 가지 습관을 보정한다. 점심, 밤, 또는 터널을 끊지 않은 노트북 절전을 거쳐 연결된 채 남은 세션도 청구되며 인원 집계에서는 보이지 않는다. 계량은 한 시간 단위이므로 이십 분 세션은 비례 청구를 가정하지 말고 한 시간으로 예산하고, 청구서가 낮게 나오면 그것은 계획 입력이 아니라 여유로 보라.

자기 리전의 요금으로 계산한다

요금은 리전마다 다르므로 배포하는 리전의 AWS VPN 요금 페이지에서 가져와 입력으로 시트에 붙인다—예시로만, 연결 시간당 0.10달러와 연결-시간당 0.05달러를 잡고, 두 연결을 한 달 내내 유지하며 100명이 20영업일 동안 여섯 시간 접속하는 30일 한 달을 계산한다.

association-hours = 2 * 24 * 30     = 1,440
association fee   = 1,440 * 0.10    = 144.00

connection-hours  = 100 * 6 * 20    = 12,000
connection fee    = 12,000 * 0.05   = 600.00

Client VPN subtotal                 = 744.00

이제 입력을 하나씩 움직이며 어느 행이 반응하는지 본다. 연결을 두 배로 하면 여기서 144달러가 늘고, 평균 세션 길이를 두 배로 하면 600달러가 는다. 그 비율이 보통 설계 논쟁을 대신 정리해 준다—정당화할 수 없는 중복을 줄이거나 유휴 세션을 겨냥하라, 더 큰 숫자 쪽으로. 결과 옆에 리전과 요금 날짜를 적어라, 그것이 없으면 육 주 뒤에 견적을 재현할 수 없다.

소계가 빼놓은 비용을 더한다

엔드포인트 요금은 엔드포인트 몫이다. 그 뒤 트래픽이 닿는 모든 것에는 각자의 미터가 있고, 낙관적인 VPN 견적이 무너지는 곳이 바로 그 행들이다.

  • 엔드포인트로 나가는 트래픽의 인터넷 이그레스, GB당 청구.
  • 퍼블릭 IPv4 주소, VPN과 무관한 자체 시간 요금이 붙는다.
  • 방금 내보낸 연결 로그의 CloudWatch Logs 수집과 저장.
  • client-connect 핸들러를 돌린다면 Lambda 호출.
  • 사용자가 그렇게 인증한다면 Directory Service 또는 SAML 자격 증명 공급자, 거기서 인증서를 발급한다면 ACM Private CA 요금.
  • 경로가 사용할 때의 NAT Gateway 시간과 데이터 처리, Transit Gateway 연결 시간과 데이터 처리.

이 중 어느 것도 연결 수에 비례하지 않는다. 그래서 엔드포인트 요금만으로 짠 사용자당 숫자는 종이에서는 좋아 보이고 실제 트래픽이 생기면 커진다—추정해야 할 때도 별도 행에 두어 어디가 측정이고 어디가 추측인지 읽는 사람이 보게 하라.

보내기 전에 시트를 점검한다

네 가지 점검이 내가 실제로 한 실수를 잡는다. 연결 수가 Associations 탭과 정확히 일치하는가, 연결-시간이 인원수가 아니라 짝지은 로그 이벤트에서 왔는가, 리전과 요금 날짜가 적혀 있는가, 부대 비용마다 행이 있는가—넷 중 하나라도 빠지면 그것은 서식이 갖춰진 추측이다.

먼저 로그 내보내기를 받아라. 나중에 기억으로 재구성할 수 없는 유일한 입력이며, 첫 청구서가 오기 전에 유휴 세션 문제를 고칠 가치가 있는지도 알려 준다.

관련 글