# Cloud DDoS Saldırıları Nedir? Bulut Altyapılarında DDoS Koruması Nasıl Sağlanır?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/ddos-simulasyonu/cloud-ddos-saldirilari-nedir

![Cloud DDoS Saldırıları Nedir? Bulut Altyapılarında DDoS Koruması Nasıl Sağlanır?](/images/bilgi-merkezi/covers/cover-ddos-08.webp)

Bulut altyapısına geçmek birçok kurum için ölçeklenebilirlik, esneklik ve yüksek erişilebilirlik avantajı sağlar.

Ancak cloud kullanmak DDoS riskini ortadan kaldırmaz.

Hatta bazı durumlarda riskin şekli değişir.

Fiziksel data center ortamında saldırı;

internet hattını,

firewall'u,

router'ı,

load balancer'ı

hedefleyebilirken, bulut ortamında saldırgan;

public IP,

cloud load balancer,

API Gateway,

web application,

authentication service,

container platformu,

autoscaling mekanizması

gibi farklı bileşenleri hedefleyebilir.

Bu nedenle **Cloud DDoS Protection – Bulut DDoS Koruması**, yalnızca yüksek kapasiteye sahip bir cloud provider kullanmaktan ibaret değildir.

Asıl soru şudur:

#### Bulut altyapınız saldırı altında hem erişilebilir hem de maliyet açısından sürdürülebilir kalabiliyor mu?

Bu noktada **Cloud DDoS, AWS DDoS Protection, Azure DDoS Protection, Google Cloud DDoS Security, WAF, CDN, Autoscaling, Multi-Region Architecture ve EDoS** gibi kavramlar önem kazanır.

#### Cloud DDoS Nedir?

**Cloud DDoS**, bulut üzerinde çalışan servislerin Distributed Denial of Service saldırılarıyla hedef alınmasını ifade eder.

Bu hedefler;

- virtual machine,
- public IP,
- cloud load balancer,
- API Gateway,
- Kubernetes ingress,
- web application,
- DNS,
- authentication service,
- serverless function

olabilir.

Bulut ortamının ölçeklenebilir olması saldırının etkisini azaltabilir.

Ancak sınırsız kapasite anlamına gelmez.

Ayrıca saldırı teknik olarak sistemi çökertmese bile maliyetleri ciddi şekilde artırabilir.

### Cloud Ortamları DDoS'a Karşı Daha Güvenli midir?

Bazı açılardan evet.

Büyük cloud provider'lar;

geniş network kapasitesi,

Anycast altyapısı,

global edge network,

otomatik mitigation

gibi avantajlar sağlayabilir.

Ancak bu durum her cloud workload'un otomatik olarak güvenli olduğu anlamına gelmez.

Örneğin yanlış yapılandırılmış bir public IP doğrudan internete açık olabilir.

Bir API endpoint'i rate limit olmadan hizmet veriyor olabilir.

Bir autoscaling group saldırı altında sürekli yeni instance açabilir.

Bu nedenle cloud security'nin temel prensibi yine aynıdır:

**Varsayılan kapasiteye değil, doğru mimariye güvenmek gerekir.**

### Public IP DDoS Riski Nedir?

Bulut ortamındaki public IP adresleri doğrudan saldırı yüzeyidir.

Özellikle;

virtual machine,

load balancer,

VPN gateway,

public API

üzerinde public IP bulunuyorsa saldırgan bu servisi hedefleyebilir.

Bu nedenle cloud mimarisinde mümkün olduğunca doğrudan internet erişimi azaltılmalı ve trafik;

CDN,

WAF,

reverse proxy,

load balancer

gibi kontrollü katmanlardan geçirilmelidir.

### Origin Exposure Cloud Ortamında Neden Kritiktir?

Bir web uygulaması CDN ve WAF arkasında olabilir.

Ancak saldırgan backend origin IP'yi biliyorsa doğrudan bu adrese saldırabilir.

Bu durumda CDN ve WAF koruması bypass edilmiş olur.

Bu nedenle cloud ortamlarında;

security group,

network ACL,

firewall rule

kullanılarak origin yalnızca güvenilir edge kaynaklarından trafik kabul edecek şekilde sınırlandırılmalıdır.

### Cloud Load Balancer DDoS'a Karşı Ne Kadar Dayanıklıdır?

Cloud load balancer'lar genellikle yüksek ölçeklenebilirlik sağlar.

Ancak sınırsız değildir.

Özellikle;

TLS handshake,

new connection rate,

HTTP request rate,

backend connection

yükleri önemlidir.

Ayrıca load balancer ayakta kalırken arka taraftaki application instance'ları veya database darboğaza girebilir.

Bu nedenle sadece load balancer'ın kapasitesine bakmak yeterli değildir.

### Autoscaling DDoS Koruması Sağlar mı?

Autoscaling, trafik arttıkça yeni compute instance'larının devreye alınmasını sağlar.

Bu availability açısından faydalıdır.

Ancak saldırgan trafiği sürdürürse sistem sürekli büyüyebilir.

Bu durumda iki sonuç ortaya çıkabilir:

**Hizmet ayakta kalır.**

Ama aynı zamanda:

**Cloud faturası hızla yükselir.**

Bu nedenle autoscaling tek başına DDoS koruması değildir.

Trafiğin meşru olup olmadığı da analiz edilmelidir.

### EDoS Nedir?

**Economic Denial of Sustainability – EDoS**, özellikle cloud ortamlarında saldırının sistemi tamamen çökertmek yerine ekonomik olarak sürdürülemez hale getirmesini ifade eder.

Örneğin;

serverless function sürekli tetiklenir,

autoscaling yüzlerce instance açar,

database I/O tüketimi yükselir,

egress trafiği artar.

Sistem çalışmaya devam eder.

Ancak maliyet normalin onlarca katına çıkabilir.

Bu nedenle cloud DDoS güvenliğinde **cost monitoring ve budget protection** teknik güvenlik kadar önemlidir.

### Serverless DDoS Riski

Serverless mimariler otomatik ölçeklenebilir.

Bu büyük avantajdır.

Ancak saldırgan çok sayıda request gönderdiğinde function invocation sayısı hızla artabilir.

Bu durum;

execution cost,

downstream database load,

API call cost

oluşturabilir.

Bu nedenle serverless uygulamalarda;

rate limiting,

authentication,

quota,

API Gateway protection

kritiktir.

### API Gateway DDoS'a Karşı Nasıl Korunur?

API Gateway cloud ortamlarında önemli savunma katmanlarından biridir.

Şu kontroller uygulanabilir:

#### Rate Limiting

İstemci başına request sınırı.

#### Quota

Belirli zaman aralığında toplam kullanım limiti.

#### Authentication

Anonim erişimin azaltılması.

#### Request Validation

Geçersiz veya anormal isteklerin reddedilmesi.

#### WAF Integration

HTTP saldırılarının analiz edilmesi.

Bu kontroller API DDoS riskini azaltabilir.

### Cloud WAF Ne İşe Yarar?

Cloud WAF, HTTP/HTTPS trafiğini application layer seviyesinde analiz eder.

Örneğin;

HTTP Flood,

bot traffic,

API abuse,

malicious request

tespit edilebilir.

Cloud WAF'ların avantajı genellikle edge network'e entegre olmalarıdır.

Böylece trafik origin'e ulaşmadan filtrelenebilir.

### Cloud CDN DDoS Korumasında Nasıl Yardımcı Olur?

CDN;

statik içerikleri edge üzerinde sunar,

origin yükünü azaltır,

trafik dağılımını coğrafi olarak yayar.

Bu durum özellikle web tabanlı servislerin DDoS dayanıklılığını artırır.

Ancak dinamik API trafiği veya authentication işlemleri yine backend'e ulaşabilir.

Bu nedenle CDN tek başına yeterli değildir.

### Multi-Region Architecture Nedir?

**Multi-Region Architecture**, uygulamanın birden fazla cloud region üzerinde çalışmasıdır.

Amaç tek bir bölge problem yaşadığında diğer bölgelerin hizmet vermeye devam etmesidir.

DDoS açısından avantajı trafik yükünün dağıtılması ve failover seçeneği sağlamasıdır.

Ancak multi-region mimari;

data replication,

routing,

DNS,

application consistency

gibi karmaşık konular içerir.

### Active-Active Cloud Mimari

Active-Active yapıda birden fazla region aynı anda trafik alabilir.

Bu durum DDoS dayanıklılığı açısından güçlü olabilir.

Çünkü saldırı yükü tek bir bölgeye binmez.

Ancak global load balancing ve backend kapasitesinin doğru tasarlanması gerekir.

### Active-Passive Cloud Mimari

Active-Passive modelde ana region aktif çalışır.

İkinci region standby durumdadır.

Saldırı veya servis kesintisi durumunda failover yapılabilir.

Bu modelde kritik soru:

#### Failover ne kadar hızlı gerçekleşiyor?

RTO burada önemli metriktir.

### Global Load Balancing DDoS İçin Neden Önemlidir?

Global load balancer kullanıcıları farklı region veya edge noktalarına yönlendirebilir.

Bu sayede;

geographic distribution,

failover,

traffic steering

sağlanabilir.

DDoS saldırısında belirli bölgenin aşırı yüklenmesi durumunda trafik başka bölgelere dağıtılabilir.

Ancak saldırı global ise tek başına yeterli olmayabilir.

### Anycast Cloud DDoS'ta Nasıl Kullanılır?

Anycast aynı IP adresinin farklı lokasyonlardan duyurulmasını sağlar.

Bu sayede trafik en yakın veya en uygun edge noktasına ulaşabilir.

DDoS saldırısında trafik geniş altyapıya yayılır.

Bu yaklaşım cloud ve CDN tabanlı DDoS çözümlerinde yaygındır.

### Cloud DNS DDoS Koruması

DNS hizmeti cloud uygulamalarının erişilebilirliği için kritiktir.

DNS çökerse uygulama ayakta olsa bile kullanıcı erişemez.

Bu nedenle;

Anycast DNS,

multiple DNS servers,

secondary DNS,

DNS rate limiting

kullanılabilir.

### Managed DNS ile Self-Hosted DNS Arasındaki Risk

Self-hosted DNS tam kontrol sağlar.

Ancak kapasite ve DDoS savunması kurumun sorumluluğundadır.

Managed DNS hizmetleri genellikle daha büyük dağıtık altyapıya sahip olabilir.

Kritik uygulamalarda managed veya redundant DNS tercih edilmesi availability açısından avantajlı olabilir.

### Kubernetes DDoS Riski

Kubernetes ortamlarında uygulamalar;

Ingress Controller,

Load Balancer,

Service,

Pod

katmanlarından geçebilir.

DDoS saldırısı bu zincirin farklı noktalarını etkileyebilir.

Örneğin Ingress Controller CPU tüketimi kritik hale gelebilir.

Pod autoscaling devreye girebilir.

Ancak database aynı hızda scale olmayabilir.

Bu nedenle Kubernetes DDoS dayanıklılığı uçtan uca test edilmelidir.

### Kubernetes HPA DDoS'u Çözer mi?

**Horizontal Pod Autoscaler – HPA**, yük arttığında pod sayısını artırabilir.

Bu availability açısından faydalıdır.

Ancak saldırı trafiği devam ederse pod sayısı sürekli artabilir.

Ayrıca node kapasitesi veya backend servisleri sınır oluşturabilir.

Bu nedenle HPA tek başına DDoS mitigation değildir.

### Ingress Controller DDoS Darboğazı Olabilir mi?

Evet.

Ingress Controller;

TLS termination,

routing,

rate limiting,

WAF

gibi işlemleri yapabilir.

Yoğun Layer 7 saldırısında Ingress Controller CPU veya connection limiti kritik hale gelebilir.

Bu nedenle Kubernetes DDoS testlerinde ingress telemetry izlenmelidir.

### Microservice Mimarisinde DDoS Riski

Microservice yapılarında tek bir request birden fazla servisi tetikleyebilir.

Örneğin:

API

↓

Auth Service

↓

Order Service

↓

Payment Service

↓

Database

Tek bir kötü amaçlı request zincirleme kaynak tüketimi oluşturabilir.

Bu nedenle DDoS riskinin sadece public endpoint'te değil, internal service dependency seviyesinde de değerlendirilmesi gerekir.

### Cascade Failure Nedir?

Bir servis aşırı yüklendiğinde diğer servisler ona tekrar tekrar request gönderebilir.

Bu durum zincirleme çöküş oluşturabilir.

Buna **Cascade Failure** denir.

Circuit Breaker ve timeout mekanizmaları bu riski azaltabilir.

### Circuit Breaker Cloud DDoS'ta Nasıl Yardımcı Olur?

Circuit Breaker belirli bir downstream servis sürekli hata verdiğinde çağrıları geçici olarak durdurabilir.

Bu sayede bir servisin çökmesi diğer servislerin de kaynak tüketmesini önleyebilir.

Cloud-native uygulamalarda resilience açısından önemlidir.

### Load Shedding Cloud Ortamında Neden Önemlidir?

Saldırı altında tüm request'leri işlemeye çalışmak yerine düşük öncelikli request'ler reddedilebilir.

Örneğin;

raporlama,

arama,

anonim içerik

geçici olarak sınırlandırılabilir.

Kritik işlemler korunabilir.

Bu yaklaşım cloud maliyetlerini de kontrol altında tutabilir.

### Cloud Security Group DDoS Koruması Sağlar mı?

Security Group veya network firewall;

port,

IP,

protocol

bazında erişim kontrolü sağlar.

Ancak büyük volumetric saldırıların tek başına çözümü değildir.

Özellikle cloud provider edge seviyesinde DDoS mitigation gerekebilir.

Security Group daha çok saldırı yüzeyini azaltır.

### Cloud NAT DDoS Darboğazı Olabilir mi?

Evet.

Cloud NAT servislerinin;

connection,

throughput,

port allocation

limitleri olabilir.

Yoğun trafik altında NAT kaynağı tükenebilir.

Bu nedenle outbound dependency kullanan uygulamalarda NAT kapasitesi de resilience testinde değerlendirilmelidir.

### Cloud Egress Maliyetleri DDoS'ta Neden Önemlidir?

Cloud ortamlarında data transfer ücretleri önemli maliyet oluşturabilir.

DDoS sırasında yoğun egress trafiği maliyeti artırabilir.

Bu nedenle monitoring sadece compute değil;

network egress,

API usage,

storage operation

gibi maliyet metriklerini de içermelidir.

### Budget Alert Güvenlik Kontrolü müdür?

Doğrudan saldırıyı engellemez.

Ancak EDoS riskini erken fark etmek için önemlidir.

Örneğin normal günlük maliyet:

1.000 USD

iken saldırı sırasında:

5.000 USD

seviyesine çıktığında alarm oluşturulabilir.

Bu durum SOC ve FinOps ekiplerine sinyal sağlayabilir.

### FinOps ile DDoS Güvenliği Arasındaki İlişki

**FinOps**, cloud maliyetlerinin izlenmesi ve optimize edilmesine odaklanır.

DDoS saldırıları cloud maliyetlerini etkileyebileceği için FinOps verileri güvenlik açısından da değerlidir.

Özellikle;

anormal compute artışı,

traffic cost,

API usage,

serverless invocation

siber güvenlik anomalisi olabilir.

### Cloud DDoS Detection Nasıl Yapılır?

Birden fazla telemetry kaynağı kullanılabilir.

Örneğin;

cloud load balancer metrics,

WAF logs,

CDN telemetry,

flow logs,

API Gateway logs,

application monitoring,

cost anomaly

birlikte değerlendirilebilir.

Bu veriler SIEM veya XDR üzerinden ilişkilendirilebilir.

### Cloud Flow Logs Nedir?

Cloud platformlarındaki flow log'lar network trafiğine ilişkin özet veriler sağlar.

Örneğin;

source IP,

destination IP,

port,

protocol,

traffic volume

analiz edilebilir.

DDoS sırasında source diversity ve trafik davranışını anlamaya yardımcı olabilir.

### Cloud SOC DDoS Saldırısında Ne İzlemeli?

SOC şu alanları izleyebilir:

#### Traffic anomaly

Normal dışı bandwidth.

#### WAF alerts

Layer 7 saldırılar.

#### API request spike

Ani API yükü.

#### Autoscaling events

Beklenmeyen instance artışı.

#### Cost anomaly

Maliyet artışı.

#### Application error

5xx oranı.

Bu sinyaller birlikte değerlendirilmelidir.

### Cloud DDoS ile Account Compromise Birlikte Olabilir mi?

Evet.

DDoS bazen güvenlik ekiplerini meşgul ederken başka saldırılar gerçekleştirilebilir.

Bu nedenle SOC yalnızca trafik saldırısına odaklanmamalıdır.

Aynı zamanda;

IAM changes,

suspicious login,

credential abuse,

data access

gibi sinyaller izlenmelidir.

### Cloud DDoS Testi Nasıl Yapılır?

Cloud ortamında DDoS testi yapmadan önce ilgili cloud provider'ın politikaları kontrol edilmelidir.

