Transit Gateway

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

• বোঝাতে, VPC peering-এর mesh কেন একসময় আর বাড়ানো যায় না (n(n−1)/2টা connection, VPC-প্রতি quota, VPN আর Direct Connect মিলে জট পাকানো “spaghetti”), আর transit gateway কীভাবে সেটাকে transitive routing-ওয়ালা একটা regional hub-and-spoke বানিয়ে দেয়।
• Attachment-এর ধরনগুলো চিনতে (VPC, Site-to-Site VPN, Direct Connect gateway, Connect, peering, আর নতুন VPN Concentrator ও Network Firewall attachment), আর কোনটা কীসের জন্য।
• Association, propagation, static আর blackhole route দিয়ে transit gateway route table সাজাতে, যাতে dev কখনো prod-এ না যায় কিন্তু দুজনেই shared services-এ যায়; আর প্রতিটা packet আসা-যাওয়ার পথে যে দুটো করে route table পেরোয়, সেখানে সমস্যা খুঁজতে।
• এক Region-এর transit gateway-কে আরেক Region-এরটার সাথে peer করতে, আর AWS RAM দিয়ে অন্য account-এর সাথে share করতে।
• ECMP দিয়ে Site-to-Site VPN-এর bandwidth যোগ করতে (আর virtual private gateway কেন পারে না তা বলতে), আর connection, tunnel আর flow ধরে হিসাব করতে।
• একটা Direct Connect line শত শত VPC আর অনেক account-এর মধ্যে ভাগ করে দিতে: transit VIF → Direct Connect gateway → transit gateway → RAM।
• পরীক্ষা আর বাস্তব ঝামেলায় যেসব খুঁটিনাটি আসে, সেগুলো জানতে: multicast, SD-WAN-এর জন্য Connect, MTU 8500 বনাম 1500, appliance mode, দাম, quota, আর কখন Cloud WAN, VPC sharing, PrivateLink বা VPC Lattice বেশি মানানসই।

#Hub কেন: যখন peering আর টানে না

লেসন ২২.১-এ দেখেছ, VPC peering হলো দুটো VPC-র মধ্যে private, সস্তা, সরাসরি একটা যোগাযোগ, আর সেটা transitive না: A-র peering B-র সাথে, B-র peering C-র সাথে থাকলেও A, C-তে যেতে পারে না। তিনটা VPC থাকলে এতে কোনো সমস্যা নেই। কোম্পানি বড় হলে ঝামেলা শুরু হয়:

• Mesh ফুলে-ফেঁপে ওঠে। প্রতিটা VPC-কে বাকি সবার কাছে পৌঁছাতে হলে n-টা VPC-র জন্য লাগে n(n−1)/2টা peering: ১০টা VPC-তে ৪৫টা, ১০০টা VPC-তে ৪,৯৫০টা। প্রতিটার request পাঠাতে হয়, accept করতে হয়, দুই দিকেই route বসাতে হয়।
• Quota এমনিতেই থামিয়ে দেয়। একটা VPC-তে সর্বোচ্চ ১২৫টা active peering থাকতে পারে (default ৫০), তাই ১২৬টার বেশি VPC-র পুরো mesh বানানোই অসম্ভব।
• Hybrid link-ও বাড়তে থাকে। একটা virtual private gateway একটাই VPC-তে লাগে (লেসন ২২.৪), আর peering-এ edge-to-edge routing নেই, তাই এক VPC তার peer-এর VPN বা Direct Connect ব্যবহার করতে পারে না। যে যে VPC-র ডেটা সেন্টার লাগবে, প্রত্যেকের নিজের VPN connection বা নিজের virtual interface লাগে। Slide-এ ঠিক এই ছবিটাই আঁকা: VPN connection, peering আর একটা Direct Connect gateway একটার ওপর আরেকটা এমনভাবে জড়িয়ে গেছে যে কোন packet কোন পথে যাচ্ছে, কেউ বলতে পারে না।

AWS Transit Gateway এই mesh-এর জায়গায় একটা তারা (star) বসায়। প্রতিটা VPC, VPN আর Direct Connect gateway একবারই যুক্ত হয়, একটা regional hub-এর সাথে, আর hub-টা নিজেই তাদের মধ্যে route করে। Hub দিয়ে routing transitive: যা যা attach করা আছে, hub-এর route table যতটা অনুমতি দেয়, তারা সবাই একে অন্যের কাছে পৌঁছাতে পারে।

#Transit gateway আসলে কী

Transit gateway হলো একটা regional virtual router, যেটা AWS তোমার হয়ে চালায়। এটা কাজ করে layer 3-এ: প্রতিটা packet-এর destination IP address সে একটা transit gateway route table-এ খোঁজে, তারপর মিলে যাওয়া attachment-এ পাঠিয়ে দেয়। Traffic বাড়লে নিজেই বড় হয়, নিজের Region-এর ভেতরে highly available, আর IPv4, IPv6 দুটোই route করে।

• Regional। একটা transit gateway একটা Region-এ থাকে। Region জুড়তে হলে transit gateway peer করতে হয় (নিচে আছে)।
• Cross-account। একটা account (সাধারণত একটা central network account) এর মালিক, আর AWS RAM দিয়ে share করে; অন্য account-গুলো নিজেদের VPC attach করে।
• বিশাল। Default হিসেবে একটা transit gateway-তে ৫,০০০টা attachment, আর প্রতি AZ-এ VPC attachment-প্রতি ১০০ Gbps পর্যন্ত।

#কী কী attach করা যায়

প্রথম পাঁচটা পুরোনো তালিকা, পরীক্ষাও এগুলো নিয়েই প্রশ্ন করে। শেষ দুটো সাম্প্রতিক সংযোজন, চিনে রাখা ভালো।

#একটা VPC attachment, ধাপে ধাপে

1. প্রতি AZ-এ একটা subnet বাছো। Transit gateway ওই subnet-এ একটা network interface বসায় (একটা private IP সহ)। একটা AZ চালু হলে ওই AZ-এর সব subnet attachment-টা ব্যবহার করতে পারে; যে AZ তুমি চালু করোনি, সেখানকার resource transit gateway-তে পৌঁছাতেই পারে না। AWS-এর পরামর্শ: attachment-এর জন্য প্রতি AZ-এ একটা ছোট আলাদা subnet (/28), যার নিজের route table আর খোলা network ACL থাকবে, যাতে application subnet-এর নিয়ম attachment-এর পথে বাধা না দেয়।
2. Transit gateway route table-এ attachment-টা associate আর propagate করো (পরের অংশ)। Default setting থাকলে দুটোই default route table-এ নিজে থেকে হয়ে যায়।
3. VPC-র subnet route table-এ route যোগ করো। VPC attach করলে তার route table একটুও বদলায় না। যে subnet hub ব্যবহার করবে, তার route table-এ 10.0.0.0/8 → tgw-…-এর মতো একটা route লাগবেই। নতুন attachment “কাজ করছে না”, এই অভিযোগের সবচেয়ে বড় কারণ এটাই।

তাহলে দুটো VPC-র মধ্যে প্রতিটা packet চারবার route খোঁজে: উৎস subnet-এর route table, উৎস attachment যে transit gateway route table-এর সাথে associated সেটা, আর ফেরার পথে গন্তব্য subnet-এর route table এবং তার attachment যে transit gateway route table-এর সাথে associated সেটা। এর যেকোনো একটায় route না থাকলে আসে timeout, যেটা দেখতে হুবহু firewall-এর সমস্যার মতো।

#Transit gateway route table

একটা transit gateway-তে কয়েকটা route table থাকতে পারে (default ২০টা)। প্রতিটা আলাদা একটা routing এলাকা, আর দুটো setting attachment-কে এদের সাথে জোড়ে।

#Association আর propagation

• Association: প্রতিটা attachment ঠিক একটা route table-এর সাথে associated। কোনো packet ওই attachment দিয়ে ঢুকলে, transit gateway তার গন্তব্য খোঁজে ওই table-এ। Association-এর প্রশ্ন: “কোথায় খুঁজব”।
• Propagation: একটা attachment তার route এক বা একাধিক route table-এ propagate করতে পারে। VPC attachment propagate করে তার CIDR; BGP-ওয়ালা VPN বা Direct Connect gateway attachment propagate করে তোমার router যে prefix advertise করে সেগুলো। Propagation-এর প্রশ্ন: “কে আমাকে খুঁজে পাবে”।

একটা route table অনেক attachment-এর সাথে associated থাকতে পারে, অনেকের কাছ থেকে propagation-ও পেতে পারে। Default setting দিয়ে transit gateway বানালে (default route table association আর default route table propagation দুটোই চালু), প্রতিটা নতুন attachment default route table-এর সাথে associated হয় আর সেখানেই propagate করে: একটা চ্যাপ্টা network, যেখানে সবাই সবার কাছে পৌঁছায়।

#Static, propagated আর blackhole route

• Propagated route attachment-এর সাথে আসে-যায় (আর BGP-র সাথে)।
• Static route তুমি নিজে যোগ করো, যেমন একটা summary 0.0.0.0/0 → egress VPC attachment, বা peering attachment-এর দিকে যেকোনো route (peering কখনো propagate করে না)।
• Blackhole route হলো এমন একটা static route, যেটা মিলে যাওয়া traffic ফেলে দেয়। এটা দিয়ে নিশ্চিত করো যে কোনো table থেকে একটা prefix-এ কখনো পৌঁছানো যাবে না, পরে কেউ propagation যোগ করলেও; বা কোনো VPC hack হলে কয়েক সেকেন্ডে তাকে আলাদা করে দাও।

কয়েকটা route মিলে গেলে transit gateway আগে নেয় সবচেয়ে নির্দিষ্ট prefix। একই prefix হলে static route propagated route-কে হারায় (তাই blackhole জেতে), আর propagated route-গুলোর মধ্যে AWS পছন্দ করে এই ক্রমে: VPC, তারপর Direct Connect gateway, তারপর Connect, তারপর Site-to-Site VPN। একই ধরনের BGP route-এর মধ্যে ছোট AS path জেতে। এজন্যই একই prefix Direct Connect আর VPN দুই দিক থেকে শিখলে transit gateway traffic পাঠায় Direct Connect দিয়ে, আর VPN থাকে backup হয়ে (লেসন ২২.৫)।

#ভাগ করা: dev, prod আর shared services

Default দুটো বন্ধ করে প্রতিটা নিরাপত্তা-অঞ্চলের জন্য একটা করে route table বানালে network-এর ভেতরেই ভাগাভাগি (segmentation) তৈরি হয়, যেটা নিয়ন্ত্রণ করে network account, প্রতিটা application team না।

এবার নিজে বানাও। চ্যাপ্টা design থেকে শুরু করো, সব জোড়া যাচাই করো, তারপর কারও উত্তর আটকে না দিয়ে dev-কে আলাদা করো।

#Region আর account পেরিয়ে

#Transit gateway peering

Transit gateway regional, তাই Mumbai আর Singapore-এ কাজ করা একটা কোম্পানি প্রতি Region-এ একটা transit gateway চালায়, আর একটা peering attachment দিয়ে দুটোকে জোড়ে:

• এক দিক peering-এর request পাঠায় (অন্য account বা অন্য Region হতে পারে), অন্য দিক সেটা accept করে।
• Peering attachment শুধু static route নেয়: propagation নেই, BGP নেই। প্রতিটা দিকের route table-এ অন্য দিকের CIDR-এর জন্য একটা static route যোগ করো।
• Inter-Region traffic থাকে AWS backbone-এ, encrypted, আর কোনো একক দুর্বল বিন্দু নেই। খরচ: inter-Region data transfer আর পাঠানো দিকের transit gateway-র data processing; যে দিক পায়, সে processing-এর টাকা নেয় না।
• Peering hub দুটোর ভেতর দিয়ে transitive: Mumbai transit gateway-র একটা VPN, Singapore-এ attach করা VPC-তে পৌঁছাতে পারে, যদি দুই route table-এই route থাকে। VPC peering-এর সাথে তুলনা করো, যেখানে এক VPC কখনো তার peer-এর VPN ব্যবহার করতে পারে না।
• দুটো transit gateway-র মধ্যে peering থাকতে পারে একটাই। একই Region-এর ভেতরেও peering চলে (২০২১ থেকে), যেমন দুই ব্যবসা-বিভাগের hub জুড়তে, আর একটা transit gateway একটা Cloud WAN core network-এর সাথেও peer করতে পারে।
• প্রতিটা transit gateway-কে আলাদা Amazon-side ASN দাও; routing পড়া সহজ হয়, কিছু design-এ এটা লাগেই।

#AWS RAM দিয়ে transit gateway share করা

অনেক account-এর চেনা design-এ একটা network account থাকে, যে transit gateway, তার route table, VPN আর Direct Connect attachment-এর মালিক। সে AWS Resource Access Manager দিয়ে transit gateway অন্য account-এর সাথে share করে (লেসন ২০.১):

1. Network account transit gateway দিয়ে একটা resource share বানায়, তাতে organization, একটা OU বা নির্দিষ্ট কিছু account যোগ করে। Organization-এর ভেতরে (sharing চালু থাকলে) কোনো invitation লাগে না; বাইরের account-কে invitation accept করতে হয়।
2. প্রতিটা application account নিজের VPC থেকে share করা transit gateway-তে একটা VPC attachment বানায়।
3. Network account attachment-টা accept করে (বা auto accept shared attachments চালু রাখে), আর ঠিক করে সেটা কোন route table-এর সাথে associated হবে আর কোথায় propagate করবে।

Application account-গুলো transit gateway-র route table দেখতেও পারে না, বদলাতেও পারে না: ভাগাভাগির চাবি থাকে network team-এর হাতে। Attachment-এর ঘণ্টার দাম আর তার VPC থেকে পাঠানো traffic-এর data processing দেয় VPC-র মালিক।

#Transit gateway-তে Site-to-Site VPN: ECMP

ECMP (equal-cost multi-path) routing মানে: একই গন্তব্যে যাওয়ার কয়েকটা সমান ভালো পথ থাকলে router সবগুলো একসাথে ব্যবহার করে, flow-গুলো ওদের মধ্যে ভাগ করে দেয়। এতে দুটো লাভ: মোট bandwidth বাড়ে, আর কোনো পথ মরে গেলে তাকে দল থেকে সরিয়ে দিলেই হয়, তাই failover দ্রুত।

• Virtual private gateway ECMP সমর্থন করে না। এর VPN connection-এ দুটো tunnel থাকে, কিন্তু AWS traffic পাঠায় একটা দিয়ে; অন্যটা standby (active/passive)। একই VGW-তে আরও VPN connection যোগ করলে standby পথ বাড়ে, bandwidth না। একটা standard tunnel সর্বোচ্চ ১.২৫ Gbps বয়, ছাদ ওটাই।
• Transit gateway VPN attachment-এ ECMP সমর্থন করে। Transit gateway-তে VPN ECMP support চালু থাকলে (default চালু), VPN connection-গুলোতে dynamic routing (BGP) থাকলে, আর প্রতিটা tunnel-এ একই prefix একই AS path দিয়ে advertise করলে transit gateway সব tunnel একসাথে ব্যবহার করে (active/active)। AWS-এর দিকে যাওয়া traffic-এর জন্য তোমার নিজের router-কেও ECMP করতে হবে।
• Bandwidth tunnel ধরে যোগ হয়। Transit gateway-তে একটা VPN connection তার দুটো tunnel-ই ব্যবহার করে: ২ × ১.২৫ = ২.৫ Gbps। দুটো connection = ৪টা tunnel = ৫ Gbps; তিনটা connection = ৭.৫ Gbps। VGW-র সাথে তুলনা করো: যত connection-ই দাও, ১.২৫ Gbps।
• Flow-প্রতি সীমা থেকেই যায়। ECMP ভাগ করে flow (একই উৎস আর গন্তব্য address, port আর protocol), packet না। একটা TCP connection সবসময় একটাই tunnel দিয়ে যায়, প্রায় ১.২৫ Gbps-এর বেশি কখনো ওঠে না। সব pipe ভরতে parallel stream চালাও।
• Static routing মানে ECMP নেই। Transit gateway-তে ECMP-এর জন্য BGP লাগে।

#একটা Direct Connect line অনেক account-এ ভাগ করা

Direct Connect line দামি, আসতে সপ্তাহের পর সপ্তাহ লাগে (লেসন ২২.৫)। শত শত account-ওয়ালা একটা organization প্রতিটা account-এর জন্য একটা করে কিনতে পারে না, আর private virtual interface-ও বড় হয় না: প্রতিটা পৌঁছায় একটা VGW-তে (বা VGW-এর সাথে associated একটা Direct Connect gateway-তে), আর একটা connection-এ এমন interface সীমিত সংখ্যায় রাখা যায়। যে pattern বড় হতে পারে:

1. Transit virtual interface

   Direct Connect connection-এ একটা transit VIF বানাও: নিজের VLAN আর BGP session সহ। Private VIF transit gateway-তে পৌঁছাতে পারে না; পারে শুধু transit VIF।

2. Direct Connect gateway

   Transit VIF-টা একটা Direct Connect gateway-তে লাগাও, যেটা একটা global জিনিস।

3. Transit gateway-র সাথে associate করো

   Direct Connect gateway-কে network account-এর transit gateway-র সাথে associate করো, আর allowed prefixes তালিকাটা লেখো: transit gateway নিজে থেকে তার VPC-গুলোর CIDR তোমার network-কে জানায় না, জানায় শুধু এই তালিকার prefix (সাধারণত 10.0.0.0/8-এর মতো একটা summary)। একটা Direct Connect gateway সর্বোচ্চ ৬টা transit gateway-র সাথে associate হতে পারে, যেমন প্রতি Region-এ একটা।

4. RAM দিয়ে transit gateway share করো

   AWS RAM দিয়ে transit gateway পুরো organization-এর সাথে share করো। প্রতিটা account নিজের VPC attach করে, আর প্রতিটা attach করা VPC একই line দিয়ে ডেটা সেন্টারে পৌঁছায়।

#SD-WAN appliance-এর জন্য Transit Gateway Connect

অনেক কোম্পানি তাদের branch-গুলো একটা SD-WAN product দিয়ে জোড়ে (একটা virtual router appliance, যেটা প্রতিটা application-এর জন্য সবচেয়ে ভালো link বেছে নেয়)। VPC-র ভেতরে (বা Direct Connect দিয়ে on-premises-এ) চলা এমন appliance-কে transit gateway-র সাথে জুড়তে Connect attachment ব্যবহার করো:

• এটা চলে আগে থেকে থাকা একটা VPC বা Direct Connect attachment-এর ওপর (যাকে বলে “transport”)।
• Appliance আর transit gateway GRE tunnel বানায় (“Connect peer”), তার ওপর BGP চালায়, তাই route নিজে থেকে আদানপ্রদান হয় আর peer-গুলো জুড়ে ECMP চলে।
• প্রতিটা Connect peer ৫ Gbps পর্যন্ত বয়; একটা Connect attachment-এ ৪টা peer মিলে ২০ Gbps পর্যন্ত। IPsec নেই, তাই tunnel-প্রতি encryption-এর বোঝা নেই, আর transport attachment-এর বাইরে কোনো বাড়তি data processing খরচও নেই।

Connect আসার আগে এই একই কাজে প্রতিটা appliance থেকে IPsec VPN লাগত, ১.২৫ Gbps-এর tunnel আর static বা জটিল BGP setup সহ।

#IP multicast

Multicast-এ একটা packet পাঠানো হয় একটা group address-এ, আর network সেটা কপি করে পৌঁছে দেয় group-এ যোগ দেওয়া প্রতিটা receiver-এর কাছে; কে শুনছে, পাঠানোর লোকের তা জানতেই হয় না। সাধারণ VPC routing multicast (বা broadcast) সমর্থন করে না। Transit gateway পারে:

• Transit gateway বানানোর সময় multicast support চালু করো, তারপর একটা multicast domain বানাও, আর যে VPC subnet-গুলো এতে অংশ নেবে সেগুলো associate করো।
• Group member আর source static-ভাবে (API দিয়ে) register করো, অথবা instance-গুলোকে IGMPv2 দিয়ে যোগ দিতে দাও।
• যে সীমাগুলো জানা দরকার: flow-প্রতি প্রায় ১ Gbps, আর AZ-প্রতি ২০ Gbps; AWS নিজেই সাবধান করে, এটা high-frequency trading-এর জন্য বানানো না।

#Production-এ যেসব খুঁটিনাটি দরকার

#MTU

Transit gateway VPC, Direct Connect, Connect আর peering attachment-এর মধ্যে 8500 byte পর্যন্ত MTU সমর্থন করে, কিন্তু VPN attachment দিয়ে মাত্র 1500 byte (আর IPsec tunnel-এর ভেতরে জায়গা থাকে 1446 byte-এর, লেসন ২২.৪)। একটা VPC-র ভেতরে instance 9001 byte-এর jumbo frame ব্যবহার করতে পারে; transit gateway-র পথ যতটা অনুমতি দেয়, তার চেয়ে বড় packet বাদ পড়ে। VPC আর Connect attachment দিয়ে ঢোকা traffic-এর জন্য transit gateway TCP MSS ছোট করে দেয় আর “fragmentation needed” বার্তা পাঠায় (path MTU discovery), কিন্তু VPN, Direct Connect বা peering-এর জন্য পাঠায় না। VPC peering (একই Region-এ 9001 সমর্থন করে) থেকে transit gateway-তে সরানোর সময় দুটো VPC একসাথে সরাও, যাতে jumbo frame শুধু এক দিকে 8500-এর দেয়ালে ধাক্কা না খায়।

#Appliance mode আর এক জায়গায় পরীক্ষা

একটা চেনা design-এ VPC-গুলোর মধ্যের, বা internet-এ যাওয়া সব traffic পাঠানো হয় firewall-ওয়ালা একটা inspection VPC দিয়ে (AWS Network Firewall, লেসন ২২.৭, বা Gateway Load Balancer-এর পেছনে third-party appliance, লেসন ৬.৩)। Stateful firewall-কে একটা flow-এর দুই দিকই দেখতে হয়। Default-এ transit gateway request পাঠাতে পারে এক AZ-এর appliance দিয়ে, আর উত্তর আরেক AZ দিয়ে; দ্বিতীয় firewall request-টা কখনো দেখেনি, তাই উত্তরটা ফেলে দেয়। Inspection VPC-র attachment-এ appliance mode চালু করলে transit gateway একটা flow-এর দুই দিককে তার পুরো জীবন ধরে একই AZ-এ রাখে। ২০২৫ থেকে AWS Network Firewall সরাসরি transit gateway-তে network function attachment হিসেবেও লাগানো যায়, যেটা তোমার হয়ে inspection VPC বানিয়ে দেয়, appliance mode আগে থেকেই চালু।

#DNS, flow log আর monitoring

• DNS support (default চালু) থাকলে, একটা attach করা VPC-র instance-এর public DNS hostname আরেকটা attach করা VPC থেকে জিজ্ঞেস করলে তার private IP-তে resolve হয়।
• Transit Gateway Flow Logs প্রতিটা attachment ধরে traffic লিখে রাখে, VPC Flow Logs-এর মতোই ধারণা (লেসন ২২.৩), সাথে attachment ID-র মতো transit gateway-র নিজস্ব field।
• Network Manager transit gateway, VPN আর site মিলিয়ে global network-এর ছবি আঁকে, আর Reachability Analyzer কোনো packet না পাঠিয়েই transit gateway-র ভেতর দিয়ে একটা পথ খুঁজে দেখাতে পারে।

#খরচ কত

Transit Gateway দুটো জিনিসের দাম নেয় (us-east-1 আর বেশিরভাগ Region-এ; তোমার Region-এর জন্য pricing page দেখো):

• Attachment-এর ঘণ্টা: attachment-প্রতি ঘণ্টায় প্রায় $০.০৫ (VPC, VPN, Direct Connect gateway, Connect, peering), বিল যায় attachment-এর মালিকের কাছে (VPC attachment হলে VPC-র মালিক)। ৭৩০ ঘণ্টার এক মাসে attachment-প্রতি প্রায় $৩৬.৫০।
• GB-প্রতি processing: VPC, VPN বা Direct Connect attachment থেকে transit gateway-তে ঢোকা প্রতি GB-তে প্রায় $০.০২। Peering attachment থেকে আসা ডেটার জন্য আবার টাকা নেয় না, আর Connect কোনো বাড়তি processing যোগ করে না। এর ওপরে সাধারণ data transfer-এর খরচ (inter-Region, internet egress) আলাদা, VPN connection-এর ঘণ্টাও আলাদা। তবে transit gateway-এর ভেতর দিয়ে AZ পেরোলে বাড়তি কিছু লাগে না: ২০২২-এর এপ্রিল থেকে AWS Transit Gateway-এর AZ পেরোনো data transfer-এর টাকা নেয় না।

গ্রুপটার উদাহরণ: ১২০টা VPC attachment + ১টা Direct Connect gateway attachment + ২টা VPN attachment = ১২৩ × ৭৩০ × $০.০৫ ≈ মাসে $৪,৪৯০, সাথে VPC-গুলোর মধ্যে মাসে ৫০ TB = ৫১,২০০ GB × $০.০২ = $১,০২৪।

খরচে peering বনাম Transit Gateway। Peering-এর ঘণ্টার দাম নেই, processing-এর দামও নেই: শুধু data transfer (peering দিয়ে একই AZ-এর traffic ফ্রি; AZ বা Region পেরোলে টাকা লাগে, লেসন ২২.১)। দুটো VPC যদি মাসে ১০০ TB আদানপ্রদান করে, transit gateway মাসে প্রায় ১,০২,৪০০ × $০.০২ = $২,০৪৮ যোগ করে, যেটা peering-এ লাগত না। চেনা উত্তর হলো দুটোই: সবকিছুর জন্য hub, আর খুব বেশি কথা বলা এক জোড়ার জন্য সরাসরি একটা peering (subnet route table-এ এর বেশি নির্দিষ্ট route জেতে)। লেসন ২২.৮-এ network-এর সব দাম পাশাপাশি রাখা আছে।

#যে quota-গুলো জানা দরকার

#Transit Gateway, peering, নাকি অন্য কিছু?

#কোথায় ভুল হয়

• Attachment available, অথচ কিছুই চলে না: VPC-র subnet route table-এ transit gateway-র দিকে কোনো route নেই। Attach করলে বদলায় transit gateway, তোমার VPC না।
• এক দিকে traffic, timeout: উত্তরের route নেই, হয় গন্তব্য subnet-এর route table-এ, নয়তো গন্তব্য attachment যে transit gateway route table-এর সাথে associated সেখানে।
• একটা AZ-এর instance hub-এ পৌঁছায় না: VPC attachment-এ ওই AZ চালু করা হয়নি (সেখানে কোনো subnet বাছা হয়নি)।
• Dev, prod-এ পৌঁছে যাচ্ছে: transit gateway-তে default association আর propagation রয়ে গেছে, তাই সবকিছু একটা চ্যাপ্টা route table-এ; অথবা বেশি নির্দিষ্ট route-ওয়ালা একটা পুরোনো peering hub এড়িয়ে যাচ্ছে।
• Peering attachment চালু, traffic নেই: কেউ static route যোগ করেনি; peering attachment কখনো propagate করে না।
• Transit gateway-তে VPN ১.২৫ Gbps-এ আটকে আছে: static routing (ECMP নেই), tunnel-গুলোতে আলাদা AS path, transit gateway-তে ECMP বন্ধ, on-premises router ECMP করছে না, বা একটাই বড় flow।
• Direct Connect দিয়ে on-premises থেকে নতুন VPC-তে যাওয়া যায় না: তার CIDR Direct Connect gateway association-এর allowed prefixes-এ নেই, তাই তোমার router সেটা কখনো শেখে না; অথবা যেখানে transit VIF লাগত, সেখানে বানানো হয়েছে private VIF।
• বড় file copy আটকে যায়, ছোট request চলে: MTU। VPN পথে ১৫০০ byte পর্যন্ত চলে; VPC থেকে VPC-র jumbo frame এমন কোথাও বাদ পড়ছে, যেখান থেকে “fragmentation needed” আসে না।
• Firewall উত্তর ফেলে দেয়: appliance mode ছাড়া stateful inspection VPC, তাই flow-এর দুই দিক দুই AZ দিয়ে যাচ্ছে।
• নতুন VPC attach হলো, কিন্তু কেউ তার কাছে পৌঁছাতে পারছে না: তার CIDR আগে থেকে attach করা কোনো VPC-র সাথে মিলে গেছে। Attachment ঠিকই তৈরি হয়, কিন্তু মিলে যাওয়া route-টা transit gateway তার route table-এ propagate করে না। Peering-এর মতো transit gateway-ও গন্তব্য address দেখে route করে, তাই range আলাদা হতেই হবে (IPAM দিয়ে পরিকল্পনা করো; মিল এড়ানো না গেলে PrivateLink বা private NAT gateway, লেসন ৩.৪)।
• অপ্রত্যাশিত বিল: কয়েকটা VPC hub দিয়ে দশ দশ terabyte আদানপ্রদান করছে; ওই জোড়াকে সরাসরি একটা peering দাও।

#System design-এ Transit Gateway

• Hub-and-spoke landing zone: একটা network account প্রতি Region-এ একটা transit gateway-র মালিক, RAM দিয়ে share করা; production, non-production, shared services আর on-premises-এর জন্য আলাদা route table; সীমানা পাহারায় blackhole।
• এক জায়গা দিয়ে বাইরে যাওয়া (centralised egress): spoke VPC-গুলোতে NAT gateway নেই; transit gateway-তে একটা 0.0.0.0/0 static route internet-এর traffic পাঠায় NAT gateway-ওয়ালা (আর firewall-ওয়ালা) একটা egress VPC-তে। NAT gateway কম লাগে, log রাখার জায়গা একটা, তবে বিনিময়ে hub দিয়ে প্রতি GB-তে $০.০২।
• এক জায়গায় পরীক্ষা (centralised inspection): VPC থেকে VPC আর ভেতর-বাইরের traffic একটা inspection VPC (appliance mode) বা একটা Network Firewall attachment দিয়ে।
• Shared services আর endpoint: DNS resolver, Active Directory, package mirror আর interface endpoint একটা VPC-তে, যেখানে প্রতিটা spoke পৌঁছায় (লেসন ১০.১০-এ S3-এর জন্য এটা দেখানো হয়েছে)।
• Hybrid hub: মূল পথ transit VIF দিয়ে Direct Connect, backup হিসেবে ECMP-ওয়ালা Site-to-Site VPN, দুটোই একই transit gateway-তে; branch-গুলো SD-WAN দিয়ে Connect হয়ে।
• Multi-Region: প্রতি Region-এ একটা transit gateway, peer করা; Region আর site অনেক হলে Cloud WAN। Region পেরিয়ে disaster recovery-র জন্য অধ্যায় ২৩ দেখো (RPO আর RTO-র কৌশল); এমন network জুড়ে খারাপ address আটকানো আছে লেসন ২৪.৩-এ।

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

# 1. Create a transit gateway with segmentation in mind: no default association/propagation
aws ec2 create-transit-gateway --description "core-hub-ap-south-1" \
  --options AmazonSideAsn=64512,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable,VpnEcmpSupport=enable,DnsSupport=enable,AutoAcceptSharedAttachments=enable
# {"TransitGateway": {"TransitGatewayId": "tgw-0a1b2c3d4e5f67890", "State": "pending", ...}}

# 2. Attach a VPC with one small subnet per AZ
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example subnet-0ccc3333example
# {"TransitGatewayVpcAttachment": {"TransitGatewayAttachmentId": "tgw-attach-0dev1234example", "State": "pending", ...}}

# 3. Route tables: create, associate, propagate
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=rt-dev}]'
aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --transit-gateway-attachment-id tgw-attach-0dev1234example
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --transit-gateway-attachment-id tgw-attach-0shared9example

# 4. Guard rail: blackhole prod in the dev table
aws ec2 create-transit-gateway-route --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --destination-cidr-block 10.20.0.0/16 --blackhole

# 5. What does the dev table contain?
aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id tgw-rtb-0dev5678example \
  --filters Name=type,Values=static,propagated \
  --query "Routes[].[DestinationCidrBlock,Type,State]" --output table
# |  10.20.0.0/16 |  static     |  blackhole |
# |  10.30.0.0/16 |  propagated |  active    |

# 6. Do not forget the VPC side
aws ec2 create-route --route-table-id rtb-0dev1111example \
  --destination-cidr-block 10.0.0.0/8 --transit-gateway-id tgw-0a1b2c3d4e5f67890

# 7. Share it with the whole organization
aws ram create-resource-share --name core-hub \
  --resource-arns arn:aws:ec2:ap-south-1:111122223333:transit-gateway/tgw-0a1b2c3d4e5f67890 \
  --principals arn:aws:organizations::111122223333:organization/o-exampleorgid

# 8. Two VPN connections with BGP for ECMP (dynamic routing is the default)
aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id cgw-0router1example \
  --transit-gateway-id tgw-0a1b2c3d4e5f67890
aws ec2 create-vpn-connection --type ipsec.1 --customer-gateway-id cgw-0router2example \
  --transit-gateway-id tgw-0a1b2c3d4e5f67890

# 9. Peer with the Singapore transit gateway, accept there, then add static routes on both sides
aws ec2 create-transit-gateway-peering-attachment --transit-gateway-id tgw-0a1b2c3d4e5f67890 \
  --peer-transit-gateway-id tgw-0f9e8d7c6b5a43210 --peer-account-id 111122223333 \
  --peer-region ap-southeast-1
aws ec2 accept-transit-gateway-peering-attachment --region ap-southeast-1 \
  --transit-gateway-attachment-id tgw-attach-0peer777example
aws ec2 create-transit-gateway-route --transit-gateway-route-table-id tgw-rtb-0prod999example \
  --destination-cidr-block 10.70.0.0/16 --transit-gateway-attachment-id tgw-attach-0peer777example

# 10. Direct Connect: associate the Direct Connect gateway and say what to advertise
aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id 5f8e2c1a-1234-4bcd-9abc-0123456789ab \
  --gateway-id tgw-0a1b2c3d4e5f67890 \
  --add-allowed-prefixes-to-direct-connect-gateway cidr=10.0.0.0/8

Dev VPC-র একটা instance থেকে traceroute 10.30.4.10 shared services-এ পৌঁছানো উচিত, আর ping 10.20.8.5 (prod) কোনো উত্তর ছাড়াই timeout হওয়া উচিত: blackhole সেটা নিঃশব্দে ফেলে দেয়।

#সারসংক্ষেপ

মূল কথাগুলো

• Peering mesh-এ লাগে n(n−1)/2টা connection (১০০টা VPC → ৪,৯৫০), আর VPC-প্রতি ১২৫টা peering-এর ছাদ; transit gateway হলো একটা regional hub, প্রতিটা network-এর একটা attachment, আর routing transitive।
• Attachment: VPC (প্রতি AZ-এ একটা subnet), Site-to-Site VPN, Direct Connect gateway (transit VIF), Connect (SD-WAN-এর জন্য GRE + BGP), peering (শুধু static route), সাথে VPN Concentrator আর Network Firewall attachment।
• প্রতিটা packet প্রতি দিকে দুটো route table পেরোয়: VPC-র subnet route table (tgw-…-এর দিকে route তোমাকেই বসাতে হবে), আর তার attachment যে transit gateway route table-এর সাথে associated সেটা।
• Association (attachment-প্রতি একটা) = খোঁজা হয় কোথায়; propagation (অনেকগুলো) = table-এ কে থাকে। Static জেতে propagated-এর ওপর; blackhole ফেলে দেয়। Dev, prod আর shared services ভাগ করতে default দুটো বন্ধ করো।
• Region পেরিয়ে transit gateway peer করো (encrypted backbone, static route); network account থেকে AWS RAM দিয়ে share করো।
• Transit gateway-তে ECMP (BGP, VPN ECMP support) সব tunnel ব্যবহার করে: ১টা connection = ২.৫ Gbps, ২টা = ৫ Gbps; VGW কখনো ECMP করে না; একটা flow একটা tunnel-এই আটকা (১.২৫ Gbps, বা ২০২৫-এর large tunnel হলে ৫ Gbps)।
• অনেক account-এর জন্য একটা Direct Connect: transit VIF → Direct Connect gateway (allowed prefixes, ৬টা পর্যন্ত transit gateway) → transit gateway → RAM।
• VPC-গুলোর মধ্যে multicast → Transit Gateway multicast (IGMPv2 বা static member)।
• MTU 8500 (VPC, Direct Connect, Connect, peering) বনাম 1500 (VPN); stateful inspection VPC-র জন্য appliance mode।
• খরচ ≈ attachment-ঘণ্টায় $০.০৫ + process করা প্রতি GB-তে $০.০২; peering-এ এর কোনোটাই নেই, তাই খুব বেশি কথা বলা জোড়ার জন্য peering রাখো। Policy-চালিত global network-এর জন্য Cloud WAN, একটা service বা মিলে যাওয়া CIDR-এর জন্য PrivateLink, কিছুই না জুড়তে চাইলে VPC sharing।

নিজেকে যাচাই করো: Transit Gateway৩১টি প্রশ্ন