Bulut Etiketleme ile Maliyet Tahsisi: AWS, Azure ve GCP Rehberi

Bulut Etiketleme Neden FinOps'un Temel Taşıdır?

Bulut faturanız her ay geliyor, ama şu soruyu gerçekten cevaplayabiliyor musunuz: "Bu harcamanın ne kadarı pazarlama ekibinin geliştirme ortamından, ne kadarı ürün ekibinin production sunucularından kaynaklanıyor?" Eğer cevabınız "bilmiyorum" ise — yalnız değilsiniz. Araştırmalar, kurumların %82'sinin yetersiz kaynak görünürlüğü nedeniyle gereksiz bulut harcaması yaptığını gösteriyor.

Açıkçası, sorunun kaynağı genellikle teknik değil. Organizasyonel: tutarlı bir etiketleme (tagging) stratejisinin yokluğu. Etiketler, bulut kaynaklarına eklenen basit anahtar-değer çiftleridir. Ama doğru kullanıldığında maliyet tahsisi, otomasyon, güvenlik ve uyumluluk için vazgeçilmez bir veri katmanı oluştururlar.

2026 itibarıyla FinOps Foundation'ın raporuna göre, olgun FinOps programları bulut israfını %15-20 seviyesine düşürürken, hiçbir FinOps uygulaması olmayan kuruluşlar harcamalarının %32-40'ını boşa harcıyor. Bu farkın en büyük nedenlerinden biri? Tutarlı etiketleme.

Bu rehberde AWS, Azure ve GCP'de etiketleme stratejisi oluşturmayı, zorunlu etiketleri belirlemeyi, Terraform ile otomatik etiketlemeyi ve showback/chargeback modellerine geçişi adım adım ele alacağız. Hadi başlayalım.

Zorunlu Etiket Taksonomisi: Hangi Etiketleri Kullanmalısınız?

Etiketleme stratejisinin ilk adımı, tüm ekiplerin üzerinde anlaştığı bir zorunlu etiket seti tanımlamaktır. Burada çok önemli bir uyarı var: 20 farklı zorunlu etiket tanımlamaya çalışmayın. Ekipler buna direnecek ve veri kalitesi düşecektir.

5-8 zorunlu etiket ideal denge noktasıdır.

Temel Zorunlu Etiketler

İşte her bulut kaynağında bulunması gereken minimum etiket seti:

• environment: Kaynağın çalıştığı ortam (production, staging, development, test). Bu etiket, geliştirme ortamlarını mesai saatleri dışında otomatik olarak kapatarak %65-70 tasarruf sağlayan otomasyon senaryolarının temelidir. (Evet, doğru okudunuz — sadece dev ortamlarını gece kapatmak bile bu kadar fark yaratıyor.)
• owner: Kaynaktan sorumlu ekip veya kişi. Kişisel e-posta yerine ekip dağıtım listesi kullanın (ör. backend-team, data-engineering). Olay anında kime ulaşılacağını belirler.
• cost-center: Finans sisteminizdeki maliyet merkeziyle birebir eşleşen değer. Showback ve chargeback raporlarını oluşturmak için kritik öneme sahiptir.
• application: Kaynağın ait olduğu uygulama veya hizmet adı (ör. payment-api, user-service). Maliyetleri ve olayları doğrudan sistemlere eşlemeyi sağlar.
• project: İlgili proje veya iş girişimi (ör. crm-migration, data-lake-v2). Finans ekibinin harcamaları departman veya proje bazında ayırmasını sağlar.
• managed-by: Kaynağın nasıl yönetildiği (terraform, cloudformation, manual). IaC dışı kaynakları tespit etmek için gerçekten önemli — çünkü manuel oluşturulan kaynaklar genellikle unutulanlar oluyor.

Opsiyonel Ama Değerli Etiketler

