VPC Peering

এই লেসন শেষে তুমি পারবে

• VPC peering connection কী, কোথায় চলে (একই বা আলাদা account, একই বা আলাদা Region), আর কেন এর জন্য কোনো gateway, VPN বা বাড়তি hardware লাগে না, সেটা বুঝিয়ে বলতে।
• শুরু থেকে শেষ পর্যন্ত একটা বানাতে: request, accept, দুই VPC-তেই route, security group আর network ACL, আর link-এর ওপারে DNS resolution।
• যে চারটা নিয়মে peering-এর ডিজাইন ভেঙে পড়ে, সেগুলো চিনতে: CIDR overlap চলবে না, transitive না, edge-to-edge routing নেই, আর n(n−1)/2 connection-এর full mesh-এর বিস্ফোরণ।
• Inter-Region peering-এ কী বদলায় (encryption, MTU, security group reference, DNS) আর peering-এর খরচ কত, সেটা বলতে।
• Active অথচ কোনো traffic যাচ্ছে না, এমন peering-এর সমস্যা খুঁজতে, আর কখন peering ঠিক উত্তর আর কখন Transit Gateway, PrivateLink বা VPC sharing, সেটা ঠিক করতে।

#দুটো VPC জোড়ার দরকারই বা কেন

VPC হলো দেয়ালঘেরা একটা network (লেসন ৩.২)। দেয়ালটাই আসল কথা: developer-এর test VPC থেকে production ছোঁয়া যায় না, আর এক team-এর ভুল তার নিজের VPC-র ভেতরেই আটকে থাকে। তাই বেশির ভাগ কোম্পানির শেষমেশ অনেকগুলো VPC হয়, প্রায়ই অনেকগুলো account-এ (প্রতিটা team, environment বা business unit-এর জন্য একটা করে, AWS Organizations দিয়ে সামলানো, লেসন ২০.১)।

আগে বা পরে এর মধ্যে দুটো VPC-কে কথা বলতেই হয়। Payments service-কে analytics team-এর reporting database-এ লেনদেনের তথ্য পাঠাতে হবে। এক VPC-র checkout service-কে আরেক VPC-র fraud-scoring service ডাকতে হবে। কোনো private connection না থাকলে একমাত্র পথ পাবলিক internet: public IP, internet gateway, NAT gateway, traffic AWS থেকে বেরিয়ে আবার ফিরে আসা, আর আক্রমণের জন্য বড় একটা দরজা। এর সবচেয়ে সহজ private বিকল্প হলো VPC peering।

#VPC peering আসলে কী

VPC peering connection হলো ঠিক দুটো VPC-র মধ্যে একটা private network link। একবার বসিয়ে দিলে যেকোনো পাশের instance অন্য পাশের instance-এ পৌঁছায় private IPv4 বা IPv6 address দিয়ে, যেন দুই VPC মিলে একটাই network।

• AWS backbone দিয়ে। Traffic কখনো পাবলিক internet পার হয় না। Peering VPC networking-এর ভেতরেই গাঁথা: এটা gateway না, VPN না, কোনো যন্ত্রও না, তাই এর single point of failure নেই, নিজের কোনো bandwidth-এর বাধাও নেই। সীমা শুধু instance কতটা পাঠাতে পারে।
• একই বা আলাদা account। অন্য VPC-টা তোমার নিজের হতে পারে, অন্য কোনো AWS account-এরও হতে পারে।
• একই বা আলাদা Region। Region পেরিয়ে peering-কে বলে inter-Region peering (নিচে বিস্তারিত)।
• এক জোড়ায় একটাই connection। একই দুটো VPC-র মধ্যে দুটো peering বানানো যায় না, দরকারও নেই: redundant করার মতো কিছুই নেই।
• ID pcx-…। Route table-এ peering connection একটা target হিসেবে দেখা যায়, ঠিক যেভাবে internet gateway (igw-…) বা NAT gateway (nat-…) দেখা যায় (লেসন ৩.৩)।

#Peering connection কীভাবে বানানো হয়

#Request আর accept

একটা peering connection-এর থাকে একজন requester আর একজন accepter:

1. Requester VPC-র মালিক accepter VPC-র নাম দিয়ে (তার VPC ID, আর account বা Region আলাদা হলে সেগুলোও) একটা peering request বানায়।
2. AWS দুই VPC-র CIDR block মিলিয়ে দেখে। কোনোটা overlap করলে request সঙ্গে সঙ্গে fail করে।
3. নইলে request pending-acceptance অবস্থায় অপেক্ষা করে। Accepter VPC-র মালিক accept বা reject করে। কেউ কিছু না করলে ৭ দিনে মেয়াদ শেষ হয়ে যায়।
4. Accept হওয়ার পর অল্প সময় provisioning দেখায়, তারপর হয় active।

কে কী করে, এটা পরীক্ষার প্রশ্নে খুব কাজে লাগে:

• একই account: তুমি নিজেই বানাও, নিজেই accept করো।
• ভিন্ন account: accepter account-কেই accept করতে হবে। Requester তার হয়ে accept করতে পারে না।
• ভিন্ন Region: request বানানো হয় requester-এর Region-এ, আর accept করতে হয় accepter VPC-র Region-এ গিয়ে। Requester-এর Region-এর console-এ খুঁজলে accept করার মতো কিছু পাবে না।
• যেকোনো মালিক যেকোনো সময় active peering delete করতে পারে; সঙ্গে সঙ্গে দুই পাশেরই যোগাযোগ বন্ধ।

#দুই VPC-তেই route

Active peering-এ কোনো route না দেখালে কিছুই যায় না। Connection বানালে কোনো পাশেই route যোগ হয় না।

• VPC A-তে, যেসব route table-এর subnet-কে VPC B-তে পৌঁছাতে হবে, প্রতিটায় একটা route: destination = VPC B-র CIDR, target = pcx-…।
• VPC B-তে, যেসব route table-এর subnet-কে উত্তর দিতে হবে, প্রতিটায় ফেরার route: destination = VPC A-র CIDR, target = সেই একই pcx-…।
• যেকোনো পাশে route না থাকলেই কথোপকথন ভেঙে যায়। সবচেয়ে বিরক্তিকর হলো গ্রহণকারী পাশে route না থাকা: request পৌঁছায়, server সেটা দেখতেও পায়, কিন্তু উত্তরের বাড়ি ফেরার পথ নেই, তাই caller timeout পায়।
• পুরো CIDR route করতেই হবে, এমন না। 10.20.0.0/16-এর বদলে শুধু 10.20.2.0/24 route করলে কেবল database subnet-টাই খোলা থাকে। সাধারণ longest prefix match নিয়মই খাটে (লেসন ৩.৩)।
• প্রত্যেক মালিক শুধু নিজের route table-ই নিয়ন্ত্রণ করে। ভিন্ন account-এর peering-এ দুই team-কেই নিজের অর্ধেক কাজ করতে হয়।

#Security group আর network ACL

Route ঠিক করে packet কোথায় যাবে; firewall ঠিক করে সেটা যেতে দেওয়া হবে কি না (লেসন ৩.৫)।

• গ্রহণকারী instance-এর security group-কে peer-এর traffic allow করতে হবে। Default অবস্থায় অন্য VPC থেকে কিছুই allow করে না।
• একই Region-এ একটা security group rule peer VPC-র security group-কে reference করতে পারে, অন্য account-এর হলেও। ভিন্ন account-এর বেলায় লিখতে হয় account-id/sg-id আকারে, যেমন 111122223333/sg-0aa11bb22।
• Region পেরিয়ে security group reference চলে না: বদলে peer-এর CIDR দাও (যত সরু করা যায়)।
• Peer পরে referenced group-টা মুছে ফেললে, বা peering-টাই মুছে গেলে, rule-টা হয়ে যায় stale security group rule। এটা আর কিছু মেলায় না, কিন্তু তুমি না সরানো পর্যন্ত group-এ থেকে যায় (describe-stale-security-groups এগুলোর তালিকা দেয়)।
• দুই subnet-এর network ACL-কেও traffic allow করতে হবে, আর যেহেতু এরা stateless, ephemeral port-এ ফেরার traffic-ও।

#Peering-এর ওপারে DNS

Instance-রা প্রায়ই একে অপরকে IP দিয়ে না, নাম দিয়ে ডাকে। Default অবস্থায় কোনো instance যদি peer VPC-র একটা instance-এর public DNS hostname (ec2-203-0-113-40.ap-southeast-1.compute.amazonaws.com) ব্যবহার করে, নামটা resolve হয় public IP-তে, আর traffic peering ছেড়ে internet দিয়ে যাওয়ার চেষ্টা করে।

