AWS Trusted Advisor ile Bulut Altyapınızı Optimize Edin

Tarafındankomut
0 Comments

AWS hesabını açtığında karşına çıkan onlarca servis arasında Trusted Advisor genellikle göz ardı edilir. Oysa bu araç, hem maliyetleri düşürmek hem de güvenlik açıklarını kapatmak için gerçekten değerli öneriler sunuyor. Ben bu aracı ilk kez bir müşteri projesinde aktif olarak kullanmaya başladığımda, tek bir hafta içinde aylık 3.000 dolar tasarruf sağladık. Bu yazıda Trusted Advisor’ı sysadmin gözüyle ele alacağız, AWS CLI ile nasıl otomatize edeceğimizi göreceğiz ve gerçek dünya senaryolarıyla konuyu pekiştireceğiz.

AWS Trusted Advisor Nedir ve Ne İşe Yarar?

Trusted Advisor, AWS’nin size hesabınızdaki kaynakları inceleyerek maliyet optimizasyonu, güvenlik, hata toleransı, performans ve servis limitleri konularında öneriler sunan yönetilen bir danışmanlık servisidir. Basitçe söylemek gerekirse AWS, kendi en iyi pratiklerini bir araç haline getirmiş ve bunu sizin hesabınıza uyguluyor.

Beş temel kategoride çalışır:

  • Cost Optimization: Kullanılmayan veya az kullanılan kaynakları tespit eder, Reserved Instance önerisi yapar
  • Security: Güvenlik açıklarını, yanlış yapılandırmaları ve IAM sorunlarını raporlar
  • Fault Tolerance: Yedeklilik eksikliklerini, Single Point of Failure durumlarını gösterir
  • Performance: Servis limitlerine yaklaşan kaynakları ve performans darboğazlarını saptar
  • Service Limits: Hesabınızdaki servis kullanımını limitlerle karşılaştırır

Önemli bir not: Bazı Trusted Advisor kontrolleri yalnızca Business veya Enterprise Support planlarında kullanılabilir. Ücretsiz planda sadece temel güvenlik ve servis limit kontrolleri gelir. Eğer ciddi bir üretim ortamı yönetiyorsanız Business Support planı, bu araç için bile çok hızlı kendini amorti ediyor.

CLI ile Trusted Advisor Kullanımı

AWS Console üzerinden Trusted Advisor’ı görmek kolaydır ama bir sysadmin için asıl güç otomasyonda yatıyor. AWS CLI ile tüm kontrolleri sorgulayabilir, sonuçları otomatik işleyebilir ve uyarıları kendi monitoring sisteminize entegre edebilirsiniz.

Önce temel kurulumu yapalım:

# AWS CLI kurulu ve yapılandırılmış olmalı
aws configure list

# Trusted Advisor kontrol kategorilerini listele
aws support describe-trusted-advisor-checks 
    --language en 
    --region us-east-1 
    --query 'checks[*].[name,category,id]' 
    --output table

Dikkat edilmesi gereken önemli bir nokta: Trusted Advisor API’si yalnızca us-east-1 region’ında çalışır. Farklı bir default region ayarladıysanız her sorguda --region us-east-1 parametresini eklemeniz gerekiyor.

# Belirli bir kategorideki kontrolleri filtrele
aws support describe-trusted-advisor-checks 
    --language en 
    --region us-east-1 
    --query 'checks[?category==`security`].[name,id]' 
    --output text

Kontrol Sonuçlarını Sorgulama

Her kontrolün benzersiz bir ID’si vardır. Bu ID’leri alarak detaylı sonuçları çekebilirsiniz:

# Belirli bir kontrolün sonucunu getir
# Örnek: "Security Groups - Specific Ports Unrestricted" kontrolü
CHECK_ID="HCP4007jGY"

aws support describe-trusted-advisor-check-result 
    --check-id $CHECK_ID 
    --language en 
    --region us-east-1 
    --query 'result.{Status:status,ResourcesSummary:resourcesSummary}' 
    --output json