Test kapsamında;

public endpoint,

load balancer,

WAF,

API Gateway,

autoscaling,

application backend

değerlendirilebilir.

Test kontrollü şekilde kademeli artırılmalıdır.

### Cloud Provider Test Politikaları Neden Önemlidir?

Cloud sağlayıcılar belirli trafik testleri için özel kurallar uygulayabilir.

Yetkisiz veya plansız yüksek trafik platformun abuse mekanizmalarını tetikleyebilir.

Bu nedenle test öncesi;

provider policy,

scope,

traffic limit,

approval process

doğrulanmalıdır.

### Cloud DDoS Testinde Hangi Metrikler Ölçülmelidir?

Örneğin;

#### Requests Per Second

#### Load Balancer Latency

#### WAF Block Rate

#### Application CPU

#### Autoscaling Speed

#### Instance Count

#### Database Load

#### Cloud Cost Increase

#### Error Rate

#### Mitigation Time

ölçülebilir.

Cloud ortamında klasik Gbps metriklerinin yanında maliyet ve scaling metrikleri de önemlidir.

### Cloud DDoS Raporunda Neler Olmalıdır?

Profesyonel raporda şu alanlar bulunabilir:

#### Cloud Architecture Overview

Test edilen mimari.

#### Public Attack Surface

İnternete açık kaynaklar.

#### DDoS Protection Controls

WAF, CDN ve cloud-native koruma.

#### Traffic Results

Gbps/PPS/RPS sonuçları.

#### Autoscaling Behavior

Scale-up ve scale-down süreleri.

#### Cost Impact

Saldırının ekonomik etkisi.

#### Application Performance

Response time ve error rate.

#### Detection Timeline

SOC ve cloud security alarm süreleri.

#### Remediation

İyileştirme önerileri.

### Multi-Cloud DDoS Dayanıklılığı

Bazı kurumlar tek cloud provider yerine birden fazla platform kullanabilir.

Bu yaklaşım vendor dependency riskini azaltabilir.

Ancak multi-cloud;

routing,

identity,

data synchronization,

operational complexity

gibi yeni zorluklar oluşturur.

DDoS açısından multi-cloud ancak doğru tasarlandığında gerçek resilience sağlar.

### Hybrid Cloud DDoS

Birçok kurum hem on-premise hem cloud ortamı kullanır.

Bu durumda saldırı trafiği;

cloud application,

data center,

VPN,

private connectivity

arasında farklı etkiler oluşturabilir.

Hybrid mimaride Anti-DDoS stratejisi tüm trafik yollarını kapsamalıdır.

### Cloud DDoS ve Business Continuity

Cloud kullanmak yüksek availability sağlayabilir.

Ancak iş sürekliliği yine planlanmalıdır.

Örneğin;

primary region erişilemezse ne olacak?

DNS failover çalışıyor mu?

Secondary region hazır mı?

Database replication yeterli mi?

RTO karşılanıyor mu?

Bu sorular cloud DDoS resilience'ın temelidir.

### Cloud DDoS Korumasında En Büyük Hata Nedir?

En yaygın hatalardan biri:

**“Cloud'dayız, DDoS sorunumuz yok.”**

varsayımıdır.

Cloud provider network katmanında güçlü koruma sağlayabilir.

Ancak kurumun;

uygulama tasarımı,

API rate limit,

origin exposure,

autoscaling,

cost controls

zayıf olabilir.

Bu nedenle cloud DDoS güvenliği shared responsibility mantığıyla ele alınmalıdır.

### Shared Responsibility DDoS İçin Ne Anlama Gelir?

Cloud provider altyapının belirli katmanlarını koruyabilir.

Ancak uygulama ve konfigürasyon sorumluluğunun önemli bölümü müşteride olabilir.

Örneğin provider büyük volumetric saldırıyı absorbe edebilir.

Ama kurumun login endpoint'i düşük RPS'te database'i tüketiyorsa bu application design problemidir.

Bu nedenle sorumluluk paylaşımı net anlaşılmalıdır.

### Cloud DDoS Koruması Nasıl Güçlendirilir?

Kurumsal cloud mimarisinde şu kontroller değerlendirilebilir:

#### Cloud-Native DDoS Protection

Provider seviyesinde trafik koruması.

#### CDN

Edge dağıtımı.

#### WAF

Layer 7 filtreleme.

#### API Gateway

