कई VPC में AWS VPC Endpoint साझा करना: केंद्रीकृत आर्किटेक्चर और कॉन्फ़िगरेशन गाइड

📅 2026-08-21
📍 AWS Centralized VPC Endpoint
⏱️ पढ़ने का समय: लगभग 35 मिनट

इंटरफ़ेस एंडपॉइंट | ट्रांज़िट गेटवे | वीपीसी पीयरिंग | रूट 53 | क्रॉस-अकाउंट | लागत और सुरक्षा

AWS में, "विभिन्न VPCs में एक VPC एंडपॉइंट साझा करने" का मूल सिद्धांत केवल एक एंडपॉइंट को सीधे कई VPCs से जोड़ना नहीं है, बल्कि यह है:

इंटरफ़ेस वीपीसी एंडपॉइंट्स को एक ही सेंट्रल/शेयर्ड सर्विसेज वीपीसी में केंद्रीकृत करें, और फिर रूट 53 का उपयोग करके डीएनएस को एकीकृत करते हुए, ट्रांजिट गेटवे या वीपीसी पीयरिंग के माध्यम से अन्य वीपीसी को इस एंडपॉइंट के निजी आईपी तक पहुंचने की अनुमति दें।

AWS आधिकारिक तौर पर इस मॉडल को इस प्रकार संदर्भित करता है... Centralized access to VPC private endpoints。

लेकिन सबसे पहले, इन दोनों के बीच अंतर करना आवश्यक है। Interface Endpoint और Gateway Endpoint。

सबसे पहले, आइए सबसे महत्वपूर्ण निष्कर्ष बताते हैं।

मान लीजिए कि आपके पास वर्तमान में निम्नलिखित है:

VPC-A
VPC-B
VPC-C

तीनों वीपीसी को निम्नलिखित की आवश्यकता है:

SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...

आपके पास दो डिजाइन हैं।

विकल्प ए: प्रत्येक वीपीसी अपना स्वयं का एंडपॉइंट बनाता है।

VPC-A
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-B
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

VPC-C
 ├─ SSM Endpoint
 ├─ EC2 Endpoint
 ├─ ECR Endpoint
 ├─ Logs Endpoint
 └─ KMS Endpoint

यह सबसे सरल और सबसे पृथक डिजाइन है।

हालांकि, अंतिम बिंदुओं की संख्या में तेजी से वृद्धि होगी।

उदाहरण के लिए:

10 वीपीसी × 20 एडब्ल्यूएस सर्विस एंडपॉइंट × 2 एजेड = 400 एंडपॉइंट ईएनआई

इंटरफ़ेस एंडपॉइंट इस पर आधारित है एंडपॉइंट × AZ × घंटाइसके लिए शुल्क के साथ-साथ डेटा प्रोसेसिंग शुल्क भी देना होगा।

इसलिए, जैसे-जैसे पैमाना बढ़ेगा, लागत और रखरखाव में काफी वृद्धि होगी।

II. केंद्रीकृत वीपीसी एंडपॉइंट की वास्तुकला

स्थापित करें:

Network VPC / Shared Services VPC

सभी अंतिम बिंदु यहाँ रखे गए हैं।

उदाहरण के लिए:

                  AWS Services
                       │
                PrivateLink
                       │
             ┌───────────────────┐
             │  Network VPC      │
             │  10.0.0.0/16      │
             │                   │
             │ SSM Endpoint      │
             │ KMS Endpoint      │
             │ ECR Endpoint      │
             │ Logs Endpoint     │
             │ STS Endpoint      │
             │ Secrets Endpoint  │
             └─────────┬─────────┘
                       │
                Transit Gateway
             ┌─────────┼─────────┐
             │         │         │
             │         │         │
          VPC-A      VPC-B      VPC-C
       10.10/16   10.20/16   10.30/16

तब:

VPC-A में EC2 ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ साझा VPC में SSM एंडपॉइंट के निजी IP पर रिजॉल्व होता है ↓ ट्रांजिट गेटवे ↓ इंटरफ़ेस एंडपॉइंट ENI ↓ AWS प्राइवेटलिंक ↓ SSM

AWS आधिकारिक तौर पर इस केंद्रीकृत डिजाइन का समर्थन करता है।

III. एक विशेष रूप से महत्वपूर्ण अपवाद: S3 / DynamoDB

इस पर अलग से चर्चा करने की आवश्यकता है।

गेटवे एंडपॉइंट्स को इस तरह से साझा नहीं किया जा सकता है।

S3 और DynamoDB में निम्नलिखित विशेषताएं हैं:

Gateway VPC Endpoint

उदाहरण के लिए:

com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodb

यह एक सामान्य इंटरफेस एंडपॉइंट से पूरी तरह अलग है।

Gateway Endpoint：

  • प्राइवेटलिंक का उपयोग न करें
  • ENI न बनाएं
  • असल में, यह रूट टेबल और एडब्ल्यूएस मैनेज्ड प्रीफिक्स लिस्ट का संयोजन है।
  • मुक्त
  • इसका उपयोग केवल उसी वीपीसी द्वारा किया जा सकता है जिसमें यह स्थित है।

AWS ने आधिकारिक तौर पर कहा है:

गेटवे एंडपॉइंट वीपीसी से आगे नहीं बढ़ सकते; वीपीसी पीयरिंग, ट्रांजिट गेटवे, वीपीएन या डायरेक्ट कनेक्ट के दूसरे छोर से संसाधन इस गेटवे एंडपॉइंट से उधार नहीं लिए जा सकते।

इसलिए, इसे निम्नलिखित तरीके से डिजाइन नहीं किया जाना चाहिए:

VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint

फिर हम चाहते हैं कि VPC-A, Shared VPC के S3 Gateway Endpoint का उपयोग करे।

नहीं।

IV. S3 / DynamoDB के लिए सही कार्यप्रणाली

सामान्यतः यह इस प्रकार होना चाहिए:

VPC-A → आपका अपना S3 गेटवे एंडपॉइंट VPC-B → आपका अपना S3 गेटवे एंडपॉइंट VPC-C → आपका अपना S3 गेटवे एंडपॉइंट

क्योंकि:

गेटवे एंडपॉइंट्स के लिए कोई अतिरिक्त शुल्क नहीं लिया जाता है।

इसलिए, "एंडपॉइंट्स की संख्या कम करने" के उद्देश्य से एस3 गेटवे एंडपॉइंट को केंद्रीकृत करने की कोई आवश्यकता नहीं है।

अनुशंसा करना:

                  S3
             ↑     ↑     ↑
             │     │     │
           GW EP  GW EP  GW EP
             │     │     │
           VPC-A VPC-B VPC-C

और:

SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.

इन Interface VPC Endpoint इसी कारण केंद्रीकरण उपयुक्त होता है।

5. इंटरफ़ेस एंडपॉइंट का उपयोग वीपीसी में क्यों किया जा सकता है?

क्योंकि एक इंटरफ़ेस एंडपॉइंट मूल रूप से यह है:

अपने निर्दिष्ट सबनेट में एक निजी आईपी पते के साथ एक ENI बनाएं।

AWS के आधिकारिक दस्तावेज़ के अनुसार, एक इंटरफ़ेस एंडपॉइंट आपके द्वारा चुने गए सबनेट में एक एंडपॉइंट नेटवर्क इंटरफ़ेस बनाता है और उस सबनेट को एक निजी आईपी पता असाइन करता है।

उदाहरण के लिए:

Shared VPC
10.0.0.0/16

AZ-a:
Endpoint ENI
10.0.10.50

AZ-c:
Endpoint ENI
10.0.20.60

दूसरे वीपीसी के लिए, बशर्ते कि:

VPC-A → 10.0.10.50 पर रूट कर सकता है

और:

सुरक्षा समूह 10.0.10.50 वीपीसी-ए की अनुमति देता है

वास्तव में, नेटवर्क पहले से ही एंडपॉइंट तक पहुंच सकता है।

इसलिए, तथाकथित:

साझा वीपीसी एंडपॉइंट

असल में हुआ ये था:

अन्य वीपीसी ↓ क्रॉस-वीपीसी नेटवर्क ↓ केंद्रीय वीपीसी एंडपॉइंट ईएनआई तक पहुंचें

नहीं:

एक vpce-xxx को एक साथ तीन VPC से जोड़ा जा सकता है।

ये दो बिल्कुल अलग-अलग अवधारणाएं हैं।

VI. तीन व्यावहारिक कार्यान्वयन विधियाँ

वास्तव में, इसे तीन प्रकारों में विभाजित किया जा सकता है।

तरीका अनुशंसा स्तर उपयुक्त
Transit Gateway ⭐⭐⭐⭐⭐ बड़े पैमाने पर, मल्टी-वीपीसी
VPC Peering ⭐⭐⭐⭐ 2 से 5 वीपीसी
एंडपॉइंट डीएनएस का सीधे उपयोग करें ⭐⭐⭐ परीक्षण/विशेष आवेदन
प्रति वीपीसी स्वतंत्र एंडपॉइंट ⭐⭐⭐⭐⭐ अलगाव को प्राथमिकता दें, छोटे पैमाने पर

VII. विधि 1: ट्रांजिट गेटवे + सेंट्रल एंडपॉइंट

यह उद्यमों के लिए सबसे आम समाधान है।

टोक्यो क्षेत्र को मानकर चलें:

ap-northeast-1

नेटवर्क:

Network VPC
10.0.0.0/16

App VPC-A
10.10.0.0/16

App VPC-B
10.20.0.0/16

App VPC-C
10.30.0.0/16

