ऑन-प्रिमाइसिस क्लाइंट के लिए S3 गेटवे या इंटरफ़ेस एंडपॉइंट?

किसी साइट VPN के ज़रिये ऑफ़िस नेटवर्क से S3 तक पहुँचना ऐसी रूटिंग समस्या नहीं है जिसे कोई स्टैटिक रूट अकेले हल कर दे। गेटवे एंडपॉइंट रूट टेबल से जुड़ा होता है और 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 पैकेट गिरा सकता है, इसलिए इसे बाद की सोच नहीं बल्कि चौथे मद के रूप में जाँचें।

VPC में किसी EC2 इंस्टेंस तक काम करने वाला रूट इनमें से कुछ भी सिद्ध नहीं करता। वह केवल दिखाता है कि टनल चालू है, जो पथ का वही एक हिस्सा है जो आप पहले से जानते थे। एंडपॉइंट का पता अलग से सिद्ध करें, फिर सिद्ध करें कि नाम उसी में हल होता है।

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 उस एंडपॉइंट के लिए प्रकाशित करता है, या ऐसा निजी होस्टेड ज़ोन जिसे आपने जान-बूझकर ऑफ़िस से हल होने योग्य बनाया है।

हाइब्रिड रिज़ॉल्यूशन के लिए ऑन-प्रिमाइसिस रिज़ॉल्वर को VPC के DNS दृश्य तक एक समर्थित पथ चाहिए, आम तौर पर 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 की ओर से पहुँच चाहिए।