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. Yanı 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 tabiî. 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.
Yanı, 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. Yanı 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.
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 dürüyor?” 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
Yanı, 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. Yanı 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 tabiî 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 Öldü?
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 tabiî.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
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder