Yükleniyor
GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü?
GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü?

Garip gelecek ama, Geçen hafta bir müşteride tam bu konuyu masaya yatırdık: “Veri Avrupa’da kalsın” deniyor ama Avrupa’nın da kendi içinde ince çizgileri var. İşin aslı şu ki, bulut tarafında en çok kafa karıştıran şeylerden biri teknoloji değil; sınırların kendisi (ki bu çoğu kişinin gözünden kaçıyor). GitHub’ın 1 Mayıs 2026 itibarıyla EU data residency kapsamını EFTA ülkelerini de içine alacak şekilde genişletmesi de tam bu yüzden önemli.

Şöyle söyleyeyim, Ben buna ilk baktığımda, açık konuşayım, “güzel hamle ama herkesin işini aynı anda kolaylaştırmıyor” dedim. Çünkü evet, Norveç ve İsviçre’nın devreye girmesi birçok kurumsal ekip için daha esnek bir yerleşim anlamına geliyor. Ama bazı kurumlar için de “hayır, biz sadece AB üyesi ülkelerde kalacağız” çizgisi hâlâ geçerli. Yani olay siyah-beyaz değil.

Peki neden?

2019’da benzer bir veri bölgesi tartışmasını Azure tarafında yaşamıştım; Logosoft’ta bir finans müşterisinde veri egemenliği konusu açıldığında, ekip önce “AB içinde olmak yetmez mi?” diye sormuştu. Yetmiyor tabii. Regülasyon, sözleşme maddesi, iç politika ve denetim beklentisi aynı anda konuşuluyor. GitHub’ın bu güncellemesi de o büyük resmin küçük ama kilit bir parçası (ben de ilk duyduğumda şaşırmıştım)

Asıl Değişiklik Ne?

Şimdi gelelim işin net kısmına: GitHub Enterprise Cloud on ghe.com için EU data residency bölgesi, artık yalnızca AB üye devletlerindeki Azure bölgeleriyle sınırlı değil. 1 Mayıs 2026’dan sonra Norveç ve İsviçre gibi EFTA ülkelerindeki Azure altyapısı da bu kapsama giriyor.

Yani, Bu ne demek? EU bölgesine atanmış kurumsal verileriniz, artık Fransa, İsveç, Almanya ve Hollanda gibi mevcut lokasyonlara ek olarak Norveç ya da İsviçre’de de saklanabiliyor veya işlenebiliyor. Hani depo mantığıyla düşünün; ürün aynı depolama ağında kalıyor ama raf sayısı artıyor.

Şahsen, Bir de şu var: Bu değişiklik çoğu müşteri için operasyonel açıdan sessiz sedasız gelecek. Yani ekstra kurulum yapmanız gerekmiyor. GitHub burada oldukça rahat davranmış; sertifikalar, güvenlik kontrolleri ve şifreleme aynen devam ediyor. Kağıt üstünde baya iş görüyor.

💡 Bilgi: Eğer organizasyonunuzun verileri yalnızca AB üye devletleri içinde kalmak zorundaysa, 1 Mayıs 2026’dan önce GitHub account team veya GitHub Support ile konuşmanız gerekiyor.

Neden EFTA Meselesi Bu Kadar Önemli?

Şunu fark ettim: EFTA deyince çoğu kişinin aklına hemen teknik detay gelmiyor; normal. Ama veri yerleşimi tarafında bu ülkeler bayağı kilit çünkü GDPR ile uyumlu veri koruma çerçeveleriyle çalışıyorlar. EEA Agreement sayesinde hukukî zemin zaten tanıdık geliyor.

Ben AZ-305 sınavına hazırlanırken bile bu tip konulara özellikle takılmıştım: “Sadece servis nerede çalışıyor?” sorusu yetmiyor; “veri hangi hukukî çerçevede duruyor?” sorusu da lazım. Bulut mimarisinde lokasyon bazen DNS kaydı gibi görünür… ama etkisi gayet gerçek olur.

2024 yazında bir telekom müşterisinde yaptığımız tasarım görüşmesinde de bunu birebir yaşadık. Ekip önce region listesini konuştu, sonra compliance ekibi devreye girdi. Konu aniden storage’a değil governance’a döndü. İşte tam orada fark ettik: Bölge genişlemesi teknik bir haber gibi görünse de aslında satın alma sürecinden denetime kadar uzanan bir zinciri etkiliyor.

Durum Eski Yapı Yeni Yapı
Kapsam AB üye devletleri AB + Norveç + İsviçre
Müşteri Etkisi Daha dar lokasyon seçeneği Daha fazla esneklik
Aksiyon Gereksinimi Bazen manuel kontrol gerekirdi Çoğu müşteri için yok
Sınırlama AB dışı risk algısı daha düşük değildi Sadece AB üyesi şartı olanlarda dikkat şart

Peki Kurumlar İçin Pratikte Ne Değişecek?

Küçük ekiplerde durum daha rahat

Şunu söyleyeyim, Küçük startup’lar ya da orta ölçekli yazılım ekipleri için bu değişiklik genelde iyi haber. Çünkü compliance takımınız üç kişiyse — biri CTO, biri hukukçu arkadaşınız, biri de sizseniz — seçeneklerin artması nefes aldırır. Bilhassa Avrupa’daki müşterilere çalışan SaaS ürünlerinde data residency konusu satış kapısında bile soruluyor artık.

Enterprise tarafta işe oyun biraz başka

Yani, Büyük kurumlarda mesele sadece “nerede tutuluyor” sorusu değil; logların nerede işlendiği, yedeklerin nereye aktığı, support erişiminin nasıl yönetildiği. Alt yüklenici zinciri ayrı ayrı inceleniyor. Geçen ay Frankfurt’taki bir toplantıda bunu net gördüm; satın alma ekibi tek cümlede karar vermedi çünkü risk kabul matrisi masadaydı.

Kendi deneyimimden konuşuyorum, Ama dürüst olayım: Her güzel haberin ufak bir hayal kırıklığı tarafı olur ya… İşte burada da var. Eğer sizin iç politikanız “yalnızca AB member state” diyorsa, Norveç. İsviçre’nın eklenmesi sizi sevindirmez; hatta tam tersine ekstra kontrol ihtiyacı doğurur. Yani genişleme herkese otomatik avantaj değil. Bu konuyla ilgili github ile ilgili önceki yazımız da göz atmanızı tavsiye ederim. Daha fazla bilgi için Visual Studio Aboneliğinde Gizli Güç: Syncfusion’ı Kaçırmayın yazımıza bakabilirsiniz.

Kısa bir not düşeyim buraya.

GitHub burada güvenlik sertifikalarını değiştirmiyor; sınırı genişletiyor.
Ama regülasyon hassasiyeti olan kurumlarda sınırın büyümesi çoğu zaman daha iyi anlamına gelmeyebilir.
Bazı ekipler için esneklik kazançtır… bazıları için yeni bir onay türü demektir.

Aynı Anda Hem Teknik Hem Hukukî Okumak Gerekir

Mühendis gözüyle bakınca güzel duran şeyler var

Trafik dağılımının daha geniş havuza yayılması teoride operasyonu rahatlatabilir. Azure altyapısı zaten küresel ölçekte olgun olduğu için böyle geçişler kağıt üstünde pürüzsüz görünür. Ben kendi projelerimde bunu çok gördüm; doğru design varsa kullanıcı hiç hissetmeden arkada coğrafya değişir. Daha fazla bilgi için azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem yazımıza bakabilirsiniz.

Hukuk ve uyumluluk tarafı işe daha temkinli ilerler

E tabii burada esas soru şu oluyor: “Eğer şirket politikam AB dışındaki herhangi bir EEA ülkesini istemiyorsa ne olacak?” Cevap basit. Can sıkıcı olabilir—önceden plan yapacaksınız. GitHub Support veya account team ile temas kurmak boşuna önerilmiyor; son dakika telaşı genelde en pahalı yol oluyor (inanın bana)

İşte tam da bu noktada devreye giriyor.

Neyse uzatmayayım… Ben olsam bu tip değişiklikleri üç katmanda okurum: teknik etki, uyumluluk etkisi ve ticari etki. Mesela satış ekibi açısından bu güncelleme bazı sektörlerde olumlu algılanabilir çünkü Avrupa içinde veri tutma argümanı güçleniyor. Bu konuyla ilgili Kubernetes’te AI Dönemi: Microsoft’un KubeCon 2026 Hamlesi yazımıza da göz atmanızı tavsiye ederim. GitHub Copilot Verisi Değişiyor: Ne Toplanıyor, Ne Toplanmıyor? yazımızda bu konuya da değinmiştik.

# Kontrol listesi mantığıyla yaklaşın
1) Mevcut data residency sözleşmenizi okuyun
2) İç politikanızda "EU only" mi yazıyor bakın
3) DPA / vendor assessment dokümanlarını güncelleyin
4) Gerekirse GitHub destek kanalına önceden sorun açın
5) Denetim kanıtlarını arşivleyin

Bende Yarattığı İzlenim Ne Oldu?

Açık söyleyeyim, ben bu haberi ilk gördüğümde “nihayet mantıklı bir hizalama” dedim. Microsoft’un EU Data Boundary yaklaşımıyla aynı çizgiye yaklaşmak bence doğru adım; çünkü müşteriler farklı platformlarda birbirinden kopuk sınırlar görmek istemiyor.

nAma işin mutfağında hâlâ boşluklar var mı? Var tabii.nÖrneğin tüm kurumların veri egemenliği tanımı aynı değil.nBir bankanın beklediğiyle bir medya şirketinin beklediği şey arasında dağ kadar fark oluyor.nBu yüzden tek satırlık blog duyurusu bazen sahada beş toplantılık tartışmaya dönüşüyor — klasik hikâye.

Sizin Tarafınızda Şimdi Ne Yapmalı?

  • Eğer mevcutta EU data residency kullanıyorsanız politika metninizi gözden geçirin.
  • “Sadece AB üyeleri” şartınız varsa erken aksiyon alın.
  • Sözleşme ve tedarikçi değerlendirme dosyalarınızı güncelleyin.
  • Compliance ekibine teknik değişikliğin etkisini sade dille anlatın (yoksa konu gereksiz uzar).

Bir de şunu söyleyeyim: Bu tarz değişikliklerde sessiz kalmak bazen en kötü tercih oluyor.n2018’de Hollanda’daki bir hosting geçişinde bunu acıyla öğrenmiştik; kimse doküman güncellememişti ve audit sırasında gereksiz efor çıkmıştı.nO günden beri ben her küçük boundary değişikliğini bile not alırım.nİnanılmaz sıkıcı görünüyor ama audit günü geldiğinde hayat kurtarıyor.

Sıkça Sorulan Sorular

GitHub’ın yeni EU data residency kapsamı ne zaman başlıyor?n

Size bir şey söyleyeyim, Duyuruya göre değişiklik 1 Mayıs 2026 tarihinde yürürlüğe giriyor. O tarihten sonra EU-region enterprise verileri Norveç ve İsviçre dahil olmak üzere daha geniş bir Azure altyapısında tutulabiliyor veya işlenebiliyor (ben de ilk duyduğumda şaşırmıştım)

No action required ne demek? Gerçekten hiçbir şey yapmayacak mıyız?n

Çoğu müşteri için evet, ekstra işlem gerekmiyor.nAma iç politikanız yalnızca AB üye devletlerini şart koşuyorsa istisna sizde olabilir.nYani resmî duyuru sakın görünüyor diye bayağı kenara çekilmek iyi fikir değil.

Norveç ve İsviçre GDPR açısından uygun mu?n

Evet, EFTA ülkeleri EEA Agreement üzerinden GDPR-benzeri koruma çerçeveleriyle çalışıyor.nBu yüzden birçok kurumsal senaryoda uyumluluk açısından kabul edilebilir görülüyor.nYine de nihai karar şirketinizin hukuk. Compliance politikalarına bağlıdır.

Sadece AB üyesi ülkelerde kalmak isteyen kurumlar ne yapmalı?n

Böyle kurumların Mayıs 2026’dan önce GitHub account team veya GitHub Support ile iletişime geçmesi gerekiyor.nBurada amaç sürpriz yaşamamak.nMesela finans, kamu ve regüle sektörlerde ön onay süreci kritik oluyor.

Kaynaklar ve İleri Okuma

GitHub Changelog – EU data residency region expanding to include EFTA countries

GitHub Docs – About storage of your data with data residency

GitHub Docs – Network details for GHE.com

Microsoft Learn – Microsoft EU Data Boundary

İçeriği paylaş:

📬 Bu yazıyı faydalı buldunuz mu?

Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!

Yorum gönder

Microsoft Azure Çözüm Uzmanı | Bulut Bilişim, Yapay Zekâ, DevOps ve Kurumsal Güvenlik alanlarında 15+ yıl deneyim. Azure, Kubernetes, AI/ML ve modern altyapı mimarileri üzerine yazılar yazıyorum.

SİZİN İÇİN DERLEDİK