Pelanggan AWS Tidak Bisa Lepas dari IPv4

 (tty.neveragain.de)
1 poin oleh GN⁺ 2023-09-24 | 1 komentar | Bagikan ke WhatsApp
  • Mulai Februari 2024, AWS mengenakan biaya $0,005 per jam untuk alamat IPv4 publik khusus, tetapi karena keterbatasan layanan AWS, pelanggan sulit menghindari biaya dengan beralih ke IPv6
  • Cakupan penagihannya luas, termasuk Elastic Load Balancer, EC2/Elastic IP, tugas ECS Fargate yang dikonfigurasi dengan IP publik, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway, dan lainnya
  • EC2, VPN, Transit Gateway, Direct Connect, Network Firewall, dan lainnya berjalan di atas IPv6, tetapi layanan inti seperti API Gateway, Lambda, ECS, dan App Runner menolak subnet IPv6-only atau tidak mendukungnya dengan baik
  • Meski internal dikonfigurasi dual-stack, lebih dari 90% endpoint API layanan tidak mendukung IPv6, sehingga sulit menggunakan S3, Systems Manager, SQS, dan lainnya dari VPC tanpa IPv4 publik
  • Bagi pelanggan besar, biayanya sering kali kurang dari 1% tagihan sehingga insentif migrasinya lemah, sementara SMB, pengguna hobi, dan startup dapat mengalami kenaikan biaya 10–30%, sehingga bebannya lebih besar

Penagihan IPv4 publik khusus mulai Februari 2024

  • Mulai Februari 2024, AWS mengenakan biaya $0,005 per jam untuk setiap alamat IPv4 publik khusus
    • Setara hampir $4 per bulan, lebih dari $40 per tahun
    • Berlaku untuk IP milik AWS, sementara alamat BYOIP yang membawa blok IPv4 publik yang dapat dirutekan milik pelanggan tidak dikenai biaya
  • Objek penagihan mencakup hampir semua resource utama yang menggunakan IPv4 publik secara langsung
    • Elastic Load Balancer
      • Menggunakan 1 alamat per Availability Zone
      • Minimal perlu 2 alamat dan IPv4 tidak bisa dimatikan
    • Instance EC2 dan Elastic IP
    • Tugas ECS Fargate yang dikonfigurasi dengan IP publik
    • IP Global Accelerator
    • IP Site-to-site VPN
    • RDS
    • Managed NAT Gateway
  • Alamat IPv4 bersama dikecualikan
    • Alamat bersama yang dipakai untuk distribusi CloudFront atau endpoint API Gateway tidak termasuk objek penagihan
    • Alamat IPv4 publik yang digunakan fungsi Lambda di luar VPC juga dikecualikan

Konfigurasi yang biayanya naik besar

  • Elastic Load Balancer publik yang dikonfigurasi di 3 Availability Zone mengalami kenaikan harga dasar lebih dari 50%
  • Harga dasar Managed NAT Gateway naik sekitar 10%
    • NAT Gateway tidak menyediakan redundansi per Availability Zone
    • Jika koneksi outbound penting, NAT Gateway diperlukan di setiap Availability Zone
  • Dua pola yang sangat memboroskan alamat akan paling terdampak
    • Konfigurasi dengan beberapa Load Balancer per VPC
      • Ini terjadi saat menggabungkan beberapa template CloudFormation atau modul Terraform, atau saat Kubernetes ingress controller membuat Load Balancer untuk setiap layanan
      • Satu Load Balancer dapat menangani beberapa URL dan layanan
    • Konfigurasi yang sengaja memasang IPv4 publik pada instance EC2 dan tugas Fargate untuk menghindari Managed NAT Gateway
      • Ironisnya, pendekatan ini tetap lebih murah sampai jumlah alamat IPv4 publik mencapai sekitar 10 per Availability Zone

Cara memeriksa penggunaan saat ini

  • Penggunaan alamat IPv4 publik sudah diagregasi di akun
    • Saat ini ditampilkan sebagai $0, tetapi mulai Februari 2024 akan dikenakan biaya $0,005 per jam
  • Jalur pemeriksaannya sebagai berikut
    • Billing Dashboard > Bills
      • Ditampilkan sebagai PublicIPv4:InUseAddress di bagian Virtual Private Cloud
    • Cost Explorer
      • Anda dapat melihat penggunaan harian dan per jam dengan memfilter agar hanya menyertakan PublicIPv4:InUseAddress
      • Pengelompokan per akun anggota juga dimungkinkan
    • VPC > VPC IP Address Manager > Public IP insights
      • Anda dapat melihat gambaran penggunaan IPv4 publik
      • Bagian IPAM ini gratis
      • Hanya menampilkan data per akun dan Region, serta tidak menangkap alamat yang digunakan sementara, sehingga datanya tidak lengkap