वास्तुकला:

                       AWS SSM
                          ▲
                          │
                     PrivateLink
                          │
                 SSM Interface EP
                 10.0.10.50
                 10.0.20.50
                          │
                ┌─────────────────┐
                │   Network VPC   │
                │   10.0.0.0/16   │
                └────────┬────────┘
                         │
                       TGW
              ┌──────────┼──────────┐
              │          │          │
            VPC-A      VPC-B      VPC-C
          10.10/16   10.20/16   10.30/16

ट्रांजिट गेटवे (TGW) को AWS द्वारा कई VPCs में केंद्रीय रूटिंग के लिए डिज़ाइन किया गया है और यह ट्रांजिएंट रूटिंग का समर्थन करता है; AWS बड़े पैमाने पर मल्टी-VPC नेटवर्क के लिए TGW को प्राथमिकता देने की भी सिफारिश करता है।

VIII. विशिष्ट संचालन प्रक्रियाएँ

निम्नलिखित वास्तविक कॉन्फ़िगरेशन का विवरण है।

चरण 1: एक नेटवर्क वीपीसी बनाएं

उदाहरण के लिए:

VPC:
shared-endpoint-vpc

CIDR:
10.0.0.0/16

दो एजेड:

ap-northeast-1a
Endpoint subnet:
10.0.10.0/24

ap-northeast-1c
Endpoint subnet:
10.0.20.0/24

कम से कम 2 एजेड रखने की सलाह दी जाती है।

9. चरण 2: एक ट्रांजिट गेटवे बनाएं

VPC Console：

Transit Gateways
→ Create transit gateway

उदाहरण के लिए:

Name:
core-tgw

फिर एक वीपीसी अटैचमेंट बनाएं:

core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c

यदि आपके पास अलग-अलग AWS खाते हैं, तो आप AWS RAM के माध्यम से ट्रांजिट गेटवे को साझा कर सकते हैं। AWS आधिकारिक तौर पर खातों के बीच TGW को साझा करने का समर्थन करता है।

10. चरण 3: वीपीसी रूट टेबल को कॉन्फ़िगर करें

मान्यता:

Shared VPC:
10.0.0.0/16

VPC-A:
10.10.0.0/16

VPC-B:
10.20.0.0/16

VPC-A：

Destination        Target

10.10.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

VPC-B：

Destination        Target

10.20.0.0/16       local
10.0.0.0/16        tgw-xxxxxxxx

Shared Endpoint VPC：

Destination        Target

10.0.0.0/16        local
10.10.0.0/16       tgw-xxxxxxxx
10.20.0.0/16       tgw-xxxxxxxx

अन्यथा, निम्नलिखित परिणाम होंगे:

VPC-A → Endpoint

आप जा सकते हैं, लेकिन:

Endpoint → VPC-A

वे वापस नहीं आ सकते।

11. चरण 4: TGW रूट टेबल को कॉन्फ़िगर करें

TGW Route Table：

10.0.0.0/16
    → shared-endpoint-vpc attachment

10.10.0.0/16
    → VPC-A attachment

10.20.0.0/16
    → VPC-B attachment

10.30.0.0/16
    → VPC-C attachment

यदि नेटवर्क आइसोलेशन की कोई विशेष आवश्यकता नहीं है, तो रूट प्रोपेगेशन का उपयोग किया जा सकता है।

कॉर्पोरेट वातावरण को आमतौर पर इस प्रकार विभाजित किया जाता है:

Spoke TGW RT
Shared Services TGW RT
Inspection TGW RT

डिफ़ॉल्ट रूप से सभी वीपीसी को एक दूसरे के साथ संवाद करने की अनुमति देने से बचें।

12. चरण 5: इंटरफ़ेस एंडपॉइंट बनाएं

उदाहरण के लिए, यदि साझा करना आवश्यक है:

AWS Systems Manager

बनाएं:

VPC
→ Endpoints
→ Create endpoint

Service：

com.amazonaws.ap-northeast-1.ssm

VPC：

shared-endpoint-vpc

Subnets：

ap-northeast-1a
10.0.10.0/24

ap-northeast-1c
10.0.20.0/24

अतः, निम्नलिखित स्थिति उत्पन्न होती है:

vpce-0123456789

ENI-A:
10.0.10.50

ENI-C:
10.0.20.50

तेरहवीं और सबसे महत्वपूर्ण बात: प्राइवेट डीएनएस को सीधे तौर पर सक्षम न करें।

जब कोई VPC सामान्यतः अपने स्वयं के एंडपॉइंट का उपयोग करता है:

Enable Private DNS
✓

बहुत सुविधाजनक।

उदाहरण के लिए, मूल रूप से:

ssm.ap-northeast-1.amazonaws.com

यह स्वचालित रूप से निम्न में परिवर्तित हो जाएगा:

10.0.10.50
10.0.20.50

AWS SDK में किसी भी प्रकार के संशोधन की आवश्यकता नहीं है।

हालांकि, केंद्रीकृत वास्तुकला में एक समस्या है।

