Amazon SAA-C03: Yönetim, Operasyonlar, Gözlemlenebilirlik ve Maliyet — Çalışma kılavuzu

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Şunun bir parçası: AWS SAA-C03 — Eksiksiz çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Amazon sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

CloudWatch: Metrikler, Ad Alanları, Panolar ve Alarmlar

CloudWatch, AWS hizmetleri için varsayılan telemetri düzlemidir, ancak kullanışlılığı, bir hizmetin hangi ad alanına (namespace) yayın yaptığını bilmeye tamamen bağlıdır. Ad alanı, hizmetler arasında çakışmaları önleyen bir metrik kapsayıcısıdır — AWS/Lambda ad alanı fonksiyonlar için Invocations, Errors ve Throttles metriklerini tutarken, AWS/Events ad alanı EventBridge kuralları için Invocations, FailedInvocations, TriggeredRules ve MatchedEvents metriklerini tutar. Bu ayrım, olay güdümlü (event-driven) işlem hatlarını teşhis ederken önem kazanır. Bir EventBridge kuralı, bir API hedefi aracılığıyla üçüncü taraf bir API’yi çağırırsa ve alt akışa (downstream) hiç trafik ulaşmazsa, cevap AWS/Lambda‘da değil, AWS/Events‘dedir. TriggeredRules metriğini kontrol etmek, kural deseninin gerçekten eşleşip eşleşmediğini, Invocations/FailedInvocations ise hedefin kendisinin çağrılıp çağrılmadığını ve çağrının başarılı olup olmadığını söyler. Lambda daha bilinen bir hizmet olduğu için Lambda metriklerinde arama yapmak, kuralın gelen bir olayla hiçbir zaman eşleşmemiş olabileceği gerçeğini gözden kaçırır.

Metrik çözünürlüğü, maliyet etkileri olan kaynak başına bir ayardır. Temel izleme (Basic monitoring), ek ücret olmadan her beş dakikada bir metrik yayınlar; bu, uzun süreli kararlı durumdaki iş yükleri için yeterli olsa da, dakika başına çözünürlük gerektiren otomasyonlu ölçeklendirme (autoscaling) tepkileri, ani artış tespiti veya SLO hesaplamaları için çok kabadır. Ayrıntılı izleme (Detailed monitoring) bunu bir dakikaya (ve özel yüksek çözünürlüklü metrikler için bir saniyeye) düşürür; ölçeklendirme gruplarının hızlı tepki vermesi gerektiğinde etkinleştirdiğiniz şey budur. Bu ücretli bir özelliktir ve varsayılan olarak açık olmamasının nedeni budur.

Her hizmet varsayılan olarak bir dizi metrik yayınlar, ancak hipervizör (hypervisor) konuk işletim sisteminin (guest OS) içini göremez. CPUUtilization, NetworkIn ve DiskReadOps gibi metrikler EC2 için çaba gerektirmeden görülebilir; bellek kullanımı ve dosya sistemi kullanım yüzdeleri CloudWatch agent’ını gerektirir ve bunları elde etmenin tek yolu budur. Özel uygulama metrikleri de agent aracılığıyla veya PutMetricData API’si ile gelir.

Alarmlar, gürültüden sinyali ayırt etmelidir. CPU > %50 için tek bir alarm, normal ani artışlar sırasında sürekli tetiklenir ve operatörleri bunu görmezden gelmeye alıştırır. Bileşik alarmlar (Composite alarms), alt alarm durumlarını bir Boole kural ifadesiyle birleştirir, böylece operatörler yalnızca gerçekten eyleme geçilebilir bir durum oluştuğunda çağrı alır. Geçici CPU artışlarının zararsız olduğu ancak sürekli CPU baskısının yüksek disk okuma IOPS’u ile birleştiğinde gerçek bir soruna işaret ettiği bir iş yükü için:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Alt alarmlar dahili olarak ALARM durumuna geçebilir, ancak yalnızca bileşik alarm SNS’i tetikler. Nöbetçiyi çağıran iki bağımsız alarm, gürültü sorununu yeniden yaratır; daha yüksek bir eşikteki tek bir alarm ise bu korelasyonu kaçırır.

Panolar (Dashboards), metrik widget’larını, günlük (log) widget’larını ve metinleri bir araya getirir. İki paylaşım modeli vardır ve bunları karıştırmak sık düşülen bir tuzaktır. İzleyicinin zaten bir AWS hesabı varsa, onlara cloudwatch:GetDashboard ve cloudwatch:GetMetricData izinleriyle bir IAM kimliği (veya hesaplar arası gözlemlenebilirlik aracılığıyla bir rol) verin. İzleyicinin bir AWS hesabı yoksa - örneğin bir ürün yöneticisi, bir müşteri paydaşı - yerleşik pano paylaşım özelliğini kullanın; bu özellik, tek bir e-posta/şifre, bir Cognito kullanıcı havuzu veya genel bir URL (nadiren uygun olur) ile korunan paylaşılabilir bir bağlantı oluşturur. Ekran görüntüsü e-postalamak gözlemlenebilirlik değildir ve AWS kullanıcısı olmayan bir izleyici için konsol erişimine sahip bir IAM kullanıcısı oluşturmak en az ayrıcalık (least-privilege) ilkesine aykırıdır.

OAM ile Hesaplar Arası Gözlemlenebilirlik

Metrikleri görüntülemek için onlarca hesap arasında geçiş yapmak sürdürülebilir değildir. CloudWatch hesaplar arası gözlemlenebilirlik, merkezi bir alıcı (sink) olarak bir izleme hesabı (monitoring account) ve metrikleri, günlükleri ve izleri (trace) bu hesapla alıcı ve bağlantı (sink and link) kaynakları aracılığıyla paylaşan herhangi bir sayıda kaynak hesap (source account) belirler. Geniş ölçekte en hızlı dağıtım yöntemi, izleme hesabında CloudWatch konsolunu açmak, bir alıcı (sink) oluşturmak ve her kaynak hesapta AWS::Oam::Link kaynakları oluşturmak için üretilen CloudFormation StackSet şablonunu organizasyon geneline dağıtmaktır:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Bunu hesaplar arası IAM rolleri ve manuel sorgularla çözmek teknik olarak mümkündür, ancak bu size birleşik panolar, hesaplar arası Metrics Insights sorguları veya OAM bağlantılarının sağladığı otomatik hesap adı etiket zenginleştirmesini vermez.

Container Insights ve Dağıtık İzleme (Distributed Tracing)

Konteynerleştirilmiş iş yükleri için Container Insights, standart CloudWatch özelliğidir. EKS üzerinde, CloudWatch agent’ını (veya ADOT collector’ı) bir DaemonSet olarak ve günlük yönlendirme için Fluent Bit’i dağıtır. Agent, cAdvisor ve kubelet metriklerini toplar (scrape) ve bunları ECS/ContainerInsights ve ContainerInsights ad alanlarına (pod, node, namespace ve cluster başına CPU/bellek) yayınlarken, Fluent Bit ise stdout/stderr çıktılarını /aws/containerinsights/<cluster>/application, /dataplane ve /host gibi günlük gruplarına gönderir. Kendi Prometheus/Grafana yığınınızı kurmak mümkündür; ancak yönetilen model Container Insights artı Logs Insights’tır:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Metrikler size bir şeyin yavaş olduğunu söyler; izler (trace’ler) ise nerede yavaş olduğunu söyler. X-Ray, bir istek yolundaki her hizmeti izler (instrument), X-Amzn-Trace-Id başlığı aracılığıyla bir izleme kimliği (trace ID) yayar ve segmentler ile alt segmentleri X-Ray daemon’ına veya ADOT collector’a gönderir. Hizmet haritası (service map), düğümleri ve bağlantıları gecikme, hata ve arıza yüzdeleriyle görselleştirir. X-Ray olmadan, bir p99 ani artışı, kaynağı belirsiz bir CloudWatch metriği olarak ortaya çıkar.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights, X-Ray ve CloudWatch Logs, mikroservis gözlemlenebilirliği için üç sacayağını oluşturur.

Üç Log Akışı: CloudTrail, VPC Flow Logs, CloudWatch Logs

Herhangi bir AWS gözlemlenebilirlik stratejisi üç farklı log akışını birbirinden ayırır: yönetim düzlemi API etkinliği (CloudTrail), veri düzlemi ağ etkinliği (VPC Flow Logs) ve uygulama/işletim sistemi çıktısı (CloudWatch Logs). Her biri farklı bir adli bilişim sorusunu yanıtlar ve bunları birbirine karıştırmak yaygın bir tasarım hatasıdır.

