S3 เกตเวย์หรือปลายทางอินเทอร์เฟซสำหรับไคลเอนต์ภายในองค์กร?

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

แยกประเภทปลายทางตามจุดที่คำขอเริ่มต้น

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

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

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

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

สร้างเส้นทางไปยังที่อยู่ของอินเทอร์เฟซก่อนทดสอบ S3

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

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

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

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

ตัดสินใจว่าแอปพลิเคชันได้รับคำตอบ DNS แบบใด

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

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

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

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

การเข้าถึงได้ไม่ใช่การอนุญาต

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

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

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