FinOps Unit Economics: คู่มือฉบับ 2026

Q: FinOps Unit Economics คืออะไรในประโยคเดียว?

คือการวัดต้นทุนคลาวด์ต่อหน่วยทางธุรกิจ เช่น ต่อลูกค้า ต่อ Transaction หรือต่อ Feature เพื่อเชื่อม Spend ของ AWS, Azure, GCP เข้ากับ KPI ของธุรกิจอย่างเป็นรูปธรรม

Q: ต้นทุนคลาวด์ต่อลูกค้าควรอยู่ที่เท่าไร?

ไม่มีตัวเลขเดียวที่ใช้ได้กับทุกธุรกิจ Benchmark ที่ใช้กันคือ Cloud Cost ควรอยู่ที่ 8-15% ของ Revenue สำหรับ SaaS ส่วนต้นทุนต่อ Customer ที่ "ดี" คือควรลดลงทุกไตรมาสตามที่ Scale ขึ้น ถ้าเพิ่มขึ้นแสดงว่า Architecture ไม่ Scale เชิงเศรษฐกิจ

Q: FOCUS Specification ต่างจาก AWS CUR อย่างไร?

FOCUS เป็นมาตรฐานเปิดที่กำหนด Schema กลางสำหรับ Billing Data จากทุก Cloud ส่วน CUR เป็น Format เฉพาะของ AWS FOCUS ทำให้รวมข้อมูล AWS, Azure, GCP ลง Schema เดียวได้โดยไม่ต้องทำ Field Mapping เอง

Q: จัดสรร Shared Cost อย่างไรให้ยุติธรรมที่สุด?

ใช้ Proportional Allocation ตาม Metric การใช้งานจริง เช่น Bytes Transferred, API Calls, หรือ Active Pods แล้วเสริมด้วย Catch-All Bucket สำหรับสิ่งที่ Allocate ไม่ได้ เป้าหมายคือลด Unallocated Cost ให้ต่ำกว่า 5%

Q: เครื่องมืออะไรเหมาะกับการเริ่มทำ Unit Economics?

สำหรับทีมเล็ก เริ่มที่ AWS CUR 2.0 + Athena + QuickSight หรือ Azure Cost Management + Power BI สำหรับทีมที่มี Data Warehouse แล้ว ใช้ dbt + Looker/Metabase ส่วน Kubernetes ใช้ OpenCost หรือ Kubecost

Q: ต้องใช้เวลานานแค่ไหนกว่าจะวัด Unit Cost ได้ครบ?

ในประสบการณ์ผม Phase 1 (วัด 1-2 Metric หลัก) ใช้เวลา 4-6 สัปดาห์ Phase 2 (ครอบคลุม 80% ของ Spend) ใช้ 3-6 เดือน Phase 3 (Unallocated < 5%, Forecasting) ใช้ 6-12 เดือน สำคัญที่สุดคือเริ่ม ไม่ใช่รอให้สมบูรณ์

อัปเดตล่าสุด: 27 พฤษภาคม 2026

FinOps Unit Economics คือการวัดต้นทุนคลาวด์ต่อหน่วยทางธุรกิจ เช่น ต้นทุนต่อลูกค้า ต่อ Transaction หรือต่อ Feature เพื่อเชื่อมตัวเลขบิลคลาวด์ AWS, Azure, GCP เข้ากับ KPI ของธุรกิจโดยตรง บทความนี้จะอธิบายวิธีคำนวณ Unit Cost ตั้งแต่ระดับ Cost and Usage Report (CUR) จนถึง Dashboard สำหรับ CFO พร้อมตัวอย่างสูตร SQL, การออกแบบ Tag Strategy และการเชื่อมต่อกับ FOCUS Specification เวอร์ชัน 1.2 ที่กลายเป็นมาตรฐานกลางของอุตสาหกรรมในปี 2026

Unit Economics คือสะพานเชื่อมระหว่างบิลคลาวด์รายเดือนกับตัวเลขทางธุรกิจ ทำให้ทีมวิศวกรรมและ CFO คุยภาษาเดียวกัน
เริ่มจากการกำหนด Unit ที่ชัดเจน 1-3 ตัว เช่น Cost per Tenant, Cost per 1,000 API Calls, Cost per GB Processed แล้วค่อยขยาย
FOCUS 1.2 ทำให้ข้อมูล Billing จาก AWS, Azure, GCP มี Schema เดียวกัน ลดเวลา ETL จากสัปดาห์เหลือชั่วโมง
ทีมที่ผมเคยทำงานด้วยลดต้นทุนต่อ Tenant ได้ 38% ภายใน 6 เดือน หลังเริ่มวัด Unit Cost รายสัปดาห์
Allocation 100% เป็นเป้าหมายที่ทำได้จริง โดยใช้ Shared Cost Allocation Rules และ Tag Inheritance
Dashboard ที่มีประสิทธิภาพต้องแสดง Trend, Outlier และ Forecast ไม่ใช่แค่ตัวเลขนิ่งๆ ของเดือนที่แล้ว