CloudTrail, her AWS API çağrısını kaydeder: kimin (userIdentity) çağırdığını, hangi IP’den, hangi kaynağa karşı, hangi parametrelerle ve başarılı olup olmadığını. Bir değişikliği belirli bir IAM principal’ına güvenilir bir şekilde bağlayan tek hizmet budur. Yaygın bir yanılgı, API etkinliğini aramak için doğru yerin CloudWatch Logs olduğudur; CloudWatch Logs, principal seviyesinde denetim verilerini değil, uygulama/sistem çıktılarını yakalar. CloudTrail, gerçek zamanlı metrik filtreleme için olaylarını CloudWatch Logs’a teslim edebilir, ancak temel denetim kaydı CloudTrail’de oluşturulur.

Bir AWS Organizations ortamında doğru model, yönetim (veya yetkilendirilmiş yönetici) hesabından oluşturulan ve yeni üye hesapları otomatik olarak kaydedip olayları özel bir log arşiv hesabındaki tek bir S3 bucket’ına aktaran bir kuruluş izidir (organization trail):

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

Hedef bucket’ın sürüm oluşturma (versioning), s3:PutObject eylemini CloudTrail hizmet principal’ı ile kısıtlayan bir bucket politikası, SSE-KMS şifrelemesi, denetçiler için hesaplar arası salt okunur erişim ve ideal olarak WORM (Write Once, Read Many - Bir Kez Yaz, Çok Kez Oku) garantileri için uyumluluk modunda S3 Object Lock özelliklerine sahip olması gerekir. Log dosyası doğrulaması, kurcalamanın tespit edilebilmesi için imzalı özet dosyaları (digest files) üretir. Yönetim olayları (Management events) varsayılan olarak 90 gün boyunca açıktır; bu süreden daha uzun saklamak için bir iz (trail) gerekir. Veri olayları (Data events) (S3 nesne seviyesi, Lambda invoke, DynamoDB öğe seviyesi) hacim ve maliyet nedeniyle isteğe bağlıdır. Geçmişe yönelik anlık sorgular için, iz (trail) bucket’ı üzerinde CloudTrail Lake veya Athena kullanarak SQL çalıştırabilirsiniz:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs, bir VPC, alt ağ (subnet) veya ENI için IP trafiği hakkındaki üst verileri (metadata) yakalar: 5’li demet (5-tuple), baytlar, paketler, eylem (ACCEPT/REJECT) ve log durumu. Yükleri (payloads) yakalamazlar. Teslimat hedefleri CloudWatch Logs, S3 veya Kinesis Data Firehose’dur. Arşivleme yaparken S3’ü seçin; şüpheli trafik desenlerine karşı alarmları tetiklemek için metrik filtrelerine ihtiyacınız olduğunda CloudWatch Logs’u seçin; gereksinim gerçek zamanlıya yakın analiz olduğunda Firehose’u seçin. NLB’ler, ASG’ler ve veritabanları içeren bir VPC için standart gerçek zamanlıya yakın işlem hattı:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Alternatif CloudWatch Logs → abonelik filtresi → Firehose → OpenSearch yolu çalışır ancak ek bir atlama (hop) ve maliyet getirir. Gereksinim “gerçek zamanlıya yakın” olduğunda S3 yanlış bir seçimdir. Flow Logs’u hiç etkinleştirmemek en zararlı tuzaktır: bir güvenlik olayı meydana geldiğinde kaynak/hedef/port kaydı ve ACCEPT/REJECT görünürlüğü olmaz. Aynı mantık ALB erişim logları (access logs) için de geçerlidir; isteğe bağlıdırlar, S3’e teslim edilirler ve onlar olmadan istemci IP’leri, yanıt kodları, hedef gecikmeleri veya kullanıcı aracıları (user agents) hakkında istek seviyesinde bir kayıt bulunmaz. Birlikte, Flow Logs (L3/L4) ve ALB erişim logları (L7), trafik adli bilişim temelini (forensics baseline) oluşturur.

CloudWatch Logs, CloudWatch ajanı aracılığıyla uygulama, Lambda ve işletim sistemi loglarını alır. Gücünü metrik filtrelerinden alır: gelen olayları tarayan ve bir eşleşme olduğunda özel bir metriği artıran desen ifadeleri (pattern expressions), bu da bir alarmı tetikler:

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

