Amazon API Gateway

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

• Serverless API-র সামনের দরজা হিসেবে Amazon API Gateway কী করে (client → API Gateway → Lambda → DynamoDB) সেটা বুঝিয়ে বলতে, আর কোন কোন কাজ সে তোমার ঘাড় থেকে নামিয়ে দেয় তার তালিকা দিতে: routing, stage, security, API key আর usage plan, throttling, validation, transformation, caching, OpenAPI import, WebSocket।
• তিন রকম API, মানে REST, HTTP আর WebSocket-এর মধ্যে feature আর দাম দেখে বেছে নিতে।
• একটা API-কে Lambda function (proxy বা custom), HTTP backend, Kinesis Data Streams-এর মতো AWS service, বা mock-এর সাথে জুড়তে, আর 500-এর পেছনে লুকানো permission-এর অভাব ধরে ঠিক করতে।
• Endpoint type বেছে নিতে, edge-optimized, Regional নাকি private, আর ঠিক Region-এর ACM certificate দিয়ে তাতে custom domain বসাতে।
• IAM (SigV4), Cognito user pool, Lambda authorizer, resource policy আর AWS WAF দিয়ে API সুরক্ষিত করতে, আর 401 আর 403-এর তফাত বুঝতে।
• যে limit-গুলো design ঠিক করে দেয় সেগুলো কাজে লাগাতে (২৯ সেকেন্ডের integration timeout, ১০ MB payload, account-এ সেকেন্ডে ১০,০০০ request, cache TTL ৩০০ থেকে ৩,৬০০ সেকেন্ড পর্যন্ত), আর API Gateway, ALB আর Lambda function URL-এর মধ্যে বেছে নিতে।

#একটা API-র কেন সামনের দরজা লাগে

Mobile app, website বা partner-এর server কখনো সরাসরি তোমার database-এর সাথে কথা বলে না। সে call করে একটা API-কে: কিছু HTTPS ঠিকানা, যেমন GET /products/42 বা POST /orders। এই call-গুলো কাউকে না কাউকে নিতে হবে, কে call করছে যাচাই করতে হবে, বন্যার মতো request এলে থামাতে হবে, প্রতিটা call ঠিক code-এর কাছে পাঠাতে হবে, তারপর উত্তর ফেরত দিতে হবে। Server-ভিত্তিক design-এ এই কাজ করে তোমার web server আর নিজের লেখা একগাদা middleware, যেগুলো patch-ও তোমাকেই করতে হয়।

Amazon API Gateway একটা fully managed service, যে ঠিক এই কাজটা করে। Note-এ একে বলা হয়েছে client (mobile app, website) আর তোমার backend (Lambda, EC2, DynamoDB)-এর মাঝখানের সামনের দরজা বা front door। এটা তোমাকে API বানাতে, publish করতে, রক্ষণাবেক্ষণ করতে, নজরে রাখতে আর সুরক্ষিত করতে সাহায্য করে। টাকা দাও call ধরে; কোনো server নেই, আর কেউ call না করলে কোনো খরচও নেই।

#একটা serverless API, শুরু থেকে শেষ

চেনা serverless API-তে চারটা বাক্স: client HTTPS request পাঠায় API Gateway-কে, সে সেটা (proxy হিসেবে) পাঠায় একটা Lambda function-এর কাছে, আর function একটা DynamoDB table-এ CRUD করে। চারটার কোনোটাতেই তোমার চালানো server লাগে না, চারটাই traffic-এর সাথে বাড়ে-কমে, আর ভোর ৪টায় bill প্রায় শূন্যে নেমে যায়। Note-এর প্রথম exam trick: প্রশ্নে যদি থাকে “serverless architecture” বা “expose AWS Lambda as a RESTful API”, তাহলে উত্তর API Gateway।

Lambda নিজে lesson ১৫.১ আর ১৫.২-এ; DynamoDB lesson ১৫.৪-এ। এখানে আমরা request-টার পিছু নেব সামনের দরজা দিয়ে: আগে সব ঠিক থাকলে কী হয়, তারপর যে পাঁচটা চেনা উপায়ে সেটা ভেস্তে যায়।

