Azure Application Gateway Yapılandırması: Adım Adım Kurulum Rehberi

Tarafındankomut
0 Yorum

Azure ortamında bir web uygulaması yayına aldığınızda, önünüzde kaçınılmaz bir soru belirir: Trafiği nasıl yöneteceksiniz? Load balancer yeterli mi, WAF gerekiyor mu, SSL termination nerede yapılacak? İşte tam bu noktada Azure Application Gateway devreye giriyor. Basit bir yük dengeleyiciden çok daha fazlası olan bu servis, Layer 7 yük dengeleme, Web Application Firewall, SSL offloading ve URL tabanlı yönlendirme gibi özellikleri tek çatı altında topluyor. Bu yazıda gerçek dünya senaryoları üzerinden Application Gateway’i sıfırdan yapılandırmayı, ince ayarlarını ve olası sorunları ele alacağız.

Azure Application Gateway Nedir ve Ne Zaman Kullanılır?

Application Gateway, OSI modelinin 7. katmanında (uygulama katmanı) çalışan bir yük dengeleyicidir. Azure Load Balancer’dan temel farkı, HTTP/HTTPS trafiğini anlayabilmesidir. URL yoluna, host başlığına veya cookie bilgisine göre farklı backend pool’lara yönlendirme yapabilirsiniz.

Şöyle bir senaryo düşünelim: Bir e-ticaret şirketinin /api/ isteklerini containerized backend servislerine, /static/ isteklerini blob storage’a, geri kalanını ise klasik IIS sunucularına göndermesi gerekiyor. Bunu Application Gateway olmadan yönetmek gerçek bir kabus. Application Gateway ile bu URL tabanlı yönlendirme birkaç kural ile hallediliyor.

Application Gateway’in öne çıkan özellikleri:

  • Layer 7 Load Balancing: HTTP/HTTPS başlıklarını okuyup akıllı yönlendirme yapar
  • WAF (Web Application Firewall): OWASP kurallarıyla SQL injection, XSS gibi saldırıları engeller
  • SSL Termination: SSL/TLS işlemini Gateway üzerinde sonlandırarak backend sunucularının yükünü azaltır
  • URL tabanlı routing: /api, /web, /admin gibi path’lere göre farklı backend’e yönlendirme
  • Multi-site hosting: Tek Gateway üzerinden birden fazla domain yönetimi
  • Autoscaling: v2 SKU ile trafik artışına göre otomatik ölçekleme

Ön Hazırlık ve Gereksinimler

Başlamadan önce birkaç şeyi hazır etmeniz gerekiyor. Azure CLI kurulu olmalı ve ilgili subscription’a erişiminiz olmalı. Tüm örnekleri Azure CLI üzerinden yapacağız çünkü Infrastructure as Code mantığına en yakın yaklaşım bu.

# Azure CLI versiyonunu kontrol et
az --version

# Login ol
az login

# Subscription listele ve doğru subscription'ı seç
az account list --output table
az account set --subscription "Production-Subscription"

# Resource group oluştur
az group create 
  --name rg-appgw-prod 
  --location westeurope

Application Gateway için dedicated bir subnet zorunludur, başka hiçbir resource bu subnet’i paylaşamaz. En az /27 (27 IP adresi) önerilen minimum boyuttur, ancak autoscaling kullanıyorsanız /24 daha mantıklı.

# Virtual Network ve Application Gateway subnet oluştur
az network vnet create 
  --resource-group rg-appgw-prod 
  --name vnet-prod 
  --address-prefix 10.0.0.0/16 
  --subnet-name snet-appgw 
  --subnet-prefix 10.0.1.0/24

# Backend sunucuları için ayrı subnet
az network vnet subnet create 
  --resource-group rg-appgw-prod 
  --vnet-name vnet-prod 
  --name snet-backend 
  --address-prefixes 10.0.2.0/24

Public IP ve Temel Application Gateway Oluşturma

Application Gateway v2 için Standard_v2 veya WAF_v2 SKU kullanmanızı kesinlikle öneririm. v1 SKU artık deprecated sayılıyor ve yeni özellikler yalnızca v2’ye geliyor.

# Static Public IP oluştur (v2 için static zorunlu)
az network public-ip create 
  --resource-group rg-appgw-prod 
  --name pip-appgw-prod 
  --allocation-method Static 
  --sku Standard 
  --zone 1 2 3

