คู่มือ Multi-Account Cloud Cost 2026

อัปเดตล่าสุด: 30 กรกฎาคม 2026

การจัดการต้นทุนคลาวด์แบบ multi-account หมายถึงการออกแบบลำดับชั้นของบัญชี (AWS Accounts), Subscriptions (Azure) หรือ Projects (GCP) ให้แยกตามทีม, product หรือ environment เพื่อให้บิลค่าใช้จ่ายถูกจัดสรร (allocate) ได้แม่นยำ, ควบคุมการใช้งานผ่านนโยบายส่วนกลาง, และแชร์ส่วนลดอย่าง Savings Plans หรือ Committed Use Discounts ให้เกิดประโยชน์สูงสุด ในปี 2026 ทั้งสาม hyperscaler ต่างขับเคลื่อนโมเดลนี้เป็นค่าเริ่มต้น และ FOCUS 1.2 ก็ทำให้การ consolidate ข้อมูลบิลข้าม cloud เป็นเรื่องง่ายขึ้นมาก บทความนี้เจาะลึกโครงสร้างที่ผมใช้จริงในองค์กรระดับ enterprise พร้อมตัวอย่างโค้ดที่รันได้ (และที่ผมได้เรียนรู้แบบเจ็บ ๆ จากการซ่อม setup ที่ทำพัง)

โครงสร้าง multi-account ที่ดีเริ่มจาก 3 แกน: environment (prod/nonprod), business unit และ workload domain (ไม่ใช่แค่ทีม)
AWS Organizations ปี 2026 รองรับสูงสุด 10,000 accounts ต่อ org, ใช้ SCPs จำกัด region และ instance family ป้องกันค่าใช้จ่ายไหลออกนอกงบ
Azure Management Groups รองรับ 6 ระดับ (ไม่นับ root) ใช้ร่วมกับ Azure Policy และ Cost Management scope inheritance
GCP Folders รองรับ 10 ระดับความลึก ใช้ Organization Policy Service ควบคุมและ inherits ลงมาถึง project
Savings Plans, RIs และ CUDs สามารถแชร์ข้าม accounts ในองค์กรได้ทั้งสาม cloud แต่มีเงื่อนไข (payer, billing account, linked project) ที่ต้องตั้งค่าถูกต้อง
FOCUS 1.2 spec ทำให้ export บิลจากทั้ง 3 cloud มาต่อกันใน table เดียวได้จริงในปี 2026

ทำไมต้องใช้โครงสร้าง multi-account?

ในประสบการณ์ของฉันที่ทำ FinOps ให้กับองค์กรที่มีมากกว่า 300 accounts, การรวมทุกอย่างไว้ใน account เดียวเป็นความผิดพลาดที่แพงที่สุด เพราะเมื่อบิลรวมมาถึงสิ้นเดือน คุณจะไม่มีทางแยกได้เลยว่าใครใช้เท่าไหร่ — และเมื่อถึงเวลาที่ CFO ถามว่า "ทำไมค่า EC2 เพิ่มขึ้น 40%" คุณจะได้แต่ยักไหล่

โครงสร้าง multi-account แก้ปัญหานี้ด้วย hard boundaries ที่ระดับ API. ไม่ใช่แค่ tag ที่ engineer มักจะลืมใส่ ทุก resource ที่ถูกสร้างในแต่ละ account จะถูก billed แยกทันทีโดยอัตโนมัติ ไม่ต้องพึ่งวินัยของทีม developer และในหลายกรณี boundaries นี้ยังช่วยเรื่อง blast radius (ถ้า credential รั่วในบัญชีเดียว, ความเสียหายจำกัดอยู่ในบัญชีนั้น) และ compliance (แยก data ตามภูมิภาคหรือ regulatory zone)

ในปี 2026 มีอีก 3 แรงผลักดันที่ทำให้ multi-account กลายเป็นค่าเริ่มต้น:

FinOps Foundation State of FinOps 2026 รายงานว่า 78% ขององค์กร enterprise ใช้ 20+ accounts และ 34% ใช้ 100+ accounts เพิ่มจาก 22% ในปี 2024
Landing Zone-as-a-service เช่น AWS Control Tower, Azure Landing Zones Accelerator และ GCP Cloud Foundation ทำให้การสร้าง account พร้อม guardrails ใช้เวลาไม่ถึง 15 นาที
FOCUS 1.2 ทำให้ข้อมูลบิลข้าม cloud มี schema เดียวกันได้จริง ไม่ต้องเขียน ETL แยกอีกต่อไป

AWS Organizations และ Consolidated Billing 2026

AWS Organizations คือบริการที่ใช้ผูก AWS accounts หลายบัญชีเข้าเป็น organization เดียว โดยมี management account (เดิมชื่อ payer account) เป็นบัญชีศูนย์กลางที่รับบิลรวมและถือสิทธิ์บริหาร ปี 2026 ขีดจำกัดต่อ org อยู่ที่ 10,000 accounts (ขึ้นจาก 5,000 ในปี 2024) ซึ่งเพียงพอสำหรับองค์กรทุกขนาดในปฏิบัติ

โครงสร้างที่ฉันใช้บ่อยที่สุดในลูกค้า enterprise คือ 4 ชั้น OU (Organizational Unit):

Root
├── Security_OU              (log-archive, audit, IAM identity center)
├── Infrastructure_OU        (network hub, shared services, DNS)
├── Workloads_OU
│   ├── Prod_OU
│   │   ├── payments-prod
│   │   ├── orders-prod
│   │   └── analytics-prod
│   └── NonProd_OU
│       ├── payments-dev
│       ├── payments-staging
│       └── sandbox-team-a
└── Suspended_OU             (accounts รอลบ)

เมื่อวาง SCP (Service Control Policy) ที่ระดับ OU มันจะ inherit ลงมาที่ทุก account ใต้ OU นั้น ตัวอย่าง SCP ที่ทุกลูกค้าของฉันควรมีเป็นอย่างแรก คือ จำกัด region เพื่อป้องกันการสร้าง resource ในภูมิภาคที่ไม่ได้ใช้ (เช่น ap-east-1) ซึ่งเป็นสาเหตุ shadow cost ที่พบบ่อยที่สุด:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutOfRegionResources",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "route53:*",
      "cloudfront:*", "waf:*", "support:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]
      }
    }
  }]
}

อีกตัวที่ควรมีคือ DenyLargeInstances ป้องกัน developer เปิด m7i.24xlarge ใน sandbox โดยไม่ตั้งใจ ใช้ condition ec2:InstanceType จำกัดแค่ family และ size ที่อนุญาต Consolidated Billing ทำงานอัตโนมัติเมื่อคุณเชื่อม account เข้า org ค่า Savings Plans และ RIs ในบัญชีลูกจะถูกแชร์ให้ทุก linked account ตามที่ตั้งค่าไว้ที่ management account (จะเจาะลึกในหัวข้อ แชร์ส่วนลด) ดูรายละเอียดเพิ่มเติมได้ที่ AWS Organizations Service Control Policies documentation

Azure Management Groups และ Subscription Hierarchy

ฝั่ง Microsoft Azure โครงสร้างมี 4 ระดับที่ต้องเข้าใจ: Tenant Root Group → Management Groups (สูงสุด 6 ระดับ) → Subscriptions → Resource Groups → Resources Cost Management ใช้ scope inheritance เหมือน RBAC คือ policy หรือ budget ที่วางที่ระดับ management group จะครอบคลุมทุก subscription ที่อยู่ใต้มัน

โครงสร้างมาตรฐานที่ Microsoft แนะนำใน Cloud Adoption Framework (และที่ผมใช้กับลูกค้าที่มี EA หรือ Enterprise Agreement) หน้าตาประมาณนี้:

Tenant Root Group
└── Contoso (root MG)
    ├── Platform
    │   ├── Identity            (Entra ID, PIM)
    │   ├── Management          (Log Analytics, monitoring)
    │   └── Connectivity        (Hub VNet, firewall)
    ├── Landing Zones
    │   ├── Corp
    │   │   ├── payments-prod-sub
    │   │   └── payments-dev-sub
    │   └── Online
    │       └── customer-portal-prod-sub
    ├── Sandbox
    └── Decommissioned

ใน Azure Cost Management ปี 2026 คุณสามารถตั้ง budget alerts ที่ระดับ management group ได้ ซึ่งเป็นความสามารถที่รอมานาน (เดิม budget ตั้งได้เฉพาะระดับ subscription หรือ resource group เท่านั้น). ตัวอย่างการตั้ง budget ที่ครอบทุก subscription ใต้ Landing Zones ด้วย Bicep:

targetScope = 'managementGroup'

resource landingZonesBudget 'Microsoft.Consumption/budgets@2024-08-01' = {
  name: 'landing-zones-monthly-budget'
  properties: {
    amount: 250000
    category: 'Cost'
    timeGrain: 'Monthly'
    timePeriod: {
      startDate: '2026-08-01'
      endDate: '2027-08-01'
    }
    notifications: {
      Actual_80: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 80
        thresholdType: 'Actual'
        contactEmails: ['[email protected]']
      }
      Forecasted_100: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 100
        thresholdType: 'Forecasted'
        contactEmails: ['[email protected]', '[email protected]']
      }
    }
  }
}

สำหรับ governance ให้ใช้ Azure Policy assign ที่ระดับ MG เช่นบังคับ tag ทุก resource, จำกัด SKU ที่อนุญาต, หรือบังคับ region สำหรับ data residency อ่านคู่มืออย่างเป็นทางการได้ที่ Azure Management Groups overview การเชื่อมโยงระหว่าง tag ที่ resource กับ cost allocation จะต้องเปิด tag inheritance ใน Cost Management (Settings → Rules → Tag inheritance) ไม่เช่นนั้น tag ที่ subscription level จะไม่ propagate ลงไปที่ line item

GCP Organization Hierarchy: Folders และ Projects

โครงสร้างของ Google Cloud มีความยืดหยุ่นที่สุดในบรรดา 3 cloud: Organization → Folders (nested สูงสุด 10 ระดับ) → Projects → Resources ต่างจาก AWS OU ที่จำกัด 5 ระดับ และ Azure MG ที่จำกัด 6 ระดับ ทำให้ GCP เหมาะกับองค์กรที่มี business unit ซ้อนกันหลายชั้น

สิ่งที่ทำให้ FinOps บน GCP ง่ายกว่าคือ billing account ผูกกับ project ได้แบบ many-to-one, คุณสามารถมี billing account เดียวที่รวมทุก project ในองค์กร (คล้าย AWS management account) หรือแยก billing account ตาม business unit ก็ได้ ในลูกค้าที่ผ่านมือฉันมา 90% เลือกใช้ billing account เดียวเพื่อ maximize CUD sharing

Organization: acme.com
├── Folder: production
│   ├── Folder: payments
│   │   ├── Project: payments-api-prod
│   │   ├── Project: payments-db-prod
│   │   └── Project: payments-cache-prod
│   └── Folder: analytics
│       └── Project: bigquery-warehouse-prod
├── Folder: nonprod
│   ├── Project: payments-api-dev
│   └── Project: sandbox-alice
└── Folder: shared
    ├── Project: shared-vpc-host
    └── Project: security-logs

ใช้ Terraform สร้าง project พร้อมผูก billing account และ label สำหรับ cost allocation ในคราวเดียว:

resource "google_project" "payments_prod" {
  name            = "Payments Production"
  project_id      = "acme-payments-prod-a1b2"
  folder_id       = google_folder.payments.name
  billing_account = var.billing_account_id
  labels = {
    environment    = "prod"
    business_unit  = "payments"
    cost_center    = "cc-8842"
    data_class     = "restricted"
    managed_by     = "terraform"
  }
}

resource "google_billing_budget" "payments_prod_budget" {
  billing_account = var.billing_account_id
  display_name    = "payments-prod-monthly"
  budget_filter {
    projects = ["projects/${google_project.payments_prod.number}"]
  }
  amount {
    specified_amount {
      currency_code = "USD"
      units         = "45000"
    }
  }
  threshold_rules { threshold_percent = 0.5 }
  threshold_rules { threshold_percent = 0.9 }
  threshold_rules { threshold_percent = 1.0 }
  all_updates_rule {
    monitoring_notification_channels = [
      google_monitoring_notification_channel.finops_email.id
    ]
  }
}

สำหรับ policy inheritance ใช้ Organization Policy Service เช่น compute.vmExternalIpAccess ห้ามสร้าง VM ที่มี public IP หรือ gcp.resourceLocations จำกัด region สามารถอ่านรายการ constraint ทั้งหมดได้ที่ GCP Organization Policy constraints reference

เปรียบเทียบโครงสร้าง 3 cloud แบบข้าง ๆ กัน

ก่อนเลือกโครงสร้าง multi-account ให้ผู้อ่านเทียบดูว่าแต่ละ cloud รองรับอะไรบ้าง ตารางนี้อ้างอิงข้อมูลจาก service quotas ที่อัปเดตล่าสุดกลางปี 2026:

คุณลักษณะ	AWS Organizations	Azure Management Groups	GCP Resource Hierarchy
หน่วยการเรียกเก็บเงินย่อย	Account	Subscription	Project
หน่วยจัดกลุ่ม	Organizational Unit (OU)	Management Group	Folder
ความลึกสูงสุด	5 ระดับ OU	6 ระดับ MG (ไม่รวม root)	10 ระดับ Folder
จำนวนสูงสุดต่อองค์กร	10,000 accounts	10,000 subscriptions	ไม่จำกัด (soft quota)
Policy engine	SCP (deny-only)	Azure Policy (deny + audit + modify)	Org Policy + IAM Deny
Billing consolidation	Consolidated Billing (auto)	EA/MCA billing account	Billing account (many-to-one)
Discount sharing	Savings Plans + RIs	Reservations + Savings Plans	CUDs (spend-based + resource-based)
ไฟล์ export ต้นทุน	CUR 2.0 + FOCUS 1.2	Cost details (Amortized) + FOCUS 1.2	BigQuery billing export + FOCUS 1.2

ประเด็นที่ทีมมัก overlook คือ policy engine AWS SCP สามารถทำได้แค่ Deny เท่านั้น ในขณะที่ Azure Policy และ GCP Org Policy สามารถ audit, append tags, หรือ modify ค่าเริ่มต้นให้ได้ ทำให้ workflow governance บน Azure/GCP ยืดหยุ่นกว่าเล็กน้อย. แต่ AWS ชนะเรื่อง SCP inheritance ที่คาดเดาได้ง่ายกว่า

Cost Allocation ข้าม accounts: Tags, Cost Categories และ Split Cost Allocation

Account boundaries ให้ระดับการแยกที่หยาบ (coarse-grained) แต่ในความเป็นจริงคุณต้องการรายละเอียดที่ละเอียดกว่านั้น เช่น "ค่าใช้จ่ายของ feature X" หรือ "ค่าใช้จ่ายต่อ tenant" — ตรงนี้แหละที่ tag ยังจำเป็น ฉันเขียนแยกไว้ในบทความ กลยุทธ์การแท็กทรัพยากรคลาวด์ แต่ในบริบท multi-account มีอีก 2 features ที่ทีม FinOps ปี 2026 ต้องรู้:

AWS Cost Categories

Cost Categories คือ virtual dimensions ที่คุณกำหนดเอง โดย map จาก account, tag, service หรือ region ไปเป็น "business view" ที่ CFO เข้าใจ เช่น รวม 12 accounts ที่เกี่ยวกับ payments เข้าเป็น category "Payments Platform" โดยไม่ต้องแตะโครงสร้าง OU:

{
  "Name": "BusinessUnit",
  "RuleVersion": "CostCategoryExpression.v1",
  "Rules": [
    {
      "Value": "Payments",
      "Rule": {
        "Dimensions": {
          "Key": "LINKED_ACCOUNT",
          "Values": ["111122223333", "444455556666", "777788889999"]
        }
      }
    },
    {
      "Value": "Analytics",
      "Rule": {
        "Tags": {
          "Key": "business_unit",
          "Values": ["analytics", "data-platform"]
        }
      }
    }
  ],
  "DefaultValue": "Unallocated"
}

Cost Categories จะปรากฏใน Cost Explorer, Budgets, และ CUR 2.0 เหมือน dimension ปกติ ใช้ประโยชน์สูงสุดเมื่อต้องรายงานให้ finance ในโครงสร้างที่ไม่ตรงกับ engineering hierarchy

Split Cost Allocation Data (SCAD)

สำหรับ shared resources โดยเฉพาะ EKS/ECS ที่หลาย tenant แชร์ cluster เดียวกัน AWS SCAD จะ split ค่า EC2, Fargate และ EBS ตาม pod-level usage (CPU/memory) และเขียนเข้า CUR แยก row ต่อ namespace ปี 2026 SCAD รองรับ EKS, ECS on Fargate และ SageMaker Studio ตั้งค่าใช้เวลาไม่กี่นาที และมันคือทางเดียวที่ทำ chargeback ระดับ tenant ได้อย่างแม่นยำโดยไม่ต้องเขียน custom ETL

สำหรับรายละเอียดว่า chargeback vs showback ต่างกันอย่างไรและควรเลือกโมเดลไหน อ่านบทความ FinOps Showback vs Chargeback 2026 ของฉันได้เลย

ประโยชน์ที่ใหญ่ที่สุดของโครงสร้าง multi-account คือการที่ commitment-based discounts (Savings Plans, Reserved Instances, Committed Use Discounts) สามารถ float ข้าม account ในองค์กรเดียวกันได้. เมื่อ workload ใน account A ไม่ใช้ discount, account B จะได้ใช้แทน ทำให้ utilization ใกล้ 100% โดยไม่ต้องซื้อซ้ำ

AWS: ต้องเปิด discount sharing ใน management account ก่อน (Billing → Billing preferences → Reserved Instances and Savings Plans discount sharing) ค่าเริ่มต้นในปี 2026 คือเปิดให้ทุก linked account แต่คุณสามารถ opt-out เฉพาะ account ที่ต้องการไม่ให้ใช้ (เช่น sandbox ที่ไม่อยากให้กิน commitment ไปเสียเปล่า) ได้

Azure: Reservations แชร์ผ่าน scope ได้ 3 แบบ: Single subscription, Management group, หรือ Shared (ทั้ง billing account) แนะนำให้เริ่มจาก Shared เว้นแต่มีเหตุผลด้าน chargeback ที่ต้อง lock ไว้ที่ subscription เดียว

GCP: Committed Use Discounts มี 2 ประเภทที่ต่างกันมาก:

Spend-based CUDs: ผูกกับ billing account โดยตรง แชร์ข้ามทุก project อัตโนมัติ ไม่มีอะไรต้องตั้งค่า
Resource-based CUDs: ผูกกับ project ที่ซื้อ แต่สามารถเปิด CUD sharing ที่ billing account เพื่อให้แชร์ข้าม projects ได้