• Peering connection-এর DNS resolution চালু করো। Console-এ: Edit DNS settings → Requester DNS resolution (“Allow accepter VPC to resolve the DNS of requester VPC”) আর Accepter DNS resolution (“Allow requester VPC to resolve the DNS of accepter VPC”)। API-তে এটা প্রতিটা পাশের peering option-এর AllowDnsResolutionFromRemoteVpc।
• এরপর অন্য VPC থেকে খুঁজলে peer instance-এর public hostname resolve হয় তার private IP-তে, আর traffic যায় peering দিয়ে।
• শর্ত: peering active থাকতে হবে, দুই VPC-তেই DNS resolution আর DNS hostnames চালু থাকতে হবে, আর প্রত্যেক মালিক নিজের পাশের option নিজে চালু করে।
• Inter-Region peering-এ, বা যে VPC-র CIDR private RFC 1918 range-এর বাইরে, সেখানে private DNS hostname-কে private IP-তে resolve করাতেও এই option লাগে।
• Peer VPC-র Amazon DNS server-কে সরাসরি query করা যায় না। Private hosted zone-এর জন্য zone-টা দুই VPC-র সাথেই associate করো (Route 53, অধ্যায় ৮)।

#যে চারটা নিয়মে peering টেকে বা ভাঙে

#নিয়ম ১: CIDR overlap চলবে না, একটুও না

CIDR block overlap করে এমন দুই VPC-র মধ্যে AWS peering বানাতেই দেয় না (লেসন ৩.১)। কারণটা routing: দুই VPC-রই যদি 10.0.5.9 থাকে, তাহলে VPC A-র route table-এ লাগবে 10.0.0.0/16 → pcx, অথচ ওই range তো আগে থেকেই তার নিজের local route। কোনো router-ই “আমার 10.0.5.9” আর “তোমার”টা আলাদা করতে পারে না।

• হুবহু এক range overlap করে (10.0.0.0/16 আর 10.0.0.0/16)।
• একটার ভেতরে আরেকটা থাকলেও overlap (10.0.0.0/16 আর 10.0.128.0/20)।
• Secondary CIDR block-ও গোনা হয়: এক VPC-র যেকোনো IPv4 বা IPv6 block অন্যটার যেকোনো block-এর সাথে মিলে গেলেই peering বাতিল, এমনকি তুমি যদি শুধু না-মেলা block-গুলো route করার কথা ভাবো, তবুও।
• VPC-র primary CIDR পরে বদলানো যায় না। আগে থেকে overlap থাকলে সমাধান re-IP: খালি range-এ নতুন VPC বানিয়ে workload সরিয়ে নাও।

On-premises network-এর বেলাতেও একই নিয়ম: VPC-র range আর ডেটা সেন্টারের range overlap করলে VPN আর Direct Connect-এর routing ঠিক একইভাবে ভেঙে যায় (লেসন ২২.৪ আর ২২.৫)। কেউ VPC বানানোর আগেই পুরো কোম্পানির জন্য একটা address plan করো, যেমন VPC IP Address Manager (IPAM) দিয়ে।

#নিয়ম ২: peering transitive না

A-র সাথে B-র peering, আর B-র সাথে C-র peering থাকলে A C-তে পৌঁছাতে পারে না। Peering শুধু সেই packet পৌঁছে দেয়, যার গন্তব্য peer VPC-র ভেতরে। A থেকে C-র ঠিকানায় যাওয়া packet A–B link-এই ফেলে দেওয়া হয়, যে যা-ই route বসাক, কারণ B সেটা হাতেই পায় না যে এগিয়ে দেবে।

A আর C-কে কথা বলাতে হলে সরাসরি একটা A–C peering বানাও (দুই পাশে route সহ), নয়তো সবাইকে একটা Transit Gateway-তে লাগাও, যেটা attachment-গুলোর মধ্যে সত্যিই route করে (লেসন ২২.৬)।

#নিয়ম ৩: edge-to-edge routing নেই

Peer তোমার VPC-র ভেতরের address-এ পৌঁছাতে পারে, তার পেছনের কিছুতে না। তোমার VPC-কে সে অন্য কোথাও যাওয়ার রাস্তা বানাতে পারে না। VPC A-র নিচের যেকোনোটা থাকলেও VPC B peering দিয়ে সেটা ব্যবহার করতে পারবে না:

• internet gateway (B A হয়ে internet-এ যেতে পারবে না);
• NAT gateway বা NAT instance;
• কোম্পানির network-এ যাওয়ার Site-to-Site VPN বা Direct Connect connection;
• S3 বা DynamoDB-র gateway endpoint (লেসন ১০.১০-এ এটা দেখেছিলে)।

যা চলে: peer-এর ভেতরে যার সত্যিকারের address আছে, এমন সবকিছু: instance, database, internal load balancer, বা একটা interface endpoint-এর ENI, কারণ এর private IP peer VPC-র ভেতরেই।

#নিয়ম ৪: full mesh খুব দ্রুত বাড়ে

Peering transitive না বলে যে দুটো VPC-কে কথা বলতে হবে, প্রতিটা জোড়ার নিজস্ব connection লাগে। n-টা VPC-র সবাইকে সবার কাছে পৌঁছাতে হলে full mesh-এ লাগে n(n−1)/2টা peering, প্রতিটার দুই পাশে route সহ:

Quota ব্যাপারটাকে আরও কঠিন করে: একটা VPC-র default অবস্থায় ৫০টা active peering connection থাকতে পারে, বাড়িয়ে ১২৫ পর্যন্ত, আর ২৫টা outstanding request। তাই ১২৬টার বেশি VPC-র full mesh অসম্ভব, আর ৫১-র বেশি হলেই quota বাড়াতে হয়, সঙ্গে হাজার হাজার route (route table-এরও নিজের route-সংখ্যার সীমা আছে)। এ কারণেই “জটিল VPC peering mesh সহজ করো” বা “শত শত VPC” দেখলে উত্তর Transit Gateway (লেসন ২২.৬): ১০০টা VPC হয়ে যায় একটা hub-এ ১০০টা attachment।

#Inter-Region peering

আলাদা Region-এর VPC-র মধ্যেও peering চলে, একই বা আলাদা account-এ, শুধু কয়েকটা পার্থক্য আছে:

• Encrypted। Inter-Region traffic AWS নিজেই encrypt করে, আর সেটা থাকে AWS global backbone-এ, এখানেও single point of failure বা bandwidth-এর বাধা নেই।
• Accept করতে হয় accepter-এর Region-এ, ওপরে যেমন বলা হয়েছে।
• Region পেরিয়ে security group reference চলে না: CIDR ব্যবহার করো।
• MTU: Region-এর ভেতরে jumbo frame ৯,০০১ byte পর্যন্ত, Region-এর মধ্যে ৮,৫০০ byte।
• DNS: private hostname-কে private IP-তে resolve করাতেও peering-এ DNS resolution চালু করতে হয়।
• খরচ: traffic-এর বিল হয় inter-Region data transfer-এর রেটে।

#Peering-এর খরচ কত

• Peering connection বানাতে কোনো খরচ নেই, ঘণ্টার কোনো ভাড়াও নেই। Transit gateway-র মতো GB-প্রতি processing খরচও নেই।
• একই Availability Zone-এর ভেতরের data transfer ফ্রি, ভিন্ন account হলেও (মে ২০২১ থেকে)। AZ মেলানো হয় AZ ID দিয়ে (যেমন aps1-az1), AZ-এর নাম দিয়ে না, কারণ এক account-এর ap-south-1a অন্য account-এ অন্য কোনো physical AZ হতে পারে।
• Peering দিয়ে cross-AZ traffic-এর বিল হয় Region-এর অন্য যেকোনো cross-AZ traffic-এর মতোই, প্রতি দিকে GB-প্রতি প্রায় $০.০১।
• Inter-Region traffic-এর বিল হয় পাঠানো Region-এর inter-Region data transfer রেটে (অনেক Region-এ GB-প্রতি প্রায় $০.০২, কোথাও কোথাও বেশি)।
• Transit gateway-র সাথে তুলনা করলে (attachment-hour, সাথে GB-প্রতি প্রায় $০.০২ processing), দুটো VPC-র মধ্যে প্রচুর ডেটা সরাতে peering-ই সবচেয়ে সস্তা। লেসন ২২.৮ (network costs) এই সংখ্যাগুলো পাশাপাশি রাখে। দাম বদলায়: তোমার Region-এর জন্য VPC আর EC2-র pricing page দেখে নিও।

#কোথায় গোলমাল হয়

• Peering pending-acceptance-এ আটকে: accepter account কখনো accept করেনি, বা ভুল Region-এ খুঁজছে। ৭ দিন পর request-এর মেয়াদ শেষ, নতুন করে বানাতে হবে।
• Request সঙ্গে সঙ্গে fail: CIDR overlap, ভুলে যাওয়া কোনো secondary block বা IPv6 block সহ।
• Active, অথচ কিছুই যায় না: এক পাশে route নেই, অথবা route বসানো হয়েছে main route table-এ, অথচ subnet ব্যবহার করে একটা custom route table।
• Server connection দেখে, client timeout পায়: গ্রহণকারী VPC-তে ফেরার route নেই।
• Route ঠিক, তবু timeout: গ্রহণকারীর security group peer-কে allow করে না, অথবা network ACL traffic বা ephemeral port-এ তার ফেরাটা আটকে দেয়।
• Security group rule বাতিল: অন্য Region-এর peer VPC-র security group reference করা হয়েছে। CIDR ব্যবহার করো।
• Traffic উল্টো internet দিয়ে যায়: app public DNS নাম বা public IP ব্যবহার করছে; peering-এ DNS resolution চালু করো, private IP ব্যবহার করো। Peer-এর public IP-তে যাওয়া traffic internet gateway দিয়ে বেরোয়, আর internet-মুখী transfer হিসেবে বিল হয়।
• তৃতীয় VPC-তে পৌঁছানো যায় না: কেউ ধরে নিয়েছিল peering transitive।
• Peer থেকে internet বা on-premises-এ যাওয়া যায় না: কেউ ধরে নিয়েছিল edge-to-edge routing চলে।
• Peer group মুছে ফেললে বা peering মুছে গেলে stale security group rule: পরিষ্কার করে ফেলো।
• Region-এর মধ্যে বড় packet হারিয়ে যায়: inter-Region peering-এ ৮,৫০০ byte-এর বেশি jumbo frame; Path MTU Discovery-কে কাজ করতে দাও (ICMP “fragmentation needed” allow করো)।

#System design-এ এটা কীভাবে কাজে লাগে

• Prod আর analytics, বা app আর shared database: ভারী, কম-latency traffic-ওয়ালা দুটো VPC। একই AZ-এ peering ফ্রি, processing খরচও নেই, তাই একটা ব্যস্ত জোড়ার জন্য এটা hub-কে হারিয়ে দেয়।
• হাতে গোনা কয়েকটা VPC-র জন্য shared service: কয়েকটা application VPC প্রত্যেকে একটা shared-services VPC-র সাথে peered (directory, CI runner, monitoring)। Application VPC-গুলো এর মধ্য দিয়ে একে অপরের কাছে যেতে পারে না, আর অনেক সময় ঠিক এই আলাদা থাকাটাই চাওয়া হয়।
• Region পেরিয়ে replication-এর পথ: database replica, cache warming বা file sync দুই Region-এর মধ্যে inter-Region peering দিয়ে, encrypted, কোনো VPN appliance ছাড়াই।
• Partner integration: একটা data feed-এর জন্য দুই কোম্পানির account peered, প্রত্যেকে নিজের route আর security group নিজে সামলায়। শুধু একটা service খুলতে হলে, বা range overlap করলে, PrivateLink বেশি পরিষ্কার।
• বড় পরিসরে: অনেক VPC আর hybrid link-এর জন্য Transit Gateway, আর যে কয়েকটা VPC জোড়া সবচেয়ে বেশি ডেটা সরায়, team-রা তাদের জন্য transit gateway-র পাশাপাশি peering রাখে, GB-প্রতি processing খরচ এড়াতে।

#Peering, নাকি অন্য কিছু?

#নিজে করে দেখো

# 1. In the prod account (ap-south-1): request a peering with the analytics account's VPC
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --peer-vpc-id vpc-0f9e8d7c6b5a43210 \
  --peer-owner-id 444455556666
# {
#   "VpcPeeringConnection": {
#     "VpcPeeringConnectionId": "pcx-0a1b2c3d4e5f60718",
#     "Status": { "Code": "initiating-request", "Message": "Initiating Request to 444455556666" },
#     "RequesterVpcInfo": { "CidrBlock": "10.10.0.0/16", "OwnerId": "111122223333" }, ...

# 2. In the analytics account: accept it (for cross-Region, run this in the accepter's Region)
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
# "Status": { "Code": "provisioning", "Message": "Provisioning" }

# 3. Routes on BOTH sides
aws ec2 create-route --route-table-id rtb-0aaa1111example \
  --destination-cidr-block 10.20.0.0/16 --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
