Showback vs Chargeback: คู่มือ FinOps 2…

อัปเดตเมื่อ: 28 พฤษภาคม 2026

FinOps Showback vs Chargeback คือสองโมเดลการจัดสรรต้นทุนคลาวด์ที่ต่างกันตรงผลกระทบทางการเงิน Showback แค่ "แสดง" ค่าใช้จ่ายให้ทีมเจ้าของเห็นเพื่อสร้างความตระหนัก ไม่มีการเรียกเก็บข้ามศูนย์ต้นทุน ส่วน Chargeback "เรียกเก็บ" จริงจากงบประมาณของทีมนั้น ๆ ผ่านระบบบัญชีภายใน บทความนี้สรุปวิธีเลือกโมเดลที่เหมาะกับองค์กรของคุณบน AWS, Azure และ GCP พร้อมแม่แบบการคำนวณ การจัดการต้นทุนร่วม (shared cost) และ playbook ขั้นตอนการ rollout จริงที่ผมใช้กับลูกค้าหลายราย (จากประสบการณ์ตรงในไทย ไม่ใช่ทฤษฎีจากตำรา)

Showback เหมาะกับองค์กรช่วง Crawl/Walk ของ FinOps Framework คือสร้างความรับผิดชอบโดยไม่กระทบงบประมาณ
Chargeback ต้องการระบบ tagging ที่ครอบคลุม ≥95% ของค่าใช้จ่าย และกระบวนการ dispute ที่ชัดเจน
ต้นทุนร่วม (shared cost) เช่น Transit Gateway, control plane, observability ควรปันส่วนด้วย proportional หรือ even-split ตามบริบท
RI/Savings Plans ต้อง amortize รายวันก่อนปันส่วน ไม่ใช้ค่า on-demand เพราะจะบิดเบือนต้นทุนจริง
AWS, Azure, GCP มี cost allocation tag, management group และ folder/label ต่างกัน เลือกโมเดลให้สอดคล้องโครงสร้างบัญชี
โมเดล Hybrid (Showback + selective Chargeback) เป็นเส้นทางที่ปลอดภัยที่สุดสำหรับองค์กรไทยส่วนใหญ่

Showback กับ Chargeback ต่างกันอย่างไร

คำตอบสั้นที่สุดคือ Showback เป็นการ "รายงาน" ส่วน Chargeback เป็นการ "เรียกเก็บ" แต่ในทางปฏิบัติทั้งสองโมเดลต่างกันที่ระดับวุฒิภาวะของ FinOps องค์กร โครงสร้างบัญชีภายใน และการยอมรับของผู้บริหารด้านการเงิน Showback ใช้แดชบอร์ดบอกทีมว่าเดือนนี้ใช้คลาวด์ไปเท่าไหร่ มีแนวโน้มอย่างไร และเปรียบเทียบกับ unit economics ของผลิตภัณฑ์ แต่งบประมาณ (budget code) ของทีมไม่ถูกหัก คนใช้คลาวด์ "เห็น" แต่ "ไม่จ่าย" จึงเหมาะกับช่วงสร้างวัฒนธรรม

Chargeback ตรงข้ามกัน. เมื่อสิ้นเดือนระบบจะ generate invoice ภายในที่หักจากศูนย์ต้นทุน (cost center) ของแต่ละ business unit เหมือนเป็นซัพพลายเออร์ภายใน ฝ่ายการเงินจะมองค่าคลาวด์เป็น OPEX ของทีมโดยตรง ทำให้ทีมที่ใช้มากต้องตอบคำถามผู้บริหารเอง โมเดลนี้สร้างแรงจูงใจในการ optimize ที่แข็งแกร่งกว่า แต่ก็เพิ่มภาระทาง process ต้องมี ledger, dispute window, และนโยบายปันส่วน shared cost ที่ผู้มีส่วนได้เสียทุกฝ่ายเห็นพ้อง การเปลี่ยนจาก Showback ไป Chargeback ในประสบการณ์ของผมใช้เวลาเฉลี่ย 6–9 เดือนหากเริ่มจากศูนย์ (เคยมีลูกค้ารายหนึ่งใช้เวลา 14 เดือนเพราะติดที่ ERP)

