1 puan yazan GN⁺ 2025-06-22 | 1 yorum | WhatsApp'ta paylaş
  • ABD bulut hizmetlerinde ortaya çıkan veri egemenliği ve GDPR uyumluluğu sorunları, Avrupa bulutuna geçiş ihtiyacını doğurdu
  • AWS’nin kolaylık ve entegre hizmetlerinden tamamen vazgeçerken bile, Hetzner gibi Avrupa barındırma sağlayıcılarına geçerek anında maliyet tasarrufu ve veri netliği elde edildi
  • Altyapı operasyonlarında verimlilik için Ansible tabanlı otomasyon ve kendi kendini yöneten bir izleme sistemi kuruldu
  • Her şeyin doğrudan inşa edilmesiyle güvenlik tasarımında daha sıkı bir yaklaşım ve şeffaf denetimi kolaylaştıran bir yapı elde edildi
  • %90 maliyet düşüşü ve ABD gözetim riskinin azalması gibi iş açısından stratejik avantajlar da sağlandı

AWS’den Avrupa bulutuna (Hetzner) geçiş süreci ve ISO 27001’i koruma stratejisi

Bir Avrupalı CTO’nun ikilemi: AWS dışına çıkınca uyumluluk sorunu

  • Birçok teknoloji liderinin yaşadığı temel sorun, ABD merkezli bulut sağlayıcılarının sınırlamalarından kaynaklanıyor
  • AWS’nin sunduğu güçlü ISO 27001 sertifikalı hizmetlerden memnun olunsa da, ABD CLOUD Act ve FISA nedeniyle Avrupa’daki müşteri verilerinin ABD yargı yetkisine maruz kalması kaçınılmazdı
  • Sunucuların fiziksel konumundan bağımsız olarak GDPR taahhütlerini yerine getirmenin zorlaştığı bir durum ortaya çıktı
  • Yıllık 24.000 dolar seviyesine ulaşan bulut faturalarının gerçek ihtiyaçlara kıyasla aşırı yüksek olduğu fark edildi
  • Şirketin geleceğini tek bir ABD merkezli sağlayıcıya bağımlı kılmanın stratejik olarak riskli olduğu anlaşıldı

Datapult’un gerçek vaka örneği

  • Datapult, çalışan vardiya planlama, fazla mesai ödemesi ayarlamaları ve devamlılık verisi yönetimi yapan, Danimarka merkezli bir iş gücü yönetimi yazılım şirketi; bu alanlarda finans seviyesi güvenilirlik gerekiyor
  • Şirket, hukuki gerekliliklerini AWS tabanlı iş akışına göre şekillendirmişti; ancak on-premise ya da bağımsız alternatif hizmetlere geçiş ek hukuki değerlendirme gerektiriyordu

AWS’den çıkarken duyulan kaygılar ve gerçek kayıplar

  • AWS’nin entegre kullanım kolaylığından vazgeçmek psikolojik olarak ciddi bir giriş bariyeri yaratıyor
  • Lambda, tek tıkla RDS ve çeşitli yerleşik uyumluluk araçları gibi kolaylık ve otomasyonlar kaybediliyor
  • Yönetilen hizmetlerden çıkış, daha fazla doğrudan kontrol ve daha fazla sorumluluk anlamına geliyor

Avrupa bulutunun beklenen etkisi ve somut kazanımları

  • Avrupalı hizmet sağlayıcılarına (Hetzner, OVHcloud) geçiş, veri egemenliği, GDPR ve ISO 27001 açısından anında fayda sağladı
    • Gerçek veri yerleşimini kanıtlayabilme sayesinde müşterilerle daha şeffaf iletişim ve denetimlere daha iyi yanıt
    • Beklenmedik düzeyde maliyet düşüşü (%90) ve bütçe şeffaflığı elde edildi
    • AWS’nin rahatlığından vazgeçilse de, teknik olarak daha güçlü otomasyon süreçleri (Ansible yapılandırması) ve daha iyi güvenlik deneyimi kazanıldı
  • Öncekine kıyasla daha fazla özerklik, inovasyon ve doğrulanabilir altyapı sağlandı

