AWS Shield ile DDoS Koruması: Kapsamlı Rehber
DDoS saldırıları artık sadece büyük şirketlerin sorunu değil. Küçük bir e-ticaret sitesi, bir SaaS uygulaması ya da kurumsal bir API gateway, herhangi bir gün hedef alınabilir. AWS üzerinde çalışıyorsanız, Shield size bu konuda ciddi bir avantaj sağlıyor. Ama “Shield açık mı, tamam o zaman güvendeyiz” demek de tam olarak doğru değil. Gelin AWS Shield’i gerçekten nasıl kullanmanız gerektiğini, maliyetleri nasıl kontrol altında tutacağınızı ve production ortamında karşılaşabileceğiniz gerçek senaryoları ele alalım.
AWS Shield Nedir ve İki Katmanı Nasıl Çalışır
AWS Shield, temelde iki katmandan oluşuyor: Shield Standard ve Shield Advanced. Aradaki fark hem fiyat hem de koruma derinliği açısından oldukça büyük.
Shield Standard, AWS hesabınız varsa zaten aktif. Ek bir yapılandırma gerektirmiyor ve ücretsiz. Layer 3 ve Layer 4 saldırılarına karşı temel koruma sağlıyor. SYN flood, UDP flood, reflection saldırıları gibi volumetrik saldırıları absorbe edebiliyor. Bu katman CloudFront, Route 53 ve Global Accelerator üzerinde özellikle etkili çünkü AWS’nin global anycast ağından faydalanıyor.
Shield Advanced ise aylık 3.000 USD başlayan bir maliyetle geliyor ve şunları ekliyor:
- Layer 7 uygulama katmanı saldırı tespiti ve mitigasyonu
- DDoS Response Team (DRT) erişimi
- Gerçek zamanlı görünürlük ve detaylı metrikler
- Maliyet koruması (saldırı sırasında oluşan EC2, CloudFront, ELB maliyetlerini kapsıyor)
- WAF ile entegrasyon ve otomatik kural oluşturma
- Route 53, CloudFront, ELB, EC2 Elastic IP ve Global Accelerator desteği
Advanced’ın en kritik özelliklerinden biri maliyet koruması. Büyük bir DDoS saldırısı sırasında auto scaling devreye girip faturanızı patlatabilir. Advanced bu maliyetleri geri almanızı sağlıyor.
Temel Kavramlar: Saldırı Vektörleri ve Korunan Kaynaklar
Şimdi pratiğe geçmeden önce kısa bir terminoloji alıştırması yapalım.
Layer 3/4 saldırıları ağ ve transport katmanını hedef alır. Volumetrik saldırılar (bant genişliğini doldurmak), protocol saldırıları (SYN flood, ACK flood) bu kategoriye girer. Shield Standard bunlara karşı oldukça iyi.
Layer 7 saldırıları uygulama katmanını hedef alır. HTTP flood, slowloris, düşük bant genişliğiyle yüksek kaynak tüketen istekler bu kategoride. Bunlara karşı WAF kuralları ve Shield Advanced birlikte kullanılıyor.
Korunan kaynak türleri şunlar:
- EC2 Elastic IP: Doğrudan sunucu IP’leri için
- ELB (Application Load Balancer, Network Load Balancer, Classic): Yük dengeleyiciler
- CloudFront Distribution: CDN dağıtımları
- Route 53 Hosted Zone: DNS katmanı
- Global Accelerator Accelerator: Global hızlandırıcılar
AWS CLI ile Shield Advanced’ı Etkinleştirme
Shield Advanced’ı AWS Console üzerinden etkinleştirmek mümkün ama bir SysAdmin olarak CLI ve IaC yaklaşımını tercih ediyoruz. Önce subscription oluşturalım:
# Shield Advanced subscription oluştur
aws shield create-subscription
# Subscription durumunu kontrol et
aws shield describe-subscription
--query 'Subscription.{Status:SubscriptionState,StartTime:StartTime,EndTime:EndTime}'
--output json
Korunan kaynak eklemek için kaynak ARN’ine ihtiyacınız var:
# Application Load Balancer'ı Shield Advanced ile koru
ALB_ARN=$(aws elbv2 describe-load-balancers
--names "production-alb"
--query 'LoadBalancers[0].LoadBalancerArn'
--output text)
aws shield create-protection
--name "Production-ALB-Protection"
--resource-arn $ALB_ARN
# CloudFront distribution'ı koru
CF_ARN="arn:aws:cloudfront::123456789012:distribution/E1234ABCDEF"
aws shield create-protection
--name "Production-CloudFront-Protection"
--resource-arn $CF_ARN
Mevcut korumalarınızı listelemek için:
# Tüm korumaları listele
aws shield list-protections
--query 'Protections[*].{Name:Name,ResourceArn:ResourceArn,ProtectionId:Id}'
--output json
# Belirli bir kaynağın koruma detaylarını gör
aws shield describe-protection
--resource-arn $ALB_ARN
--output json
Terraform ile Shield Advanced Yapılandırması
Production ortamında her şeyi elle yapmak yerine Terraform ile yönetmek çok daha sağlıklı. İşte gerçek bir senaryo için Terraform kodu:
# Terraform yapılandırma dosyası: shield_advanced.tf
# Bu dosyayı doğrudan çalıştırmak için terraform init && terraform apply
cat > shield_advanced.tf << 'EOF'
resource "aws_shield_protection" "alb_protection" {
name = "production-alb-shield"
resource_arn = aws_lb.production.arn
tags = {
Environment = "production"
ManagedBy = "terraform"
CostCenter = "security"
}
}
resource "aws_shield_protection" "cloudfront_protection" {
name = "production-cloudfront-shield"
resource_arn = aws_cloudfront_distribution.main.arn
tags = {
Environment = "production"
ManagedBy = "terraform"
}
}
resource "aws_shield_protection_group" "all_resources" {
protection_group_id = "production-all-resources"
aggregation = "MAX"
pattern = "ALL"
tags = {
Environment = "production"
}
}
EOF
terraform init
terraform plan -out=shield.plan
terraform apply shield.plan
Protection Group kullanımı önemli. Birden fazla kaynağı bir grup olarak izlemenizi sağlıyor ve saldırı tespitini daha akıllı hale getiriyor.
WAF ile Entegrasyon: Layer 7 Koruması
Shield Advanced’ın gücü WAF entegrasyonuyla ortaya çıkıyor. DRT (DDoS Response Team) saldırı anında otomatik WAF kuralları oluşturabiliyor ama siz de önceden hazırlıklı olmalısınız:
# WAF Web ACL oluştur ve Shield ile ilişkilendir
aws wafv2 create-web-acl
--name "shield-advanced-waf"
--scope REGIONAL
--default-action Allow={}
--rules file://waf-rules.json
--visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ShieldWAFMetric
--region us-east-1
# WAF'ı ALB ile ilişkilendir
aws wafv2 associate-web-acl
--web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/shield-advanced-waf/abc123"
--resource-arn $ALB_ARN
# Shield Advanced'a WAF ilişkilendirmesini bildir
aws shield associate-drt-log-bucket
--log-bucket "s3://your-shield-logs-bucket"
Rate-based kural eklemek için waf-rules.json içeriği şöyle olabilir:
# Rate-based kural için JSON dosyası oluştur
cat > waf-rules.json << 'EOF'
[
{
"Name": "RateLimitRule",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitRuleMetric"
}
},
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 2,
"OverrideAction": {
"None": {}
},
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CommonRuleSetMetric"
}
}
]
EOF
CloudWatch ile Gerçek Zamanlı İzleme
Saldırıları tespit etmek için doğru metrikleri izlemeniz gerekiyor. Shield Advanced’ın CloudWatch entegrasyonu bu konuda çok değerli:
# Shield saldırı alarmı oluştur
aws cloudwatch put-metric-alarm
--alarm-name "Shield-DDoS-Attack-Detected"
--alarm-description "DDoS saldırısı tespit edildi"
--metric-name DDoSDetected
--namespace AWS/DDoSProtection
--statistic Sum
--period 60
--threshold 1
--comparison-operator GreaterThanOrEqualToThreshold
--evaluation-periods 1
--alarm-actions "arn:aws:sns:us-east-1:123456789012:security-alerts"
--dimensions Name=ResourceArn,Value=$ALB_ARN
# DDoS mitigasyon süresini izle
aws cloudwatch put-metric-alarm
--alarm-name "Shield-Attack-BitsPerSecond"
--alarm-description "Yüksek saldırı trafiği"
--metric-name DDoSAttackBitsPerSecond
--namespace AWS/DDoSProtection
--statistic Maximum
--period 60
--threshold 1000000000
--comparison-operator GreaterThanOrEqualToThreshold
--evaluation-periods 2
--alarm-actions "arn:aws:sns:us-east-1:123456789012:security-alerts"
--dimensions Name=ResourceArn,Value=$ALB_ARN
# Son 24 saatteki saldırıları listele
aws shield list-attacks
--start-time StartTime=$(date -d "24 hours ago" +%s),EndTime=$(date +%s)
--output json
SNS topic’i önceden oluşturmuş ve email/PagerDuty/Slack entegrasyonunu tamamlamış olmanız gerekiyor. Security ekibinin gecenin 3’ünde bile haberdar olması kritik.
Gerçek Dünya Senaryosu: E-Ticaret Sitesine UDP Flood Saldırısı
Şimdi gerçek bir senaryo üzerinden gidelim. Bir e-ticaret müşterim, Black Friday gecesi yoğun bir UDP flood saldırısıyla karşılaştı. Mimari şöyleydi: Route 53 -> CloudFront -> ALB -> EC2 Auto Scaling.
Saldırı başladığında Shield Advanced otomatik olarak devreye girdi ama Layer 7’deki anormal HTTP pattern’ı için WAF’a manuel müdahale gerekti. O gece yaptığım şeyler:
# Aktif saldırının detaylarını gör
ATTACK_ID=$(aws shield list-attacks
--start-time StartTime=$(date -d "2 hours ago" +%s),EndTime=$(date +%s)
--query 'AttackSummaries[0].AttackId'
--output text)
aws shield describe-attack
--attack-id $ATTACK_ID
--output json
# Saldırı sırasında anında IP bazlı bloklama için WAF güncellemesi
aws wafv2 get-ip-set
--name "blocked-ips"
--scope REGIONAL
--id "your-ipset-id"
--output json > current-ipset.json
# Yeni IP'leri ekle ve güncelle
aws wafv2 update-ip-set
--name "blocked-ips"
--scope REGIONAL
--id "your-ipset-id"
--lock-token "your-lock-token"
--addresses "192.0.2.0/24" "198.51.100.0/24" "203.0.113.0/24"
Saldırı 47 dakika sürdü ve Shield Advanced’ın maliyet koruması sayesinde bu sürede oluşan ek CloudFront ve EC2 maliyetleri geri alındı. Toplamda yaklaşık 2.800 USD’lik bir kredi geldi.
DRT ile Çalışma: Proaktif Engagement
DDoS Response Team ile çalışmak için önceden izin vermeniz gerekiyor. Bu adımı önceden yapın, saldırı anında uğraşmayın:
# DRT'ye S3 bucket erişimi ver (log analizi için)
aws shield associate-drt-log-bucket
--log-bucket "your-waf-logs-bucket"
# DRT'ye IAM rol erişimi ver
aws shield associate-drt-role
--role-arn "arn:aws:iam::123456789012:role/DRTAccessRole"
# IAM rolü oluşturma (önceden yapılmalı)
aws iam create-role
--role-name DRTAccessRole
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "drt.shield.amazonaws.com"
},
"Action": "sts:AssumeRole"
}]
}'
aws iam attach-role-policy
--role-name DRTAccessRole
--policy-arn "arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy"
DRT’nin proaktif engagement modeli var. Saldırı tespit edildiğinde otomatik olarak size ulaşabilirler ama bunun için “Proactive Engagement” özelliğini Console’dan veya API’den etkinleştirmeniz gerekiyor.
Maliyet Optimizasyonu ve Shield’in Gerçek Maliyeti
Shield Advanced’ın 3.000 USD/ay maliyeti kulağa pahalı geliyor ama hesabı doğru yapmak lazım. Bu maliyet tüm hesabı kapsıyor (Organizations kullanıyorsanız konsolide ödeme seçeneğiyle birden fazla hesap). Ayrıca şu faktörleri değerlendirin:
- Bir DDoS saldırısı sırasında oluşabilecek EC2, CloudFront, data transfer maliyetleri
- Downtime maliyeti (e-ticaret için dakikada ne kadar gelir kaybı?)
- DRT danışmanlık maliyeti (normalde saatlik ücretle satılan bir hizmet)
- WAF dahil geliyor mu? Hayır, WAF ayrı faturalanıyor ama entegrasyon ücretsiz
Maliyetleri izlemek için:
# Shield Advanced maliyet koruması talebi oluştur
# Saldırı sonrası bu komutu kullanın
aws shield create-protection-group
--protection-group-id "cost-tracking-group"
--aggregation "MAX"
--pattern "ARBITRARY"
--members $ALB_ARN $CF_ARN
# AWS Cost Explorer ile Shield maliyetlerini izle
aws ce get-cost-and-usage
--time-period Start=2024-01-01,End=2024-01-31
--granularity MONTHLY
--filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS Shield"]}}'
--metrics BlendedCost
--output json
Shield Standard yeterliyse (küçük/orta ölçekli, yüksek riskli olmayan uygulamalar için) Advanced’a para harcamamanız gerekiyor. Ama şu kriterleri karşılıyorsanız Advanced ciddi şekilde değerlendirin:
- Aylık gelir 50.000 USD üzerindeyse ve downtime çok maliyetliyse
- Regülasyon gereksinimleri compliance raporu istiyorsa
- Geçmişte DDoS saldırısına maruz kaldıysanız
- Finans, oyun, medya gibi yüksek risk sektörlerindeyseniz
Automation: Saldırı Tespitinde Otomatik Yanıt
Manuel müdahale her zaman yeterince hızlı olmayabilir. Lambda ve EventBridge ile otomatik yanıt sistemi kurabilirsiniz:
# EventBridge rule oluştur - Shield saldırı event'leri için
aws events put-rule
--name "shield-attack-response"
--event-pattern '{
"source": ["aws.shield"],
"detail-type": ["DDoS Attack Started"]
}'
--state ENABLED
# Lambda fonksiyonunu EventBridge'e bağla
aws events put-targets
--rule "shield-attack-response"
--targets '[{
"Id": "shield-response-lambda",
"Arn": "arn:aws:lambda:us-east-1:123456789012:function:shield-auto-response"
}]'
# Lambda'ya EventBridge izni ver
aws lambda add-permission
--function-name "shield-auto-response"
--statement-id "EventBridgeInvoke"
--action "lambda:InvokeFunction"
--principal "events.amazonaws.com"
--source-arn "arn:aws:events:us-east-1:123456789012:rule/shield-attack-response"
Lambda fonksiyonu içinde şu aksiyonları otomatikleştirebilirsiniz: Slack/PagerDuty bildirimi, WAF kural güncelleme, Route 53 sağlık denetimi tetikleme, Auto Scaling policy güncelleme.
Sık Yapılan Hatalar ve Dikkat Edilmesi Gerekenler
Yıllar içinde gördüğüm en yaygın hataları paylaşayım:
- Sadece ALB’yi koruyup CloudFront’u unutmak: Saldırganlar ALB’ye doğrudan ulaşabiliyorsa CloudFront bypassed edilebilir. Her iki kaynağı da koruyun.
- WAF olmadan Shield Advanced kullanmak: Layer 7 saldırılarına karşı WAF olmadan Shield Advanced yarım kalıyor. İkisi birlikte çalışmak zorunda.
- DRT erişimini önceden yapılandırmamak: Saldırı anında konsola girip IAM rolü oluşturmaya çalışmak hem stresli hem de zaman kaybı.
- Test ortamında Shield Advanced açmak: Shield Advanced organization düzeyinde çalışıyor. Test hesabını aynı org’a bağladıysanız maliyet paylaşımı konusunu anlayın.
- Alarm eşiklerini yanlış ayarlamak: Çok hassas ayarlanmış alarmlar alert fatigue yaratır. Gerçekçi threshold’lar belirleyin.
- Shield Health Check’i atlamak: Route 53 Health Check ile Shield entegrasyonu sağlıklı endpoint’lere trafik yönlendirmede kritik rol oynuyor.
- Maliyet koruması talebini geç yapmak: Saldırı sonrası 15 gün içinde maliyet koruması talebini açmanız gerekiyor. Bunu takviminize not edin.
Sonuç
AWS Shield, doğru yapılandırıldığında gerçekten etkili bir DDoS koruma katmanı sunuyor. Shield Standard ücretsiz ve temel koruması güçlü. Shield Advanced ise ciddi bir yatırım gerektiriyor ama yüksek riskli ortamlar için bu yatırım kendini hızla amorti edebiliyor.
Önemli olan şu: Shield tek başına yeterli değil. WAF kuralları, doğru mimari kararlar (CloudFront önünde bulundurmak, EC2’yu direkt expose etmemek), CloudWatch izleme, otomatik yanıt mekanizmaları ve DRT ile önceden kurulmuş ilişki, bütünsel bir DDoS savunma stratejisi oluşturuyor.
Eğer şu an Shield kullanıyor ama gerçekten ne kadar etkili olduğunu bilmiyorsanız, test ortamınızda bir yük testi yapın, CloudWatch metriklerine bakın, Shield konsolundan son 30 günlük saldırı raporunu inceleyin. Gerçek dünyada hazırlıklı olmak, saldırı anında paniklemekten çok daha az maliyetli.
