Các khái niệm mạng AWS bằng sơ đồ
(miparnisariblog.wordpress.com)- Để hiểu các mục phức tạp trong bảng điều khiển AWS VPC, tác giả đã tạo một sơ đồ tư duy giúp nhìn quan hệ giữa các tài nguyên mạng AWS trong một cái nhìn tổng thể
- Tác giả sử dụng AWS Networking Fundamentals của Toni Pasanen làm tài liệu tham khảo chính, và sắp xếp các tài nguyên liên quan đến mạng xoay quanh cấu trúc kết nối
- Lý do mạng AWS trở nên phức tạp là vì có nhiều loại kết nối khác nhau, bao gồm kết nối tài khoản-on-premise, tài khoản-tài khoản, VPC-VPC, subnet-subnet, VPC-Internet và VPC-dịch vụ AWS
- Kết quả là một sơ đồ tư duy nối các thành phần mạng AWS với nhau, đồng thời có thể xem cả bản gốc trên Lucidchart
- Các lập trình viên đang bắt đầu hệ thống hóa mạng AWS có thể dùng nó để nắm bắt trực quan các tài nguyên được liên kết với nhau theo quan hệ nào
Sự bối rối bắt đầu từ bảng điều khiển VPC
- Trước tháng 3 năm 2023, tác giả thấy rất khó hiểu chuyện gì đang diễn ra trong bảng điều khiển AWS VPC
- Có quá nhiều mục đến mức thanh cuộn ở panel bên trái rất dài, nên khó nắm được mỗi tài nguyên được kết nối với nhau như thế nào
Tài liệu tham khảo và hướng hệ thống hóa
- Để hiểu nhiều tài nguyên tham gia vào mạng AWS, tác giả đã đọc phần lớn cuốn AWS Networking Fundamentals của Toni Pasanen
- Sau khi đọc sách, tác giả rút ra rằng lý do có nhiều tài nguyên mạng AWS là vì số lượng cách kết nối khả dĩ rất lớn
Các loại kết nối được xử lý trong mạng AWS
- Mạng AWS bao gồm nhiều loại kết nối khác nhau
- Kết nối giữa tài khoản AWS và on-premise
- Kết nối giữa tài khoản với tài khoản
- Kết nối giữa VPC với VPC
- Kết nối giữa subnet với subnet
- Kết nối giữa VPC với Internet
- Kết nối giữa VPC với các dịch vụ AWS cụ thể
Kết quả sơ đồ tư duy
- Để nối các mảnh ghép lại với nhau, tác giả đã tạo một sơ đồ tư duy về các khái niệm mạng AWS
- Có thể xem bản gốc có thể chỉnh sửa tại liên kết Lucidchart
- Tác giả mong nhận được phản hồi về việc nó có hữu ích hay không và có lỗi nào không
1 bình luận
Ý kiến trên Hacker News
Không hiểu vì sao việc debug chính sách IAM và các vấn đề xác thực trên AWS lại tệ đến vậy
Nếu muốn trở thành đối thủ cạnh tranh, đây là chỗ cần tập trung. Tôi đã mất hàng giờ chỉ để tìm nguyên nhân lỗi thiếu quyền, vậy mà tài liệu chính thức lại bảo phải tự lần mò thủ công qua khoảng 8 loại chính sách có thể áp dụng như SCP, IAM, chính sách tài nguyên, v.v.
Cuối cùng ngay cả khi tìm được tài liệu dùng Athena và CloudTrail thì một nửa request vẫn biến mất không rõ lý do, và dù thông báo lỗi có request ID thì cũng không thể tra cứu dễ dàng bằng nó. Phải cho phép tra cứu trực tiếp bằng request ID để hiển thị rõ chính sách nào đã từ chối
Từ đầu đến cuối đúng là một mớ hỗn độn, và cũng có cảm giác họ giữ nguyên tình trạng này để bán thêm hợp đồng hỗ trợ
Với các dự án cá nhân, trừ vài trường hợp rất hiếm, tôi gần như luôn chọn phương án khác cho giá trị tốt hơn. Khoảng 10 năm trước AWS được bán kiểu “chúng tôi quản lý hệ thống nên hãy sa thải hết quản trị viên hệ thống”, nhưng giờ thì kỹ sư AWS DevOps giỏi vừa đắt vừa khó tìm, mà nhất là với các cấu hình lớn, nếu thực sự làm đúng theo khuyến nghị của AWS thì chi phí còn đội lên khủng khiếp
Khi cấp quyền cho function app truy cập cơ sở dữ liệu SQL, tôi chỉ cần dùng đúng tên thật của function app, còn nếu có bí danh thì chỉ cần giới hạn bằng object identifier. Không còn cần mật khẩu hay chứng chỉ gì nữa, cứ thế là chạy
Nếu dùng cùng các thứ như gói xác thực và Application Insights thì, miễn là bạn biết cách đọc log, hầu như không bị kẹt quá lâu với câu hỏi “rốt cuộc chuyện gì đang xảy ra vậy”
Dù vậy Azure cũng đòi hỏi bạn phải biết trước các bãi mìn nằm ở đâu, không biết thì vẫn sẽ rơi vào kiểu bực bội tương tự. Microsoft để lại gợi ý về vị trí bãi mìn tốt hơn AWS rất nhiều, nhưng một số gợi ý lại conveniently biến mất đến mức bạn cần một phù thủy với 20 năm kinh nghiệm mới xuyên qua được bức màn cuối cùng và tránh để chi phí cùng độ phức tạp phình lên gấp 5~10 lần
Việc debug service account còn khó hơn vì đôi khi phải khởi động lại máy hoặc cụm. Sẽ rất tuyệt nếu có một công cụ kiểu “cloud traceroute” chỉ ra chính xác vấn đề nằm ở đâu
Nói công bằng thì vẫn có vài công cụ cho đặc quyền tối thiểu mà tôi chưa dùng thử: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
Thực sự rất khó chịu, và lẽ ra họ phải để UX designer và kỹ sư cùng thiết kế, nhưng lại không làm vậy
Nếu dịch vụ như vậy được cung cấp cho khách hàng thì về mặt tiềm năng cũng có thể bị cung cấp cho kẻ tấn công, và thực tế còn có thể vi phạm chính sách bảo mật·tuân thủ của một số công ty
Dù vậy, tôi vẫn nghĩ nên cho phép khách hàng chọn nếu họ ký vào tài liệu chấp nhận rủi ro lớn, kiểu như “thực hiện việc nguy hiểm bằng người dùng root của AWS”
Vì các request của AWS vốn đã phân tán đến mức đó, về mặt khái niệm thì một cấu trúc giống GraphQL có vẻ hợp với kiểu hệ thống này. Nó cũng không quá xa với các hệ thống truy vết như OTEL
Vì vậy tôi ghét việc phải đụng đến AWS. Học thứ này không phải là kiến thức kỹ thuật mà là kiến thức về sản phẩm
Tôi đã đọc và nắm vững toàn bộ bộ sách TCP/IP Illustrated từ đầu đến cuối, và kiến thức đó hữu ích suốt hàng chục năm
Trong khi đó, kiến thức về AWS tuy tự nó cũng phức tạp nhưng lại luôn khiến tôi không muốn học. Nhìn vào sơ đồ này, nếu mục tiêu là đơn giản hóa thì tôi không rõ họ đã thành công đến mức nào
Ví dụ, nếu mục tiêu là để khách hàng doanh nghiệp tái tạo mạng doanh nghiệp ảo hoặc mạng trung tâm dữ liệu ảo, thì những thứ đó phức tạp hơn stack TCP của máy khách rất nhiều
Với nhu cầu đơn giản thì mặc định cũng đơn giản. Với các trường hợp phức tạp, đúng là cần kiến thức sản phẩm riêng của AWS, nhưng phần lớn các khái niệm nền tảng đều được chia sẻ với cloud khác hoặc mạng on-premise. Nó giống như học ngôn ngữ lập trình thứ N vậy
TCP/IP là kiến thức hữu ích cho lập trình viên mạng. Trong các môn học mạng ở đại học, chúng tôi làm việc với network, subnet, bảng định tuyến, các giao thức định tuyến như RIP·OSPF·BGP, NAT... trên thiết bị thực tế, và vì được Cisco tài trợ nhiều nên đến cuối kỳ gần như đạt mức chứng chỉ CCNA
Chúng tôi cũng học nhiều “kiến thức sản phẩm” như cách sản phẩm Cisco hoạt động, nhưng phần lớn đã quên, còn các khái niệm cốt lõi thì chuyển sang Azure, AWS, GCP rất tốt. VPC trên cloud là bản đối ứng ảo của mạng thực, giống như máy ảo là bản đối ứng của máy thật
Đặc biệt NAT thực sự làm mọi người bối rối. Cơ bản hơn nữa là nhiều kỹ sư còn thấy ký pháp CIDR hay bản thân TCP cũng khó. Ví dụ, họ nghĩ
send()sẽ gửi buffer đã truyền như một đơn vị duy nhất, hoặcrecv()lúc nào cũng nhận được một “thông điệp” hoàn chỉnh. Nhiều người cũng hay nhầm lẫn giữa timeout kết nối và việc peer resetTuy vậy, tôi vẫn mong là không cần phải có loại kiến thức này. IPv6 làm mạng đủ lớn để loại bỏ phần lớn việc như lập kế hoạch kích thước subnet. NAT có thể biến mất xuống địa ngục băng giá cũng được. VPN thì tôi cũng chẳng muốn thấy lại nữa, cứ dùng TLS là được. Tôi cũng muốn loại bỏ tường lửa cloud dùng địa chỉ IP như thể đó là cơ chế xác thực, cùng những lỗi dễ gây hiểu nhầm phát sinh từ đó. Azure ở phần này thật khủng khiếp
Giống nhiều phần mềm chuyên dụng khác, ban đầu nó đơn giản vì nhu cầu, nhưng theo thời gian thì trở nên phức tạp, và AWS phình to rất nhanh nhờ sức hấp dẫn của dịch vụ hạ tầng fully managed theo nhu cầu cùng lượng tài nguyên mà Amazon đổ vào
Giá trị của việc không phải trực tiếp xử lý phần cứng vẫn rất lớn, nhưng ngoài mức giá niêm yết, rõ ràng còn phải trả cái giá là kiến thức riêng của nhà cung cấp rất khó di chuyển
Thay vào đó lại có đầy những khái niệm dùng một lần như “internet gateway”, “NAT gateway”, “egress only internet gateway”, “transit gateway”. Cuối cùng có lẽ sẽ xuất hiện cả một thế hệ kỹ sư chỉ hiểu “cloud” mà không biết nó thực sự vận hành như thế nào
Chỉ cần giao toàn bộ các thành phần “không tạo khác biệt” đó cho AWS, rồi tập trung vào công việc kinh doanh mà họ làm giỏi
Nếu chỉ cung cấp địa chỉ toàn cục thông thường và tường lửa thì phần lớn sự phức tạp này đã biến mất
Chúng ta rất dễ quên Internet ở cấp IP dùng để làm gì, và kiến trúc đầu-cuối giải quyết vấn đề gì
Điều AWS dạy là mạng “Well-Architected™” thực ra gần với một kiểu sùng bái hình thức sinh lợi hơn, và nó dẫn đến sự phức tạp, mê cung các mạng 10.x na ná nhau, xung đột địa chỉ, những proxy chắp vá khi cố cho chúng giao tiếp với nhau, mức độ bảo mật thực tế thấp hơn, và sự phụ thuộc vào nhà cung cấp. Sự phức tạp là kẻ thù của bảo mật
Các quản trị viên hệ thống ngày xưa đâu có chỉ nhận một nửa hay một phần tư mức lương của tôi, và thông thường một người có thể quản lý phần cứng cho 100 lập trình viên. Nghĩa là overhead để phần còn lại tránh phải mở rộng phạm vi như vậy và tránh tổn thương não bộ chỉ vào khoảng 0,5%
Trên AWS, theo đúng nghĩa đen, cái chết của chuyên môn lại đang diễn ra lần nữa
Và địa chỉ toàn cục cùng tường lửa về cơ bản chẳng phải cũng có thể làm được bằng cách tạo VPC chỉ có public subnet và dùng security group như tường lửa sao. Best practice là subnet public/private và NAT gateway, nhưng có vẻ cũng không hẳn là không thể chỉ dựa vào security group
Cái đó cũng nằm sau địa chỉ IP anycast toàn cục
Vì thế mới phát sinh rất nhiều sự phức tạp không cần thiết mà chúng ta thấy trong mạng cloud
Có vẻ sơ đồ tư duy này có thể được đơn giản hóa hơn nữa bằng một vài khái niệm mạng
Khi đó phần lớn các mối quan hệ và mũi tên sẽ biến mất, và các khái niệm của AWS cũng có thể được ánh xạ sang các cloud khác hoặc cả mạng gia đình
https://news.ycombinator.com/item?id=18925350 là một tài liệu trực quan hóa phần căn bản rất tốt. Nếu bắt đầu từ việc mạng là gì, đâu là bên trong và đâu là bên ngoài, thì mô hình tư duy sẽ dễ hơn nhiều, và các tính năng AWS cũng khá hợp lý ngay cả khi không biết hết mọi chi tiết
Kết quả là đã tóm lược một hệ thống phức tạp theo cách rõ ràng và súc tích. Đây là tài liệu mà lần tới khi phải lần mò trong khu rừng AWS tôi sẽ tham khảo
Ví dụ, subnet nằm trong hình chữ nhật Availability Zone, bên ngoài là VPC, rồi hình chữ nhật đó lại nằm trong region. Đại khái là như vậy, chỉ là được vẽ đẹp hơn: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
Tôi nhớ những ngày hào hứng đầu thời cloud, khi networking của AWS còn đơn giản
Nhưng tôi cũng biết kiểu gì rồi chuyện này cũng sẽ đến. Muốn trở thành mọi thứ cho mọi người thì cuối cùng không tránh khỏi việc sao chép sự điên rồ của networking trung tâm dữ liệu IPv4 kiểu legacy
Gần đây tôi đã cố làm một việc về mặt khái niệm khá đơn giản trên Azure: không để một storage account chứa backup cơ sở dữ liệu bị lộ ra Internet để ai cũng có thể chọc vào
Tôi tưởng chỉ cần bật firewall lên là xong, nhưng danh sách cho phép chỉ nhận subnet, và còn phải thêm từng subnet riêng lẻ. Không được dùng virtual network, cũng không có kiểu “mọi virtual network của tôi” như ở nơi khác vốn vẫn hoạt động
Cũng có tính năng Private Endpoint, nhưng nó làm giảm hiệu năng và tốn thêm chi phí. Chắc việc đổi một địa chỉ từ “public” sang “private” trong thiết lập mạng định nghĩa bằng phần mềm quá vất vả, nên phải trả công cho các tiên cloud
Nhưng rồi trên thực tế nó lại không chạy. Phải ghi đè DNS để client tìm được, mà khi gắn vào domain AD thì các dịch vụ PaaS lại không truy cập được
Cuối cùng tôi phải tạo một private DNS zone cũng tốn thêm tiền, kết nối nó vào hub network, rồi gắn thêm dịch vụ DNS Resolver cũng tốn tiền, và thiết lập cả đống rule để AD domain tiếp tục hoạt động, thế là trôi mất một tuần
Ban đầu tôi chỉ muốn nếu storage key bị lộ thì hacker Nga cũng không thể truy cập được vào backup thôi. Có khi tuần sau tôi sẽ cập nhật template subscription để triển khai lại virtual network với cấu hình DNS đã được làm mới. Không idempotent à? Biết đâu sang năm sẽ có bản preview
Sau đó, với phần cần public thì dùng public gateway hoặc Front Door là được. Tôi không thích, nhưng cũng không phải là trước đây nó chưa từng cực kỳ phức tạp. Chỉ là giờ đây các nhà phát triển phải tiếp xúc nhiều hơn với mớ hỗn loạn điên rồ của enterprise networking, vốn trước kia gần như hoàn toàn là việc của đội vận hành
Tôi gọi phần cấu hình DNS là phép thuật vì đó là chỗ tôi không tự tay đụng vào. Đặc biệt nếu dùng App Service và nhiều subscription thì không thể chia sẻ subnet, và nếu dùng app slot thì phải tính trước để không bị thiếu không gian địa chỉ IP
Điều tôi không hiểu ở Azure là tại sao mặc định cho môi trường doanh nghiệp lại không phải là “không cái gì ở trên Internet cả”. Khi nào cần đưa ra Internet thì hãy mở ra. Dù sao muốn public cũng vốn đã phức tạp vì còn phải cấu hình load balancer và nhiều thứ khác
Ít nhất với thiết lập doanh nghiệp thì mặc định phải là nằm ngoài Internet. Có lẽ Microsoft bán chứng chỉ Azure nên phải làm cho nó khó, nhưng tôi không hiểu tại sao đến năm 2023 vẫn phải lo lắng về độ phức tạp này ngay từ mặc định. Việc có thể tùy biến rất sâu thì không sao
Tài liệu này rất tuyệt. Tôi luôn cảm thấy tài liệu của Google Cloud thường giới thiệu khá tốt mức độ phức tạp này mỗi khi cần, nhưng tôi chưa từng thấy một cái nhìn tổng quan hoàn chỉnh như thế này
Chỉ có điều để xem được ảnh thì phải khá vất vả. Trên trang thì quá nhỏ và không bấm vào được, mở trong tab mới thì dẫn tới một trang vô dụng kiểu imgur và ảnh vẫn nhỏ. Cuối cùng tôi phải tải ảnh xuống mới xem tử tế được
Tài liệu này thật ấn tượng. Nó cho thấy rõ sơ đồ tư duy và biểu đồ mạnh mẽ đến mức nào khi học về sản phẩm cloud hay các khái niệm khác
Khi học chứng chỉ AWS tôi dùng chúng rất nhiều, vì dù có viết ghi chú dài đến đâu thì việc nhìn các dịch vụ được nối với nhau trên một bản đồ vẫn giúp tôi hiểu tốt hơn rất nhiều so với nhìn như một chuỗi trang. Tất nhiên mỗi người có cách học khác nhau
Tôi không chắc mình hiểu hết những lời chỉ trích trong thread này. Phần lớn các hệ thống networking mà AWS cung cấp là thứ bạn dùng khi cần
Có thể không thanh nhã, nhưng chúng làm được việc. Hơn nữa, khá nhiều thành phần riêng của AWS tương ứng trực tiếp với các khái niệm networking ngoài đời thực. AZ là cage, VPC là VLAN, PL thì gần tương đương VPN P2P liên tài khoản
Phần lớn những thứ còn lại cũng chỉ là các thành phần networking thông thường thường thấy trong các môi trường quy mô lớn
Công ty tôi làm việc vận hành một mạng toàn cầu khá phức tạp, kết nối với AWS qua DX tại nhiều PoP. Chúng tôi dùng mọi thứ trong sơ đồ này và mỗi thành phần đều có mục đích được xác định rõ ràng
Nếu sơ đồ này trông quá phức tạp, thì có lẽ là vì bạn không dùng hết số này, hoặc không dùng chúng đúng mục đích thiết kế, hoặc đơn giản là bạn không phải kỹ sư mạng
Có ai thực sự đọc nổi hình này không? Ngay cả trên desktop tôi cũng không thể xem nó ở độ phân giải đủ để đọc
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... vẫn chỉ là một trang web, và dù ảnh lớn hơn thì cũng không dễ đọc hơn
Dù sao nếu lưu xuống thì ít nhất cũng dùng được. Sau đó bạn sẽ cần một màn hình lớn. Kích thước của nó là 7,763 × 4,684 pixel
Trông cực kỳ phức tạp. Trong ba nhà cung cấp đám mây lớn thì tôi chỉ biết GCP; ở đó networking cũng không hẳn là đơn giản, nhưng ít nhất vẫn khá trực quan và nhất quán
Sẽ rất hay nếu ai có kinh nghiệm multi-cloud nhiều hơn có thể so sánh mức độ dễ và khó khi thiết lập giao tiếp nội bộ và bên ngoài theo tiêu chuẩn của big 3
Điều đó cũng không có gì đáng ngạc nhiên, vì phần lớn trong số đó cũng có đối tượng tương ứng trực tiếp ngay trong các tiêu chuẩn networking. Về bản chất, cả hai chỉ là những góc nhìn khác nhau về thế giới software-defined networking