ลูกค้า AWS ยังหนีออกจาก IPv4 ไม่ได้

 (tty.neveragain.de)
1 คะแนน โดย GN⁺ 2023-09-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่เดือนกุมภาพันธ์ 2024 AWS จะคิดค่าบริการ $0.005 ต่อชั่วโมงสำหรับที่อยู่ public IPv4 แบบเฉพาะ แต่ข้อจำกัดของบริการ AWS ทำให้ลูกค้าหลีกเลี่ยงค่าใช้จ่ายด้วยการย้ายไปใช้ IPv6 ได้ยาก
  • ขอบเขตการคิดค่าบริการครอบคลุมกว้าง ทั้ง Elastic Load Balancer, EC2/Elastic IP, งาน ECS Fargate ที่ตั้งค่า public IP, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway เป็นต้น
  • แม้ EC2, VPN, Transit Gateway, Direct Connect, Network Firewall และบริการอื่น ๆ จะทำงานบนพื้นฐาน IPv6 ได้ แต่บริการหลักอย่าง API Gateway, Lambda, ECS, App Runner กลับปฏิเสธ subnet แบบ IPv6-only หรือรองรับได้ไม่สมบูรณ์
  • ต่อให้ตั้งค่าภายในเป็น dual-stack ก็ยังไม่พอ เพราะ มากกว่า 90% ของ service API endpoints ยังไม่รองรับ IPv6 ทำให้ใช้งาน S3, Systems Manager, SQS และบริการอื่น ๆ จาก VPC โดยไม่มี public IPv4 ได้ยาก
  • สำหรับลูกค้ารายใหญ่ ค่าใช้จ่ายนี้มักต่ำกว่า 1% ของบิล จึงมีแรงจูงใจในการย้ายไม่มากนัก ขณะที่ SMB, ผู้ใช้สายงานอดิเรก และสตาร์ทอัพอาจเจอต้นทุนเพิ่ม 10–30% จึงได้รับผลกระทบมากกว่า

เริ่มคิดค่าบริการ public IPv4 แบบเฉพาะตั้งแต่กุมภาพันธ์ 2024

  • ตั้งแต่เดือนกุมภาพันธ์ 2024 AWS จะคิดค่าบริการ $0.005 ต่อชั่วโมง สำหรับ ที่อยู่ public IPv4 แบบเฉพาะ แต่ละรายการ
    • คิดเป็นเกือบ $4 ต่อเดือน และมากกว่า $40 ต่อปี
    • ใช้กับ IP ที่ AWS เป็นเจ้าของ ส่วนที่อยู่ BYOIP ที่ลูกค้านำบล็อก public IPv4 ที่ route ได้ของตนเองมาใช้จะไม่ถูกคิดค่าบริการ
  • ทรัพยากรที่อยู่ในข่ายคิดค่าบริการครอบคลุมทรัพยากรหลักที่ใช้ public IPv4 โดยตรง
    • Elastic Load Balancer
      • ใช้ที่อยู่ 1 รายการต่อ Availability Zone
      • ต้องมีอย่างน้อย 2 รายการ และไม่สามารถปิด IPv4 ได้
    • EC2 instances และ Elastic IP
    • งาน ECS Fargate ที่ตั้งค่า public IP
    • Global Accelerator IP
    • Site-to-site VPN IP
    • RDS
    • Managed NAT Gateway
  • ที่อยู่ IPv4 แบบใช้ร่วมกันจะไม่ถูกคิดค่าบริการ
    • ที่อยู่แบบใช้ร่วมกันที่ใช้กับ CloudFront distributions หรือ API Gateway endpoints ไม่อยู่ในข่ายคิดค่าบริการ
    • public IPv4 ที่ Lambda functions นอก VPC ใช้ก็ไม่ถูกคิดเช่นกัน

รูปแบบที่ทำให้ต้นทุนเพิ่มขึ้นมาก

  • Elastic Load Balancer แบบ public ที่กระจายอยู่ 3 Availability Zones จะมี ราคาพื้นฐานเพิ่มขึ้นมากกว่า 50%
  • Managed NAT Gateway จะมีราคาพื้นฐานเพิ่มขึ้นราว 10%
    • NAT Gateway ไม่มีความซ้ำซ้อนระดับ Availability Zone ในตัว
    • หากการเชื่อมต่อขาออกมีความสำคัญ ก็ต้องมี NAT Gateway แยกในแต่ละ Availability Zone
  • มีอยู่ 2 รูปแบบที่ได้รับผลกระทบมากเป็นพิเศษ เพราะสิ้นเปลืองที่อยู่จำนวนมาก
    • การวางหลาย Load Balancer ไว้ในแต่ละ VPC
      • มักเกิดจากการประกอบหลาย CloudFormation templates หรือ Terraform modules เข้าด้วยกัน หรือเมื่อ Kubernetes ingress controller สร้าง Load Balancer แยกต่อบริการ
      • ทั้งที่ Load Balancer ตัวเดียวสามารถรองรับหลาย URL และหลายบริการได้
    • การตั้งใจผูก public IPv4 ให้กับ EC2 instances และ Fargate tasks เพื่อหลีกเลี่ยง Managed NAT Gateway
      • น่าขันที่จนกว่าจะใช้ public IPv4 ถึงราว 10 รายการต่อ Availability Zone วิธีนี้ก็ยังถูกกว่าอยู่ดี

วิธีตรวจสอบการใช้งานปัจจุบัน

  • ปริมาณการใช้ public IPv4 address ถูกนับรวมไว้ในบัญชีแล้ว
    • ตอนนี้ยังแสดงเป็น $0 แต่ตั้งแต่กุมภาพันธ์ 2024 จะถูกคิดที่อัตรา $0.005 ต่อชั่วโมง
  • ตรวจสอบได้จากเส้นทางต่อไปนี้
    • Billing Dashboard > Bills
      • ในส่วน Virtual Private Cloud จะปรากฏเป็น PublicIPv4:InUseAddress
    • Cost Explorer
      • สามารถกรองให้รวมเฉพาะ PublicIPv4:InUseAddress เพื่อดูการใช้งานรายวันและรายชั่วโมงได้
      • และยังสามารถจัดกลุ่มตาม member account ได้
    • VPC > VPC IP Address Manager > Public IP insights
      • ดูภาพรวมการใช้งาน public IPv4 ได้
      • ส่วนนี้ของ IPAM ใช้งานฟรี
      • แต่แสดงข้อมูลได้เพียงระดับ account และ region และจับที่อยู่ที่ถูกใช้ชั่วคราวไม่ได้ จึงทำให้ข้อมูลไม่สมบูรณ์

2 แนวทางในการนำ IPv6 มาใช้

  • เมื่อที่อยู่ IPv4 มีค่าใช้จ่าย แต่ที่อยู่ IPv6 ฟรี มองเผิน ๆ การย้ายไปใช้ IPv6 ดูเป็นทางเลือกที่สมเหตุสมผล
  • IPv6 ไม่มีแนวคิดเรื่อง private address จึงสามารถหลีกเลี่ยง Managed NAT Gateway และค่าใช้จ่ายของมันได้
  • วิธีนำ IPv6 มาใช้มีหลัก ๆ 2 แบบ
    • dual-stack
      • ตั้งค่าทั้ง IPv4 และ IPv6 ให้ทุกระบบ
    • IPv6-only ภายใน
      • ใช้ IPv6 ภายในอย่างเดียว และให้มีการเชื่อมต่อ IPv4 เฉพาะที่ edge หรือ CDN ที่ติดต่อกับผู้ใช้ทั่วไป
  • บันทึกคำสั่งจากทำเนียบขาวสหรัฐระบุว่าการเดินระบบแบบ dual-stack ซับซ้อนเกินไปและไม่จำเป็นต่อการดูแลรักษาอีกแล้ว และองค์กรกำหนดมาตรฐานกับบริษัทเทคโนโลยีรายใหญ่ก็เริ่มขยับไปสู่การ deploy แบบ IPv6-only
  • ตัวการรองรับเครือข่าย IPv6 พื้นฐานของ AWS เองนั้นถือว่าค่อนข้างดี
    • สามารถตั้งค่า EC2 instances แบบ IPv6-only ใน subnet แบบ IPv6-only ได้
    • ฟีเจอร์ที่คาดหวังในเครือข่าย IPv6 เช่น local DNS, time service, host configuration, security ใช้งานได้
    • VPN, Transit Gateway, Direct Connect, Network Firewall ก็รองรับ IPv6 เช่นกัน

IPv6 ติดขัดตอนใช้งานบริการ AWS

  • คอขวดไม่ได้อยู่ที่เครือข่ายเอง แต่เกิดขึ้นตอน เชื่อมต่อกับบริการ AWS อื่น
  • บริการหลักอย่าง API Gateway, Lambda, ECS, App Runner จะปฏิเสธการตั้งค่า subnet แบบ IPv6-only หรือเกิด error
    • Elastic Load Balancer อาจแสดง error เช่น Not enough IP space available
  • ต่อให้ตั้งค่าภายในเป็น dual-stack ก็ยังไม่พอ
    • หลายบริการจะมองข้ามการตั้งค่า IPv6 แม้ subnet จะถูกตั้งค่าไว้แล้ว
    • และมักเชื่อมต่อได้เฉพาะปลายทางแบบ IPv4
  • มีหลายกรณีที่การใช้ service API จาก VPC โดยไม่มี public IPv4 address ทำได้ยากหรือแทบเป็นไปไม่ได้
    • การรัน aws s3 ls บน EC2 instance ล้มเหลว
    • Systems Manager ซึ่งเป็นวิธีที่แนะนำสำหรับการเข้าถึงและจัดการ instance ใช้งานไม่ได้
    • ECS Task ไม่สามารถเข้าถึง SQS ได้
  • ตาม สถานะการรองรับ IPv6 ของ AWS พบว่า มากกว่า 90% ของ service API endpoints ยังไม่รองรับ IPv6
  • SES SMTP และ ECR repository endpoints ก็ใช้งานไม่ได้ และ CloudFront ก็เชื่อมต่อกับ IPv6 origin ไม่ได้
    • แม้จะไม่สามารถเริ่ม ECS tasks จาก ECR ได้ แต่สามารถทำได้จาก Docker Hub ที่รองรับ IPv6
    • Docker Hub มี rate limit สำหรับการ pull

PrivateLink เป็นทางเลือก แต่ติดข้อจำกัดด้านต้นทุน

  • หลายบริการสามารถเชื่อมต่อผ่าน PrivateLink ได้
    • เพราะเชื่อมตรงเข้ากับ VPC ของลูกค้า จึงไม่ต้องใช้ public IP address
    • แต่ก็ไม่ได้รองรับทุกบริการ
  • PrivateLink คิดค่าบริการ ต่อบริการและต่อ Availability Zone
    • ตกประมาณ $9 ต่อ endpoint ต่อเดือน
    • ตัวอย่างเช่น หากเชื่อม Secrets Manager, EC2, SSM และ SSM-Messages ใน 3 Availability Zones จะมีต้นทุนมากกว่า $1,200 ต่อปีต่อ VPC
    • และยังมีค่าทราฟฟิกเพิ่มเติมอีก

ทำไมการคิดค่าบริการ IPv4 จึงผลักให้ย้ายไป IPv6 ได้ยาก

  • สำหรับลูกค้าที่มีขนาดใหญ่ ค่าใช้จ่าย IPv4 โดยมากอยู่ที่ระดับ ต่ำกว่า 1% ของบิล จึงไม่รู้สึกว่าเป็นการเปลี่ยนแปลงใหญ่
    • ค่าใช้จ่ายระดับนี้เพียงอย่างเดียวมักไม่พอให้เกิดการลงทุนทางวิศวกรรมอย่างจริงจัง
  • สำหรับ SMB, ผู้ใช้งานแบบงานอดิเรก และสตาร์ทอัพ ค่าบริการอาจเพิ่มขึ้นถึง 10–30% ของบิล
    • กลุ่มนี้มีแรงจูงใจสูงที่จะนำ IPv6 มาใช้เพื่อลดค่าใช้จ่าย
    • แต่ช่องว่างด้านการรองรับ IPv6 ของบริการ AWS ทำให้ทางเลือกในการเลี่ยงต้นทุน IPv4 มีจำกัด
  • เมื่อพิจารณาต้นทุนการจัดหา IPv4 ในปัจจุบัน การคิดค่าบริการที่อยู่ IPv4 เองอาจเป็นสิ่งจำเป็น
  • หากการรองรับ IPv6 ของบริการต่าง ๆ บน AWS เติบโตเต็มที่กว่านี้ ลูกค้าจะย้ายไปสภาพแวดล้อมแบบ IPv6-only ได้มากขึ้น
  • ปัจจุบันยังยากจะมองว่า IPv6 เป็น พลเมืองชั้นหนึ่ง บน AWS และในสภาพนี้ การคิดค่าบริการ IPv4 ก็ยิ่งทำให้การใช้ AWS สำหรับบัญชีส่วนตัว การเรียนรู้ การเตรียมสอบใบรับรอง และการสนับสนุนโอเพนซอร์ซ น่าสนใจน้อยลง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-24
ความคิดเห็นจาก Hacker News

  • เมื่อนานมาแล้วตอนผมเป็นนักพัฒนารุ่นจูเนียร์ที่ Amazon มีโปรเจกต์ภายในขนาดใหญ่ที่แยกระบบภายในทั้งหมดออกเป็น เวอร์ชันตามรีเจียน และอนุญาตให้เรียกข้ามรีเจียนได้ผ่านเกตเวย์ที่จำกัดไว้เท่านั้น
    เหตุผลคือ ที่อยู่ IPv4 ภายในกำลังจะหมด
    เมื่อมีคำถามว่า “แค่เปลี่ยนเป็น IPv6 ไม่ได้เหรอ?” Principal PM ที่รับผิดชอบตอบประมาณว่า “อุปกรณ์เครือข่ายภายในที่เรามีอยู่ตอนนี้ มีจำนวนมากเกินไปที่ไม่รองรับ IPv6 ถ้าจะเปลี่ยนใหม่ คงต้องซื้ออุปกรณ์ในปริมาณใกล้เคียงกับการผลิตทั้งปีทั่วโลกแล้วติดตั้งทั้งหมด”
    มันง่ายที่จะมองว่า Amazon กำลังทำตัวไม่ดีในฝั่ง IPv4 แต่เมื่อคิดถึงขนาดของระบบ AWS แล้ว ก็เชื่อได้พอสมควรว่าการเปลี่ยนฮาร์ดแวร์เครือข่ายเก่าทั้งหมดภายในเวลาสั้น ๆ อาจเป็นโปรเจกต์ที่ใหญ่เกินไปจริง ๆ

    • อยากรู้ว่าจำได้ไหมว่าเป็นปีไหน
      ผมสงสัยว่านั่นอาจจะเป็นเรื่องเหลวไหลอยู่บ้าง หรืออย่างน้อยก็เป็นการห่อหุ้มข้อเท็จจริงแบบสร้างสรรค์ ตัวอย่างเช่น จริง ๆ แล้วอาจมี การรองรับ IPv6 ทั้งหมดอยู่แล้ว แต่เหล่าวิศวกรเครือข่ายที่เต็มไปด้วยความกลัว ความไม่แน่นอน และความสงสัยไม่อยากเปิดใช้ก็ได้
      อุปกรณ์เครือข่ายส่วนใหญ่ที่ผมเคยเห็นเป็น dual stack มานานก่อนที่คนรอบตัวจะใช้ IPv6 จริง ๆ แล้ว และผมคิดมาตลอดว่านั่นเป็นเพราะข้อกำหนดของรัฐบาลหรือกองทัพสหรัฐฯ
    • จำเรื่อง regionalisation นั่นได้ มองจากข้าง ๆ ก็เป็นงานที่ “สนุก” ดี ผมอยู่ฝั่งบริการใหม่ที่สร้างมาให้แยกตามรีเจียนตั้งแต่แรก
      จำไม่ได้ว่า PM ของโปรเจกต์นั้นคือใคร แต่ตอนนั้นทำให้ผมเคารพคุณค่าที่ TPM สามารถสร้างได้จริง ๆ
      เรื่องที่ค่าใช้จ่ายและความจำเป็นในการเปลี่ยนอุปกรณ์เครือข่ายเป็นหนึ่งในเหตุผลสำคัญที่ไม่ไปทาง IPv6 นั้นถูกต้อง Amazon ใช้อุปกรณ์เครือข่ายที่ออกแบบและผลิตเองด้วยหลายเหตุผล และน่าจะยังเป็นเช่นนั้นอยู่ตอนนี้
      อุปกรณ์เหล่านั้นทั้งหมดมี ความจุหน่วยความจำแบบคงที่ ดังนั้นถ้าจะเพิ่มหน่วยความจำให้พอรองรับตาราง routing ของ IPv6 เป็นต้น ก็ต้องเปลี่ยนอุปกรณ์อยู่ดี ต่อให้เลือกใช้ IPv6-only อุปกรณ์เดิมก็คงไม่พอ และไม่ว่าจะอย่างไรก็คงผ่านไปได้ยากหากไม่มี dual stack IPv4/IPv6
    • PM คนนั้นน่าจะเป็น Laura Grit และผมคิดว่าจริง ๆ แล้วคงเป็น TPM Laura ตอนนี้เป็น Distinguished Engineer
      ดูเหมือนเธอจะทำโปรเจกต์ระดับมหึมาอยู่เสมอ และตอนนี้ IPv4 กลายเป็นแค่ส่วนเล็ก ๆ ในบรรดาโปรเจกต์เหล่านั้น โปรเจกต์ใหญ่บางอย่างที่ทำอยู่ตอนนี้น่าเสียดายที่แชร์ไม่ได้
      เธอเคยสละเวลาให้สองสามครั้งและให้คำแนะนำที่ชาญฉลาด ซึ่งผมรู้สึกขอบคุณ
    • ถ้าการเปลี่ยนฮาร์ดแวร์เครือข่ายเก่าทั้งหมดเป็นโปรเจกต์ที่ใหญ่เกินไปสำหรับเวลาสั้น ๆ Amazon ก็ไม่ควรผลักดันการเก็บค่าบริการ IPv4 ด้วยกำหนดการที่สั้น จนกว่าจะเปลี่ยนเสร็จเพื่อให้ รองรับ IPv6 ได้ทุกที่ภายใน
    • แต่นั่นไม่ได้หมายความว่าไม่ต้อง ทยอยนำ IPv6 มาใช้ ปัญหานี้เลื่อนไปตลอดกาลไม่ได้
      แน่นอนว่าคงเริ่มกระบวนการไปแล้ว
      ใช่ไหม? นึกภาพไม่ออกว่า AWS จะเอาหัวมุดทรายแล้วทำเป็นไม่สนใจเรื่องนี้

  • การที่ AWS จะให้บริการ IPv6 ที่ใช้งานได้จริงดูเหมือนจะขัดกับแรงจูงใจของตัวเองอย่างชัดเจน เครื่องมืออิทธิพลของ AWS เช่นเกณฑ์ Well-Architected หรือการรับรองต่าง ๆ ผลักดันอย่างหนักให้สร้างเขาวงกตเครือข่าย 10.x RFC1918 ที่มีการกำหนดที่อยู่แบบคลุมเครือ แทนที่จะเป็นสถาปัตยกรรมแบบอินเทอร์เน็ตที่มีการกำหนดที่อยู่แบบ end-to-end
    ในโลกของแนวทางแนะนำของ AWS แนวคิดเรื่อง “ที่อยู่ IP สาธารณะ” เองก็เป็นสัญญาณอันตราย และ AWS ยังแนะนำเครื่องมือที่คิดค่าใช้จ่ายเพิ่มเพื่อแสดงและ “บรรเทา” ที่อยู่เหล่านั้นด้วย
    ถ้าทำให้ลูกค้าทุ่มแรงสร้างโครงสร้างพื้นฐานที่ซับซ้อนในนามของความปลอดภัย ก็จะเกิด ผลของการล็อกอิน ที่แข็งแรง ทั้งที่จริงแล้วมันบั่นทอนความปลอดภัยด้วยความซับซ้อนที่ไม่จำเป็น ความคลุมเครือของที่อยู่ และอื่น ๆ

    • Azure ก็ลอกสิ่งนี้ไปทั้งชุด
      มีผลิตภัณฑ์อย่าง “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN” ออกมามากจนแทบนับไม่ไหว และทั้งหมดมีไว้เพื่อใช้งาน IPv4 ในระดับใหญ่
      ถ้าทำให้ IPv6 ใช้งานได้จริง ผลิตภัณฑ์พวกนี้จะไม่จำเป็นแม้แต่ตัวเดียวอย่างแท้จริง
      แต่ Azure กลับทำ NAT กับ IPv6 ด้วย ดังนั้นจึงใช้ IPv6 เพื่อหลีกเลี่ยง NAT ที่ถูกบังคับเพราะ IPv4 ไม่ได้ ในปี 2023 ก็ยังออกผลิตภัณฑ์ใหม่ที่ไม่รองรับ IPv6 และมีแนวโน้มสูงว่าจะเป็นแบบนั้นต่อไป
      ในเอกสารยังมีข้อจำกัดเหลืออยู่เต็มหนึ่งหน้า: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      ถ้าลองคิดว่านี่เป็นการเปลี่ยนผ่านจาก IPX ไป IPv4 จะเห็นว่ามันไร้เหตุผลแค่ไหน เหมือนในหน้านี้เขียนว่า “ข้อจำกัดของ IPv4: VM ทุกเครื่องต้องมีที่อยู่ IPX อย่างน้อยหนึ่งรายการ”
      ฟังดูแปลกไหม? ในปี 1999 ลูกค้ากำลังถูกย้ายจาก IPX ไป IPv4 และการรองรับ IPv6 ก็เริ่มปรากฏราวปี 2001–2003 ผ่านมาหลายสิบปีแล้ว แต่ยังให้ความรู้สึกเหมือนยุคก่อนย้ายจาก Novell NetWare ที่บอกว่า “ยังไม่ใช่ทุกอย่างรองรับ IPv4 ดังนั้นจึงต้องใช้ IPX+IPv4”
      รายการนี้ไม่ใช่ข้อจำกัดทั้งหมดอย่างแน่นอน ผลิตภัณฑ์ PaaS ส่วนใหญ่ไม่รองรับ IPv6 ดังนั้นโซลูชันแบบ IaaS+PaaS จึงลงเอยด้วยการต้องใช้ IPv4 เป็นส่วนใหญ่
    • ไม่ใช่ปัญหาของ AWS อย่างเดียว Microsoft, ผู้ตรวจสอบความปลอดภัย, penetration tester, บริษัทประกันไซเบอร์ ฯลฯ โดยทั่วไปก็เรียกร้องว่าอย่าวาง endpoint ที่สามารถกำหนดที่อยู่สาธารณะได้
      ผมไม่เข้าใจว่าทำไม แต่จนกว่าบริษัทเทคโนโลยีรายใหญ่สักแห่งจะผลักดันการกำหนดที่อยู่แบบ end-to-end ให้เป็น best practice ก็จำเป็นต้องทำตามความเชื่อเดิมเพื่อไม่ให้เกิดสัญญาณอันตราย
    • ผมทำงานที่ Azure และจากประสบการณ์ของผม ลูกค้าต้องการสิ่งนี้ และก็มีเหตุผลที่สมควร
      ลูกค้าต้องการ เครือข่ายส่วนตัว ของตัวเองเพื่อป้องกันการบุกรุกและข้อมูลรั่วไหล แม้บนเครื่องที่ตนไม่ได้เป็นเจ้าของ ยิ่งไปกว่านั้นยังอยากนำบริการ PaaS แบบครบเครื่องเข้าไปไว้ในเครือข่ายนั้นด้วย
    • ผมไม่มั่นใจว่าสองเรื่องนี้เกี่ยวข้องกัน ถ้า AWS ต้องการ ก็สามารถโปรโมตได้ว่า IPv6 เป็นยาครอบจักรวาลที่แก้ปัญหาเครือข่ายภายในทั้งหมด และถ้ามันใช้งานได้จริง คู่แข่งก็คงไล่ตามได้ยาก
      ผมเดาว่าเหตุผลน่าจะธรรมดากว่านั้น เมื่อคำนึงถึงจำนวนบริการของ AWS แล้ว การรองรับ IPv4 มันง่ายกว่าเฉย ๆ
    • ผมไม่เห็นว่าการปิดกั้นการเข้าถึงจากภายนอกไปยังบริการภายในจะบั่นทอนความปลอดภัยได้อย่างไร

  • ในฐานะลูกค้า AWS ผมอยากหลุดพ้นจากเรื่อง IP ไปเลย การดูแลระบบเครือข่ายที่ซับซ้อนซึ่งประกอบด้วยโปรโตคอลเก่า ๆ อย่าง IP, BGP, DNS เป็นเรื่องเสียเวลา
    แค่ผูก ตัวตนที่แข็งแรง เข้ากับ workload แล้วให้กำหนดเป็นนโยบายได้ว่า workload ไหนรับส่งข้อมูลกับ workload ไหนได้ก็พอ
    ข้อมูลจะเดินทางจาก workload หนึ่งไปอีก workload หนึ่งอย่างไรไม่ควรเป็นเรื่องที่ผมต้องสนใจ แค่ทำให้มันใช้งานได้ก็พอ

    • เห็นด้วยเต็มที่ อนึ่ง ด้วยความรู้สึกแบบนี้ช่วงนี้จึงมี “แพลตฟอร์ม” คลาวด์จำนวนมากเกิดขึ้นเพื่อทำเรื่องแบบนั้นให้
      แทนที่จะจมอยู่กับ สวนสัตว์ขององค์ประกอบ เครือข่ายจำลอง หรือก็คือดาต้าเซ็นเตอร์เสมือนจริง ก็抽象มันทั้งหมดออกไปเลย
    • ความรู้สึกนั้นสมเหตุสมผล แต่ข้ออ้างแบบนี้คล้ายกับตรรกะที่คนใช้เวลาพูดถึงโซลูชัน low-code
      ในความเป็นจริงมันไม่เคยทำงานได้ดีจริง ๆ เลย และต่อไปก็ไม่น่าจะทำได้ มี nuance และรายละเอียดที่ต้องพิจารณามากเกินไปหากต้องรันและปรับแต่ง workload จริง
    • “คนที่มองภาพใหญ่” ก็จะหันมาสนใจ รายละเอียด ทันทีเมื่อภาพใหญ่นั้นแก้รายละเอียดไม่ได้
    • หมายถึงอะไรแบบ Heroku หรือเปล่า? ไม่ได้ใช้ Heroku มาหลายปีแล้ว เลยไม่รู้ว่าสภาพตอนนี้เป็นอย่างไร
    • คืออยากได้อินเทอร์เน็ตโดยไม่มี Internet Protocol เหรอ?

  • จากประสบการณ์ของผม ปัญหาใหญ่ที่สุดเมื่อจะไปเป็น IPv6-only บน AWS คือ GitHub ยังใช้ IPv6 ไม่ได้ ซอฟต์แวร์จำนวนมากตั้งสมมติฐานไว้ว่าจะเชื่อมต่อ GitHub เพื่อดาวน์โหลดอะไรบางอย่างได้
    จะใช้บริการ NAT64 สาธารณะก็ได้ แต่สำหรับงานจริงจังมันไม่น่าเชื่อถือเท่าไร: https://nat64.xyz/
    AWS คิดค่า traffic ผ่าน NAT gateway แพงมาก และผมก็ไม่รู้ว่าสามารถตั้งค่าให้ดักเฉพาะ traffic ที่จะไปยังโฮสต์ IPv4-only ได้หรือไม่ ถ้าผมเข้าใจผิดก็ช่วยบอกด้วย
    นอกเหนือจากนี้ การใช้ IPv6-only บน AWS ทำงานได้ไร้ที่ติและถูกกว่า egress gateway สำหรับ private network ฟรี แน่นอนว่าต้องมีเงื่อนไขว่าไม่ต้องสนใจ IPv4

    • น่าเสียดายที่ GitHub ตามกระแส การ deploy IPv6 ของ Microsoft ซึ่งเป็นบริษัทแม่ไม่ทัน
    • ถ้าใช้เครือข่าย dual-stack บน AWS ใน DNS ก็จะ prefer IPv6 แต่ IPv4 ก็ยังทำงานอยู่ไม่ใช่หรือ? ผมตั้งค่าของส่วนใหญ่ที่ต้องการ egress อินเทอร์เน็ตทั่วไปไว้แบบนั้น

  • ผมคิดว่าปัญหาจริง ๆ คือ Lambda และ S3 ไม่รองรับ IPv6 และ AWS ควรทำให้บริการเหล่านี้เป็น dual-stack และเข้าถึงผ่าน IPv6 ได้ก่อน แล้วค่อยเปลี่ยนราคา
    ในเชิงเทคนิค S3 มี dual-stack endpoint แยกต่างหากก็จริง แต่ไม่ได้ช่วยมากนัก เพราะอย่างไรก็ต้องเปลี่ยนการตั้งค่าแอปพลิเคชันเพื่อรับมือกับการเปลี่ยนแปลงนี้อยู่ดี

  • เหตุผลครึ่งหนึ่งที่ AWS นำหน้าเรื่องการรองรับ IPv6 ตั้งแต่แรก เป็นเพราะ ข้อบังคับเชิงนโยบาย ของรัฐบาลสหรัฐฯ ที่สั่งให้เริ่มย้าย
    ในมุมต้นทุนก็จริงที่ค่าใช้จ่ายใหม่เป็นเรื่องเล็กน้อยสำหรับลูกค้ารายใหญ่ แต่อย่าประเมินพลังของข้อบังคับเชิงนโยบายของลูกค้ารายใหญ่ที่สุดต่ำเกินไป แค่การขู่ว่าจะสร้างทางเลือกของตัวเองเพื่อให้เป็นไปตามนโยบาย ก็อาจทำให้ AWS ต้องยกระดับความสำคัญของการรองรับในที่สุด

    • ใช่ เป็นความคิดที่ผมไม่ค่อยชอบนัก แต่ดูเหมือนว่าวิธีอื่น ๆ ในการส่งเสริม IPv6 ฝั่ง “เซิร์ฟเวอร์” จะยิ่งเหลือน้อยลงเรื่อย ๆ
      ฝั่ง client หรือฝั่งผู้ใช้ปลายทางดูเหมือนจะไปได้ดี เห็นได้จากที่ Google รายงานว่า traffic IPv6 ของผู้ใช้ปลายทาง ตอนนี้เกือบ 50%

  • โดยส่วนตัว สิ่งที่แย่ที่สุดคือ CloudFront ไม่รองรับ IPv6 ของ custom origin
    ถ้ารันคอนเทนเนอร์ Fargate แยกเป็น origin จำนวนมาก ก็ต้องเปิด public IPv4 address และอีกไม่นานต้นทุนของคอนเทนเนอร์เล็ก ๆ จะเพิ่มเป็นสองเท่า
    Amazon ควรทำให้โครงสร้างพื้นฐานของตัวเองรองรับ IPv6 ได้จริงก่อนจะคิดค่าธรรมเนียมเพิ่มสำหรับการใช้ IPv4 แบบ legacy

    • ใช่ แปลกที่เรื่องนี้เจ็บที่สุด
      ผมเข้าใจว่า Amazon สร้างสัตว์ประหลาดขนาดมหึมาขึ้นมา และการ deploy IPv6 ทั่วทั้งบริการจำนวนมากเป็นงานใหญ่มาก แต่ผมไม่เห็นเหตุผลที่ CloudFront จะยังไม่รองรับ IPv6 origin ตั้งแต่เมื่อวานแล้วด้วยซ้ำ ไม่ใช่แค่ตอนนี้
      มันก็ดูไม่ได้ยากขนาดนั้นเมื่อเทียบกัน และยังอาจเป็นเครื่องมือที่ดีในการอ้อมข้อจำกัดอื่น ๆ ได้ด้วย
      พูดตรง ๆ จนถึงตอนนี้ผมยังรู้สึกว่าการตัดสินใจของ Amazon สุดท้ายแล้วคำนึงถึงผลประโยชน์สูงสุดของลูกค้า แต่ตอนนี้ไม่รู้สึกแบบนั้นแล้ว และมองว่าเป็นสัญญาณไม่ดีต่อไปข้างหน้า

  • ถ้าสหรัฐฯ มี การแข่งขันของ ISP จริง ๆ ก็คงช่วยได้มาก
    ที่ที่ผมเช่าอยู่เป็นชานเมืองใกล้ Seattle แต่มี ISP บรอดแบนด์จริง ๆ แค่เจ้าเดียว ตามนิยามไหนก็ไม่ใช่ชนบท แต่ Comcast เป็นตัวเลือกเดียว ราคาและบริการก็สะท้อนความจริงนั้นอย่างชัดเจน

    • ต้องขอบคุณ การล็อบบี้ ไม่รู้จบที่ทำให้การผูกขาดโดยบังคับตามกฎหมายในวงการนี้เกิดขึ้นได้ พวกบริษัทโทรศัพท์ก็ทำแบบเดียวกัน
      ไม่ใช่ว่าบังเอิญ “มีแค่ Comcast” แต่เป็น “มีแค่ Comcast” เพราะกฎระเบียบทางกฎหมาย
    • Comcast รองรับ IPv6 ไปถึง อัตรารองรับ IPv6 98% ในปี 2016 แล้ว
    • ผู้บริโภคไม่รู้จักและไม่สนใจ IPv6 ดังนั้นการแข่งขันจึงไม่สามารถผลักดันให้ ISP implement ได้
      ที่การบ่น Comcast น่าสนุกคือ ตอนผมใช้ Comcast ผมมี IPv6 native แต่ผู้ให้บริการที่ใช้อยู่ตอนนี้มีแค่ IPv6 ผ่าน NAT46
    • Starlink อาจเป็นอีกตัวเลือกหนึ่งได้
      แม้จะมีข้อเสียอย่างประสิทธิภาพตกตอนฝนตกหนัก แต่ผมก็เห็นรีวิวเชิงบวกอยู่บ้าง
    • การนำ IPv6 มาใช้จะยิ่งผลักลูกค้าไปหาผู้ผูกขาดรายใหญ่ เพราะมีแต่พวกเขาที่รับภาระ ทีมวิศวกรรมเครือข่ายเฉพาะทาง เพื่อทำให้มันทำงานได้เสถียรได้
      คนส่วนใหญ่ไม่รู้ว่าตอนนี้มีอินเทอร์เน็ต IPv6 อยู่สองฝั่ง คือฝั่ง Cogent กับฝั่ง Hurricane Electric ทั้งสองมีขนาดใกล้เคียงกันและปฏิเสธที่จะเชื่อมต่อกัน ดังนั้นต้องรู้เรื่องนี้แล้วซื้อ transit จากทั้งสองฝั่ง หรือซื้อจากเครือข่ายที่ซื้อ transit จากทั้งสองฝั่ง
      ผู้ให้บริการรายใหญ่อย่างน้อยหนึ่งรายที่ผมรู้จักยังรัน v6 บน tunnel อยู่ ในหลายที่ traffic v6 วิ่งผ่านเส้นทางที่ไม่ optimal และเครือข่ายองค์กรอาจมีการเชื่อมต่อ v4 ที่แต่ละดาต้าเซ็นเตอร์ แต่ v6 กลับถูกส่งทั้งหมดไปยัง “กล่องใบนั้นใต้โต๊ะของ Dave” เพียงจุดเดียว
      ถึงอย่างนั้น พวกเขาก็วัดอัตราการนำ v6 ไปใช้จากที่อย่าง Google หรือ Cloudflare ซึ่งมีทีมเฉพาะคอยรับประกันว่า packet จะไปถึง แล้วก็ตบหลังชมตัวเอง

  • สำนวนที่ว่า “ไม่สามารถหลุดพ้นจาก IPv4 ได้” ถือว่าเหมาะสมแล้ว แม้จะสร้าง VPC แบบ IPv6-only ได้ แต่มีหลายอย่างเสียหายมากเกินไป ตั้งแต่บริการต่าง ๆ ของ AWS ไปจนถึง repository ของแพ็กเกจ: https://blog.devopstom.com/ipv6-only-ec2/
    ท้ายที่สุดก็ต้องเปิด IPv4 หรือรัน NAT64 gateway เอง หรือไม่ก็ต้องเชื่อใจ NAT64 ที่มีคนอื่นดำเนินการให้: https://nat64.net และ http://v4-frontend.netiter.com

  • คำกล่าวที่ว่า “ใน IPv6 ไม่มีแนวคิดเรื่องที่อยู่ส่วนตัว จึงบอกลา Managed NAT Gateway กับราคาสุดอลังการของมันได้” อาจจริงใน AWS แต่ใน IPv6 มี Unique Local IPv6 address ในช่วง fc00::/7 และถ้ารัก NAT จริง ๆ ก็ยังมี NAT66 ด้วย

    • ถูกต้อง หมายถึง AWS และควรทำให้ชัดเจนกว่านั้น
      อย่างไรก็ตาม ULA มักไม่ค่อยถูกแนะนำให้ใช้ และ NAT66 นั้น… แค่ไม่ควรทำ
      จากที่ได้ยินมาเมื่อไม่นานนี้ Microsoft ทำให้ IPv6 ของ Azure ทั้งหมดเป็นแบบ เน้น NAT เป็นศูนย์กลาง ว่ากันตรง ๆ คือแปลกมาก