Chiến lược tagging đa tài khoản là bộ quy tắc buộc mọi resource trên AWS, Azure và GCP phải mang các nhãn nhất quán (Environment, Owner, CostCenter, Application, Project, ManagedBy, DataClassification) trước khi được tạo, nhờ đó FinOps có thể phân bổ 100% chi phí về đúng team hoặc business unit thay vì bỏ vào rổ "Untagged". Nói thật, với 7+ tài khoản thì việc dựa vào tag thủ công gần như chắc chắn thất bại. Bạn cần AWS Organizations Tag Policy, Service Control Policy (SCP), Azure Policy và Terraform pre-commit hook để chặn resource không tag ngay từ khâu provisioning. Trong bài này mình tổng hợp cách mình đã ship chiến lược tagging cho các setup nhiều trăm tài khoản, kèm bảng tính mẫu và code example.
Bắt đầu với 5–7 tag bắt buộc (Environment, Owner, CostCenter, Application, Project, ManagedBy, DataClassification) trước khi mở rộng thêm. AWS cho phép tối đa 500 cost allocation tag active/management account và 50 tag/resource.
Kích hoạt Cost Allocation Tag chỉ thực hiện được từ management account của AWS Organizations, mất tối đa 24 giờ để tag key xuất hiện và thêm 24 giờ để active. Kế hoạch onboarding phải tính buffer.
Từ tháng 12/2025, AWS ra mắt account-level cost allocation tag qua AWS Organizations, giúp phân bổ được cả những chi phí không thể tag như Data Transfer, Support, Marketplace và Refunds.
FOCUS 1.4 (ra ngày 4/6/2026) chuẩn hoá schema billing của AWS, Azure và GCP. Dùng nó cùng Cost Categories và virtual tagging để loại bỏ "Untagged Costs" trên báo cáo chargeback.
Ba mô hình phân bổ chính (Account-based, BU/Team-based và Application-based) mỗi mô hình phù hợp một quy mô tổ chức khác nhau; kết hợp cả ba khi bạn có >50 tài khoản.
Enforcement phải nằm ở khâu provisioning (SCP + Terraform pre-commit), không phải ở khâu remediation sau đó, vì backfill tag cho resource đã chạy vài tháng gần như bất khả thi.
Chiến lược tagging đa tài khoản là gì và tại sao FinOps 2026 cần nó?
Với các setup mình đã dựng cho khách hàng có 40–300 tài khoản AWS cộng thêm Azure subscription và GCP project, tag không chỉ là metadata. Nó là bản khai thuế nội bộ để mỗi đồng chi phí về đúng cost center. Không có chiến lược tagging bền vững, hoá đơn Cloud sẽ về "Untagged" khoảng 15–40% và bạn không thể chargeback, không thể forecast, không thể trả lời câu hỏi "team nào tiêu tiền nhất tuần này".
Ba lý do năm 2026 khiến tagging trở nên cấp bách hơn:
Chi phí AI/ML bùng nổ. GPU instance (p5, ND H100 v5, A3) đắt 20–60× so với CPU. Một team dev quên bật shutdown là mất hàng nghìn USD/đêm. Không tag nghĩa là không biết ai làm mất tiền. Mình viết chi tiết hơn trong hướng dẫn FinOps cho AI/ML.
Multi-cloud phổ biến. Khảo sát State of FinOps 2026 cho thấy 68% tổ chức đang chạy ≥2 cloud. Tag key khác nhau giữa AWS (case-sensitive), Azure (không phân biệt hoa thường) và GCP (lowercase-only) làm báo cáo tổng hợp vỡ trận.
FOCUS 1.4 đã GA vào tháng 6/2026 và trở thành chuẩn de facto. Nếu tag của bạn không map được sang x_ResourceTags theo FOCUS, bạn không thể tận dụng bất kỳ FinOps platform hiện đại nào.
Tagging đa tài khoản khác tagging đơn giản ở ba điểm: (1) tag phải được kế thừa hoặc kích hoạt ở cấp organization/tenant/folder, không chỉ ở resource; (2) enforcement phải áp dụng cross-account, dùng SCP hoặc Azure Management Group; (3) báo cáo phải join được tag giữa các account bằng cùng một schema. Nếu thiếu bất kỳ điểm nào, bạn sẽ có "silo hoá tag", tức là mỗi account có tag riêng và không ai tổng hợp được.
Bảy tag bắt buộc cho mọi tổ chức đa tài khoản
Câu hỏi hay gặp nhất: "Tôi nên bắt đầu với bao nhiêu tag?" Câu trả lời ngắn là 5 đến 7 tag bắt buộc, kích hoạt hoàn toàn, trước khi thêm bất kỳ tag tuỳ chọn nào. AWS Cost Explorer hỗ trợ tối đa 500 cost allocation tag active/management account, nhưng thực tế trên 15 tag là bạn không còn quản lý được nữa.
Đây là bộ tag mà mình áp dụng mặc định cho mọi setup mới:
Tag key
Giá trị mẫu
Mục đích
Bắt buộc?
Environment
prod | staging | dev | sandbox
Phân tách chi phí theo môi trường; nền tảng cho rightsize dev/staging.
Ứng dụng logic, quan trọng khi 1 team có nhiều app.
Có
Project
peak-2026 | migration-eu
Sáng kiến kinh doanh, dùng để track ROI dự án.
Có
ManagedBy
terraform | pulumi | manual
Phân biệt IaC vs click-ops, cần cho compliance audit.
Nên có
DataClassification
public | internal | pii | pci
Gắn compliance vào chi phí; quan trọng cho ngân hàng, fintech.
Tuỳ ngành
Giá trị của mỗi tag phải là danh sách đóng (allowed values), không phải free-text. Ví dụ, cho phép Environment=prod|staging|dev|sandbox nhưng chặn Environment=production hoặc Environment=PRD. Bạn có thể enforce điều này bằng AWS Organizations Tag Policy hoặc Azure Policy, chi tiết ở phần Thực thi tag bên dưới.
Ba mô hình phân bổ chi phí đa tài khoản: chọn cái nào?
AWS Well-Architected Cost Optimization Pillar khuyến nghị ba mô hình phân bổ chi phí đa tài khoản, mỗi mô hình phù hợp một quy mô và cấu trúc tổ chức khác nhau. Trong thực tế, mình thấy hầu hết công ty >100 tài khoản đều dùng kết hợp cả ba, chứ không chọn thuần một cái.
1. Account-based (mỗi team một tài khoản)
Mỗi team hoặc business unit sở hữu 1–5 tài khoản (prod, staging, dev, sandbox, data). Đây là cách đơn giản nhất và cho độ chính xác chargeback cao nhất, vì AWS đã tách billing sẵn theo account ID. Phù hợp cho tổ chức <20 team hoặc mới bắt đầu multi-account. Nhược điểm: tăng số tài khoản nhanh, chạm quota AWS Organizations (hiện tại 10.000 account/org nhưng còn nhiều soft limit khác).
2. BU/Team-based với Cost Categories
Với vài trăm account, việc mở Cost Explorer chọn từng account ID không khả thi. Bạn dùng AWS Cost Categories để group account thành business unit ảo. Cost Category về bản chất là "meta-tag": bạn định nghĩa rule kiểu account_id IN (111, 222, 333) AND environment=prod → BU=Payments-Prod, sau đó filter và budget theo BU thay vì theo account. Cost Category cũng chấp nhận tag key làm điều kiện, nên bạn có thể kết hợp cả account ID lẫn tag.
3. Application-based (dựa hoàn toàn vào tag)
Nhiều app dùng chung account (thường thấy ở shared services như logging, monitoring, ingress). Ở đây bạn bắt buộc phải có tag Application và CostCenter chuẩn, vì không có cách nào phân bổ khác. Mô hình này khó nhất về mặt operational nhưng flexible nhất; bạn có thể chargeback cho 200 team dù chỉ có 30 tài khoản.
Kích hoạt Cost Allocation Tags trên AWS Organizations
Đây là chỗ nhiều team mắc bẫy: áp tag lên resource và kích hoạt tag làm Cost Allocation Tag là hai thao tác khác nhau. Bỏ bước 2 thì tag của bạn vĩnh viễn không xuất hiện trong Cost Explorer, Budget hay Cost & Usage Report (CUR).
Quy trình chuẩn mình hay chạy:
Đăng nhập bằng management account của AWS Organization. Member account không thể kích hoạt cost allocation tag, chỉ payer/management account làm được.
Vào Billing and Cost Management → Cost allocation tags. Đợi 24 giờ sau khi tag đầu tiên được áp lên bất kỳ resource nào trong org, tag key mới xuất hiện ở đây.
Tick chọn cả User-defined cost allocation tags (7 tag của bạn) và AWS-generated tags (aws:createdBy, aws:cloudformation:stack-name). Nhấn Activate.
Đợi thêm 24 giờ để CUR bắt đầu xuất tag vào cột resourceTags/user:Environment...
Đoạn code Boto3 dưới đây tự động kích hoạt danh sách tag mà không cần vào console, hữu ích khi bạn phải setup lại cho nhiều organization:
import boto3
REQUIRED_TAGS = [
"Environment", "Owner", "CostCenter",
"Application", "Project", "ManagedBy",
"DataClassification",
]
# Client phải chạy trong management account
ce = boto3.client("ce")
# Kích hoạt cost allocation tags
resp = ce.update_cost_allocation_tags_status(
CostAllocationTagsStatus=[
{"TagKey": key, "Status": "Active"} for key in REQUIRED_TAGS
]
)
# Log kết quả để kiểm tra tag nào chưa xuất hiện
for err in resp.get("Errors", []):
print(f"[WARN] Không kích hoạt được {err['TagKey']}: {err['Message']}")
# Xác nhận trạng thái sau khi kích hoạt
status = ce.list_cost_allocation_tags(Status="Active")
active_keys = {t["TagKey"] for t in status["CostAllocationTags"]}
missing = set(REQUIRED_TAGS) - active_keys
if missing:
print(f"[ACTION] Các tag chưa active (cần chờ 24h hoặc tag chưa xuất hiện): {missing}")
else:
print("[OK] Đã kích hoạt đủ toàn bộ tag bắt buộc.")
Cập nhật quan trọng tháng 12/2025: Account-level cost allocation tags
Từ tháng 12/2025, AWS mở tính năng account-level cost allocation tags qua AWS Organizations. Trước đây, các dòng chi phí không gắn được vào resource cụ thể (Data Transfer inter-region, AWS Support fee, phần lớn Marketplace subscription, refund, credit) sẽ bị đẩy vào rổ "No Tag Key" và bạn không cách nào phân bổ. Với account-level tag, bạn tag chính account (ví dụ CostCenter=CC-2401 gắn lên account ID 111122223333), thì mọi untaggable cost trên account đó cũng thừa hưởng tag này. Điều này đặc biệt quan trọng nếu chi phí Data Transfer của bạn lớn. Xem thêm hướng dẫn giảm chi phí Data Transfer để hiểu vì sao khoản này thường chiếm 8–15% hoá đơn.
Chuẩn hoá tag giữa AWS, Azure và GCP với FOCUS 1.4
Ba nhà cung cấp cloud có ba cách hiểu về "tag" khác nhau, và đó là lý do 90% báo cáo multi-cloud mình từng thấy đều sai lệch:
Đặc tính
AWS
Azure
GCP
Tên gọi
Tag
Tag
Label (hoặc Tag, hai khái niệm khác nhau)
Số tag tối đa/resource
50
50
64 label
Case-sensitive?
Có (key và value)
Không (nhưng giữ nguyên hiển thị)
Chỉ chấp nhận lowercase, số, dấu gạch ngang, gạch dưới
Ký tự cho phép trong key
Rộng (Unicode)
Rộng (không dấu < > % &)
Nghiêm ngặt: chỉ [a-z0-9_-], bắt đầu bằng chữ cái
Kế thừa từ cấp trên
Không (trừ account-level tag)
Có option (Azure Policy inherit)
Có (tag folder/project inherit xuống resource)
Cột trong FOCUS 1.4
x_ResourceTags (JSON object), chuẩn cross-cloud
Bởi GCP chỉ chấp nhận key/value ở dạng lowercase, bạn buộc phải chọn taxonomy tương thích với ràng buộc chặt nhất. Convention mình khuyên: dùng cost_center, environment, owner_email, application ở dạng snake_case lowercase toàn bộ, rồi apply nhất quán trên cả AWS lẫn Azure. Cost Explorer AWS vẫn hiển thị đẹp, và bạn không phải viết lookup table để "map" giữa các cloud.
FOCUS 1.4 làm gì cho tag của bạn?
FinOps Foundation ban hành FOCUS 1.4 vào ngày 4/6/2026 (chi tiết trong FOCUS Specification v1.0 và các bản 1.3, 1.4). Cột chính bạn cần biết là x_ResourceTags, một JSON object chứa toàn bộ tag/label của resource, giống hệt nhau về schema dù dữ liệu đến từ AWS CUR, Azure Cost Management Export hay GCP Billing Export.
-- Ví dụ query BigQuery/Athena chuẩn FOCUS 1.4
-- Tổng chi phí theo cost_center trên cả ba cloud, một câu lệnh
SELECT
JSON_VALUE(x_ResourceTags, '$.cost_center') AS cost_center,
BillingAccountName,
ProviderName, -- 'AWS' | 'Microsoft' | 'Google'
SUM(EffectiveCost) AS total_usd
FROM focus_billing.consolidated
WHERE ChargePeriodStart >= DATE '2026-08-01'
GROUP BY cost_center, BillingAccountName, ProviderName
ORDER BY total_usd DESC;
Query này trước đây phải viết thành ba pipeline ETL riêng cho ba cloud, mỗi lần AWS đổi format CUR là hỏng. Với FOCUS 1.4, bạn viết một lần chạy ở mọi nơi, miễn là tag key của bạn nhất quán.
Thực thi tag qua SCP, Terraform và Azure Policy (có code)
Chốt lại nguyên tắc quan trọng nhất mình học được sau nhiều năm làm FinOps: không bao giờ backfill được tag cho resource đã chạy vài tháng. Owner đã đổi team, project đã kết thúc, tài liệu đã thất lạc. Cách duy nhất bền vững là chặn resource không đủ tag ngay từ khâu tạo. Đây là 3 lớp defense mình luôn triển khai:
Lớp 1: Terraform module bọc mọi resource
# modules/tags/main.tf
# Buộc caller truyền đủ 7 tag bắt buộc, nếu thiếu thì terraform plan fail
variable "environment" { type = string }
variable "owner" { type = string }
variable "cost_center" { type = string }
variable "application" { type = string }
variable "project" { type = string }
variable "managed_by" { type = string, default = "terraform" }
variable "data_classification" { type = string, default = "internal" }
# Validation chặn giá trị sai chính tả (production vs prod)
variable "environment_check" {
type = string
default = "checked"
validation {
condition = contains(["prod", "staging", "dev", "sandbox"], var.environment)
error_message = "environment phải là một trong: prod, staging, dev, sandbox"
}
}
output "tags" {
value = {
Environment = var.environment
Owner = var.owner
CostCenter = var.cost_center
Application = var.application
Project = var.project
ManagedBy = var.managed_by
DataClassification = var.data_classification
}
}
Dev viết tags = module.standard_tags.tags mỗi lần tạo resource. Không cách nào lách được vì terraform plan báo lỗi khi thiếu biến.
Lớp 2: Service Control Policy (SCP) ở AWS Organization
SCP này attach vào root OU sẽ chặn cả console click-ops lẫn CI/CD nếu API call không kèm 4 tag core. Nó là safety net cuối cùng, cover cho trường hợp ai đó lách qua Terraform bằng cách bấm console trực tiếp.
Assign policy này ở Management Group cấp cao nhất; nó áp dụng xuống mọi subscription mà không cần đụng vào từng cái.
Trên GCP, do label không có "deny at create" như SCP, mình thường dùng Config Validator hoặc Terraform Sentinel ở pipeline để chặn resource label thiếu, kèm scheduled job qua Cloud Asset Inventory phát hiện resource vi phạm sau đó.
Xử lý chi phí không thể tag: virtual tagging và Cost Categories
Kể cả khi tag coverage của bạn đạt 100% resource, vẫn có 5–15% chi phí không thể tag: Data Transfer inter-AZ, Support Business/Enterprise plan, một số dịch vụ Marketplace, EBS snapshot của resource đã xoá, credit và refund. Đây là chỗ virtual tagging và Cost Categories phát huy tác dụng.
Virtual tag về bản chất là rule "nếu chi phí thoả điều kiện X thì gán tag Y", không đụng vào resource thật. Ví dụ, mình thường tạo rule như sau trong FinOps platform (hoặc trong Cost Categories):
service = 'DataTransfer' AND account_id = 111122223333 → CostCenter = CC-2401. Chi phí Data Transfer về đúng cost center của account.
service = 'AWSSupport' → CostCenter = CC-9000 (Shared IT). Support phí là chi phí chung, đẩy vào cost center IT.
credit_amount < 0 → CostCenter = CC-9001 (Corporate). Credit và refund về ngân sách công ty, không distort BU nào.
Việc tự động hoá phần này giúp bạn tránh phải bảo vệ báo cáo trước CFO với 12% chi phí "Unknown". Sau khi có Cost Categories + account-level tag + virtual tag, mình thường đưa được "Unknown" xuống dưới 1%.
Showback vs Chargeback: chọn mô hình nào?
Tag chỉ là công cụ; câu hỏi FinOps thật sự là bạn làm gì với dữ liệu tag đó. Có ba mô hình phổ biến, sắp theo thứ tự "trưởng thành":
Mô hình
Cách hoạt động
Phù hợp khi
Rủi ro
Showback
Báo cáo chi phí cho từng team nhưng không trừ ngân sách. Team thấy số nhưng chưa "trả tiền".
Tổ chức mới bắt đầu FinOps, tag coverage <80%, chưa có văn hoá cost accountability.
Không có động lực thay đổi. Team đọc báo cáo rồi ignore.
Chargeback
Trừ trực tiếp vào ngân sách của team dựa trên chi phí thực. Finance gửi hoá đơn nội bộ hàng tháng.
Tag coverage >95%, có processes handle dispute, có tooling forecast tốt.
Team đổ lỗi cho tag sai gây tranh chấp; team over-provisioning để "trữ" ngân sách.
Optimization-only
Trung tâm FinOps giữ ngân sách, team chỉ nhận KPI về efficiency (cost per transaction, unit economics).
SaaS trưởng thành đo được unit metric; startup high-growth không muốn tạo friction chargeback.
Phụ thuộc vào chất lượng unit metric. Sai metric là tối ưu sai hướng.
Roadmap mình hay khuyên: 6 tháng đầu chạy Showback để làm sạch tag và training team đọc báo cáo; tháng 7–12 chuyển sang Chargeback với 3 tháng dual-run song song để giải quyết tranh chấp; sau đó bổ sung KPI unit-economics. Đừng đốt cháy giai đoạn. Chargeback áp dụng khi tag coverage <90% sẽ đẻ ra vô số dispute và team ghét FinOps.
Mình vận hành tagging bằng ba KPI, chạy weekly review với team platform:
Tag coverage %. Tỷ lệ resource có đủ 7 tag bắt buộc. Target: >95% trên prod, >85% trên non-prod.
Untagged spend %. Tỷ lệ chi phí không có CostCenter. Target: <5% (bao gồm cả virtual tag đã áp).
Tag drift count. Số resource có tag không match allowed values (ví dụ Environment=Production thay vì prod). Target: 0, phát hiện là remediate ngay.
Đoạn script Python dưới đây chạy hàng đêm để quét toàn bộ AWS org qua Cost Explorer API và alert Slack nếu untagged spend vượt ngưỡng:
import boto3
from datetime import date, timedelta
THRESHOLD = 0.05 # 5% untagged spend
ce = boto3.client("ce")
today = date.today()
resp = ce.get_cost_and_usage(
TimePeriod={"Start": str(today - timedelta(days=7)), "End": str(today)},
Granularity="MONTHLY",
Metrics=["UnblendedCost"],
GroupBy=[{"Type": "TAG", "Key": "CostCenter"}],
)
total, untagged = 0.0, 0.0
for group in resp["ResultsByTime"][0]["Groups"]:
amt = float(group["Metrics"]["UnblendedCost"]["Amount"])
total += amt
# Key rỗng nghĩa là resource chưa tag CostCenter
if group["Keys"][0] in ("CostCenter$", "CostCenter$(no value)"):
untagged += amt
pct = untagged / total if total else 0
print(f"Tuần vừa rồi: ${total:,.0f}, untagged ${untagged:,.0f} ({pct:.1%})")
if pct > THRESHOLD:
# Gửi Slack alert cho team FinOps
# requests.post(SLACK_URL, json={"text": f":warning: Untagged spend {pct:.1%}"})
print(f"[ALERT] Vượt ngưỡng {THRESHOLD:.0%} - cần điều tra ngay.")
Để đi sâu hơn nữa, dùng AWS Config rule required-tags cho AWS, Azure Resource Graph query hoặc Policy compliance report cho Azure, và Cloud Asset Inventory export cho GCP. Ba nguồn này join lại thành một dashboard "Tag Coverage" duy nhất trong Grafana hoặc Looker. Đó là artifact mình luôn đề xuất là output đầu tiên của mọi FinOps program.
Câu hỏi thường gặp
Cần bao nhiêu tag bắt buộc cho một tổ chức đa tài khoản?
Bắt đầu với 5–7 tag bắt buộc (Environment, Owner, CostCenter, Application, Project, ManagedBy và tuỳ chọn DataClassification). Enforce chặt các tag này trước khi mở rộng thêm. AWS cho phép tối đa 500 cost allocation tag active, nhưng thực tế trên 15 tag là không quản lý nổi.
Ai được phép kích hoạt Cost Allocation Tags trên AWS?
Chỉ management account (payer account) của AWS Organizations mới có quyền kích hoạt cost allocation tag. Member account không làm được. Sau khi kích hoạt, mất tối đa 24 giờ để tag key xuất hiện và thêm 24 giờ nữa để tag chính thức active trong Cost Explorer và CUR.
Xử lý chi phí không thể tag như Data Transfer, Support hay Marketplace ra sao?
Dùng ba lớp: (1) account-level cost allocation tag của AWS Organizations (ra tháng 12/2025) để tag chính account; (2) AWS Cost Categories để tạo rule "nếu service = Support thì gán CostCenter = CC-9000"; (3) virtual tagging trong FinOps platform để phân bổ credit và refund. Sau ba lớp này, phần "Unknown" thường xuống dưới 1%.
Làm sao chuẩn hoá tag giữa AWS, Azure và GCP?
Chọn taxonomy tương thích với ràng buộc chặt nhất là GCP (chỉ lowercase, số, dấu gạch ngang, gạch dưới). Dùng snake_case như cost_center, environment, owner_email, application áp nhất quán trên cả ba cloud. Sau đó xuất billing data theo chuẩn FOCUS 1.4 để join tag qua cột x_ResourceTags trong một query duy nhất.
Chargeback hay Showback tốt hơn cho FinOps mới bắt đầu?
Showback phù hợp với tổ chức mới bắt đầu FinOps hoặc tag coverage dưới 80%. Chỉ chuyển sang Chargeback khi coverage đạt trên 95%, có process handle dispute và tool forecast tốt. Chargeback quá sớm sẽ tạo tranh chấp giữa các team và làm hỏng uy tín của FinOps program.
Có thể backfill tag cho resource đã chạy nhiều tháng không?
Về mặt kỹ thuật có (bằng script boto3 batch tag), nhưng thực tế rất khó vì chủ resource đã đổi team, project đã kết thúc, không ai còn biết resource của ai. Cách duy nhất bền vững là chặn resource thiếu tag ngay từ khâu provisioning bằng Terraform module + SCP + Azure Policy, như hướng dẫn ở phần Thực thi tag trong bài này.
Hướng dẫn chi tiết cách tối ưu chi phí Kubernetes trên EKS, AKS, GKE năm 2026. Bao gồm right-sizing với VPA, Karpenter, Spot Instance và OpenCost/Kubecost — tiết kiệm 40-60% chi phí mà không ảnh hưởng hiệu năng.
