· kaynak dev.to (home feed)
AWS BYOASN, sağlayıcıların Direct Connect rotalarına Region başına ASN bağlamasına izin veriyor
3 Kasım'da belgelenen AWS'nin BYOASN özelliği, sağlayıcıların kendi public ASN'lerini her Region'a bağlamasına olanak tanıyor; böylece Direct Connect müşterileri tek bir BGP import policy ile veri yerleşimini (data residency) zorunlu kılabiliyor.
AWS, ağ sağlayıcılarının kendi public Autonomous System Number (ASN)lerini tek tek AWS Region'larına bağlamasını ve bu ASN'lerin müşterilerin Direct Connect üzerinden aldığı BGP duyurularında görünmesini sağlayan bir özelliğin uygulama kılavuzunu yayımladı. 3 Kasım 2026'da yayımlanan AWS Networking and Content Delivery blog yazısının dev.to üzerinden aktarılan anlatımına göre bu özelliğin adı BYOASN; Amazon VPC IP Address Manager (IPAM) içinde yer alıyor ve Bring Your Own IP (BYOIP) ile Direct Connect public virtual interface'leri (VIF) ile birlikte kullanılıyor.
BYOASN ne yapıyor
Sağlayıcı, kendi public ASN'lerinden birini AWS'ye kaydeder ve belirli bir Region ile ilişkilendirir. Sağlayıcı BYOIP prefix'lerini o Region'dan duyurduğunda, BGP UPDATE içindeki AS_PATH niteliği, Region'a özgü ASN'yi origin olarak taşır. Her Region farklı bir ASN taşıyabilir; bu da bir rotanın nereden kaynaklandığı sorusunu, zamanla değişen bir prefix listesi yerine, yönlendiricinin tek ve kararlı bir kuralla eşleştirebileceği bir bilgiye dönüştürür.
Hedeflediği egemenlik sorunu
dev.to üzerinden aktarılan AWS yazısı, Zürih'te bir son müşterisi olan bir SaaS sağlayıcı örneği üzerinden ilerliyor. Müşterinin iki Direct Connect lokasyonunda devresi var: Frankfurt Region (eu-central-1) ile ilişkili ZUR1 ve Zürih Region (eu-central-2) ile ilişkili ZH5. İki devre de fiziksel olarak İsviçre'de bulunuyor; ancak ZUR1'deki yönlendirici, farklı bir düzenleyici yargı alanı olan Frankfurt'ta kaynaklanan prefix duyuruları alıyor. İsviçre veri egemenliği gereksinimleri, müşterinin yalnızca Zürih'te çalışan hizmetlere yönelik trafiği kabul etmesine ve yönlendirmesine izin veriyor.
IP prefix'leri üzerinden filtreleme bunu çözmüyor. Region başına prefix eşlemeleri sağlayıcının içinde kaldığı için, sağlayıcı tarafındaki her yeniden tahsis veya genişletme, müşterinin yönlendiricilerinde koordineli bir değişiklik anlamına geliyor. BYOASN, tanımlayıcıyı hareket eden prefix'ten sabit duran ASN'ye kaydırıyor.
Hat üzerinde nasıl görünüyor
Public VIF üzerinde AWS kendi ASN'si olan 7224'ü prepend eder; böylece müşterinin gördüğü yol 7224'ü ve ardından sağlayıcının Region'a özgü ASN'sini içerir. Müşteri, onaylı origin ASN'yi kabul eden ve diğer her şeyi reddeden bir import policy yazar. AWS yazısı, yapılandırmanın biçimini Cisco IOS-XR için as-path-set olarak, ios-regex deseniyle eşleştirilen, ve Juniper Junos için aynı sayıyla biten bir as-path pattern olarak gösteriyor. ASN, prefix yeniden tahsislerinden, bölünmelerinden ve genişlemelerinden etkilenmediği için müşterinin yönlendirici yapılandırmasının sağlayıcının kapasite planlamasını takip etmesi gerekmiyor.
Ön koşullar: sağlayıcı ve müşteri arasında paylaşılmış
Kurulumun büyük kısmı sağlayıcı tarafında: prefix duyuracak her Region için operating Regions yapılandırılmış, public scope ve regional pool'lara sahip bir IPAM instance'ı (AWS Organizations içinde atanmış bir IPAM yönetici hesabı); ARIN, RIPE veya APNIC'e kayıtlı, her yerden erişilebilir (publicly routable), en az IPv4 /24 veya IPv6 /48 büyüklüğünde ve provizyon sırasında başka hiçbir yerden duyurulmayan bir BYOIP aralığı; ve bir RIR'e kayıtlı, ASN'nin RDAP kaydına BYOIP için kullanılan aynı X.509 sertifikasının yüklenmiş olduğu, ayrıca Amazon'un ASN'lerini yetkilendiren ROA'ya ek olarak o ASN için ek bir ROA içeren public 2 byte veya 4 byte bir ASN. Her regional ASN, aws ec2 provision-ipam-byoasn AWS CLI komutuyla provizyon edilir.
Geri kalan adımlar müşteriye ait: public VIF'li bir Direct Connect bağlantısı, ASN 7224 ile kurulmuş BGP peering ve AS_PATH filtrelemesi yapabilen bir yönlendirici. dev.to yazısı, göründüğü kadar basit olan bu son gereksinimin tasarımın çalışıp çalışmayacağını belirlediğini vurguluyor: import policy yazmayan bir müşteri, yönlendiricilerinin denetlemediği bir sınıra fiilen razı olmuş sayılıyor.
Plan yapılırken dikkate alınması gereken operasyonel sınırlar
Yazı birkaç kısıt listeliyor. Amazon ASN'sinden sağlayıcının kendi ASN'sine geçiş saatte bir ile sınırlıyken, geri geçiş her zaman mümkün. Halihazırda duyurulmuş bir prefix'in yeni bir ASN ile ilişkilendirilmesi için withdraw edilmesi gerekmiyor; böylece takas kesintisiz gerçekleşiyor. Yetkilendirme mesajı bir sona erme tarihi taşıyor ve süresi dolmadan yenilenmesi gerekiyor. Ayrıca geçersiz bir ROA, Amazon'un prefix'i duyurmayı durdurmasına yol açabileceği için RIR'deki ROA'lar geçerli kalmak zorunda.
Neden önemli
Bu özellik, veri yerleşimi zorunluluğunu evrak işinden yönlendirmeye taşıyor. Son müşterinin yönlendiricisi, yerleşim sınırının uygulandığı nokta hâline geliyor; uygulama katmanında hiçbir değişiklik gerekmiyor ve müşterinin kendi ekipmanındaki yönlendirme tablosu, bir denetçinin tek bir show komutuyla doğrulayabileceği kayda dönüşüyor. Sağlayıcılar, prefix'leri Region'lar arasında taşıma özgürlüğünü müşterileri değişiklik pencerelerine dahil etmeden koruyor; müşteriler ise sağlayıcının ağı geliştikçe doğru kalmaya devam eden bir filtre kazanıyor. Regüle sektörler için operasyonel ayrıntılar — saatlik takas sınırı, süresi dolan yetkilendirme ve ROA geçerliliği — ilk günden itibaren runbook'ta yer almalı.
- #aws
- #direct-connect
- #bgp
- #networking
- #data-sovereignty