• data-classification: Veri hassasiyet seviyesi (public, internal, confidential, restricted). Güvenlik ve uyumluluk için.
• backup-policy: Yedekleme gereksinimleri (daily, weekly, none). Otomatik yedekleme politikalarını tetiklemek için.
• expiry-date: Geçici kaynaklar için bitiş tarihi. Birçok büyük şirket bu etiketi kullanarak geçici kaynakları otomatik temizliyor ve inanılmaz derecede etkili.

Adlandırma Kuralları

Tutarsız adlandırma, etiketleme stratejisini tamamen işe yaramaz hale getirir. Şu kurallara mutlaka uyun:

• Etiket anahtarlarında ve değerlerinde küçük harf kullanın. Environment:Production ve environment:production bazı araçlarda farklı etiketler olarak değerlendirilir — bu da raporlamayı mahveder.
• Kısaltmalardan kaçının. Dokümante edilmemiş kısaltmalar ekipler arasında her zaman karışıklık yaratır.
• Özel karakter ve boşluk kullanmayın — bazı AWS hizmetlerinde beklenmedik sorunlara yol açabilir.
• Ayırıcı olarak tire (-) kullanın (ör. cost-center, data-classification).

AWS'de Maliyet Tahsisi Etiketleri

AWS, etiketleme konusunda en gelişmiş yerel araçlara sahip bulut sağlayıcıdır. İşte bilmeniz gerekenler:

Cost Allocation Tags'ı Aktifleştirme

AWS'de etiketleri oluşturmak tek başına yeterli değildir — bunları Cost Allocation Tag olarak aktifleştirmeniz gerekir. Aktifleştirilmiş etiketler AWS Cost Explorer ve fatura raporlarında görünür hale gelir. Bunu atlamak, en sık yapılan hatalardan biri.

# AWS CLI ile maliyet tahsisi etiketlerini aktifleştirme
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
  Key=environment,Status=Active \
  Key=owner,Status=Active \
  Key=cost-center,Status=Active \
  Key=application,Status=Active \
  Key=project,Status=Active

# Mevcut etiket durumlarını kontrol etme
aws ce list-cost-allocation-tags \
  --status Active \
  --type UserDefined

Aktifleştirme sonrası etiketlerin Cost Explorer'da görünmesi 24 saate kadar sürebilir. Sabırlı olun.

AWS Organizations Tag Policies

2026 itibarıyla AWS Organizations Tag Policies, CloudFormation, Terraform ve Pulumi dağıtımlarını IaC şablonları düzeyinde doğrulayabiliyor. Yani uyumsuz kaynakların oluşturulması daha kaynak yaratılmadan engelleniyor — bu gerçekten büyük bir avantaj.

{
  "tags": {
    "environment": {
      "tag_key": {
        "@@assign": "environment"
      },
      "tag_value": {
        "@@assign": [
          "production",
          "staging",
          "development",
          "test"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "rds:db",
          "s3:bucket",
          "lambda:function"
        ]
      }
    },
    "cost-center": {
      "tag_key": {
        "@@assign": "cost-center"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "rds:db",
          "s3:bucket"
        ]
      }
    }
  }
}

Bu politika, belirtilen kaynak türleri için environment etiketinin yalnızca belirli değerleri kabul etmesini ve cost-center etiketinin zorunlu olmasını sağlıyor.

AWS Config ile Etiket Uyumluluk Denetimi

# AWS Config kuralı: zorunlu etiketleri olmayan kaynakları tespit etme
aws configservice put-config-rule --config-rule \
  '{"ConfigRuleName":"required-tags-check","Source":{"Owner":"AWS","SourceIdentifier":"REQUIRED_TAGS"},"InputParameters":"{\"tag1Key\":\"environment\",\"tag2Key\":\"owner\",\"tag3Key\":\"cost-center\",\"tag4Key\":\"application\"}","Scope":{"ComplianceResourceTypes":["AWS::EC2::Instance","AWS::RDS::DBInstance","AWS::S3::Bucket","AWS::Lambda::Function"]}}'

Bu kural, belirtilen kaynak türlerinde zorunlu etiketlerin varlığını sürekli denetler ve uyumsuz kaynakları AWS Config panosunda raporlar.