प्राइवेट डीएनएस स्वचालित रूप से एक एडब्ल्यूएस-प्रबंधित प्राइवेट होस्टेड ज़ोन बनाता है, जो केवल उसी वीपीसी के भीतर काम करता है जहां एंडपॉइंट स्थित है।

इसलिए:

Shared VPC

जानना:

ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50

लेकिन:

VPC-A
VPC-B

मुझें नहीं पता।

इसलिए, AWS की आधिकारिक सेंट्रल एंडपॉइंट आर्किटेक्चर निम्नलिखित की अनुशंसा करती है:

सेंट्रल एंडपॉइंट परिदृश्य में, एंडपॉइंट के लिए स्वचालित प्राइवेट डीएनएस को अक्षम करें और फिर मैन्युअल रूप से रूट 53 प्राइवेट होस्टेड ज़ोन बनाएं।

14. चरण 6: रूट 53 प्राइवेट होस्टेड ज़ोन बनाएं

बनाएं:

Route 53
→ Hosted zones
→ Create hosted zone

Domain：

ssm.ap-northeast-1.amazonaws.com

Type：

Private Hosted Zone

सबसे पहले, संबद्ध करें:

shared-endpoint-vpc

15. चरण 7: उपनाम बनाएँ

प्रवेश करना:

ssm.ap-northeast-1.amazonaws.com

Create record。

Record：

ssm.ap-northeast-1.amazonaws.com

Type：

A

चुनना:

Alias

लक्ष्य चयन:

VPC Endpoint

तब:

vpce-0123456789...

AWS का आधिकारिक सेंट्रल एंडपॉइंट सॉल्यूशन यह है:

AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface Endpoint

एप्लिकेशन को मैन्युअल रूप से एंडपॉइंट आईपी का उपयोग करने के बजाय।

16. चरण 8: सभी वीपीसी के साथ पीएचजेड को संबद्ध करें

Private Hosted Zone：

ssm.ap-northeast-1.amazonaws.com

संबंधित:

shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-c

AWS Route 53 में एक प्राइवेट होस्टेड ज़ोन को कई VPCs के साथ संबद्ध किया जा सकता है।

तब:

VPC-A

अमल में लाना:

nslookup ssm.ap-northeast-1.amazonaws.com

पाना:

10.0.10.50
10.0.20.50

VPC-B

वही:

nslookup ssm.ap-northeast-1.amazonaws.com

बहुत:

10.0.10.50
10.0.20.50

इस समय:

VPC-A
   │
   │ DNS
   ▼
ssm.ap-northeast-1.amazonaws.com
   │
   ▼
10.0.10.50
   │
   ▼
Transit Gateway
   │
   ▼
Central VPC
   │
   ▼
SSM VPC Endpoint

इसी के साथ कहानी समाप्त होती है।

17. चरण 9: एंडपॉइंट सुरक्षा समूह

यह दूसरी सबसे आम गलती है।

एंडपॉइंट ENI में सिक्योरिटी ग्रुप है।

उदाहरण के लिए:

endpoint-sg

Inbound：

HTTPS
TCP 443

Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16

इसे और भी बेहतर बनाया जा सकता है।

उदाहरण के लिए, केवल:

10.10.10.0/24
10.20.20.0/24

एंडपॉइंट तक पहुंच की अनुमति दें।

यदि यहां से गुजरना प्रतिबंधित है:

DNS OK
Routing OK
TGW OK

फिर भी:

timeout

18. अंतिम डेटा प्रवाह

उदाहरण के लिए, VPC-A में EC2:

aws ssm describe-instance-information \
    --region ap-northeast-1

एसडीके अनुरोध:

https://ssm.ap-northeast-1.amazonaws.com

① DNS：

ssm.ap-northeast-1.amazonaws.com
↓
Route53 Private Hosted Zone
↓
10.0.10.50

② Routing：

EC2
10.10.1.50
↓
VPC-A route table
↓
10.0.0.0/16 → TGW

③ TGW：

10.0.10.50
↓
Shared VPC attachment

④ Shared VPC：

Endpoint ENI
10.0.10.50

⑤ Endpoint：

PrivateLink
↓
AWS SSM

निम्नलिखित चीजें पूरी प्रक्रिया के दौरान आवश्यक नहीं हैं:

Internet Gateway
NAT Gateway
Public IP

यह इसकी सबसे महत्वपूर्ण विशेषताओं में से एक है। प्राइवेटलिंक का उद्देश्य आईजीडब्ल्यू, एनएटी या सार्वजनिक आईपी पतों की आवश्यकता के बिना एक निजी नेटवर्क के माध्यम से एडब्ल्यूएस सेवाओं तक पहुंच प्रदान करना है।

19. एकाधिक एंडपॉइंट्स को कैसे हैंडल करें?

मान लीजिए आपको इसकी आवश्यकता है:

SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STS

Central VPC：

Network VPC

├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-sts

Route53：

ssm.ap-northeast-1.amazonaws.com
→ SSM Endpoint

ssmmessages.ap-northeast-1.amazonaws.com
→ SSM Messages Endpoint