Rate limiting ve quota.

#### Origin Protection

Backend'in doğrudan erişiminin azaltılması.

#### Autoscaling

Kontrollü kapasite artışı.

#### Budget Controls

EDoS riskinin izlenmesi.

#### Multi-Region

Failover ve dağıtım.

#### SIEM/SOC Integration

Merkezi visibility.

### Cloud DDoS için Rate Limiting Nasıl Tasarlanmalı?

Sadece IP bazlı limit yerine;

user,

API key,

session,

tenant,

endpoint

bazlı limitler uygulanabilir.

Örneğin her müşterinin farklı quota'sı olabilir.

Bu yaklaşım dağıtık saldırıların etkisini azaltabilir.

### Tenant-Based Rate Limiting Nedir?

SaaS uygulamalarında bir müşterinin aşırı kullanımı diğer müşterileri etkilememelidir.

Bu nedenle **Tenant-Based Rate Limiting** uygulanabilir.

Her tenant için belirli kaynak kotası belirlenir.

Bir tenant aşırı trafik oluştursa bile diğer tenant'ların servisi korunabilir.

Bu aynı zamanda multi-tenant resilience yaklaşımıdır.

### Resource Quota Neden Önemlidir?

Cloud-native sistemlerde;

CPU,

memory,

API request,

database connection

kaynaklarına limit konulabilir.

Amaç tek bir servis veya kullanıcının tüm platform kaynaklarını tüketmesini engellemektir.

Bu yaklaşım DDoS ve abuse dayanıklılığı açısından değerlidir.

### Cloud DDoS ile Zero Trust İlişkisi

Zero Trust doğrudan DDoS çözümü değildir.

Ancak kritik yönetim servislerini public internetten kaldırmak saldırı yüzeyini azaltabilir.

Örneğin;

admin panel,

management API,

database interface

yalnızca private network veya identity-aware access üzerinden kullanılabilir.

Bu sayede saldırganın hedefleyebileceği public servis sayısı azalır.

### Cloud DDoS Resilience Score

Kurum cloud DDoS olgunluğunu farklı alanlarda puanlayabilir:

#### Network Protection

#### Application Protection

#### API Security

#### DNS Resilience

#### Autoscaling

#### Cost Protection

#### Multi-Region Readiness

#### SOC Visibility

Bu yaklaşım zaman içerisindeki gelişimi takip etmeyi kolaylaştırır.

### Sonuç: Cloud'a Geçmek DDoS Riskini Ortadan Kaldırmaz, Riskin Şeklini Değiştirir

Bulut altyapıları DDoS saldırılarına karşı önemli avantajlar sağlayabilir.

Global network kapasitesi,

Anycast,

otomatik scaling,

cloud-native protection

güçlü savunma katmanlarıdır.

Ancak bu imkanlar yanlış güven hissi oluşturmamalıdır.

Cloud ortamında saldırı;

public IP'yi,

load balancer'ı,

API Gateway'i,

authentication servisini,

Kubernetes ingress'i,

database'i,

serverless function'ı

hedefleyebilir.

Üstelik sistem tamamen çökmese bile saldırı maliyetleri ciddi şekilde artırabilir.

Bu nedenle cloud DDoS güvenliğinde sadece:

**“Servis ayakta mı?”**

sorusu sorulmamalıdır.

Şunlar da ölçülmelidir:

#### Saldırı altında response time ne oluyor?

#### Autoscaling ne kadar hızlı devreye giriyor?

#### WAF kötü trafiği ayırabiliyor mu?

#### API rate limit doğru çalışıyor mu?

#### Origin doğrudan erişilebilir mi?

#### Cloud maliyeti ne kadar artıyor?

#### SOC saldırıyı ne kadar sürede fark ediyor?

Cloud DDoS dayanıklılığı ancak network, application, identity, scaling ve cost kontrolleri birlikte değerlendirildiğinde gerçek anlamda ölçülebilir.

Ancak cloud olsun veya olmasın, birçok internet servisinin ortak bir bağımlılığı vardır:

**DNS.**

Web sunucusu çalışıyor olabilir.

API sağlıklı olabilir.

Cloud region tamamen ayakta olabilir.

Ama DNS cevap vermiyorsa kullanıcı hizmete ulaşamaz.

Bu nedenle DDoS saldırılarında DNS altyapısı ayrı bir kritik hedef olarak değerlendirilmelidir.