AWS EBS: Kılavuzlar, Fiyatlandırma, Maliyet Optimizasyonu

Bulut mimarileri ölçeklendikçe, depolama en çok hafife alınan maliyet ve performans unsurlarından biri haline gelir. AWS ortamlarında, Amazon Elastic Block Store (EBS) bu katmanda temel bir rol oynar.

İş çıkarma yeteneğini, gecikmeyi ve fiyatlandırmayı neyin etkilediğini daha iyi anlamak için EBS'nin arka planda nasıl çalıştığını ve maliyetlerinin nasıl optimize edileceğini ayrıntılı olarak inceleyeceğiz.

Önemli Çıkarımlar

>  AWS EBS, kalıcı ve yüksek performanslı blok depolama sağlar – ancak bunun etkinliği büyük ölçüde doğru birim seçimine ve yapılandırmasına bağlıdır;

>  Verimsizliklerin çoğu 3 temel alandan kaynaklanır: 1 – aşırı ayrılmış birimler, 2 – gereksiz yüksek performanslı katmanlar, 3- yaşam döngüsü yönetiminin olmaması;

>  Kurumlar, AWS kredileri güvence altına alarak, depolama kullanımını optimize ederken altyapı maliyetlerini dengeleyebilir ve böylece bütçelerini inovasyon ve ölçeklendirmeye yeniden tahsis edebilirler.

AWS EBS Nedir?

AWS EBS, Amazon EC2 örnekleri. ile kullanılmak üzere tasarlanmış, kalıcı bir blok depolama hizmetidir. Tamamen yönetilen ve bulut tabanlı olurken, geleneksel bir disk gibi davranan güvenilir, yüksek performanslı depolama sağlar.

Bunu yaparken, depolama yönetimi için ezber bozan birkaç fayda sunar:

• Düşük gecikmeli erişim işlemsel ve performansa duyarlı iş yükleri için;
• İçinde yüksek kullanılabilirlik Kullanılabilirlik Bölgesi, donanım arızalarına karşı koruma sağlamak için yerleşik yedeklilik ile;
• Esnek performans yapılandırmaları, iş yükü ihtiyaçlarına bağlı olarak genel amaçlı ve ayrılmış IOPS birimleri arasında seçim yapmanıza olanak tanır.

Geleneksel Depolama ile AWS EBS Modeli Karşılaştırması
Geleneksel Depolama	AWS EBS Modeli
Yerel disk depolama	Ağa bağlı blok depolama
Fiziksel donanıma bağlı	İşlem (compute) yaşam döngüsünden bağımsız
Manuel ölçeklendirme	Esnek birim yeniden boyutlandırma
Sınırlı yedeklilik	AZ (Erişilebilirlik Alanı) içinde yerleşik replikasyon
Donanıma bağımlı	Tamamen AWS tarafından yönetilir

Temel AWS EBS Mimari Unsurları

“Yalnızca bir disk” olmasının basitliğinin arkasında, performansı, kullanılabilirliği ve maliyeti doğrudan etkileyen bir dizi mimari unsur yatar. Bu nedenle, Amazon Elastic Block Store (EBS) hizmetini etkili bir şekilde kullanmak için onun temel bileşenlerini anlamak faydalı olacaktır:

• Birimler (depolama birimleri). Bunlar, birincil veri katmanını oluşturan ve EC2 örneklerine bağlanan kalıcı blok depolamalardır.
• Anlık Görüntüler (yedekler). S3'te depolanan artımlı yedekler – kurtarma, kopyalama, bölgeler arası replikasyon vb. imkanlar sağlar.
• IOPS ve iş çıkarma yeteneği yapılandırması. Bu ayarlar performans özelliklerini tanımlar ve gecikmeye duyarlı uygulamaları veya yüksek iş çıkarma yeteneğine sahip iş yüklerini desteklemek üzere ayarlanabilir.
• Birim türleri (performans katmanları) – gp3 (dengeli) veya io1/io2 (yüksek performans) gibi seçenekler, iş yükü ihtiyaçlarıyla uyum sağlamaya olanak tanır.
• Bağlantı modeli. Genellikle tek bir örneğe bağlama, belirli kümelenmiş iş yükleri için Çoklu Bağlantı (Multi-Attach) seçeneği mevcuttur.
• Esnek değişiklik yapabilme yeteneği. Birim boyutu ve performansı dinamik olarak, genellikle kesinti süresi olmadan ayarlanabilir, böylece depolamayı yeniden oluşturma veya taşıma ihtiyacı ortadan kalkar. 

AWS EBS'nin Temel Yetenekleri

Gözlemlerimize göre, AWS EBS; performansı, operasyonel ve maliyet verimliliğini doğrudan etkileyen birkaç öne çıkan yetenek sunar. Hadi inceleyelim.

AWS EBS Birim Türleri 

AWS EBS, her biri belirli iş yükü modelleri için tasarlanmış birden fazla disk bölümü (volume) türü sunar. 

Aynı zamanda, temel yetenekleri (kalıcılık, performans ince ayarı, anlık görüntüler ve ölçeklendirme) tüm türler için geçerlidir, ancak disk bölümlerinin nasıl yapılandırıldığına bağlı olarak farklı davranır. Bu nedenle, en büyük etki uyumdan – özellikle doğru disk bölümü türünü ve yapılandırmasını gerçek iş yükü modelleriyle eşleştirmekten – gelir. Bunu nasıl başaracağınıza dair temel hususları içeren aşağıdaki tabloya göz atın.

AWS EBS Disk Bölümü Türlerine Genel Bakış
Disk Bölümü Türü	İçin En İyisi	Performans Özellikleri	Önemli Hususlar
Genel Amaçlı SSD (gp3 / gp2)	Çoğu iş yükü (web uygulamaları, veri tabanları)	Dengeli IOPS, veri aktarım hızı (throughput) ve gecikme süresi	Varsayılan seçimdir ancak genellikle gereğinden fazla kaynak ayrılır (overprovisioned)
Garantili IOPS SSD (io1 / io2)	Gecikmeye duyarlı uygulamalar (veri tabanları, kritik sistemler vb.)	Yüksek, tutarlı IOPS, düşük gecikme süresi	Daha yüksek maliyet, hassas ince ayar gerektirir
Veri Aktarım Hızı Optimize Edilmiş HDD (st1)	Büyük sıralı iş yükleri (günlükler, analitik vb.)	Yüksek veri aktarım hızı, daha düşük IOPS	Rastgele erişim için uygun değildir
Soğuk HDD (sc1)	Seyrek erişim, arşiv verileri	Düşük maliyet, düşük performans	Minimum erişim modelleri için tasarlanmıştır

Kalıcı Depolama

Birincisi, kalıcı depolama AWS EBS'nin en değerli yönlerinden biridir. Disk bölümleri EC2 örneklerinden (instance) bağımsız olarak var olduğundan, bir örnek durdurulsa veya sonlandırılsa bile verileriniz bozulmadan kalır.

Bu durum, iş yüklerinizi verimli bir şekilde çalıştırmanız ve ölçeklendirmeniz için size çok daha fazla esneklik ve kontrol sağlar, özellikle de:

• Depolamayı bilgi işlem (compute) yaşam döngüsüne bağlamazsınız (bu da ölçeklendirme ve mimari kararlarını basitleştirir);
• Örnekleri değiştirmek veya taşımak, veriler disk bölümü düzeyinde korunduğu için düşük riskli hale gelir;
• Yeniden başlatmalar, arızalar veya güncellemeler veri kullanılabilirliğini kesintiye uğratmaz.

Deneyimlerimize göre bu durum; çalışma süresi (uptime), kurtarılabilirlik ve operasyonel sürekliliğin önemli olduğu durumlarda özellikle faydalıdır.

Performans Özelleştirme

Bir diğer harika avantaj ise AWS EBS'nin yüksek derecede kontrol sunmasıdır. EBS'nin sunduğu hassas kontrol sayesinde performansta ince ayar yapabilirsiniz:

• IOPS (saniye başına girdi/çıktı işlemleri);
• Veri aktarım hızı (throughput - veri aktarım hızı);
• Disk bölümü boyutu (performans sınırlarını doğrudan belirler).

Bu esneklik, ister düşük gecikmeli işlemsel sistemler ister yüksek veri aktarım hızlı veri işleme için optimize ediyor olun, depolamayı iş yükü davranışıyla tam olarak eşleştirmenize olanak tanır.

Ancak şunları göz önünde bulundurun:

• Özellikle erken aşama kurulumlarında IOPS veya veri aktarım hızının aşırı yapılandırılması yaygındır (çünkü ekipler genellikle kullanılmayan kapasite için ödeme yapar);
• Yetersiz kaynak tahsisi (underprovisioning) genellikle daha sonra, iş yükleri ölçeklendiğinde ve performans sorunları gecikme artışları, kuyruk birikmesi veya düşük kullanıcı deneyimi olarak ortaya çıktığında kendini gösterir.

Anlık Görüntü (Snapshot) ve Yedekleme Entegrasyonu

EBS, dayanıklı artımlı yedeklemeler sağlayan anlık görüntüler (snapshots) aracılığıyla Amazon S3 ile yerel olarak entegre olur.

İşlevsel olarak bu, aşağıdaki avantajları sağlar:

• Güçlü veri koruması ve geri alma senaryoları için belirli bir ana geri dönme kurtarması (point-in-time recovery);
• Test, hazırlık (staging) veya ölçeklendirme ortamları için hızlı disk bölümü klonlama;
• Olağanüstü durum kurtarma ve iş sürekliliği için bölgeler arası anlık görüntü replikasyonu.

En önemlisi, anlık görüntüler artımlıdır ve bu nedenle yalnızca değişiklikler depolanır. İlk anlık görüntüyü oluşturduğunuzda, EBS disk bölümündeki tüm veri bloklarını S3'e kopyalar (tam bir temel çizgi). Sonraki her anlık görüntü için yalnızca bir önceki anlık görüntüden bu yana değişen bloklar kaydedilir. Bu, uzun vadede hem depolama tüketimini hem de maliyeti zaman içinde optimize eder.

Esnek Ölçeklendirme

AWS EBS disk bölümleri çoğu durumda kesinti süresi olmadan yeniden boyutlandırılabilir veya performansları ayarlanabilir. Bu, ekiplerin talepteki artışlara hızlı tepki vermesini, yeni iş yüklerini sisteme dahil etmesini ve performans sorunlarını verimli bir şekilde stabilize etmesini sağlar.

Ancak, verimliliği korumak için sürekli izleme gereklidir (örneğin, IOPS kullanımı, kuyruk derinliği, verim kullanımı). Aşağıdakileri aklınızda bulundurun:

• Ölçeklendirme genellikle tek yönlüdür – birimler büyüme veya olaylar sırasında artırılır, ancak nadiren geri ölçeklendirilir;
• Performans parametreleri (IOPS, verim) genellikle reaktif olarak ayarlanır (daha sonra yeniden değerlendirme yapılmadan);
• Zamanla, birimler gerçek iş yükü ihtiyaçlarından uzaklaşabilir ve aşırı kaynak tahsisine (overprovisioning) neden olabilir.

AWS Ekosistemi ile Entegrasyon

Diğer bir önemli güç ise daha geniş AWS ekosistemi ile ne kadar sorunsuz entegre olduğudur. Aşağıda entegrasyonların listesini ve bunların hep birlikte sunduğu etkiyi görebilirsiniz.

AWS EBS Entegrasyonlarına Genel Bakış
Hizmet	Rol	Saklama süresi yapılandırması
Amazon EC2	Bilgi işlem katmanı	Örneklere (instance) kalıcı blok depolama ekleme
AWS CloudWatch	İzleme	IOPS, verim, gecikme süresini izleme; uyarıları ayarlama
AWS Backup	Yedekleme yönetimi	Merkezi yedekleme politikaları ve otomasyon
Amazon S3	Anlık görüntü (snapshot) depolama	Anlık görüntüler (snapshot) ve kurtarma için dayanıklı depolama
AWS IAM	Erişim kontrolü	Birimler ve anlık görüntüler için ayrıntılı yetkilendirme izinleri
AWS KMS	Şifreleme	Birimler ve anlık görüntüler için bekleme durumunda şifreleme (encryption at rest)
AWS CloudTrail	Denetim ve günlük kaydı	API etkinliğini ve EBS kaynaklarına erişimi izleme
Amazon Data Lifecycle Manager (DLM)	Yaşam döngüsü otomasyonu	Anlık görüntü oluşturma ve saklama süreçlerini otomatikleştirme
AWS Sistem Yöneticisi	Operasyonlar	EBS birimlerini kullanan örnekleri yönetme, yama işlemlerini otomatikleştirme
Amazon FSx / EFS	Depolama ekosistemi	Paylaşılan dosya iş yükleri için tamamlayıcı depolama
AWS Lambda	Otomasyon	EBS olaylarına dayalı iş akışlarını tetikleme

AWS EBS İçin En Popüler Kullanım Durumları

Amazon Elastic Block Store (EBS), AWS iş yüklerinde yaygın olarak kullanılır, ancak etkinliği kullanım durumuna ne kadar iyi uyduğuna bağlıdır. Aşağıda en fazla değer sağladığı senaryolar yer almaktadır.

AWS EBS Otopilot: Uygunluk Genel Bakışı
Uygunluk	Kullanım Senaryosu	Neden Çalışır (veya Çalışmaz)
Son derece uygun	İlişkisel veritabanları (OLTP)	– Düşük gecikmeli SSD seçenekleri (gp3, io2)  – Sağlanan (provisioned) IOPS ile tutarlı performans  – Bir Kullanılabilirlik Alanı (AZ) içinde güçlü dayanıklılık
Son derece uygun	Durumsal uygulamalar (örneğin, arka uç servisleri)	– Bilgi işlemden bağımsız kalıcı depolama – EC2 örneklerine kolay ekleme – Ölçeklendirme ve yük devretme (failover) senaryolarını destekler
Son derece uygun	Lift-and-shift iş yükleri	– Tanıdık blok depolama modeli (geleneksel diskler gibi) – Geçiş sırasında minimum değişiklik gereksinimi – Amazon EC2 ile sorunsuz entegrasyon
Son derece uygun	Geliştirme ve test ortamları	– Anlık görüntüler aracılığıyla hızlı kaynak sağlama ve klonlama – Esnek yeniden boyutlandırma ve yapılandırma – Hızlı yinelemeyi destekler
Orta düzeyde uygunluk	Veri işleme (ardışık iş yükleri)	– Verim odaklı optimize edilmiş birimlerle (st1) çalışır – Ardışık erişim modelleri için maliyet etkindir – Rastgele erişimde performans düşer
Orta düzeyde uygunluk	Yedekleme ve arşivleme (anlık görüntüler aracılığıyla)	– AWS S3'te depolanan artımlı anlık görüntüler – Kurtarma ve olağanüstü durum kurtarma (DR) için iyidir – Maliyetleri kontrol etmek için yaşam döngüsü yönetimi gerektirir
Sınırlı uygunluk	Yüksek düzeyde dağıtık sistemler	– Tek AZ kapsamı, bölgeler arası dayanıklılığı sınırlar – Dağıtık depolama modelleri için tasarlanmamıştır
Sınırlı uygunluk	Son derece değişken / dalgalı iş yükleri	– Önceden yapılandırılmış performans gerektirir – Aşırı kaynak tahsisine ve maliyet verimsizliğine yol açabilir – Sunucusuz depolama seçeneklerine göre daha az esnektir

✅ Durum #1: Uygulama ve Veritabanı Depolama

Bu, Amazon Elastic Block Store (EBS) için en yaygın ve kritik kullanım durumlarından biridir. Uygulama arka uçları ve veritabanları (örneğin, OLTP sistemleri), küçük gecikmelerin bile kullanıcı deneyimini ve sistem performansını etkileyebileceği durumlarda, verilere tutarlı ve düşük gecikmeli erişim gerektirir.

Bu kurulumlarda EBS; işlemsel veritabanlarından (PostgreSQL, MySQL) durum bilgisi olan (stateful) arka uç hizmetlerine kadar her şeyi destekleyerek birincil veri katmanı görevi görür. Nesne depolamanın aksine, hızlı ve öngörülebilir G/Ç'ye dayanan veritabanı motorları için temel olan blok düzeyinde erişim sağlar.

Uygulama ve Veritabanı Depolama için AWS EBS: Değerlendirme Özetleri
Birincil değer	Düşük gecikmeli blok depolama
Performans etkenleri	IOPS, verim
Operasyonel etki	İşlemsel iş yüklerini destekler
Kritik bağımlılıklar	Birim boyutlandırma, performans ayarı

Üretim ortamlarında gördüklerimize göre, EBS veritabanı iş yükleri için tutarlı performans gösteriyor – ancak yalnızca performans gerçek kullanımla uyumlu olduğunda. 

Testlerimizden öne çıkan bazı bulgular:

>  gp3 birimleri, doğru şekilde yapılandırıldığında çoğu OLTP iş yükünü verimli bir şekilde yönetti;

>  Aşırı kaynak tahsis edilmiş IOPS iş yükleri gerçekten gecikmeye bağlı olmadığı sürece performansı nadiren artırdı;

>  Sorgu optimizasyonu depolama performansını artırmaktan daha büyük bir etkiye sahipti;

>  Gereksiz ölçeklendirmeyi önlemek için, gecikme süresini ve kuyruk derinliğini izlemek verimliliği artırır.

✅ Durum #2: EC2 için Önyükleme (Boot) Birimleri

Her Amazon EC2 örneği işletim sistemini, sistem dosyalarını ve temel yapılandırmaları depolamak için bir önyükleme (boot) birimine güvenir. AWS'de Amazon EBS tam olarak bunu üstlenir. 

Geçici örnek depolamasının aksine, EBS destekli önyükleme birimleri kalıcıdır – yani örnek durdurulsa veya yeniden başlatılsa bile işletim sistemi ve veriler bozulmadan kalır. Bu, sistem durumunu korumak, güncellemeleri uygulamak ve yeniden başlatmalar arasında tutarlı ortamlar sağlamak için kritik öneme sahiptir.

EC2 için AWS EBS ve Önyükleme Birimleri: Değerlendirme Özetleri
Birincil değer	Kalıcı işletim sistemi depolaması
Performans etkenleri	Birim türü seçimi
Operasyonel etki	Örnek güvenilirliğini sağlar
Kritik bağımlılıklar	Anlık görüntü (snapshot) stratejisi

Gözlemlerimize göre, önyükleme birimleri genellikle kararlı ve öngörülebilirdir – ancak maliyet ve yaşam döngüsü perspektifinden genellikle göz ardı edilirler. Uygulamada, verimsizlikler genellikle aşırı büyük birimler ve yönetilmeyen anlık görüntüler nedeniyle birikir.

Testlerimizden öne çıkanlar şunları gösterdi:

• gp3 yeterli performans sağlar ince ayar gerektirmeden çoğu önyükleme birimi için;
• Büyük boyutlu kök birimleri genellikle yaygındır ve nadiren tamamen kullanılır;
• Anlık görüntü (snapshot) birikimi, saklama politikaları olmadığında gizli bir maliyet artırıcı unsur haline gelir;
• AMI'lerin ve birim boyutlarının standartlaştırılması, operasyonel karmaşıklığı ve maliyeti azaltır.

✅ Örnek Durum #3: Veri İşleme İş Yükleri

Bu örnek durumda, EBS'nin veri işleme iş yüklerini nasıl desteklediğini inceledik. Bu bağlamda, Amazon Elastic Block Store (EBS); ara veriler, hazırlama alanları ve işleme çıktıları (ETL boru hatları, günlük işleme, toplu analiz işleri vb.) için yüksek verimli bir depolama katmanı olarak kullanılır. Buradaki amaç, yoğun okuma/yazma işlemleri sırasında tutarlı bir veri aktarım performansı sağlamaktır.

Bu senaryoda şunları gözlemledik:

>  st1, sıralı iş yükleri için SSD'ye kıyasla daha düşük maliyetle güçlü performans sunar;

>  Yüksek veri hızlı iş yükleri için gp3 kullanılması genellikle gereksiz harcamalara yol açar;

>  İş yükleri sıralı erişimden rastgele erişime geçtiğinde performans önemli ölçüde düşer;

>  Veri boru hatlarındaki temel darboğaz genellikle IOPS değil, veri hızı (throughput) limitleridir.

Veri İşleme İş Yükleri için AWS EBS: Değerlendirme Özeti
Birincil değer	Yüksek veri hızlı depolama
Performans etkenleri	Sıralı okuma/yazma performansı
Operasyonel etki	Toplu işlemeyi (batch processing) destekler
Kritik bağımlılıklar	Birim tipi uyumluluğu

Sınırlandırmalar ve EBS'nin Optimal Olmayabileceği Durumlar

❌ Birden fazla örnek arasında paylaşılan depolama

EBS birimleri öncelikli olarak tek bir EC2 örneğine bağlanacak şekilde tasarlanmıştır; bu da onları birden fazla örnekten eşzamanlı erişim gerektiren senaryolar için uygunsuz hale getirir. Sınırlı Çoklu Bağlantı (Multi-Attach) seçenekleri mevcut olsa da bunlar ek karmaşıklık getirir ve gerçek bir paylaşımlı dosya sistemi davranışı sağlamaz. Bu durum, veri tutarlılığı sorunlarına ve operasyonel yükün artmasına neden olabilir. 

Bu tür kullanım durumları için, çoklu örnek erişimini yerel olarak destekleyecek şekilde tasarlanmış Amazon EFS gibi yönetilen ağ dosya sistemleri veya Amazon FSx gibi yüksek performanslı dosya sistemleri daha uygundur.

❌ Nesne depolama iş yükleri

EBS, blok depolama için tasarlanmıştır ve dosyalar, medya veya büyük veri kümeleri gibi yapılandırılmamış verilerin API'ler aracılığıyla depolanması veya bunlara erişilmesi için optimize edilmemiştir. Bu iş yükleri için EBS kullanmak, nesne depolama çözümlerine kıyasla daha yüksek maliyetlere ve sınırlı ölçeklenebilirliğe yol açabilir. 

Buna karşılık Amazon S3; nesne tabanlı iş yükleri için neredeyse sınırsız ölçeklenebilirlik, yüksek dayanıklılık ve verimli erişim modelleri sunarken, uzun vadeli depolama için S3 Glacier gibi ek arşivleme seçenekleriyle daha uygun bir model sağlar.

❌ Sık erişilmeyen veya arşivlik veriler

EBS, verilere ne sıklıkta erişildiğine bakılmaksızın sağlanan depolama alanı için ücret alır; bu da düşük erişim sıklığına sahip iş yükleri için verimsiz olmasına neden olur. Soğuk veriler için yerleşik bir katmanlandırma olmadığından, orantılı bir değer elde edilmeden maliyetler zamanla birikebilir. 

Bu senaryolar için, sık erişilmeyen veya arşivlik verilerin maliyetlerini azaltmak üzere özel olarak tasarlanmış Amazon S3 Infrequent Access veya S3 Glacier gibi depolama sınıfları daha uygundur.

❌ Yüksek düzeyde dağıtık sistemler

EBS birimleri tek bir Erişilebilirlik Alanı (Availability Zone) ile sınırlandırılmıştır; bu da verilerin bölgeler veya birden fazla alan arasında erişilmesini gerektiren dağıtık mimariler için uygunluklarını kısıtlar. Bu tür sistemleri EBS ile uygulamak genellikle ek çoğaltma (replikasyon) mekanizmaları gerektirir, bu da karmaşıklığı ve maliyeti artırır. 

Bu nedenle, dağıtık iş yükleri için yüksek kullanılabilirlik ve küresel erişilebilirlik amacıyla tasarlanmış Amazon S3 veya DynamoDB gibi dağıtık veritabanları daha uygun bir temel oluşturur.

AWS EBS Nasıl Çalışır: Temel Hususlar

Pratikte AWS EBS, geleneksel bir disk gibi çalışır ancak bulut esnekliği ve performans kontrolleri avantajlarına sahiptir. Adım adım nasıl çalıştığını inceleyelim.

Adım 1: Depolama gereksinimlerinin belirlenmesi

Ekipler, bir birim oluşturmadan önce boyutu, performans ihtiyaçlarını (IOPS/veri hızı) ve iş yükü özelliklerini (örneğin, işlemsel ve yüksek veri hızlı yük karşılaştırması) tanımlar. 

Not: Bu aşamada doğru birim tipinin (örneğin gp3 ve io2 karşılaştırması) seçilmesi kritik öneme sahiptir (en yüksek yüke karşı ortalama yükü, büyüme projeksiyonlarını ve gecikme süresi hassasiyetini göz önünde bulundurun).

Adım 2: Birimlerin oluşturulması ve yapılandırılması

Birimler; performansı ve maliyeti doğrudan belirleyen belirli parametrelerle (boyut, tip, IOPS, veri hızı vb.) sağlanır.

En önemlisi, sağlanan her ek performans biriminin doğrudan bir maliyet etkisi olduğunu göz önünde bulundurun (“güvenlik” amacıyla aşırı kaynak sağlama yaygındır, ancak verimliliği sağlayan şey gerçek kullanım modelleriyle uyumlu olmaktır).

Adım 3: Birimlerin EC2 örneklerine bağlanması

Birim bir EC2 örneğine bağlanır ve bir blok cihazı olarak sunulur. Bu aşamada, geleneksel bir disk gibi biçimlendirilebilir ve bağlanabilir (mount).

Bu aşamada, birimlerin Erişilebilirlik Alanına (AZ) bağlı olduğunu unutmayın; bu nedenle uyumsuzluklar kullanılabilirliği etkiler. Ayrıca, bağlantı sınırlarını ve mimarinizin Çoklu Bağlantı mı yoksa paylaşımlı depolama modelleri mi gerektirdiğini hesaba katın.

Adım 4: Veri okuma ve yazma

Uygulamalar, birimle yerel depolama alanıymış gibi etkileşime girerek standart okuma/yazma işlemlerini gerçekleştirir. Performans, hem birim yapılandırmasına hem de uygulama davranışına bağlıdır.

Adım 5: Veri dayanıklılığının sağlanması

Veriler, donanım arızalarına karşı koruma sağlamak ve depolama katmanında yüksek kullanılabilirlik sunmak için aynı Erişilebilirlik Alanı içinde otomatik olarak çoğaltılır (ancak bunun AZ düzeyindeki bir arızaya karşı koruma sağlamadığını unutmayın; üretim düzeyindeki kurulumlar genellikle bölgeler arası veya alanlar arası çoğaltma stratejileri gerektirir).

Adım 6: Yedekleme ve kurtarma için anlık görüntülerin (snapshot) oluşturulması

Anlık görüntüler artımlı (incremental) olarak alınır ve Amazon S3'te depolanır; bu da belirli bir zamana geri dönerek kurtarmayı, ortamların kopyalanmasını ve felaket kurtarma stratejilerini mümkün kılar.

Bu noktada, verilerin ne sıklıkla değiştiğini anlamak önemlidir (örneğin, yüksek değişim oranına sahip iş yükleri daha fazla anlık görüntü verisi üretir; bu nedenle, yaşam döngüsü politikaları olmadığında maliyetler zamanla fark edilmeden artabilir).

Adım 7: Depolama ve performansın ölçeklendirilmesi

İş yükleri geliştikçe, birimler yeniden boyutlandırılabilir veya IOPS ve aktarım hızı ayarlanabilir (genellikle kesinti süresi olmadan).

Verimli bir şekilde ölçeklendirmek için, tüm yapılandırmaları düzenli olarak gözden geçirdiğinizden ve bunları gerçek kullanım kalıplarıyla uyumlu hale getirdiğinizden emin olun.

Adım 8: Kullanımı izleme ve optimize etme

Ekipler, darboğazları veya aşırı kaynak tahsisini belirlemek ve yapılandırmaları buna göre ayarlamak için IOPS, aktarım hızı, gecikme süresi ve kullanım metriklerini izler.

AWS EBS: İzlenmesi Gereken Temel Metrikler
Metrik	Ne gösteriyor	Nelere dikkat etmeli
IOPS (okuma/yazma)	Saniye başına I/O işlem sayısı	Sürekli sınırlara yakın → yetersiz kaynak tahsisi; sürekli düşük → aşırı kaynak tahsisi
Aktarım Hızı (MB/s)	Veri aktarım hızı	Doygunluk → darboğazlar; düşük kullanım → israf edilen kapasite
Gecikme Süresi (Latency)	I/O işlemi başına süre	Anlık yükselmeler veya sürekli yüksek gecikme süresi → performans sorunları
Kuyruk derinliği	Bekleyen I/O isteklerinin sayısı	Yüksek kuyruk derinliği → yetersiz IOPS veya verimsiz I/O kalıpları
Burst dengesi (gp2/gp3 için)	Kullanılabilir burst kredileri	Tükenme → ani performans düşüşleri
Birim kullanımı (%)	Fiili ve tahsis edilen kullanım karşılaştırması	Düşük kullanım → aşırı kaynak tahsisi; yüksek → ölçeklendirme gerekiyor
Okuma/yazma oranı	İş yükü deseni	Dengesizlik, ince ayar veya farklı birim türü gerektirebilir
Snapshot boyutunun büyümesi	Zaman içindeki veri değişim oranı	Hızlı büyüme → artan depolama maliyetleri

Blok Depolamanın Gizli Karmaşıklığı

İlk bakışta AWS EBS basit görünür; bir birim bağlarsınız ve kullanırsınız. Ancak gerçekte, performans ince ayarı, maliyet görünürlüğü ve yaşam döngüsü yönetimi gibi konularda süregelen bir karmaşıklık getirir.

Deneyimlerimize dayanarak, genellikle gözden kaçırılan yönler şunlardır:

• Depolama pasif değildir: uygulama performansını ve maliyetini doğrudan etkiler;
• Verimsizlikler genellikle uyumsuz performans ayarlarından ve kullanılmayan birimlerden veya snapshot'lardan kaynaklanır;
• İş yükleri geliştikçe yapılandırmalar nadiren yeniden gözden geçirilir (bu da sapmaya ve aşırı harcamaya yol açar);
• Maliyetler gerçek kullanıma değil, tahsis edilen kapasiteye dayanır (bu da hatalı yapılandırmaları pahalı hale getirir).

Bundan çıkardığımız temel sonuç: EBS altyapıyı basitleştirir, ancak optimizasyonu değil. Verimli bir şekilde kullanmak için maliyet etkenlerini anlamak önemlidir. Aşağıya bakın.

AWS EBS Fiyatlandırmasına Genel Bakış

Tüketime dayalı modellerin aksine, AWS EBS fiyatlandırması ayrılan kapasiteye ve performans ayarlarına bağlıdır. Özellikle, EBS fiyatlandırması şunlardan etkilenir:

• Birim türü (farklı türlerin (örn. gp3, io2) belirgin fiyatlandırma modelleri ve performans özellikleri vardır;
• Tahsis edilen depolama (GB/ay) – fiili kullanımdan bağımsız olarak ayrılan kapasite için ödeme yaparsınız;
• Tahsis edilen IOPS (io1/io2) – yüksek performanslı birimler, yapılandırılan IOPS için ayrı olarak ücretlendirilir;
• Aktarım Hızı (gp3) – temel değerin üzerindeki ek aktarım hızı ayrıca faturalandırılır
• Anlık görüntü (snapshot) depolama – Amazon S3'te depolanan artımlı yedeklemeler, zaman içinde depolanan verilere göre ücretlendirilir.

AWS EBS Fiyatlandırma Dağılımı
Fiyatlandırma Bileşeni	Davranış	Birincil Maliyet Etkisi	Tipik Fiyatlandırma
Depolama kapasitesi (GB)	Tahsis edilen GB/ay başına faturalandırılır	Aşırı ayrılmış depolama boyutu	GB/ay başına $0.08–$0.10 (gp3)
Birim türü	Fiyatlandırma katmanını belirler (gp3, io2, vb.)	Gerekenden daha yüksek katmanlı depolama kullanılması	gp3 (temel) ve io2 karşılaştırması (premium, önemli ölçüde daha yüksek)
Tahsis edilmiş IOPS	Yapılandırılan IOPS başına faturalandırılır (io1/io2)	Fazla performans tahsisi	IOPS/ay başına $0.005–$0.065
Aktarım Hızı (gp3)	Tahsis edilen MB/s başına faturalandırılır	Kullanılmayan anlık görüntülerin (snapshot) birikmesi	MB/s/ay başına $0.04–$0.06
Birim yaşam döngüsü	Birimler mevcut olduğu sürece ücretlendirilir (kullanılmasa bile)	Bağlantısı kesilmiş veya boşta duran birimler	GB/ay başına $0.05

Pratik bir örneği inceleyelim. Aşağıdaki senaryo, Amazon Elastic Block Store (EBS) üzerinde çalışan tipik bir orta ölçekli üretim iş yükünü yansıtmaktadır; örneğin veritabanına sahip bir arka uç servisi, orta düzeyde trafik, devam eden yedeklemeler vb.

Orta Ölçekli Bir Dağıtım İçin Tahmini AWS EBS Aylık Maliyetleri
Bileşen	Kullanım	Aylık Maliyet
Depolama (gp3)	1 TB tahsis edilmiş depolama	$80–100
Tahsis edilmiş IOPS	6.000 IOPS (varsa temel değerin üzerinde)	$30–60
Aktarım Hızı (gp3)	250 MB/s yapılandırılmış	$10–20
Anlık görüntü (snapshot) depolama	Amazon S3'te 500 GB artımlı yedekleme	$20–30
Boşta / bağlantısı kesilmiş birimler	200–500 GB kullanılmayan birim	$15–50
İzleme ve veri aktarımı	Temel metrikler + küçük dahili trafik	$5–15
Toplam (optimize edilmiş kurulum)		$160–275/ay

Potansiyel maliyetleri daha iyi anlamak için gerçek hayattan bir senaryoyu inceleyelim. Aşağıdaki örnek, maliyetlerin öncelikle CPU ve bellek kullanımıyla yönlendirildiği, depolama, ağ iletişimi ve gözlemlenebilirliğin daha küçük katkılar sağladığı tipik bir orta ölçekli otomatik ölçeklendirilen iş yükünü yansıtmaktadır. Genel olarak, verimli ölçeklendirmenin harcamaları gerçek taleple uyumlu tutmaya yardımcı olduğu öngörülebilir bir maliyet aralığı göstermektedir; daha fazla ayrıntıyı tabloda görebilirsiniz.

Orta Ölçekli Bir Dağıtım İçin Tahmini AWS EBS Aylık Maliyetleri
Bileşen	Kullanım	Aylık Maliyet
CPU talepleri	Ortalama 2 vCPU (otomatik ölçeklendirilmiş, 730 saat)	$60–70
Bellek talepleri	Ortalama 8 GB (otomatik ölçeklendirilmiş, 730 saat)	$25–35
Geçici depolama (ephemeral)	50 GB geçici kullanım	$2–3
Pod çalışma zamanı ek yükü	Kaynak fiyatlandırmasına dahildir
Ağ çıkışı (egress)	100 GB giden trafik	$10–12
İzleme ve günlük kaydı (logging)	Standart günlük ve metrik hacmi	$10–20
Toplam (HA - Yüksek Erişilebilirlik ile)		$110–140/ay

AWS EBS Maliyetlerini Ne Tetikler? 

Gözlemlerimize göre, AWS EBS'deki verimsizlikler genellikle depolama ve performansın nasıl tahsis edildiği ve sürdürüldüğünden kaynaklanır. Aşağıda, EBS ile yaptığımız çalışmalarda belirlediğimiz temel maliyet faktörlerini bulabilirsiniz.

Faktör #1. Aşırı büyük depolama tahsisi

Hacimler en yüksek kapasiteye göre tahsis edildiğinde ancak düşük kapasitede kullanıldığında, gerçek kullanımdan bağımsız olarak sürekli maliyet oluştururlar.

Faktör #2. Kullanılmayan veya ayrılmış hacimler

Artık örneklere bağlı olmayan ancak silinmeyen hacimler ücretlendirilmeye devam eder ve büyük ortamlarda genellikle gözden kaçar.

Faktör #3. Aşırı yapılandırılmış performans (IOPS ve aktarım hızı)

Gerekenden daha yüksek IOPS veya aktarım hızı tahsis etmek, ölçülebilir performans iyileştirmeleri sağlamadan maliyeti artırır.

Faktör #4. Kontrolsüz anlık görüntü (snapshot) artışı

Eski veya gereksiz anlık görüntülerin birikmesi, kademeli maliyet artışlarına yol açar (özellikle tanımlanmış saklama politikaları olmadığında).

Faktör #5. Yanlış hacim türü seçimi

Buna ihtiyaç duymayan iş yükleri için yüksek performanslı SSD hacimlerinin kullanılması, önlenebilir aşırı harcamalara yol açar.

AWS EBS: Yetenekler ve Maliyet Riskleri
Yetenek	Maliyet Riski ve Etkisi	Optimizasyon
Hacim boyutlandırma (depolama kapasitesi)	Aşırı tahsis edilmiş hacimler, gerçek kullanımdan bağımsız olarak sürekli maliyete yol açar	→ Hacimleri doğru boyutlandırın → Kullanılmayan kapasiteyi gözden geçirin → Boyutu küçültün
Performans yapılandırması (IOPS / aktarım hızı)	Aşırı IOPS veya aktarım hızı, gerçek bir performans faydası sağlamadan maliyeti artırır	→ İş yüküyle uyumlu hale getirin → Kullanımı izleyin → Aşırı tahsisattan kaçının
Hacim yaşam döngüsü yönetimi	Bağlantısı kesilmiş veya kullanılmayan hacimler hala tam olarak ücretlendirilir	→ Kullanılmayan hacimleri silin → Temizliği otomatikleştirin
Anlık görüntü (snapshot) depolama	Biriken anlık görüntüler zamanla depolama maliyetlerini artırır	→ Yaşam döngüsü politikaları uygulayın → Eski anlık görüntüleri kaldırın → Sıklığı optimize edin
Birim türü seçimi	Yüksek performanslı türlerin (io1/io2) gereksiz yere kullanılması maliyeti artırır	→ Türü iş yüküyle eşleştirin → Mümkünse gp3 kullanın
Esnek ölçeklendirme	Aşağı doğru ölçeklendirme yapmadan yukarı doğru ölçeklendirme yapmak, uzun vadeli aşırı tahsisata yol açar	→ Zirve dönemlerinden sonra aşağı doğru ölçeklendirin
İzleme ve görünürlük	İzleme eksikliği, gizli verimsizliklere ve maliyet sapmalarına yol açar	→ Temel metrikleri takip edin → Uyarılar ayarlayın → FinOps uygulamalarını kullanın
Veri değişim oranı (anlık görüntüler)	Yüksek yazma aktivitesi, artımlı anlık görüntü depolama maliyetlerini artırır	→ Yedekleme sıklığını ayarlayın → Veri kullanımını optimize edin

AWS EBS Maliyetlerini Optimize Etme: En İyi Uygulamalar

Optimizasyon açısından bakıldığında, Amazon Elastic Block Store sürekli ince ayar gerektirir. Neyse ki bu, hem hızlı kazanımlar hem de daha uzun vadeli, daha yüksek çaba gerektiren optimizasyon uygulamalarıyla elde edilebilir.

Google Cloud SQL için Hemen Etki Gösterecek İyileştirme Alanları
Strateji	Çaba	Tasarruf	Darbe Hızı
Fazla depolamayı azaltın	Düşük	Yüksek	Hemen
Kullanılmayan hacimleri silin	Düşük	Yüksek	Hemen
IOPS/verim oranını doğru boyutlandırın	Düşük	Orta	Kısa vadeli
Anlık görüntüleri temizleyin	Düşük	Orta	Kısa vadeli
Disk türü seçimini optimize edin	Düşük	Yüksek	Hemen

AWS EBS maliyet optimizasyonunda hızlı kazanımlar elde etmek için şu önerileri izleyin: 

• Depolama kapasitesini ayarlayın gerçek kullanıma göre – ayrılan fazla alanı düzenli olarak gözden geçirin ve azaltın;
• Performans ayarlarını uyumlu hale getirin gerçek taleple – IOPS ve verim oranını gözlemlenen iş yükü davranışına göre yapılandırın;
• Kullanılmayan diskleri kaldırın – aktif olmayan veya bağlı olmayan depolama alanlarını belirleyin ve silin;
• Kontrol anlık görüntü yaşam döngüsü – saklama politikalarını uygulayın ve güncel olmayan yedekleri temizleyin;
• Uygun olanı seçin disk katmanları – varsayılan olarak premium seçenekleri kullanmak yerine depolama türünü iş yükü gereksinimleriyle eşleştirin;

AWS EBS için Uzun Vadeli Maliyet Optimizasyonu Stratejileri
Strateji	Çaba	Tasarruf	Darbe Hızı
Sürekli depolama doğru boyutlandırmasını uygulayın	Orta	Yüksek	Devam ediyor
Anlık görüntü yaşam döngüsü politikaları oluşturun	Düşük	Orta	Devam ediyor
Kullanılmayan disklerin tespitini otomatikleştirin	Orta	Yüksek	Kısa vadeli
Disk türü seçimini standartlaştırın	Orta	Yüksek	Orta vadeli
IOPS ve verim oranı referans değerlerini optimize edin	Orta	Orta	Orta vadeli
Maliyet izleme ve uyarı sistemlerini devreye alın	Düşük	Yüksek	Hemen
Depolamayı iş yükü yaşam döngüsüyle uyumlu hale getirin	Orta	Yüksek	Orta vadeli
Depolama yapılandırmalarını düzenli olarak denetleyin	Düşük	Yüksek	Devam ediyor

Bu sırada, uzun vadeli verimliliği korumak için şu en iyi uygulamaları öneriyoruz:

- Sürekli olarak depolamayı doğru boyutlandırın – uzun vadeli aşırı tahsisi önlemek için kullanım trendlerini düzenli olarak gözden geçirin ve disk boyutlarını ayarlayın;

- Anlık görüntü yaşam döngüsünü yönetin proaktif olarak – saklama politikalarını tanımlayın, temizliği otomatikleştirin, kontrolsüz anlık görüntü büyümesini önleyin;

- Depolama kararlarını standartlaştırın – gereksiz yükseltmeleri önlemek için ne zaman gp3 veya io2 kullanılacağına dair net kılavuzlar tanımlayın;

- Maliyet görünürlüğü ve uyarılar tanımlayın – depolama harcama eğilimlerini izleyin, sıra dışı durumlar veya beklenmeyen büyümeler için uyarılar ayarlayın;

- Düzenli denetimler gerçekleştirin – verimsizlikleri ve optimizasyon fırsatlarını belirlemek için ortamlar genelindeki yapılandırmaları gözden geçirin.

AWS Kredileri EBS Maliyetlerini Nasıl Kolaylaştırabilir?

Yapılandırmayı optimize etmek önemli olsa da, Amazon EBS'te maliyetleri düşürmenin bir diğer etkili yolu da AWS kredilerini kullanmaktır – özellikle de aşağıdaki gibi iş ortakları aracılığıyla erişildiğinde: Spendbase.

Resmi bir AWS ortağı olarak Spendbase, işletmelerin ücretsiz AWS kredileri almasına yardımcı olur ve doğru programların belirlenmesinden başvuruya, etkinleştirmeye ve bunların EBS ile genel bulut harcamaları üzerindeki etkisini en üst düzeye çıkarmaya kadar tüm süreci uçtan uca yönetir.

Özellikle EBS'i şu alanlarda etkileyebilir:

• Depolama maliyetleri (GB/ay) – kredilerle karşılanarak temel harcamaları azaltır;
• Ayrılmış IOPS ve verim oranı – yüksek performanslı yapılandırmalar, ölçeklendirme aşamalarında daha uygun maliyetli hale gelir;
• Anlık Görüntüler (Amazon S3'te depolanır) – yedekleme ile ilgili maliyetler kısmen veya tamamen dengelenebilir;
• Geçici aşırı tahsis – siz optimize edip doğru boyutlandırırken krediler maliyeti yumuşatır.

Ayrıca, AWS kredilerine ek olarak (startuplar için $100,000'ye kadar), Spendbase, bulut maliyeti denetimleri dahil olmak üzere daha kapsamlı FinOps ve maliyet optimizasyonu desteği sağlar –, SaaS maliyet optimizasyonu (ortalama 39% oranında), satıcı müzakereleri, harcamaları kontrol etmek için kurumsal kartlar ve daha fazlası.