VPC Endpoint আর PrivateLink

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

• বোঝাতে, VPC endpoint কেন দরকার: internet-এর পথ নেই এমন subnet থেকে AWS service-এ private পথে যাওয়া, public IP ছাড়া, পথের ওপর policy-র নিয়ন্ত্রণ, আর NAT gateway-র processing fee ছাড়া।
• Gateway endpoint ঠিক কীভাবে কাজ করে (prefix list, route table, longest prefix match, একই Region) আর কেন নিজের VPC-র বাইরের কেউ এটা ব্যবহার করতে পারে না, তা খুলে বলতে।
• Interface endpoint কীভাবে কাজ করে (প্রতি AZ-এ একটা ENI, security group, Regional আর zonal নাম, private DNS আর VPC-র দুটো DNS attribute), আর কে কে এর নাগাল পায়: on-premises, peered VPC, Transit Gateway-র spoke, অন্য Region, তা বলতে।
• Endpoint policy লিখতে, bucket policy (aws:SourceVpce, aws:SourceVpc) আর IAM-এর সাথে মিলিয়ে ব্যবহার করতে, আর এদের দিয়ে একটা data perimeter বানাতে।
• S3 আর DynamoDB-র জন্য gateway না interface endpoint, ঠিক করতে; VPC-র ভেতরের Lambda DynamoDB-তে পৌঁছাতে না পারলে সারাতে; আর NAT আর endpoint-এর বিল হিসাব করতে।
• PrivateLink দিয়ে নিজের service প্রকাশ করতে: NLB, endpoint service, allowed principal, acceptance, private DNS নাম, একমুখী connection, মিলে যাওয়া CIDR, আর ২০২৪–২০২৫-এর cross-Region অপশন।
• লক্ষণ দেখে endpoint-এর সমস্যা ধরতে: timeout না Access Denied, DNS না route না security group।

#VPC endpoint কেন দরকার

Code থেকে তুমি যত AWS service call করো (S3, DynamoDB, SQS, KMS, Secrets Manager, EC2 API…), সবগুলোর ঠিকানা একটা public service endpoint, যেমন sqs.ap-south-1.amazonaws.com, যেটা resolve হয় public IP address-এ। Private subnet-এর একটা instance-এর public IP নেই, internet gateway-তে যাওয়ার route-ও নেই, তাই বাড়তি কিছু না করলে সে এদের কাউকেই call করতে পারে না।

লেসন ৩.৪-এ পুরোনো সমাধানটা দেখেছ: public subnet-এ একটা NAT gateway, আর তার দিকে একটা 0.0.0.0/0 route। এতে কাজ চলে, কিন্তু তিনটা দাম দিতে হয়:

• টাকা। NAT gateway ঘণ্টা ধরে টাকা নেয়, আর যত GB process করে, প্রতিটার জন্যও (us-east-1-এ মোটামুটি ঘণ্টায় $০.০৪৫ + GB-প্রতি $০.০৪৫)। S3 বা DynamoDB-তে ভারী traffic থাকলে বিলের সবচেয়ে বড় লাইনটাই হয়ে যেতে পারে NAT।
• Internet-এর একটা পথ। Subnet এখন internet-এর যেকোনো জায়গায় যেতে পারে। অনেক regulator আর security team data tier-এর জন্য এটা মানে না।
• নিয়ন্ত্রণ কম। Service দেখে NAT gateway-র public IP, তাই “এই bucket শুধু আমার VPC থেকে আসা request-এর জন্য” এমন কথা বলা যায় না।

VPC endpoint subnet-কে service-এ যাওয়ার একটা private পথ দেয়, internet gateway, NAT device, VPN বা public IP কোনোটাই লাগে না। Traffic AWS network দিয়ে service-এ যায়, service বুঝতে পারে request কোন endpoint আর কোন VPC দিয়ে এল, আর endpoint-এর গায়েই তুমি একটা policy বসাতে পারো।

#VPC endpoint কত রকমের

পরীক্ষা মূলত প্রথম দুটো নিয়ে, আর তৃতীয়টা আসে “third-party appliance” প্রসঙ্গে। PrivateLink নামটার জন্মই interface endpoint থেকে: এটা সেই প্রযুক্তি, যেটা একটা service-এর private প্রবেশপথ তোমার VPC-র ভেতরে বসিয়ে দেয়, ফলে তোমার application ভাবে service-টা যেন তার নিজের network-এই আছে।

#Gateway endpoint ভেতর থেকে

#Gateway endpoint কীভাবে traffic ঘোরায়

তুমি com.amazonaws.ap-south-1.s3 বা com.amazonaws.ap-south-1.dynamodb-এর মতো একটা service name-এর জন্য gateway endpoint বানাও, VPC বেছে দাও, আর যেসব route table এটা ব্যবহার করবে সেগুলোতে টিক দাও।

