AWS-Kunden können IPv4 nicht hinter sich lassen

• AWS hat angekündigt, ab Februar 2024 Gebühren für öffentliche IPv4-Adressen zu erheben. Mit $0.005 pro Stunde entstehen Kosten von $4 pro Monat oder mehr als $40 pro Jahr.
• Diese Gebühr wird sich auf Dienste wie Elastic Load Balancers, EC2-Instanzen, Elastic IPs, ECS-Fargate-Tasks mit öffentlicher IP, Global Accelerator IPs, Site-to-Site-VPN-IPs und Managed NAT Gateways auswirken. Nicht betroffen sind gemeinsam genutzte IPv4-Adressen und öffentliche IPv4-Adressen, die von non-VPC-Lambda-Funktionen verwendet werden.
• Diese Ankündigung wurde von vielen begrüßt, da erwartet wurde, dass sie die Einführung von IPv6 fördern würde. Der Autor argumentiert jedoch, dass die Gebühr die IPv6-Einführung nicht wesentlich beeinflussen wird, weil vielen AWS-Diensten die IPv6-Unterstützung fehlt.
• Der Autor weist darauf hin, dass verschwenderische Muster wie mehrere Load Balancer pro VPC oder die bewusste Zuweisung öffentlicher IPv4-Adressen zu EC2-Instanzen und Fargate-Tasks, um Managed NAT Gateways zu vermeiden, von dem neuen Preismodell stark betroffen sein werden.
• Der Autor argumentiert, dass es praktisch unmöglich ist, auf AWS ausschließlich mit IPv6 zu arbeiten, weil zentrale Dienste wie API Gateway, Lambda, ECS und App Runner keine ausreichende IPv6-Unterstützung bieten. Selbst bei internem Dual-Stack-Betrieb können die meisten AWS-Dienste nur mit IPv4-Zielen verbunden werden.
• Der Autor kritisiert, dass AWS die neue Gebühr als Anreiz für die IPv6-Einführung darstellt, und argumentiert, dass es keine Möglichkeit gibt, diese Gebühren zu vermeiden, weil AWS IPv6 über Jahre weitgehend ignoriert hat.
• Der Autor kommt zu dem Schluss, dass die IPv4-Gebühr angesichts der zuletzt gestiegenen Kosten für die Beschaffung von IPv4-Adressen zwar nötig sein könnte, sie aber weder die IPv6-Einführung beschleunigen noch Innovation fördern wird und zudem eigene AWS-Konten für Einzelpersonen weniger attraktiv machen könnte.
• Dies ist der erste Teil einer Blogserie. In künftigen Beiträgen sollen Optionen rund um die IPv6-Einführung auf AWS in Bezug auf Ingress- und Intra-VPC-Traffic, Egress-Traffic sowie Probleme bei der Anwendungsprogrammierung ausführlicher behandelt werden.

[GN⁺]

Hacker-News-Kommentare

• Amazon führt ein großes Projekt durch, bei dem alle internen Systeme in regionale Versionen aufgeteilt werden, weil die internen IPv4-Adressen knapp werden
• Eine Umstellung auf IPv6 ist nicht möglich, weil es viele interne Netzwerkgeräte gibt, die IPv6 nicht unterstützen
• Da die AWS-Tools den Aufbau von Netzwerken, die 10.x-RFC1918-Netze mehrdeutig adressieren, stark empfehlen, hat AWS wenig Anreiz, funktionierendes v6 bereitzustellen
• Ein zentrales Problem bei der ausschließlichen Nutzung von IPv6 auf AWS ist, dass viel Software, die auf GitHub zugreifen will, IPv6 noch immer nicht unterstützt
• Einige AWS-Kunden äußern den Wunsch, IP vollständig hinter sich zu lassen, weil die Verwaltung dieser Netzwerksysteme so komplex ist
• Dass Dienste wie Lambda und S3 kein IPv6 unterstützen, ist ein erhebliches Problem, und AWS hätte sie dual-stack und über IPv6 erreichbar machen müssen, bevor Preisänderungen vorgenommen wurden
• Die wesentliche IPv6-Unterstützung bei AWS ist teilweise darauf zurückzuführen, dass die US-Regierung angeordnet hat, mit der Migration zu beginnen
• Dass CloudFront IPv6 für benutzerdefinierte Origins nicht unterstützt, ist ein Problem für viele, die viele separate Fargate-Container als Origins betreiben
• Der Mangel an Wettbewerb unter US-ISPs behindert die Einführung von IPv6
• Wenn man auf AWS eine reine IPv6-VPC einrichtet, kann vieles kaputtgehen, von verschiedenen AWS-Services bis hin zu Paket-Repositories
• Da es bei IPv6 kein Konzept privater Adressen gibt, muss man sich vom Managed NAT Gateway und seinen Preisen verabschieden