3389 portu üzerindeki paralel bir filtre RDP’yi kapsar. Uyarı mekanizması olmadan log toplama, önleme değil, olay sonrası adli bilişim sağlar.

Büyük filolar için standart yöntem, bir log grubu üzerindeki bir abonelik filtresi aracılığıyla logları bir işlem hattına yaymak ve eşleşen olayları gerçek zamanlıya yakın bir şekilde bir Kinesis Data Stream, Firehose veya Lambda’ya aktarmaktır:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

Tuzak, ham logları bir işlem hattı olmadan depolamaya göndermektir: Glue kataloğu, OpenSearch indeksi ve Athena çalışma grubu olmadan S3’e yığmak, logların var olduğu ancak bir olay sırasında üzerinde işlem yapılamayacağı anlamına gelir. Gözlemlenebilirlik, sadece kalıcı baytları değil, bir sorgu yüzeyi gerektirir. Log gruplarının ayrıca açık saklama politikalarına (retention policies) ihtiyacı vardır — varsayılan “asla süresi dolmaz” ayarıdır ve bu sessizce para yakar — ve yaşam döngüsü kuralları (lifecycle rules) altında uzun süreli arşivleme için S3’e ihraç edilebilirler.

En Düşük Ek Yük ile API Seviyesinde Olay Tespiti

Yüksek değerli kontrol düzlemi olayları — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, MFA’sız ConsoleLogin — için en düşük ek yüke sahip model CloudTrail → EventBridge kuralı → SNS’tir. EventBridge, her CloudTrail yönetim olayını yerel olarak alır ve bir olay desenine (event pattern) sahip bir kural, Lambda yapıştırıcı koduna (glue code) ihtiyaç duymaz:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

CloudTrail’i CloudWatch Logs’a gönderip bir metrik filtresi uygulamak da işe yarar, ancak bir log grubu, filtre, alarm ve maliyet ekler, bu nedenle gereksinim sadece “X API’sinde uyar” olduğunda operasyonel ek yük açısından dezavantajlıdır.

AWS Config: Sürekli Yapılandırma ve Sapma

Config ve CloudTrail sıkça karıştırılır ancak temelde farklı soruları yanıtlarlar. CloudTrail kimin neyi çağırdığını kaydederken; Config kaynağın şu an nasıl göründüğünü ve zaman içinde nasıl değiştiğini kaydeder. Config’in API çağrılarını loglamasını beklemek klasik bir yanlış cevaptır — Config, bir kullanıcının PutBucketAcl komutunu çağırdığını bilmez; o, saat 14:03:22’de bucket’ın ACL’sinin A durumundan B durumuna değiştiğini bilir. Sorumluyu (principal) belirlemek için, Config değişiklik kaydını aynı zaman damgasındaki CloudTrail olayıyla ilişkilendirin (Config konsolunda buna derin bir bağlantı verir).

Config kuralları kaynakları istenen duruma göre değerlendirir. Yönetilen kurallar yaygın kontrolleri kapsar (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type) ve özel kurallar Lambda fonksiyonları olarak çalışır veya CloudFormation Guard kullanır. Kurallar, yapılandırma değişikliğinde ve belirli bir programa göre değerlendirme yapar, kaynakları COMPLIANT veya NON_COMPLIANT olarak işaretler ve SSM Automation belgeleri aracılığıyla otomatik düzeltmeyi tetikleyebilir. Bu, “açık SSH’ı tespit et” veya “fazla büyük instance tiplerini tespit et” gibi sorulara yönelik düşük operasyonel yüke sahip bir cevaptır — kurallar zaten mevcuttur ve SNS ile Security Hub’a doğal olarak entegre olurlar. Periyodik manuel denetimler, zamanlanmış taramalar veya kendi geliştirdiğiniz tarayıcıları önermek, Config’in zaten sunduğu bir kod parçasını sizin yazmanızı ve bakımını yapmanızı gerektirir.