# Application Gateway oluştur (bu işlem 5-10 dakika sürer)
az network application-gateway create 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --location westeurope 
  --sku WAF_v2 
  --capacity 2 
  --vnet-name vnet-prod 
  --subnet snet-appgw 
  --public-ip-address pip-appgw-prod 
  --frontend-port 80 
  --http-settings-port 80 
  --http-settings-protocol Http 
  --routing-rule-type Basic 
  --priority 100 
  --servers 10.0.2.10 10.0.2.11

--capacity 2 parametresi minimum instance sayısını belirtir. Autoscaling açıkken bu değer minimum kapasiteyi gösterir. Production ortamında en az 2 instance ile başlamak availability açısından önemli.

SSL/TLS Yapılandırması

Gerçek dünyada HTTP üzerinden çalışan Application Gateway görmek istemezsiniz. SSL termination yapılandıralım.

Önce sertifikanızı PFX formatına dönüştürün. Let’s Encrypt kullanıyorsanız:

# Let's Encrypt sertifikasını PFX'e dönüştür
openssl pkcs12 -export 
  -out appgw-cert.pfx 
  -inkey privkey.pem 
  -in cert.pem 
  -certfile chain.pem 
  -passout pass:SecurePassword123!

# SSL sertifikasını Application Gateway'e yükle
az network application-gateway ssl-cert create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name ssl-cert-prod 
  --cert-file ./appgw-cert.pfx 
  --cert-password "SecurePassword123!"

# HTTPS listener ekle
az network application-gateway frontend-port create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name port-443 
  --port 443

az network application-gateway http-listener create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name listener-https 
  --frontend-ip appGatewayFrontendIP 
  --frontend-port port-443 
  --ssl-cert ssl-cert-prod 
  --host-name "app.sirketim.com"

Production ortamında sertifikaları Azure Key Vault’ta tutmak ve Application Gateway’i Key Vault’a bağlamak çok daha iyi bir yaklaşım. Böylece sertifika yenileme işlemi otomatikleşir.

# Key Vault'tan sertifika referansı ile SSL cert oluştur
az network application-gateway ssl-cert create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name ssl-cert-keyvault 
  --key-vault-secret-id "https://kv-prod.vault.azure.net/secrets/appgw-cert"

URL Tabanlı Yönlendirme

Burası Application Gateway’in gerçek gücünün ortaya çıktığı yer. E-ticaret senaryomuzda /api/ ve /web/ için farklı backend pool’lar kullanalım.

# API backend pool oluştur
az network application-gateway address-pool create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name pool-api 
  --servers 10.0.2.20 10.0.2.21

# Web backend pool oluştur
az network application-gateway address-pool create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name pool-web 
  --servers 10.0.2.10 10.0.2.11

# API için HTTP settings
az network application-gateway http-settings create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name httpsettings-api 
  --port 8080 
  --protocol Http 
  --cookie-based-affinity Disabled 
  --timeout 30 
  --host-name-from-backend-pool false

# URL path map oluştur
az network application-gateway url-path-map create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name urlmap-main 
  --paths "/api/*" 
  --rule-name rule-api 
  --address-pool pool-api 
  --http-settings httpsettings-api 
  --default-address-pool pool-web 
  --default-http-settings httpsettings-web

# Path-based routing için yeni listener'a bağla
az network application-gateway rule create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name rule-path-based 
  --http-listener listener-https 
  --rule-type PathBasedRouting 
  --url-path-map urlmap-main 
  --priority 200

Health Probe Yapılandırması

Default health probe çoğu zaman yeterli değildir. Özellikle uygulamanızın /health veya /status gibi özel bir endpoint’i varsa custom probe tanımlamak şart.

# Custom health probe oluştur
az network application-gateway probe create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name probe-api 
  --protocol Http 
  --host "10.0.2.20" 
  --path "/api/health" 
  --interval 30 
  --timeout 10 
  --threshold 3

# Probe'u HTTP settings'e bağla
az network application-gateway http-settings update 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name httpsettings-api 
  --probe probe-api

Probe parametreleri:

  • –interval: Kaç saniyede bir kontrol yapılacağı (varsayılan 30 saniye)
  • –timeout: Probe’un cevap bekleyeceği maksimum süre
  • –threshold: Kaç başarısız denemeden sonra backend unhealthy sayılır
  • –path: Health check için kullanılacak URL yolu
  • –host: Override edilecek host header değeri