#API Gateway তোমার জন্য কী কী করে

“Gateway” এই একটা শব্দের পেছনে অনেকগুলো feature। পরীক্ষায় আর আসল project-এ যেগুলো কাজে লাগে:

#Stage আর deployment

REST API-তে কোনো method বদলালে client-রা কিছুই টের পায় না, যতক্ষণ না তুমি সেটা একটা stage-এ deploy করো। Deployment হলো API-র একটা snapshot; stage একটা deployment-এর দিকে দেখায় আর নিজের setting যোগ করে: throttling, caching, logging, WAF, আর stage variable (key–value জোড়া, যেমন lambdaAlias=prod, যাতে prod stage function-এর prod alias call করে আর dev call করে dev)। Stage-এর canary setting দিয়ে সবাইকে দেওয়ার আগে নতুন deployment-এ traffic-এর ছোট একটা অংশ পাঠানো যায়। HTTP API প্রতিটা পরিবর্তন নিজে থেকেই একটা stage-এ auto-deploy করতে পারে, dev-এর জন্য খুব কাজের।

Note অনুযায়ী: stage দিয়ে একই API-র কয়েকটা version বা environment (dev, test, prod) পাশাপাশি চালানো যায়। Lambda alias (lesson ১৫.১)-এর সাথে মিলিয়ে এভাবেই নতুন version ছাড়া হয়, মানুষের ফোনে আগে থেকে থাকা app না ভেঙে।

#REST, HTTP নাকি WebSocket API

API Gateway তিন রকম API দেয়। পরীক্ষা বেশিরভাগ সময় শুধু “API Gateway” বলে, আর বোঝায় REST API; আসল project-এ ভেবেচিন্তে বেছে নেওয়া উচিত।

AWS documentation-এর সোজা নিয়ম: API key, client ধরে throttling, request validation, WAF, caching বা private endpoint লাগলে REST নাও; না লাগলে HTTP নাও, কারণ সেটা সস্তা আর দ্রুত।

#এক অনুচ্ছেদে WebSocket API

WebSocket API client আর API Gateway-এর মধ্যে একটা connection খোলা রাখে। Client JSON message পাঠায়; $request.body.action-এর মতো একটা route selection expression প্রতিটা message-কে একটা route-এ পাঠায় (sendMessage, updateLocation), আর আছে তিনটা বিশেষ route: $connect (authorize করা আর connection ID রেখে দেওয়া, যেমন DynamoDB-তে), $disconnect (গুছিয়ে ফেলা) আর $default। কোনো client-কে message push করতে backend সেই client-এর connection ID দিয়ে @connections callback URL call করে। একটা connection সর্বোচ্চ ২ ঘণ্টা টেকে, আর ১০ মিনিট চুপচাপ থাকলে বন্ধ হয়ে যায়; একটা message ১২৮ KB পর্যন্ত হতে পারে (৩২ KB-র frame-এ)। Chat app, live dashboard, multiplayer game, আর ride-sharing map-এ rider-এর icon নড়াচড়া, সবই এখানে মানায়।

#Integration: দরজার পেছনে কী থাকে

Integration একটা route বা method-কে একটা backend-এর সাথে জোড়ে। Slide-এ বড় দাগে তিন রকম, আর REST API-তে চতুর্থ একটা।

1. Lambda function। Lambda-চালিত REST API খুলে দেওয়ার সহজ উপায়।
   • Lambda proxy (AWS_PROXY): পুরো request (path, query string, header, body, caller-এর পরিচয়) হয়ে যায় event; function ফেরত দেয় statusCode, headers আর একটা string body। প্রায় সবাই এটাই ব্যবহার করে।
   • Lambda custom (non-proxy, AWS): mapping template (VTL-এ লেখা) request-কে event-এর আকারে আর function-এর ফলকে HTTP response-এর আকারে বদলায়। পুরোনো, খাটুনিও বেশি, তবে function-কে HTTP নিয়ে কিছু জানতে হয় না।
