מדריך FinOps מעשי ל-Cost Allocation Tags ב-AWS מולטי-אקאונט: טקסונומיה בת 6 מפתחות, Tag Policies, SCP, Config, CUR ב-Athena, Cost Categories ואלוקציה של משאבים משותפים ב-2026.
עודכן: 7 ביולי 2026
תגי Cost Allocation ב-AWS הם מטא-נתונים בפורמט מפתח:ערך שמופעלים ב-Billing Console כדי לחלק כל שורת חיוב ב-Cost and Usage Report (CUR) לפי צוות, מוצר, סביבה או lifecycle. בסביבת מולטי-אקאונט הם הכלי היחיד שמאפשר chargeback אמיתי מעבר לגבולות ה-Payer. כדי שהם יעבדו ב-2026 צריך שילוב של Tag Policies ברמת ה-Organization, אכיפת SCP על משאבים חסרי תגים, ו-normalization ב-CUR. זה לא רק "להגיד לצוותים לתייג" (הלוואי שזה היה מספיק).
תג Cost Allocation הוא בעצם תג רגיל ב-AWS (זוג מפתח:ערך) שהופעל במפורש במסך Cost Allocation Tags תחת ה-Billing Console של Management Account. עד שלא הפעלתם אותו, הוא שקוף לחלוטין בכל הקשור לחיוב. אחרי ההפעלה, הוא מופיע כעמודה נפרדת ב-Cost and Usage Report (CUR), ב-Cost Explorer, וב-Budgets. יש שני סוגים:
Environment=prod). דורש הפעלה ידנית לכל מפתח.aws:createdBy, aws:cloudformation:stack-name. פחות שימושיים ל-chargeback אבל טובים ל-drift detection.הנקודה שגורמת ל-90% מהצוותים להיכשל בפרויקט התיוג הראשון: ההפעלה אינה רטרואקטיבית. אם הפעלתם תג CostCenter ב-1 בפברואר, החל מאותו יום ה-CUR יכיל עמודה resource_tags_user_cost_center. עבור ינואר, העמודה תופיע ריקה גם אם המשאבים היו מתויגים בפועל. בסביבת מולטי-אקאונט זה קריטי. אז לפני שאתם מבטיחים דוח chargeback לפיננסים, ודאו שהפעלתם את כל התגים לפחות 30-60 יום מראש. אם החברה עוברת snapshot רבעוני, זו הסיבה שהרבעון הראשון תמיד ייראה חסר (אני נכוותי בזה פעמיים בפרויקטים שונים, זה כואב).
ההפעלה נעשית רק מ-Management Account (ה-Payer) של ה-Organization, ורק על ידי משתמש עם הרשאת aws-portal:ModifyBilling. יש שני מסלולים:
# הפעלת תגים דרך AWS CLI. יש להריץ מ-Management Account
aws ce update-cost-allocation-tags-status \
--cost-allocation-tags-status \
TagKey=Environment,Status=Active \
TagKey=CostCenter,Status=Active \
TagKey=Owner,Status=Active \
TagKey=Project,Status=Active \
TagKey=Application,Status=Active \
TagKey=DataClassification,Status=Active \
--region us-east-1
אם אתם מנהלים את הכל ב-Terraform, מומלץ להוסיף resource מסוג aws_ce_cost_allocation_tag (זמין מ-AWS Provider 5.20 והלאה) לכל מפתח:
resource "aws_ce_cost_allocation_tag" "core_tags" {
for_each = toset([
"Environment",
"CostCenter",
"Owner",
"Project",
"Application",
"DataClassification",
])
tag_key = each.value
status = "Active"
}
מהניסיון שלי בעבודה עם ארגונים שיש להם 40-800 חשבונות ב-Organization אחד, טקסונומיית התיוג היא ההחלטה הכי חשובה בפרויקט ה-FinOps כולו, ואי אפשר לתקן אותה אחר כך בלי כאב עצום. כלל האצבע: פחות זה יותר. שישה עד שמונה מפתחות מנדטוריים הם המקסימום שהצוותים יכולים לתחזק ברמת דיוק של 95%+. כל מה שמעבר, הופך לעמודה של NULLs ב-CUR.
הטקסונומיה הבסיסית שאני ממליצה עליה ב-2026:
| מפתח | מטרה | ערכים לדוגמה | מנדטורי? |
|---|---|---|---|
Environment | הפרדת prod/non-prod ל-guardrails ותקציב | prod, staging, dev, sandbox | כן |
CostCenter | Chargeback ליחידה עסקית או פיננסית | CC-1042, CC-2001 | כן |
Owner | מייל צוות/DL, למי לצלצל ב-3 בבוקר | [email protected] | כן |
Project | Chargeback ברמת פרויקט/יוזמה | checkout-v2, ml-recs | כן |
Application | מיפוי CMDB/service catalog | orders-api, billing-worker | כן |
DataClassification | Compliance ו-tiering | public, internal, pii, phi | כן |
ManagedBy | IaC vs manual, לזיהוי drift | terraform, cloudformation, manual | מומלץ |
ExpirationDate | Sandbox ומשאבי POC | 2026-08-31 | אופציונלי |
שימו לב שאין לי תג ל-Team נפרד, כי Owner (מייל צוות) מספק את אותו מידע בלי לפתוח מלחמת reorg מדי חצי שנה. גם אין לי Region. אותו נתון כבר קיים ב-CUR בעמודת product_region ואין טעם לשכפל אותו. עקרון פשוט: תג רק מה שאי אפשר לגזור אחרת.
לצוותים שבונים אסטרטגיה כזו לראשונה, ה-מדריך Shift-Left FinOps עם Terraform ו-Infracost משלים את הפאזל, כי אכיפת תגים בפייפליין CI (לפני הפריסה) חוסכת את כל הכאב של תיקון רטרואקטיבי.
Tag Policies הם feature של AWS Organizations שמאפשר להגדיר ברמת ה-OU (Organizational Unit) איזה מפתחות תגים מותרים, אילו ערכים חוקיים לכל מפתח, ואיזה סוגי משאבים חייבים לציית. שימו לב שזה לא מנגנון אכיפה בפני עצמו. Tag Policy יכולה לדווח על non-compliance, ואופציונלית לחסום שינוי שיוצר תג לא-תואם, אך היא לא מונעת יצירת משאב חדש בלי תגים בכלל.
דוגמה של Tag Policy מלאה שאני מפיצה על OU של Production:
{
"tags": {
"environment": {
"tag_key": {
"@@assign": "Environment"
},
"tag_value": {
"@@assign": ["prod", "staging", "dev", "sandbox"]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"rds:db",
"s3:bucket",
"lambda:function"
]
}
},
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": ["CC-[0-9]{4}"]
},
"enforced_for": {
"@@assign": ["ec2:instance", "rds:db", "s3:bucket"]
}
}
}
}
שני דברים שכדאי לדעת שלא כתובים בבירור בתיעוד. ראשית, enforced_for חוסם רק שינוי של תג קיים לערך לא-תואם. הוא לא חוסם יצירה של משאב בלי התג בכלל. שנית, Regex ב-tag_value נתמך רק מאמצע 2024. לחסימה אמיתית של משאבים לא-מתויגים, תזדקקו ל-SCP. עיינו ב-תיעוד הרשמי של AWS על Tag Policies לפרטים המלאים על סינטקס.
אכיפה אמיתית של תיוג ב-AWS דורשת שכבות. אף שכבה בפני עצמה לא מספיקה, ויחד הן מגיעות ל-compliance של 95%+ בטווח של 3-6 חודשים.
הדרך הכי זולה ופשוטה למנוע 80% מהחוסרים היא להגדיר default_tags ברמת ה-provider. כל resource שנוצר דרך ה-provider יורש אותם אוטומטית:
provider "aws" {
region = "eu-west-1"
default_tags {
tags = {
Environment = var.environment
CostCenter = var.cost_center
Owner = var.team_email
Project = var.project_name
Application = var.app_name
DataClassification = var.data_classification
ManagedBy = "terraform"
TerraformRepo = "github.com/acme/infra-live"
}
}
}
SCP שדוחה יצירת EC2, RDS, ו-S3 buckets בלי המפתחות המנדטוריים:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRunInstancesWithoutRequiredTags",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"Null": {
"aws:RequestTag/Environment": "true",
"aws:RequestTag/CostCenter": "true",
"aws:RequestTag/Owner": "true"
}
}
}
]
}
שני managed rules של Config מספקים כיסוי טוב: required-tags מזהה משאבים חסרי תגים מנדטוריים, ו-ec2-instance-managed-by-systems-manager מזהה instances שנוצרו ידנית. יחד עם EventBridge rule שמפעילה Lambda שממיילת ל-Owner בכל non-compliance, מקבלים לולאת feedback שגורמת לצוותים לתקן בעצמם. גישה זו משלבת יפה עם מעבר ל-AWS Graviton, כי בזמן ההחלפה של instance types קל להוסיף גם את התגים החסרים.
Cost and Usage Report הוא ה-source of truth, לא Cost Explorer. Cost Explorer מציג אגרגציה חלקית עם עד 12 חודשי היסטוריה, ולא נותן לכם JOIN לנתוני CMDB או HR. CUR הוא Parquet ב-S3 עם שורה לכל שילוב של resource, hour ו-usage type, ומתחבר ישירות ל-Athena, Redshift, או Snowflake.
שאילתת Athena בסיסית ל-chargeback חודשי לפי CostCenter:
SELECT
bill_billing_period_start_date AS month,
COALESCE(NULLIF(resource_tags_user_cost_center, ''), 'UNTAGGED') AS cost_center,
line_item_product_code AS service,
SUM(line_item_unblended_cost) AS unblended_usd,
SUM(line_item_net_unblended_cost) AS net_after_discounts_usd
FROM cur_v2
WHERE bill_billing_period_start_date >= date '2026-01-01'
AND line_item_line_item_type IN ('Usage', 'SavingsPlanCoveredUsage')
GROUP BY 1, 2, 3
ORDER BY 1, 4 DESC;
שלושה דגשים ל-chargeback ברמת ארגון (הרבה תוכניות FinOps מפילות אותם בשנה הראשונה):
line_item_net_unblended_cost. הוא כולל את הנחות ה-Savings Plans ו-Reserved Instances. הצוותים שלכם צריכים לראות את המחיר שהחברה משלמת בפועל, לא את list price. לניתוח מעמיק של הבחירה בין השניים, ראו את המדריך שלנו על Savings Plans מול Reserved Instances.line_item_line_item_type = 'SavingsPlanRecurringFee' יחד עם SavingsPlanCoveredUsage, ובחשבון-נפש חדשי בצעו amortization דרך CTE. אל תציגו ל-CFO "עלות" שכוללת upfront payment של RI כפייק ב-1 בינואר.Cost Categories הם ה-feature שהופך CUR ל-chargeback אמיתי. הם מגדירים כלל business-level ("כל מה שקטגוריית service שלו EC2 וגם תג Owner=platform-team, שייך ל-Cost Center CC-9000") ונשמרים כעמודות נוספות ב-CUR עצמו. יש להם ארבעה use cases מרכזיים:
יש שני משאבים שקשה במיוחד לתייג ואי אפשר להתחמק מהם: Data Transfer ו-NAT Gateway. Data Transfer בין AZ ב-VPC לא נושא תגים כי הוא מיוחס ל-VPC, לא ל-instance. הפתרון: Cost Category שמייחסת את עלות ה-DTO לפי חלוקת CPU-hours של ה-instances באותו VPC. NAT Gateway דומה, אלוקציה לפי pod egress. פחות מדויק ממדידה אמיתית, אבל מספיק ל-chargeback ברמת שוליים של ±3% (וזה, בכנות, טוב יותר מרוב הארגונים שאני רואה).
שש טעויות שאני רואה חוזרות בכל פרויקט FinOps בהיקף מולטי-אקאונט:
Production, prod, PROD, PRD. אכפו lowercase דרך Tag Policy מהיום הראשון.לניהול תג compliance ברמת ארגון, ה-FinOps Foundation Allocation Framework נותן מבנה שלם של maturity levels. שווה קריאה לפני שאתם קובעים targets פנימיים.
לא. תג הופך ל-cost allocation tag רק מרגע ההפעלה שלו ב-Billing Console, ומהיום ההוא הוא מתחיל להופיע ב-CUR כעמודה. עבור חודשים קודמים העמודה תהיה ריקה גם אם המשאב היה מתויג. הפעילו כל תג core לפחות 60 יום לפני שהוא נדרש לדוח פורמלי.
Cost Allocation Tags הם המנגנון שמעביר את התגים אל CUR ו-Cost Explorer לצורך חלוקה כספית. Tag Policies הם מנגנון governance של AWS Organizations שמגדיר אילו מפתחות וערכים חוקיים ומדווח על non-compliance. השילוב שלהם, יחד עם SCP, נדרש לאכיפה מלאה.
שישה עד שמונה מפתחות core. פחות מזה, אין מספיק מידע ל-chargeback. יותר מזה, הצוותים מתקשים לתחזק ורמת ה-compliance צונחת מתחת ל-80%. הליבה המומלצת: Environment, CostCenter, Owner, Project, Application, DataClassification.
השתמשו ב-AWS Cost Categories עם proportional allocation לפי מדד ייחוסי, למשל אחוז ה-vCPU-hours של ה-instances ב-VPC, או אחוז ה-egress bytes של pods ב-EKS. זה לא מדויק ב-100%, אבל מספיק ל-chargeback ברמת דיוק של ±3% ומחזיר את הצוותים לשליטה בעלויות egress.
חלק מהמשאבים (Marketplace subscriptions, KMS keys שמנוהלים ע"י שירותים אחרים, ו-AWS Support fees) לא ניתנים לתיוג. חלקו אותם באמצעות Cost Categories לפי כלל business (למשל: Support fee מחולק שווה בין כל CostCenter פעיל, או Marketplace subscription משויך לחשבון שרכש). קבעו SLO של 92-95% תיוג ולא רדיפה אחרי 100%.
מדריך מעשי להחלטה בין Savings Plans ל-Reserved Instances ב-AWS לשנת 2026. השוואה בין הסוגים, חישוב נקודת איזון, תהליך רכישה עם CLI, וטעויות נפוצות שראיתי בכל אודיט FinOps.
מדריך מעשי למעבר מ-x86 ל-AWS Graviton בשנת 2026 עם שלבי מיגרציה, benchmark, תמונות Docker רב-ארכיטקטוניות, NodePool של Karpenter ושילוב עם Savings Plans.