Cost Governance และ Cloud Cost Management

ไอเดียหลักในหนึ่งประโยค

ต้นทุนของ Datadog ขึ้นกับสิ่งที่คุณเลือกเก็บให้ index และ query ได้ — time series ของ custom metric ที่ไม่ซ้ำกันและ indexed log event ตามที่ billing docs ระบุ — และ Cloud Cost Management นำบิล cloud จริงของคุณเข้ามาอยู่ในโมเดล query-and-monitor เดียวกัน

🐶 บทนี้อ้างอิงข้อมูลจากไหน

ราคา, retention, allotment และพฤติกรรมของ product เปลี่ยนได้และขึ้นกับสัญญาของคุณ บทนี้จึงไม่รันอะไรกับ Datadog และ quote เฉพาะสิ่งที่ docs บอก (ดึงเมื่อ 2026-09-30) โดยมี URL ข้างทุกตัวเลข สิ่งเดียวที่รันจริงคือ terraform validate กับ provider DataDog/datadog 4.22.0 ที่ pin ไว้ (key ปลอม, validate = false) สำหรับ fence HCL จุดที่ docs ไม่อธิบายจะบอกไว้ตรง ๆ ตรวจทุกอย่างในนี้กับสัญญาของคุณเองก่อนนำไปตั้งงบ

ทบทวน: คันโยกต้นทุนสองแบบ ธีมเดียว

สองโมดูลก่อนหน้าสอนคันโยกต้นทุนไว้แล้ว

Custom metric (Infrastructure & Metrics, Metrics without Limits) หน้า billing (https://docs.datadoghq.com/account_management/billing/custom_metrics/) ระบุว่า: “A custom metric is uniquely identified by a combination of a metric name and tag values (including the host tag)” และ usage ที่คิดเงินรายเดือน “is calculated by taking the total of all distinct custom metrics (also known as timeseries) for each hour in a given month, and dividing it by the number of hours in the month to compute a monthly average value. Your billable usage is not impacted by data point submission frequency or the number of queries you run on your metrics.” ดังนั้นตัวขับคือ time series ที่ไม่ซ้ำกัน (tag cardinality) ไม่ใช่จำนวน point ต่อวินาที ข้อควรระวังสองข้อจากหน้าเดียวกัน: หน้านี้อธิบาย “cardinality-based Custom Metrics billing model” และชี้สัญญาที่ใช้ Metric Name pricing SKU ไปที่อื่น; และสำหรับ metric ที่ตั้งค่าด้วย Metrics without Limits “you pay for ingested custom metrics and indexed custom metrics” ไม่ใช่แค่มุมมองที่ index
Log (Log Management, index และ exclusion filter) หน้า billing ของ log (https://docs.datadoghq.com/account_management/billing/log_management/) ระบุว่า: “At the end of the month, Datadog computes the total number of log events that have been indexed” ถ้าต่ำกว่า commitment “your bill stays the same”; ถ้าเกิน “the committed amount is subtracted and on demand usage is charged with a 50% premium.” หน้านั้นอธิบายเฉพาะการคิดเงินตาม indexed event ไม่ได้อธิบาย line item อื่นของ log ดังนั้นให้อ่านสัญญาของคุณสำหรับสิ่งอื่น (ingestion, rehydration ฯลฯ) แทนที่จะสมมติว่าฟรี

เส้นเรื่องร่วมที่ docs รองรับ: หน้า billing นับ สิ่งที่ถูกเก็บและ query ได้ (series ที่ไม่ซ้ำกัน, indexed event) ไม่ใช่ traffic ดิบ นั่นคือเหตุผลที่ exclusion filter หรือการตั้ง tag ของ Metrics without Limits เป็นการตัดสินใจเรื่อง cost แต่มันไม่รองรับคำกล่าวที่แรงกว่านั้นว่า Datadog ไม่เคยคิดเงินกับสิ่งที่แค่ส่งเข้ามา อย่าเขียนแบบนั้นใน design doc

Custom metric: allotment ตาม docs

หน้า billing เดียวกัน ตัวเลขตามที่ docs พิมพ์

สำหรับ metric ที่ไม่ได้ตั้ง Metrics without Limits: “Account allotment: Pro: 100 indexed custom metrics per host; Enterprise: 200 indexed custom metrics per host” เกิน allotment “for each 100 indexed custom metrics over the account allotment, you pay an amount that is specified in your current contract.”
สำหรับ metric ที่ตั้ง Metrics without Limits: allotment ของ ingested เท่ากันคือ 100 (Pro) หรือ 200 (Enterprise) ต่อ host และ “For each 100 ingested custom metrics over the account allotment, you pay $0.10.” ส่วน indexed ที่เกินยังเป็นไปตามสัญญาของคุณ

docs ระบุ allotment ต่อ host ดังนั้น fleet ที่มี host เล็กจำนวนมากกับ fleet ที่มี host ใหญ่ไม่กี่ตัวได้ headroom ต่างกันมากสำหรับ metric design เดียวกัน เหตุผลที่ดีที่จะประเมิน cardinality ก่อน go-live แทนที่จะอ่านจาก invoice ทีหลัง

Cloud Cost Management: บิล cloud ในฐานะ metric source

หน้า Cloud Cost Management (https://docs.datadoghq.com/cloud_cost_management/) ระบุว่า: “Datadog ingests your cloud cost data and transforms it into metrics you can use in a search query on the Explorer page. If costs rise, you can correlate the increase with usage metrics to determine the root cause.” มีหน้า setup สำหรับ AWS, Azure, Google Cloud, Oracle, ต้นทุน SaaS และ AI และ custom costs ข้อมูลต้นทุนถูกเก็บ “with a retention period of 15 months” (หน้าเดียวกัน)

สำหรับ AWS (https://docs.datadoghq.com/cloud_cost_management/setup/aws/) สิ่งที่ต้องมีคือ AWS account ที่เข้าถึง billing ได้, AWS integration ที่ติดตั้งใน Datadog และ Cost and Usage Report; docs ยังบอกว่า “It may take between 48 and 72 hours for all available data to populate in your Datadog organization after a complete Cost and Usage Report is generated.” Datadog แนะนำให้ report มาจาก AWS management account เพราะ “A delegated administrator account cannot discover other member accounts.”

การเลือก metric สำคัญ และ docs ลิสต์ไว้ (หน้า AWS เดียวกัน)

aws.cost.net.amortized.shared.resources.allocated “provides the most complete cost allocation for specific workloads and teams” และต้องมี container cost allocation;
“If you do not have container cost allocation, use aws.cost.net.amortized”;
“If you do not have net amortized costs, use aws.cost.amortized.shared.resources.allocated or aws.cost.amortized”;
aws.cost.unblended “Matches the AWS invoice”; aws.cost.ondemand คือ “based on the list rate provided by AWS, excluding all savings plans, reservations, discounts, taxes, and fees”

ดังนั้น monitor บน aws.cost.amortized กับบน aws.cost.unblended จะไม่ตรงกันโดยออกแบบ เลือกตัวที่ตรงกับคำถาม (กระทบยอด invoice หรือ allocation ของต้นทุนที่หักส่วนลด)

บิลของ Datadog เองก็ query ได้: หน้า Datadog Costs (https://docs.datadoghq.com/cloud_cost_management/datadog_costs/) ระบุว่า daily Datadog costs ให้ “visibility into daily Datadog spending across dashboards, notebooks, cost monitors, Cloud Cost Explorer, reports, budgets, and anomalies”, ว่า “no additional charge” สำหรับมัน, ว่าการดูต้องมี permission “both the billing_read and usage_read” (default role: Datadog Admin) และ “Datadog cost data has an expected data delay of 48 hours and is available for the past 15 months.”

Cost alert monitor: กลไกเดียวกับที่ผ่านมา

fence ด้านล่างคือ resource datadog_monitor ตัวเดียวกับบทก่อนหน้าโดยใช้ type = "cost alert" ที่มาสำคัญตรงนี้: มันคือ config ที่ acceptance test ของ provider เอง TestAccDatadogMonitor_FormulaFunction_Cost ที่ tag v4.22.0 ใช้ (datadog/tests/resource_datadog_monitor_test.go) ซึ่งมี API cassette ที่บันทึกไว้รองรับ มัน validate ผ่านกับ provider ที่ pin ไว้; แต่ ไม่ใช่ คำแนะนำที่จูนแล้ว และทั้ง query grammar กับความหมายของ threshold 6 ไม่ได้ถูกอธิบายในหน้า docs ที่ผมหาเจอ

resource "datadog_monitor" "cloud_cost_spike" {
  name    = "EC2 cost anomaly"
  type    = "cost alert"
  message = "Unusual EC2 spend detected"

  query = "formula(\"query1\").last(\"30d\").anomaly(direction=\"both\") > 6"

  variables {
    cloud_cost_query {
      data_source = "cloud_cost"
      name        = "query1"
      query       = "sum:aws.cost.amortized{servicename:ec2} by {account}"
      aggregator  = "sum"
    }
  }

  monitor_thresholds {
    critical = 6
  }
}

สิ่งที่พิสูจน์ได้เกี่ยวกับมัน

type = "cost alert" เป็นหนึ่งใน monitor type ที่ valid ของ provider (docs ของ provider, docs/resources/monitor.md ที่ v4.22.0)
variables.cloud_cost_query เป็น block จริง (สูงสุด 5 ต่อ monitor); data_source รับ metrics, cloud_cost หรือ datadog_usage และ aggregator รับ avg, sum, max, min, last, area, l2norm, percentile, stddev (docs ของ provider เดียวกัน และ validate error ด้านล่าง)
query ที่ตั้งชื่อ (query1) ถูกอ้างจาก formula ใน query ระดับบนสุด

สิ่งที่หน้า Cloud Cost Monitor (https://docs.datadoghq.com/monitors/types/cloud_cost/) เพิ่มเรื่องพฤติกรรม

“Cloud Cost monitors use a 30-minute evaluation frequency and a 48-hour delayed evaluation window, since cost data may not be available until 48 hours after usage.”
monitor type ใน UI คือ Changes, Anomalies, Threshold, Forecast และ Budget; “Anomaly monitors require at least 1 month of cloud cost data to evaluate since historical data is required to train the algorithm” และ anomaly ใช้ “the agile anomaly algorithm … with two bounds and monthly seasonality”
“You can use custom metrics or observability metrics alongside a cost metric to monitor unit economics.”
หน้านั้นระบุ Terraform เป็นหนึ่งในวิธีสร้าง cost monitor และลิงก์ไป resource datadog_monitor

ผลต่อตัวอย่างนี้: cost monitor เตือนเรื่องการใช้จ่ายใน 48 ชั่วโมงล่าสุดไม่ได้ และ anomaly monitor ใน account ใหม่ไม่มีอะไรให้เรียนรู้ Cost alert ใช้กับ trend และ budget ไม่ใช่การตรวจจับ incident

flowchart LR
  A["Custom metrics: distinct time series"] --> D[Cost governance decisions]
  B["Logs: indexed events"] --> D
  C["Cloud provider billing data, 48 to 72 h to populate"] --> E[Cloud Cost Management]
  E --> F["Queryable cost metric: aws.cost.amortized etc."]
  F --> G["Cost alert monitor: 30 min evaluation, 48 h delayed window"]
  G --> H[Same alert routing as any other monitor]
  D --> G

จากข้อมูลบิล cloud สู่ cost alert

Reading AI-generated code

🐛 หา bug ในโค้ดนี้

# AI comment: "Alert on EC2 cost anomalies"
resource "datadog_monitor" "cloud_cost_spike" {
name    = "EC2 cost anomaly"
type    = "cost alert"
message = "Unusual EC2 spend detected"

query = "formula(\"query1\").last(\"30d\").anomaly(direction=\"both\") > 6"

variables {
  cloud_cost_query {
    data_source = "cloud_costs"
    name        = "query1"
    query       = "sum:aws.cost.amortized{servicename:ec2} by {account}"
    aggregator  = "total"
  }
}

monitor_thresholds {
  critical = 6
}
}

เฉลย

อันนี้อ่านเหมือน monitor ข้างบนและ parse เป็น HCL ได้ แต่ terraform validate กับ provider 4.22.0 ปฏิเสธสองค่าด้วยข้อความ error ของ provider เอง

Error: Invalid enum value
  on main.tf line 20, in resource "datadog_monitor" "cloud_cost_spike":
  20:       data_source = "cloud_costs"
`invalid value 'cloud_costs' for MonitorFormulaAndFunctionCostDataSource:
valid values are [metrics cloud_cost datadog_usage]`

Error: Invalid enum value
  on main.tf line 23, in resource "datadog_monitor" "cloud_cost_spike":
  23:       aggregator  = "total"
`invalid value 'total' for MonitorFormulaAndFunctionCostAggregator: valid
values are [avg sum max min last area l2norm percentile stddev]`

ทั้งสองค่าดูเป็นธรรมชาติ (“cloud costs”, “total”) และไม่มีใน doc ที่ reviewer จะเช็กจากความจำ วิธีแก้ใช้ cloud_cost และ sum (validate กับ provider ที่ pin ไว้แล้ว)

resource "datadog_monitor" "cloud_cost_spike_fixed" {
  name    = "EC2 cost anomaly"
  type    = "cost alert"
  message = "Unusual EC2 spend detected"

  query = "formula(\"query1\").last(\"30d\").anomaly(direction=\"both\") > 6"

  variables {
    cloud_cost_query {
      data_source = "cloud_cost"
      name        = "query1"
      query       = "sum:aws.cost.amortized{servicename:ec2} by {account}"
      aggregator  = "sum"
    }
  }

  monitor_thresholds {
    critical = 6
  }
}

validate พิสูจน์แค่ enum และรูปทรง block ส่วนว่า query string ทำงานตามที่ต้องการบน account ของคุณหรือไม่ (และ aws.cost.amortized คือ metric ที่ควรใช้หรือไม่ ตามรายการ metric ข้างบน) terraform validate บอกไม่ได้

Mental Model

คิดว่า cost เป็น telemetry stream ที่สองที่มี delay และหน่วยของตัวเอง Custom metric และ log เป็นแหล่งต้นทุน ภายใน Datadog ที่ควบคุมด้วยการตัดสินใจเรื่อง tag, index และ exclusion; cloud cost เป็นแหล่งต้นทุน ภายนอก ที่ Datadog นำเข้า (จาก Cost and Usage Report สำหรับ AWS) และ expose เป็น metric ทั้งสองจบที่การเป็นสิ่งที่ query, graph และ monitor ได้ ข้อเท็จจริงทางกายภาพที่สำคัญคือเวลา: ข้อมูล cloud cost มาถึง 48 ถึง 72 ชั่วโมงหลัง setup และล่าช้าได้ถึง 48 ชั่วโมงหลังจากนั้น จึงใช้ชี้นำ budget ไม่ใช่ incident

Trade-offs

Allotment ต่อ host เทียบกับวินัยเรื่อง cardinality — docs ระบุ headroom ของ custom metric ต่อ host การเพิ่ม host จึงเพิ่ม allotment แต่ tag cardinality สูงเพียงตัวเดียวก็เกินได้; ทางแก้ที่ถูกคือการตัดสินใจเรื่อง tag (Metrics without Limits) ซึ่ง docs บอกว่าเปลี่ยนการคิดเงินเป็นทั้ง ingested และ indexed
Commit log volume เทียบกับ on demand — docs อธิบาย premium 50% เมื่อเกิน commitment การ commit ต่ำเกินไปจึงไม่ฟรี; commit สูงเกินจ่ายค่า volume ที่อาจไม่ได้ใช้
aws.cost.unblended เทียบกับ metric แบบ amortized/net-amortized — unblended “matches the AWS invoice”; แบบ amortized กระจายส่วนลด commitment และรองรับการ allocate ให้ workload การกระทบยอดกับการระบุเจ้าของต้องการ metric ต่างกัน
Cost monitor แบบ anomaly เทียบกับ threshold เทียบกับ forecast เทียบกับ budget — anomaly ต้องการข้อมูลอย่างน้อยหนึ่งเดือนและใช้ monthly seasonality; threshold และ change ทำงานได้ด้วยประวัติน้อยกว่าแต่ไม่เรียนรู้ว่าอะไรปกติ

Common Misconceptions

“ต้นทุน custom metric ขึ้นกับจำนวน point ที่ส่ง” หน้า billing บอกว่า usage “not impacted by data point submission frequency or the number of queries you run”
“ใช้ Metrics without Limits แล้วจ่ายแค่มุมมองที่ index” หน้า billing บอกว่า metric แบบนั้นจ่าย “for ingested custom metrics and indexed custom metrics”; ingested ที่เกิน quote ไว้ที่ $0.10 ต่อ 100 เกิน allotment
“Datadog ไม่เคยคิดเงินกับสิ่งที่แค่รับเข้ามา” หน้า billing ของ log อธิบายแค่การคิดตาม indexed event; บทนี้ไม่ได้อ้างอะไรเกี่ยวกับ line item อื่น และคุณก็ไม่ควรโดยไม่อ่านสัญญา
“cost monitor จะจับ spike ของวันนี้ได้” docs ระบุ evaluation window ที่ล่าช้า 48 ชั่วโมง
“terraform validate ผ่านแปลว่า query ของ cost monitor ถูก” มันเช็กแค่รูปทรง block และ enum (ตามที่สอง error ข้างบนแสดง); ความหมายของ query ต้องดูบน account ของคุณ