Azure Kaynak Grubu: Etiket, Taşıma ve Kilit Rehberi

Neden kaynak grubu yönetişimi?

Kaynak grubu, ilişkili kaynakların yaşam döngüsünü tutan kaptır. Ama kabı açtığınızda üç soruyla karşılaşırsınız: Bu kaynak hangi projeye/maliyet merkezine ait? Yanlış grupta oluşturduysam ne yaparım? Birinin yanlışlıkla silmesini nasıl önlerim? Azure bu üç soruya üç ayrı ama birbirini tamamlayan cevap verir. Etiketlerle sorumluluğu işaretler, taşımayla düzeltir, kilitlerle korursunuz. Önemli bir ayrım: bu üçü yönetim düzlemi (control plane) araçlarıdır; yani Azure Resource Manager üzerinden kaynağın kendisini yönetirler, içindeki veriyi (blob içeriği, veritabanı kayıtları) doğrudan korumazlar. Bunu baştan netleştirmek, ileride “kilit koydum ama veri silindi” sürprizini önler.

Etiketler (Tags): düzen ve maliyet tek anahtarda

Etiket, kaynağa iliştirdiğiniz basit bir anahtar–değer çiftidir: Ortam=Uretim, MaliyetMerkezi=00123, Sahip=altyapi gibi. Kaynaklara, kaynak gruplarına ve aboneliklere uygulanır; yönetim gruplarına uygulanmaz. Sınırları bilmek önemli: her kaynakta en fazla 50 etiket olabilir, etiket adı 512, değeri 256 karaktere kadar (depolama hesaplarında ad sınırı 128). En çok tökezlenen nokta şudur: etiketler miras kalmaz. Kaynak grubuna Ortam=Uretim yazmanız, içindeki VM’in o etiketi otomatik almasını sağlamaz. Grup genelinde tutarlılık istiyorsanız Azure Policy ile zorlamanız gerekir — bu, 6. günün konusu.

Portal adımları

1. Kaynak grubunu aç → sol menüde Etiketler.
2. Ad ve değer gir (örn. Ortam / Test), Uygula‘ya bas.
3. Birden çok kaynağı topluca etiketlemek için üstteki aramadan “Etiketler” hizmetini açıp kaynakları seçip toplu atama yapabilirsin.

Azure CLI ve PowerShell karşılığı

CLI’da iki komut var: az tag create mevcut tüm etiketleri değiştirir; az tag update ise --operation ile Merge/Replace/Delete yapar. Günlük işte en çok Merge kullanılır, çünkü var olan etiketleri bozmadan yenisini ekler.

# Bir depolama hesabının ID'sini al, sonra etiketle
resource=$(az resource show -g rg-egitim-01 -n stegitim01 \
  --resource-type Microsoft.Storage/storageAccounts --query "id" -o tsv)

# Var olan etiketleri koruyarak ekle (Merge)
az tag update --resource-id $resource --operation Merge \
  --tags Ortam=Test MaliyetMerkezi=00123

# Kaynak grubunu doğrudan etiketle
az group update -n rg-egitim-01 --set tags.Ortam=Test tags.Sahip=altyapi

# PowerShell
$r = Get-AzResource -Name stegitim01 -ResourceGroupName rg-egitim-01
Update-AzTag -ResourceId $r.Id -Tag @{ "Ortam"="Test"; "MaliyetMerkezi"="00123" } -Operation Merge

Etikete göre filtrelemek, raporlamanın yarısıdır: az resource list --tag MaliyetMerkezi=00123 --query "[].name" ya da az group list --tag Ortam=Test. Aynı etiketler faturada da görünür; maliyeti maliyet merkezine veya ortama göre gruplamak, ay sonu “bu para nereye gitti?” sorusunun tek cevabıdır. Bir uyarı: etiketler düz metin saklanır, parola/gizli değer koymayın.

Kaynakları taşıma (Move): yanlış grubu düzeltmek

Kaynağı yanlış grupta oluşturmak olağan. İyi haber: taşıma destekleniyor ve doğru yapıldığında kesinti yaratmıyor. Kritik iki gerçeği baştan oturtalım. Birincisi, taşıma kaynağın fiziksel bölgesini değiştirmez — yalnızca mantıksal grubunu değiştirir; West Europe’daki bir VM taşımadan sonra yine West Europe’da kalır. İkincisi, kaynağın ID’si değişir; script’lerde, ARM şablonlarında ve panolarda eski ID’ye referans varsa güncellemeniz gerekir.

Önce doğrula, sonra taşı

Taşımayı tetiklemeden sonucu modellemek için doğrulama eylemini kullanın. Başarılıysa boş sonuç, başarısızsa nedeni açıklayan bir hata döner:

# Taşımayı önce doğrula (gerçekten taşımaz)
az resource invoke-action --action validateMoveResources \
  --ids "/subscriptions/<abonelik-id>/resourceGroups/rg-kaynak" \
  --request-body '{ "resources": ["/subscriptions/<abonelik-id>/resourceGroups/rg-kaynak/providers/Microsoft.Storage/storageAccounts/stegitim01"], "targetResourceGroup": "/subscriptions/<abonelik-id>/resourceGroups/rg-hedef" }'

# Doğrulama geçtiyse taşı: --ids boşlukla ayrılmış kaynak ID listesi alır
webapp=$(az resource show -g rg-kaynak -n ornekSite --resource-type "Microsoft.Web/sites" --query id -o tsv)
az resource move --destination-group rg-hedef --ids $webapp

# PowerShell
$res = Get-AzResource -ResourceGroupName rg-kaynak -Name stegitim01
Move-AzResource -DestinationResourceGroupName rg-hedef -ResourceId $res.ResourceId

Birkaç kural işi kurtarır: Kaynak ve bağımlı kaynakları birlikte taşınır; istekte yalnızca üst düzey (parent) kaynakları belirtirsiniz. İşlem sırasında hem kaynak hem hedef grup kilitlenir (en fazla 4 saat; çoğu taşıma çok daha hızlı). Ve en önemlisi: kaynak, hedef grup veya abonelikte bir Read-only kilit varsa taşıma engellenir — bu da bizi günün son konusuna götürüyor.

Kilitler (Locks): kazara silmeye karşı sigorta

Bir kaynağı silmek genellikle tek tıktır; yanlış kaynağa yapılan o tek tık ise gece yarısı çağrısıdır. Azure kilitleri tam bu yüzden var. İki tür vardır ve portaldaki adlarıyla CLI adları farklıdır, bunu karıştırmayın:

• Delete (CLI: CanNotDelete): yetkili kullanıcılar kaynağı okuyabilir ve değiştirebilir, ama silemez.
• Read-only (CLI: ReadOnly): yetkili kullanıcılar yalnızca okuyabilir; silme de güncelleme de engellenir. Etkisi, herkesi Reader rolüne indirmeye benzer.

Kilitlerin iki önemli özelliği var. Birincisi, rol izinlerini geçersiz kılarlar: Owner olsanız bile Delete kilidi varken silemezsiniz; bu RBAC’den farklı, ek bir güvenlik katmanıdır. İkincisi, miras kalırlar: kaynak grubuna koyduğunuz kilit, içindeki ve sonradan eklenen tüm kaynaklara uygulanır; miras zincirinde en kısıtlayıcı kilit kazanır.

Portal adımları ve komutlar

1. Kaynak grubu veya kaynak → sol menü Kilitler → Ekle.
2. Ad ver, türü seç (Delete / Read-only), kaydet.

# Kaynak grubuna silme kilidi
az lock create --name KilitGrup --lock-type CanNotDelete \
  --resource-group rg-egitim-01

# Tek bir kaynağa salt-okunur kilit
az lock create --name KilitSite --lock-type ReadOnly \
  --resource-group rg-egitim-01 \
  --resource-name ornekSite --resource-type Microsoft.Web/sites

# Kilidi kaldır (silmeden önce şart)
lockid=$(az lock show --name KilitGrup --resource-group rg-egitim-01 --query id -o tsv)
az lock delete --ids $lockid

# PowerShell
New-AzResourceLock -LockName KilitGrup -LockLevel CanNotDelete -ResourceGroupName rg-egitim-01
$lockId = (Get-AzResourceLock -ResourceGroupName rg-egitim-01).LockId
Remove-AzResourceLock -LockId $lockId