Azure'da Etiketleme Stratejileri

Azure, etiketleri kaynak grubu düzeyinde bağımsız olarak uygulayabilmesi ve Azure Policy ile güçlü politika uygulama yetenekleriyle öne çıkıyor. Özellikle etiket miras alma özelliği çok pratik.

Azure Policy ile Zorunlu Etiket Uygulama

Azure Policy, etiket yokluğunda kaynak oluşturmayı doğrudan engelleyebilir veya üst kaynak grubundan etiket miras alabilir:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "notEquals": "Microsoft.Resources/subscriptions/resourceGroups"
        },
        {
          "anyOf": [
            {
              "field": "tags['environment']",
              "exists": "false"
            },
            {
              "field": "tags['cost-center']",
              "exists": "false"
            },
            {
              "field": "tags['owner']",
              "exists": "false"
            }
          ]
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Bu politika oldukça sert: environment, cost-center veya owner etiketlerinden herhangi biri eksikse kaynağın oluşturulmasını tamamen engelliyor.

Azure'da Etiket Miras Alma (Tag Inheritance)

Azure'un en güçlü özelliklerinden biri, kaynak gruplarından etiketlerin otomatik olarak alt kaynaklara miras alınabilmesi. Bu, özellikle büyük ekiplerde tutarlılığı sağlamak için harika çalışıyor:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "tags['cost-center']",
          "exists": "false"
        },
        {
          "value": "[resourceGroup().tags['cost-center']]",
          "notEquals": ""
        }
      ]
    },
    "then": {
      "effect": "modify",
      "details": {
        "roleDefinitionIds": [
          "/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
          {
            "operation": "addOrReplace",
            "field": "tags['cost-center']",
            "value": "[resourceGroup().tags['cost-center']]"
          }
        ]
      }
    }
  }
}

Bu modify efektli politika, kaynak üzerinde cost-center etiketi yoksa üst kaynak grubundan bu değeri otomatik olarak devralır. Mevcut uyumsuz kaynaklar için de bir remediasyon görevi oluşturarak geriye dönük düzeltme yapabilirsiniz — bu özellik gerçekten hayat kurtarıcı.

Azure Kaynak Sınırlamaları

Azure, kaynak başına 50 etikete kadar izin verir. Etiketleri hem kaynak grubu düzeyinde hem de bireysel kaynak düzeyinde bağımsız olarak uygulayabilirsiniz. Azure Cost Management ise etiketlere göre filtreleme ve gruplama yaparak abonelikler arası raporlama sağlar.

GCP'de Etiketler (Labels)

Google Cloud Platform, "etiket" yerine "label" terimini kullanır. Ve bazı önemli kısıtlamalara sahiptir — bu yüzden dikkatli olmak gerekiyor:

• Kaynak başına maksimum 64 label
• Anahtar ve değerlerde yalnızca küçük harf, rakam ve tire geçerlidir — büyük harf ve alt çizgi kullanılamaz
• AWS'de geçerli olan bir etiket anahtarı (ör. CostCenter), GCP'de geçersizdir — cost-center kullanmanız gerekir

GCP'de Label Oluşturma

# GCP Compute Engine instance'a label ekleme
gcloud compute instances update my-instance \
  --update-labels=environment=production,cost-center=engineering,owner=backend-team

# GCP'de tüm label'ları listeleme
gcloud compute instances describe my-instance \
  --format="table(name, labels)"

# BigQuery veri setine label ekleme
bq update --set_label environment:production \
  --set_label cost-center:data-team \
  my_project:my_dataset

GCP Billing Export ile Maliyet Analizi

GCP'de label'lar BigQuery billing export'a otomatik olarak akar. Bu sayede son derece esnek maliyet analizi sorguları yazabilirsiniz:

-- BigQuery: Label bazında aylık maliyet raporu
SELECT
  labels.value AS cost_center,
  invoice.month AS billing_month,
  ROUND(SUM(cost), 2) AS total_cost,
  ROUND(SUM(cost) / SUM(SUM(cost)) OVER() * 100, 1) AS cost_percentage
FROM
  `my-project.billing_dataset.gcp_billing_export_v1_*`,
  UNNEST(labels) AS labels
WHERE
  labels.key = 'cost-center'
  AND invoice.month >= '202601'
GROUP BY
  cost_center, billing_month
ORDER BY
  total_cost DESC;

Bu sorgu, maliyet merkezine göre aylık harcama dağılımını ve her merkezin toplam harcamadaki yüzdesini gösterir. Oldukça güçlü bir analiz aracı.

Terraform ile Otomatik Etiketleme: Kod Olarak Etiket Politikası

Manuel etiketleme ölçeklenmez — bunu ne kadar erken kabul ederseniz o kadar iyi. Infrastructure as Code (IaC) araçlarıyla etiketleri kaynak oluşturma anında otomatik olarak uygulamak, tutarlılığın tek güvenilir yoludur.

AWS Provider default_tags

Terraform AWS provider v3.38.0+ ile gelen default_tags özelliği, provider düzeyinde tanımlanan etiketleri otomatik olarak tüm kaynaklara uygular. Bu özellik tek başına bile Terraform kullanmanın en iyi gerekçelerinden biri:

# providers.tf
provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      environment  = var.environment
      cost-center  = var.cost_center
      owner        = var.team_name
      application  = var.app_name
      managed-by   = "terraform"
      project      = var.project_name
    }
  }
}

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment environment"
  validation {
    condition     = contains(["production", "staging", "development", "test"], var.environment)
    error_message = "Environment must be one of: production, staging, development, test."
  }
}

variable "cost_center" {
  type        = string
  description = "Cost center code matching finance system"
  validation {
    condition     = can(regex("^[a-z]+-[a-z]+$", var.cost_center))
    error_message = "Cost center must follow the pattern: department-team (e.g., engineering-backend)."
  }
}

Buradaki validation blokları çok önemli: hatalı değerlerin girilmesini daha terraform plan aşamasında engelliyor. Biri environment = "prod" yazarsa, Terraform hata verecek ve doğru değeri kullanmasını zorunlu kılacak.

Azure Provider ile Etiketleme

# Azure kaynak grubu ve kaynaklar için etiketleme
resource "azurerm_resource_group" "main" {
  name     = "rg-${var.app_name}-${var.environment}"
  location = var.azure_region

  tags = local.common_tags
}

locals {
  common_tags = {
    environment  = var.environment
    cost-center  = var.cost_center
    owner        = var.team_name
    application  = var.app_name
    managed-by   = "terraform"
  }
}

# Tüm kaynaklarda tutarlı etiketleme
resource "azurerm_linux_virtual_machine" "app" {
  name                = "vm-${var.app_name}-${var.environment}"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_B2s"

  # ... diğer yapılandırmalar ...

  tags = merge(local.common_tags, {
    role = "application-server"
  })
}

GCP Provider ile Label Uygulama

# GCP Compute Engine instance ile label
resource "google_compute_instance" "app" {
  name         = "vm-${var.app_name}-${var.environment}"
  machine_type = "e2-medium"
  zone         = "${var.gcp_region}-a"

  labels = merge(local.common_labels, {
    role = "application-server"
  })

  # ... diğer yapılandırmalar ...
}

locals {
  common_labels = {
    environment = var.environment
    cost-center = var.cost_center
    owner       = var.team_name
    application = var.app_name
    managed-by  = "terraform"
  }
}

GCP'de label anahtar ve değerlerinin küçük harf olması zorunludur. Terraform locals bloğunda tanımladığınız değerlerin bu kurala uyduğundan emin olun — aksi halde deploy sırasında can sıkıcı hatalar alırsınız.

Etiket Politikası Uygulama: Yumuşak mı, Sert mi?

Etiketleme politikasını uygulamanın iki temel yaklaşımı vardır. Doğru strateji genellikle ikisinin bir kombinasyonudur.