FinOps Unit Economics คืออะไร และทำไมถึงสำคัญในปี 2026

เอาตรงๆ ในประสบการณ์ผม ปัญหาที่ทำให้ FinOps ล้มเหลวในองค์กรไม่ใช่เพราะคนไม่อยากประหยัด แต่เพราะ CFO ถามว่า "ต้นทุนต่อลูกค้าหนึ่งคนเท่าไร" แล้วทีม Platform ตอบไม่ได้ (จริงๆ ผมเจอเหตุการณ์นี้กับลูกค้า 3 รายติดในปีที่แล้ว) Unit Economics ในบริบท FinOps คือการแปลตัวเลขดอลลาร์บนใบเสร็จ AWS, Azure, GCP ให้กลายเป็นตัวเลขที่ธุรกิจเข้าใจ เช่น "ต้นทุนคลาวด์ต่อ Active User คือ $0.42 ต่อเดือน" หรือ "ต้นทุนต่อคำสั่งซื้อหนึ่งรายการคือ $0.013"

FinOps Foundation ระบุไว้ใน FinOps Framework: Unit Economics Capability ว่า Unit Economics เป็นหนึ่งใน Capability ขั้น Run ซึ่งเป็นระดับสุดท้ายของ Maturity Model ทีมจะมาถึงจุดนี้ได้ต้องผ่านขั้น Inform (รู้ว่าใช้เท่าไร), Optimize (ลดได้เท่าไร) แล้วจึงเข้าสู่ขั้น Operate ที่ใช้ Unit Cost เป็น North Star Metric

ทำไมเรื่องนี้ระเบิดในปี 2026? คำตอบสั้นๆ คือ AI Workload ทีม ML ที่รัน Inference บน GPU ทำให้บิลพุ่งทะลุเพดาน ผู้บริหารเริ่มถามว่า "เราคืนทุนจาก Feature AI ใหม่นี้ได้เมื่อไร" คำตอบจะให้ได้ต่อเมื่อรู้ Cost per Inference Call และเชื่อมกับ Revenue per Customer ตรงนี้แหละครับที่การวัด Unit Cost เปลี่ยนสถานะจาก Nice-to-have มาเป็นข้อมูลที่ต้องส่งให้ Board ทุกไตรมาส

วิธีเลือก Unit Metric ที่เหมาะกับธุรกิจของคุณ

กับดักที่ผมเห็นบ่อยที่สุดคือ ทีมพยายามวัด Unit Cost ทั้ง 20 ตัวพร้อมกันตั้งแต่วันแรก สุดท้ายเลิกล้มเพราะข้อมูลไม่ครบ คำแนะนำของผมคือเริ่มจาก 1-3 ตัวที่สอดคล้องกับ Business Model จริงๆ

SaaS Multi-Tenant

ตัวที่ต้องวัดอันดับแรกคือ Cost per Tenant และ Cost per Monthly Active User (MAU) ถ้าโมเดลคิดเงินตาม Seat ให้เพิ่ม Cost per Paid Seat

ตัวอย่างจริงที่ผมเจอ บริษัท B2B SaaS แห่งหนึ่ง พอเริ่มวัด ก็พบว่า Top 10 Tenant กิน 67% ของต้นทุนคลาวด์ แต่จ่ายแค่ 28% ของ MRR เพราะอยู่ใน Free Trial ที่ไม่ Cap การใช้งาน หลังจาก Cap Free Tier และเปลี่ยน Pricing Plan ลดต้นทุนต่อ Tenant ลงได้ 38% (ใช้เวลาประมาณ 6 เดือน ไม่ใช่ Magic Bullet)

E-commerce

วัด Cost per Order, Cost per Cart Session, และ Cost per Search Query ตัวสุดท้ายสำคัญมากเพราะ Search Service มักใช้ Elasticsearch หรือ OpenSearch ที่กินทรัพยากรหนัก แยกออกมาแล้วจะเห็น ROI ชัดเจน