Bir tuzağa dikkat: Read-only kilit “zararsız” sanılır ama bazı görünürde salt-okunur işlemler aslında yazma gerektirir. Örneğin depolama hesabında Read-only kilit, hesap anahtarlarını listelemeyi (List Keys bir POST çağrısıdır) engeller; o durumda blob/kuyruk verisine Entra kimliğiyle erişmeniz gerekir. Yine Read-only kilit, VM başlatma/yeniden başlatma gibi işlemleri de bloklar. Kilit koymadan önce “bu kaynakta hangi rutin işlemleri yapıyorum?” diye düşünün.

Güvenlik ve maliyet notu

Üretimde her kritik kaynak grubuna en az Delete kilidi koymak, bedava bir sigortadır — kilitlerin maliyeti yoktur. Read-only kilidi ise yalnızca gerçekten dondurmak istediğiniz, değişmeyecek kaynaklarda kullanın; aksi halde ekibin rutin işlerini kırarsınız. Kilit oluşturup kaldırmak için Microsoft.Authorization/locks/* izni gerekir; bu, Owner ve User Access Administrator rollerinde vardır. Maliyet tarafında etiketler sizin en güçlü aracınız: MaliyetMerkezi ve Ortam etiketlerini tutarlı uygularsanız, Cost Management’ta harcamayı bu boyutlara göre ayrıştırabilirsiniz. Gün sonunda deneme kaynaklarını silmeyi unutmayın — ama önce kilitleri kaldırın, yoksa silme komutu kilide takılır: az group delete --name rg-egitim-01 --yes --no-wait.

Mini ödev

rg-egitim-01 içindeki depolama hesabına Ortam=Test ve MaliyetMerkezi=00123 etiketlerini Merge ile ekle. Sonra ikinci bir grup (rg-egitim-02) oluştur ve bu depolama hesabını önce doğrulayıp oraya taşı; taşımadan sonra kaynağın bölgesinin değişmediğini portalda doğrula. Son olarak rg-egitim-02‘ye bir CanNotDelete kilidi koy, grubu silmeyi dene (engellenmeli), kilidi kaldır ve iki grubu da sil. Hangi adımda hangi hatayı aldığını bir cümleyle not et.

Etiketler kaynak grubundan kaynaklara otomatik geçer mi?

Hayır. Etiketler miras kalmaz. Grup genelinde tutarlılık istiyorsanız Azure Policy ile zorlamanız gerekir.

Kaynağı taşımak bölgesini değiştirir mi?

Hayır. Taşıma yalnızca kaynağın mantıksal grubunu değiştirir; fiziksel bölge aynı kalır. Bölge değiştirmek için Azure Resource Mover gibi ayrı bir yol gerekir.

Delete ile Read-only kilit arasındaki fark nedir?

Delete (CanNotDelete) yalnızca silmeyi engeller, değişikliğe izin verir. Read-only (ReadOnly) hem silmeyi hem güncellemeyi engeller, yalnızca okumaya izin verir.

Kilit, kaynağın içindeki veriyi korur mu?

Hayır. Kilitler yönetim düzlemi (control plane) işlemlerine uygulanır; blob içeriği gibi veri düzlemi işlemlerini doğrudan korumaz.

Değerlendirmem

Bu üç aracı birlikte düşünün: etiketle düzenle, gerektiğinde güvenle taşı, kritik olanı kilitle. Benim ortamımda varsayılan refleks şu: her yeni kaynak grubunda ilk iş Ortam ve Sahip etiketleri, üretimdeyse hemen bir Delete kilidi. Bu dersteki tüm komut söz dizimlerini güncel Microsoft Learn dokümantasyonuna karşı doğruladım; kendi abonenizde çalıştırırken yalnızca kaynak adlarını ve abonelik ID’sini kendinize uyarlayın. Dördüncü günde kimlik tarafına geçiyoruz: Microsoft Entra ID’de kullanıcılar ve gruplar. Yönetişimin “kim, neye erişebilir?” ayağı orada başlıyor.