Sonuçlar üç farklı durumda gelebilir:

  • ok: Kontrol geçti, sorun yok
  • warning: Dikkat edilmesi gereken bir durum var
  • error: Acil müdahale gerektiren kritik bir sorun tespit edildi
  • not_available: Bu kontrol sizin support planınızda mevcut değil

Tüm kontrollerin özet durumunu görmek için şu scripti kullanabilirsiniz:

#!/bin/bash
# trusted_advisor_summary.sh
# Tüm Trusted Advisor kontrollerinin durumunu özetle

REGION="us-east-1"

echo "=== Trusted Advisor Özet Raporu ==="
echo "Tarih: $(date)"
echo ""

# Tüm kontrol ID'lerini al
CHECK_IDS=$(aws support describe-trusted-advisor-checks 
    --language en 
    --region $REGION 
    --query 'checks[*].id' 
    --output text)

ERROR_COUNT=0
WARNING_COUNT=0
OK_COUNT=0

for CHECK_ID in $CHECK_IDS; do
    STATUS=$(aws support describe-trusted-advisor-check-result 
        --check-id $CHECK_ID 
        --language en 
        --region $REGION 
        --query 'result.status' 
        --output text 2>/dev/null)
    
    case $STATUS in
        "error")
            ERROR_COUNT=$((ERROR_COUNT + 1))
            ;;
        "warning")
            WARNING_COUNT=$((WARNING_COUNT + 1))
            ;;
        "ok")
            OK_COUNT=$((OK_COUNT + 1))
            ;;
    esac
done

echo "Kritik Sorunlar (Error): $ERROR_COUNT"
echo "Uyarılar (Warning): $WARNING_COUNT"
echo "Sorunsuz (OK): $OK_COUNT"

Güvenlik Kontrollerini Otomatize Etmek

Güvenlik kategorisi, bence Trusted Advisor’ın en değerli kısmı. Özellikle büyük ekiplerde çalışırken birileri yanlışlıkla bir S3 bucket’ı public açabiliyor, security group’a 0.0.0.0/0 ekleyebiliyor. Trusted Advisor bunları yakalıyor.

Şimdi gerçek bir senaryo üzerinden gidelim. Diyelim ki her gece çalışan ve güvenlik sorunlarını Slack’e bildiren bir script yazmak istiyorsunuz:

#!/bin/bash
# security_check.sh
# Güvenlik uyarılarını kontrol et ve Slack'e bildir

REGION="us-east-1"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

# Güvenlikle ilgili kritik kontrol ID'leri
SECURITY_CHECKS=(
    "HCP4007jGY"  # Security Groups - Specific Ports Unrestricted
    "Pfx0RwqBli"  # IAM Use
    "1iG5NDGVre"  # MFA on Root Account
    "nNauJisYIT"  # Security Groups - Unrestricted Access
    "a2sEc6ILx"   # S3 Bucket Permissions
)

ISSUES_FOUND=false
MESSAGE="*AWS Trusted Advisor Güvenlik Raporu*n$(date)nn"

for CHECK_ID in "${SECURITY_CHECKS[@]}"; do
    # Önce refresh isteği gönder
    aws support refresh-trusted-advisor-check 
        --check-id $CHECK_ID 
        --region $REGION > /dev/null 2>&1
    
    sleep 5
    
    RESULT=$(aws support describe-trusted-advisor-check-result 
        --check-id $CHECK_ID 
        --language en 
        --region $REGION 
        --output json 2>/dev/null)
    
    STATUS=$(echo $RESULT | python3 -c "import sys, json; data=json.load(sys.stdin); print(data['result']['status'])")
    CHECK_NAME=$(aws support describe-trusted-advisor-checks 
        --language en 
        --region $REGION 
        --query "checks[?id=='$CHECK_ID'].name" 
        --output text)
    
    if [ "$STATUS" = "error" ] || [ "$STATUS" = "warning" ]; then
        ISSUES_FOUND=true
        if [ "$STATUS" = "error" ]; then
            MESSAGE+="🔴 *KRITIK:* $CHECK_NAMEn"
        else
            MESSAGE+="🟡 *UYARI:* $CHECK_NAMEn"
        fi
    fi
done