สำหรับกลยุทธ์การซื้อ RI/SP/CUD แบบ portfolio อ่านคู่มือ Spot Instances, Savings Plans และ Reserved Instances ที่ฉันเคยเขียนไว้เพิ่มเติม

Consolidated Billing Export: CUR 2.0, FOCUS และ Cost Details

เมื่อโครงสร้าง org พร้อมและ discount sharing เปิดแล้ว ขั้นต่อไปคือการ export ข้อมูลบิลเข้า data warehouse ของคุณเพื่อสร้าง dashboard, chargeback report และ anomaly detection ปี 2026 นี้ทั้งสาม cloud มี format ที่แนะนำต่างกัน:

AWS: CUR 2.0 กับ FOCUS 1.2 ที่ export ควบคู่กัน

CUR 2.0 (Cost and Usage Report 2.0) เป็น native format ของ AWS ที่มี column มากกว่า 200 columns ครอบคลุมทุกรายละเอียด รวมถึง SCAD, RI/SP amortization และ tag ทั้งหมด ตั้งค่าผ่าน Data Exports service ให้ส่งเข้า S3 แล้ว query ผ่าน Athena:

SELECT
  bill_billing_period_start_date AS billing_month,
  product_product_name AS service,
  line_item_usage_account_id AS account_id,
  resource_tags_user_business_unit AS bu,
  SUM(line_item_unblended_cost) AS unblended,
  SUM(line_item_net_amortized_cost) AS amortized
FROM cur2_hourly
WHERE bill_billing_period_start_date >= DATE '2026-07-01'
  AND line_item_line_item_type IN ('Usage', 'SavingsPlanCoveredUsage', 'DiscountedUsage')
GROUP BY 1, 2, 3, 4
ORDER BY amortized DESC
LIMIT 100;

ควรตั้ง FOCUS 1.2 export คู่ขนานไปด้วยเพราะเป็น schema เดียวกับ Azure และ GCP ทำให้ง่ายต่อการทำ multi-cloud dashboard

Azure: Cost details + FOCUS via Exports

ตั้ง Cost Management Exports ให้ส่ง Amortized cost รายวันเข้า Storage Account (Parquet format แนะนำ) ถ้าใช้ EA billing account ให้เลือก scope เป็น Billing account เพื่อครอบทุก subscription ในองค์กร ปี 2026 Microsoft รองรับ FOCUS 1.2 native แล้ว ตั้งค่าใน Cost Management → Exports → Create → เลือก dataset เป็น FOCUS cost

GCP: BigQuery billing export

GCP ชนะเรื่อง ergonomics ของ billing export ชัดเจน. เพียงเปิด Detailed usage cost ให้ส่งตรงเข้า BigQuery table แล้ว query ได้ทันทีไม่ต้องตั้ง crawler หรือ Parquet loader และตั้งแต่ Q1 2026 ก็มี FOCUS view built-in ที่ auto-materialize จาก detailed export

เมื่อรวมทั้ง 3 cloud ผ่าน FOCUS schema เดียวกัน คุณสามารถ union table ข้ามได้เลย, ใช้ประโยชน์นี้เพื่อทำ multi-cloud spend view ในกรอบเดียว รายละเอียด spec ครบถ้วนอ่านได้ที่บทความ FOCUS Specification 2026 ของฉัน หรือดูตัว spec ต้นฉบับที่ FinOps Foundation FOCUS specification

ข้อผิดพลาดที่พบบ่อยและวิธีเลี่ยง

หลังจาก audit multi-account setup มาหลายสิบองค์กร ฉันเห็นรูปแบบข้อผิดพลาดซ้ำ ๆ 5 อย่างที่แพงที่สุด:

รวม cost ของ shared services เข้าไปในทุก account แบบสุ่ม: เช่น NAT Gateway ใน network hub ที่ทุก account ใช้ควรถูก split ตาม traffic (VPC Flow Logs → cost model) ไม่ใช่แบ่งเท่า ๆ กัน
ตั้ง discount sharing แล้ว opt-in ทุก account: sandbox หรือ ephemeral env ที่ auto-tear-down จะกิน commitment แบบไม่ได้วางแผน ตั้งให้ opt-out sandbox ตั้งแต่วันแรก
ไม่ตั้ง SCP หรือ Azure Policy จำกัด region: resource ในภูมิภาคที่ไม่ได้ตั้งใจใช้เป็นสาเหตุ shadow spend อันดับ 1 ในปี 2025-2026
ตั้ง management/billing account ผิดที่: เช่นตั้งใน region ที่ IAM Identity Center ใช้ไม่ได้เต็มที่ ย้ายภายหลังยากมาก วางแผน region นี้ให้ดีก่อน day one
ไม่ทำ tag inheritance: resource ระดับ subscription/project มี tag แต่ resource ระดับล่างไม่มี ทำให้ chargeback ไม่ครบ Azure Cost Management และ AWS Cost Explorer ต่างมี tag inheritance ให้เปิด

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

โครงสร้าง AWS Organizations ที่ดีสำหรับ FinOps คืออะไร?

เริ่มจาก OU 4 ชั้น: Security, Infrastructure, Workloads (แยก Prod/NonProd), และ Suspended ทำให้ SCP inherit ได้แม่นยำ และแยก blast radius ตาม environment แล้วใช้ Cost Categories จับกลุ่ม account เข้าเป็น business unit ตามที่ finance ต้องการ ไม่ต้องบิดโครงสร้าง OU ตาม CFO

Azure Management Groups ต่างจาก Subscription อย่างไร?

Management Group เป็นหน่วยจัดกลุ่มเชิง governance ที่ใช้ apply Azure Policy และ RBAC ให้ครอบหลาย subscription ในขณะที่ Subscription เป็นหน่วย billing และ resource boundary จริง ๆ MG ไม่มีบิลของตัวเอง แต่คุณสามารถตั้ง budget ที่ระดับ MG ได้ใน Cost Management ตั้งแต่ปี 2024 เป็นต้นมา

Reserved Instances และ Savings Plans แชร์ข้าม accounts ได้ไหม?

ได้ ทั้ง AWS Savings Plans, Azure Reservations และ GCP Committed Use Discounts รองรับการแชร์ข้าม account/subscription/project ในองค์กรเดียวกัน โดย AWS ต้องเปิด discount sharing ใน management account, Azure ต้องตั้ง scope เป็น Shared หรือ MG, และ GCP spend-based CUDs แชร์อัตโนมัติ ส่วน resource-based CUDs ต้องเปิด CUD sharing ที่ billing account

ควรมีกี่ AWS accounts ในองค์กร?

ขึ้นกับขนาดและระดับการแยก ในทางปฏิบัติแนะนำอย่างน้อย: 1 account ต่อ (environment × workload) เช่น 3 environment × 5 workload = 15 accounts บวก security/network/log-archive อีก 3-4 องค์กร enterprise ทั่วไปมี 50-500 accounts ส่วน hyperscaler-scale จะไปถึง 1,000+ ได้

FOCUS spec ช่วยเรื่อง multi-cloud FinOps อย่างไร?

FOCUS (FinOps Open Cost and Usage Specification) กำหนด schema กลางสำหรับข้อมูลบิลคลาวด์ ทำให้คุณ union ข้อมูลจาก AWS, Azure, GCP และ SaaS providers อื่นได้ในตารางเดียวโดยไม่ต้องเขียน ETL แยก ปี 2026 FOCUS 1.2 รองรับ commitment discount, split cost allocation และ tag columns มาตรฐาน — เป็นค่าเริ่มต้นของทีม FinOps ทุกองค์กร enterprise ในปีนี้