ในกรอบ FinOps Framework ของ FinOps Foundation ทั้งสองโมเดลอยู่ในโดเมน "Allocation" ของ Capability "Inform" ซึ่งเป็นพื้นฐานก่อนเข้าสู่ Optimize และ Operate ระยะถัดไป

ตารางเปรียบเทียบ Showback vs Chargeback

ตารางด้านล่างสรุปมิติที่ลูกค้าผม (CFO, FinOps lead, engineering manager) มักถามเปรียบเทียบเสมอ ก่อนตัดสินใจเลือกโมเดล. ผมเก็บมาจากสไลด์ที่ใช้พรีเซนต์จริง

มิติ	Showback	Chargeback
ผลกระทบงบประมาณ	ไม่มี (รายงานอย่างเดียว)	หักจากศูนย์ต้นทุนทีม
ระดับ tagging ที่ต้องการ	~80% ของค่าใช้จ่าย	≥95% และมี allocation rule สำหรับส่วนที่เหลือ
กระบวนการ dispute	ไม่จำเป็น	จำเป็น ต้องมี window 5–10 วันทำการ
ระยะเวลา implement	4–8 สัปดาห์	6–9 เดือน (รวมเปลี่ยน policy การเงิน)
วุฒิภาวะ FinOps ที่เหมาะ	Crawl, Walk	Walk ปลาย, Run
แรงจูงใจให้ optimize	ปานกลาง	สูง
ความซับซ้อนต่อทีมการเงิน	ต่ำ	สูง (ต้องมี internal billing ledger)
เหมาะกับองค์กรแบบ	Product-led, team autonomy ปานกลาง	BU-led, มี internal market clear

สังเกตว่า Showback "ถูกกว่า" ไม่ได้แปลว่าด้อยกว่า. หลายองค์กรระดับ enterprise ในไทยที่ผมทำงานด้วยใช้ Showback ถาวรเพราะการเปลี่ยนเป็น Chargeback ต้องแก้ระบบ ERP และ approval workflow ของฝ่ายการเงินซึ่งคุ้มค่าน้อยกว่าผลที่ได้

ควรเลือก Showback หรือ Chargeback ดี

คำตอบขึ้นกับสามปัจจัย: (1) วุฒิภาวะ FinOps ตาม FinOps Framework, (2) โครงสร้างบัญชีภายในและ ERP, (3) วัฒนธรรมความรับผิดชอบของ engineering team. ผมใช้ matrix ง่าย ๆ นี้กับลูกค้า ถ้าตอบ "ใช่" สามข้อขึ้นไปให้พิจารณา Chargeback มิฉะนั้นเริ่มจาก Showback ก่อน

มีระบบ tagging ครอบคลุม ≥90% ของค่าใช้จ่ายแล้วและมี automated enforcement
ฝ่ายการเงินมี cost center hierarchy ที่ map กับ business unit ได้ชัดเจน
มี FinOps team หรือ practitioner เต็มเวลาอย่างน้อย 1 คน
ผู้บริหาร engineering พร้อมรับผิดชอบงบประมาณคลาวด์เป็น OPEX ของทีม
มี unit economics ของผลิตภัณฑ์ที่ใช้ตัดสินใจราคาแล้ว

หากองค์กรอยู่ในช่วงเริ่มต้น คำแนะนำของผมคือเริ่มจาก Showback 6 เดือนเพื่อสร้างความไว้วางใจในข้อมูล. ถ้าเริ่ม Chargeback โดยที่ tagging ยังโหว่ ทีมเจ้าของค่าใช้จ่ายจะ dispute ทุกใบและกระบวนการจะพัง (ผมเคยเห็นมาแล้วสองที่ และทั้งสอง rollback ภายในไตรมาส). สิ่งสำคัญที่สุดในขั้นนี้คือคุณภาพข้อมูลของ กลยุทธ์การแท็กทรัพยากรคลาวด์ เพราะเป็นรากฐานของทั้งสองโมเดล

วิธี implement chargeback บนคลาวด์

การ implement chargeback ต้องผ่าน 6 ขั้นตอนเรียงตามลำดับนี้ ข้ามขั้นไม่ได้เพราะแต่ละขั้นเป็น prerequisite ของขั้นถัดไป. ผมเคยเห็นองค์กรพยายามข้ามขั้น 2 (tagging governance) เพื่อรีบไป production แล้ว rollback ภายในไตรมาส

กำหนด allocation hierarchy ตัดสินใจว่าจะ allocate ในระดับ Account, Subscription, Project หรือ Tag. ขอแนะนำให้ใช้ account/subscription/project เป็นชั้นบนสุด แล้ว tag เป็นชั้นย่อย เพื่อใช้ guard rail ของ provider ช่วย enforce
สร้าง tagging policy บังคับ mandatory tags อย่างน้อย 4 ตัว ได้แก่ cost-center, environment, application, owner และใช้ Service Control Policy (AWS) / Azure Policy / GCP Org Policy ปฏิเสธ resource ที่ไม่มี tag
ดึง billing data รายวัน export CUR (AWS), Cost Management exports (Azure), หรือ Billing Export to BigQuery (GCP) เก็บเป็น append-only เพื่อ audit
Amortize commitments กระจายค่า Reserved Instance, Savings Plans และ Committed Use Discount เป็นรายวันตามจริง อ่านเพิ่มเติมเรื่อง commitment discounts
คำนวณ shared cost ใช้ allocation rule (ด้านล่าง) สำหรับ untaggable resources
ส่ง invoice + dispute window generate invoice ภายในรายเดือน เปิด dispute window 7 วันทำการ ก่อน lock เข้าระบบ ERP

ตัวอย่าง SQL ที่ผมใช้คำนวณ chargeback รายเดือนจาก CUR ที่ load ลง Athena/BigQuery (เอามาจากโปรเจกต์จริงที่เพิ่งจบเมื่อไตรมาสที่แล้ว):

-- AWS CUR: chargeback by cost-center tag, amortized
SELECT
  COALESCE(resource_tags['user_cost_center'], 'UNALLOCATED') AS cost_center,
  COALESCE(resource_tags['user_application'], 'UNKNOWN')     AS application,
  product_product_name                                       AS service,
  SUM(line_item_unblended_cost)                              AS unblended_usd,
  SUM(savings_plan_savings_plan_effective_cost
      + reservation_effective_cost
      + CASE WHEN line_item_line_item_type = 'Usage'
             THEN line_item_unblended_cost ELSE 0 END)       AS amortized_usd
FROM aws_cur
WHERE bill_billing_period_start_date = DATE '2026-05-01'
GROUP BY 1,2,3
ORDER BY amortized_usd DESC;

หมายเหตุสำคัญ: คอลัมน์ amortized_usd เป็นค่าที่ควรใช้ chargeback ไม่ใช่ unblended_usd เพราะ unblended จะแสดงราคา on-demand เต็มซึ่งสูงกว่าจริงเมื่อมี Savings Plans. ผมเจอบั๊กนี้ตอน ship ระบบ chargeback ให้ลูกค้ารายแรก ตัวเลขสูงกว่า invoice จริง 27% ทีมการเงินจับได้พอดี

วิธีปันส่วนต้นทุนร่วม (Shared Cost)

ต้นทุนร่วมคือค่าใช้จ่ายที่ tag กับทีมใดทีมหนึ่งไม่ได้ เช่น Transit Gateway ที่ทุกทีมใช้, EKS control plane, Datadog license แบบ org-wide, NAT Gateway แบบ shared. มีสี่วิธีปันส่วนหลักที่ FinOps Foundation รับรอง เลือกตามบริบทของ resource นั้น ๆ ไม่ใช่ใช้วิธีเดียวกันหมด

Even split: แบ่งเท่ากันต่อทีม เหมาะกับบริการที่ทุกทีมได้ประโยชน์เท่ากัน เช่น single sign-on, GitHub Enterprise license
Proportional: แบ่งตามสัดส่วน direct cost ของทีมนั้น เช่น ทีม A ใช้ direct 60% ก็รับ shared 60% เหมาะกับ shared platform service
Usage-based: วัด consumption จริง (vCPU-hour, GB egress) แล้ว allocate ตามนั้น เหมาะกับ NAT Gateway, Transit Gateway ที่มี VPC Flow Log ระบุ source ได้ ดูรายละเอียดในคู่มือลดค่าเครือข่ายคลาวด์
Fixed allocation: กำหนดเปอร์เซ็นต์ตายตัวจาก business agreement เช่น Product A 40% / Product B 60% ใช้กับ legacy system ที่แยก usage ไม่ออก

