แนวคิด AWS Networking ในรูปแบบไดอะแกรม

• ผู้เขียนได้สร้างมายด์แมปที่ช่วยให้เห็นความสัมพันธ์ของ AWS Networking resources ได้ในภาพรวม เพื่อทำความเข้าใจรายการที่ซับซ้อนใน AWS VPC Dashboard
• ใช้ AWS Networking Fundamentals ของ Toni Pasanen เป็นแหล่งอ้างอิงหลัก และจัดระเบียบ resources ที่เกี่ยวข้องกับ networking โดยเน้นโครงสร้างการเชื่อมต่อ
• เหตุผลที่ AWS networking ซับซ้อนขึ้นคือมี ประเภทการเชื่อมต่อ ที่หลากหลาย ครอบคลุมการเชื่อมต่อระหว่าง account กับ on-premises, account กับ account, VPC กับ VPC, subnet กับ subnet, VPC กับ internet และ VPC กับ AWS service
• ผลลัพธ์คือ มายด์แมป ที่เชื่อมโยงองค์ประกอบของ AWS networking เข้าด้วยกัน และสามารถดูต้นฉบับ Lucidchart ได้ด้วย
• นักพัฒนาที่เริ่มจัดระเบียบความเข้าใจเกี่ยวกับ AWS networking สามารถใช้เพื่อมองเห็นภาพว่า resources ต่าง ๆ ถูกผูกเข้าด้วยกันด้วยความสัมพันธ์แบบใด

---

ความสับสนที่เริ่มจาก VPC Dashboard

• ก่อนเดือนมีนาคม 2023 ผู้เขียนพบว่ายากที่จะเข้าใจว่าเกิดอะไรขึ้นใน VPC Dashboard ของ AWS
• มีรายการจำนวนมากจนแถบเลื่อนในแผงด้านซ้ายยาวมาก ทำให้ยากที่จะจับภาพว่าแต่ละ resource เชื่อมต่อกันอย่างไร

แหล่งอ้างอิงและแนวทางการจัดระเบียบ

• เพื่อทำความเข้าใจ resources หลายประเภทที่เกี่ยวข้องกับ AWS networking ผู้เขียนอ่านหนังสือ AWS Networking Fundamentals ของ Toni Pasanen ไปเกือบทั้งหมด
• หลังอ่านหนังสือ จึงสรุปว่าเหตุผลที่ AWS networking มี resources จำนวนมาก เป็นเพราะมี วิธีการเชื่อมต่อ ที่เป็นไปได้จำนวนมาก

ประเภทการเชื่อมต่อที่ครอบคลุมใน AWS networking

• AWS networking ครอบคลุมการเชื่อมต่อหลายประเภท
  • การเชื่อมต่อระหว่าง AWS account กับ on-premises
  • การเชื่อมต่อระหว่าง account กับ account
  • การเชื่อมต่อระหว่าง VPC กับ VPC
  • การเชื่อมต่อระหว่าง subnet กับ subnet
  • การเชื่อมต่อระหว่าง VPC กับ internet
  • การเชื่อมต่อระหว่าง VPC กับ AWS service เฉพาะ

ผลลัพธ์เป็นมายด์แมป

• เพื่อเชื่อมชิ้นส่วนต่าง ๆ เข้าด้วยกัน ผู้เขียนได้ทำแนวคิด AWS networking เป็น มายด์แมป
• สามารถดูไฟล์ต้นฉบับสำหรับแก้ไขได้ที่ ลิงก์ Lucidchart
• ผู้เขียนขอ feedback ว่ามีประโยชน์หรือมีข้อผิดพลาดหรือไม่

[GN⁺]

ความคิดเห็นจาก Hacker News

• ไม่เข้าใจเลยว่าทำไม การดีบักนโยบาย IAM และปัญหาการยืนยันตัวตน ใน AWS ถึงยุ่งเหยิงได้ขนาดนี้
  ถ้าใครอยากเป็นคู่แข่ง ก็ควรมาโฟกัสตรงนี้เลย ผมเสียเวลาไปหลายชั่วโมงเพื่อหาสาเหตุของ error ว่าไม่มีสิทธิ์ แล้วเอกสารทางการก็บอกให้ไล่ตรวจนโยบายราว 8 แบบที่อาจมีผล เช่น SCP, IAM, resource policy ฯลฯ ด้วยมือ
  สุดท้ายต่อให้หาเอกสารที่ใช้ Athena กับ CloudTrail ก็ยังมีคำขอหายไปแบบไม่มีเหตุผลเกือบครึ่ง และถึงในข้อความผิดพลาดจะมี request ID ก็ยังเอาไปค้นต่อได้ไม่ง่าย ควรจะค้นจาก request ID ได้ทันทีแล้วบอกให้ชัดเลยว่านโยบายไหนเป็นตัวปฏิเสธ
  ตั้งแต่ต้นจนจบมันคือความโกลาหลเต็มรูปแบบ และก็อดคิดไม่ได้ว่าสภาพแบบนี้ช่วยให้ขาย สัญญาซัพพอร์ต ได้มากขึ้น

  • ถ้ามองแบบประชดหน่อย ๆ สถานการณ์นี้ก็น่ายินดีอยู่เหมือนกัน บริษัทที่กระโดดขึ้นขบวน AWS กำลังจ่ายราคาของมัน และเงินเดือนผมก็รวมอยู่ในนั้นด้วย
    สำหรับโปรเจกต์ส่วนตัว นอกจากกรณีที่หาได้ยากมาก ผมแทบจะเลือกทางเลือกอื่นที่คุ้มค่ากว่าเสมอ ราว 10 ปีก่อน AWS ถูกขายด้วยแนวคิดประมาณว่า “ระบบเราดูแลให้เอง ไปไล่ผู้ดูแลระบบออกให้หมดได้เลย” แต่ตอนนี้วิศวกร AWS DevOps ที่เก่ง ๆ ทั้งแพงและหายาก และโดยเฉพาะในระบบขนาดใหญ่ ถ้าทำตามคำแนะนำของ AWS อย่างถูกต้อง ค่าใช้จ่ายก็สูงมหาศาล
  • บน Azure การจับคู่ Managed Identity กับ AAD จากประสบการณ์แล้วสะดวกมากจริง ๆ
    เวลาจะให้ฟังก์ชันแอปเข้าถึงฐานข้อมูล SQL ก็แค่ใช้ชื่อจริงของฟังก์ชันแอปเท่านั้น และถ้ามีชื่อแฝงก็จำกัดด้วย object identifier ได้เลย ไม่ต้องใช้รหัสผ่านหรือใบรับรองอีกต่อไป แล้วมันก็ใช้งานได้เลย
    ถ้าใช้ร่วมกับแพ็กเกจยืนยันตัวตนและของอย่าง Application Insights ด้วย ตราบใดที่คุณอ่านล็อกเป็น ก็แทบไม่ค่อยติดอยู่กับคำถามว่า “ตกลงมันเกิดอะไรขึ้นกันแน่” เป็นเวลานาน
    อย่างไรก็ดี Azure ก็ยังมีจุดอันตรายที่ต้องรู้ล่วงหน้า และถ้าไม่รู้ก็จะเจอความหงุดหงิดคล้าย ๆ กัน Microsoft ทิ้งเบาะแสเรื่องตำแหน่งของกับดักไว้ดีกว่า AWS มากก็จริง แต่ก็ยังมีบางจุดที่ “เผลอ” ไม่บอกไว้อย่างสะดวก จนต้องใช้พ่อมดที่มีประสบการณ์ 20 ปีมาช่วยทะลุม่านชั้นสุดท้ายเพื่อหลีกเลี่ยงค่าใช้จ่ายและความซับซ้อนที่พุ่งขึ้น 5–10 เท่า
  • ทั้งใน AWS และ GCP เรื่อง การควบคุมการเข้าถึงและสิทธิ์ขั้นต่ำเท่าที่จำเป็น นั้นยากมาก
    บางครั้งการดีบัก service account ถึงขั้นต้องรีบูตเครื่องหรือคลัสเตอร์ด้วย เลยยิ่งลำบากขึ้นไปอีก ถ้ามีเครื่องมือคล้าย “cloud traceroute” ที่ช่วยชี้ได้เป๊ะ ๆ ว่าปัญหาเกิดตรงไหนก็คงยอดเยี่ยมมาก
    เพื่อความยุติธรรม ก็ยังมีเครื่องมือสำหรับสิทธิ์ขั้นต่ำที่ผมยังไม่ได้ลองใช้อยู่: 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...
  • เกือบทุกอย่างใน AWS API ใกล้เคียงกับความโกลาหลมาก พัน object หนึ่งไว้ในอีก object หนึ่งซ้ำไปซ้ำมาโดยแทบไม่มีเหตุผล โยนภาระให้ลูกค้าต้องมานั่งเรียนรู้และลงมือทำกับโครงสร้างข้อมูลที่ซับซ้อนเอง
    มันน่ารำคาญมาก และควรให้ นักออกแบบ UX กับวิศวกร มาช่วยกันออกแบบ แต่ก็ไม่ได้ทำ
  • การให้ข้อมูลดีบักเพิ่มเติมกับความล้มเหลวของ IAM ก็เท่ากับเปิดข้อมูลเพิ่มอีกชั้นให้ผู้โจมตีด้วย
    ถ้าบริการแบบนั้นมีให้ลูกค้าใช้ ก็อาจเท่ากับมีให้ผู้โจมตีใช้ได้ด้วย และในความเป็นจริงอาจขัดกับนโยบายความปลอดภัยและคอมพลายแอนซ์ของบางบริษัท
    ถึงอย่างนั้น ผมก็คิดว่าควรเปิดให้ลูกค้าเลือกได้ หากยอมเซ็นเอกสารรับความเสี่ยงใหญ่ ๆ เช่น “การทำเรื่องอันตรายด้วยผู้ใช้ root ของ AWS”
    เนื่องจากคำขอของ AWS กระจายตัวมาก ในเชิงแนวคิดแล้ว โครงแบบคล้าย GraphQL น่าจะเข้ากับระบบลักษณะนี้ได้ดี และก็ไม่ได้ห่างจากระบบติดตามอย่าง OTEL มากนัก