2. HTTP। যেকোনো HTTP endpoint-এ পাঠানো: EC2 বা container-এর সামনের একটা ALB, অফিসের ভেতরের একটা পুরোনো API, partner-এর URL। যা আগে থেকেই চলছে তার সামনে API Gateway বসাব কেন? যাতে সেটা না ছুঁয়েই rate limiting, caching, authentication আর API key যোগ করা যায়। VPC-র ভেতরের backend-এ (private ALB বা NLB) পৌঁছাতে লাগে একটা VPC link।
3. AWS service। মাঝে কোনো Lambda ছাড়াই সরাসরি যেকোনো AWS API call করা: SQS-এ SendMessage, Step Functions workflow চালু করা, Kinesis Data Streams-এ PutRecord, DynamoDB-তে PutItem। API Gateway call-টা sign করে তোমার দেওয়া একটা IAM role দিয়ে। কেন? Code ছাড়াই service-এর সামনে authentication, একটা public HTTPS ঠিকানা আর rate নিয়ন্ত্রণ পাওয়ার জন্য। HTTP API একই জিনিস দেয় তৈরি করা “first-class” integration হিসেবে: SQS, EventBridge, Kinesis Data Streams, Step Functions আর আরও কয়েকটা।
4. Mock (শুধু REST): API Gateway নিজেই একটা নির্দিষ্ট response দিয়ে উত্তর দেয়। Backend তৈরি না হওয়া পর্যন্ত, বা CORS preflight-এর জন্য কাজে লাগে।

Slide-এর AWS service উদাহরণটা একটা clickstream pipeline: client → API Gateway → Kinesis Data Streams → Data Firehose → S3 (.json file)। যেকোনো হারে event নেয়, অথচ তোমার একটা function-ও চলে না (lesson ১৩.৫ আর ১৩.৬)।

#Endpoint type আর custom domain

একটা API সবসময় একটা Region-এই থাকে। Client কীভাবে সেখানে পৌঁছাবে, সেটা ঠিক করে endpoint type।

দুটো কথা slide-এ নেই। প্রথমত, edge-optimized তোমার response edge-এ cache করে না; শুধু network-এর পথটা ছোট করে (API caching আলাদা একটা stage setting)। দ্বিতীয়ত, edge-optimized যে CloudFront distribution ব্যবহার করে সেটা AWS চালায়, তুমি সেটা configure করতে পারো না; CloudFront-এ WAF, geo restriction বা নিজের cache rule চাইলে নিজের distribution-এর পেছনে একটা Regional endpoint রাখো। Interface endpoint নিজে lesson ২২.২-এ।

#Custom domain name আর ACM certificate

Partner-এর চুক্তিপত্রে কেউ abc123.execute-api.ap-southeast-1.amazonaws.com ছাপতে চায় না। api.shop.example-এর মতো একটা custom domain name এক বা একাধিক API আর stage-এর দিকে দেখায় (API mapping দিয়ে, যেমন /v1 → API A-র stage prod)। এর HTTPS-এর জন্য লাগে AWS Certificate Manager-এর একটা certificate (lesson ২১.৪), আর সেই certificate কোন Region-এ থাকবে, এটা পরীক্ষার খুব প্রিয় খুঁটিনাটি:

• Edge-optimized custom domain → certificate থাকতেই হবে us-east-1-এ (N. Virginia), কারণ পেছনের CloudFront distribution global, আর CloudFront certificate পড়ে ওখান থেকে।
• Regional custom domain → certificate থাকতে হবে API-র নিজের Region-এ।
• তারপর একটা Route 53 alias (A বা AAAA) record, বা একটা CNAME বানাও, যেটা নামটাকে domain-এর target-এর দিকে দেখায় (edge-optimized হলে একটা CloudFront নাম, Regional হলে একটা Regional d-…execute-api নাম)। Alias আর CNAME-এর তফাত lesson ৮.২-এ।