Config, değerlendirme sonuçlarını SNS’e yayınlar. Otomatik düzeltme için, bir EventBridge kuralını uyumluluk değişikliği olayına bağlayın ve bir SSM Automation belgesini veya Lambda’yı çağırın:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Aggregator’lar (Toplayıcılar) bir organizasyon genelindeki uyumluluğu birleştirir; conformance pack’ler (uygunluk paketleri) PCI-DSS veya HIPAA gibi çerçeveler için kuralları bir araya getirir. Workload Discovery on AWS (eski adıyla AWS Perspective), Config üzerine inşa edilmiş, kaynak ilişkilerini görselleştiren ve mimari diyagramlar oluşturan bir çözümdür — bir soruda mevcut bir ortamın diyagramını çizebilecek bir envanter aracı istendiğinde verilecek standart cevaptır. Config bir ön koşuldur.

Security Hub, GuardDuty ve Control Tower

Security Hub, güvenlik bulguları için bir toplama düzlemidir. GuardDuty (VPC Akış Logları, DNS ve CloudTrail’e dayalı tehdit tespiti), Inspector (zayıflık bulguları), Macie, IAM Access Analyzer ve Config’den veri alır, ardından her şeyi AWS Security Finding Format (ASFF) standardına göre normalleştirir. Security Hub’ı etkinleştirmek aynı zamanda güvenlik standartlarını, özellikle de AWS Foundational Security Best Practices (FSBP) standardını etkinleştirir — bu standart, arka planda Config kurallarıyla eşleştirilmiş düzinelerce otomatik kontrol (root MFA, halka açık S3, şifrelenmemiş EBS, çok bölgeli CloudTrail) içerir.

Organizasyon ölçeğinde, Security Hub (ve GuardDuty ile Config) için bir delegated administrator account (yetkilendirilmiş yönetici hesabı) belirleyin, “yeni hesapları otomatik etkinleştir” seçeneğiyle tüm organizasyon için servisi ve FSBP standardını etkinleştirin ve bulguları, Security Hub Findings - Imported olayını FSBP standardı ARN’sine göre ve Compliance.Status = FAILED ile filtreleyerek EventBridge üzerinden SNS’e yönlendirin. Kendi CloudTrail ayrıştırıcı Lambda’nızı veya hesap başına panolarınızı oluşturmak, Security Hub’ın zaten üstlendiği bir operasyonel yük ekler.

Önemli bir kavramsal ayrım: Security Hub önleyici değil, tespit edici ve toplayıcıdır. Sapmayı önlemek, iyi mimarilmiş çoklu hesaplı bir landing zone düzenleyen AWS Control Tower‘ın görevidir. Account Factory, yeni hesapları temel ağ, loglama ve IAM yapılandırmalarıyla sağlar. Yönetişim, üç türdeki guardrail (koruma rayı) aracılığıyla ifade edilir:

Proaktif kontroller, bir stack dağıtılmadan önce CloudFormation şablonlarını değerlendirir ve örneğin şifrelenmemiş bir RDS instance’ının oluşturulmasını reddeder. Security Hub ise şifrelenmemiş instance’ın var olduğunu ancak çalışmaya başladıktan sonra size söyler. Eğer bir gereksinim “önle” diyorsa, Control Tower’ı düşünün. Eğer “tespit et, bildir veya topla” diyorsa, Security Hub veya Config’i düşünün.

Macie: Hassas Veri Keşfi

Macie, S3 nesneleri içindeki hassas verileri — PII (Kişisel Tanımlanabilir Bilgiler), finansal veriler, kimlik bilgileri — tanımlamak için makine öğrenmesi ve desen eşleştirme kullanır. Kritik tuzak, Macie’nin veriyi koruduğunu varsaymaktır. Korumaz. Macie keşfeder ve raporlar. Doğru kullanım:

1. Hedef hesapta/bölgede Macie’yi etkinleştirin.
2. Belirli bir programa göre bucket’ları/ön ekleri/etiketleri hedefleyen bir hassas veri keşif işi yapılandırın.
3. Bulguları bildirimler için SNS’e, düzeltme (karantina, bucket politikasını sıkılaştırma) için Lambda’ya veya Security Hub’a EventBridge (source: aws.macie) aracılığıyla yönlendirin.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Keşif işi olmadan Macie hiçbir şey üretmez. EventBridge → SNS bağlantısı olmadan, bulgular Macie konsolunda fark edilmeden kalır.

Organizations, SCP’ler ve Etiket İlkeleri