AI/ML Product

วัด Cost per Inference, Cost per Training Run, และ Cost per Token สำหรับ LLM ตัวเลข Cost per Token ในปี 2026 เป็นมาตรฐานใหม่ที่ทุกคนใช้เทียบ Self-hosted Model กับ API ของ OpenAI หรือ Anthropic ถ้ายังไม่ได้วัด ถือว่าคุณ Blind ในเกมนี้ครับ

วิธีคำนวณต้นทุนคลาวด์ต่อลูกค้า (Cost per Customer)

การคำนวณ Cost per Customer ในระบบ Multi-Tenant แบ่งเป็น 3 ประเภทตามรูปแบบการ Allocation

1. Direct Cost: ทรัพยากรเฉพาะลูกค้า

คือทรัพยากรที่ Provision ให้ Tenant คนเดียว เช่น Dedicated Database, Single-tenant Cluster วิธีระบุง่ายที่สุดคือใช้ Tag tenant_id ติดทุก Resource แล้ว Query จาก Cost and Usage Report (CUR) ของ AWS หรือเทียบเท่า บทความ กลยุทธ์การแท็กทรัพยากรคลาวด์ ที่ผมเขียนไว้ก่อนหน้านี้ ถือเป็น Prerequisite ของขั้นนี้

-- ตัวอย่าง SQL บน Athena / AWS Cost and Usage Report (CUR 2.0)
SELECT
    resource_tags['tenant_id']         AS tenant_id,
    DATE_TRUNC('month', line_item_usage_start_date) AS billing_month,
    SUM(line_item_unblended_cost)      AS direct_cost_usd
FROM   cur2_database.cur2_table
WHERE  line_item_usage_start_date >= DATE '2026-05-01'
  AND  resource_tags['tenant_id'] IS NOT NULL
GROUP BY 1, 2
ORDER BY direct_cost_usd DESC;

2. Shared Cost: ทรัพยากรร่วม

คือ Resource ที่หลาย Tenant ใช้ร่วมกัน เช่น Shared RDS, Load Balancer, NAT Gateway วิธีจัดสรรมี 3 แบบหลัก คือ Even Split (หารเท่า), Proportional (หารตามสัดส่วนการใช้งาน), และ Custom Driver (หารตาม Metric ที่กำหนด เช่น จำนวน API Call) ผมแนะนำ Proportional ถ้ามี Metric ใช้งานต่อ Tenant อยู่แล้ว เพราะสะท้อนความเป็นจริงมากที่สุด

3. Indirect Cost: Platform Overhead

คือต้นทุนที่ไม่เกี่ยวกับ Tenant โดยตรง เช่น CI/CD Pipeline, Monitoring Stack, Development Environment ส่วนนี้ควรกระจายเป็น "Platform Tax" บวกเข้าทุก Tenant แบบเท่าๆ กันหรือตาม Revenue เพื่อให้ Unit Cost สะท้อนต้นทุนแท้จริง

สูตรรวม Cost per Customer ในเดือนหนึ่งจึงเป็น

CostPerTenant = DirectCost(tenant)
              + (SharedCost × UsageShare(tenant))
              + (PlatformTax / TenantCount)

FOCUS Specification 1.2 มาตรฐาน Billing ข้ามคลาวด์

FOCUS (FinOps Open Cost and Usage Specification) คือมาตรฐานเปิดที่กำหนด Schema กลางสำหรับข้อมูล Billing จากทุก Cloud Provider เวอร์ชัน 1.2 ที่ปล่อยต้นปี 2026 เพิ่มฟิลด์สำคัญสำหรับ Unit Economics โดยเฉพาะ ดูรายละเอียดได้ที่ เว็บไซต์ทางการของ FOCUS Specification

ก่อน FOCUS ทีม FinOps ต้อง Map Field กันเอง เช่น AWS เรียก line_item_unblended_cost แต่ Azure เรียก CostInBillingCurrency และ GCP เรียก cost การทำ Multi-cloud Unit Economics จึงต้องเขียน ETL หลักหลายร้อยบรรทัด FOCUS แก้ปัญหานี้โดยกำหนดคอลัมน์มาตรฐาน เช่น

BilledCost: ต้นทุนที่อยู่บนใบเสร็จจริง
EffectiveCost: ต้นทุน Amortized ที่รวม Reserved Instance, Savings Plans แล้ว
ServiceCategory: หมวดบริการมาตรฐาน เช่น Compute, Storage, AI and Machine Learning
ResourceId, ResourceType: ระบุทรัพยากรแบบข้ามคลาวด์
Tags: Map ของ Tag ที่ Normalize แล้ว