Yumuşak Uygulama (Soft Enforcement)

İlk aşamada uyarı verin, engellemeyin. Ekiplere adapte olmaları için süre tanıyın. Bunu atlayıp direkt sert uygulamaya geçmek, genellikle dirençle sonuçlanır:

• AWS Config ile uyumsuz kaynakları raporlama
• Azure Policy'de audit efekti kullanma (deny yerine)
• Haftalık etiket uyumluluk raporları paylaşma
• Etiket kapsama oranını (%tagged spend) ekip bazında dashboard'a ekleme

Sert Uygulama (Hard Enforcement)

Ekipler hazır olduğunda, eksik etiketli kaynakların oluşturulmasını tamamen engelleyin:

• AWS Organizations Tag Policies ile IaC doğrulaması
• Azure Policy'de deny efekti
• Terraform validation blokları ve Open Policy Agent (OPA) entegrasyonu
• CI/CD pipeline'da Infracost ile etiket politikası doğrulaması

Shift-Left Yaklaşımı: PR Seviyesinde Etiket Kontrolü

Deneyimlerimize göre en etkili yöntem, etiket kontrolünü CI/CD pipeline'ın en erken aşamasına taşımaktır. Infracost gibi araçlar, pull request seviyesinde etiket politikası ihlallerini tespit eder ve geliştiricilere anında geri bildirim verir. Kaynak oluşturulduktan sonra temizlemeye çalışmaktan çok daha verimli.

# .github/workflows/infracost.yml - Etiket politikası kontrolü
name: Infracost Tag Policy Check
on:
  pull_request:
    paths:
      - '**/*.tf'

jobs:
  tag-policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Run Infracost with tag policies
        run: |
          infracost breakdown --path=. \
            --format=json \
            --out-file=/tmp/infracost.json

          infracost comment github \
            --path=/tmp/infracost.json \
            --repo=${{ github.repository }} \
            --pull-request=${{ github.event.pull_request.number }} \
            --github-token=${{ secrets.GITHUB_TOKEN }}

Çoklu Bulut Ortamlarında Etiketleme Zorlukları

Kuruluşların %87'si artık çoklu bulut stratejisi uyguluyor. Birden fazla sağlayıcıda tutarlı etiketleme, tahmin edeceğiniz gibi ek zorluklar getiriyor.

Sağlayıcı Farklılıkları Tablosu

Özellik	AWS Tags	Azure Tags	GCP Labels
Kaynak başına limit	50	50	64
Büyük/küçük harf	Duyarlı	Duyarlı değil (anahtar)	Yalnızca küçük harf
Karakter kısıtlaması	Esnek	Esnek	Küçük harf, rakam, tire
Kaynak grubu etiketleri	Yok	Bağımsız uygulama	Yok (proje düzeyinde label)
Politika uygulama	Tag Policies, SCP	Azure Policy	Organization Policy
Maliyet raporlama	Cost Explorer	Cost Management	BigQuery Export

Çözüm: Ortak Etiket Taksonomisi

Çoklu bulut ortamlarında tutarlılık için şu adımları izleyin:

1. En kısıtlayıcı sağlayıcıya göre standart belirleyin: GCP'nin küçük harf zorunluluğu tüm sağlayıcılarda uygulanmalı. Böylece aynı etiket formatını her yerde kullanabilirsiniz.
2. Etiket anahtarlarını normalleştirin: AWS'de CostCenter ve GCP'de cost-center yerine, her yerde cost-center kullanın.
3. Merkezi etiket kataloğu oluşturun: Tüm geçerli etiket anahtarlarını ve değerlerini tek bir yerde dokümante edin.
4. Üçüncü parti araçlar kullanın: Finout, Vantage veya CloudHealth gibi çoklu bulut FinOps platformları, farklı sağlayıcıların etiketlerini normalleştirerek birleşik maliyet görünümü sunar.

Showback'tan Chargeback'e Geçiş

