Khách hàng AWS không thể thoát khỏi IPv4
(tty.neveragain.de)- Từ tháng 2/2024, AWS tính phí $0.005 mỗi giờ cho mỗi địa chỉ IPv4 công cộng chuyên dụng, nhưng do các hạn chế của dịch vụ AWS, khách hàng khó tránh chi phí bằng cách chuyển sang IPv6
- Phạm vi tính phí rất rộng, bao gồm Elastic Load Balancer, EC2/Elastic IP, tác vụ ECS Fargate có cấu hình IP công cộng, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway, v.v.
- EC2, VPN, Transit Gateway, Direct Connect, Network Firewall hoạt động trên nền IPv6, nhưng các dịch vụ cốt lõi như API Gateway, Lambda, ECS, App Runner lại từ chối subnet chỉ IPv6 hoặc không hỗ trợ đúng mức
- Ngay cả khi cấu hình nội bộ dạng dual-stack, hơn 90% endpoint API dịch vụ không hỗ trợ IPv6, khiến việc dùng S3, Systems Manager, SQS, v.v. trong VPC mà không có IPv4 công cộng trở nên khó khăn
- Với khách hàng lớn, khoản này thường dưới 1% hóa đơn nên động lực chuyển đổi yếu; còn SMB, người dùng hobby và startup có thể chịu mức tăng chi phí 10–30%, tạo gánh nặng lớn hơn
Từ tháng 2/2024, tính phí IPv4 công cộng chuyên dụng
- Từ tháng 2/2024, AWS tính phí $0.005 mỗi giờ cho mỗi địa chỉ IPv4 công cộng chuyên dụng
- Tương đương gần $4 mỗi tháng, hơn $40 mỗi năm
- Áp dụng cho IP thuộc sở hữu của AWS; các địa chỉ BYOIP mà khách hàng mang theo khối IPv4 công cộng có thể định tuyến sẽ không bị tính phí
- Phạm vi tính phí bao trùm hầu hết các tài nguyên chính trực tiếp dùng IPv4 công cộng
- Elastic Load Balancer
- Dùng 1 địa chỉ cho mỗi Availability Zone
- Cần tối thiểu 2 địa chỉ và không thể tắt IPv4
- EC2 instance và Elastic IP
- Tác vụ ECS Fargate có cấu hình IP công cộng
- IP của Global Accelerator
- IP của Site-to-site VPN
- RDS
- Managed NAT Gateway
- Elastic Load Balancer
- Địa chỉ IPv4 dùng chung được loại trừ
- Các địa chỉ dùng chung được dùng cho phân phối CloudFront hoặc endpoint API Gateway không thuộc diện tính phí
- Địa chỉ IPv4 công cộng do các hàm Lambda ngoài VPC sử dụng cũng được loại trừ
Các cấu hình khiến chi phí tăng mạnh
- Một Elastic Load Balancer công cộng được cấu hình trên 3 Availability Zone sẽ tăng giá cơ bản hơn 50%
- Giá cơ bản của Managed NAT Gateway tăng khoảng 10%
- NAT Gateway không cung cấp tính dư thừa theo Availability Zone
- Nếu kết nối outbound là quan trọng, mỗi Availability Zone cần một NAT Gateway riêng
- Đặc biệt, hai mẫu cấu hình lãng phí nhiều địa chỉ sẽ bị ảnh hưởng lớn
- Cấu hình đặt nhiều Load Balancer trong mỗi VPC
- Thường xảy ra khi kết hợp nhiều template CloudFormation hoặc module Terraform, hoặc khi Kubernetes ingress controller tạo Load Balancer cho từng service
- Một Load Balancer có thể xử lý nhiều URL và service
- Cấu hình cố ý gắn IPv4 công cộng cho EC2 instance và tác vụ Fargate để tránh Managed NAT Gateway
- Trớ trêu là cho đến khi đạt khoảng 10 địa chỉ IPv4 công cộng trên mỗi Availability Zone, cách này vẫn rẻ hơn
- Cấu hình đặt nhiều Load Balancer trong mỗi VPC
Cách kiểm tra mức sử dụng hiện tại
- Mức sử dụng địa chỉ IPv4 công cộng đã được tổng hợp trong tài khoản
- Hiện được hiển thị là $0, nhưng từ tháng 2/2024 sẽ bị tính $0.005 mỗi giờ
- Có thể kiểm tra theo các đường dẫn sau
- Billing Dashboard > Bills
- Hiển thị trong phần Virtual Private Cloud dưới tên
PublicIPv4:InUseAddress
- Hiển thị trong phần Virtual Private Cloud dưới tên
- Cost Explorer
- Có thể lọc chỉ bao gồm
PublicIPv4:InUseAddressđể xem mức sử dụng theo ngày/giờ - Cũng có thể nhóm theo từng member account
- Có thể lọc chỉ bao gồm
- VPC > VPC IP Address Manager > Public IP insights
- Có thể xem tổng quan mức sử dụng IPv4 công cộng
- Phần này của IPAM là miễn phí
- Chỉ hiển thị dữ liệu theo tài khoản và region; dữ liệu không đầy đủ vì không bắt được các địa chỉ chỉ được dùng tạm thời
- Billing Dashboard > Bills
Hai cách triển khai IPv6
- Vì địa chỉ IPv4 bị tính phí còn địa chỉ IPv6 miễn phí, nhìn bên ngoài thì chuyển sang IPv6 có vẻ là lựa chọn tự nhiên
- IPv6 không có khái niệm địa chỉ riêng, nên có thể tránh Managed NAT Gateway và chi phí của nó
- Có hai cách triển khai IPv6 chính
- Dual-stack
- Cấu hình cả địa chỉ IPv4 và IPv6 cho mọi hệ thống
- Nội bộ chỉ IPv6
- Bên trong chỉ dùng IPv6, chỉ cung cấp kết nối IPv4 ở edge hoặc CDN tiếp xúc với người dùng phổ thông
- Dual-stack
- Bản ghi nhớ của Văn phòng Tổng thống Mỹ nêu rõ rằng vận hành dual-stack đã trở nên quá phức tạp và không còn cần thiết để duy trì, đồng thời các tổ chức tiêu chuẩn hóa và những công ty công nghệ lớn đã bắt đầu chuyển sang triển khai chỉ IPv6
- Hỗ trợ mạng IPv6 nền tảng của AWS về cơ bản tương đối đầy đủ
- Có thể cấu hình EC2 instance chỉ IPv6 trong subnet chỉ IPv6
- Các chức năng được kỳ vọng trên mạng IPv6 như DNS cục bộ, dịch vụ thời gian, cấu hình host, bảo mật đều hoạt động
- VPN, Transit Gateway, Direct Connect, Network Firewall cũng hỗ trợ IPv6
IPv6 bị chặn ở bước sử dụng dịch vụ AWS
- Điểm nghẽn không nằm ở bản thân mạng mà xuất hiện ở bước kết nối với các dịch vụ AWS khác
- Các dịch vụ cốt lõi như API Gateway, Lambda, ECS, App Runner từ chối hoặc báo lỗi với cấu hình subnet chỉ IPv6
- Elastic Load Balancer có thể báo lỗi như
Not enough IP space available
- Elastic Load Balancer có thể báo lỗi như
- Cấu hình nội bộ dạng dual-stack cũng chưa đủ
- Nhiều dịch vụ bỏ qua IPv6 dù subnet đã được cấu hình IPv6
- Trong nhiều trường hợp, chúng chỉ có thể kết nối tới đích IPv4
- Có nhiều trường hợp khó hoặc không thể dùng API dịch vụ trong VPC nếu không có địa chỉ IPv4 công cộng
- Chạy
aws s3 lstrên EC2 instance bị thất bại - Systems Manager, cách được khuyến nghị để truy cập và quản lý instance, không hoạt động
- Tác vụ ECS không thể truy cập SQS
- Chạy
- Theo tình trạng hỗ trợ IPv6 của AWS, hơn 90% endpoint API dịch vụ không hỗ trợ IPv6
- SES SMTP và endpoint ECR repository cũng không hoạt động, còn CloudFront không thể kết nối tới origin IPv6
- Không thể khởi chạy tác vụ ECS từ ECR, nhưng có thể từ Docker Hub, nơi hỗ trợ IPv6
- Docker Hub áp dụng rate limit cho pull
PrivateLink là phương án thay thế nhưng bị giới hạn lớn về chi phí
- Nhiều dịch vụ có thể kết nối qua PrivateLink
- Kết nối trực tiếp vào VPC của khách hàng nên không cần địa chỉ IP công cộng
- Không hỗ trợ tất cả dịch vụ
- PrivateLink được tính phí theo từng dịch vụ và từng Availability Zone
- Khoảng $9 mỗi tháng cho mỗi endpoint
- Ví dụ, nếu kết nối Secrets Manager, EC2, SSM, SSM-Messages ở 3 Availability Zone, chi phí sẽ vượt $1.200 mỗi năm cho mỗi VPC
- Còn có thêm phí lưu lượng
Vì sao phí IPv4 khó dẫn đến chuyển đổi sang IPv6
- Với khách hàng có quy mô, phí IPv4 nhìn chung ở mức dưới 1% hóa đơn, nên không được cảm nhận là thay đổi lớn
- Chỉ riêng khoản chi phí này khó tạo ra khoản đầu tư kỹ thuật đáng kể
- Với SMB, người dùng hobby và startup, phí có thể làm hóa đơn tăng tới 10–30%
- Họ có động lực lớn để triển khai IPv6 nhằm tránh chi phí
- Nhưng các khoảng trống trong hỗ trợ IPv6 của dịch vụ AWS khiến cách tránh chi phí IPv4 bị hạn chế
- Xét đến chi phí mua IPv4 gần đây, bản thân việc tính phí địa chỉ IPv4 có thể là cần thiết
- Nếu hỗ trợ IPv6 trên toàn bộ dịch vụ AWS đã trưởng thành hơn, nhiều khách hàng hơn có thể chuyển sang môi trường chỉ IPv6
- Hiện tại, khó có thể xem IPv6 là công dân hạng nhất trên AWS; trong tình huống này, việc tính phí IPv4 khiến việc dùng AWS cho tài khoản cá nhân, học tập, ôn chứng chỉ và hỗ trợ mã nguồn mở trở nên kém hấp dẫn hơn
1 bình luận
Ý kiến trên Hacker News
Từ rất lâu trước, khi tôi còn là lập trình viên junior ở Amazon, từng có một dự án nội bộ quy mô lớn nhằm tách toàn bộ hệ thống nội bộ thành phiên bản theo từng region, và chỉ cho phép các lời gọi giữa các region đi qua những gateway bị giới hạn
Lý do là vì địa chỉ IPv4 nội bộ đã cạn kiệt
Khi được hỏi “sao không chuyển sang IPv6 luôn?”, Principal PM phụ trách đã trả lời kiểu như: “Trong số thiết bị mạng nội bộ hiện có, có quá nhiều thiết bị không hỗ trợ IPv6; nếu muốn thay thế thì gần như phải mua số thiết bị tương đương sản lượng hằng năm của cả thế giới rồi lắp đặt toàn bộ”
Dễ nhìn nhận Amazon như đang hành xử ác ý ở phía IPv4, nhưng xét đến quy mô hệ thống AWS, việc thay toàn bộ phần cứng mạng cũ trong thời gian ngắn cũng hoàn toàn có thể là một dự án quá lớn
Tôi hơi nghi ngờ rằng chuyện đó phần nào là nói nhảm, hoặc ít nhất là một cách “đóng gói” sự thật khá sáng tạo. Chẳng hạn, thực tế có thể mọi thứ đều đã hỗ trợ IPv6, nhưng các kỹ sư mạng đầy sợ hãi, bất định và nghi ngờ không muốn bật nó lên
Phần lớn thiết bị mạng tôi từng thấy đã là dual stack từ rất lâu trước khi xung quanh thực sự dùng IPv6, và tôi luôn nghĩ điều đó là do yêu cầu của chính phủ hoặc quân đội Mỹ
Tôi không nhớ PM của dự án đó là ai, nhưng khi ấy tôi thật sự bắt đầu tôn trọng giá trị mà một TPM có thể tạo ra
Nói rằng chi phí và nhu cầu thay thiết bị mạng là một trong những lý do mạnh khiến họ không đi theo IPv6 là đúng. Amazon dùng thiết bị mạng do họ tự thiết kế và chế tạo vì nhiều lý do, và có lẽ bây giờ vẫn vậy
Tất cả các thiết bị đó đều có dung lượng bộ nhớ cố định, nên để tăng bộ nhớ đủ gánh các bảng định tuyến IPv6 và tương tự thì phải thay thế. Ngay cả nếu chọn chỉ dùng IPv6, phần cứng hiện có cũng không đủ, và dù sao cũng khó qua được nếu không có dual stack IPv4/IPv6
Có vẻ bà ấy luôn làm các dự án quy mô khổng lồ, và IPv4 giờ chỉ là một phần nhỏ trong số đó. Đáng tiếc là tôi không thể chia sẻ vài dự án lớn hiện nay
Bà ấy đã vài lần dành thời gian cho tôi và cho tôi những lời khuyên sáng suốt, tôi rất biết ơn
Chắc chắn họ đã bắt đầu quy trình rồi
Đúng không? Khó tưởng tượng AWS đang vùi đầu xuống cát và phớt lờ chuyện này
Việc AWS cung cấp IPv6 hoạt động đúng có vẻ rõ ràng là đi ngược lại động lực lợi ích của họ. Các công cụ gây ảnh hưởng của AWS, chẳng hạn tiêu chí Well-Architected hay chứng chỉ, thúc đẩy mạnh việc tạo ra một mê cung mạng 10.x RFC1918 được gán địa chỉ mơ hồ, thay vì kiến trúc kiểu Internet có định địa chỉ end-to-end
Trong thế giới các khuyến nghị của AWS, bản thân khái niệm “địa chỉ IP công khai” đã là một tín hiệu cảnh báo, và AWS còn khuyến nghị các công cụ tính thêm phí để hiển thị và “giảm thiểu” những địa chỉ đó
Khi khiến khách hàng bỏ công xây dựng hạ tầng phức tạp dưới danh nghĩa bảo mật, hiệu ứng lock-in sẽ rất mạnh. Dù trên thực tế điều đó làm hại bảo mật vì độ phức tạp không cần thiết, sự mơ hồ về địa chỉ, v.v.
Không đếm nổi đã có bao nhiêu sản phẩm như “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN”, và tất cả đều nhằm vận hành IPv4 ở quy mô lớn
Nếu làm cho IPv6 hoạt động đúng, theo nghĩa đen sẽ không cần đến bất kỳ sản phẩm nào trong số này
Thay vào đó, Azure xử lý cả IPv6 qua NAT, nên bạn cũng không thể dùng IPv6 để tránh NAT vốn bị áp đặt vì IPv4. Ngay cả năm 2023 họ vẫn tung ra sản phẩm mới không hỗ trợ IPv6 và nhiều khả năng sẽ tiếp tục như vậy
Tài liệu vẫn còn nguyên một trang giới hạn: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Hãy thử nghĩ nếu đây là quá trình chuyển đổi từ IPX sang IPv4 thì sẽ vô lý đến mức nào. Chẳng khác nào trên trang này ghi “Giới hạn IPv4: mọi VM phải có ít nhất một địa chỉ IPX”
Nghe kỳ lạ đúng không? Năm 1999, khách hàng đang được chuyển từ IPX sang IPv4, và hỗ trợ IPv6 xuất hiện khoảng năm 2001–2003. Đã nhiều thập kỷ trôi qua mà vẫn có cảm giác như thời trước khi chuyển khỏi Novell NetWare, khi người ta nói “vì chưa phải mọi thứ đều hỗ trợ IPv4 nên cần IPX+IPv4”
Danh sách này chắc chắn không phải toàn bộ các giới hạn. Phần lớn sản phẩm PaaS không hỗ trợ IPv6, nên các giải pháp IaaS+PaaS rốt cuộc phần lớn vẫn phải dùng IPv4
Tôi không hiểu vì sao, nhưng cho đến khi một công ty công nghệ lớn nào đó thúc đẩy định địa chỉ end-to-end như best practice, chúng ta buộc phải theo quan niệm hiện hành để tránh tạo tín hiệu cảnh báo
Khách hàng muốn có mạng riêng của riêng mình để ngăn xâm nhập và rò rỉ dữ liệu ngay cả trên những máy không thuộc sở hữu của họ. Xa hơn nữa, họ còn muốn đưa cả các dịch vụ PaaS kiểu “đầy đủ pin kèm theo” vào trong mạng đó
Suy đoán của tôi là lý do tầm thường hơn. Tính cả số lượng dịch vụ của AWS, hỗ trợ IPv4 đơn giản là dễ hơn
Là khách hàng AWS, tôi muốn thoát khỏi chính IP. Quản lý một hệ thống mạng phức tạp được tạo nên từ các giao thức cũ kỹ như IP, BGP, DNS là lãng phí thời gian
Chỉ cần cho phép gắn danh tính mạnh vào workload và áp dụng bằng chính sách rằng workload nào được trao đổi dữ liệu với workload nào
Dữ liệu đi từ workload này sang workload khác như thế nào không nên là điều tôi phải quan tâm; hãy cứ làm cho nó chạy là được
Thay vì sa vào sở thú các thành phần của một trung tâm dữ liệu ảo hóa, tức mạng giả lập, họ trừu tượng hóa hết mọi thứ
Trong thực tế, nó chưa từng hoạt động đúng cách và sau này cũng không thể. Có quá nhiều sắc thái và chi tiết cần cân nhắc để chạy và tối ưu các workload thực tế
Theo trải nghiệm của tôi, vấn đề lớn nhất khi chuyển sang chỉ IPv6 trên AWS là GitHub vẫn chưa hỗ trợ IPv6. Rất nhiều phần mềm mặc định rằng chúng có thể kết nối tới GitHub để tải thứ gì đó
Có thể dùng dịch vụ NAT64 công cộng, nhưng không đáng tin cậy lắm cho mục đích nghiêm túc: https://nat64.xyz/
AWS tính phí cực cao cho lưu lượng NAT gateway, và tôi cũng không biết có thể cấu hình để chỉ chặn lưu lượng đi tới host chỉ hỗ trợ IPv4 hay không. Nếu tôi sai thì mong được chỉ ra
Ngoài chuyện đó, dùng chỉ IPv6 trên AWS hoạt động không chê vào đâu được và rẻ hơn. Egress gateway cho mạng riêng là miễn phí. Tất nhiên, điều kiện là không phải bận tâm đến IPv4
Theo tôi, vấn đề thật sự là Lambda và S3 không hỗ trợ IPv6, và AWS lẽ ra phải làm cho chúng thành dual-stack trước để có thể truy cập bằng IPv6 rồi mới thay đổi giá
Về mặt kỹ thuật, S3 có endpoint dual-stack riêng, nhưng dù sao để ứng phó với thay đổi này vẫn phải đổi cấu hình ứng dụng nên cũng không giúp được nhiều
Ngay từ đầu, một nửa lý do AWS đi trước về hỗ trợ IPv6 là do nghĩa vụ chính sách của chính phủ Mỹ yêu cầu bắt đầu chuyển đổi
Xét về chi phí, đúng là khoản phí mới này không đáng kể với khách hàng lớn, nhưng không nên đánh giá thấp sức nặng của các nghĩa vụ chính sách từ những khách hàng lớn nhất. Chỉ riêng lời đe dọa sẽ tự xây phương án thay thế để tuân thủ chính sách cũng có thể khiến AWS cuối cùng phải nâng mức ưu tiên hỗ trợ
Phía client, tức người dùng cuối, có vẻ đang tiến triển tốt. Nhìn việc Google gần đây báo cáo lưu lượng IPv6 của người dùng cuối gần 50% là thấy
Cá nhân tôi thấy tệ nhất là CloudFront không hỗ trợ IPv6 cho origin tùy chỉnh
Nếu chạy nhiều container Fargate riêng làm origin thì phải bật địa chỉ IPv4 công cộng, và chẳng mấy chốc chi phí cho các container nhỏ sẽ tăng gấp đôi
Amazon nên làm cho hạ tầng của chính họ thực sự hỗ trợ IPv6 trước khi thu thêm phí cho việc dùng IPv4 legacy
Tôi biết Amazon đã tạo ra một con quái vật khổng lồ và việc triển khai IPv6 trên vô số dịch vụ là một công việc khổng lồ, nhưng tôi không thấy có lý do gì để CloudFront không thể hỗ trợ IPv6 origin từ hôm qua, chứ đừng nói là ngay bây giờ
Nó cũng không có vẻ khó đến vậy, và còn có thể là công cụ tốt để обход qua các giới hạn khác
Thành thật mà nói, cho đến giờ tôi vẫn cảm thấy các quyết định của Amazon cuối cùng vẫn tính đến lợi ích tốt nhất của khách hàng, nhưng giờ thì không còn như vậy nữa. Tôi coi đây là tín hiệu xấu cho tương lai
Nếu ở Mỹ thật sự có cạnh tranh ISP thì đã giúp ích rất nhiều
Nơi tôi thuê ở là vùng ngoại ô gần Seattle mà vẫn chỉ có một ISP băng rộng thực sự. Theo bất kỳ định nghĩa nào cũng không phải nông thôn, nhưng Comcast là lựa chọn duy nhất. Giá cả và dịch vụ phản ánh đúng thực tế đó
Không phải tình cờ mà “chỉ có Comcast”, mà là do quy định pháp lý khiến thành “chỉ có Comcast”
Điều thú vị khi phàn nàn về Comcast là khi tôi dùng Comcast thì có IPv6 native. Nhà cung cấp hiện tại của tôi chỉ có IPv6 qua NAT46
Có nhược điểm như suy giảm hiệu năng khi mưa lớn, nhưng tôi đã thấy vài đánh giá tích cực
Hầu hết mọi người không biết rằng Internet IPv6 hiện có hai mạng. Có phía Cogent và phía Hurricane Electric, hai bên có quy mô tương tự và từ chối kết nối với nhau. Vì vậy phải biết điều này và mua transit từ cả hai bên, hoặc mua từ một mạng có mua transit từ cả hai bên
Ít nhất một nhà cung cấp lớn mà tôi biết vẫn đang chạy v6 trên tunnel. Ở nhiều nơi, lưu lượng v6 đi qua các tuyến không tối ưu, và mạng doanh nghiệp có thể có kết nối v4 ở từng trung tâm dữ liệu, nhưng v6 thì bị dồn hết qua “cái hộp dưới bàn của Dave”
Thế mà họ vẫn đo tỷ lệ áp dụng v6 ở những nơi có đội chuyên trách như Google hay Cloudflare đảm bảo gói tin tới nơi, rồi tự vỗ vai khen mình
Cách diễn đạt “không thể thoát khỏi IPv4” là phù hợp. Bạn có thể tạo VPC chỉ dùng IPv6, nhưng quá nhiều thứ sẽ hỏng, từ nhiều dịch vụ AWS cho đến kho lưu trữ gói: https://blog.devopstom.com/ipv6-only-ec2/
Cuối cùng bạn phải bật IPv4, hoặc tự chạy cổng NAT64, hoặc tin tưởng NAT64 do ai đó vận hành: https://nat64.net và http://v4-frontend.netiter.com
Câu “IPv6 không có khái niệm địa chỉ riêng tư, nên hãy tạm biệt Managed NAT Gateway và mức giá hoành tráng của nó” có thể đúng trong AWS, nhưng IPv6 có địa chỉ IPv6 Unique Local thuộc fc00::/7, và nếu bạn thật sự yêu NAT thì cũng có NAT66
Tuy nhiên ULA thường không được khuyến nghị, còn NAT66 thì… đơn giản là không ổn
Gần đây tôi nghe nói Microsoft đã xây dựng toàn bộ IPv6 của Azure theo hướng lấy NAT làm trung tâm. Thật sự kỳ lạ