תיוג משאבי AWS לחלוקת עלויות

הטמעת תיוג משאבים לחלוקת עלויות לפי פרויקטים וצוותים

בסוף החודש, מחלקת הכספים שולחת חשבון AWS בסך 40,000 דולר — ואף אחד לא יכול לדעת איזה צוות צרך שליש מהתקציב. מופעי EC2 ללא תגיות, דליים של S3 עם שמות כמו backup-old-2022, אשכולות RDS עם Owner שהושארו ריקים. נתקלנו בזה פעמים רבות. הפתרון הוא תמיד אותו דבר — תיוג שיטתי עם מדיניות אכיפה. זה לא על דוחות יפים. זה על הפיכת חשבון הענן מקופסה שחורה לפירוט מפורט: כמה צוות ה-backend מוציא, כמה הולך לסביבת ה-staging של פרויקט התשלומים, ומאיפה מגיע הזינוק הלא מוסבר של 3,000 דולר עבור תעבורה יוצאת. בהתבסס על הנתונים שלנו, עד 30% מעלויות הענן הולכות למשאבים לא מתויגים. זה 10,000–15,000 דולר בחודש עבור פרויקט טיפוסי. למהנדסים שלנו יש הסמכות AWS וניסיון של 10+ שנים בתשתיות ענן. אנו מבטיחים שקיפות עלויות לאחר הטמעת מערכת התיוג.

למה פשוט הוספת תגיות לא עובדת

הניסיון הנפוץ ביותר הוא לומר למפתחים "תייגו משאבים בעת יצירתם" ולהוסיף זאת לרשימת הבדיקות של ה-PR. שלושה חודשים לאחר מכן, 40% מהמשאבים עדיין לא מתויגים. מישהו יצר מופע ידנית דרך הקונסולה, הריץ terraform apply ללא המשתנים הנדרשים, או פשוט שכח.

המלכוד השני הוא טקסונומיה לא עקבית. צוות אחד כותב environment: prod, אחר env: production, ושלישי Env: Production. AWS Cost Explorer לא ממזג אותם אוטומטית. הדוח מציג שלוש שורות לא קשורות במקום אחת.

הבעיה השלישית היא שתגיות לא עוברות בירושה. אם Terraform יוצר Auto Scaling Group ללא propagate_at_launch = true, מופעי EC2 מאותה קבוצה מופיעים ללא תגיות. ה-ASG עצמו מתויג כראוי.

איך לבנות אסטרטגיית תיוג

אנחנו מתחילים בביקורת של המצב הנוכחי. השתמשו בפקודה זו: aws resourcegroupstaggingapi get-resources --resource-type-filters ec2:instance --query 'ResourceTagMappingList[?Tags==[]]'. זה מראה כמה משאבים אין להם תגיות כלל. בפרויקט טיפוסי, זה 30–50%.

לאחר מכן אנו מגדירים תגיות חובה. סט עבודה מינימלי:

לאחר הסכמה על הטקסונומיה, אנו מיישמים אותה ברמת ה-IaC. ב-Terraform, אנו מוסיפים default_tags בבלוק ה-provider:

provider "aws" {
  region = var.aws_region
  default_tags {
    tags = {
      project     = var.project_name
      team        = var.team_name
      environment = var.environment
      managed-by  = "terraform"
    }
  }
}

זה מבטיח ירושת תגיות לכל המשאבים שנוצרים ללא ציון מפורש בכל מודול. עבור ASG, אנו מוסיפים provider "aws" { region = var.aws_region default_tags { tags = { project = var.project_name team = var.team_name environment = var.environment managed-by = "terraform" } } } :

resource "aws_autoscaling_group" "app" {
  # ...
  tag {
    key                 = "project"
    value               = var.project_name
    propagate_at_launch = true
  }
}

לאכיפה, אנו מפעילים את AWS Config Rule propagate_at_launch. משאב ללא תגיות חובה מסומן כ-NON_COMPLIANT. אנו יכולים להגדיר התראה ב-CloudWatch או מדיניות בידוד אוטומטית דרך AWS Config Remediations.

מה לעשות עם משאבים קיימים