AWS, Azure, GCP ทั้งสามรายรองรับ FOCUS แบบ Native ในปี 2026 โดย AWS ทำผ่าน Data Exports, Azure ผ่าน Cost Management Exports, ส่วน GCP ทำผ่าน BigQuery Billing Export Schema ใหม่ ทีมที่ผมที่ปรึกษาให้ลดเวลา ETL ข้ามคลาวด์จาก 3 สัปดาห์เหลือ 4 ชั่วโมง หลังเปลี่ยนมาใช้ FOCUS Schema (ผมก็ตกใจเหมือนกันว่ามันเร็วขนาดนั้น)

การจัดสรร Shared Cost และ Unallocated Spend

Pain Point ที่ผมเจอตลอดคือ "Unallocated Cost" หรือเงินที่จ่ายไปแต่ไม่รู้ว่าของใคร เป้าหมายของ FinOps Mature คือลด Unallocated Cost ให้เหลือต่ำกว่า 5% ของบิลทั้งหมด แต่ถ้ายังอยู่ที่ 30-40% Unit Cost ที่คำนวณออกมาจะหลอกตัวเอง

3 ขั้นตอนลด Unallocated Spend

Tag Coverage Audit: ใช้ AWS Cost Allocation Tag Report หรือ Azure Tag Inheritance Policy ตรวจว่า Resource ใดไม่มี Tag tenant_id หรือ cost_center ถ้าหลุดเกิน 10% ให้ทำ Tag Enforcement ด้วย AWS Tag Policies หรือ Azure Policy
Shared Cost Allocation Rules: ตั้ง Rule กระจาย Shared Cost เช่น "NAT Gateway แบ่งตามสัดส่วน VPC Flow Log Bytes ต่อ Tenant" หรือ "RDS Shared แบ่งตาม Query Count ต่อ Schema"
Catch-All Bucket: สิ่งที่ Allocate ไม่ได้จริงๆ ให้ใส่ Bucket "Platform" และทำให้ Visible เพื่อให้ทีมรู้ว่าต้องลด ไม่ใช่ซ่อน

การตรวจจับ Spike ที่ทำให้ Unit Cost พุ่งฉับพลันก็สำคัญไม่แพ้กัน ผมแนะนำให้อ่าน Cloud Cost Anomaly Detection 2026 ควบคู่ไปด้วย เพราะ Unit Cost ที่ผันผวนโดยไม่ทราบสาเหตุ มักมาจาก Anomaly ที่ไม่ได้แจ้งเตือน

สร้าง Dashboard Unit Economics ที่ใช้งานได้จริง

Dashboard ที่ผมพบว่าได้ผลในองค์กรจริงต้องมี 4 ชั้น ไม่ใช่แค่ตัวเลข Cost per Customer ลอยๆ

ชั้น	ตัวอย่างกราฟ	ผู้ใช้หลัก	ความถี่ของการดู
Executive Summary	Cost per Tenant Trend, Gross Margin per Customer	CFO, VP Eng	รายสัปดาห์
Service Breakdown	Cost per Customer แยกตาม Service Category (Compute, Storage, AI)	Engineering Manager	รายสัปดาห์
Tenant Drill-down	Top 20 Tenant by Cost, Outlier Detection	Customer Success, FinOps	รายวัน
Forecast and Anomaly	30-day Forecast Cost per Unit, Spike Alerts	FinOps Team, On-call	Real-time

Stack เทคโนโลยีที่แนะนำในปี 2026

สำหรับ Data Pipeline ผมแนะนำ Pattern นี้: Export FOCUS Data จากทุก Cloud ลง Object Storage (S3, ADLS Gen2, GCS), โหลดเข้า Data Warehouse (Snowflake, BigQuery, Databricks), ทำ Modeling ด้วย dbt, แล้ว Visualize ด้วย Looker, Metabase, หรือ Cube.dev

สำหรับ Workload ขนาดเล็ก-กลาง (บิล < $50K/เดือน) ใช้ AWS CUR 2.0 + Athena + QuickSight ก็เพียงพอ ไม่ต้องลง Stack ใหญ่ ผมเคยเห็นทีม 5 คนสร้าง Unit Economics Dashboard ใน 2 สัปดาห์ด้วย Stack นี้ (ทำได้จริง ผมตามดูใกล้ๆ)