২০২৪-এর শেষ থেকে private REST API-তেও custom domain name দেওয়া যায়, access association দিয়ে VPC endpoint-এর সাথে ভাগ করে। ২০২৫-এ API Gateway আরও দুটো জিনিস যোগ করেছে: dual-stack (IPv4 আর IPv6) endpoint (মার্চে, REST, HTTP আর WebSocket API আর custom domain সবগুলোর জন্য), আর custom domain-এ routing rule (জুনে, শুধু REST API-র জন্য: header বা path দেখে কোন API-তে যাবে ঠিক করা, যেমন ধীরে ধীরে v1 থেকে v2-তে সরানোর জন্য)। এগুলো পাশের কথা; পরীক্ষা জিজ্ঞেস করে certificate-এর Region।

#Security: API কে call করতে পারবে

Slide-এ user authenticate করার তিনটা উপায় আছে; পুরো তালিকাটা একটু লম্বা।

Status code ঠিকমতো পড়তে শেখো। 401 Unauthorized মানে “তুমি কে?”: token নেই, বা ভুল, বা মেয়াদ শেষ। 403 Forbidden মানে “তুমি কে জানি, কিন্তু না”: Lambda authorizer Deny দিয়েছে, IAM execute-api:Invoke দেয়নি, resource policy বা WAF উৎসটা আটকেছে। দুটোই ফেরত আসে তোমার backend চলার আগেই, তাই Lambda-র কোনো সময় খরচ হয় না।

#Throttling, usage plan আর caching

#Throttling: চার স্তর

Throttling তোমার backend আর bill-কে request-এর বন্যা থেকে বাঁচায়। API Gateway ব্যবহার করে একটা token bucket: একটা স্থির rate (সেকেন্ডে কতটা request) আর একটা burst (bucket-এর আকার, একসাথে কতটা আসতে পারে)। সীমা পেরোলে caller পায় 429 Too Many Requests, আর তার উচিত exponential backoff দিয়ে আবার চেষ্টা করা। সীমাগুলো এই ক্রমে বসে, আর যেটা সবচেয়ে কড়া সেটাই জেতে:

1. Client ধরে (শুধু REST): সেই client-এর API key-র usage plan-এর সীমা, চাইলে method ধরেও।
2. Method ধরে: stage-এর method-স্তরের সীমা, যেমন POST /orders সেকেন্ডে ২০০।
3. Stage ধরে: stage-এর সব method-এর default।
4. Account আর Region ধরে: default-এ সেকেন্ডে ১০,০০০ request, সাথে ৫,০০০-এর burst bucket, account-এর ওই Region-এর সব REST, HTTP আর WebSocket API মিলিয়ে ভাগাভাগি (কিছু নতুন Region-এ শুরু ২,৫০০ থেকে)। Service Quotas-এ বাড়ানোর আবেদন করা যায়।

Note-এ default বলা আছে সেকেন্ডে ১০,০০০; production-এ যে শব্দটা কামড় দেয় সেটা হলো ভাগাভাগি: একটা API-র হঠাৎ চাপে account-এর বাকি সব API-ও throttle হতে পারে। Stage আর method-এর সীমা বসাও, যাতে কোনো একটা API একাই পুরো account-এর সীমা খেয়ে ফেলতে না পারে।

#Usage plan আর API key

Usage plan (শুধু REST) বলে দেয় একটা client কতটা ব্যবহার করতে পারবে: একটা throttle (rate আর burst) আর একটা quota (দিনে, সপ্তাহে বা মাসে কতটা request)। Client পায় একটা API key, key জোড়া হয় একটা plan-এর সাথে, আর plan জোড়া হয় API-র stage-এর সাথে। যে method-এ key লাগবে সেখানে API key required চালু থাকে। Rate পেরোলে client পায় 429; quota পেরোলে period নতুন না হওয়া পর্যন্ত “Limit Exceeded” সহ 429। Note-এর exam trick: “usage plans”, “API keys” বা “throttling third-party developers” মানে API Gateway (আরও নির্দিষ্ট করে REST API)।

