AWS müşterileri IPv4'ten kurtulamıyor
(tty.neveragain.de)- AWS, 2024 Şubat'tan itibaren özel genel IPv4 adresleri için saat başına $0.005 ücret alıyor; ancak AWS hizmetlerindeki kısıtlar nedeniyle müşterilerin IPv6'ya geçerek bu maliyetten kaçınması zor
- Ücret kapsamı Elastic Load Balancer, EC2/Elastic IP, genel IP atanmış ECS Fargate görevleri, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway gibi geniş bir alana yayılıyor
- EC2, VPN, Transit Gateway, Direct Connect, Network Firewall gibi servisler IPv6 tabanında çalışsa da, API Gateway, Lambda, ECS, App Runner gibi çekirdek servisler yalnızca IPv6 alt ağları reddediyor veya bunu düzgün desteklemiyor
- İç yapıyı dual-stack kursanız bile, hizmet API endpoint'lerinin %90'dan fazlası IPv6 desteklemediği için VPC içinde genel IPv4 olmadan S3, Systems Manager, SQS gibi servisleri kullanmak zor
- Büyük müşteriler için bu ücret çoğu zaman faturanın %1'inden az olduğundan geçiş motivasyonu zayıf kalıyor; SMB'ler, hobi kullanıcıları ve girişimler ise %10-30 maliyet artışı yaşayabildiği için yük daha büyük oluyor
2024 Şubat'tan itibaren özel genel IPv4 ücretlendirmesi
- AWS, 2024 Şubat'tan itibaren her özel genel IPv4 adresi için saat başına $0.005 ücret alıyor
- Bu, ayda yaklaşık $4, yılda ise $40'ın üzerine denk geliyor
- AWS'ye ait IP'ler için geçerli; müşterinin yönlendirilebilir genel IPv4 bloğunu getirdiği BYOIP adresleri ise ücretlendirilmiyor
- Ücretlendirme, genel IPv4'ü doğrudan kullanan başlıca kaynakların tamamına yayılıyor
- Elastic Load Balancer
- Her availability zone için 1 adres kullanıyor
- En az 2 tane gerekiyor ve IPv4 kapatılamıyor
- EC2 instance'ları ve Elastic IP
- Genel IP atanmış ECS Fargate görevleri
- Global Accelerator IP'leri
- Site-to-site VPN IP'leri
- RDS
- Managed NAT Gateway
- Elastic Load Balancer
- Paylaşımlı IPv4 adresleri bunun dışında tutuluyor
- CloudFront dağıtımları veya API Gateway endpoint'lerinde kullanılan paylaşımlı adresler ücretlendirmeye dahil değil
- VPC dışındaki Lambda fonksiyonlarının kullandığı genel IPv4 adresleri de hariç
Maliyetin ciddi biçimde arttığı yapılandırmalar
- 3 availability zone'a dağıtılmış genel bir Elastic Load Balancer'ın taban fiyatı %50'den fazla artıyor
- Managed NAT Gateway'in taban fiyatı yaklaşık %10 yükseliyor
- NAT Gateway, availability zone düzeyinde yedeklilik sağlamıyor
- Giden bağlantı kritikse her availability zone için bir NAT Gateway gerekiyor
- Özellikle adresleri çok israf eden iki desen daha fazla etkileniyor
- Her VPC için birden fazla Load Balancer kullanılan yapı
- Birden çok CloudFormation şablonu veya Terraform modülünün birleştirilmesi ya da Kubernetes ingress controller'ın her servis için Load Balancer oluşturmasıyla ortaya çıkıyor
- Tek bir Load Balancer birden fazla URL'yi ve servisi işleyebilir
- Managed NAT Gateway'den kaçınmak için EC2 instance'larına ve Fargate görevlerine bilerek genel IPv4 eklenen yapı
- İronik olarak, availability zone başına genel IPv4 adresi sayısı yaklaşık 10'a ulaşana kadar bu yöntem hâlâ daha ucuz kalıyor
- Her VPC için birden fazla Load Balancer kullanılan yapı
Mevcut kullanım nasıl kontrol edilir
- Genel IPv4 adresi kullanımı hesapta zaten ölçülüyor
- Şu anda $0 olarak görünüyor, ancak 2024 Şubat'tan itibaren saat başına $0.005 ücret kesilecek
- Kontrol yolları şöyle
- Billing Dashboard > Bills
- Virtual Private Cloud bölümünde
PublicIPv4:InUseAddressolarak görünüyor
- Virtual Private Cloud bölümünde
- Cost Explorer
- Yalnızca
PublicIPv4:InUseAddressdahil olacak şekilde filtreleyip günlük ve saatlik kullanımı görebilirsiniz - Üye hesap bazında gruplama da yapılabiliyor
- Yalnızca
- VPC > VPC IP Address Manager > Public IP insights
- Genel IPv4 kullanımının özetini görebilirsiniz
- IPAM'in bu bölümü ücretsiz
- Yalnızca hesap ve bölge düzeyinde veri gösteriyor; geçici olarak kullanılmış adresleri yakalayamadığı için veriler eksik olabiliyor
- Billing Dashboard > Bills
IPv6'ya geçiş için iki yaklaşım
- IPv4 adresleri ücretli, IPv6 adresleri ücretsiz olduğu için yüzeyde IPv6'ya geçiş doğal bir tercih gibi görünüyor
- IPv6'da özel adres kavramı olmadığından Managed NAT Gateway ve onun maliyetinden kaçınılabilir
- IPv6'yı devreye almanın başlıca iki yolu var
- Dual-stack
- Tüm sistemlere hem IPv4 hem IPv6 adresi atanır
- İçeride yalnızca IPv6
- İçeride sadece IPv6 kullanılır, genel kullanıcıya bakan edge veya CDN tarafında IPv4 bağlantısı sağlanır
- Dual-stack
- ABD Başkanlık Ofisi memorandumunda, dual-stack işletiminin sürdürülmesinin gereksiz derecede karmaşık hâle geldiği ve artık gerekli olmadığı, standart kuruluşları ile büyük teknoloji şirketlerinin yalnızca IPv6 dağıtımlarına yönelmeye başladığı belirtiliyor
- AWS'nin temel IPv6 ağ desteği ise kendi başına görece iyi durumda
- Yalnızca IPv6 alt ağlarında yalnızca IPv6 EC2 instance'ları kurulabiliyor
- Yerel DNS, zaman servisi, host yapılandırması, güvenlik gibi IPv6 ağında beklenen işlevler çalışıyor
- VPN, Transit Gateway, Direct Connect ve Network Firewall da IPv6 destekliyor
IPv6, AWS servislerini kullanma aşamasında tıkanıyor
- Darboğaz, ağın kendisinden çok diğer AWS servislerine bağlanma aşamasında ortaya çıkıyor
- API Gateway, Lambda, ECS, App Runner gibi çekirdek servisler yalnızca IPv6 alt ağ yapılandırmalarını reddediyor veya hata veriyor
- Elastic Load Balancer
Not enough IP space availablegibi hatalar verebiliyor
- Elastic Load Balancer
- İç yapıyı dual-stack kurmak da yeterli olmuyor
- Birçok servis alt ağda IPv6 tanımlı olsa bile bunu yok sayıyor
- Çoğu durumda yalnızca IPv4 hedeflerine bağlanabiliyorlar
- VPC içinde genel IPv4 adresi olmadan servis API'lerini kullanmanın zor ya da imkânsız olduğu pek çok örnek var
- EC2 instance'ında
aws s3 lsçalıştırmak başarısız oluyor - Instance erişimi ve yönetimi için önerilen yöntem olan Systems Manager çalışmıyor
- ECS Task içinden SQS'e erişilemiyor
- EC2 instance'ında
- AWS IPv6 destek durumu'na göre hizmet API endpoint'lerinin %90'dan fazlası IPv6 desteklemiyor
- SES SMTP ve ECR repository endpoint'leri de çalışmıyor; CloudFront ise IPv6 origin'e bağlanamıyor
- ECR üzerinden ECS görevi başlatılamasa da, IPv6 destekleyen Docker Hub ile bu mümkün
- Docker Hub pull işlemlerine rate limit uyguluyor
PrivateLink bir alternatif ama maliyet kısıtı büyük
- Pek çok servis PrivateLink ile bağlanabiliyor
- Müşteri VPC'sine doğrudan bağlandığı için genel IP adresine ihtiyaç yok
- Ancak tüm servisleri desteklemiyor
- PrivateLink, servis başına ve availability zone başına ücretlendiriliyor
- Endpoint başına aylık yaklaşık $9
- Örneğin Secrets Manager, EC2, SSM ve SSM-Messages'ı 3 availability zone'da bağlamak, VPC başına yılda $1.200'ün üzerine çıkabiliyor
- Buna ek trafik ücretleri de ekleniyor
IPv4 ücretlendirmesinin IPv6 geçişine yol açmasının zor olmasının nedeni
- Ölçekli müşteriler için IPv4 ücretlendirmesi genelde faturanın %1'inden azı düzeyinde kaldığından büyük bir değişim gibi hissedilmiyor
- Yalnızca bu maliyetin anlamlı bir mühendislik yatırımı doğurması zor
- SMB'ler, hobi kullanıcıları ve girişimler için ücretler faturayı %10-30 artırabiliyor
- Bu grupların maliyetten kaçınmak için IPv6'ya geçme motivasyonu yüksek
- Ancak AWS servislerindeki IPv6 destek boşlukları nedeniyle IPv4 maliyetinden kaçmanın yolları sınırlı
- Son dönemdeki IPv4 edinme maliyetleri düşünüldüğünde, IPv4 adres ücretlendirmesinin kendisi gerekli olabilir
- AWS servislerinin tamamında IPv6 desteği olgunlaşmış olsaydı, daha fazla müşteri yalnızca IPv6 ortamlara geçebilirdi
- Şu anda IPv6'yı AWS içinde birinci sınıf vatandaş olarak görmek zor; bu durumda IPv4 ücretlendirmesi, kişisel hesaplar, öğrenme, sertifika hazırlığı ve açık kaynak desteği amacıyla AWS kullanımını daha az cazip hâle getiriyor
1 yorum
Hacker News görüşleri
Uzun zaman önce Amazon’da junior geliştiriciyken, tüm iç sistemleri bölge bazlı sürümlere ayıran ve bölgeler arası çağrılara yalnızca sınırlı gateway’ler üzerinden izin veren büyük bir iç proje vardı
Nedeni, dahili IPv4 adreslerinin tükenmiş olmasıydı
“Peki sadece IPv6’ya geçilemez miydi?” sorusuna, sorumlu Principal PM kabaca “Şu anda elimizdeki dahili ağ ekipmanlarının çok büyük bir kısmı IPv6’yı destekleyemiyor; değiştirmek için dünya çapındaki yıllık üretime yakın miktarda ekipman satın alıp hepsini kurmamız gerekirdi” diye yanıt vermişti
Amazon’un IPv4 tarafında kötü niyetli davrandığını düşünmek kolay, ama AWS sistemlerinin ölçeği düşünülünce, eski ağ donanımının tamamını değiştirme işinin kısa vadede fazlasıyla büyük bir proje olmuş olabileceği de gayet inandırıcı
Biraz saçmalık gibi, ya da en azından gerçeğin yaratıcı biçimde paketlenmiş hâli gibi şüphe uyandırıyor. Örneğin gerçekte hepsinde IPv6 desteği vardı ama korku, belirsizlik ve şüphe içindeki ağ mühendisleri bunu açmak istememiş olabilir
Gördüğüm çoğu ağ ekipmanı, çevremizde IPv6 fiilen kullanılmaya başlanmadan çok önce dual stack idi; ben de bunun hep ABD hükümeti ya da askeri gereksinimleri nedeniyle eklendiğini düşünürdüm
O projenin PM’inin kim olduğunu hatırlamıyorum ama o dönemde bir TPM’in yaratabileceği değere gerçekten saygı duymaya başladım
Maliyet ve ağ ekipmanlarını değiştirme zorunluluğunun IPv6’ya geçilmemesindeki güçlü nedenlerden biri olduğu doğru. Amazon çeşitli nedenlerle kendi tasarlayıp ürettiği ağ ekipmanlarını kullanıyordu; muhtemelen hâlâ da öyledir
Bu ekipmanların hepsi sabit bellek kapasitesine sahipti; IPv6 yönlendirme tabloları vb. için yeterli belleğe çıkmak istiyorsanız değiştirilmeleri gerekiyordu. Yalnızca IPv6’yı seçmiş olsalar bile mevcut ekipman yetmezdi; zaten IPv4/IPv6 dual stack olmadan süreci geçirmek de zordu
Her zaman devasa ölçekli projeler yapıyor gibi görünüyor; IPv4 artık bunların küçüklerinden biri sayılır. Şu anda yaptığı bazı büyük projeleri ne yazık ki paylaşamam
Birkaç kez vakit ayırıp bana akıllıca tavsiyeler vermişti; bunun için minnettarım
Elbette süreci çoktan başlatmışlardır
Değil mi? AWS’nin başını kuma gömüp bunu görmezden geldiğini hayal etmek zor
AWS’nin düzgün çalışan IPv6 sunması, teşvikleriyle açıkça çelişiyor gibi görünüyor. AWS’nin etki araçları, örneğin Well-Architected kriterleri ve sertifikaları, uçtan uca adreslemeye sahip internet tarzı mimariler yerine, belirsiz biçimde adreslenmiş 10.x RFC1918 ağ labirentleri oluşturmaya güçlü biçimde yönlendiriyor
AWS önerileri dünyasında “genel IP adresi” kavramının kendisi bir tehlike işareti; AWS de ek ücret alarak bu adresleri işaretleyen ve “hafifleten” araçlar öneriyor
Müşterilerin güvenlik adı altında karmaşık altyapı kurmaya emek harcamasını sağlamak güçlü bir lock-in etkisi yaratıyor. Gerçekte gereksiz karmaşıklık, adres belirsizliği vb. yüzünden güvenliği zedelese bile durum bu
“Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN” gibi kaç ürün çıktığını sayamaz hâle geldik; hepsi IPv4’ü büyük ölçekte döndürmek için
IPv6’yı düzgün çalışır hâle getirmiş olsalardı bu ürünlerin kelimenin tam anlamıyla hiçbirine gerek kalmazdı
Bunun yerine Azure, IPv6’yı da NAT’lıyor; dolayısıyla IPv4 yüzünden zorunlu kalan NAT’tan kaçınmak için IPv6’yı da kullanamıyorsunuz. 2023’te bile IPv6’yı desteklemeyen ve muhtemelen gelecekte de desteklemeyecek yeni ürünler çıkarıyor
Belgelerde hâlâ kısıtlamalar için tam bir sayfa duruyor: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Bunun IPX’ten IPv4’e geçiş olduğunu düşününce ne kadar mantıksız olduğu görülüyor. Bu sayfada “IPv4 kısıtlamaları: Tüm VM’ler en az bir IPX adresi içermelidir” gibi bir şey yazıyor demek oluyor
Tuhaf gelmiyor mu? 1999’da müşterileri IPX’ten IPv4’e taşıyorduk ve IPv6 desteği kabaca 2001–2003’te ortaya çıktı. Aradan onlarca yıl geçtiği hâlde hâlâ “henüz her şey IPv4’ü desteklemediği için IPX+IPv4 gerekiyor” diyen Novell NetWare geçişi öncesi dönem gibi hissettiriyor
Bu liste kesinlikle tüm kısıtlamaları kapsamıyor. Çoğu PaaS ürünü IPv6’yı desteklemediğinden, IaaS+PaaS çözümleri sonuçta çoğunlukla IPv4 kullanmak zorunda kalıyor
Nedenini anlamıyorum ama büyük bir teknoloji şirketi uçtan uca adreslemeyi en iyi uygulama olarak öne çıkarana kadar, tehlike işareti yaratmamak için mevcut genel kabulleri izlemek zorundayız
Müşteriler, sahip olmadıkları makineler üzerinde bile izinsiz girişleri ve veri sızıntılarını önlemek için kendilerine ait özel ağlar istiyor. Dahası, hazır özellikleriyle gelen PaaS servislerini de o ağın içine koymak istiyorlar
Benim tahminim, nedenin daha sıradan olduğu yönünde. AWS’nin servis sayısı da düşünülünce IPv4 desteği sadece daha kolay
Bir AWS müşterisi olarak IP’nin kendisinden uzaklaşmak istiyorum. IP, BGP, DNS gibi eski protokollerden oluşan karmaşık ağ sistemlerini yönetmek zaman kaybı.
İş yüklerine güçlü kimlik bağlayıp, hangi iş yükünün hangi iş yüküyle veri alışverişi yapabileceğini yalnızca politikayla uygulatmam yeterli.
Verinin bir iş yükünden diğerine nasıl gittiği benim umurumda olmamalı; sadece çalışmalı.
Sanallaştırılmış veri merkezinin, yani taklit edilmiş ağın bileşen hayvanat bahçesine saplanmak yerine her şeyi soyutluyorlar.
Gerçekte hiçbir zaman düzgün çalışmadı, bundan sonra da çalışamaz. Gerçek iş yüklerini çalıştırıp optimize etmek için dikkate alınması gereken çok fazla nüans ve ayrıntı var.
AWS’de yalnızca IPv6’ya geçerken kendi deneyimime göre en büyük sorun, GitHub’ın hâlâ IPv6 yapamaması. Çok sayıda yazılım, bir şeyler indirmek için GitHub’a bağlanabileceğini varsayıyor.
Herkese açık NAT64 servisleri kullanılabilir, ama ciddi kullanım için pek güvenilir değiller: https://nat64.xyz/
AWS, NAT gateway trafiği için çok yüksek ücret alıyor ve yalnızca IPv4-only host’lara giden trafiği yakalayacak şekilde ayarlanıp ayarlanamayacağını da bilmiyorum. Yanılıyorsam söylerseniz sevinirim.
Bunun dışında AWS’de yalnızca IPv6 kullanmak kusursuz çalışıyor ve daha ucuz. Özel ağlar için egress gateway ücretsiz. Elbette IPv4’ü umursamamak ön koşuluyla.
Bence asıl sorun Lambda ve S3’ün IPv6’yı desteklememesi; AWS önce bunları dual-stack hâle getirip IPv6 üzerinden erişilebilir kılmalı, sonra fiyat değişikliğine gitmeliydi.
Teknik olarak S3 için ayrı dual-stack endpoint’ler var, ama bu değişikliğe uyum sağlamak için zaten uygulama ayarlarını değiştirmeniz gerektiğinden pek işe yaramıyor.
AWS’nin IPv6 desteğinde önde olmasının yarısı zaten ABD hükümetinin geçişi başlatın diye getirdiği politika zorunluluğu sayesinde.
Maliyet açısından bakınca yeni ücretin büyük müşteriler için önemsiz olduğu doğru; ancak en büyük müşterilerin politika zorunluluklarının gücünü küçümsememek gerekir. Uyumluluk için kendi alternatifimizi yaparız tehdidi bile AWS’nin sonunda destek önceliğini yükseltmesini sağlayabilir.
İstemci, yani son kullanıcı tarafı iyi gidiyor gibi. Google’ın bugünlerde son kullanıcı IPv6 trafiğini neredeyse %50 olarak raporlamasına bakınca öyle.
Bana göre en kötüsü CloudFront’un özel origin’lerde IPv6 desteklememesi.
Origin olarak çok sayıda ayrı Fargate container çalıştırıyorsanız public IPv4 adresini açmanız gerekiyor ve yakında küçük container maliyeti ikiye katlanacak.
Amazon, legacy IPv4 kullanımına ek ücret koymadan önce kendi altyapısının gerçekten IPv6 destekler hâle gelmesini sağlamalı.
Amazon’un devasa bir canavar yarattığını ve sayısız servis genelinde IPv6 dağıtmanın muazzam bir iş olduğunu anlıyorum, ama CloudFront’un şu anda değil, dünden beri IPv6 origin desteklememesi için bir neden göremiyorum.
Görece o kadar da zor görünmüyor ve başka kısıtları aşmak için iyi bir araç da olabilir.
Açıkçası şimdiye kadar Amazon’un kararlarının sonunda müşterinin en iyi çıkarını gözettiğini hissediyordum; artık öyle değil. Bunu gelecek için kötü bir işaret olarak görüyorum.
ABD’de gerçek ISP rekabeti olsaydı çok faydası olurdu.
Kiracı olarak oturduğum yer Seattle yakınlarında banliyö olmasına rağmen gerçek geniş bant ISP yalnızca bir tane. Hiçbir tanıma göre kırsal değil ama tek seçenek Comcast. Fiyat ve hizmet de bu gerçeği aynen yansıtıyor.
Tesadüfen “yalnız Comcast” değil; yasal düzenlemelerle “yalnız Comcast” oldu.
Comcast’ten şikâyet etmenin ilginç yanı şu: Comcast kullanırken native IPv6’m vardı. Şu anki sağlayıcımda ise yalnızca NAT46 üzerinden IPv6 var.
Sağanak yağmurda performans düşüşü gibi dezavantajları var ama birkaç olumlu yorum da gördüm.
Çoğu kişi bugün iki IPv6 interneti olduğunun farkında değil. Bir Cogent tarafı, bir de Hurricane Electric tarafı var; ikisi benzer ölçekte ve birbirine bağlanmayı reddediyor. Bu yüzden bunu bilip iki taraftan da transit almak ya da iki taraftan da transit alan bir ağdan almak gerekiyor.
Bildiğim en az bir büyük operatör hâlâ v6’yı tünel üzerinden çalıştırıyor. Pek çok yerde v6 trafiği optimal olmayan rotalardan gidiyor; kurumsal ağlarda her veri merkezinde v4 bağlantısı bulunabilirken v6’nın tamamı “Dave’in masasının altındaki şu kutuya” gönderiliyor.
Buna rağmen Google veya Cloudflare gibi, paketlerin ulaşmasını garanti eden özel ekipleri olan yerlerde v6 benimseme oranını ölçüp kendi sırtlarını sıvazlıyorlar.
“IPv4’ten kurtulmak mümkün değil” ifadesi yerinde. Yalnızca IPv6 kullanan bir VPC oluşturabilirsiniz, ama birçok AWS hizmetinden paket depolarına kadar çok fazla şey bozuluyor: https://blog.devopstom.com/ipv6-only-ec2/
Sonunda ya IPv4’ü açmanız, ya kendi NAT64 gateway’inizi çalıştırmanız ya da birinin işlettiği NAT64’e güvenmeniz gerekiyor: https://nat64.net ve http://v4-frontend.netiter.com
“IPv6’da özel adres kavramı yok, o yüzden Managed NAT Gateway’e ve onun görkemli fiyatına elveda” sözü AWS içinde geçerli olabilir; ancak IPv6’da fc00::/7 için Unique Local IPv6 adresleri var ve NAT’ı gerçekten seviyorsanız NAT66 da var
Yine de ULA pek sık önerilmiyor; NAT66 ise… hiç olmuyor
Son duyduğuma göre Microsoft, Azure’daki IPv6’yı tamamen NAT merkezli hale getirmiş. Gerçekten tuhaf