ec2messages.ap-northeast-1.amazonaws.com
→ EC2 Messages Endpoint

kms.ap-northeast-1.amazonaws.com
→ KMS Endpoint

logs.ap-northeast-1.amazonaws.com
→ Logs Endpoint

secretsmanager.ap-northeast-1.amazonaws.com
→ Secrets Manager Endpoint

फिर पीएचजेड एक साथ जुड़ता है:

VPC-A
VPC-B
VPC-C
VPC-D
...

कुछ AWS सेवाओं की DNS संरचनाएँ अद्वितीय होती हैं, जैसे कि ECR Docker/OCI एंडपॉइंट्स। AWS यह भी बताता है कि कुछ सेवाओं के लिए वाइल्डकार्ड एलियास की आवश्यकता हो सकती है, इसलिए यह मान लेना उचित नहीं है कि सभी एंडपॉइंट्स का केवल एक ही सरल रिकॉर्ड होता है।

20. क्या होगा यदि वे अलग-अलग AWS खाते हों?

उदाहरण के लिए:

Network Account
111111111111

App Account A
222222222222

App Account B
333333333333

वास्तुकला पूरी तरह से स्वीकार्य है।

अनुशंसा करना:

AWS Organizations

Network Account
 ├─ TGW
 ├─ Shared VPC
 ├─ Interface Endpoints
 └─ Route53 PHZ

       ↓ AWS RAM

App Account A
 └─ VPC-A

App Account B
 └─ VPC-B

TGW को निम्न माध्यमों से एक्सेस किया जा सकता है:

AWS Resource Access Manager

शेयर करना।

प्राइवेट होस्टेड ज़ोन के लिए क्रॉस-अकाउंट एसोसिएशन थोड़े अधिक जटिल होते हैं।

21. क्रॉस-अकाउंट पीएचजेड एसोसिएशन

उदाहरण के लिए:

Network Account:
PHZ Z123456

App Account:
VPC vpc-abcdef

नेटवर्क खाता पहले:

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

फिर ऐप खाता:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456 \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef

क्रॉस-अकाउंट प्राइवेट होस्टेड ज़ोन के लिए आधिकारिक AWS प्रक्रिया इस प्रकार है:

PHZ Owner
↓
CreateVPCAssociationAuthorization

VPC Owner
↓
AssociateVPCWithHostedZone

इसके अलावा, यह क्रॉस-अकाउंट ऑपरेशन पूरी तरह से रूट 53 कंसोल पर निर्भर रहकर पूरा नहीं किया जा सकता है; इसके लिए CLI/API/SDK की आवश्यकता होती है।

22. विधि 2: वीपीसी पीयरिंग

यदि आपके पास केवल दो या तीन वीपीसी हैं, तो आपको टीजीडब्ल्यू की आवश्यकता नहीं है।

उदाहरण के लिए:

           Central VPC
          Endpoint VPC
        10.0.0.0/16
          /       \
         /         \
      Peering     Peering
       /             \
   VPC-A             VPC-B
10.10/16           10.20/16

विन्यास:

VPC-A ↔ Central VPC
VPC-B ↔ Central VPC

तब:

VPC-A：

10.0.0.0/16
→ pcx-aaa

Central：

10.10.0.0/16
→ pcx-aaa

10.20.0.0/16
→ pcx-bbb

Endpoint SG：

443
10.10.0.0/16

443
10.20.0.0/16

DNS अभी भी:

PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B

23. पीयरिंग की सबसे बड़ी कमी

यह:

ट्रांजिटिव रूटिंग समर्थित नहीं है।

AWS ने आधिकारिक बयानों में यह बात स्पष्ट कर दी है।

उदाहरण के लिए:

VPC-A
  │
peering
  │
Central
  │
peering
  │
VPC-B

इससे यह निष्कर्ष नहीं निकाला जा सकता कि:

A → Central → B

यह संभव है।

इसलिए, यदि:

2 VPC
3 VPC

झाँकना बहुत आरामदायक है।

अगर:

20 VPC
50 VPC
100 VPC

इसका रखरखाव करना दिन-प्रतिदिन कठिन होता जाएगा।

इसलिए, सामान्य तौर पर कहें तो:

छोटा: वीपीसी पीयरिंग बड़ा: ट्रांजिट गेटवे

24. विधि 3: सीधे एंडपॉइंट डीएनएस का उपयोग करें

एक बहुत ही सरल विधि भी है, जो विशेष रूप से परीक्षण के लिए उपयुक्त है।

एंडपॉइंट बनाने के बाद, AWS कुछ इस तरह का आउटपुट जेनरेट करेगा:

vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

AWS इंटरफेस एंडपॉइंट के लिए क्षेत्रीय और ज़ोन DNS नाम बनाएगा।

इसलिए, जब तक वीपीसी-ए नेटवर्क साझा वीपीसी तक पहुंच सकता है, तब तक यह सीधे निम्न कार्य कर सकता है:

aws ssm describe-instance-information \
  --endpoint-url \
  https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.com

इस तरह आपको इसे खुद करने की भी जरूरत नहीं पड़ेगी:

ssm.ap-northeast-1.amazonaws.com

Private Hosted Zone。

फ़ायदा

बहुत आसान।

इसके लिए आदर्श:

रूटिंग को मान्य करें, SG को मान्य करें, TGW को मान्य करें, एंडपॉइंट को मान्य करें

कमी

एप्लिकेशन के कॉन्फ़िगरेशन में बदलाव करना आवश्यक है।

मूल:

AWS SDK
↓
ssm.ap-northeast-1.amazonaws.com

अब यह इस प्रकार हो जाता है:

AWS SDK
↓
vpce-xxx....

कई एप्लिकेशन को इस तरह से संशोधित करना सुविधाजनक नहीं होता है।

इसलिए, उत्पादन वातावरण सामान्यतः इस प्रकार होता है:

PHZ + Alias

अधिकांश।

25. केंद्रीकृत एंडपॉइंट का सबसे बड़ा लाभ

① अंतिम बिंदु को काफी हद तक कम करें

मान्यता:

20 VPC
15 Interface Endpoints
2 AZ

Distributed：

20 × 15 × 2
=
600 Endpoint AZ instances

केंद्रीकरण:

15 × 2
=
30

अंतर बहुत बड़ा है।

26. लाभ 2: लागत में काफी कमी आ सकती है।

इंटरफ़ेस एंडपॉइंट प्राप्त हुआ:

Endpoint/AZ/hour
+
Data Processing / GB

AWS PrivateLink में प्रत्येक AZ के लिए प्रति घंटे का शुल्क और डेटा प्रोसेसिंग शुल्क लगता है। पहले 1 PB के लिए आधारभूत डेटा प्रोसेसिंग दर लगभग ₹0.96/GB है; प्रति घंटे की दर क्षेत्र के अनुसार बदलती है।

Distributed：

VPC × Service × AZ × endpoint-hour

Central：

Service × AZ × endpoint-hour
+
TGW

जितने अधिक वीपीसी होंगे, एंडपॉइंट्स की संख्या में उतना ही अधिक अंतर होगा।

27. लेकिन TGW मुफ़्त नहीं है।

यहां मौजूद कई आर्किटेक्चरल डायग्राम जानबूझकर इस बिंदु को नजरअंदाज करते हैं।

ट्रांजिट गेटवे को प्राप्त हुआ:

प्रति घंटा संलग्नक दर + डेटा प्रोसेसिंग / जीबी

AWS आधिकारिक तौर पर अटैचमेंट घंटों की संख्या और TGW के माध्यम से प्रवाहित होने वाले डेटा की मात्रा के आधार पर शुल्क लेता है।

इसलिए, वास्तव में जिसकी गणना की जानी चाहिए वह यह है:

प्रति वीपीसी एंडपॉइंट

लागत = वीपीसी की संख्या × एंडपॉइंट्स की संख्या × एजेड की संख्या × एंडपॉइंट प्रति घंटा + प्राइवेटलिंक डेटा

Centralized

लागत = एंडपॉइंट्स की संख्या × AZs की संख्या × एंडपॉइंट की प्रति घंटा लागत + TGW अटैचमेंट की प्रति घंटा लागत + TGW डेटा प्रोसेसिंग + प्राइवेटलिंक डेटा प्रोसेसिंग + संभावित क्रॉस-AZ डेटा

इसलिए:

यदि किसी कंपनी के पास पहले से ही TGW (टाउनशिप गेटवे) है, तो सेंट्रल एंडपॉइंट आमतौर पर बहुत आकर्षक विकल्प होता है।

लेकिन अगर:

यहां केवल 2 वीपीसी, केवल 3 एंडपॉइंट और कोई टीजीडब्ल्यू नहीं है।

एंडपॉइंट लागतों को बचाने के लिए विशेष रूप से TGW का निर्माण करना लागत प्रभावी नहीं हो सकता है।

28. केंद्रीकृत प्रणाली की सबसे बड़ी खामी: विस्फोट त्रिज्या

यह एक बहुत ही महत्वपूर्ण मुद्दा है।

उपस्थित हों:

VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-C

एंडपॉइंट-ए में समस्या है:

केवल A को समस्या है।

केंद्रीकरण:

A ─┐
B ─┼→ Central Endpoint
C ─┘

सेंट्रल एंडपॉइंट, शेयर्ड वीपीसी राउटिंग, डीएनएस या टीजीडब्ल्यू की गलत कॉन्फ़िगरेशन:

A
B
C
D
E
...

उन दोनों को निलंबित किया जा सकता है।

इसलिए:

पैसा बचाने और लागतों को नियंत्रित करने की कीमत साझा बुनियादी ढांचे के लिए विस्फोट के दायरे में वृद्धि है।