#Response cache করা

Note-এর দ্বিতীয় exam trick: “API-র performance বাড়াও আর backend-এর চাপ কমাও” → API caching চালু করো। একটা REST API-র stage-এ cache রাখা যায়:

• TTL default-এ ৩০০ সেকেন্ড (৫ মিনিট), ০ (caching বন্ধ) থেকে ৩,৬০০ সেকেন্ড পর্যন্ত বদলানো যায়।
• Cache key হলো method আর path, সাথে তুমি যে parameter বাছো (query string, header)। সাবধানে বাছো: কোনো parameter বাদ পড়লে একজনের উত্তর আরেকজনকে দেখানো হয়ে যাবে।
• Cache-এর bill হয় size ধরে ঘণ্টা হিসেবে, ০.৫ GB থেকে ২৩৭ GB, ব্যবহার হোক বা না হোক; একটা cache করা response ১ MB পর্যন্ত হতে পারে।
• পুরো stage cache flush করা যায়, আর method ধরে caching বদলানো যায়। কোনো client Cache-Control: max-age=0 পাঠিয়ে একটা request-এর জন্য cache এড়াতে পারে, যদি তার IAM permission execute-api:InvalidateCache থাকে; এই permission বাধ্যতামূলক রাখো, নইলে যে কেউ তোমার cache এড়িয়ে যাবে।
• HTTP আর WebSocket API-তে নিজস্ব cache নেই; লাগলে সামনে CloudFront বসাও।

Caching গতির বদলে টাটকা ভাব কিছুটা ছাড়ে। Flash sale-এর সময় দামের ওপর পাঁচ মিনিটের TTL পুরোনো দাম দেখাতে পারে; data কতটা পুরোনো চলবে সেটা দেখে TTL ঠিক করো, দরকার হলে flush করো।

#যে limit-গুলো design ঠিক করে দেয়

২৯ সেকেন্ডের timeout-টাই পরীক্ষার প্রশ্নে সবচেয়ে বেশি আসে। এর পেছনের ফাঁদ: API Gateway হাল ছেড়ে 504 ফেরত দিলেও Lambda function নিজের timeout (১৫ মিনিট পর্যন্ত) পর্যন্ত চলতেই থাকে আর bill হয়, অথচ তার উত্তর কোথাও পৌঁছায় না। Lambda-র timeout API-র timeout-এর চেয়ে ছোট রাখো।

#যাচাইগুলোর ভেতর দিয়ে একটা request-এর পিছু নাও

এবার সব একসাথে মেলাও। API type, token, client-এর traffic, cache, backend কত সময় নেয় আর body-র size বেছে নাও, তারপর button চাপো আর দেখো কোন যাচাইয়ে request থামে, কোন status code নিয়ে, কত সময় পরে, আর Lambda চলার জন্য টাকা গেল কি না।

#API Gateway বনাম Application Load Balancer

দুটোই client-এর HTTP traffic নেয় আর backend-এ পাঠায়। Note-এর তুলনা, inventory যে সংশোধনগুলো পেয়েছে সেগুলোসহ:

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

#System design-এ API Gateway