Somut geçiş stratejisi ve başlıca dersler

  • Ansible ile uyumluluk otomasyonu
    • Tüm sunucu yapılandırmalarını ISO 27001 Ek A kontrollerine doğrudan bağlayan, kendi kendini dokümante eden altyapı yönetimi hayata geçirildi
  • AWS’ye alternatif izleme sisteminin kurulması
    • Prometheus, Grafana, Loki kombinasyonuyla AWS CloudWatch seviyesinde kurumsal izleme ve hızlı olay müdahalesi mümkün oldu
  • Güvenlik by design yaklaşımıyla güvenlik tasarımının güçlendirilmesi
    • Yönetilen güvenlik araçlarının yokluğunda, Ansible otomasyonu sayesinde ISMS (Bilgi Güvenliği Yönetim Sistemi) güçlendirildi ve geliştiricilerin uyumluluk gerekliliklerine uyması kolaylaştırıldı

Teknolojinin ötesindeki stratejik etkiler

  • ABD gözetim yasalarından kaynaklanan uyumluluk riskleri en aza indirildi
  • Avrupa barındırma altyapısı, satışta farklılaştırıcı unsur olarak kullanılarak güven ve marka değeri artırıldı
  • Azalan bulut maliyetlerinin (%90) işin özüne yeniden yatırım için kullanılabileceği bir yapı kuruldu

Geçiş stratejisini uygulamak için önerilen rehber

  • Mevcut AWS altyapısından egemenlik odaklı Avrupa bulutuna geçiş ve ISO 27001’i koruma deneyimine dayanarak tekrarlanabilir yönergeler sunulabiliyor
  • CTO’lar ve kurucular AWS’den Avrupa bulutuna geçişi değerlendirirken maliyet analizi, uyumluluk riski ve geçiş takvimi gibi başlıklarda özelleştirilmiş danışmanlık alabiliyor
    • Bir saat içinde maliyet farkı, başlıca hukuki riskler ve geçişin ilk adımları netleştirilebiliyor

1 yorum

 
GN⁺ 2025-06-22
Hacker News yorumu
  • AWS’in temel özelliklerini kendimiz yeniden uygulayarak maliyeti düşürdük, ancak birçok kişi DIY tarzı barındırmanın gerçek maliyetini, özellikle de 7/24 destek gibi kısımları gözden kaçırıyor. Böyle bir desteği kendi bünyende kurmaya çalışırsan aslında epey pahalıya mal olabilir. Yıllık 24.000 $’lık AWS faturası, çok iyi bir DevOps freelancer’ının 1-2 aylık ücreti ya da düşük maaşlı bir geliştiricinin 1/3 FTE’si seviyesinde; bu bütçeyle 7/24 müdahale desteği beklemek zor. Elbette bu tercih mantıklı olabilir, ama gerçekten harcanan geliştirme zamanı ya da yönetim maliyeti gibi tüm detayların dürüstçe paylaşılmaması üzücü. Ben de benzer bir tercihi değerlendiriyorum ama maliyet düşürmekten çok Almanya’daki müşteriler gibi iş gereksinimleri nedeniyle. Yine de iş daha karmaşık hale gelecek ve ekibe yeni insanlar katmak gerekecek. CTO olarak zamanım sınırlı; böyle işlere doğrudan girmek zaman kullanımı açısından en kötü seçenek. Bence şirketin ve ürünün gelişimine daha çok odaklanmak gerek. Kişisel olarak bu kadar küçük ölçekte Terraform’un fazla ağır kaçtığını, Ansible’ın ise daha uygun bir YAGNI (You Ain’t Gonna Need It) örneği olduğunu düşünüyorum.

    • İnsanlar AWS, Azure, GCP gibi büyük bulut sağlayıcılarının gerçekten 7/24 uygulama desteği verdiğini sanıyor, ama gerçekte durum böyle değil. Sadece altyapı “çoğunlukla” çalışıyor; onu düzgün kullanabilmek için yine de maliyet patlamalarını ya da entegrasyon sorunlarını takip edecek uzmanlara ihtiyaç var. Bulut faturasının TCO (toplam sahip olma maliyeti) olduğu söylemi tamamen yanlış bir efsane.

    • AWS özelliklerini %100 kopyalarsan maliyet yüksek olabilir ama sadece %80’i gerekiyorsa durum değişir. Ayrıca AWS’i kurmak ve bu konuda beceriyi sürekli güncel tutmak için gereken emeği de küçümsememek gerekir. Örneğin AWS dashboard yerine grafana gibi daha iyi araçlar kullanılabilir. Sonuçta her şey ihtiyaçların ölçeğine ve çeşitliliğine bağlı. En pahalı çekiç her zaman doğru cevap değildir.

    • Sadece tasarruf rakamına bakarsak, başlangıçtaki 24.000 doların %90’ı olan 21.600 doları yılda kurtarmış oluyorsun. Ama bu bütçeyle Avrupa şartlarında bir SRE/DevOps mühendisi işe alamazsın. Hatta zaman geçtikçe tüm altyapıyı kendin yönetmek zorunda kalacağın için uzun vadede toplam sahip olma maliyetinin daha da artacağını düşünüyorum. Yine de bu girişimi destekliyorum.

    • Eğer ABD hükümetinin Amazon’dan zorla hesap kapatma talep etmesi riskini hesaba katıyorsan, AWS kullanmak riskli olabilir. Son dönemde ABD ile Avrupa (Grönland) arasında savaş söylemlerinin dolaştığı bir ortamda bunu daha da olası görüyorum.

    • Yıllık 24.000 $ üzerinden yapılan bu basit hesap bana fazla safça geliyor. AWS üzerinde bu servisleri kurmak için kaç kişiye ihtiyaç olduğu, aslında 48 bin-100 bin dolarlık bir maliyeti 24 bin dolara indirmek için ne kadar insan gücü gerektiği gibi somut personel maliyetleri hesaba katılmamış gibi duruyor.

  • Sadece Prometheus, Grafana ve Loki kombinasyonuyla bile AWS’te sahip olunan izleme seviyesini birebir yeniden kurmanın, hatta aşmanın mümkün olduğunu düşünüyorum. Bu araçlar bu kadar iyiyken AWS’in izleme servislerinin pahalı, yavaş ve UX açısından hayal kırıklığı yaratıcı olması bana hep şaşırtıcı geliyor. Hatta izleme maliyeti, AWS deneyiminde en hızlı ve en can sıkıcı kötüleşen noktaydı.

    • Live Tail gibi gerçek zamanlı log izleme gibi basit bir özelliğin bile ücretli olmasına gülüyorum. Her gün log bakan biri için temel bir özelliğin ücretsiz olmaması CloudWatch’un (CW) ne kadar kullanışsız olduğunu gösteriyor.
  • Hetzner’in başlıca dezavantajları, kötü niyetli kullanıcılar yüzünden IP’lerin kirlenmesi ve donanım arızası/yükseltme ihtiyacı. Bunlar hiç endişe yaratmadı mı merak ediyorum. Ayrıca Loki’nin bellek kullanımının kontrolden çıkması sorununu nasıl çözdüklerini, başka bir alternatif olup olmadığını da merak ediyorum.

    • IP kirlenmesi sorununu, kullanıcı erişimini Cloudflare üzerinden proxy’leyerek ve güvenlik duvarını (ufw) yalnızca Cloudflare IP’lerinden gelen izinli kaynakları kabul edecek şekilde ayarlayarak çözüyoruz; böylece dışarıdan doğrudan erişimi tamamen kapatıyoruz. Donanım arızası/yükseltme tarafında ise Terraform kurulumu sayesinde kısa sürede değiştirme ve kapasite artırımı yapabiliyoruz. Donanımı Prometheus ve node exporter ile izliyoruz, önceden uyarı alıyoruz ve 9 aydır hiç arıza yaşamadık. Uygulamada neredeyse hiç veri yok, veritabanında ise sık sık geri yükleme testi yapıyoruz. Loki’nin bellek sorununu da saklama politikaları ve indeks ayrımı, sorgu eşzamanlılığı ve bellek sınırı ayarları, promtail tarzı etiketleme ve yapısal loglama, eski kayıtlar için object storage yedeği ya da grep kullanımı gibi yöntemleri birleştirerek çözüyoruz.

    • Bizim yaşadığımız Loki sorunlarının nedeni, varsayılan helm gibi dağıtım ayarlarının yeterince optimize edilmemiş olmasıydı. Blogda bahsedilen performans ipuçları doğrultusunda indeksi sıfırlayıp salt okunur instance’lar ekledikten ve diğer tavsiyeleri uyguladıktan sonra ciddi performans artışı gördük. Bence açık kaynak kullanımını kolaylaştırmaktan çok kendi bulut servislerine yönlendirme niyeti var; o yüzden başlangıçta biraz uğraştırıyor.

    • Loki’ye alternatif olarak Victoria’yı öneririm. Çok daha hızlı ve itibarı da iyi, ama biz projedeki bakım sorumlularının çeşitliliğini dikkate alarak Loki’yi seçtik. Yukarıda bahsedilen yöntemlerle de dezavantajlarını telafi ettik.

    • https://en.wikipedia.org/wiki/Sybil_attack bağlantısını paylaşıyorum. Pahalı bulut sağlayıcılarının, PoW (iş ispatı) benzeri bir şekilde IP itibarı oluşturma avantajı var.

  • ISO 27001, Avrupa’da popüler olan uluslararası bir güvenlik yönetimi standardı. ABD’de neredeyse hiç uygulanmıyor ve birçok Avrupalı şirket bu farkı pek kabullenemiyor. ABD’de güvenlik standartları için temel çerçeve SOC 2; ISO 27001’e göre daha az katı ve ABD pazarına daha tanıdık geliyor.

    • ISO 27001 aslında o kadar katı ya da sert bir standart değil; genel olarak yazılım kullanırken yapılması gereken temel şeyleri talep ediyor. Zor olan kısım, bunları belgelerle kanıtlamak. SOC 2’de ise buna kıyasla dokümantasyon yükü belirgin biçimde daha az.

    • Hem SOC 2 hem ISO 27001 deneyimi olan biri olarak, SOC 2 denetimlerinin pratik kontrollerden çok denetçinin yetkinliği ve sezgisine bağlı kalmasından hoşlanmıyorum. ISO 27001 bana çok daha net ve adil bir denetim gibi geliyor.

    • ISO 27001 sertifikası olmayan tek bir büyük Amerikan bulut sağlayıcısı söyleyebilir misin?

  • Ben de Azure’da benzer bir kurulum yapıp %90 tasarruf ettim. Büyük şirketlerin, kasten karmaşık servis soyutlamaları dayatarak kolay operasyonu giderek zorlaştırdığını düşünüyorum.

    • Azure’daki maliyet düşüşü örneğini biraz daha ayrıntılı anlatır mısın?
  • AWS’e para ödemenin nedenlerinden biri operasyon yükünü azaltması ve gerçekten de AWS’in yönetilen veritabanlarını kullandığımdan beri eskiden olduğu gibi mysql cluster yükseltmeleri yüzünden stres olmuyorum. Elbette sadece bu yönü yüksek maliyeti haklı çıkarmaz ama önemli bir değer sunduğunu düşünüyorum.

    • Bu noktaya katılıyorum. Gerçek anlamda ISO 27001 uyumluluğu istiyorsan, yükseltme süreçlerini de içselleştirmen gerekir ki geliştirme/dağıtım kontrolünü etkin biçimde yapabilesin. Örneğin AWS RDS, Postgres ve MySQL için major/minor yükseltmeleri otomatik yapmıyor; yalnızca patch’ler otomatik, geri kalanı sana kalıyor. Buradaki mesele bulut ile Avrupa sunucularını üstünlük açısından karşılaştırmak değil, karmaşık ve sertifikalı bir ortamı kendin nasıl işleteceğin. Müşteri veya regülasyon nedeniyle altyapı üzerinde özerklik gerekiyorsa yükseltmeleri de kendin yapıp ISO 27001 almak mantıklı; böyle bir gereklilik yoksa AWS RDS gibi bulut bağımlılığı da gayet kabul edilebilir.
  • Rakamlar bana mantıklı gelmiyor. Yıllık 24.000 dolardan %90 tasarruf edince aylık 200 dolar kalıyor; bu da neredeyse tek bir Hetzner sunucusunun fiyatı. Böyle bir durumda dağıtık sistem yerine tek sunucu yeterli olur gibi, gerçek istek/saniye ya da kullanıcı sayısı nedir merak ettim.

    • ISO 27001 uyumluluğu için tek sunucuyla çalışamazsın; loglama ve izleme için ayrı sunucular da gerekir. Yükten bağımsız olarak belli bir karmaşıklık kaçınılmaz. Çalışanlar her gün giriş yapmıyor, uygulama bir planlama uygulaması olduğu için haftada yalnızca 1-2 kez kontrol edenler de var. DAU 10 bin-20 bin aralığında, eşzamanlı tepe kullanıcı sayısı 1.500-2.000, ortalama eşzamanlı kullanıcı ise 50-150 civarında. Bulut maliyetinin yükselmesinin sebebi, uygulamadaki gerçek zamanlı özellikler ve karmaşık iş gücü kuralları nedeniyle veri işleme yükünün ağır olması. Örneğin vardiya ataması gibi işlemlerde bonus hesaplama kuralları da değişiyor ve takvim optimizasyonu ciddi hesaplama gerektiriyor.

    • 2.400 $ değil, 200 $.

  • Disk şifrelemeyi nasıl yaptıklarını merak ediyorum. AWS’te bu otomatik ama sıradan hosting sağlayıcılarında iyi uygulanmış örnekleri pek görmedim. Şifreleme anahtarını boot partition’da tutmanın da anlamsız olduğunu belirtmek isterim.

    • ISO27001 disk şifrelemeyi zorunlu kılmaz; önemli verilerin uygun şekilde korunmasını şart koşar. Özellikle paylaşımlı donanım ortamlarında disk şifreleme en yaygın yöntemdir. Hetzner’in veri merkezleri ISO27001 sertifikalı ve disk imhasında veri silme süreçleri mevcut, bu da sertifikasyon gerekliliklerini karşılamaya yetebilir.
  • Hetzner’i gerçekten çok seviyorum, arama motorumu da orada çalıştırıyorum. Fiziksel sunucu kullanmanın en iyisi olduğunu düşünüyorum.

  • OVH ve Hetzner dışında Avrupa bulut sağlayıcıları arasında UpCloud’u da önermek isterim. UpCloud’da CPU core’larının tamamı gerçek çekirdek gibi görünüyor; vCPU (thread tabanlı) değil, bu da büyük avantaj. Yine de resmî referans eksikliği can sıkıcı. OVH, Hetzner ve hyperscaler’ları karşılaştırmak kolay değil; özellikle Hetzner çoğunlukla tüketici sınıfı parçalar kullandığı için fark oluşuyor. UpCloud tanıtımı

    • Neden düşük maliyetli bulutlarda gerçek IaaS seviyesinde IAM (yetki/politika/log) hiçbir zaman olmuyor diye merak ediyorum. Sadece konsol girişi var ama gerçek izinler, roller, machine identity ve audit log gibi şeyler varsayılan olarak gelmiyor. Oysa OpenStack bunları zaten sağlıyor; düşük maliyetli bulutların ise her şeyi yeniden yapmış gibi duruyor. Örnek olarak UpCloud’un Crossplane kılavuzunda API credential’larının konsol kullanıcı seviyesinde paylaşılması isteniyor, bu da riskli görünüyor. Terraform ile yönetmek de zor olunca sonunda upcli gibi araçlara yönelmek gerekiyor. OpenStack Service Users OpenStack Federation UpCloud Crossplane kılavuzu UpCloud subaccount yönetimi UpCloud permission ayarları