• เพราะแบบนี้เลยไม่ชอบเวลาต้องยุ่งกับ AWS การเรียนสิ่งนี้ไม่ใช่ ความรู้ทางเทคนิค แต่เป็นความรู้เฉพาะตัวผลิตภัณฑ์
  ชุดหนังสือ TCP/IP Illustrated ผมอ่านตั้งแต่ต้นจนจบและทำความเข้าใจอย่างถ่องแท้ แล้วความรู้นั้นก็ยังมีประโยชน์ต่อเนื่องมาหลายสิบปี
  ในทางกลับกัน ความรู้เรื่อง AWS แม้จะซับซ้อนในตัวเอง แต่ก็ทำให้ไม่อยากเรียนมันทุกครั้ง พอเห็นไดอะแกรมนี้แล้ว ถ้าเป้าหมายคือการทำให้เรียบง่าย ก็ไม่แน่ใจว่าเรียกว่าประสบความสำเร็จได้แค่ไหน

  • ถ้ามองว่าเป็นการแลกเปลี่ยนกับเป้าหมายอื่นที่ไม่ใช่ความเรียบง่าย ก็พอเข้าใจได้มากขึ้น
    ตัวอย่างเช่น ถ้าเป้าหมายคือทำให้ลูกค้าองค์กรสามารถจำลองเครือข่ายองค์กรเสมือนหรือเครือข่ายดาต้าเซ็นเตอร์เสมือนได้ สิ่งเหล่านั้นซับซ้อนกว่าสแตก TCP ฝั่งไคลเอนต์มาก
    สำหรับการใช้งานง่าย ๆ ค่าเริ่มต้นก็เรียบง่ายอยู่แล้ว ส่วนกรณีซับซ้อนก็จำเป็นต้องมีความรู้เฉพาะผลิตภัณฑ์ของ AWS แต่แนวคิดพื้นฐานส่วนใหญ่ก็ใช้ร่วมกับคลาวด์อื่นหรือเครือข่าย on-premises ได้ คล้ายกับการเรียนภาษาการเขียนโปรแกรมลำดับที่ N
  • ไม่ถึงกับเป็นแบบนั้นเสียทีเดียว แต่มันขึ้นอยู่กับเลนส์ของสาขาอื่นที่ใช้มองมากกว่า
    TCP/IP เป็นความรู้ที่มีประโยชน์สำหรับโปรแกรมเมอร์เครือข่าย ในวิชาเครือข่ายสมัยมหาวิทยาลัย เราได้ทำงานกับเครือข่าย ซับเน็ต ตารางเราต์ติ้ง โปรโตคอลเราต์ติ้งอย่าง RIP·OSPF·BGP, NAT และอุปกรณ์จริง และเพราะได้รับการสนับสนุนจาก Cisco เยอะ พอจบเทอมก็มีความรู้ระดับสอบ CCNA ได้เลย
    เราได้เรียน “ความรู้เฉพาะผลิตภัณฑ์” อย่างวิธีการทำงานของผลิตภัณฑ์ Cisco อยู่มาก แต่ก็ลืมไปเกือบหมดแล้ว ขณะที่แนวคิดแกนหลักยังถ่ายโอนไปใช้กับ Azure, AWS, GCP ได้ดี VPC บนคลาวด์คือสิ่งเทียบเท่าเสมือนของเครือข่ายจริง เหมือนที่ virtual machine เป็นสิ่งเทียบเท่าของเครื่องจริง
    โดยเฉพาะ NAT ทำให้คนสับสนกันมาก ในระดับพื้นฐานกว่านั้น วิศวกรจำนวนมากยังมีปัญหากับสัญกรณ์ CIDR หรือแม้แต่ตัว TCP เอง เช่น คิดว่า send() จะส่งบัฟเฟอร์ที่ส่งให้ไปเป็นหนึ่งหน่วยเดียว หรือคิดว่า recv() จะได้รับ “ข้อความ” ที่สมบูรณ์เสมอ หลายคนก็ยังสับสนระหว่าง connection timeout กับ peer reset
    แต่ก็อยากให้ไม่จำเป็นต้องต้องมีความรู้พวกนี้ IPv6 ทำให้เครือข่ายมีขนาดใหญ่พอจนลดเรื่องอย่างการวางแผนขนาดซับเน็ตไปได้มาก NAT หายไปจากโลกนี้ได้เลยก็ดี VPN ก็ไม่อยากเห็นอีกแล้ว ใช้ TLS ไปเลยดีกว่า ผมก็อยากให้กำจัด cloud firewall ที่ใช้ IP address ราวกับเป็นการยืนยันตัวตน รวมถึงข้อผิดพลาดที่ชวนให้เข้าใจผิดซึ่งตามมาด้วย Azure นี่หนักมากในเรื่องนี้
  • ผมมองว่านี่คือสถานการณ์แบบ กบต้มช้า ๆ เป้าหมายของ AWS ไม่ใช่ความเรียบง่าย แต่คือส่วนแบ่งตลาด
    เหมือนซอฟต์แวร์สำหรับผู้เชี่ยวชาญจำนวนมาก มันเริ่มจากความเรียบง่ายเพราะความจำเป็น แต่เมื่อเวลาผ่านไปก็ซับซ้อนขึ้น และ AWS ก็ขยายตัวอย่างรวดเร็วเพราะเสน่ห์ของบริการโครงสร้างพื้นฐานแบบ fully managed on-demand กับทรัพยากรที่ Amazon ทุ่มลงไป
    คุณค่าของการไม่ต้องจัดการฮาร์ดแวร์เองยังคงสูงมาก แต่ชัดเจนว่านอกจากราคาที่แสดงแล้ว ยังต้องจ่ายด้วยความรู้เฉพาะผู้ขายที่ย้ายออกได้ยากด้วย
  • ถ้าใช้คำศัพท์มาตรฐานก็น่าจะดีกว่านี้ เช่นมีแนวคิดอย่าง virtual router ที่ใช้ตั้งค่าอินเทอร์เน็ต, NAT, การเชื่อมต่อกับ VPC อื่น, กฎไฟร์วอลล์ ฯลฯ ก็พอแล้ว
    แต่กลับมีแนวคิดเฉพาะกิจเต็มไปหมดอย่าง “internet gateway”, “NAT gateway”, “egress only internet gateway”, “transit gateway” สุดท้ายคงจะเกิดคนรุ่นใหม่ของวิศวกรที่เข้าใจแค่ “คลาวด์” แต่ไม่รู้ว่าจริง ๆ แล้วมันทำงานอย่างไร
  • มันคืองานหนักที่ไม่สร้างความแตกต่าง บริษัทไม่จำเป็นต้องฝึกและจ้างวิศวกรที่มีความรู้ลึกเรื่อง TCP/IP กับฮาร์ดแวร์เราเตอร์ แล้วคอยตามเก็บกวาดและบำรุงรักษาหลังจากคนเหล่านั้นลาออก
    แค่โยนองค์ประกอบ “ที่ไม่สร้างความแตกต่าง” ทั้งหมดให้ AWS แล้วไปโฟกัสกับธุรกิจที่ตัวเองถนัดก็พอ

• ถ้าให้แค่ การกำหนดที่อยู่แบบ global ตามปกติและไฟร์วอลล์ ความซับซ้อนส่วนใหญ่ก็คงหายไป
  เรามักลืมกันง่าย ๆ ว่าอินเทอร์เน็ตระดับ IP มีไว้เพื่ออะไร และสถาปัตยกรรมแบบ end-to-end ถูกสร้างมาเพื่อแก้ปัญหาอะไร
  สิ่งที่ AWS สอนว่าเป็นเครือข่ายแบบ “Well-Architected™” จริง ๆ แล้วใกล้เคียงกับการบูชารูปแบบที่ทำเงินมากกว่า และมันนำไปสู่ความซับซ้อน, เขาวงกตของเครือข่าย 10.x ที่หน้าตาคล้ายกัน, การชนกันของที่อยู่, พร็อกซีแบบหยาบ ๆ เวลาพยายามให้สื่อสารกัน, ความปลอดภัยจริงที่ลดลง, และ vendor lock-in ความซับซ้อนคือศัตรูของความปลอดภัย

  • การเอาวิศวกรอาวุโสที่มีความเชี่ยวชาญเฉพาะโดเมนด้านการแก้ปัญหาธุรกิจมา แล้วบอกว่าเพราะ “คลาวด์” พวกเขาต้องกลายเป็น DevOps/NetworkOps/SecOps เพื่อทำเครือข่าย ไฟร์วอลล์ และโซลูชันด้านไซเบอร์ซีเคียวริตี้สำหรับแอปพลิเคชันให้เสร็จด้วย Terraform ก็ไม่สมเหตุสมผล
    ผู้ดูแลระบบสมัยก่อนก็ไม่ได้รับค่าตอบแทนแค่ครึ่งหนึ่งหรือหนึ่งในสี่ของผมหรอก และโดยทั่วไปคนหนึ่งก็ดูแลฮาร์ดแวร์ให้กับนักพัฒนา 100 คนได้อยู่แล้ว เท่ากับว่าโอเวอร์เฮดที่คนที่เหลือต้องแบกรับเพื่อหลีกเลี่ยงการขยายขอบเขตงานและความเสียหายทางสมองแบบนี้น่าจะมีแค่ราว 0.5%
    บน AWS เรากำลังเห็น การตายของความเชี่ยวชาญ เกิดขึ้นอีกครั้งแบบตรงตัว
  • คำว่า “การบูชารูปแบบที่ทำเงินซึ่งนำไปสู่ความซับซ้อน” อธิบายสิ่งที่เราเห็นในวงการเทคโนโลยีส่วนใหญ่ได้อย่างคมมาก
  • ผมสงสัยว่า Amazon Lightsail ก็น่าจะเป็นแบบนั้นในระดับหนึ่ง แม้จะยังไม่เคยใช้จริง แต่เข้าใจว่ามันซ่อนความซับซ้อนของการตั้งค่าเครือข่ายไว้
    แล้วเรื่องการกำหนดที่อยู่แบบ global กับไฟร์วอลล์ก็ดูเหมือนจะทำได้อยู่แล้วโดยพื้นฐาน แค่สร้าง VPC ที่มีเฉพาะ public subnet แล้วใช้ security group เป็นไฟร์วอลล์ แนวปฏิบัติที่ดีที่สุดคือ public/private subnet กับ NAT gateway ก็จริง แต่ก็คงไม่ถึงกับเป็นไปไม่ได้ที่จะพึ่งแค่ security group
  • หมายถึงแนวทางแบบ Google Cloud ที่ VPC เป็น global และสามารถสร้างซับเน็ตตามรีเจียนเป็นค่าเริ่มต้นได้หรือเปล่า
    ซึ่งมันก็อยู่หลัง anycast IP แบบ global ด้วย
  • ยังมีด้านที่ซับซ้อนกว่านั้นอีก องค์กรด้านความปลอดภัยของหลายบริษัทพยายามยกแนวคิดความปลอดภัยที่ใช้บน on-premises มาใช้บนคลาวด์ตรง ๆ และหน่วยงานกำกับดูแลก็มักทำแบบเดียวกัน
    นั่นจึงก่อให้เกิดความซับซ้อนที่ไม่จำเป็นจำนวนมากในเครือข่ายคลาวด์ที่เราเห็นกัน