Etiketleme stratejiniz olgunlaştıkça, maliyet tahsisi modeliniz de evrilmelidir. Bu geçiş genellikle üç aşamada gerçekleşir.

1. Aşama: Showback (Görünürlük)

İlk aşamada, her ekibin bulut harcamasını görünür kılın. Amaç farkındalık yaratmak, cezalandırmak değil:

• Haftalık veya aylık maliyet raporlarını ekip bazında paylaşın
• Dashboard'larda etiket bazında harcama trendlerini gösterin
• Anormal artışları işaretleyin

2. Aşama: Bilgilendirilmiş Showback

Ekiplerin harcamalarını iş değeriyle ilişkilendirmeye başladığı aşama. Burası işlerin gerçekten ilginçleştiği nokta:

• Birim maliyet metrikleri tanımlayın (ör. istek başına maliyet, kullanıcı başına maliyet)
• Ekipler arası kıyaslama (benchmarking) yapın
• Optimizasyon önerilerini maliyet raporlarına ekleyin

3. Aşama: Chargeback (Gerçek Faturalama)

Etiketleme verisi yeterince doğru ve kapsamlı olduğunda, bulut harcamalarını gerçek bütçe kalemleri olarak ekiplere tahsis edin:

• Her ekibin bulut bütçesi olsun
• Aşım durumunda yönetici onayı gerektirin
• Optimizasyondan elde edilen tasarrufları ekibin bütçesine geri yansıtın

Kritik uyarı: Chargeback'e geçmeden önce etiket kapsama oranınız %90+ olmalıdır. Aksi halde etiketlenmemiş harcamalar "sahipsiz" kalır ve kimse bunlardan sorumlu tutulmaz. Bu da modelin tamamını zayıflatır.

Etiket Kapsama Oranını Ölçme ve İzleme

Etiket kapsama oranı, herhangi bir operasyonel metrik gibi düzenli olarak izlenmelidir. Nihai hedef basit: harcamanın %100'ünün bir maliyet sahibine atfedilebilmesi.

AWS'de Etiket Kapsama Raporu

# AWS Resource Groups Tagging API ile etiketsiz kaynakları bulma
import boto3
from collections import defaultdict

client = boto3.client('resourcegroupstaggingapi')
required_tags = ['environment', 'owner', 'cost-center', 'application']

def get_untagged_resources():
    paginator = client.get_paginator('get_resources')
    results = defaultdict(list)

    for page in paginator.paginate():
        for resource in page['ResourceTagMappingList']:
            arn = resource['ResourceARN']
            existing_keys = [tag['Key'] for tag in resource.get('Tags', [])]
            missing = [t for t in required_tags if t not in existing_keys]

            if missing:
                resource_type = arn.split(':')[2]
                results[resource_type].append({
                    'arn': arn,
                    'missing_tags': missing
                })

    return results

untagged = get_untagged_resources()
for service, resources in untagged.items():
    print(f"\n{service}: {len(resources)} uyumsuz kaynak")
    for r in resources[:3]:
        print(f"  - {r['arn']}")
        print(f"    Eksik: {', '.join(r['missing_tags'])}")

Bu Python betiği, tüm AWS kaynaklarını tarar ve zorunlu etiketleri eksik olanları hizmet bazında raporlar. Bunu bir Lambda fonksiyonuna dönüştürerek haftalık otomatik raporlama kurabilirsiniz — biz de birçok projede tam olarak bunu yapıyoruz.

Sık Yapılan Hatalar ve Nasıl Önlenir

Yıllar içinde gördüğümüz en yaygın etiketleme hataları:

• Kişisel e-posta kullanmak: owner etiketinde [email protected] yerine backend-team kullanın. Kişiler ekip değiştirir, dağıtım listeleri kalıcıdır.
• Tutarsız değerler: Bir ekip env=prod, diğeri environment=production kullanırsa raporlar anlamsızlaşır. Merkezi bir değer kataloğu oluşturun ve buna sadık kalın.
• Etiketleri sonradan eklemeye çalışmak: Retroaktif etiketleme her zaman bir yakalama çalışmasıdır. IaC ile etiketleri kaynak oluşturma anında uygulayın — bu en temiz yaklaşım.
• Çok fazla zorunlu etiket: 15-20 zorunlu etiket, geliştirici deneyimini ciddi şekilde olumsuz etkiler. 5-8 ile başlayın, gerçekten ihtiyaç duydukça artırın.
• Etiketlerin güncellenmemesi: Projeler kapanır, ekipler birleşir — etiketler de güncellenmezse güncelliğini yitirir. Çeyreklik etiket denetimi yapmanızı şiddetle tavsiye ederiz.

Sıkça Sorulan Sorular (SSS)

Etiketleme stratejisi oluşturmak için hangi ekipler dahil edilmeli?

Etiketleme stratejisi yalnızca DevOps ekibinin sorumluluğu değildir — bu çok yaygın bir yanılgı. Finans (maliyet merkezleri ve bütçe kodları için), mühendislik (teknik etiketler ve IaC entegrasyonu için), güvenlik (veri sınıflandırma etiketleri için) ve yönetim (iş birimleri ve proje hiyerarşisi için) ekiplerinin birlikte çalışması gerekir. FinOps Foundation verilerine göre, başarılı FinOps uygulamalarının %78'i CTO/CIO organizasyonuna bağlıdır.

AWS, Azure ve GCP arasında etiketler nasıl standardize edilir?

En kısıtlayıcı sağlayıcının kurallarını baz alın. GCP yalnızca küçük harf, rakam ve tire kabul ettiği için tüm sağlayıcılarda bu formatı kullanın. Etiket anahtarlarını normalleştirin — her yerde cost-center kullanın, kimi yerde CostCenter kimi yerde cost_center değil. Finout veya Vantage gibi çoklu bulut FinOps araçları, farklı sağlayıcıların etiketlerini otomatik olarak normalleştirerek birleşik maliyet görünümü sunabilir.

Mevcut etiketsiz kaynakları geriye dönük etiketlemek mümkün mü?

Evet, ama kolay olduğunu söylemek yalan olur. AWS'de Resource Groups Tagging API ile toplu etiketleme, Azure'da Policy remediation görevleri ile otomatik etiketleme yapılabilir. Yine de en etkili yaklaşım IaC araçlarıyla (Terraform, CloudFormation) etiketleri kaynak oluşturma anında zorunlu kılmaktır. Mevcut kaynaklar için AWS Config veya Azure Resource Graph sorguları ile etiketsiz kaynakları tespit edip önceliklendirerek aşamalı temizlik yapın.

Etiketleme maliyetine değer mi? ROI nasıl hesaplanır?

Kesinlikle değer. Etiketleme stratejisinin doğrudan ROI'si, sağladığı maliyet görünürlüğü ve buna bağlı optimizasyonlarla ölçülür. Geliştirme ortamlarını mesai dışında otomatik kapatmak %65-70, sahipsiz kaynakları tespit edip temizlemek %10-15, ekip bazında bütçe hesap verebilirliği ise %5-10 ek tasarruf sağlar. Toplam bulut harcamanızın %30'unu israf olarak kabul ederseniz, iyi bir etiketleme stratejisi bu israfın büyük bölümünü ortaya çıkarır.

Etiketleme politikasını yumuşak uygulamadan sert uygulamaya ne zaman geçmeliyim?

Yumuşak uygulamada (audit/uyarı modu) etiket kapsama oranınızı düzenli olarak izleyin. Oran %80'in üzerine çıktığında ve ekipler sürece alıştığında, sert uygulamaya (deny/engelleme) geçiş yapabilirsiniz. Bu geçiş süreci genellikle 2-3 ay sürer. Önce kritik olmayan ortamlarda (dev/test) sert uygulamayı etkinleştirin, sonra production'a genişletin. Acele etmeyin — ekip desteği olmadan yapılan sert uygulama, sadece workaround'lara yol açar.