AWS ने यह भी विशेष रूप से बताया है कि एक केंद्रीय एंडपॉइंट नीति और विफलता के प्रभावों के दायरे को व्यापक बना सकता है।

29. एंडपॉइंट पॉलिसी भी अधिक जटिल हो जाएगी।

Distributed：

देव वीपीसी एंडपॉइंट → देव अनुमतियाँ प्रोड वीपीसी एंडपॉइंट → प्रोड अनुमतियाँ सिक्योरिटी वीपीसी एंडपॉइंट → सिक्योरिटी अनुमतियाँ

इसका प्रबंधन करना बहुत आसान है।

केंद्रीकरण:

डेवलपमेंट और प्रोडक्शन टेस्ट की सुरक्षा निगरानी के लिए एक KMS एंडपॉइंट...

सभी ने साझा किया।

Endpoint Policy：

Principal
Resource
Action
Conditions

यह और भी जटिल होता जाएगा।

AWS ने इस संबंध में एक विशेष अनुस्मारक भी जारी किया है:

केंद्रीकरण से न्यूनतम विशेषाधिकार वाली एंडपॉइंट नीतियों के प्रबंधन की कठिनाई बढ़ जाती है, और एक एकल एंडपॉइंट नीति का प्रभाव क्षेत्र भी बड़ा होता है; एंडपॉइंट नीति दस्तावेज़ के आकार पर भी सीमाएं होती हैं।

30. सुरक्षा अलगाव भी एक समस्या है।

उदाहरण के लिए:

Production VPC
Development VPC

सभी उपयोग:

Central S3 Interface Endpoint

हालांकि:

IAM
Bucket Policy
Endpoint Policy
SG

अनुमतियों को अभी भी नियंत्रित किया जा सकता है, लेकिन भौतिक/नेटवर्क सीमाएं अब पूरी तरह से स्वतंत्र नहीं हैं।

इसलिए, विशेष रूप से चुनौतीपूर्ण वातावरणों के लिए:

पीसीआई वित्तीय उत्पादन सुरक्षा उपकरण

संभावित डिज़ाइन:

Prod Endpoint VPC

NonProd Endpoint VPC

पूरी कंपनी के बजाय:

एक एंडपॉइंट वीपीसी

31. अनुशंसित उद्यम संरचना

ऐसा नहीं है कि पूरी कंपनी में केवल एक ही व्यक्ति है, बल्कि बात यह है कि:

                   AWS Services
                        │
          ┌─────────────┴──────────────┐
          │                            │
   Prod Endpoint VPC           NonProd Endpoint VPC
          │                            │
        TGW                         TGW
     ┌────┼────┐                 ┌────┼────┐
     │    │    │                 │    │    │
   Prod Prod Prod              Dev  Test Sandbox
   VPC1 VPC2 VPC3

यहां तक ​​की:

Security
Production
NonProduction

अलग से एक साझा एंडपॉइंट वीपीसी बनाएं।

इस तरह हम दोनों बातों को ध्यान में रख सकते हैं:

लागत प्रबंधन सुरक्षा अलगाव विस्फोट त्रिज्या

32. एक और बहुत ही व्यावहारिक समस्या: DNS विरोध।

उदाहरण के लिए, वीपीसी-ए के पास पहले से ही अपना स्वयं का था:

SSM Endpoint
Private DNS = Enabled

फिर आप पुनः संबद्ध करते हैं:

ssm.ap-northeast-1.amazonaws.com

यह केंद्रीय पीएचजेड है।

इससे DNS नेमस्पेस में टकराव हो सकता है।

इसलिए, प्रवासन सामान्यतः इस प्रकार होना चाहिए:

① एक केंद्रीय एंडपॉइंट बनाएं ② एक केंद्रीय pHZ बनाएं ③ एंडपॉइंट-विशिष्ट DNS का परीक्षण करें ④ स्पोक VPC को संबद्ध करें ⑤ DNS सत्यापित करें ⑥ स्पोक VPC के स्वयं के एंडपॉइंट को हटाएं ⑦ सेवाओं को सत्यापित करें ⑧ अगले VPC में माइग्रेट करें

उन सभी को एक साथ हटाने के बजाय।

33. अंतर-क्षेत्रीय संचालन संभव है, लेकिन इसका अत्यधिक उपयोग अनुशंसित नहीं है।

उदाहरण के लिए:

Tokyo VPC
ap-northeast-1

Osaka VPC
ap-northeast-3

सिद्धांत में:

Tokyo VPC
    ↓
TGW
    ↓
TGW Peering
    ↓
Osaka
    ↓
Central Endpoint

AWS निम्नलिखित माध्यमों से क्रॉस-रीजन सेंट्रलाइज्ड एंडपॉइंट आर्किटेक्चर भी प्रदान करता है:

TGW Peering
+
Private Hosted Zones

पूरा करना।

हालांकि, आमतौर पर यह सलाह दी जाती है कि:

Tokyo Endpoint VPC
   ↓
Tokyo VPCs

