สองบัญชี AWS หนึ่งเครือข่ายภายในองค์กร: เลือกเส้นทางใด
Transit Gateway ที่ใช้ร่วมกัน, VPN อิสระสองเส้นทาง หรือพร็อกซีแคบหนึ่งตัว: เลือกตามความเป็นเจ้าของและขอบเขตผลกระทบ ไม่ใช่ตามเส้นทางที่เพิ่มง่ายที่สุดวันนี้
กรอบที่ดูเหมือนชัดเจนคือ peering เทียบกับ VPN และนั่นคือกรอบที่ผิด VPC ที่ peered กันไม่สามารถยืมการเชื่อมต่อ VPN ของเพื่อนบ้านเพื่อกำหนดเส้นทางจากขอบถึงขอบได้ ตัวเลือกนั้นจึงไม่เคยอยู่บนโต๊ะ ไม่ว่าตารางเส้นทางจะบอกอะไร สิ่งที่คุณเลือกจริง ๆ คือฮับเครือข่ายที่ใช้ร่วมกัน เส้นทาง VPN อิสระสองเส้นทาง และทางเข้าของแอปพลิเคชันแบบแคบหนึ่งทาง แต่ละอย่างตอบคำถามต่างกันว่าใครเป็นเจ้าของการกำหนดเส้นทาง
สามตัวเลือกและตัวเลือกที่ไม่มีอยู่จริง
เริ่มด้วยการลบแนวคิด peering แล้วเปรียบเทียบสิ่งที่เหลือตามความเป็นเจ้าของ ไม่ใช่ตามความเรียบง่ายของแผนภาพ ตารางด้านล่างคือการตัดสินใจในรูปแบบย่อ
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
ถ้าบัญชี A ต้องเข้าถึงเครือข่ายภายในทั้งหมด แถวพร็อกซีก็ผิดรูป ถ้าบัญชี A ต้องการ API เดียว สองแถวแรกก็เป็นเครือข่ายมากกว่าที่ข้อกำหนดขอ
เมื่อ Transit Gateway ที่ใช้ร่วมกันชนะ
Transit Gateway เชื่อมทุก VPC และ VPN เป็นเครือข่ายแยกกัน และการแชร์ข้ามบัญชีช่วยให้เจ้าของ VPC ใช้ฮับได้โดยไม่ต้องรวมบัญชี นี่คือจุดดึงดูด: ที่เดียวที่คำนำหน้าภายในพบกับเครือข่าย AWS และที่เดียวสำหรับคิดว่าไฟล์แนบใดเรียนรู้เส้นทางใด
การเชื่อมทุกอย่างไม่ใช่การอนุญาตทุกอย่าง การเชื่อมโยงและการเผยแพร่กำหนดว่าไฟล์แนบใดใช้ตารางเส้นทางใด คำนำหน้า VPC สองชุดจึงเข้าถึงบริการภายในได้คนละทาง ขณะที่การเข้าถึงระหว่างกันยังถูกตัดออกโดยการออกแบบของฮับ ฝั่งภายในยังต้องมีเส้นทางย้อนกลับสำหรับคำนำหน้า AWS และนั่นคือตั๋วเปลี่ยนแปลงของทีมอื่น
ค่าใช้จ่ายเป็นเรื่ององค์กรพอ ๆ กับเรื่องการเงิน เจ้าของฮับควบคุมความสัมพันธ์การกำหนดเส้นทางที่ทีมอื่นพึ่งพา การเปลี่ยนแปลงไฟล์แนบเดียวจึงย้ายทราฟฟิกของบริการที่เจ้าของฮับไม่เคยได้ยินชื่อได้ ชั่วโมงไฟล์แนบและการประมวลผลข้อมูลเพิ่มขึ้นตามทุกเครือข่ายที่คุณเชื่อม ซึ่งเป็นเหตุผลที่ฮับมักโตเร็วกว่าทีมที่ดูแล
เมื่อ VPN แยกหรือพร็อกซีแคบชนะ
VPN อิสระสองเส้นทางเหมาะกับการติดตั้งขนาดเล็กที่มีขอบเขตการปฏิบัติงานจริง: แต่ละบัญชีเปลี่ยนอุโมงค์ของตนเอง และไม่มีใครทำลายอีกฝ่ายได้ด้วยการแก้ไขตารางเส้นทาง ข้อจำกัดอยู่ที่ฝั่งภายใน เกตเวย์คู่ต้องมีความจุสำหรับอุโมงค์เพิ่มเติม แผนที่อยู่ต้องไม่ทับซ้อน และการกำหนดค่าสองชุดที่ประกาศคำนำหน้าเดียวกันต้องมีลำดับความสำคัญที่ตั้งใจไว้ ไม่ใช่ความหวัง
พร็อกซีคืออินเทอร์เฟซที่แคบที่สุด ถ้าบัญชี A ต้องการฐานข้อมูลหนึ่งหรือ API หนึ่งในบัญชี B ตัวกลางที่จำกัดขอบเขตจะให้ทางเข้าที่ชัดเจนพร้อมเรื่องราวการพิสูจน์ตัวตน การบันทึก และความพร้อมใช้งานของตัวเอง มันยังเป็นตัวเลือกที่ถูกละเมิดมากที่สุด: ตัวกลางที่ส่งต่อไปยังทุกปลายทางส่วนตัวกลายเป็นรีเลย์ไร้ขอบเขตที่มีขั้นตอนเพิ่มขึ้น และมันจะไม่ทำตัวเหมือนการส่งผ่านโปร่งใสจาก VPC ไปยังเครือข่ายภายในสำหรับสิ่งอื่นใด
ควรอ่านข้อจำกัดของ VPC peeringก่อนทั้งหมดนี้ เพราะมันอธิบายว่าทำไมแนวคิดที่สี่จึงกลับมาเสมอและทำไมจึงใช้งานไม่ได้
เลือกอินเทอร์เฟซที่แคบที่สุดที่ตอบโจทย์
เรียงคำถาม: A ต้องการเครือข่ายหนึ่งชุด เครือข่ายหลายชุด หรือบริการเดียว ทีมภายในต้องการเส้นทางเดียวหรือหลายเส้นทาง ใครได้รับอนุญาตให้เปลี่ยนการกำหนดเส้นทางสำหรับทราฟฟิกของอีกทีม คำตอบแรกที่ให้อินเทอร์เฟซแคบที่สุดคือสถาปัตยกรรม และทุกอย่างหลังจากนั้นคือการนำไปใช้
บันทึกคำตอบพร้อมแผนคำนำหน้า ความเป็นเจ้าของเส้นทาง รายการอุโมงค์หรือไฟล์แนบ และโหมดความล้มเหลวที่แต่ละฝ่ายคาดหวัง เมื่อมีคนถามภายหลังว่าทำไมบัญชี A จึงใช้ VPN ของบัญชี B ตรง ๆ ไม่ได้ บันทึกนั้นคือคำตอบ และช่วยให้คุณไม่ต้องเถียงสามตัวเลือกเดิมซ้ำในโครงการถัดไป