วิธีประมาณใบเรียกเก็บเงิน AWS Client VPN จากคอนโซล
แนวทางประมาณ AWS Client VPN: นับการเชื่อมโยง ดึงชั่วโมงเชื่อมต่อจากบันทึกเซสชัน แล้วบวกค่าใช้จ่ายนอกเหนือจากค่าธรรมเนียม endpoint
เดือนที่แล้วผมสร้างการประมาณ Client VPN ในสเปรดชีต ส่งให้ลูกค้า แล้วแก้ไขสองครั้ง: ครั้งหนึ่งเพราะผมคูณจำนวนการเชื่อมโยงด้วยจำนวนซับเน็ต และอีกครั้งเพราะผมใช้จำนวนคนแทนข้อมูลเซสชัน เวอร์ชันที่ผ่านการตรวจสอบยืนอยู่บนมิเตอร์รายชั่วโมงสองตัวและรายการค่าใช้จ่ายข้างเคียงสั้น ๆ คุณสร้างใหม่ได้จากคอนโซลและการส่งออกบันทึกหนึ่งครั้ง โดยไม่ต้องใช้เครื่องคิดราคา
มิเตอร์สองตัว และไม่มีอะไรอื่นบน endpoint
AWS เรียกเก็บเงิน endpoint ของ Client VPN ตามชั่วโมงการเชื่อมโยงและชั่วโมงการเชื่อมต่อ ชั่วโมงการเชื่อมโยงเดินสำหรับทุกเครือข่ายเป้าหมายที่ผูกกับ endpoint ตลอดวันทั้งคืน ไม่ว่ามีใครเชื่อมต่อหรือไม่ ส่วนชั่วโมงการเชื่อมต่อเดินตามไคลเอนต์ที่เชื่อมต่อแต่ละราย ตราบใดที่เซสชันนั้นยังเปิดอยู่
| Meter | What increments it | What does not change it |
|---|---|---|
| Association-hours | Each associated subnet or Transit Gateway attachment, per hour, 24/7 while attached | Number of users, traffic volume |
| Connection-hours | Each active client session, per hour | How many subnets that client can reach |
ผลสองข้อตามมาจากตารางนั้นโดยตรง endpoint ที่ไม่มีใครอยู่ก็ยังมีค่าใช้จ่าย และคนเดียวที่ใช้แล็ปท็อปกับโทรศัพท์พร้อมกันทำให้เกิดสองการเชื่อมต่อ
นับการเชื่อมโยงในคอนโซล ไม่ใช่ซับเน็ตใน VPC
เปิด VPC ตามด้วย Client VPN endpoints ตามด้วย endpoint ของคุณ ตามด้วยแท็บ Associations แต่ละแถวที่นั่นคือการผูกซับเน็ต และจำนวนแถวนั้นคือตัวคูณการเชื่อมโยงของคุณ จำนวนซับเน็ตของแอปพลิเคชันที่อยู่หลัง VPC ไม่เกี่ยวข้องกัน
การเชื่อมโยงเดียวพอที่จะไปถึงเครือข่าย VPC ที่ได้รับอนุญาต เมื่อเส้นทางของ endpoint และกฎการอนุญาตครอบคลุมปลายทาง การเชื่อมโยงเพิ่มเติมซื้อ ความทนทานต่อโซนพร้อมใช้งานขัดข้อง ไม่ใช่การเข้าถึงเพิ่มเติม ดังนั้นการออกแบบสอง 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 ดอลลาร์ แล้วคำนวณเดือน 30 วันที่มีการเชื่อมโยงสองรายตลอดเดือนและ 100 คนเชื่อมต่อหกชั่วโมงใน 20 วันทำการ:
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 อัตราส่วนนั้นมักตัดสินข้อโต้แย้งด้านการออกแบบให้คุณ ตัดความซ้ำซ้อนที่คุณให้เหตุผลไม่ได้ หรือไปจัดการเซสชันที่ไม่ได้ใช้งาน ตามจำนวนที่มากกว่า เขียนภูมิภาคและวันที่ของอัตราไว้ข้างผลลัพธ์ เพราะใบเสนอราคาที่ไม่มีสิ่งเหล่านั้นไม่สามารถทำซ้ำได้ในอีกหกสัปดาห์
บวกค่าใช้จ่ายที่ยอดรวมย่อยละไว้
ค่าธรรมเนียม endpoint จ่ายให้ endpoint ทุกสิ่งที่ทราฟฟิกแตะหลังนั้นมีมิเตอร์ของตัวเอง และบนแถวเหล่านั้นเองที่การประมาณ VPN แบบมองโลกในแง่ดีแตกสลาย
- การออกอินเทอร์เน็ตสำหรับทราฟฟิกที่ออกผ่าน endpoint คิดเป็น GB
- ที่อยู่ IPv4 สาธารณะ ซึ่งมีค่าธรรมเนียมรายชั่วโมงของตัวเองโดยไม่ขึ้นกับ VPN
- การรับและจัดเก็บใน CloudWatch Logs สำหรับบันทึกการเชื่อมต่อที่คุณเพิ่งส่งออก
- การเรียกใช้ Lambda หากคุณรันตัวจัดการ client-connect
- Directory Service หรือผู้ให้บริการตัวตน SAML ของคุณ หากผู้ใช้ยืนยันตัวตนแบบนั้น พร้อมค่าธรรมเนียม ACM Private CA หากคุณออกใบรับรองที่นั่น
- ชั่วโมง NAT Gateway และการประมวลผลข้อมูล และชั่วโมงการผูก Transit Gateway พร้อมการประมวลผลข้อมูล ทุกครั้งที่เส้นทางใช้สิ่งเหล่านั้น
ไม่มีสิ่งใดในนี้ที่ขยายตามจำนวนการเชื่อมโยง ดังนั้นตัวเลขต่อผู้ใช้ที่ประกอบจากค่าธรรมเนียม endpoint เท่านั้นจึงดูดีบนกระดาษ แล้วโตขึ้นเมื่อทราฟฟิกจริงปรากฏ วางไว้ในแถวแยกแม้เมื่อคุณต้องประมาณ เพื่อให้ผู้อ่านเห็นว่าส่วนใดวัดได้และส่วนใดเป็นการคาดเดา
ตรวจสเปรดชีตก่อนส่ง
การตรวจสี่ข้อจับข้อผิดพลาดที่ผมทำจริง จำนวนการเชื่อมโยงตรงกับแท็บ Associations อย่างแม่นยำ ชั่วโมงเชื่อมต่อมาจากเหตุการณ์บันทึกที่จับคู่กันไม่ใช่จากการนับคน ภูมิภาคและวันที่ของอัตราถูกเขียนไว้ และค่าใช้จ่ายข้างเคียงแต่ละรายการมีแถวของตัวเอง หากขาดข้อใดข้อหนึ่งในสี่ข้อ คุณมีการคาดเดาที่จัดรูปแบบแล้ว
ดึงการส่งออกบันทึกก่อน เป็นอินพุตเดียวที่คุณไม่สามารถสร้างใหม่จากความจำได้ในภายหลัง และยังบอกด้วยว่าปัญหาเซสชันที่ไม่ได้ใช้งานคุ้มค่าที่จะแก้ก่อนใบเรียกเก็บเงินแรกมาถึงหรือไม่