1. টিক দেওয়া প্রতিটা route table-এ AWS একটা route যোগ করে: destination = এই Region-এ service-টার AWS-managed prefix list (pl-…, তার সব address range-এর একটা নামওয়ালা তালিকা), target = endpoint (vpce-…)। Route-টা তুমি দেখতে পাবে, কিন্তু বদলাতে বা মুছতে পারবে না; সরাতে চাইলে route table-টা endpoint থেকে খুলে নাও, বা endpoint-টাই মুছে দাও।
2. তোমার code আগের মতোই সাধারণ নামটা call করে, যেমন s3.ap-south-1.amazonaws.com। DNS তখনো একটা public S3 address ফেরত দেয়। Application-এ কিছুই বদলায় না।
3. VPC router এখন ওই address-এর জন্য দুটো route পায়: 0.0.0.0/0 (NAT বা internet gateway-র দিকে) আর prefix list। বেশি নির্দিষ্ট route জেতে (longest prefix match, লেসন ৩.৩), তাই S3-র traffic যায় endpoint-এ, বাকি সবকিছু আগের পথেই চলে।
4. কেউ যদি service-এর ঠিক ওই IP range-টাই একটা route-এ লিখে দেয়, সেটা endpoint route-কে হারিয়ে দেবে। আর অন্য Region-এর একই service-এর traffic prefix list-এর সাথে মেলেই না, তাই সেটা 0.0.0.0/0 ধরে চলে।

“এটা তো শুধু একটা route”, এই কথা থেকেই কয়েকটা নিয়ম বেরিয়ে আসে:

• এটা কাজ করে route table ধরে, পুরো VPC ধরে না। যে subnet-এর route table-এ টিক দাওনি, সেটা এখনো NAT দিয়ে যায় (আর টাকা গোনে), নয়তো কোনো পথই পায় না।
• একটা route table-এ S3-এর endpoint route আর DynamoDB-র endpoint route দুটোই থাকতে পারে, কিন্তু একই service-এর দুটো route না।
• Route যোগ হওয়ার মুহূর্তে ওই subnet-গুলো থেকে service-এর দিকে খোলা TCP connection reset হয়ে যায়, কারণ পথ বদলে গেছে।

#Security group, network ACL আর DNS

Gateway endpoint-এর নিজের কোনো ENI, IP address বা security group নেই। Instance-গুলো তখনো service-এর public address-এর সাথেই কথা বলে, তাই:

• Instance-এর security group-এ service-এর দিকে outbound TCP 443 allow থাকতে হবে। Rule-এর destination হিসেবে prefix list (pl-…) সরাসরি দেওয়া যায়।
• Network ACL prefix list চেনে না: service-এর CIDR range-গুলো (prefix list-এ যা আছে) allow করো, নয়তো default allow-all রেখে দাও।
• VPC-র DNS resolution চালু রাখো, যাতে instance service-এর নাম resolve করতে পারে; default ছাড়া অন্য DNS record type (IPv6 বা dual-stack উত্তর) চাইলে enableDnsSupport আর enableDnsHostnames দুটোই চালু থাকতে হবে।

#Gateway endpoint-এর সীমা

• শুধু S3 আর DynamoDB, আর শুধু endpoint-এর নিজের Region-এ।
• শুধু তার VPC-র ভেতরে শুরু হওয়া traffic-এর জন্য। Site-to-Site VPN, Direct Connect, VPC peering বা transit gateway দিয়ে আসা traffic এদিকে পাঠানো যায় না: “gateway endpoint কখনো নিজের VPC-র বাইরে টেনে নেওয়া যায় না”।
• ফ্রি: ঘণ্টা বা GB-প্রতি কোনো খরচ নেই। S3 আর DynamoDB-র সাধারণ request-এর খরচ অবশ্য থাকছেই।
• Quota: default হিসেবে প্রতি account-এ প্রতি Region-এ ২০টা gateway endpoint (বাড়ানো যায়), এক VPC-তে সর্বোচ্চ ২৫৫টা। নিজের কোনো bandwidth সীমা নেই।
• IPv6: IP address type হতে পারে IPv4, IPv6 (শুধু IPv6-only subnet-এ) বা dual-stack।
• একটা endpoint policy লাগানো যায় (নিচে আছে)। Gateway endpoint-এর policy-তে Principal হতে হবে *; caller বাছাই করতে হয় aws:PrincipalArn condition দিয়ে।

#Interface endpoint ভেতর থেকে

#কী কী তৈরি হয়

একটা interface endpoint (PrivateLink) তোমার বেছে দেওয়া প্রতিটা subnet-এ একটা endpoint network interface বসায়, প্রতি AZ-এ একটা subnet। প্রতিটা ENI:

• নিজের subnet থেকে একটা private IP পায়, endpoint যতদিন আছে ততদিন সেটা বদলায় না (চাইলে IP-টা তুমি নিজেই বেছে দিতে পারো);
• requester-managed: তোমার account-এ দেখা যায়, কিন্তু বদলানো বা খুলে নেওয়া যায় না;
• এক বা একাধিক security group পায়। তুমি কিছু না বাছলে AWS বসিয়ে দেয় VPC-র default security group, যেটা শুধু নিজের সদস্যদের traffic allow করে। Timeout-এর এক পুরোনো উৎস এটাই;
• TCP-র উত্তর দেয় (AWS service-এর ক্ষেত্রে 443-এ HTTPS), কিন্তু ping-এর উত্তর কখনো দেয় না: পরীক্ষা করো nc -vz বা curl দিয়ে, ICMP দিয়ে না।

Interface endpoint আছে বেশিরভাগ AWS service-এর জন্য: SQS, SNS, KMS, Secrets Manager, STS, ECR, CloudWatch Logs, EC2 API, Lambda, Systems Manager, আর S3 আর DynamoDB-রও (DynamoDB-র ২০২৪ থেকে)। Service যদি S3 বা DynamoDB হয় আর caller একই VPC-তে থাকে, তাহলে gateway endpoint-ই সস্তা।

#Endpoint ব্যবহার হবে কি না, ঠিক করে DNS

Interface endpoint শুধু সেই traffic পায়, যেটা তার IP-তে পাঠানো হয়। Client কোন IP-তে পাঠাবে, সেটা পুরোপুরি DNS-এর হাতে:

• Regional আর zonal endpoint নাম। প্রতিটা interface endpoint এমন নাম পায়: vpce-0a1b2c3d-x1y2.sqs.ap-south-1.vpce.amazonaws.com (Regional, সব AZ) আর vpce-0a1b2c3d-x1y2-ap-south-1a.sqs.ap-south-1.vpce.amazonaws.com (zonal, একটা AZ, traffic ওই AZ-এই রাখে)। এই record-গুলো থাকে public DNS-এ, কিন্তু resolve হয় private IP-তে, তাই VPC-তে route করতে পারে এমন যে-কেউ --endpoint-url বা SDK-র endpoint override দিয়ে এগুলো ব্যবহার করতে পারে।
• Private DNS (AWS service-এর জন্য default-এ চালু)। AWS তোমার VPC-তে একটা লুকানো private hosted zone বানায়, যেটা service-এর সাধারণ নামটা (sqs.ap-south-1.amazonaws.com) endpoint ENI-গুলোর দিকে দেখায়। পুরোনো code আর SDK কোনো বদল ছাড়াই endpoint ব্যবহার করে। এর জন্য VPC-র দুটো attribute, enableDnsSupport আর enableDnsHostnames, দুটোই চালু থাকতে হয়; যেকোনো একটা বন্ধ থাকলে private DNS চালুই করা যায় না।
• ওই লুকানো zone কাজ করে শুধু endpoint-এর নিজের VPC-র ভেতরে। Peered VPC, Transit Gateway-র spoke বা on-premises server এটা দেখতে পায় না: তাদের লাগে endpoint-এর নিজস্ব নাম, তোমার বানানো আর জুড়ে দেওয়া একটা Route 53 private hosted zone, অথবা Resolver forwarding (লেসন ৮.৫)।
• S3-এর বিশেষ ব্যবস্থা: “private DNS শুধু inbound endpoint-এর জন্য”। VPC-র ভেতরের client-রা S3-কে public address-এই resolve করতে থাকে আর ফ্রি gateway endpoint ব্যবহার করে; আর Route 53 Resolver inbound endpoint-এ আসা প্রশ্নগুলো (on-premises থেকে) পায় interface endpoint-এর IP। VPC-তে S3-এর gateway endpoint না থাকলে AWS এই setting নেয়ই না। বিস্তারিত লেসন ১০.১০-এ।
• DynamoDB-র বিশেষ ব্যবস্থা: DynamoDB-র interface endpoint private DNS সমর্থন করে না, আর dynamodb.<region>.amazonaws.com-কে নিজের private zone দিয়ে ঢেকে দিতে AWS নিষেধ করে। Client-কে endpoint-এর নিজস্ব URL-ই ব্যবহার করতে হয়।

AZ একটা হলে DNS একটাই IP ফেরত দেয়, আর সব AZ-এর client সেখানে পাড়ি দেয় (প্রতিবার বাড়তি একটা AZ পার হওয়ার latency, আর ওই AZ-এ বিভ্রাট হলে সবাই একসাথে আটকে যায়; PrivateLink-এ AZ পেরোনোর data transfer-এর টাকা ২০২২-এর এপ্রিল থেকে আর লাগে না)। কয়েকটা AZ থাকলে DNS সব সুস্থ ENI-র IP ফেরত দেয়।

#VPC-র বাইরে থেকে interface endpoint-এ পৌঁছানো

Interface endpoint যেহেতু কিছু সত্যিকারের private IP, তাই ওই IP-তে route করতে পারে এমন যে-কেউ এটা ব্যবহার করতে পারে:

Endpoint-এর security group-এ শুধু VPC না, এই caller-দের range থেকেও 443 allow করতে হবে (অফিসের CIDR, spoke-গুলোর CIDR)।

#খরচ, bandwidth আর quota

দামগুলো us-east-1-এর list price (অক্টোবর ২০২৬-এ মিলিয়ে দেখা); বেশিরভাগ Region কাছাকাছি, কয়েকটা একটু বেশি।

• ঘণ্টা: মোটামুটি প্রতি endpoint প্রতি AZ-ঘণ্টায় $০.০১। ৭৩০ ঘণ্টার মাসে ৩ AZ-এ একটা endpoint: ৩ × ৭৩০ × $০.০১ = $২১.৯০। দশটা AWS service × ৩ AZ = ডেটা ছাড়াই মাসে $২১৯, বড় VPC-তে এটা সত্যিকারের খরচ।
• ডেটা process: মাসের প্রথম PB পর্যন্ত GB-প্রতি $০.০১, পরের ৪ PB-তে $০.০০৬, ৫ PB-র ওপরে $০.০০৪ (এক Region-এ তোমার সব endpoint মিলিয়ে গোনা হয়)।
• NAT-এর সাথে তুলনা: NAT gateway ঘণ্টায় ~$০.০৪৫ + GB-প্রতি $০.০৪৫। মাসে ১ TB হলে: NAT ≈ $৩২.৮৫ + $৪৬.০৮ = $৭৯; ২ AZ-এ interface endpoint ≈ $১৪.৬০ + $১০.২৪ = $২৫; gateway endpoint $০ (শুধু S3 আর DynamoDB)।
• Bandwidth: default-এ প্রতি AZ-এ ১০ Gbps, নিজে থেকেই বেড়ে প্রতি AZ-এ ১০০ Gbps পর্যন্ত। MTU ৮,৫০০ byte; এর চেয়ে বড় packet ফেলে দেওয়া হয়, আর Path MTU Discovery চলে না (MSS clamping করা হয়)।
• Quota: এক VPC-তে interface আর Gateway Load Balancer endpoint মিলিয়ে ৫০টা (বাড়ানো যায়); endpoint policy সর্বোচ্চ ২০,৪৮০ অক্ষর।

#অন্য Region-এ interface endpoint

পুরোনো নিয়ম (আর পরীক্ষারও): interface endpoint যুক্ত হয় নিজের Region-এর service-এর সাথে; অন্য Region-এ যেতে হলে সেখানকার একটা endpoint-এ route করো inter-Region peering বা Transit Gateway peering দিয়ে। এখন আরও দুটো অপশন আছে:

• নভেম্বর ২০২৪: provider তার নিজের endpoint service অন্য Region-এও দিতে পারে, আর consumer নিজের Region-এই interface endpoint বানায়। Provider প্রতিটা দূরের Region-এর জন্য ঘণ্টা ধরে একটা fee দেয়; consumer দেয় endpoint-এর সাধারণ খরচ আর inter-Region data transfer।
• নভেম্বর ২০২৫: কিছু AWS service-এ cross-Region interface endpoint (--service-region) দিয়ে যাওয়া যায়: S3, IAM, KMS, ECR, ECS, Lambda, Data Firehose, Managed Service for Apache Flink, Route 53। এর জন্য IAM আর SCP দুই জায়গাতেই vpce:AllowMultiRegion permission লাগে, শুধু Regional DNS নাম চলে (zonal না), আর latency ও খরচের কারণে AWS এখনো একই Region-এর endpoint-কেই প্রথম পছন্দ বলে।

পরীক্ষায় যদি দুটোই অপশনে থাকে, “অন্য Region-এ interface endpoint, peering দিয়ে” আর “cross-Region endpoint” দুটোই private; প্রশ্নের keyword (সবচেয়ে কম জিনিস, peering ছাড়া) যেদিকে দেখায় সেটাই নাও, আর মনে রাখো gateway endpoint কখনো Region পার হয় না।

#Endpoint policy

Endpoint policy হলো endpoint-এর গায়ে লাগানো একটা IAM resource-based policy। এটা বলে, কোন principal এই endpoint দিয়ে কোন resource-এ কোন action করতে পারবে।

• Gateway endpoint-এ চলে, আর interface endpoint-এ চলে সেসব AWS service-এর জন্য যারা এটা সমর্থন করে (বেশিরভাগই করে)। এক endpoint-এ একটা policy, যখন খুশি বদলানো যায়; বদল কার্যকর হতে কয়েক মিনিট লাগে।
• Default policy হলো full access ("Principal": "*", "Action": "*", "Resource": "*")।
• এটা কখনো কিছু দেয় না। Endpoint দিয়ে যাওয়া একটা request-কে IAM আর endpoint policy আর যেকোনো resource policy (bucket policy, key policy) সবাইকে allow করতে হয়, আর কোনো SCP deny করতে পারবে না (লেসন ২.২)।
• এটা দেখে শুধু সেই request, যা endpoint দিয়ে যায়। Internet-এর একটা laptop থেকে আসা request এর সামনে কখনো পড়েই না।
• তোমার নিজের বা partner-এর endpoint service-এর ক্ষেত্রে endpoint policy ঘোরানোর কিছু নেই: AWS full access দেয়, আর access নিয়ন্ত্রণ করে provider তার allowed principal দিয়ে।

এর সবচেয়ে চেনা ব্যবহার হলো দুই দিক থেকে একটা data perimeter:

{
  "Statement": [
    {
      "Sid": "OnlyOurOrganisationsBuckets",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": { "StringEquals": { "aws:ResourceOrgID": "o-a1b2c3d4e5" } }
    }
  ]
}

এই endpoint policy instance-দের শুধু কোম্পানির AWS Organization-এর bucket ব্যবহার করতে দেয়, তাই বৈধ credential-ওয়ালা malware-ও endpoint দিয়ে চুরি করা ডেটা হামলাকারীর bucket-এ তুলতে পারে না। উল্টো দিকটা সামলায় bucket policy, aws:SourceVpce (একটা endpoint) বা aws:SourceVpc (এক VPC-র যেকোনো endpoint) দিয়ে, যেটা লেসন ১০.২ আর ১০.১০-এ দেখেছ: এই bucket শুধু আমাদের endpoint দিয়ে আসা request নেবে, তাই ফাঁস হওয়া key বাইরে থেকে ব্যবহার করলে ফিরিয়ে দেওয়া হয়। Endpoint দিয়ে এলে aws:SourceIp মেলে না (request-এ কোনো public source address থাকে না); private range-এর জন্য aws:VpcSourceIp ব্যবহার করো।

DynamoDB-তেও একই কায়দায় একটা endpoint-কে নির্দিষ্ট table-এ বেঁধে দেওয়া যায়, যেমন "Resource": "arn:aws:dynamodb:ap-south-1:111122223333:table/Orders"।

#S3 আর DynamoDB-র জন্য gateway না interface endpoint?

দুটো service-ই দুই ধরনের endpoint সমর্থন করে, আর একই VPC-তে দুটোই রাখা যায়।

#VPC-র ভেতরের Lambda থেকে DynamoDB

কেন সমস্যা হয়, সেটা লেসন ১৫.৩-এ দেখেছ: তোমার VPC-তে জোড়া function যে ENI পায়, তাতে শুধু private IP থাকে, public IP কখনো না, public subnet-এ রাখলেও না। তাই সে তার default internet access হারায়, আর DynamoDB, যেটা একটা public service, নাগালের বাইরে চলে যায়। সমাধান দুটো:

• NAT gateway: private subnet → public subnet-এর NAT gateway → internet gateway → DynamoDB। যেকোনো গন্তব্যে চলে, কিন্তু ঘণ্টা আর GB ধরে টাকা।
• DynamoDB-র gateway endpoint (best practice): বানাও, private subnet-গুলোর route table জুড়ে দাও, ব্যস। ফ্রি, internet-এর পথ নেই, code-এ কোনো বদল নেই।

বাস্তবের বেশিরভাগ function দুটোই ব্যবহার করে: AWS service-এর জন্য endpoint (S3 আর DynamoDB-র জন্য gateway, Secrets Manager, SQS…-এর জন্য interface), আর NAT gateway শুধু internet-এর third-party API-র জন্য।

#নিজের service-এর জন্য PrivateLink

এতক্ষণ provider ছিল AWS। PrivateLink দিয়ে তুমি নিজেও provider হতে পারো: একটা service এমনভাবে প্রকাশ করো, যাতে অন্য VPC আর অন্য AWS account সেখানে private-ভাবে পৌঁছায়, peering ছাড়া, internet ছাড়া, আর তোমার network-এর বাকি কিছু না খুলেই। লেসন ৬.৩-এ load balancer-এর দিক থেকে ধারণাটা দেখেছ; এখানে পুরো কাজের ধারা।

#Endpoint service কীভাবে কাজ করে

1. Provider: application-কে কমপক্ষে দুই AZ-এ একটা Network Load Balancer-এর পেছনে রাখো (appliance হলে Gateway Load Balancer)। Path rule-ওয়ালা HTTP app থাকতে পারে একটা NLB-র পেছনে, target হিসেবে ALB দিয়ে।
2. Provider: ওই NLB থেকে একটা VPC endpoint service বানাও। একটা service name পাবে, যেমন com.amazonaws.vpce.ap-south-1.vpce-svc-0f1e2d3c4b5a69788।
3. Provider: allowed principal যোগ করো (account ID, IAM role বা user, বা *)। Default-এ কেউই যুক্ত হতে পারে না।
4. Provider: প্রতিটা connection হাতে অনুমোদন করতে চাইলে acceptance required বেছে নাও, নইলে নিজে থেকেই accept হবে।
5. Consumer: নিজের VPC-তে ওই service name-এর জন্য একটা interface endpoint বানায় (service যেসব AZ-এ আছে, সেসব AZ-এর subnet-এ), সাথে একটা security group।
6. Provider: connection-টা accept করে (pendingAcceptance → available)। পরে চাইলে provider connection reject বা বাতিল করতে পারে।

পরীক্ষার প্রশ্ন যেসব ফল ধরে:

• CIDR মিলে গেলেও কিছু যায় আসে না। দুই VPC-র মধ্যে কোনো route বিনিময় হয় না; consumer কথা বলে তার নিজের ENI-র সাথে, PrivateLink connection-টা NLB-র হাতে দেয়।
• একটা service, পুরো network না। Consumer শুধু ওই NLB-র listener পর্যন্ত যেতে পারে, provider VPC-র আর কিছুতে না, আর provider-ও consumer VPC-র কিছুই দেখে না।
• একমুখী। Connection খোলে শুধু consumer; উত্তর ঠিকই ফেরে, কিন্তু provider consumer-এর ভেতরে নতুন connection শুরু করতে পারে না। দুই দিকে চাইলে দুটো endpoint service লাগবে।
• Source IP। Application দেখে NLB-র private IP, consumer-এর না। Consumer-এর IP আর endpoint ID পেতে NLB-র target group-এ proxy protocol v2 চালু করো।
• AZ। Service যেসব AZ-এ আছে, consumer শুধু সেগুলোই ব্যবহার করতে পারে। AZ-এর নাম account ভেদে আলাদা (এখানকার ap-south-1a ওখানে অন্য বিল্ডিং হতে পারে), তাই মেলাও AZ ID দিয়ে (aps1-az1)।
• Scale। অনেক consumer-এর জন্যই বানানো: একটা service-এ শত শত বা হাজার হাজার customer VPC যুক্ত হতে পারে।
• খরচ। Consumer দেয় interface endpoint-এর ঘণ্টা আর GB-প্রতি খরচ; provider দেয় NLB-র খরচ।
• Cross-Region। নভেম্বর ২০২৪ থেকে provider service-টা অন্য Region-এও দিতে পারে (ওপরে দেখো); নইলে অন্য Region-এর consumer peering বা transit gateway দিয়ে পৌঁছায়।

#Endpoint service-এর private DNS নাম

Consumer সবসময় endpoint-এর নিজস্ব নাম ব্যবহার করতে পারে। Provider চাইলে একটা private DNS নাম-ও জুড়ে দিতে পারে, যেমন api.fintech.example, যাতে consumer একটা সহজ নামে call করে, আর নামটা তাদের VPC-র ভেতরে তাদের নিজের endpoint ENI-তে resolve হয় (বাইরে থেকে, public endpoint থাকলে, সেখানে)। Consumer ব্যবহার করার আগে provider-কে প্রমাণ করতে হয় domain-টা তার: AWS একটা TXT record-এর নাম আর মান দেয়, provider সেটা public DNS-এ বসায়, আর verification status হতে হয় verified। পরে verification ব্যর্থ হলে নতুন connection ফিরিয়ে দেওয়া হয়; পুরোনোগুলো চলতে থাকে। Gateway Load Balancer-এর endpoint service-এ private DNS নাম চলে না।

#PrivateLink না VPC peering?

#Gateway Load Balancer endpoint আর VPC Lattice, সংক্ষেপে

• Gateway Load Balancer endpoint হলো এমন একটা PrivateLink endpoint, যেটা তুমি route table-এর next hop হিসেবে ব্যবহার করো, যাতে traffic একটা Gateway Load Balancer-এর পেছনের third-party firewall বা IDS appliance-এর বহরের ভেতর দিয়ে যায় (GENEVE, লেসন ৬.৩)। AWS Network Firewall-ও একই কায়দা ব্যবহার করে (লেসন ২২.৭)।
• VPC Lattice (২০২৩) application layer-এ বিভিন্ন VPC আর account-এর service জোড়ে, নিজের auth policy দিয়ে; ২০২৪-এর শেষ থেকে PrivateLink-এর resource endpoint আর service-network endpoint load balancer ছাড়াই share করা একটা resource (database, IP address, domain name) বা পুরো একটা Lattice service network-এ পৌঁছায়। পরীক্ষায় এখনো কমই উত্তর হয়; নামগুলো চিনে রাখো।

#Endpoint বেছে নেওয়া

1. Service-টা কী?

   S3 বা DynamoDB → gateway endpoint সম্ভব। অন্য যেকোনো AWS service → interface endpoint। তোমার নিজের বা partner-এর service → একটা endpoint service-এ interface endpoint (PrivateLink)।

2. Caller কোথায়?

   একই VPC, একই Region → S3 আর DynamoDB-র জন্য gateway endpoint। Region-এর অন্য VPC → তার নিজের gateway endpoint, অথবা অনেক VPC হলে share করা interface endpoint। On-premises বা অন্য Region → interface endpoint, সাথে caller-এর জন্য DNS।

3. DNS-কে endpoint দেখাও

   VPC-র ভেতরের caller-এর জন্য private DNS চালু (দুটো VPC attribute-সহ); বাকি সবার জন্য endpoint-এর নিজস্ব নাম, private hosted zone বা Resolver forwarding; DynamoDB-র interface endpoint শুধু URL দিয়ে।

4. তালা দাও আর মাপ ঠিক করো

   Endpoint-এর security group আসল caller-দের থেকে 443 allow করবে; endpoint policy resource সীমিত করবে; bucket বা key policy aws:SourceVpce চাইবে; অন্তত দুই AZ; আর প্রতিটা VPC-তে বিশটা endpoint বসানোর আগে AZ-ঘণ্টা আর GB গুনে নাও।

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

Endpoint-এ ঝামেলা হলে slide-এর প্রথম পরামর্শ: আগে VPC-র DNS setting দেখো, তারপর route table। লক্ষণ থেকে শুরু করো:

#System design-এ এর ব্যবহার

• শুধু private data tier: NAT একদমই না; S3 আর DynamoDB-র জন্য gateway endpoint, KMS, Secrets Manager, SQS, CloudWatch Logs, ECR, STS আর Systems Manager-এর জন্য interface endpoint। Private subnet-এর container ECR থেকে image টানলে লাগে ecr.api, ecr.dkr interface endpoint আর S3-এর gateway endpoint (image-এর layer থাকে S3-তে)।
• Data perimeter: endpoint policy শুধু organisation-এর resource allow করে, bucket আর key policy শুধু organisation-এর endpoint বা VPC allow করে, আর SCP দিয়ে সেগুলো বাধ্যতামূলক করা হয়।
• Shared endpoints VPC: Transit Gateway-ওয়ালা hub-and-spoke network-এ প্রতিটা VPC-তে ২০টা endpoint × ৩ AZ না বসিয়ে, একটা কেন্দ্রীয় VPC-তে একসেট interface endpoint আর spoke-গুলোর সাথে share করা Route 53 private hosted zone। S3-এর ভারী ব্যবহারকারীরা নিজেদের ফ্রি gateway endpoint রাখে।
• Hybrid access: on-premises Direct Connect দিয়ে interface endpoint হয়ে AWS API আর S3-তে পৌঁছায়, DNS-এর জন্য Resolver inbound endpoint।
• SaaS আর platform team: একটা payment বা identity service একবার PrivateLink দিয়ে প্রকাশ করা হয়, আর অনেক account-এর শত শত VPC সেটা ব্যবহার করে, CIDR মিলে গেলেও। Marketplace-এর SaaS vendor-রাও এভাবেই service দেয়।

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

# 1. Find the S3 and DynamoDB prefix lists in Mumbai (what a gateway endpoint route points at)
aws ec2 describe-prefix-lists --region ap-south-1 \
  --query "PrefixLists[].[PrefixListName,PrefixListId]" --output text
# com.amazonaws.ap-south-1.dynamodb    pl-66a5400f
# com.amazonaws.ap-south-1.s3          pl-6ca54005

# 2. Gateway endpoints for S3 and DynamoDB on the private route tables
aws ec2 create-vpc-endpoint --vpc-id vpc-0a1b2c3d4e5f67890 \
  --vpc-endpoint-type Gateway --service-name com.amazonaws.ap-south-1.s3 \
  --route-table-ids rtb-0aa11bb22cc33dd44 rtb-0ee55ff66aa77bb88
aws ec2 create-vpc-endpoint --vpc-id vpc-0a1b2c3d4e5f67890 \
  --vpc-endpoint-type Gateway --service-name com.amazonaws.ap-south-1.dynamodb \
  --route-table-ids rtb-0aa11bb22cc33dd44

# 3. The route AWS added (destination pl-..., target vpce-...)
aws ec2 describe-route-tables --route-table-ids rtb-0aa11bb22cc33dd44 \
  --query "RouteTables[].Routes[?DestinationPrefixListId]"
# [[{"DestinationPrefixListId": "pl-6ca54005", "GatewayId": "vpce-0a1b2c3d4e5f60718", "State": "active", ...}]]

# 4. Both DNS attributes on, then an SQS interface endpoint in two AZs with private DNS
aws ec2 modify-vpc-attribute --vpc-id vpc-0a1b2c3d4e5f67890 --enable-dns-support "{\"Value\":true}"
aws ec2 modify-vpc-attribute --vpc-id vpc-0a1b2c3d4e5f67890 --enable-dns-hostnames "{\"Value\":true}"
aws ec2 create-vpc-endpoint --vpc-id vpc-0a1b2c3d4e5f67890 \
  --vpc-endpoint-type Interface --service-name com.amazonaws.ap-south-1.sqs \
  --subnet-ids subnet-0a1b2c3d4e5f60001 subnet-0a1b2c3d4e5f60002 \
  --security-group-ids sg-0endpoint443example --private-dns-enabled

# 5. From an instance: does the normal name resolve to the ENIs? Is 443 open?
dig +short sqs.ap-south-1.amazonaws.com
# 10.0.1.40
# 10.0.2.40
nc -vz sqs.ap-south-1.amazonaws.com 443
# Connection to sqs.ap-south-1.amazonaws.com (10.0.1.40) 443 port [tcp/https] succeeded!

# 6. Restrict the S3 gateway endpoint to the organisation's buckets
aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-0a1b2c3d4e5f60718 \
  --policy-document file://only-our-buckets.json

# 7. Provider: publish an NLB as an endpoint service, allow one bank, accept its request
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:ap-south-1:111122223333:loadbalancer/net/score-nlb/0a1b2c3d4e5f6789 \
  --acceptance-required --private-dns-name api.fintech.example
aws ec2 modify-vpc-endpoint-service-permissions --service-id vpce-svc-0f1e2d3c4b5a69788 \
  --add-allowed-principals arn:aws:iam::444455556666:root
aws ec2 describe-vpc-endpoint-connections --filters Name=service-id,Values=vpce-svc-0f1e2d3c4b5a69788 \
  --query "VpcEndpointConnections[].[VpcEndpointId,VpcEndpointOwner,VpcEndpointState]" --output text
# vpce-0c9d8e7f6a5b43210   444455556666   pendingAcceptance
aws ec2 accept-vpc-endpoint-connections --service-id vpce-svc-0f1e2d3c4b5a69788 \
  --vpc-endpoint-ids vpce-0c9d8e7f6a5b43210

# 8. Consumer (the bank's account): connect to the service
aws ec2 create-vpc-endpoint --vpc-id vpc-0b2c3d4e5f6a78901 --vpc-endpoint-type Interface \
  --service-name com.amazonaws.vpce.ap-south-1.vpce-svc-0f1e2d3c4b5a69788 \
  --subnet-ids subnet-0c1d2e3f4a5b60001 subnet-0c1d2e3f4a5b60002 \
  --security-group-ids sg-0bankclients443example

তারপর aws ec2 describe-vpc-endpoint-service-configurations --query "ServiceConfigurations[].PrivateDnsNameConfiguration" দিয়ে provider-এর domain verification দেখো, যে TXT record দেখায় সেটা বসাও, আর state verified হওয়া পর্যন্ত লক্ষ রাখো।

#সারসংক্ষেপ

মূল কথাগুলো

• VPC endpoint private subnet-কে internet gateway, NAT device, VPN বা public IP ছাড়াই AWS service-এ পৌঁছে দেয়; এটা internet-এর পথ আর NAT-এর GB-প্রতি fee সরিয়ে দেয়, আর policy-র নিয়ন্ত্রণ যোগ করে। (AWS service-এর traffic দুই ক্ষেত্রেই AWS network-এর ভেতরে থাকে।)
• Gateway endpoint: শুধু S3 আর DynamoDB; টিক দেওয়া route table-এ একটা prefix-list route; longest prefix match-এ 0.0.0.0/0-কে হারায়; ফ্রি; একই Region; ENI, IP বা security group নেই; on-premises, peered VPC, Transit Gateway বা অন্য Region থেকে কখনো ব্যবহার করা যায় না। পরীক্ষার “most cost-effective” উত্তর।
• Interface endpoint (PrivateLink): প্রতি AZ-এ একটা ENI, private IP আর security group সহ (কিছু না বাছলে default SG); ব্যবহার হবে কি না ঠিক করে DNS: Regional/zonal নাম, অথবা private DNS, যার লাগে enableDnsSupport আর enableDnsHostnames, আর যেটা কাজ করে শুধু নিজের VPC-তে; AZ-ঘণ্টা প্রতি ~$০.০১ + GB-প্রতি ~$০.০১; on-premises, peered VPC, spoke আর অন্য Region থেকে নাগালে; ping চলে না।
• S3-এ চলে “private DNS শুধু inbound endpoint-এর জন্য” (gateway endpoint লাগে); DynamoDB-র interface endpoint-এ private DNS নেই।
• Endpoint policy: endpoint-এর গায়ে resource policy, default full access, এটা শুধু সীমা টানে; দুই দিকের data perimeter-এর জন্য bucket policy-র aws:SourceVpce / aws:SourceVpc-এর সাথে জোড়া বাঁধো।
• S3-এর বাছাই: VPC-র ভেতর → gateway; on-premises, অন্য VPC, অন্য Region → interface। VPC-র Lambda → DynamoDB: gateway endpoint + route table update।
• Endpoint service: NLB (বা GWLB) → endpoint service → allowed principal → acceptance → consumer-এর interface endpoint; CIDR মিললেও চলে, একমুখী, শুধু একটা service; client IP-র জন্য proxy protocol v2; AZ ID মেলাও; private DNS নাম TXT record দিয়ে verify।
• ২০২৪ থেকে নতুন: cross-Region endpoint service (নভেম্বর ২০২৪), কিছু AWS service-এর cross-Region interface endpoint (নভেম্বর ২০২৫), resource আর service-network endpoint (VPC Lattice)। পরীক্ষার default: একই Region-এর endpoint।
• লক্ষণ ধরে সমস্যা খোঁজো: timeout → DNS, route table, security group; Access Denied → endpoint, bucket বা IAM policy।

নিজেকে যাচাই করো: VPC endpoint আর PrivateLink৩২টি প্রশ্ন