WAF Politikası Oluşturma

WAF_v2 SKU kullandıysanız WAF politikasını ayrı bir resource olarak oluşturup Gateway’e bağlamanız modern yaklaşım. Bu sayede aynı politikayı birden fazla Gateway’e uygulayabilirsiniz.

# WAF Policy oluştur
az network application-gateway waf-policy create 
  --resource-group rg-appgw-prod 
  --name wafpolicy-prod 
  --location westeurope

# OWASP 3.2 rule set'i etkinleştir
az network application-gateway waf-policy managed-rule rule-set add 
  --resource-group rg-appgw-prod 
  --policy-name wafpolicy-prod 
  --type OWASP 
  --version 3.2

# WAF'ı Prevention moduna al (önce Detection ile başlayın!)
az network application-gateway waf-policy policy-setting update 
  --resource-group rg-appgw-prod 
  --policy-name wafpolicy-prod 
  --state Enabled 
  --mode Prevention 
  --request-body-check true 
  --max-request-body-size 128 
  --file-upload-limit-in-mb 100

# WAF Policy'yi Gateway'e bağla
az network application-gateway update 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --waf-policy wafpolicy-prod

Önemli not: WAF’ı canlı ortamda ilk kurduğunuzda mutlaka Detection modunda başlayın. Prevention moda geçmeden önce logları izleyin ve false positive kuralları tespit edin. Detection modunda trafik engellenmez, sadece loglanır. Ben bunu es geçip direkt Prevention moduna aldığım bir müşteri ortamında ödeme sayfasının çöktüğünü gördüm. Nedeni WAF’ın ödeme formundaki bazı alanları SQL injection girişimi olarak algılamasıydı.

HTTP’den HTTPS’e Redirect

Kullanıcılar HTTP ile geldiğinde otomatik olarak HTTPS’e yönlendirmek standart bir gereksinim.

# HTTP listener oluştur (redirect için)
az network application-gateway http-listener create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name listener-http 
  --frontend-ip appGatewayFrontendIP 
  --frontend-port port-80

# Redirect configuration oluştur
az network application-gateway redirect-config create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name redirect-http-to-https 
  --type Permanent 
  --target-listener listener-https 
  --include-path true 
  --include-query-string true

# Routing rule ile bağla
az network application-gateway rule create 
  --resource-group rg-appgw-prod 
  --gateway-name appgw-prod 
  --name rule-http-redirect 
  --http-listener listener-http 
  --rule-type Basic 
  --redirect-config redirect-http-to-https 
  --priority 50

Autoscaling Yapılandırması

v2 SKU ile autoscaling etkinleştirmek basit ama doğru parametreleri belirlemek önemli.

# Autoscaling ile Gateway'i güncelle
az network application-gateway update 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --min-capacity 2 
  --max-capacity 10

# Zone redundancy ekle (availability zones)
az network application-gateway update 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --zones 1 2 3

Autoscaling maliyet notu: Application Gateway v2, instance sayısı artıkça saatlik maliyet de artar. --min-capacity değerini production’da 2’nin altına düşürmeyin. 0 yapabilirsiniz teknik olarak ama cold start problemi yaşarsınız, ilk istek ciddi derecede yavaş gelir.

Diagnostic Logging ve Monitoring

Production ortamında Application Gateway loglarını bir Log Analytics workspace’e göndermek zorunluluk, tercih değil.

# Log Analytics Workspace oluştur
az monitor log-analytics workspace create 
  --resource-group rg-appgw-prod 
  --workspace-name law-appgw-prod 
  --location westeurope 
  --sku PerGB2018

# Diagnostic settings etkinleştir
APPGW_ID=$(az network application-gateway show 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --query id --output tsv)

LAW_ID=$(az monitor log-analytics workspace show 
  --resource-group rg-appgw-prod 
  --workspace-name law-appgw-prod 
  --query id --output tsv)

az monitor diagnostic-settings create 
  --resource $APPGW_ID 
  --workspace $LAW_ID 
  --name "appgw-diagnostics" 
  --logs '[
    {"category": "ApplicationGatewayAccessLog", "enabled": true},
    {"category": "ApplicationGatewayPerformanceLog", "enabled": true},
    {"category": "ApplicationGatewayFirewallLog", "enabled": true}
  ]' 
  --metrics '[
    {"category": "AllMetrics", "enabled": true}
  ]'