• Serverless-এর default সামনের দরজা: client → API Gateway → Lambda → DynamoDB, user-এর জন্য Cognito (lesson ১৫.৮-এর to-do app আর blog-এর design)।
• Default-এ HTTP API, আর key, plan, caching, validation, WAF বা private endpoint লাগলে REST API। অনেক company দুটোই চালায়: নিজের app-এর জন্য সস্তা HTTP API, আর partner-দের জন্য একটা REST API।
• Synchronous call ছোট রাখো: কয়েক সেকেন্ডের মধ্যে। এর চেয়ে লম্বা যেকোনো কাজ যায় queue বা workflow দিয়ে, আর client poll করে বা WebSocket-এ কান পেতে থাকে।
• সরাসরি service integration (SQS, Kinesis, Step Functions, DynamoDB) মাঝের “আঠা” Lambda function বাদ দেয়, তাতে টাকা, latency আর concurrency তিনটাই বাঁচে।
• স্তরে স্তরে সুরক্ষা: edge-এ WAF, পরিচয়ের জন্য authorizer, client ধরে usage plan, stage আর method-এর throttle, পেছনের function-এ reserved concurrency (lesson ১৫.২), যাতে একটা বন্যা সব শুষে নিতে না পারে।
• যা অনেকে চায় শুধু সেটাই cache করো; key আর TTL method ধরে বাছো।
• Environment ধরে stage, stage ধরে Lambda alias, ঝুঁকির পরিবর্তনে canary release; সবকিছু OpenAPI বা infrastructure as code-এ লিখে রাখো।
• নজর রাখো: 5XXError, Latency আর IntegrationLatency-এর ওপর alarm; access log; ধীর পথ খুঁজতে X-Ray।

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

একটা function-এর সামনে একটা HTTP API, তারপর usage plan আর cache-ওয়ালা একটা REST API, ap-southeast-1-এ, account 111122223333। Output ছোট করে দেখানো।

# 1. Quick-create an HTTP API with a Lambda proxy integration (one route, $default stage, auto-deploy)
aws apigatewayv2 create-api --name shop-http-example --protocol-type HTTP \
  --target arn:aws:lambda:ap-southeast-1:111122223333:function:products-example
#   { "ApiId": "a1b2c3d4e5", "ApiEndpoint": "https://a1b2c3d4e5.execute-api.ap-southeast-1.amazonaws.com", ... }

# Quick create adds the invoke permission; with a manual setup you must add it yourself:
aws lambda add-permission --function-name products-example \
  --statement-id apigw-invoke --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:ap-southeast-1:111122223333:a1b2c3d4e5/*"

curl -s https://a1b2c3d4e5.execute-api.ap-southeast-1.amazonaws.com/products/42
#   {"id":"42","name":"Panjabi","price":2450}

# 2. A REST API (Regional) for partners: create a usage plan with throttle and quota
aws apigateway create-usage-plan --name free-example \
  --throttle burstLimit=20,rateLimit=10 --quota limit=10000,period=MONTH \
  --api-stages apiId=x9y8z7w6v5,stage=prod
#   { "id": "pl4n1d", "name": "free-example", "throttle": {"burstLimit": 20, "rateLimit": 10.0}, ... }

aws apigateway create-api-key --name shop-a-example --enabled
#   { "id": "k3y1d", "value": "Ab12Cd34Ef56Gh78Ij90Kl12Mn34Op56Qr78St90", ... }
aws apigateway create-usage-plan-key --usage-plan-id pl4n1d --key-id k3y1d --key-type API_KEY

# 40 calls in one second from the free key: some come back 429
for i in $(seq 40); do curl -s -o /dev/null -w "%{http_code} " \
  -H "x-api-key: Ab12Cd34Ef56Gh78Ij90Kl12Mn34Op56Qr78St90" \
  https://x9y8z7w6v5.execute-api.ap-southeast-1.amazonaws.com/prod/track/7781 & done; wait
#   200 200 200 ... 429 429 200 429 ...

# 3. Turn on a 0.5 GB cache on the prod stage, TTL 600 s for all methods
aws apigateway update-stage --rest-api-id x9y8z7w6v5 --stage-name prod --patch-operations \
  op=replace,path=/cacheClusterEnabled,value=true \
  op=replace,path=/cacheClusterSize,value=0.5 \
  op=replace,path=/*/*/caching/enabled,value=true \
  op=replace,path=/*/*/caching/ttlInSeconds,value=600

# Data changed? Flush the stage cache
aws apigateway flush-stage-cache --rest-api-id x9y8z7w6v5 --stage-name prod

# 4. Check the account throttle limits for the Region
aws apigateway get-account --query throttleSettings
#   { "burstLimit": 5000, "rateLimit": 10000.0 }