• ดูเหมือนว่า mind map นี้น่าจะย่อให้เหลือเพียง แนวคิดด้านเครือข่าย ไม่กี่อย่างได้
  ถ้าเป็นแบบนั้น ความสัมพันธ์และลูกศรส่วนใหญ่ก็จะหายไป และทำให้จับคู่แนวคิดของ AWS กับคลาวด์อื่นหรือแม้แต่เครือข่ายในบ้านได้ด้วย
  https://news.ycombinator.com/item?id=18925350 เป็นสื่อที่อธิบายพื้นฐานด้วยภาพได้ดีมาก ถ้าเริ่มจากว่าเครือข่ายคืออะไร อะไรคือด้านในและด้านนอก ก็จะสร้าง mental model ได้ง่ายขึ้นมาก และถึงไม่รู้รายละเอียดทั้งหมด ฟีเจอร์ต่าง ๆ ของ AWS ก็ยังพอเข้าใจได้มาก

  • ไดอะแกรมในต้นฉบับนำเสนอจากมุมมองของการวางแผนบริการที่ AWS มีให้โดยตรง และในฐานะผลลัพธ์แบบ mind map มันคงช่วยผู้เขียนให้เข้าใจ ความซับซ้อนของ AWS ได้อย่างชัดเจน
    สุดท้ายแล้วมันสรุประบบที่ซับซ้อนออกมาได้อย่างชัดเจนและกระชับ เป็นเอกสารที่ผมคงจะกลับมาอ้างอิงอีกเวลาต้องฝ่าป่า AWS ครั้งต่อไป
  • ไดอะแกรมเครือข่ายสำหรับ AWS โดยพื้นฐานแล้วผมมักวาดเป็น กล่องสี่เหลี่ยมซ้อนกัน
    เช่น subnet อยู่ในกล่อง availability zone ด้านนอกเป็น VPC และกล่องนั้นก็อยู่ใน region อีกที ประมาณนี้แต่ภาพสวยกว่า: https://images.edrawsoft.com/articles/aws-diagram-examples/e...