aws ec2 create-route --route-table-id rtb-0bbb2222example \
  --destination-cidr-block 10.10.1.0/24 --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718
# { "Return": true }

# 4. Security group in the analytics VPC: allow PostgreSQL from the prod app's security group
aws ec2 authorize-security-group-ingress --group-id sg-0ccc3333example \
  --ip-permissions 'IpProtocol=tcp,FromPort=5432,ToPort=5432,UserIdGroupPairs=[{GroupId=sg-0aa11bb22example,UserId=111122223333,VpcPeeringConnectionId=pcx-0a1b2c3d4e5f60718}]'

# 5. DNS: each owner enables resolution for its own side (accepter side shown)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0a1b2c3d4e5f60718 \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

# 6. Inter-Region: request from Mumbai to a VPC in Singapore, then accept in Singapore
aws ec2 create-vpc-peering-connection --region ap-south-1 \
  --vpc-id vpc-0a1b2c3d4e5f67890 --peer-vpc-id vpc-0123456789abcdef0 \
  --peer-region ap-southeast-1
aws ec2 accept-vpc-peering-connection --region ap-southeast-1 \
  --vpc-peering-connection-id pcx-0f9e8d7c6b5a43210

# 7. Check state, and find stale security group rules
aws ec2 describe-vpc-peering-connections \
  --query "VpcPeeringConnections[].[VpcPeeringConnectionId,Status.Code]" --output table
aws ec2 describe-stale-security-groups --vpc-id vpc-0f9e8d7c6b5a43210

Prod VPC-র একটা instance থেকে private address দিয়ে পথটা পরীক্ষা করো:

$ dig +short ip-10-20-2-30.ap-south-1.compute.internal
10.20.2.30
$ nc -zv 10.20.2.30 5432
Connection to 10.20.2.30 5432 port [tcp/postgresql] succeeded!
$ traceroute -n 10.20.2.30
 1  10.20.2.30  0.612 ms  0.540 ms  0.533 ms

traceroute-এ একটাই hop, এটাই আসল কথা: peering router না, তাই মাঝখানে বাড়তি কোনো hop নেই। nc ঝুলে থাকলে checklist ধরে এগোও: এই পাশের route, অন্য পাশের ফেরার route, security group, network ACL।

#সারসংক্ষেপ

মূল কথাগুলো

• VPC peering = AWS backbone দিয়ে ঠিক দুটো VPC-র মধ্যে private link; একই বা আলাদা account, একই বা আলাদা Region; gateway নেই, single point of failure নেই, bandwidth-এর বাধা নেই; এক জোড়ায় একটাই connection।
• Request → accept (ভিন্ন account: accepter accept করে; ভিন্ন Region: accepter-এর Region-এ accept; ৭ দিনে request-এর মেয়াদ শেষ)।
• দুই VPC-তেই route (যে subnet route table-এর দরকার, প্রতিটায়; পুরো CIDR বা একটা subnet), তারপর security group (peer SG reference শুধু একই Region-এ, ভিন্ন account-এ account/sg-id) আর network ACL।
• Peering-এর DNS resolution option public hostname-কে private IP-তে resolve করায়; Region পেরিয়ে private নামের জন্য এটা বাধ্যতামূলক।
• CIDR overlap চলবে না, আংশিকও না, secondary block-এও না; সমাধান re-IP, বা একটা service-এর জন্য PrivateLink। On-premises range-এও একই নিয়ম।
• Transitive না: A–B + B–C ≠ A–C। Edge-to-edge routing নেই: peer-এর IGW, NAT, VPN, Direct Connect বা gateway endpoint চলবে না।
• Full mesh = n(n−1)/2: ১০টা VPC = ৪৫, ১০০টা = ৪,৯৫০; quota প্রতি VPC-তে ৫০টা active (১২৫ পর্যন্ত) → অনেক VPC = Transit Gateway।
• Inter-Region: encrypted, MTU ৮,৫০০, SG reference নেই, inter-Region transfer-এর খরচ।
• খরচ: ঘণ্টার খরচ নেই, processing খরচ নেই; একই AZ (AZ ID দিয়ে) ফ্রি; cross-AZ প্রতি দিকে ~$০.০১/GB; দুটো ব্যস্ত VPC-র জন্য সবচেয়ে সস্তা।

নিজেকে যাচাই করো: VPC peering৩০টি প্রশ্ন