if [ "$ISSUES_FOUND" = true ]; then
    curl -s -X POST -H 'Content-type: application/json' 
        --data "{"text":"$MESSAGE"}" 
        "$SLACK_WEBHOOK_URL"
fi

Maliyet Optimizasyonu Senaryoları

İşte en dikkat çekici gerçek dünya örneğim. Bir e-ticaret müşterisinin AWS hesabını audit ettiğimizde Trusted Advisor’ın Cost Optimization kategorisinde şunları bulduk:

Boşta çalışan EC2 instance’ları: 14 tane m5.large instance CPU kullanımı yüzde 2-3 civarında çalışıyordu. Bunlar test ortamı için kaldırılıp yeniden oluşturulmuş ama biri silmeyi unutmuş. Aylık maliyet: yaklaşık 1.200 dolar.

Kullanılmayan Elastic IP’ler: 23 adet Elastic IP hiçbir kaynağa bağlı değildi. AWS kullanılmayan Elastic IP’leri ücretlendiriyor. Bu 23 IP saatte 0.005 dolar, ayda yaklaşık 83 dolar ediyor. Küçük görünüyor ama kim bıraktı bunu?

Boş Load Balancer’lar: 4 adet Application Load Balancer hiç traffic almıyordu. Aylık 65-70 dolar civarı.

Bu tespitleri script ile nasıl yakalayabiliriz:

#!/bin/bash
# cost_optimization_report.sh
# Maliyet optimizasyonu önerilerini raporla

REGION="us-east-1"
REPORT_FILE="/tmp/trusted_advisor_cost_$(date +%Y%m%d).json"

# Boşta çalışan EC2 instance'ları
IDLE_EC2_CHECK="Ti39halfu8"

echo "Boşta çalışan EC2 instance'ları kontrol ediliyor..."

aws support describe-trusted-advisor-check-result 
    --check-id $IDLE_EC2_CHECK 
    --language en 
    --region $REGION 
    --query 'result.flaggedResources[*].{ResourceId:resourceId,Status:status,Metadata:metadata}' 
    --output json > $REPORT_FILE

# Kaynak sayısını ve tahmini tasarrufu göster
FLAGGED_COUNT=$(cat $REPORT_FILE | python3 -c "
import sys, json
data = json.load(sys.stdin)
print(len(data))
")

echo "Tespit edilen boşta EC2 instance sayısı: $FLAGGED_COUNT"
echo "Detaylı rapor: $REPORT_FILE"

# Kullanılmayan Elastic IP'ler
UNUSED_EIP_CHECK="Z4AUBRNSmz"

EIP_RESULT=$(aws support describe-trusted-advisor-check-result 
    --check-id $UNUSED_EIP_CHECK 
    --language en 
    --region $REGION 
    --query 'result.flaggedResources[*].metadata[1]' 
    --output text 2>/dev/null)

echo "Kullanılmayan Elastic IP'ler: $EIP_RESULT"

Servis Limitleri Takibi

Servis limitleri konusu özellikle büyüme döneminde olan şirketler için kritik. Bir proje canlıya alındığında “ec2 instance açamıyoruz” hatası almak, o kadar da hoş bir deneyim değil. Trusted Advisor bu limitleri önceden gösteriyor.

#!/bin/bash
# service_limits_monitor.sh
# Servis limitlerinin yüzde 80'ini aşan kaynakları raporla

REGION="us-east-1"
THRESHOLD=80

# Servis limiti kontrol ID'leri
SERVICE_LIMIT_CHECKS=(
    "eW7HH0l7J9"  # EC2 On-Demand Instances
    "pW9IIoVZqG"  # VPC
    "dBkuNCvqn5"  # ELB
    "iH7oEc7799"  # RDS DB Instances
)

echo "=== Servis Limit Raporu ==="
echo "Uyarı Eşiği: %$THRESHOLD"
echo ""

for CHECK_ID in "${SERVICE_LIMIT_CHECKS[@]}"; do
    RESULT=$(aws support describe-trusted-advisor-check-result 
        --check-id $CHECK_ID 
        --language en 
        --region $REGION 
        --output json 2>/dev/null)
    
    if [ $? -eq 0 ]; then
        # Flagged resource'ları listele
        FLAGGED=$(echo $RESULT | python3 -c "
import sys, json
data = json.load(sys.stdin)
resources = data.get('result', {}).get('flaggedResources', [])
for r in resources:
    meta = r.get('metadata', [])
    if len(meta) >= 6:
        region = meta[0]
        service = meta[1]
        limit_name = meta[2]
        limit_amount = meta[3]
        current = meta[4]
        status = r.get('status', '')
        if status in ['warning', 'error']:
            print(f'{region} | {service} | {limit_name} | Kullanım: {current}/{limit_amount}')
" 2>/dev/null)
        
        if [ ! -z "$FLAGGED" ]; then
            echo "$FLAGGED"
        fi
    fi
done

CloudWatch ile Entegrasyon

Trusted Advisor’ı CloudWatch Events ile entegre ederek otomatik aksiyon alabilirsiniz. Bu kurulum özellikle güvenlik ihlallerinde hızlı tepki vermek için kullanışlı:

# CloudWatch Events rule oluştur - Trusted Advisor uyarıları için
aws events put-rule 
    --name "TrustedAdvisorSecurityAlert" 
    --event-pattern '{
        "source": ["aws.trustedadvisor"],
        "detail-type": ["Trusted Advisor Check Item Refresh Notification"],
        "detail": {
            "status": ["ERROR"],
            "check-category": ["security"]
        }
    }' 
    --state ENABLED 
    --region us-east-1

# SNS topic'e hedef ekle
aws events put-targets 
    --rule "TrustedAdvisorSecurityAlert" 
    --targets '[
        {
            "Id": "SecurityAlertSNS",
            "Arn": "arn:aws:sns:us-east-1:ACCOUNT_ID:security-alerts"
        }
    ]' 
    --region us-east-1

Burada önemli bir detay var: Trusted Advisor otomatik olarak sürekli refresh yapmaz. Kontrollerin güncellenmesi için ya manuel refresh isteği göndermeniz ya da AWS’nin periyodik refresh’ini beklemeniz gerekiyor. Business ve Enterprise Support planlarında kontroller daha sık güncelleniyor.

Refresh Mekanizması ve Otomasyon

Kontrolleri programatik olarak refresh etmek için:

#!/bin/bash
# refresh_all_checks.sh
# Tüm Trusted Advisor kontrollerini yenile

REGION="us-east-1"
MIN_REFRESH_SECONDS=3600  # 1 saat

CHECKS=$(aws support describe-trusted-advisor-checks 
    --language en 
    --region $REGION 
    --query 'checks[*].id' 
    --output text)

for CHECK_ID in $CHECKS; do
    # Refresh durumunu kontrol et
    REFRESH_STATUS=$(aws support describe-trusted-advisor-check-refresh-statuses 
        --check-ids $CHECK_ID 
        --region $REGION 
        --query 'statuses[0].status' 
        --output text 2>/dev/null)
    
    # Eğer zaten enqueued veya processing değilse refresh gönder
    if [ "$REFRESH_STATUS" != "enqueued" ] && [ "$REFRESH_STATUS" != "processing" ]; then
        aws support refresh-trusted-advisor-check 
            --check-id $CHECK_ID 
            --region $REGION > /dev/null 2>&1
        
        echo "Refresh gönderildi: $CHECK_ID"
        sleep 2  # Rate limit'e takılmamak için
    else
        echo "Zaten işleniyor: $CHECK_ID (Durum: $REFRESH_STATUS)"
    fi
done

echo "Tüm refresh istekleri gönderildi. Sonuçlar birkaç dakika içinde hazır olacak."

Terraform ile Trusted Advisor Alarm Kurulumu

Infrastructure as Code yaklaşımıyla Trusted Advisor alarmlarını Terraform ile yönetebilirsiniz. Bu, özellikle multi-account ortamlarında tutarlılık sağlamak açısından önemli:

# Bu Terraform konfigürasyonunu apply etmek için:
# terraform init
# terraform plan
# terraform apply

# Önce değişkenleri ve provider'ı ayarla
cat > trusted_advisor_alarms.tf << 'EOF'
# CloudWatch metrik alarm - Trusted Advisor güvenlik skoru düştüğünde uyar
resource "aws_cloudwatch_metric_alarm" "trusted_advisor_security" {
  alarm_name          = "trusted-advisor-security-alert"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "RedChecks"
  namespace           = "AWS/TrustedAdvisor"
  period              = "86400"
  statistic           = "Maximum"
  threshold           = "0"
  alarm_description   = "Trusted Advisor kritik güvenlik sorunu tespit etti"
  
  dimensions = {
    Category = "security"
  }
  
  alarm_actions = [aws_sns_topic.security_alerts.arn]
}
EOF

echo "Terraform konfigürasyonu oluşturuldu."

Pratik Öneriler ve Tuzaklar

Birkaç yıllık Trusted Advisor kullanımından edindiğim deneyimler:

Refresh sıklığını iyi ayarlayın. Her kontrol en az 5 dakika arayla refresh edilebilir ama bazıları 12 saatte bir güncellenebilir. Script’lerinizde bunu göz önünde bulundurun, yoksa eski verilerle çalışırsınız.

Tüm uyarılara körü körüne güvenmeyin. Özellikle güvenlik grubundaki 0.0.0.0/0 uyarıları bazen kasıtlı açık portlardır. Her uyarıyı değerlendirin, otomatik kapatamazsınız.

Multi-account ortamında AWS Organizations kullanıyorsanız, Trusted Advisor sonuçlarını merkezi bir hesaptan toplamak için AWS Organizations entegrasyonunu aktif edin. Her hesaba ayrı ayrı bağlanmak yerine management account üzerinden erişim sağlayabilirsiniz.

Cost Optimization önerilerini hemen uygulamayın. Özellikle EC2 instance’larını kapatmadan önce uygulama ekibiyle konuşun. “Boşta görünen” bir instance aslında bir cron job için bekliyor olabilir.

Servis limit artırım taleplerini proaktif yapın. Limitin yüzde 75’ine geldiğinde AWS’ye limit artırım talebi açın. Artırım birkaç gün sürebiliyor, production’da beklemek istemezsiniz.

Trusted Advisor ile Service Quotas servisini birlikte kullanın. Service Quotas, Trusted Advisor’ın göstermediği bazı granüler limitleri gösteriyor ve artırım taleplerini doğrudan bu konsoldan yapabiliyorsunuz.

IAM permission’larını doğru ayarlayın. Trusted Advisor API’sine erişmek için minimum şu permission’lar gerekiyor:

  • support:DescribeTrustedAdvisorChecks: Kontrolleri listelemek için
  • support:DescribeTrustedAdvisorCheckResult: Sonuçları okumak için
  • support:RefreshTrustedAdvisorCheck: Refresh istemek için
  • support:DescribeTrustedAdvisorCheckRefreshStatuses: Refresh durumunu kontrol etmek için

Sonuç

Trusted Advisor, AWS ekosisteminde gerçekten işe yarayan araçlardan biri. Ama potansiyelinin yalnızca bir kısmı console üzerinden manuel bakışla ortaya çıkıyor. Asıl güç, bu aracı otomatize ettiğinizde ve kendi monitoring pipeline’ınıza entegre ettiğinizde ortaya çıkıyor.

Başlangıç için şu üç adımı öneririm: Birincisi, security kontrollerini haftalık çalışan bir cron job ile sorgulayın ve sonuçları e-posta veya Slack’e gönderin. İkincisi, servis limitlerini izleyen bir alarm kurun, limitlerin yüzde 80’ine geldiğinde bildirim alın. Üçüncüsü, maliyet optimizasyonu önerilerini aylık review toplantılarınıza dahil edin, her ay bir insan saati ayırıp Trusted Advisor önerilerini gözden geçirmek, yıl sonunda ciddi tasarruflara dönüşüyor.

Business Support planı için ödediğiniz bedelin karşılığını Trusted Advisor’dan çıkarabilirsiniz. Eğer hala free plan kullanıyorsanız ve production ortamı yönetiyorsanız, Business Support’a geçişi ciddi düşünmenin zamanı gelmiştir. Zira o eksik kontroller tam da kritik anlarda fark yaratıyor.

Bir yanıt yazın

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