AWS Organizations, bu bağlamda ilgili üç ilke türü sunar. Etiket ilkeleri (Tag policies), izin verilen etiket anahtarlarını, büyük/küçük harf kullanımını ve değerleri tanımlar. Bu ilkeler, uyumsuzlukları raporlar ve aws:ResourceTag/aws:RequestTag koşullarıyla birleştirildiğinde zorunlu kılınabilir. Hizmet Kontrol İlkeleri (Service Control Policies - SCP’ler), üye kimliklerine (principal) sunulan maksimum izinleri tanımlar. Yedekleme ilkeleri (Backup policies) ve Yapay Zeka kapsam dışı bırakma ilkeleri (AI opt-out policies) bu seti tamamlar.

Önemli bir zihinsel model: SCP’ler asla izin vermez. Bunlar, IAM’in (kimlik ilkeleri, kaynak ilkeleri, izin sınırları) normalde izin verebileceği şeyler üzerinde bir filtredir. Bir kimliğin (principal) bir IAM Allow iznine sahip olması ve SCP’nin bu eylemi Deny ile engellememesi (veya Allow listesine dahil etmesi) gerekir. “Sadece bir SCP ekle” ifadesi, bir izin sorusu için asla tam bir cevap değildir. Bir IAM Allow izni olmadan, SCP’nin içeriğinden bağımsız olarak kimlik varsayılan olarak reddedilir.

Oluşturma sırasında etiketleri zorunlu kılmak için, etiket ilkelerini aşağıdaki gibi bir SCP ile birleştirin:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

Etiket ilkesi şemayı bildirir; SCP etiketsiz oluşturmayı reddeder; IAM ilkesi oluşturma eylemine izin verir. Üçü de gereklidir. AWS Config’in required-tags kuralı, mevcut uyumsuz kaynakları tespit eder ve düzeltir.

Systems Manager Otomasyonu ve Yama Yönetimi

Systems Manager (SSM), EC2 ve hibrit düğüm filolarındaki yaşam döngüsü faaliyetleri için operasyonel omurgadır. Yama yönetimi için en önemli iki yapı şunlardır: Otomasyon belgeleri (Automation documents - AWS API’lerini veya betikleri çağıran bildirimsel YAML/JSON runbook’ları) ve Bakım Pencereleri (Maintenance Windows - bu runbook’ları, eşzamanlılık ve hata eşikleri olan bir değişiklik penceresi içinde etiket tabanlı hedeflere veya kaynak gruplarına karşı zamanlayan pencereler).

Standart yama yönetimi akışı, işletim sistemine göre onay kurallarını tanımlayan bir Patch Baseline kullanarak, bir Patch Group etiketiyle seçilen sunuculara karşı yürütülen AWS-RunPatchBaseline (bir Command belgesi) komutudur. Yük dengeleyicilerin arkasındaki sunucular için, AWS-RunPatchBaseline komutunu doğrudan çalıştırmak, sunucular hedef grubunda InService durumunda kaldığı için yama ortasında bağlantıları keser. Doğru model, aşağıdaki adımları gerçekleştiren AWSEC2-PatchLoadBalancerInstance otomasyonudur:

1. Sunucuyu CLB veya ALB hedef grubundan kaydını siler (deregister).
2. Bağlantıların boşaltılmasını (connection draining) / kayıt silme gecikmesini bekler.
3. Yama taban çizgisi (patch baseline) tarama ve yükleme adımlarını başlatır.
4. Taban çizgisi gerektiriyorsa yeniden başlatır.
5. Sunucuyu yeniden kaydeder ve hedef sağlık durumunun healthy olmasını bekler.

İki ön koşul, “hata üretir” şeklindeki başarısızlık moduna neden olur. İlk olarak, AutomationAssumeRole olarak geçirilen IAM rolü, standart SSM yama yönetimi izinlerine ek olarak elasticloadbalancing:DeregisterTargets, RegisterTargets ve DescribeTargetHealth izinlerini içermelidir. İkinci olarak, sunucu bir yönetilen düğüm (managed node) olmalıdır; yani SSM Agent çalışıyor olmalı ve sunucu profili (instance profile) AmazonSSMManagedInstanceCore politikasını içermelidir. Bunlar olmadan, kayıt silme çağrıları başarısız olur veya SSM sunucuyu göremez.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Güvenlik · Tüm alanlar · Yüksek Erişilebilirlik →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Amazon'a göz atın →