S3: เอนด์พอยต์แบบเกตเวย์หรืออินเทอร์เฟซสำหรับการเข้าถึงจากเครือข่ายภายใน

เอนด์พอยต์ S3 สองประเภทดูเหมือนใช้แทนกันได้ในการทบทวนการออกแบบ และทำงานต่างกันโดยสิ้นเชิงเมื่อไคลเอนต์อยู่นอกสถานที่ เอนด์พอยต์แบบเกตเวย์คือการผสานกับตารางเส้นทางภายใน VPC คำขอจาก VPN ของสถานที่จึงไม่เคยไปถึงในฐานะปลายทางส่วนตัว เอนด์พอยต์แบบอินเทอร์เฟซวางที่อยู่ส่วนตัวบนอินเทอร์เฟซเครือข่าย ซึ่งเส้นทางแบบไฮบริดเข้าถึงได้จริง ทุกอย่างที่ตามมาขึ้นอยู่กับว่าคุณเลือกแบบใดในสองแบบนี้

ตัดสินใจจากจุดเข้าเครือข่าย ไม่ใช่ชื่อบริการ

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

การผสมทั้งสองไม่ใช่ปัญหา การสันนิษฐานว่าประเภทหนึ่งครอบคลุมอีกประเภทหนึ่งต่างหากที่เป็นปัญหา

จำแนกไคลเอนต์ก่อนเลือกสิ่งใด พื้นที่ทำงานใน VPC คอนเทนเนอร์หลังเกตเวย์ NAT และแอปพลิเคชันในสำนักงานสาขาเป็นแหล่งที่มาต่างกันสามแบบ และเฉพาะแบบสุดท้ายที่บังคับให้ใช้จุดเข้าแบบไฮบริด เขียนการจำแนกนั้นไว้ข้างรายการเอนด์พอยต์ เพื่อให้ผู้ทบทวนคนถัดไปเห็นว่าเอนด์พอยต์แต่ละตัวมีอยู่เพราะอะไร

สิ่งที่เส้นทางอินเทอร์เฟซต้องการตั้งแต่ต้นจนจบ

เอนด์พอยต์แบบอินเทอร์เฟซให้การเข้าถึงที่อยู่ส่วนตัว และการเข้าถึงเป็นเพียงหนึ่งในสี่ข้อกำหนด เครือข่ายภายในต้องการเส้นทางไปยังที่อยู่เหล่านั้น ฝั่ง VPC ต้องการเส้นทางกลับ กลุ่มความปลอดภัยของเอนด์พอยต์ต้องยอมรับช่วงต้นทาง และอุปกรณ์ตรวจสอบใด ๆ ระหว่างทั้งสองต้องอนุญาตการไหล เส้นทางไปยังอินสแตนซ์ใด ๆ ใน VPC ไม่ได้พิสูจน์ข้อใดในสี่ข้อนั้นเลย

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

ทดสอบด้วยการดำเนินการที่ได้รับอนุญาตเล็กที่สุดที่มีอยู่ แทนการดาวน์โหลดขนาดใหญ่ ความล้มเหลวจะปรากฏเร็วขึ้นและมีทราฟฟิกให้อธิบายน้อยลง

DNS ตามแหล่งที่มาของคำถาม ไม่ใช่ VPC

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

อ่านการตั้งค่า DNS ส่วนตัวของเอนด์พอยต์เป็นส่วนหนึ่งของการออกแบบ ไม่ใช่ช่องทำเครื่องหมายที่เปิดหลังการใช้งานจริง

หากตัวแก้ไขชื่อในสำนักงานต้องเห็นมุมมองของ VPC เส้นทางนั้นต้องสร้างขึ้นโดยเจตนา โดยปกติผ่านเอนด์พอยต์ตัวแก้ไขชื่อแบบขาเข้า สอบถามจากบริบทของแอปพลิเคชันเองและบันทึกว่าตัวแก้ไขชื่อใดตอบ ผลลัพธ์ที่เก็บบนโฮสต์บาสเตียนใน VPC อธิบายมุมมองของบาสเตียนเท่านั้น ไม่มีอย่างอื่น

สิทธิ์แยกจากการเข้าถึง

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

ยอมรับการออกแบบด้วยผลลัพธ์สองอย่าง คือการเรียกที่ได้รับอนุญาตและไม่เป็นอันตรายซึ่งสำเร็จ และการปฏิเสธที่คาดไว้สำหรับตัวตนหรือบักเก็ตที่ถูกยกเว้น

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

บันทึกชื่อเอนด์พอยต์ ปลายทางที่แก้ไขแล้ว และบริบทนโยบายข้างผลลัพธ์แต่ละรายการ เพราะการเปลี่ยนแปลง DNS ครั้งเดียวในภายหลังอาจทำให้ข้อสรุปทั้งหมดใช้ไม่ได้ เปรียบเทียบต้นทุนปัจจุบันและภาระการดำเนินงานของเอนด์พอยต์ทั้งสองประเภทก่อนจัดเตรียมสิ่งใด เอนด์พอยต์แบบอินเทอร์เฟซซื้อจุดเข้าแบบไฮบริดส่วนตัว ไม่ใช่ข้อกำหนดสากล และเส้นทางเกตเวย์มักยังเป็นคำตอบที่ดีกว่าสำหรับงานภายใน VPC ทางเลือกขึ้นอยู่กับไคลเอนต์แต่ละรายและยังคงพร้อมให้ทบทวน