• ผมยังจำช่วงเริ่มต้นของคลาวด์ ตอนที่ระบบเครือข่ายของ AWS ยังเรียบง่ายและน่าตื่นเต้นได้
  แต่ก็รู้อยู่แล้วว่าวันนี้ต้องมาถึง ถ้าจะเป็นทุกอย่างสำหรับทุกคน สุดท้ายก็หนีไม่พ้นการทำซ้ำความบ้าคลั่งของเครือข่ายดาต้าเซ็นเตอร์แบบ IPv4 ดั้งเดิม
  เมื่อไม่นานมานี้ผมพยายามทำเรื่องที่ในเชิงแนวคิดง่ายมากบน Azure คือไม่อยากให้ storage account ที่เก็บแบ็กอัปฐานข้อมูลเปิดออกสู่อินเทอร์เน็ตให้ใครก็ได้มาลองเจาะ
  นึกว่าแค่เปิด firewall ก็น่าจะพอ แต่ใน allowlist ใส่ได้แค่ subnet และยังต้องใส่ทีละ subnet เท่านั้น ใส่ virtual network ทั้งก้อนไม่ได้ แม้แต่ตัวเลือก “virtual network ทั้งหมดของฉัน” ที่ที่อื่นทำได้ก็ไม่มี
  ยังมีฟีเจอร์ Private Endpoint ด้วย แต่ทำให้ประสิทธิภาพลดลงและมีค่าใช้จ่ายเพิ่ม ดูเหมือนว่าการเปลี่ยน address จาก “public” เป็น “private” ในการตั้งค่า software-defined network คงเป็นงานยากจนต้องจ่ายค่าตอบแทนให้เหล่า cloud fairy
  แต่ที่จริงมันก็ยังใช้ไม่ได้ เพราะต้อง override DNS ให้ client หาเจอ พอผูกเข้ากับ AD domain แล้วบริการ PaaS กลับเข้าถึงไม่ได้
  สุดท้ายก็ต้องสร้าง private DNS zone ที่มีค่าใช้จ่ายเพิ่ม เชื่อมมันเข้ากับ hub network แล้วก็เพิ่มบริการ DNS Resolver ที่เสียเงินอีก พร้อมตั้งกฎจำนวนมหาศาลเพื่อให้ AD domain ยังทำงานต่อได้ จนผ่านไปหนึ่งสัปดาห์
  ทั้งหมดนี้เดิมทีแค่ต้องการให้ต่อให้ storage key รั่ว แฮ็กเกอร์รัสเซียก็ยังเข้าถึงแบ็กอัปไม่ได้เท่านั้นเอง สัปดาห์หน้าอาจพอมีหวังว่าจะอัปเดต subscription template ให้ deploy virtual network ใหม่พร้อมค่า DNS ที่อัปเดตแล้วได้ ไม่ idempotent เหรอ? บางทีอาจมีให้ใน preview ปีหน้าก็ได้

  • ถ้าตั้งค่า Private Endpoint ใน VNET แล้วทำให้ Azure DNS กับ DNS ของตัวเองคุยกันอย่างน่าอัศจรรย์ได้ ก็จะทำสิ่งที่ต้องการได้
    จากนั้นถ้าจะเปิดออกสาธารณะก็ค่อยใช้ public gateway หรือ Front Door ก็ได้ ผมไม่ได้ชอบมันนัก แต่พูดตามตรงมันก็ไม่ได้เพิ่งจะซับซ้อนมหาศาลอะไรตั้งแต่แรกอยู่แล้ว แค่ตอนนี้นักพัฒนาต้องมาเจอกับความโกลาหลบ้าคลั่งของ enterprise networking ที่เมื่อก่อนเป็นงานของฝ่ายปฏิบัติการอย่างเคร่งครัดมากขึ้นเท่านั้น
    ส่วนการตั้งค่า DNS ผมเรียกมันว่าเวทมนตร์เพราะเป็นส่วนที่ผมไม่แตะเอง โดยเฉพาะถ้าใช้ App Service และหลาย subscription จะแชร์ subnet กันไม่ได้ และถ้าใช้ app slot ก็ต้องวางแผนล่วงหน้าไม่ให้พื้นที่ IP address หมด
    สิ่งที่ผมไม่เข้าใจใน Azure คือทำไมค่าเริ่มต้นสำหรับองค์กรถึงไม่เป็น “ไม่อยู่บนอินเทอร์เน็ตทั้งหมด” แล้วค่อยเปิดเมื่อจำเป็นต้องเผยแพร่สู่อินเทอร์เน็ต เพราะยังไงการเอาขึ้นอินเทอร์เน็ตก็ซับซ้อนอยู่แล้ว ต้องมีการตั้งค่าหลายอย่าง เช่น load balancer อย่างน้อยในโหมด enterprise ก็ควรตั้งต้นเป็นอยู่นอกอินเทอร์เน็ต
    หรือไม่ Microsoft อาจต้องทำให้ยากเพราะขายใบรับรอง Azure อยู่ก็ได้ แต่ผมไม่เข้าใจว่าทำไมในปี 2023 เรายังต้องกังวลกับความซับซ้อนนี้ตั้งแต่ค่าเริ่มต้นด้วย การปรับแต่งได้มากเป็นเรื่องโอเค