หลักการที่ผมยึด (เรียนรู้จากการ dispute ที่ปวดหัวมาเยอะ): ถ้าทีมไม่สามารถ "ลด" ต้นทุนนั้นได้ด้วยการกระทำของตัวเอง อย่าใช้ usage-based ใช้ even หรือ fixed แทน เพราะ usage-based ที่ไม่มี control จะกลายเป็น "tax" ที่ทีมไม่สามารถจัดการได้และจะ dispute ทุกเดือน

ความต่างของ AWS, Azure, GCP ในการจัดสรรต้นทุน

ทั้งสาม hyperscaler มีโครงสร้างบัญชีและเครื่องมือต่างกันมาก ส่งผลโดยตรงต่อความง่ายของ chargeback. การเลือก allocation hierarchy ผิดในระดับ provider จะทำให้ต้องรื้อระบบใหม่ในปีถัดไป (ผมเคยเตือนลูกค้าแล้ว เขาไม่ฟัง สุดท้ายต้องทำใหม่)

AWS

ใช้ AWS Organizations + Linked Accounts เป็นชั้นบนสุดเสมอ เพราะบัญชีคือขอบเขต isolation และ billing ที่แข็งแกร่งที่สุด ใช้ Cost Allocation Tags (ต้อง activate manually ใน Billing Console) ประกอบกับ เอกสาร AWS Cost Allocation Tags สำหรับ tag dimension ในระดับลึก. source of truth คือ Cost and Usage Report (CUR) 2.0 ที่ export เป็น Parquet ลง S3 แล้ว query ผ่าน Athena

Azure

ใช้ Management Group → Subscription → Resource Group เป็นชั้น hierarchy native ของ Azure ไม่จำเป็นต้องพึ่ง tag เป็นชั้นหลัก ใช้ Azure Cost Allocation rules เพื่อย้ายต้นทุน shared service ระหว่าง subscription โดยอัตโนมัติ. ฟีเจอร์นี้ไม่มีใน AWS/GCP และเป็นเหตุผลที่หลายองค์กรไทยเลือก Azure สำหรับ chargeback model

GCP

ใช้ Organization → Folder → Project เป็น hierarchy โดย Project เป็นหน่วย billing ระดับล่างสุด ใช้ Labels (เทียบเท่า tag) สำหรับ sub-allocation. export Billing เป็น BigQuery รายวัน ตามแนวทางใน เอกสาร GCP Billing Export. query SQL บน BigQuery ที่ผมเขียนไว้ในส่วน chargeback ใช้กับ GCP ได้โดยตรง เพียงเปลี่ยน schema

โมเดล Hybrid และการ rollout แบบเป็นขั้น

ในความเป็นจริงองค์กรส่วนใหญ่ไม่ได้อยู่ที่ Showback หรือ Chargeback แบบ pure แต่ใช้ Hybrid ที่ Chargeback เฉพาะค่าใช้จ่ายที่ allocate ได้ชัด (production workload, dedicated infra) และ Showback สำหรับ shared/experimental workload. การ rollout ที่ผมเห็นได้ผลคือแบ่ง 4 phase ละ 3 เดือน รวม 12 เดือน

Phase 1, Visibility: สร้าง dashboard Showback ระดับ team สำหรับ direct cost รายวัน คุณภาพ tagging เป้าหมาย 70%
Phase 2, Accountability: เพิ่ม budget alert และ monthly review เป็นวาระประจำของ engineering leadership tagging 85%
Phase 3, Shadow Chargeback: ส่ง invoice จำลองรายเดือนที่ระบุ "ไม่หักเงินจริง" รับ dispute เพื่อปรับ allocation rule tagging 95%
Phase 4, Live Chargeback: เปิด chargeback จริงเฉพาะ direct cost ของ production ส่วน shared cost ยังคงเป็น Showback หรือใช้ fixed allocation

การ rollout แบบนี้ลดความเสี่ยงทางการเมืองภายในและเปิดโอกาสให้ทีมการเงินค่อย ๆ ปรับ ERP workflow โดยไม่ติดขัด. ตรงไปตรงมา ลูกค้าที่ขอเร่งเหลือ 6 เดือนทุกรายเจอปัญหาภายหลัง