תיוג רטרוספקטיבי הוא משימה נפרדת. הגישות כוללות סקריפטים ב-boto3 שעוברים על כל האזורים והשירותים, ומוסיפים תגיות לפי כללים (לדוגמה, לפי resource "aws_autoscaling_group" "app" { # ... tag { key = "project" value = var.project_name propagate_at_launch = true } } מתפקיד ה-IAM או לפי שם קבוצת האבטחה). אנו משתמשים בשילוב של required-tags עם ייצוא מקדים של רשימת המשאבים. עבור דליים של S3 שנוצרו ללא תגיות, אנו משתמשים בסקריפט נפרד שקורא את שם הדלי ומחיל תגיות לפי מסכה (לדוגמה, Owner → aws resourcegroupstaggingapi tag-resources). הריצו זאת בחלון תחזוקה וראשית על סביבה שאינה production.

מדיניות תגיות ב-AWS Organizations

אם לחשבון יש מספר צוותים או שהוא משתמש במבנה רב-חשבונות, Tag Policies ברמת ה-Organization הם הדרך היחידה להבטיח עקביות. לפי תיעוד AWS על Tag Policies, Tag Policies מגדירים ערכים מותרים למפתחות ספציפיים. מדיניות:

{
  "tags": {
    "environment": {
      "tag_key": {
        "@@assign": "environment"
      },
      "tag_value": {
        "@@assign": [
          "production",
          "staging",
          "development",
          "testing"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "rds:db",
          "s3:bucket"
        ]
      }
    }
  }
}

לאחר החלת המדיניות, ערך כמו logs-* יידחה. רק environment: production, team: infra מותר. זה מחמיר, אבל בדיוק מה שצריך לחלוקת עלויות עובדת. המהנדסים שלנו מגדירים מדיניות כזו תוך התחשבות בנוף הקיים.

דוחות והדמיה

לאחר שבועיים עד שלושה שבועות של עבודה עם תגיות, AWS Cost Explorer מתחיל לספק נתונים שימושיים. אנו מגדירים Cost Allocation Tags בקונסולת החיוב. רק אז תגיות מופיעות בדוחות. ללא שלב זה, תגיות קיימות אבל Cost Explorer לא רואה אותן.

לניתוח מפורט יותר, אנו מייצאים Cost and Usage Reports ל-S3 ובונים שאילתות Athena:

SELECT resource_tags_user_project AS project, resource_tags_user_team AS team, SUM(line_item_unblended_cost) AS total_cost
FROM cur_data
WHERE line_item_usage_start_date >= CURRENT_DATE - INTERVAL '90' DAY
GROUP BY 1, 2
ORDER BY 3 DESC;

זה זול יותר מ-Cloudability או Apptio אם ההיקף לא דורש כלים ארגוניים.

באיזו גישת אכיפה לבחור

בדיקת PR ידנית עובדת בקנה מידה קטן אבל מפספסת שגיאות במהלך פריסות דרך הקונסולה. AWS Config Rules חוסמות משאבים לא תואמים באופן מרכזי אבל דורשות כללים לכל שירות. Tag Policies מבטיחים טקסונומיה אחידה ברמת החשבון אבל לא מתקנים משאבים שכבר נוצרו. בדיקות CI ב-Terraform (tflint, checkov) מגינות בשלב הקוד אבל לא מכסות שינויים ידניים. אנו משלבים Tag Policies עם בדיקות CI. זה מכסה 95% מהתרחישים.

שלבי העבודה

תוכנית ההטמעה מחולקת לשלבים עם לוחות זמנים ותוצרים ספציפיים:

לוחות הזמנים תלויים במספר החשבונות ובמורכבות ה-IaC. עבור חשבון יחיד עם Terraform, זה 1–2 שבועות. עבור רב-חשבונות עם Organizations ומספר צוותים, זה 3–6 שבועות.

מה כלול בעבודה

• תיעוד טקסונומיית התגיות (מפתחות חובה ואופציונליים, ערכים מותרים)
• עדכון מודולי Terraform ותצורות pipeline לבדיקות תגיות אוטומטיות
• הגדרת AWS Config Rules ו-Tag Policies עם זיהוי והתראות
• סקריפטים לתיוג רטרוספקטיבי של משאבים קיימים
• שאילתות Athena מוכנות ולוחות מחוונים לדיווח עלויות
• הדרכת צוות (1–2 שיחות) ותמיכה לחודש לאחר ההטמעה

בקשו ייעוץ: נעריך את הפרויקט שלכם תוך יומיים ונציע תוכנית הטמעה מלאה. צרו קשר כדי להביא סדר לעלויות הענן שלכם. קבלו ביקורת של מצב התיוג הנוכחי — נראה לכם כמה כסף דולף על משאבים לא מתויגים.