• เอกสารนี้ยอดเยี่ยมมาก ผมรู้สึกว่าเอกสารของ Google Cloud มักแนะนำความซับซ้อนพวกนี้ได้ค่อนข้างดีเวลาที่จำเป็นต้องใช้ แต่ยังไม่เคยเห็นภาพรวมที่ครบขนาดนี้มาก่อน
  แต่กว่าจะดูรูปได้ก็ต้องพยายามพอสมควร บนหน้าเว็บมันเล็กเกินไปและกดไม่ได้ พอเปิดในแท็บใหม่ก็พาไปหน้าไร้ประโยชน์คล้าย imgur ที่ยังคงแสดงเล็กอยู่ดี สุดท้ายผมต้องดาวน์โหลดรูปถึงจะดูได้สะดวก

• เอกสารนี้ยอดเยี่ยมจริง ๆ มันแสดงให้เห็นชัดว่า mind map และไดอะแกรม มีพลังแค่ไหนเวลาใช้เรียนรู้ผลิตภัณฑ์คลาวด์หรือแนวคิดอื่น ๆ
  ตอนผมอ่านหนังสือสอบใบรับรอง AWS ก็ใช้วิธีนี้เยอะมาก ต่อให้จดโน้ตยาว ๆ หลายหน้า ผมก็ยังเข้าใจได้ดีกว่าเวลามองบริการต่าง ๆ ที่เชื่อมกันอยู่ในแผนที่ มากกว่าดูเป็นหน้ากระดาษเรียงต่อกัน แน่นอนว่าแต่ละคนก็มีวิธีเรียนรู้ต่างกัน