# ตัวอย่าง dbt Model สำหรับ Cost per Tenant แบบ Multi-cloud
# models/marts/finops/fct_cost_per_tenant.sql

{{ config(materialized='incremental', unique_key=['tenant_id', 'billing_date']) }}

WITH focus_unified AS (
    SELECT * FROM {{ ref('stg_aws_focus') }}
    UNION ALL
    SELECT * FROM {{ ref('stg_azure_focus') }}
    UNION ALL
    SELECT * FROM {{ ref('stg_gcp_focus') }}
),
direct AS (
    SELECT
        tags['tenant_id'] AS tenant_id,
        DATE(billing_period_start) AS billing_date,
        SUM(effective_cost) AS direct_cost_usd
    FROM focus_unified
    WHERE tags['tenant_id'] IS NOT NULL
    GROUP BY 1, 2
),
shared AS (
    SELECT
        DATE(billing_period_start) AS billing_date,
        SUM(effective_cost) AS shared_cost_usd
    FROM focus_unified
    WHERE tags['tenant_id'] IS NULL
      AND service_category IN ('Networking', 'Storage')
    GROUP BY 1
),
usage AS (
    SELECT tenant_id, billing_date, api_calls
    FROM {{ ref('fct_tenant_usage') }}
)
SELECT
    d.tenant_id,
    d.billing_date,
    d.direct_cost_usd,
    s.shared_cost_usd * (u.api_calls / SUM(u.api_calls) OVER (PARTITION BY d.billing_date)) AS allocated_shared,
    d.direct_cost_usd + (s.shared_cost_usd * (u.api_calls / SUM(u.api_calls) OVER (PARTITION BY d.billing_date))) AS total_cost_per_tenant_usd
FROM direct d
JOIN shared s USING (billing_date)
JOIN usage  u USING (tenant_id, billing_date)
{% if is_incremental() %}
WHERE d.billing_date > (SELECT MAX(billing_date) FROM {{ this }})
{% endif %}

หลุมพรางที่พบบ่อยและวิธีหลีกเลี่ยง

หลังทำ FinOps มาหลายปี ผมรวบรวมข้อผิดพลาดที่เห็นซ้ำๆ ในทีมต่างๆ ดังนี้

1. วัด Unit ที่เปลี่ยนนิยามตลอด

เช่น เปลี่ยนวิธีนับ "Active User" จาก Login รายเดือนเป็น API Call กราฟ Unit Cost จะดูเหมือนลดลงทันที 60% โดยไม่ได้ลดต้นทุนจริง วิธีกัน คือ Lock นิยามไว้เป็นเอกสาร และเปลี่ยนเฉพาะตอนเริ่ม Fiscal Year เท่านั้น

2. ไม่รวม Cost ของ Egress และ Data Transfer

ค่า Data Transfer มักโผล่บน CUR แบบไม่มี Tag เพราะเป็น Network-level Cost ทีมที่ไม่ Allocate ส่วนนี้จะคำนวณ Unit Cost ต่ำกว่าจริง 15-25% สำหรับ Workload ที่ Heavy เรื่อง Data (ผมเจอ Case หนึ่งที่ลืมตัวนี้แล้วรายงานผิดไปทั้งไตรมาส)

3. ใช้ Cost รายเดือนเดียวตัดสินใจ

เดือนกุมภาพันธ์มี 28 วัน เดือนมกราคมมี 31 วัน Unit Cost รายวันต่างกัน 10% โดยไม่ต้องทำอะไรเลย ใช้ Cost per Customer per Day หรือ Normalize เป็นรายเดือน 30 วันเสมอ

4. ไม่แยก One-time Cost ออกจาก Run Rate

การจ่าย Upfront ของ Reserved Instance, Savings Plans ทำให้ Cost เดือนนั้นกระโดด ถ้าใช้ BilledCost Unit Economics จะเพี้ยน ต้องใช้ EffectiveCost (Amortized) เสมอ

5. เปิด Dashboard ให้ทุกคนแต่ไม่มีคน Own

ไม่มีใครรับผิดชอบเมื่อ Cost per Customer พุ่ง สุดท้าย Dashboard กลายเป็นวอลเปเปอร์ วิธีแก้คือ ตั้ง FinOps Champion ในแต่ละ Product Team ที่รายงาน Unit Cost ในประชุม Sprint Review ทุกครั้ง

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

FinOps Unit Economics คืออะไรในประโยคเดียว?