Loop চলার সময় CloudWatch-এ Count, 4XXError, 5XXError, CacheHitCount আর CacheMissCount metric দেখো। কাজ শেষে cache মুছে দিয়ো: যতক্ষণ থাকে, প্রতি ঘণ্টায় bill হয়।

#সারসংক্ষেপ

মূল কথাগুলো

• API Gateway হলো একটা API-র managed সামনের দরজা: routing, stage, security, API key আর usage plan, throttling, validation, transformation, caching, OpenAPI import, SDK বানানো, WebSocket, request ধরে টাকা। চেনা serverless API: client → API Gateway → Lambda → DynamoDB। “Expose Lambda as a RESTful API” → API Gateway।
• তিন রকম API: REST (সব feature: key, usage plan, cache, validation, WAF, private endpoint; প্রতি ১০ লাখে প্রায় $৩.৫০), HTTP (সস্তা, প্রতি ১০ লাখে প্রায় $১.০০, দ্রুত, JWT authorizer, শুধু Regional, ৩০ সে), WebSocket (দুই দিকে, server push, $connect/$disconnect, @connections)।
• Integration: Lambda proxy (function ফেরত দেয় statusCode, headers, body) বা mapping template-সহ custom; HTTP backend (ALB, অফিসের server, VPC link), যাতে rate limiting, caching, auth আর key যোগ হয়; সরাসরি AWS service-এর API (Kinesis Data Streams → Firehose → S3, SQS, Step Functions), একটা IAM role দিয়ে; mock। Lambda-র apigateway.amazonaws.com-এর জন্য resource policy লাগে।
• Endpoint: edge-optimized (REST-এর default, CloudFront edge হয়ে, তবু এক Region-এ, edge-এ caching নেই), Regional (একই Region-এর client, বা নিজের CloudFront), private (interface VPC endpoint + resource policy)। Custom domain-এর certificate edge-optimized হলে us-east-1-এ, Regional হলে API-র Region-এ; Route 53 alias বা CNAME।
• Security: ভেতরের caller-এর জন্য IAM/SigV4, বাইরের user-এর জন্য Cognito user pool (API Gateway নিজেই JWT যাচাই করে), নিজের যুক্তির জন্য Lambda authorizer (IAM policy ফেরত দেয়, default-এ ৩০০ সে cache), উৎস ধরে resource policy আর WAF। 401 = তুমি কে; 403 = অনুমতি নেই। API key authentication না।
• Throttling: token bucket, account-এ Region ধরে ১০,০০০ rps + ৫,০০০ burst, সব API-র ভাগাভাগি; stage, method আর client ধরে usage plan-এর সীমা; সীমা পেরোলে → 429। Throttling DDoS-এর সুরক্ষা না: WAF আর Shield নাও।
• Caching (শুধু REST): TTL default ৩০০ সে, ০–৩,৬০০ সে, ০.৫–২৩৭ GB ঘণ্টা ধরে bill, stage ধরে, flush করা যায়; “performance বাড়াও আর backend-এর চাপ কমাও” → caching চালু করো।
• Limit: ২৯ সে integration timeout (504, function তবু চলতে থাকে; বাড়ানো যায় শুধু Regional/private REST-এ; ২০২৫ থেকে streaming ১৫ মিনিট পর্যন্ত), ১০ MB payload (Lambda-তে ৬ MB), তাই লম্বা কাজ async-এ আর বড় file presigned URL দিয়ে S3-এ। CORS error → CORS চালু করো।
• API Gateway বনাম ALB: request ধরে দাম + API management + cache + IAM/Cognito/Lambda authorizer, বনাম ঘণ্টা + LCU, EC2/container (আর Lambda)-এর জন্য load balancing, HTTPS listener-এ Cognito/OIDC। “EC2/container-এ monolith” → ALB; “usage plans, API keys, throttle third-party developers” → API Gateway; একটা function, একটা URL → function URL।

নিজেকে যাচাই করো: Amazon API Gateway৩২টি প্রশ্ন