Tháng trước tôi dựng một bảng ước tính Client VPN trong bảng tính, gửi cho khách hàng rồi sửa hai lần: một lần vì tôi nhân số liên kết với số subnet, và một lần vì tôi dùng số người thay cho dữ liệu phiên. Bản sống sót qua đợt rà soát dựa trên hai đồng hồ theo giờ và một danh sách ngắn các khoản phụ. Bạn có thể dựng lại nó từ bảng điều khiển và một lần xuất nhật ký, không cần máy tính giá.

Hai đồng hồ, và không gì khác trên endpoint

AWS tính phí một endpoint Client VPN theo giờ liên kết và giờ kết nối. Giờ liên kết chạy cho mọi mạng đích gắn với endpoint, suốt ngày đêm, dù có ai kết nối hay không. Giờ kết nối chạy cho từng máy khách đã kết nối, chừng nào phiên đó còn mở.

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

Từ bảng đó rút ra hai hệ quả. Một endpoint không có ai vẫn tốn tiền, và một người dùng laptop lẫn điện thoại cùng lúc tạo ra hai kết nối.

Đếm liên kết trong bảng điều khiển, không phải subnet trong VPC

Mở VPC, rồi Client VPN endpoints, rồi endpoint của bạn, rồi thẻ Associations. Mỗi dòng ở đó là một lần gắn subnet, và số dòng đó chính là hệ số liên kết của bạn. Số subnet ứng dụng nằm sau VPC không liên quan gì.

Một liên kết là đủ để tới một mạng VPC được cấp quyền khi tuyến của endpoint và các quy tắc cấp quyền bao phủ đích. Các liên kết thêm mua khả năng chịu lỗi vùng khả dụng, không phải thêm phạm vi. Vì vậy thiết kế hai AZ nhân đôi giờ liên kết, còn một VPC ứng dụng tám subnet không nhân gì với tám.

Để ý loại liên kết khi còn ở trang đó. Liên kết subnet VPC và liên kết trực tiếp Transit Gateway là hai cách bố trí khác nhau với dòng phí khác nhau, nên đừng mang mô hình này sang báo giá của mô hình kia. Và đừng thử số lượng bằng cách tháo gỡ: gỡ mạng đích cuối cùng sẽ kết thúc các phiên đang hoạt động và chặn kết nối mới cho đến khi có thứ gì đó được liên kết lại.

Suy ra giờ kết nối từ dữ liệu phiên

Số người là đầu vào sai, và sai theo cả hai hướng. Mười người mỗi người giữ ba thiết bị kết nối là ba mươi kết nối. Một trăm người mỗi người kết nối hai mươi phút mỗi ngày không cho ra nổi một trăm phiên đồng thời.

Nhật ký kết nối Client VPN ghi lại sự kiện kết nối và ngắt kết nối cho từng máy khách, đúng cặp mà bạn cần. Xuất một tuần đại diện, ghép các sự kiện rồi cộng thời lượng:

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

Sau đó sửa hai thói quen. Những phiên bị bỏ kết nối qua bữa trưa, qua đêm hoặc qua lần ngủ của laptop mà không hề cắt đường hầm vẫn bị tính phí, và chúng vô hình trong phép đếm người. Cách tính cũng theo giờ, nên hãy dự trù một phiên hai mươi phút như một giờ trọn vẹn thay vì giả định tính phí theo tỷ lệ; nếu hóa đơn thấp hơn, hãy coi đó là biên lợi nhuận chứ không phải dữ liệu lập kế hoạch.

Tính toán với mức giá của vùng bạn dùng

Giá khác nhau theo vùng, nên lấy chúng từ trang giá AWS VPN cho vùng bạn triển khai và dán vào bảng tính làm đầu vào. Chỉ để minh họa, lấy mức giá liên kết 0.10 đô la mỗi giờ và mức giá giờ kết nối 0.05 đô la, rồi tính một tháng 30 ngày với hai liên kết giữ suốt tháng và 100 người kết nối sáu giờ trong 20 ngày làm việc:

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

Giờ hãy dịch chuyển từng đầu vào một và xem dòng nào phản ứng. Nhân đôi số liên kết thêm 144 đô la ở đây; nhân đôi độ dài phiên trung bình thêm 600. Tỷ lệ đó thường tự giải quyết cuộc tranh luận thiết kế cho bạn: cắt phần dư thừa không thể biện minh, hoặc nhắm vào các phiên nhàn rỗi, tùy con số nào lớn hơn. Ghi vùng và ngày áp giá bên cạnh kết quả, vì một báo giá thiếu chúng không thể tái lập sau sáu tuần.

Cộng các khoản mà tổng phụ bỏ sót

Phí endpoint trả cho endpoint. Mọi thứ lưu lượng chạm tới sau đó đều có đồng hồ riêng, và chính ở những dòng đó các ước tính VPN lạc quan đổ vỡ.

  • Lưu lượng ra internet cho dữ liệu đi qua endpoint, tính theo GB.
  • Địa chỉ IPv4 công cộng, mang phí theo giờ riêng độc lập với VPN.
  • Thu nhận và lưu trữ trên CloudWatch Logs cho nhật ký kết nối bạn vừa xuất.
  • Lệnh gọi Lambda nếu bạn chạy trình xử lý client-connect.
  • Directory Service hoặc nhà cung cấp danh tính SAML của bạn, nếu người dùng xác thực theo cách đó, cộng phí ACM Private CA nếu bạn cấp chứng chỉ ở đó.
  • Giờ NAT Gateway và xử lý dữ liệu, cùng giờ gắn Transit Gateway và xử lý dữ liệu, mỗi khi tuyến dùng chúng.

Không khoản nào trong số này lớn lên theo số liên kết, vì thế một con số trên mỗi người dùng chỉ ghép từ phí endpoint trông ổn trên giấy rồi tăng lên khi lưu lượng thật xuất hiện. Hãy đặt chúng ở dòng riêng kể cả khi phải ước tính, để người đọc thấy phần nào được đo và phần nào là phỏng đoán.

Kiểm tra bảng tính trước khi gửi

Bốn phép kiểm tra bắt được những lỗi tôi thực sự mắc: số liên kết khớp chính xác với thẻ Associations, giờ kết nối đến từ các sự kiện nhật ký đã ghép cặp chứ không phải phép đếm người, vùng và ngày áp giá được ghi lại, và mỗi khoản phụ có dòng riêng. Nếu thiếu bất kỳ điều nào trong bốn, bạn đang có một phỏng đoán được định dạng.

Hãy lấy bản xuất nhật ký trước. Đó là đầu vào duy nhất bạn không thể dựng lại từ trí nhớ về sau, và nó cũng cho biết liệu vấn đề phiên nhàn rỗi có đáng sửa trước khi hóa đơn đầu tiên tới hay không.

Bài viết liên quan