Dua cara mengadopsi IPv6

  • Karena alamat IPv4 berbiaya dan alamat IPv6 gratis, sekilas migrasi ke IPv6 terlihat seperti pilihan alami
  • Di IPv6 tidak ada konsep alamat privat, sehingga Managed NAT Gateway beserta biayanya dapat dihindari
  • Secara garis besar, ada dua cara mengadopsi IPv6
    • Dual-stack
      • Mengonfigurasi alamat IPv4 dan IPv6 bersama-sama pada semua sistem
    • Internal IPv6-only
      • Bagian internal hanya menggunakan IPv6, sementara konektivitas IPv4 hanya disediakan di edge atau CDN yang berhadapan dengan pengguna umum
  • Memorandum Kantor Presiden AS menyatakan bahwa operasi dual-stack sudah menjadi terlalu kompleks dan tidak perlu untuk dipertahankan, dan bahwa badan standardisasi serta perusahaan teknologi besar mulai beralih ke deployment IPv6-only
  • Dukungan jaringan IPv6 dasar AWS sendiri relatif baik
    • Instance EC2 IPv6-only dapat dikonfigurasi di subnet IPv6-only
    • Fitur yang diharapkan dalam jaringan IPv6 seperti DNS lokal, layanan waktu, konfigurasi host, dan keamanan berjalan
    • VPN, Transit Gateway, Direct Connect, dan Network Firewall juga mendukung IPv6

IPv6 tersendat pada tahap penggunaan layanan AWS

  • Bottleneck muncul bukan pada jaringan itu sendiri, melainkan pada tahap menghubungkan ke layanan AWS lain
  • Layanan inti seperti API Gateway, Lambda, ECS, dan App Runner menolak konfigurasi subnet IPv6-only atau memunculkan error
    • Elastic Load Balancer dapat memunculkan error seperti Not enough IP space available
  • Mengonfigurasi bagian internal sebagai dual-stack pun tidak cukup
    • Banyak layanan mengabaikan IPv6 meski subnet sudah dikonfigurasi dengan IPv6
    • Sering kali layanan hanya dapat terhubung ke target IPv4
  • Ada banyak kasus di mana penggunaan API layanan dari VPC tanpa alamat IPv4 publik sulit atau tidak mungkin
    • Menjalankan aws s3 ls dari instance EC2 gagal
    • Systems Manager, cara yang direkomendasikan untuk mengakses dan mengelola instance, tidak berjalan
    • Akses SQS dari ECS Task tidak memungkinkan
  • Menurut status dukungan AWS IPv6, lebih dari 90% endpoint API layanan tidak mendukung IPv6
  • Endpoint SES SMTP dan ECR repository juga tidak berjalan, dan CloudFront tidak dapat terhubung ke origin IPv6
    • Tugas ECS tidak dapat dimulai dari ECR, tetapi bisa dari Docker Hub yang mendukung IPv6
    • Docker Hub menerapkan rate limit pada pull

PrivateLink adalah alternatif, tetapi batasan biayanya besar

  • Banyak layanan dapat dihubungkan melalui PrivateLink
    • Karena terhubung langsung ke VPC pelanggan, alamat IP publik tidak diperlukan
    • Namun tidak mendukung semua layanan
  • PrivateLink dikenai biaya per layanan dan per Availability Zone
    • Sekitar $9 per bulan per endpoint
    • Misalnya, menghubungkan Secrets Manager, EC2, SSM, dan SSM-Messages di 3 Availability Zone akan menjadi lebih dari $1.200 per tahun per VPC
    • Biaya trafik tambahan juga berlaku

Mengapa penagihan IPv4 sulit berujung pada migrasi ke IPv6

  • Bagi pelanggan berskala besar, penagihan IPv4 umumnya berada di level kurang dari 1% tagihan, sehingga tidak terasa sebagai perubahan besar
    • Biaya ini saja sulit memicu investasi engineering yang berarti
  • Bagi SMB, pengguna hobi, dan startup, biayanya dapat menaikkan tagihan hingga 10–30%
    • Mereka punya insentif besar untuk mengadopsi IPv6 demi menghindari biaya
    • Namun celah dukungan IPv6 pada layanan AWS membatasi cara untuk menghindari biaya IPv4
  • Mengingat biaya akuisisi IPv4 belakangan ini, penagihan alamat IPv4 itu sendiri mungkin diperlukan
  • Jika dukungan IPv6 di seluruh layanan AWS sudah matang, lebih banyak pelanggan dapat bermigrasi ke lingkungan IPv6-only
  • Saat ini IPv6 sulit dianggap sebagai warga kelas satu di AWS, dan dalam situasi ini penagihan IPv4 membuat penggunaan AWS untuk akun pribadi, belajar, persiapan sertifikasi, dan dukungan open source menjadi kurang menarik

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-24
Opini Hacker News

  • Dulu sekali, ketika saya masih developer junior di Amazon, ada proyek internal berskala besar untuk memecah semua sistem internal menjadi versi per region, dan panggilan antar-region hanya diizinkan lewat gateway terbatas
    Alasannya adalah karena alamat IPv4 internal sudah habis
    Saat ditanya, “Kenapa tidak langsung pindah saja ke IPv6?”, Principal PM yang bertanggung jawab menjawab kira-kira begini: “Terlalu banyak perangkat jaringan internal yang kami miliki saat ini tidak mendukung IPv6, jadi untuk menggantinya kami harus membeli perangkat dalam jumlah yang mendekati produksi tahunan global lalu memasang semuanya”
    Memang mudah melihat Amazon seolah bersikap jahat terkait IPv4, tetapi mengingat skala sistem AWS, cukup masuk akal juga bahwa mengganti semua hardware jaringan lama dalam waktu singkat mungkin merupakan proyek yang terlalu besar

    • Saya penasaran apakah Anda ingat itu tahun berapa
      Saya curiga itu agak omong kosong, atau setidaknya pengemasan fakta secara kreatif. Misalnya, bisa saja sebenarnya semuanya punya dukungan IPv6, tetapi para network engineer yang dipenuhi rasa takut, ketidakpastian, dan keraguan tidak mau menyalakannya
      Sebagian besar perangkat jaringan yang pernah saya lihat sudah dual stack jauh sebelum IPv6 benar-benar dipakai di sekitar saya, dan saya selalu mengira itu karena persyaratan pemerintah atau militer AS
    • Saya ingat regionalisasi itu. Dari samping pun itu terlihat “menarik”. Saya berada di sisi layanan baru yang sejak awal dibuat per region
      Saya tidak ingat siapa PM proyek itu, tetapi saat itu saya benar-benar jadi menghargai nilai yang bisa dihasilkan seorang TPM
      Benar bahwa biaya dan kebutuhan mengganti perangkat jaringan adalah salah satu alasan kuat mengapa mereka tidak beralih ke IPv6. Amazon menggunakan perangkat jaringan yang dirancang dan dibuat sendiri karena berbagai alasan, dan mungkin masih begitu sampai sekarang
      Semua perangkat itu punya kapasitas memori tetap, jadi untuk menambah memori agar mampu menangani tabel routing IPv6 dan sebagainya, perangkatnya harus diganti. Bahkan jika memilih IPv6-only, perangkat lama tetap tidak akan cukup, dan bagaimanapun juga sulit lolos tanpa dual stack IPv4/IPv6
    • PM itu mungkin Laura Grit, dan menurut saya sebenarnya dia TPM. Laura sekarang Distinguished Engineer
      Dia sepertinya selalu mengerjakan proyek berskala sangat besar, dan IPv4 kini termasuk bagian kecil di antaranya. Sayangnya, beberapa proyek besar yang sedang dikerjakannya sekarang tidak bisa saya bagikan
      Ia pernah beberapa kali meluangkan waktu untuk saya dan memberi nasihat yang bijak, dan saya menghargainya
    • Jika mengganti semua hardware jaringan lama dalam waktu singkat adalah proyek yang terlalu besar, maka Amazon tidak semestinya memaksakan biaya IPv4 dengan jadwal singkat sebelum selesai mengganti perangkat agar IPv6 dapat didukung di mana-mana secara internal
    • Namun itu bukan berarti mereka boleh tidak melakukan adopsi IPv6 secara bertahap. Masalah ini tidak bisa ditunda selamanya
      Pasti mereka sudah memulai prosesnya
      Benar begitu, kan? Sulit membayangkan AWS membenamkan kepala ke pasir dan mengabaikan hal ini

  • Menyediakan IPv6 yang benar-benar berfungsi tampaknya jelas bertentangan dengan insentif AWS. Alat-alat pengaruh AWS, seperti standar Well-Architected atau sertifikasi, sangat mendorong pembuatan labirin jaringan RFC1918 10.x dengan alamat yang ambigu, bukan arsitektur ala internet yang memiliki pengalamatan end-to-end
    Dalam dunia rekomendasi AWS, konsep “alamat IP publik” itu sendiri adalah tanda bahaya, dan AWS bahkan merekomendasikan alat yang menandai serta “memitigasi” alamat semacam itu dengan biaya tambahan
    Jika pelanggan dibuat menghabiskan tenaga membangun infrastruktur kompleks atas nama keamanan, efek lock-in yang kuat pun tercipta. Padahal kenyataannya hal itu justru merusak keamanan lewat kompleksitas yang tidak perlu, ambiguitas alamat, dan sebagainya

    • Azure juga meniru ini sepenuhnya
      Sudah tak terhitung berapa banyak produk seperti “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, dan “Virtual WAN” yang muncul, dan semuanya dibuat untuk menjalankan IPv4 dalam skala besar
      Jika IPv6 dibuat berfungsi dengan benar, secara harfiah tidak satu pun produk ini diperlukan
      Sebaliknya, Azure juga melakukan NAT untuk IPv6, sehingga kita bahkan tidak bisa memakai IPv6 untuk menghindari NAT yang dipaksakan oleh IPv4. Pada 2023 pun mereka masih merilis produk baru yang tidak mendukung IPv6 dan besar kemungkinan akan tetap begitu
      Di dokumentasinya masih ada satu halaman penuh berisi batasan: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      Jika dibayangkan ini adalah transisi dari IPX ke IPv4, terlihat betapa tidak masuk akalnya. Seolah-olah halaman ini menulis, “Batasan IPv4: semua VM harus menyertakan setidaknya satu alamat IPX”
      Terdengar aneh, bukan? Pada 1999 pelanggan sedang dimigrasikan dari IPX ke IPv4, dan dukungan IPv6 muncul kira-kira pada 2001–2003. Meski sudah puluhan tahun berlalu, rasanya seperti masa sebelum migrasi Novell NetWare yang berkata, “Kita masih butuh IPX+IPv4 karena belum semuanya mendukung IPv4”
      Daftar ini sama sekali bukan seluruh batasannya. Karena sebagian besar produk PaaS tidak mendukung IPv6, solusi IaaS+PaaS pada akhirnya harus menggunakan IPv4 dalam sebagian besar kasus
    • Ini bukan masalah AWS saja. Microsoft, auditor keamanan, penetration tester, perusahaan asuransi siber, dan lainnya pada umumnya juga menuntut agar tidak ada endpoint yang dapat dialamati secara publik
      Saya tidak paham alasannya, tetapi sampai ada perusahaan teknologi besar yang mendorong pengalamatan end-to-end sebagai praktik terbaik, kita tidak punya pilihan selain mengikuti kebijaksanaan umum agar tidak menciptakan tanda bahaya
    • Saya bekerja di Azure, dan berdasarkan pengalaman saya, pelanggan memang menginginkan ini dan ada alasan yang masuk akal
      Pelanggan menginginkan jaringan privat milik mereka sendiri untuk mencegah intrusi dan kebocoran data bahkan di atas mesin yang bukan mereka miliki. Lebih jauh lagi, mereka juga ingin memasukkan layanan PaaS yang lengkap dan siap pakai ke dalam jaringan itu
    • Saya tidak yakin keduanya berkaitan. Kalau AWS mau, mereka bisa mempromosikan IPv6 sebagai obat mujarab yang menyelesaikan semua masalah jaringan internal, dan jika benar-benar berfungsi, pesaing akan sulit mengejarnya
      Dugaan saya alasannya lebih biasa: jika mempertimbangkan jumlah layanan AWS, dukungan IPv4 memang lebih mudah
    • Saya tidak mengerti bagaimana memblokir akses eksternal ke layanan internal bisa merusak keamanan

  • Sebagai pelanggan AWS, saya ingin lepas dari IP itu sendiri. Mengelola sistem jaringan kompleks yang terdiri dari protokol usang seperti IP, BGP, dan DNS itu buang-buang waktu
    Cukup izinkan saya mengaitkan identitas yang kuat ke workload, lalu menerapkan kebijakan tentang workload mana yang boleh bertukar data dengan workload mana
    Bagaimana data berpindah dari satu workload ke workload lain seharusnya bukan urusan saya; pokoknya buat saja itu berjalan

    • Sepenuhnya setuju. Sebagai catatan, karena perasaan seperti inilah sekarang banyak bermunculan “platform” cloud yang melakukan hal semacam itu
      Alih-alih terjebak dalam datacenter tervirtualisasi, yakni kebun binatang komponen jaringan tiruan, semuanya diabstraksikan
    • Perasaan itu valid, tetapi argumen seperti ini mirip dengan logika yang dipakai orang saat membicarakan solusi low-code
      Dalam kenyataannya, itu belum pernah benar-benar bekerja dengan baik dan tidak akan bisa. Terlalu banyak nuansa dan detail yang harus dipertimbangkan untuk menjalankan dan mengoptimalkan workload nyata
    • “Orang-orang yang melihat gambaran besar” pun tiba-tiba mulai peduli pada detail ketika gambaran besar itu tidak menyelesaikan detailnya
    • Semacam Heroku? Saya sudah beberapa tahun tidak memakai Heroku, jadi tidak tahu kondisinya sekarang
    • Jadi ingin internet tanpa protokol internet?

  • Dalam pengalaman saya, masalah terbesar saat beralih ke IPv6-only di AWS adalah GitHub masih belum bisa IPv6. Banyak sekali perangkat lunak mengasumsikan bisa terhubung ke GitHub untuk mengambil sesuatu
    Layanan NAT64 publik bisa dipakai, tetapi tidak terlalu bisa diandalkan untuk penggunaan serius: https://nat64.xyz/
    AWS mengenakan biaya sangat besar untuk trafik NAT Gateway, dan saya juga tidak tahu apakah bisa dikonfigurasi agar hanya mencegat trafik menuju host IPv4-only. Kalau saya keliru, saya ingin diberi tahu
    Selain itu, memakai IPv6-only di AWS berjalan tanpa cela dan lebih murah. Egress gateway untuk jaringan privat gratis. Tentu dengan prasyarat bahwa Anda tidak perlu memikirkan IPv4

    • Sayang sekali GitHub tidak mengikuti arus deployment IPv6 dari perusahaan induknya, Microsoft
    • Kalau memakai jaringan dual-stack di AWS, bukankah DNS akan memprioritaskan IPv6 tetapi IPv4 tetap berfungsi? Saya mengatur sebagian besar hal yang membutuhkan egress internet umum seperti itu

  • Menurut saya masalah sebenarnya adalah Lambda dan S3 tidak mendukung IPv6, dan AWS seharusnya terlebih dahulu membuat keduanya dual-stack agar bisa diakses lewat IPv6 sebelum mengubah harga
    Secara teknis S3 memang punya endpoint dual-stack terpisah, tetapi itu tidak banyak membantu karena bagaimanapun konfigurasi aplikasi harus diubah untuk menanggapi perubahan ini

  • Sejak awal, setengah alasan AWS unggul dalam dukungan IPv6 adalah mandat kebijakan dari pemerintah AS yang memerintahkan untuk mulai bermigrasi
    Dari sisi biaya, benar bahwa biaya baru ini sepele bagi pelanggan besar, tetapi jangan meremehkan kekuatan mandat kebijakan dari pelanggan-pelanggan terbesar. Ancaman bahwa mereka akan membuat alternatif sendiri demi kepatuhan kebijakan saja bisa membuat AWS pada akhirnya menaikkan prioritas dukungan

    • Benar. Ini bukan pemikiran yang terlalu saya sukai, tetapi tampaknya makin tidak ada cara lain untuk mendorong IPv6 di “sisi server”
      Sisi klien, yaitu pengguna akhir, tampaknya berjalan baik. Terlihat dari Google yang belakangan melaporkan trafik IPv6 pengguna akhir hampir 50%

  • Secara pribadi, yang paling buruk adalah CloudFront tidak mendukung IPv6 untuk origin kustom
    Jika menjalankan banyak kontainer Fargate terpisah sebagai origin, Anda harus mengaktifkan alamat IPv4 publik, dan sebentar lagi biaya kontainer kecil akan menjadi dua kali lipat
    Amazon seharusnya membuat infrastrukturnya sendiri benar-benar mendukung IPv6 sebelum mengenakan biaya tambahan untuk penggunaan IPv4 legacy

    • Benar. Anehnya, ini yang paling menyakitkan
      Saya tahu Amazon telah membangun monster raksasa dan menerapkan IPv6 ke begitu banyak layanan adalah pekerjaan yang sangat besar, tetapi saya tidak melihat alasan CloudFront tidak bisa mendukung origin IPv6 bukan sekarang, melainkan sejak kemarin
      Itu juga tidak tampak relatif sulit, dan bisa menjadi alat yang bagus untuk melewati batasan lain
      Sejujurnya, sampai sekarang saya merasa keputusan Amazon pada akhirnya dibuat dengan mempertimbangkan kepentingan terbaik pelanggan, tetapi sekarang tidak lagi. Saya melihat ini sebagai sinyal buruk ke depan

  • Akan sangat membantu jika di AS benar-benar ada persaingan ISP
    Tempat saya menyewa berada di pinggiran dekat Seattle, tetapi ISP broadband nyata hanya ada satu. Ini sama sekali bukan pedesaan menurut definisi apa pun, tetapi Comcast adalah satu-satunya pilihan. Harga dan layanannya persis mencerminkan kenyataan itu

    • Kita harus berterima kasih pada lobi tanpa henti yang memungkinkan monopoli yang dipaksakan secara hukum di bidang ini. Hal yang sama juga dilakukan pada perusahaan telepon
      Bukan kebetulan “hanya Comcast”, melainkan karena regulasi hukum menjadi “hanya Comcast”
    • Comcast mendukung IPv6. Pada 2016 mereka mencapai tingkat dukungan IPv6 98%
    • Konsumen tidak tahu dan tidak peduli tentang IPv6, jadi persaingan tidak akan mendorong implementasi oleh ISP
      Hal lucu dari mengeluh tentang Comcast adalah, saat saya memakai Comcast, saya punya IPv6 native. Penyedia yang saya pakai sekarang hanya punya IPv6 melalui NAT46
    • Starlink bisa menjadi pilihan lain
      Ada kekurangan seperti penurunan performa saat hujan deras, tetapi saya juga melihat beberapa ulasan positif
    • Adopsi IPv6 justru akan makin mendorong pelanggan ke operator monopoli besar. Sebab hanya merekalah yang mampu menanggung staf engineering jaringan khusus untuk membuatnya berjalan stabil
      Kebanyakan orang tidak tahu bahwa saat ini ada dua internet IPv6. Ada sisi Cogent dan sisi Hurricane Electric, ukurannya kurang lebih sama, dan keduanya menolak saling terhubung. Jadi Anda harus mengetahui hal ini dan membeli transit dari keduanya, atau membeli dari jaringan yang membeli transit dari keduanya
      Setidaknya satu operator besar yang saya tahu masih menjalankan v6 di atas tunnel. Di banyak tempat, trafik v6 melewati rute yang tidak optimal, dan jaringan perusahaan mungkin punya koneksi v4 di setiap datacenter, tetapi untuk v6 semuanya dikirim ke satu “kotak di bawah meja Dave”
      Meski begitu, mereka mengukur tingkat adopsi v6 di tempat-tempat seperti Google atau Cloudflare, yang punya tim khusus untuk memastikan paket sampai, lalu menepuk punggung sendiri

  • Ungkapan “tidak bisa lepas dari IPv4” memang tepat. Anda bisa membuat VPC khusus IPv6, tetapi terlalu banyak hal yang rusak, mulai dari berbagai layanan AWS hingga repositori paket: https://blog.devopstom.com/ipv6-only-ec2/
    Pada akhirnya Anda harus mengaktifkan IPv4, menjalankan gateway NAT64 sendiri, atau memercayai NAT64 yang dioperasikan orang lain: https://nat64.net dan http://v4-frontend.netiter.com

  • Pernyataan “karena di IPv6 tidak ada konsep alamat privat, ucapkan selamat tinggal pada Managed NAT Gateway dan harganya yang megah” mungkin benar di dalam AWS, tetapi IPv6 memiliki alamat Unique Local IPv6 di fc00::/7, dan kalau Anda benar-benar menyukai NAT, ada juga NAT66

    • Benar, yang dimaksud adalah AWS, dan seharusnya itu diperjelas
      Namun ULA sering kali tidak direkomendasikan, dan NAT66 itu… pokoknya tidak bisa
      Dari yang baru-baru ini saya dengar, Microsoft menjadikan IPv6 di Azure sepenuhnya berpusat pada NAT. Benar-benar aneh