• ผมไม่ค่อยเข้าใจคำวิจารณ์ในเธรดนี้ทั้งหมด ระบบเครือข่ายส่วนใหญ่ที่ AWS มีให้นั้นเป็นสิ่งที่ใช้เมื่อจำเป็น
  มันอาจไม่สง่างามนัก แต่ใช้งานได้จริง และองค์ประกอบที่เป็นของ AWS โดยเฉพาะจำนวนมากก็ตรงกับแนวคิดเครือข่ายจริงแบบค่อนข้างตรงตัว AZ คือ cage, VPC คือ VLAN, PL ก็ประมาณ P2P VPN ข้ามบัญชี
  ส่วนที่เหลือส่วนใหญ่ก็เป็นองค์ประกอบเครือข่ายปกติที่พบได้ในสภาพแวดล้อมขนาดใหญ่ทั่วไป
  บริษัทที่ผมทำงานอยู่ดูแลเครือข่ายระดับโลกที่ค่อนข้างซับซ้อน และเชื่อมต่อกับ AWS ผ่าน DX จากหลาย PoP เราใช้ทุกอย่างที่มีอยู่ในไดอะแกรมนี้ และแต่ละองค์ประกอบก็มีจุดประสงค์ที่กำหนดไว้อย่างชัดเจน
  ถ้าไดอะแกรมนี้ดูซับซ้อนเกินไปสำหรับคุณ ก็มีโอกาสสูงว่าคุณไม่ได้ใช้ทั้งหมดนี้ ไม่ได้ใช้ตามวัตถุประสงค์ที่ออกแบบไว้ หรือไม่ก็คุณไม่ใช่ วิศวกรเครือข่าย

• มีใครอ่านรูปนี้ออกจริง ๆ ไหม? ต่อให้เป็นเดสก์ท็อปก็ดูที่ความละเอียดพออ่านได้ไม่ได้เลย
  https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... ก็ยังเป็นหน้าเว็บอยู่ และถึงรูปจะใหญ่ขึ้นแต่ก็ไม่ได้อ่านง่ายขึ้น

  • พังสนิทเลย พอกด “เปิดรูปในแท็บใหม่” ก็ออกมาเป็นแบบนี้
    แต่ถ้าบันทึกไฟล์ก็ยังพอใช้งานได้ หลังจากนั้นก็ต้องมีจอใหญ่หน่อย ขนาดมันคือ 7,763 × 4,684 พิกเซล
  • ผมเป็นคนเขียนโพสต์ต้นฉบับเอง แก้แล้วนะ ถ้าช่วยบอกได้ว่าตอนนี้ดูได้ปกติไหมก็ดีมาก
  • บนมือถือผมต้องกดค้างแล้วเลือกเปิดรูปในแท็บใหม่

• ดูซับซ้อนมาก ในบรรดาผู้ให้บริการคลาวด์รายใหญ่ 3 เจ้า ผมรู้จักแค่ GCP และแม้ที่นั่นระบบเครือข่ายจะไม่ได้เรียบง่ายนัก แต่ก็ยังพอมีความเป็นธรรมชาติและสอดคล้องกันอยู่
  น่าจะดีถ้ามีคนที่มีประสบการณ์มัลติคลาวด์มากกว่านี้มาเปรียบเทียบให้หน่อยว่า การตั้งค่าการสื่อสารภายในและภายนอกนั้นง่ายหรือยากแค่ไหนเมื่อเทียบกันในกลุ่มบิ๊ก 3

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