ข้อผิดพลาดที่พบบ่อย

เก็บจากโปรเจกต์ที่ผมเข้าไปแก้ตามหลัง ข้อผิดพลาดเหล่านี้เกือบทั้งหมดสามารถป้องกันได้ด้วยการวางพื้นฐานในช่วง Showback ก่อนกระโดดเข้า Chargeback

ใช้ unblended cost แทน amortized ทำให้ chargeback สูงกว่าจริง 20–30% และทีมไม่ได้รับประโยชน์จาก commitment discount ที่ FinOps ซื้อให้
ไม่มี dispute window ทำให้ engineering ไม่ trust ข้อมูล และจะหา loophole เพื่อหลบ chargeback แทนการ optimize
Tagging ไม่ครอบคลุม data transfer และ NAT Gateway ซึ่งเป็น top 3 cost line ทั่วไป ทำให้ "UNALLOCATED" bucket ใหญ่จนเสีย credibility
เปลี่ยน allocation rule กลางเดือน ต้อง freeze rule ก่อนเริ่มเดือน ถ้าจำเป็นต้องแก้ให้บังคับใช้เดือนถัดไปเท่านั้น
ไม่รวม support cost และ marketplace subscription ทำให้ chargeback ไม่ตรงกับ AWS/Azure invoice จริง การเงินจะตั้งคำถาม
ไม่มี "FinOps service" charge แยก ทีม FinOps เองมีต้นทุน (tooling, license, headcount) ถ้าไม่ allocate ออกมาจะกลายเป็นหนี้ซ่อน

คำถามที่พบบ่อย

Showback คืออะไรในบริบทของ FinOps?

Showback คือการแสดงค่าใช้จ่ายคลาวด์ให้ทีมหรือ business unit เห็นโดยไม่หักจากงบประมาณของพวกเขา เป็นโมเดลที่ใช้สร้างความรับผิดชอบและความตระหนักรู้ในขั้นแรกของวุฒิภาวะ FinOps ก่อนจะพัฒนาเป็น Chargeback ในภายหลัง

Showback กับ Chargeback แบบไหนดีกว่ากัน?

ไม่มีคำตอบเดียว. Showback ดีกว่าสำหรับองค์กรช่วง Crawl/Walk ของ FinOps Framework ที่ tagging ยังไม่สมบูรณ์ ส่วน Chargeback ให้แรงจูงใจ optimize แข็งแกร่งกว่าแต่ต้องการ tagging ≥95% และ process การเงินที่พร้อม โมเดล Hybrid ที่ผสมทั้งสองมักเป็นทางเลือกที่ยั่งยืนที่สุด

การปันส่วนต้นทุนคลาวด์ร่วม (shared cost) ทำอย่างไร?

มี 4 วิธีหลัก คือ even split (แบ่งเท่ากัน), proportional (ตามสัดส่วน direct cost), usage-based (ตาม consumption จริงเช่น vCPU-hour, GB egress), และ fixed allocation (เปอร์เซ็นต์ตายตัว) เลือกตามว่าทีมสามารถ "ควบคุม" การใช้ทรัพยากรร่วมนั้นได้หรือไม่ ถ้าควบคุมไม่ได้ให้ใช้ even หรือ fixed

ต้องใช้ tagging coverage เท่าไหร่ถึงทำ Chargeback ได้?

มาตรฐานอุตสาหกรรมคือ ≥95% ของค่าใช้จ่ายทั้งหมดต้องมี mandatory tag ครบ และต้องมี allocation rule สำหรับ 5% ที่เหลือ ถ้าต่ำกว่านี้ "UNALLOCATED" bucket จะใหญ่จนทีมเริ่มไม่เชื่อตัวเลขและ dispute ทุกเดือน

ทำไมตัวเลข Chargeback ไม่ตรงกับ AWS Cost Explorer?

สาเหตุที่พบบ่อยที่สุดคือใช้ unblended cost แทน amortized cost ในระบบ chargeback และไม่นับ support charge หรือ marketplace subscription ใช้ CUR (Cost and Usage Report) เป็น source of truth เสมอ และ reconcile กับ Cost Explorer ทุกสิ้นเดือนเพื่อจับความต่าง