Osaka Endpoint VPC
   ↓
Osaka VPCs

यानी:

एक क्षेत्र, एक केंद्रीय एंडपॉइंट वीपीसी।

इसलिए:

कम विलंबता, सरल नेटवर्क, बेहतर आपदा अलगाव, अंतर-क्षेत्रीय यातायात लागत में कमी

34. चार विकल्पों की प्रत्यक्ष तुलना

परियोजना प्रति वीपीसी एंडपॉइंट Peering Central TGW Central S3 Gateway
अंतिम बिंदु संख्या बहुत ज़्यादा कुछ कुछ प्रति वीपीसी
प्राइवेटलिंक की लागत उच्च कम कम मुक्त
टीजीडब्ल्यू लागत कोई नहीं कोई नहीं पास होना कोई नहीं
डीएनएस प्रबंधन सरल मध्यम मध्यम यह बहुत सरल है।
नेटवर्क जटिलता सबसे कम मध्यम मध्यम सबसे कम
बड़े पैमाने पर वीपीसी ❌ ❌ ✅ ✅
एकांत ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
Blast Radius छोटा मध्य बड़ा छोटा
एकाधिक खाते कर सकना कर सकना बहुत उपयुक्त प्रत्येक निर्मित
Transitive Routing N/A ❌ ✅ N/A
अनुशंसित वीपीसी की संख्या 1 थोड़ी मात्रा में छोटी राशि मध्यम और बड़ा कोई

35. बड़े पैमाने के वातावरण के लिए उपयुक्त डिजाइन

मान लीजिए कि कंपनी के पास निम्नलिखित हैं:

30 वीपीसी, 5 एडब्ल्यूएस खाते, टोक्यो क्षेत्र

इसे स्थापित किया जा सकता है:

Network Account
│
├─ Transit Gateway
│
├─ Endpoint VPC
│   │
│   ├─ SSM
│   ├─ SSM Messages
│   ├─ EC2 Messages
│   ├─ ECR API
│   ├─ ECR DKR
│   ├─ STS
│   ├─ KMS
│   ├─ Secrets Manager
│   ├─ CloudWatch
│   ├─ CloudWatch Logs
│   ├─ SNS
│   └─ SQS
│
└─ Route53 Private Hosted Zones

तब:

Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
         │
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
         ▼
        TGW
         │
         ▼
 Endpoint VPC
         │
         ▼
 AWS PrivateLink

लेकिन:

S3 Gateway Endpoint
DynamoDB Gateway Endpoint

अब भी इसकी अनुशंसा की जाती है:

प्रत्येक वीपीसी के लिए अलग से बनाया गया

क्योंकि यह मुफ़्त है, और गेटवे एंडपॉइंट को TGW/पीयरिंग के माध्यम से अन्य VPC से उपयोग नहीं किया जा सकता है।

36. संपूर्ण वास्तुकला को 4 परतों के रूप में याद किया जा सकता है।

दरअसल, भविष्य में समस्याओं का निवारण करते समय, आपको केवल इन चार स्तरों को याद रखने की आवश्यकता है:

             ┌─────────────────┐
             │      DNS        │
             │   Route53 PHZ   │
             └────────┬────────┘
                      │
                      ▼
             Endpoint Private IP
                      │
             ┌────────┴────────┐
             │     Routing     │
             │   TGW/Peering   │
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    Security     │
             │ Endpoint SG/NACL│
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │    IAM Policy   │
             │ Endpoint Policy │
             │ Service Policy  │
             └─────────────────┘

यदि पहुँच अनुपलब्ध है, तो कृपया इन चरणों का पालन करें:

① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy

जांच-पड़ताल के माध्यम से आमतौर पर समस्याओं का पता लगाया जा सकता है।

सबसे यादगार वाक्य

एक वीपीसी एंडपॉइंट स्वयं रैम के माध्यम से "कई वीपीसी के साथ साझा" नहीं होता है।

इंटरफ़ेस एंडपॉइंट्स की केंद्रीकृत प्रकृति इस प्रकार है:

Central VPC
    ↓
Interface Endpoint ENI
    ↑
TGW / VPC Peering
    ↑
Other VPCs

फिर से उत्तीर्ण:

Route53 Private Hosted Zone

सभी वीपीसी में:

ssm.ap-northeast-1.amazonaws.com

सभी का विश्लेषण करने पर निम्नलिखित परिणाम सामने आए:

Central VPC Endpoint

इससे पूरी प्रक्रिया पूरी हो जाती है। Shared/Centralized VPC Endpoint。

और S3/DynamoDB गेटवे एंडपॉइंट्स के साथ ऐसा न करें; प्रत्येक VPC के लिए अपना स्वयं का गेटवे एंडपॉइंट बनाएं।क्योंकि यह मुफ़्त है, और AWS स्पष्ट रूप से TGW या पीयरिंग जैसे अन्य माध्यमों से इसके उपयोग को प्रतिबंधित करता है।