S3-তে পৌঁছানোর পথ (১/৩): প্রাইভেট নেটওয়ার্কের রাস্তা

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

• এই তিন লেসনের অংশে S3-তে ডেটা পৌঁছানোর যে ১৩টা পথ আছে, সবগুলোর নাম বলতে, আর কোনটা কোন লেসনে পড়ানো হয়েছে সেটা জানাতে।
• দুটো আলাদা কাজ আলাদা করে চিনতে: S3-তে পৌঁছানোর শেষ ধাপ (gateway endpoint, interface endpoint, Direct Connect public virtual interface) আর VPC পর্যন্ত আসার রাস্তা (VPC peering, Transit Gateway, Site-to-Site VPN, Direct Connect private বা transit virtual interface)।
• Gateway endpoint (prefix list, route table) আর interface endpoint (ENI, private IP, security group, DNS) দিয়ে traffic কীভাবে যায়, কোনটার খরচ কত, আর কোনটা কী পারে না, সেটা ব্যাখ্যা করতে।
• Endpoint policy আর aws:sourceVpce ও aws:sourceVpc condition key দিয়ে একটা bucket-কে নির্দিষ্ট endpoint বা VPC-তে বেঁধে দিতে।
• Peered VPC, transit gateway-র spoke বা on-premises network কেন gateway endpoint ব্যবহার করতে পারে না, আর তার বদলে কী বানাতে হয়, সেটা বোঝাতে।
• কোনো একটা পরিস্থিতিতে পাঁচটা network পথের মধ্যে খরচ, bandwidth, চালু হতে কত সময় লাগে আর encryption মিলিয়ে বেছে নিতে, আর NAT, endpoint ও Transit Gateway-এর বিল হিসাব করতে।

#S3-তে যাওয়ার ১৩টা পথ, কোনটা কোথায়

S3-তে ডেটা ঢোকে আর বের হয় অনেকভাবে, আর শিক্ষার্থীরা গুলিয়ে ফেলে কারণ কয়েকটার নাম প্রায় একই রকম শোনায়: “endpoint”, “gateway”, “transfer”, “connect”। এই লেসন আর পরের দুটো মিলে একটা অংশ, যেখানে ১৩টা পথ পাশাপাশি রাখা হয়েছে, প্রতিটার নিজের ব্যাখ্যা, নিজের অ্যানিমেশন, আর এটা আসলে কোন কাজে লাগে তার একটা বাস্তব উদাহরণ সহ। প্রথম এই লেসনে আছে network-এর পথগুলো: পাবলিক internet ছুঁয়ে না গিয়ে একটা server থেকে packet কীভাবে S3-তে পৌঁছায়।

১–৫ নম্বর পথ উত্তর দেয় “আমার packet কোন রাস্তায় যাবে”। ৬–১০ উত্তর দেয় “কোন service আমার file সরাবে”, আর এরা সবাই নিচে নিচে ১–৫ নম্বর পথ বা internet-এর ওপরই চলে। ১১–১৩ উত্তর দেয় “আমার application S3-এর সাথে কীভাবে কথা বলবে”। লেসন ১০.১২-এর শেষে ১৩টা পথের মধ্যে বেছে নেওয়ার একটা গাইড আছে।

#দুটো আলাদা কাজ: রাস্তা আর শেষ ধাপ

এই লেসনটা আছেই এই গোলমালটা মেটানোর জন্য। পাঁচটা network পথ আসলে দুই রকমের কাজ করে:

• S3-তে পৌঁছানোর শেষ ধাপ। কাউকে না কাউকে তোমার packet-টা S3-এর হাতে তুলে দিতে হবে। Private-ভাবে এটা পারে মাত্র তিনটা জিনিস: একটা gateway endpoint, একটা interface endpoint, আর Direct Connect-এর ক্ষেত্রে একটা public virtual interface।
• VPC পর্যন্ত আসার রাস্তা। VPC peering, Transit Gateway, Site-to-Site VPN আর Direct Connect (private বা transit virtual interface) অন্য কোথাও থেকে traffic বয়ে আনে একটা VPC-র ভেতর পর্যন্ত। নিজেরা এরা S3-তে পৌঁছায় না। Traffic VPC-তে এসে পৌঁছালে বাকি পথটা নিয়ে যেতে হয় একটা interface endpoint-কে।

#শুরুর অবস্থা: NAT gateway দিয়ে S3

কোনো endpoint না থাকলে private subnet-এর একটা instance S3-তে যায় লেসন ৩.৪-এ শেখা পথে: public subnet-এর একটা NAT gateway, তারপর internet gateway, তারপর S3-এর public endpoint। কাজ চলে, তবে:

• প্রতিটা gigabyte-এর জন্য NAT gateway টাকা নেয় (অনেক Region-এ process করা প্রতি GB-তে প্রায় $০.০৪৫, সাথে ঘণ্টায় প্রায় $০.০৪৫);
• subnet-এর internet-এ যাওয়ার একটা পথ লাগে, যেটা অনেক security team একদমই চায় না;
• NAT gateway-এর AZ-এ সমস্যা হলে, অন্য AZ-এর যেসব subnet ওটা ব্যবহার করে, তাদের S3 access-ও বন্ধ।

S3 একটা public service: এর endpoint-গুলোর public IP address আছে। নিচের প্রতিটা অপশন হলো ওই endpoint-এ, বা তার একটা private কপিতে, ওই internet-এর পথ ছাড়াই পৌঁছানোর একটা উপায়।

#পথ ১: gateway endpoint

#Gateway endpoint জিনিসটা কী

Gateway endpoint হলো একটা target, যেটা তুমি route table-এ বসাও। এটা কোনো device না, এর কোনো IP address-ও নেই। এটা আছে ঠিক দুটো service-এর জন্য: Amazon S3 আর DynamoDB। তুমি এটা বানাও com.amazonaws.ap-south-1.s3-এর মতো একটা service name-এর জন্য, একটা VPC বেছে দাও, আর যেসব subnet এটা ব্যবহার করবে তাদের route table-গুলো বেছে দাও; চাইলে একটা endpoint policy-ও লাগাও।

#এর ভেতর দিয়ে traffic কীভাবে যায়

1. বেছে দেওয়া প্রতিটা route table-এ AWS একটা route যোগ করে: destination হলো এই Region-এ S3-এর AWS-managed prefix list (pl-…, S3-এর সব address range-এর একটা নামওয়ালা তালিকা), আর target হলো endpoint (vpce-…)।
2. তোমার application আগের মতোই S3-এর সাধারণ নাম ব্যবহার করে, যেমন s3.ap-south-1.amazonaws.com, যেটা তখনো একটা public S3 address-এ resolve হয়। VPC যদি Amazon-এর DNS server ব্যবহার করে, তাহলে DNS resolution আর DNS hostnames দুটোই চালু থাকতে হবে।
3. VPC router দুটো মেলানো route পায়, 0.0.0.0/0 (NAT gateway-এর দিকে) আর S3-এর prefix list। বেশি নির্দিষ্টটা জেতে (longest prefix match, লেসন ৩.৩), তাই S3-র traffic যায় endpoint-এ, আর বাকি সব আগের মতোই NAT-এ।
4. S3 দেখে request আসছে instance-এর private IP থেকে, endpoint vpce-… হয়ে। Security group-এ S3-এর দিকে outbound HTTPS allow থাকতে হবে; security group rule-এ S3-এর prefix list সরাসরি দেওয়া যায়। Network ACL-এ prefix list দেওয়া যায় না, তাই সেখানে address range-গুলোই লিখতে হয়।

অ্যানিমেশনের private subnet-এর route table, endpoint-এর আগে আর পরে:

#Gateway endpoint-এর খরচ আর সীমা

• ফ্রি। ঘণ্টার কোনো খরচ নেই, GB-প্রতিও নেই। S3-এর সাধারণ request আর storage খরচ তো থাকছেই; একই Region-এ S3 আর EC2-এর মধ্যে data transfer-এর জন্য টাকা লাগে না।
• শুধু একই Region। Prefix list-এ থাকে শুধু endpoint-এর নিজের Region-এর S3। অন্য Region-এর bucket এর ভেতর দিয়ে পৌঁছানো যায় না।
• Quota। Default হিসেবে প্রতি account-এ প্রতি Region-এ ২০টা gateway endpoint (বাড়ানো যায়), আর এক VPC-তে সর্বোচ্চ ২৫৫টা।
• Bandwidth। Endpoint নিজে কোনো সীমা বসায় না: এটা VPC-র routing-এরই অংশ।
• IP version। শুরুতে শুধু IPv4 ছিল; এখন S3 gateway endpoint IPv6 আর dual-stack-ও সমর্থন করে।
• Route যোগ বা বদলানোর সময় ওই subnet থেকে S3-এর দিকে খোলা TCP connection-গুলো reset হয়ে যায়, কারণ পথ আর S3-এর দেখা source address দুটোই বদলে যায়। Backup চলার সময় এই কাজ কোরো না।

#Gateway endpoint যা পারে না

• এটা নিজের VPC-র বাইরে টেনে নেওয়া যায় না। Site-to-Site VPN, Direct Connect, VPC peering বা transit gateway দিয়ে আসা traffic এটা ব্যবহার করতে পারে না। শুধু VPC-র ভেতরে শুরু হওয়া traffic পারে।
• অন্য Region-এর bucket-এ পৌঁছাতে পারে না।
• এর কোনো security group নেই, কোনো IP address-ও নেই, তাই on-premises-এর machine-এর packet পাঠানোর মতো কোনো ঠিকানাই নেই।
• পথে endpoint থাকলে S3 দেখে private source address, তাই এসব request-এ aws:SourceIp শর্ত কাজ করে না। তার বদলে aws:VpcSourceIp, aws:sourceVpc বা aws:sourceVpce ব্যবহার করো।

#Endpoint দিয়ে access-এ তালা দেওয়া

দুটো policy একসাথে কাজ করে, আর দুই ধরনের endpoint-ই এদের সমর্থন করে:

• Endpoint-এর ওপর একটা endpoint policy বলে, এই endpoint দিয়ে কোন bucket আর কোন action ব্যবহার করা যাবে। Default হলো full access। এটা দিয়ে আটকাতে পারো, যাতে কোনো দখল হয়ে যাওয়া instance অন্য কারও account-এর bucket-এ ডেটা কপি করে নিতে না পারে।
• Endpoint বা VPC-র ওপর শর্তওয়ালা একটা bucket policy বলে, এই bucket শুধু ওই পথ দিয়েই ব্যবহার করা যাবে (লেসন ১০.২)।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OnlyThroughOurEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::bank-backups-example", "arn:aws:s3:::bank-backups-example/*"],
      "Condition": { "StringNotEquals": { "aws:sourceVpce": "vpce-0a1b2c3d4e5f60718" } }
    }
  ]
}

এই রকম policy console-কেও আটকে দেয়, আর VPC-র বাইরের সবাইকে, তোমাকেও। একটা administrator role-এর জন্য ছাড় রেখো, নইলে policy মুছতে হয়তো account-এর root user-কে ডাকতে হবে।

#পথ ২: interface endpoint (PrivateLink)

#Interface endpoint জিনিসটা কী

Interface endpoint তৈরি AWS PrivateLink-এর ওপর। তুমি যে subnet-গুলো বেছে দাও, তার প্রতিটায় এটা একটা করে elastic network interface (ENI) বসায়, সাধারণত প্রতি AZ-এ একটা, প্রত্যেকটার আছে ওই subnet থেকে নেওয়া একটা private IP address আর একটা security group। তোমার network-এর চোখে এখন S3-এর address আছে তোমার VPC-র ভেতরেই। Interface endpoint আছে বেশিরভাগ AWS service-এর জন্য (SQS, SNS, KMS, EC2 API…); S3-এর জন্য একই VPC-তে দুই ধরনের endpoint-ই রাখা যায়।

#Traffic কীভাবে যায়, আর DNS কেন আসল খেলোয়াড়

Endpoint-এর যেহেতু সত্যিকারের IP address আছে, প্রশ্ন শুধু একটাই: তোমার application কোন নাম resolve করছে:

• Endpoint-এর নিজস্ব নাম। প্রতিটা S3 interface endpoint পায় bucket.vpce-0a1b2c3d-xyz.s3.ap-south-1.vpce.amazonaws.com-এর মতো নাম (Regional), আর AZ-এর নাম সহ একটা zonal রূপ। এই নামগুলো থাকে public DNS-এ, আর resolve হয় ENI-গুলোর private IP-তে, তাই on-premises বা অন্য VPC-র একটা server DNS-এ কিছু না বদলেই এগুলো ব্যবহার করতে পারে। AWS CLI-তে এগুলো দাও --endpoint-url হিসেবে।
• Private DNS। Endpoint-এ private DNS চালু করলে এই VPC-র ভেতরে S3-এর সাধারণ নামগুলোই (s3.ap-south-1.amazonaws.com, access point আর control-এর নাম) resolve হয় endpoint-এর private IP-তে। Application-এ কিছুই বদলাতে হয় না।
• শুধু inbound endpoint-এর জন্য private DNS। VPC-তে যদি একটা S3 gateway endpoint-ও থাকে, তাহলে এই অপশন বেছে নিতে পারো (S3-এর জন্য private DNS চালু করলে এটাই default): VPC-র ভেতরের instance-রা আগের মতো public S3 address পায় আর ফ্রি gateway endpoint দিয়ে যায়, আর Route 53 Resolver inbound endpoint হয়ে আসা প্রশ্ন (on-premises থেকে) পায় interface endpoint-এর private IP। এই অপশনের জন্য gateway endpoint থাকতেই হবে, আর অপশন চালু থাকা অবস্থায় সেটা মোছা যায় না।

এরপর packet HTTPS দিয়ে ENI-তে যায়, ENI-র security group-এ client-দের কাছ থেকে inbound TCP 443 allow থাকতে হয়, আর PrivateLink request-টা AWS network দিয়ে S3-তে নিয়ে যায়।

#Interface endpoint-এর খরচ আর সীমা

• প্রতি AZ-এ ঘণ্টার খরচ: endpoint যতগুলো AZ-এ আছে, প্রতিটার জন্য ঘণ্টায় প্রায় $০.০১।
• Data processing: প্রতি মাসের প্রথম petabyte পর্যন্ত GB-প্রতি প্রায় $০.০১, তার ওপরে আরও কম।
• উদাহরণ: ৩টা AZ-এ একটা endpoint, ৭৩০ ঘণ্টার মাসে ৩ × ৭৩০ × $০.০১ = $২১.৯০, সাথে ৫ TB process = ৫,১২০ GB × $০.০১ = $৫১.২০, মোট প্রায় $৭৩। একই traffic gateway endpoint দিয়ে গেলে খরচ $০।
• Bandwidth: default হিসেবে প্রতি AZ-এ ১০ Gbps পর্যন্ত, নিজে থেকে বেড়ে প্রতি AZ-এ ১০০ Gbps পর্যন্ত যায়।
• Quota: default হিসেবে এক VPC-তে ৫০টা interface (আর Gateway Load Balancer) endpoint।

#Interface endpoint যা পারে না

• এটা S3-এর website endpoint (লেসন ১০.৩) চালায় না, আর ভিন্ন Region-এর bucket-এর মধ্যে CopyObject বা UploadPartCopy সমর্থন করে না।
• VPC-র ভেতরের যে traffic gateway endpoint ফ্রিতে বইত, তার জন্য এটা টাকা নেয়।
• কেউ এর দিকে resolve না করলে এটা কিছুই করে না: private DNS বন্ধ আর সাধারণ নাম ব্যবহার হলে traffic আগের মতোই S3-এর public address-এ যায়।
• Security group-এর একটা rule ভুলে গেলে এটা একটা কালো গর্ত হয়ে যায়: request Access Denied না দিয়ে timeout হয়।

#S3-এর জন্য gateway নাকি interface endpoint?

#পথ ৩: VPC peering

#VPC peering জিনিসটা কী

VPC peering হলো দুটো VPC-র মধ্যে একটা private network connection। দুই পাশের instance private IP দিয়ে একে অপরের সাথে কথা বলতে পারে, যেন একই network-এ আছে, AWS backbone দিয়ে, পাবলিক internet দিয়ে কখনো না।

• এটা চলে ভিন্ন account-এ আর ভিন্ন Region-এ (inter-Region peering encrypted)।
• দুই VPC-র CIDR range কোনোভাবেই overlap করা যাবে না (লেসন ৩.১)।
• Peering গ্রহণ হওয়ার পর দুই VPC-রই route table-এ route যোগ করতে হয় (destination = অন্য VPC-র CIDR, target = pcx-…)। এগুলো ছাড়া কিছুই চলে না।
• একই Region-এ একটা security group peer VPC-র security group-কে reference করতে পারে, ভিন্ন account হলেও।
• Peering transitive না। A-এর সাথে B-এর peering, B-এর সাথে C-এর, তবু A B হয়ে C-তে যেতে পারবে না। A–C-এর নিজস্ব peering-ও লাগবে। n-টা VPC-র পুরো mesh-এ লাগে n(n−১)/২টা connection: ১০০টা VPC → ৪,৯৫০টা।
• Edge-to-edge routing নেই। একটা VPC তার peer-এর internet gateway, NAT gateway, VPN, Direct Connect বা gateway endpoint ব্যবহার করতে পারে না।
• খরচ: ঘণ্টার কোনো খরচ নেই। একই AZ-এর ভেতরে থাকা ডেটা ফ্রি; AZ বা Region পার হওয়া ডেটার জন্য সাধারণ transfer খরচ লাগে।

#Peered VPC কীভাবে S3-তে পৌঁছায়

Peering নিজে S3-তে পৌঁছায় না। এটা শুধু VPC A-কে VPC B-র ভেতরের address-এ পৌঁছাতে দেয়। তাই:

• VPC B-র gateway endpoint: VPC A থেকে ব্যবহার করা যায় না (edge-to-edge routing নেই)। Packet ফেলে দেওয়া হয়।
• VPC B-র interface endpoint: ব্যবহার করা যায়, কারণ এর ENI-গুলো VPC B-র ভেতরের আসল address। VPC A ব্যবহার করে endpoint-এর নিজস্ব DNS নাম (public DNS উত্তর দেয় VPC B-র private IP), অথবা একটা Route 53 private hosted zone VPC A-র সাথে জুড়ে দেয়। Endpoint-এর security group-এ VPC A-র range allow থাকতে হবে।
• সাধারণত সবচেয়ে ভালো: VPC A নিজের একটা gateway endpoint বানায়, ফ্রি, আর peering থাকে তার আসল কাজের জন্য, VPC থেকে VPC-তে traffic।

#Peering কেন বেছে নেবে, কখন নেবে না

অল্প কয়েকটা VPC-র মধ্যে কম latency-তে, সস্তায় private traffic চালাতে peering বেছে নাও: ঘণ্টার খরচ নেই, GB-প্রতি processing খরচ নেই, নিজের কোনো bandwidth সীমা নেই। এড়িয়ে চলো যখন VPC-র সংখ্যা বাড়ছে (mesh-এর বিস্ফোরণ), যখন transitive routing বা on-premises-এ যাওয়ার একটা shared পথ লাগে, বা যখন লক্ষ্য শুধু S3-তে পৌঁছানো (তখন endpoint ব্যবহার করো)। Peering-এর পুরো গল্প আছে অধ্যায় ২২-এ।

#পথ ৪: Transit Gateway

#Transit Gateway জিনিসটা কী

AWS Transit Gateway (TGW) হলো একটা regional hub। VPC, Site-to-Site VPN connection, Direct Connect gateway আর অন্য transit gateway এর সাথে attach হয় (hub আর spoke), আর এটা তাদের মধ্যে routing করে। Peering-এর মতো না, এর ভেতর দিয়ে routing transitive: A আর C দুজনেই attach থাকলে A C-তে পৌঁছাতে পারে।

• Regional resource; ভিন্ন Region-এর transit gateway-দের মধ্যে peering করা যায়।
• অন্য account-এর সাথে share করা হয় AWS Resource Access Manager (RAM) দিয়ে।
• Transit gateway route table ঠিক করে কোন attachment কোনটায় পৌঁছাতে পারবে: যেমন production আর development VPC দুটোই shared service-এ যাবে, কিন্তু একে অপরের কাছে না।
• IP multicast সমর্থন করে, যেটা AWS-এর আর কোনো networking service করে না।
• Site-to-Site VPN-এর জন্য ECMP: কয়েকটা VPN connection attach থাকলে এটা সব tunnel-এ flow ভাগ করে দেয়। প্রতিটা tunnel ১.২৫ Gbps পর্যন্ত বয়, তাই দুটো VPN connection (চারটা tunnel) মিলে মোট প্রায় ৫ Gbps। Virtual private gateway এটা পারে না। একটা flow তবু একটা tunnel-ই ব্যবহার করে।
• খরচ: প্রতি attachment-এ ঘণ্টায় প্রায় $০.০৫, আর process করা প্রতি GB-তে $০.০২।

#Transit gateway কীভাবে S3-তে পৌঁছায়

Peering-এর মতোই transit gateway traffic বয়ে নেয় শুধু attach করা VPC-গুলোর ভেতরের address পর্যন্ত। অন্য VPC-র gateway endpoint এর ভেতর দিয়ে পৌঁছানো যায় না। অনেক VPC-র জন্য প্রচলিত design হলো একটা shared endpoints VPC:

1. Transit gateway-তে attach করা একটা কেন্দ্রীয় VPC-তে S3-এর interface endpoint বানাও।
2. Interface endpoint-এর private DNS কাজ করে শুধু তার নিজের VPC-তে, তাই S3-এর নামের জন্য একটা Route 53 private hosted zone বানাও যেটা endpoint-কে দেখায়, আর সেটা প্রতিটা spoke VPC-র সাথে জুড়ে দাও (বা Route 53 Resolver rule দিয়ে নামটা forward করো)।
3. Spoke-রা কেন্দ্রীয় VPC-র range-এর route দেয় transit gateway-তে। তাদের S3-র traffic যায় spoke → TGW → endpoint ENI → S3।

#Direct Connect-এর সাথে Transit Gateway, আর কেন এটা বেছে নেবে

একটা Direct Connect connection অনেক account-এর অনেক VPC মিলে ব্যবহার করতে: একটা Direct Connect gateway-এর দিকে একটা transit virtual interface বানাও, Direct Connect gateway-কে transit gateway-এর সাথে জুড়ে দাও, আর transit gateway-টা RAM দিয়ে অন্য account-দের সাথে share করো।

Transit Gateway বেছে নাও যখন তোমার অনেক VPC, transitive routing লাগে, on-premises-এ যাওয়ার একটা shared পথ (VPN বা Direct Connect) চাও, বা ECMP দিয়ে VPN-এর bandwidth বাড়াতে চাও। শুধু S3-তে পৌঁছানোর জন্য এটা বেছে নিও না, যেখানে VPC-টার নিজেরই একটা ফ্রি gateway endpoint থাকতে পারে: তাহলে attachment আর GB-প্রতি খরচ অকারণে দেবে। আরও বিস্তারিত অধ্যায় ২২-এ।

#পথ ৫: Site-to-Site VPN বা Direct Connect

এগুলো তোমার নিজের network (একটা অফিস, একটা data centre) AWS-এর সাথে জোড়ে। দুটোই শেষ হয় একটা VPC-তে (বা একটা transit gateway-তে); কোনোটাই নিজে S3-তে পৌঁছায় না।

#Site-to-Site VPN

• তোমার network আর AWS-এর মধ্যে পাবলিক internet-এর ওপর দিয়ে একটা encrypted IPsec connection। কয়েক মিনিটে তৈরি, সস্তা (connection-ঘণ্টা প্রতি প্রায় $০.০৫, সাথে data transfer out), তবে এর গতি আর latency internet-এর মেজাজের ওপর চলে।
• Virtual private gateway (VGW): AWS-এর দিকের প্রান্ত, একটা VPC-র সাথে জোড়া (এর ASN নিজে ঠিক করা যায়)। অথবা VPN-টা শেষ করো একটা transit gateway-তে।
• Customer gateway (CGW): তোমার router বা firewall-এর বর্ণনা দেওয়া AWS resource: তার public IP আর BGP ASN। Router যদি NAT traversal (NAT-T) চালু থাকা একটা NAT device-এর পেছনে থাকে, তাহলে NAT device-এর public IP দাও। ওই public IP বদলে গেলে নতুন একটা customer gateway বানাতে হয়; তারপর VPN connection-টা বদলে নতুনটার দিকে দেখানো যায়, বা নতুন connection বানানো যায়।
• একটা VPN connection = দুটো tunnel, AWS-এর দিকে দুটো ভিন্ন AZ-এ শেষ হয়। প্রতিটা tunnel ১.২৫ Gbps পর্যন্ত বয়। ২০২৫-এর শেষ থেকে transit gateway বা Cloud WAN-এ লাগানো VPN connection ৫ Gbps-এর tunnel (large bandwidth tunnel) ব্যবহার করতে পারে; পরীক্ষার প্রশ্ন এখনো ১.২৫ Gbps ধরেই চলে।
• Routing: dynamic (BGP), best practice, অথবা static। Subnet-এর route table-এ VGW-এর জন্য route propagation চালু করো, আর on-premises থেকে ping করতে চাইলে security group-এ ICMP allow করো।
• সর্বোচ্চ availability: দুটো tunnel AWS-এর দিকের নষ্ট হওয়া সামলায়, কিন্তু তোমার একমাত্র router নষ্ট হলে কিছু করতে পারে না। একটা দ্বিতীয় customer gateway (দ্বিতীয় router) আর একটা দ্বিতীয় VPN connection যোগ করো: দুটো CGW, চারটা tunnel।
• AWS VPN CloudHub: কয়েকটা branch অফিস প্রত্যেকে একই VGW-তে VPN বানায়, BGP চালায়, range-গুলো overlap করে না, তারপর এর ভেতর দিয়ে একে অপরের সাথে কথা বলতে পারে: internet-এর ওপর দিয়ে কম খরচের hub আর spoke। (অনেক VPN-এর সাথে অনেক VPC-ও থাকলে → Transit Gateway।)

#Direct Connect

• তোমার network থেকে AWS-এর একটা Direct Connect location হয়ে AWS পর্যন্ত একটা নিজস্ব private line: স্থির bandwidth আর latency, internet কখনো না। প্রতিদিন terabyte-এর পর terabyte, real-time feed, hybrid system আর compliance-এর জন্য ভালো।
• Dedicated connection: AWS থেকে নেওয়া ১, ১০, ১০০ বা ৪০০ Gbps-এর একটা physical port। Hosted connection: Direct Connect Partner-এর কাছ থেকে নেওয়া capacity, ৫০ Mbps থেকে ২৫ Gbps; partner upgrade সমর্থন করলে capacity বদলে দিতে পারে, নইলে নতুন একটা অর্ডার দিতে হয়। ১ Gbps-এর কম দরকার হলে (যেমন ৫০০ Mbps) → hosted।
• সময়: নতুন connection পেতে প্রায়ই এক মাসের বেশি লাগে।
• Line-এর ওপর virtual interface (VIF): private VIF পৌঁছায় একটা VPC-র private IP-তে (তার VGW বা একটা Direct Connect gateway হয়ে); public VIF line দিয়ে পৌঁছায় AWS-এর public address-এ, S3 সহ; transit VIF একটা Direct Connect gateway হয়ে transit gateway-তে পৌঁছায়।
• Direct Connect gateway: একটা virtual interface দিয়ে অনেক Region (China বাদে) আর account-এর VPC-তে পৌঁছানো যায়। ওই VPC-গুলোর নিজেদের মধ্যে এটা routing করে না।
• Default হিসেবে encrypted না (private, কিন্তু খোলা লেখা)। Encrypt করতে: Direct Connect-এর ওপর IPsec Site-to-Site VPN চালাও (পরীক্ষার প্রচলিত উত্তর), অথবা সমর্থিত location-এ dedicated ১০, ১০০ বা ৪০০ Gbps connection-এ MACsec ব্যবহার করো।
• Resiliency: development আর test-এর জন্য এক location-এ আলাদা device-এ দুটো connection; high resiliency-তে দুটো location-এ একটা করে connection; maximum resiliency (mission-critical)-তে দুটো location-এ দুটো করে, আলাদা device-এ, মোট চারটা।
• সবচেয়ে সস্তা backup: Direct Connect-এর পাশে একটা Site-to-Site VPN। Traffic যেন Direct Connect-কে বেশি পছন্দ করে, সেটা BGP দিয়ে করো: AWS থেকে তোমার দিকে একই prefix-এ AWS নিজেই VPN-এর চেয়ে Direct Connect বেশি পছন্দ করে; তোমার দিক থেকে AWS-এর দিকে local preference দাও, বা AS path prepending দিয়ে VPN-এর পথকে লম্বা দেখাও।
• খরচ: port-ঘণ্টার ভাড়া, সাথে Direct Connect-এর হারে data transfer out, যেটা internet-এর হারের চেয়ে কম; ঢোকা ডেটা ফ্রি।

#On-premises-এর traffic কীভাবে S3-তে পৌঁছায়

1. VPN বা Direct Connect private VIF + interface endpoint: রাস্তা traffic-কে VPC পর্যন্ত আনে; server পাঠায় interface endpoint-এর private IP-তে (endpoint-এর নিজস্ব নাম, বা Route 53 Resolver inbound endpoint হয়ে private DNS, লেসন ৮.৫); শেষ ধাপটা করে PrivateLink। Bucket-এ aws:sourceVpce দিয়ে তালা দাও।
2. Direct Connect public VIF: traffic private line দিয়ে সোজা S3-এর public endpoint-এ যায়, VPC লাগে না, endpoint-এর খরচ নেই। Bucket তোমার public IP দেখে, তাই aws:SourceIp দিয়ে সীমিত করো। নিজের router-এ route filter করো, কারণ public VIF AWS-এর সব public prefix শিখে নেয়।
3. Gateway endpoint কখনো না: on-premises-এর traffic এটা ব্যবহার করতে পারে না।

#VPN আর Direct Connect-এর মধ্যে বেছে নেওয়া

অধ্যায় ২২-এ আরও গভীরে আছে Site-to-Site VPN আর Direct Connect।

#পাঁচটা পথ পাশাপাশি

#বেছে নেওয়ার একটা গাইড

1. Request কোথা থেকে শুরু?

   একটা VPC থেকে, bucket একই Region-এ → ওই VPC-তে gateway endpoint। এখানেই থামো: এর চেয়ে সস্তা কিছু নেই।

2. অন্য একটা VPC?

   একই Region → ওই VPC-কে তার নিজের gateway endpoint দাও। অনেক VPC আর নিয়ন্ত্রণ এক জায়গায় চাও → private hosted zone সহ Transit Gateway + shared interface endpoint। Bucket অন্য Region-এ → inter-Region peering বা TGW peering দিয়ে bucket-এর Region-এ interface endpoint (অথবা ডেটা replicate করো, লেসন ১০.৪)।

3. On-premises?

   এই সপ্তাহেই লাগবে বা bandwidth মাঝারি → Site-to-Site VPN + interface endpoint। স্থির, বেশি bandwidth লাগবে বা internet একদমই চলবে না → Direct Connect private VIF + interface endpoint (অনেক VPC হলে transit VIF + Direct Connect gateway + TGW)। শুধু “internet দিয়ে না” হলেই চলে আর চালানোর খরচ সবচেয়ে কম চাও → Direct Connect public VIF।

4. তারপর নিয়ন্ত্রণগুলো যোগ করো

   Endpoint policy (কোন bucket), aws:sourceVpce বা aws:sourceVpc সহ bucket policy (কোন পথ), compliance চাইলে Direct Connect-এর জন্য encryption (ওপরে VPN বা MACsec), আর একটা backup পথ (Direct Connect-এর জন্য VPN, VPN-এর জন্য দুটো customer gateway)।

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

• Gateway endpoint বানানোর ঠিক পরেই timeout, লম্বা upload-এ: route যোগ হলে খোলা connection reset হয়। আবার চেষ্টা করো; বদলগুলো backup-এর সময়ের বাইরে করো।
• Gateway endpoint যোগের পর Access Denied: aws:SourceIp (NAT-এর public address) দিয়ে লেখা bucket policy আর মিলছে না, কারণ S3 এখন private address দেখে। aws:sourceVpce বা aws:sourceVpc-তে বদলাও। অথবা endpoint policy-তে bucket-টাই নেই, যেমন agent বা log-এর জন্য AWS-এর দরকারি কোনো bucket।
• Route table বেছে দেওয়া হয়নি: endpoint আছে, কিন্তু এক subnet-এর route table-এ prefix list-এর route নেই, তাই ওই subnet এখনো NAT দিয়ে যায় (আর টাকা দেয়) বা ব্যর্থ হয়।
• Bucket অন্য Region-এ: request চুপচাপ NAT দিয়ে যায়, বা NAT না থাকলে timeout হয়।
• Interface endpoint-এ timeout: endpoint-এর security group client-দের কাছ থেকে 443 allow করছে না, বা DNS এখনো public address দিচ্ছে (private DNS বন্ধ, বা client VPC-র বাইরে আর endpoint-এর নিজস্ব নাম ব্যবহার করছে না)।
• VPN বা Direct Connect দিয়ে on-premises থেকে private-ভাবে S3-তে যাওয়া যাচ্ছে না: কেউ শুধু একটা gateway endpoint বানিয়েছে।
• Peered VPC বা TGW-এর spoke S3-তে পৌঁছাতে পারছে না: সে অন্য VPC-র gateway endpoint ব্যবহারের চেষ্টা করছে (edge-to-edge), অথবা private hosted zone spoke-এর সাথে জোড়া হয়নি।
• নিজের bucket থেকেই তালাবন্ধ: ছাড় ছাড়া aws:sourceVpce-এর deny console-কেও আটকে দেয়।
• Direct Connect “নিরাপদ” কিন্তু encrypted না: compliance audit-এ আটকে যায়। Direct Connect-এর ওপর VPN বা MACsec যোগ করো।

#System design-এ এটা কীভাবে ব্যবহার হয়

• শুধু-private subnet: data, batch আর backup-এর tier, যেখানে NAT একদমই নেই, S3 আর DynamoDB-তে যায় gateway endpoint দিয়ে, বাকি service-এ interface endpoint দিয়ে।
• Data perimeter: একটা endpoint policy যেটা শুধু প্রতিষ্ঠানের নিজের bucket allow করে, আর bucket policy যেটা শুধু প্রতিষ্ঠানের endpoint বা VPC allow করে, যাতে ডেটা বাইরের কোনো bucket-এ চলে যেতে না পারে, আবার বাইরে থেকে পড়াও না যায়।
• Hybrid data platform: on-premises-এর producer-রা লেখে Direct Connect + interface endpoint দিয়ে, VPC-র ভেতরের consumer-রা পড়ে gateway endpoint দিয়ে, আর “শুধু inbound endpoint-এর জন্য private DNS” এই ভাগটা নিজে থেকেই করে দেয়।
• Hub আর spoke: অনেক account-এর জন্য Transit Gateway আর কেন্দ্রীয় interface endpoint; S3-র ভারী ব্যবহারকারীরা GB-প্রতি খরচ এড়াতে local gateway endpoint রাখে।
• বড় ডেটা সরানোর service, যেমন DataSync আর S3 File Gateway (লেসন ১০.১১), সাধারণত এই পথগুলোর ওপরই চলে: যেমন on-premises-এর একটা DataSync agent Direct Connect দিয়ে একটা interface endpoint-এ পাঠাচ্ছে।

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

# 1. Find the S3 prefix list for your Region (used by gateway endpoint routes and security groups)
aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.ap-south-1.s3

# 2. Create a gateway endpoint and attach it to a private subnet's route table
aws ec2 create-vpc-endpoint --vpc-id vpc-0abc1234example \
  --vpc-endpoint-type Gateway --service-name com.amazonaws.ap-south-1.s3 \
  --route-table-ids rtb-0def5678example

# 3. See the route AWS added (destination = pl-..., target = vpce-...)
aws ec2 describe-route-tables --route-table-ids rtb-0def5678example \
  --query "RouteTables[].Routes[]"

# 4. Create an interface endpoint in two subnets with private DNS for on-premises only
aws ec2 create-vpc-endpoint --vpc-id vpc-0abc1234example \
  --vpc-endpoint-type Interface --service-name com.amazonaws.ap-south-1.s3 \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example \
  --security-group-ids sg-0ccc3333example \
  --private-dns-enabled --dns-options PrivateDnsOnlyForInboundResolverEndpoint=true

# 5. Use the interface endpoint by its endpoint-specific name (works from on-premises too)
aws s3 ls s3://bank-backups-example/ --region ap-south-1 \
  --endpoint-url https://bucket.vpce-0a1b2c3d-xyz.s3.ap-south-1.vpce.amazonaws.com

# 6. Check the hybrid side: VPN tunnels and Direct Connect virtual interfaces
aws ec2 describe-vpn-connections --query "VpnConnections[].VgwTelemetry"
aws directconnect describe-virtual-interfaces \
  --query "virtualInterfaces[].[virtualInterfaceType,virtualInterfaceState]"

তারপর gateway endpoint অংশের bucket policy-টা aws s3api put-bucket-policy --bucket bank-backups-example --policy file://policy.json দিয়ে লাগাও, আর মিলিয়ে দেখো: একই aws s3 ls তোমার laptop থেকে এখন deny হচ্ছে, অথচ instance থেকে চলছে।

#সারসংক্ষেপ

মূল কথা

• তিন লেসনে S3-তে যাওয়ার ১৩টা পথ: network-এর পথ এখানে (১–৫), বড় ডেটা সরানোর service ১০.১১-এ (৬–১০), application-এর কৌশল ১০.১২-এ (১১–১৩)।
• দুটো কাজ: S3-তে শেষ ধাপ (gateway endpoint, interface endpoint, Direct Connect public VIF) আর VPC পর্যন্ত রাস্তা (peering, Transit Gateway, VPN, Direct Connect private/transit VIF)। রাস্তা নিজে কখনো S3-তে পৌঁছায় না।
• Gateway endpoint: শুধু S3 আর DynamoDB; S3-এর prefix list সহ route table-এর target; DNS-এর নাম আগের মতোই; ফ্রি; একই Region; on-premises, peered VPC বা transit gateway দিয়ে ব্যবহার করা যায় না; security group নেই। পরীক্ষায় সাশ্রয়ী উত্তর।
• Interface endpoint: বেছে দেওয়া প্রতিটা subnet-এ private IP আর security group সহ PrivateLink ENI; endpoint-এর নিজস্ব নাম বা private DNS (চাইলে শুধু inbound Resolver endpoint-এর জন্য, VPC-তে একটা gateway endpoint থাকলে); AZ-ঘণ্টা প্রতি ~$০.০১ + GB-প্রতি ~$০.০১; on-premises, peered VPC, Transit Gateway আর অন্য Region থেকে পৌঁছানো যায়।
• তালা দাও endpoint policy আর aws:sourceVpce বা aws:sourceVpc সহ bucket policy দিয়ে; endpoint দিয়ে এলে aws:SourceIp কাজ করে না।
• Peering: দুটো VPC, ভিন্ন account আর ভিন্ন Region চলে, CIDR overlap না, দুই দিকেই route, transitive না, edge-to-edge routing নেই, mesh-এ n(n−১)/২, ঘণ্টার খরচ নেই।
• Transit Gateway: regional hub, transitive, RAM দিয়ে share, route table, multicast, VPN-এর bandwidth বাড়াতে ECMP, Direct Connect gateway আর transit VIF দিয়ে একটা Direct Connect share করে; attachment-ঘণ্টা প্রতি ~$০.০৫ + GB-প্রতি $০.০২; S3-তে পৌঁছায় শুধু attach করা কোনো VPC-র interface endpoint দিয়ে।
• Site-to-Site VPN: internet-এর ওপর IPsec, কয়েক মিনিটে চালু, VGW (একটা VPC) বা TGW, CGW = তোমার router-এর public IP, ২টা AZ-এ ২টা tunnel, প্রতিটা ১.২৫ Gbps, BGP বা static, সর্বোচ্চ availability-তে দুটো CGW, branch থেকে branch-এ CloudHub।
• Direct Connect: private line, dedicated ১–৪০০ Gbps বা hosted ৫০ Mbps–২৫ Gbps, চালু হতে প্রায়ই এক মাসের বেশি, private/public/transit VIF, অনেক Region-এর জন্য Direct Connect gateway, encrypted না (ওপরে VPN বা MACsec), দুই location-এ resiliency, সস্তা backup হিসেবে VPN।

নিজেকে যাচাই করো: S3-তে যাওয়ার private network পথ৩২টি প্রশ্ন