Log Analytics’e gelen WAF loglarını sorgulamak için basit bir KQL örneği:

# Azure Portal'da Log Analytics sorgusunu CLI ile çalıştır
az monitor log-analytics query 
  --workspace $LAW_ID 
  --analytics-query "
    AzureDiagnostics
    | where ResourceType == 'APPLICATIONGATEWAYS'
    | where Category == 'ApplicationGatewayFirewallLog'
    | where action_s == 'Blocked'
    | summarize count() by ruleId_s, clientIp_s
    | order by count_ desc
    | take 20
  " 
  --output table

Backend Health Durumunu Kontrol Etme

Bir backend pool’unda problem olduğunda hızlıca kontrol etmek için:

# Backend health durumunu kontrol et
az network application-gateway show-backend-health 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --output table

# Belirli bir backend pool için detaylı kontrol
az network application-gateway show-backend-health 
  --resource-group rg-appgw-prod 
  --name appgw-prod 
  --query "backendAddressPools[?name=='pool-api'].backendHttpSettingsCollection[].servers[]" 
  --output table

Servis talepleri sırasında backend health durumu “Unknown” olarak görünüyorsa, bunun sebebi genellikle NSG kurallarıdır. Application Gateway’in backend subnet’e erişebilmesi için NSG’de 65200-65535 port aralığını açmanız gerekiyor. Bu aralık Gateway’in kendi iç iletişimi için kullanılan, çoğu zaman unutulan kritik bir detay.

# Application Gateway yönetim trafiği için NSG kuralı
az network nsg rule create 
  --resource-group rg-appgw-prod 
  --nsg-name nsg-appgw 
  --name allow-appgw-management 
  --priority 100 
  --source-address-prefixes GatewayManager 
  --source-port-ranges "*" 
  --destination-address-prefixes "*" 
  --destination-port-ranges "65200-65535" 
  --protocol Tcp 
  --access Allow

Sık Karşılaşılan Sorunlar ve Çözümleri

502 Bad Gateway hatası: Backend sunuculara ulaşılamıyorsa veya health probe başarısız oluyorsa bu hata gelir. İlk kontrol noktanız backend pool üyelerinin health durumu olmalı. NSG kurallarını ve Application Gateway’in backend subnet’e erişimini kontrol edin.

WAF false positive engellemeleri: Özellikle form verileri içeren POST isteklerinde WAF yanlış alarm verebilir. Önce Detection modunda çalıştırıp loglara bakın, sorunlu kuralları exclusion listesine alın.

SSL sertifika hatası: Backend’e SSL ile konuşuyorsanız (end-to-end SSL), backend’in sertifikasını Application Gateway’e trusted root certificate olarak eklemeniz gerekir. Self-signed sertifika kullanıyorsanız bu adımı atlamayın.

Yüksek latency: Genellikle yetersiz instance kapasitesinden kaynaklanır. Autoscaling açık olsa bile scale-out birkaç dakika alır. Min capacity değerini beklenen peak trafiğe göre ayarlayın.

Sonuç

Azure Application Gateway, doğru yapılandırıldığında web uygulamalarınız için son derece güçlü bir trafik yönetim katmanı oluşturur. Bu yazıda temel kurulumdan WAF yapılandırmasına, URL tabanlı yönlendirmeden autoscaling’e kadar production’da ihtiyaç duyacağınız neredeyse her konuya değindik.

Başlangıç için önerim: WAF_v2 SKU ile başlayın, SSL termination’ı Gateway’de yapın, sertifikaları Key Vault’ta tutun ve mutlaka diagnostic logging’i etkinleştirin. WAF’ı ilk aşamada Detection modunda tutun, birkaç gün log izleyin, false positive’leri temizleyin, sonra Prevention moduna geçin. Autoscaling için minimum 2 instance ile başlayın ve zone redundancy’yi etkinleştirin.

Application Gateway maliyetli bir servis gibi görünebilir ama düzgün yapılandırılmış bir Gateway, DDoS koruması, SSL yönetimi ve yük dengeleme maliyetlerini birleştirdiğinde aslında oldukça rekabetçi. Üstelik yönetim kolaylığı da cabası.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir