AWS Lambda-র গোড়ার কথা আর খরচ

এই lesson শেষে তুমি পারবে

• “Serverless” আসলে কী বোঝায় তা বলতে (manage করার মতো কোনো server নেই, যতটুকু ব্যবহার ততটুকু টাকা, কাজ না থাকলে শূন্যে নেমে যায়), আর AWS-এর প্রধান serverless service-গুলোর নাম ও কাজ বলতে।
• সবসময় চালু একটা EC2 instance আর একটা Lambda function-এর তুলনা করতে: কোনটা কীভাবে চলে, scale করে, bill হয়, আর কখন কোনটা ভালো (১৫ মিনিটের সীমাসহ)।
• একটা function কীভাবে চলে বুঝিয়ে বলতে (handler, event, execution environment, cold আর warm start), এখনকার তালিকা থেকে runtime বাছতে, আর কখন function-কে container image হিসেবে পাঠাতে হয় জানতে।
• তিন রকম invocation আলাদা করে চিনতে (synchronous, asynchronous, event source mapping), আর আগেই বলে দিতে ব্যর্থ হলে কে আবার চেষ্টা করবে আর ব্যর্থ event শেষে কোথায় যাবে (destination, dead-letter queue, queue-র নিজের DLQ)।
• Function-কে ঠিক permission দিতে: সে কী ডাকবে তার জন্য execution role, কে তাকে ডাকবে তার জন্য resource-based policy; function URL দিয়ে খুলে দিতে; version আর alias দিয়ে নিরাপদে release করতে।
• দুটো চেনা উদাহরণ বানাতে (S3-এ upload হলেই thumbnail, EventBridge দিয়ে serverless cron), আর request ও GB-second থেকে মাসিক Lambda bill হিসাব করে EC2-র সাথে মেলাতে।

#Serverless মানে আসলে কী

গত চারটা chapter জুড়ে তুমি সবকিছু চালিয়েছ server-এর ওপর: EC2 instance, যার size, patch আর scaling তোমার দায়িত্ব (chapter 4); নিজের বাছা instance-এ database (chapter 7); EC2 বা Fargate-এ container (chapter 14)। এদের প্রত্যেকটার bill চলে যতক্ষণ চালু থাকে ততক্ষণ, কাজ করুক বা বসে থাকুক।

Serverless একটা আলাদা চুক্তি। তুমি AWS-কে code (বা data) দিয়ে দাও, দরকার হলে AWS সেটা চালায়। তিনটা জিনিস থাকলে একটা service-কে serverless বলা হয়:

1. Manage করার মতো কোনো server নেই। Server অবশ্যই আছে, কিন্তু তুমি সেগুলো দেখো না, size ঠিক করো না, patch করো না, বদলাও না। Serverless মানে “server নেই” না; মানে “server তোমার না”।
2. যতটুকু ব্যবহার, ততটুকু টাকা। Request প্রতি, চলার প্রতি millisecond, রাখা প্রতি GB, প্রতিটা message ধরে টাকা। অলস বসে থাকা capacity-র কোনো bill নেই।
3. নিজে থেকেই scale হয়, শূন্য পর্যন্ত। দিনে দশটা request হোক বা সেকেন্ডে দশ হাজার, service নিজেই বাড়ে-কমে; কোনো traffic না থাকলে কিছুই চলে না, কোনো bill-ও নেই।

ধারণাটা শুরু হয়েছিল FaaS (Function as a Service) দিয়ে: তুমি একটা function upload করো, প্রতিটা event-এ platform সেটা চালায়। পথ দেখিয়েছিল AWS Lambda (২০১৪)। এখন এই তিন গুণ থাকা যেকোনো পুরোপুরি managed service-কেই “serverless” বলা হয়: database, queue, storage, API, workflow।

#AWS-এ serverless-এর তালিকা

পরীক্ষায় এই service-গুলোকে “serverless” ধরা হয়। প্রতিটা নিজের lesson-এ পড়ানো হয়েছে বা হবে; এই table-টা তোমার মানচিত্র।

একটা সাধারণ serverless web app এগুলো জুড়েই বানানো হয়: static file S3-এ (CloudFront দিয়ে পরিবেশন), user-রা Cognito দিয়ে sign in করে, API Gateway-এর একটা REST API Lambda function ডাকে, আর data থাকে DynamoDB-তে। Lesson 15.8 ঠিক এটাই বানাবে।

#কেন Lambda: সবসময় চালু server বনাম প্রতি request-এ function

প্রতিটা execution environment একবারে একটাই request সামলায়। একসাথে দশটা request এলে দশটা environment লাগে; এই সংখ্যাটাই function-এর concurrency। একটা account শুরুতে পায় প্রতি Region-এ ১,০০০টা concurrent execution, তার সব function মিলে। Scaling, throttling আর cold start নিয়ে পুরো একটা lesson আছে: lesson 15.2।

#Lambda-র সুবিধা

• সহজ দাম: request আর compute-এর GB-second ধরে টাকা, সাথে প্রতি মাসে ১০ লাখ request আর ৪,০০,০০০ GB-second-এর free tier (বিস্তারিত নিচে)।
• পুরো AWS-এর সাথে জোড়া: কয়েক ডজন service সরাসরি function ডাকতে পারে (পরের অংশগুলো)।
• অনেক ভাষা: Node.js, Python, Java, .NET, Ruby, আর বাকি যেকোনো ভাষা OS-only runtime বা container image দিয়ে।
• Monitoring আগে থেকেই আছে: প্রতিটা function কোনো agent ছাড়াই log পাঠায় CloudWatch Logs-এ আর metric (invocation, error, duration, throttle, concurrency) পাঠায় CloudWatch-এ; AWS X-Ray দিয়ে tracing-ও হয়।
• বেশি resource মানে একটা setting বদলানো: memory ১২৮ MB থেকে ১০,২৪০ MB। Memory-র সাথে CPU-ও বাড়ে: ১,৭৬৯ MB-তে function পায় প্রায় একটা vCPU-র সমান, আর ১০,২৪০ MB-তে ছয়টা vCPU পর্যন্ত। CPU-নির্ভর function বেশি memory পেলে এত দ্রুত শেষ হয় যে খরচ প্রায়ই একই থাকে বা কমে।

Slide আরও বলে, বেশি RAM দিলে network bandwidth-ও বাড়ে। এখন প্রতিটা execution environment পায় ৬২৫ Mbps; VPC-র বাইরের function-এর জন্য বাড়ানোর আবেদন করা যায়, তারপর ২,০৪৮ MB থেকে memory-র সাথে bandwidth বাড়ে, ১০,২৪০ MB-তে প্রায় ৩,০০০ Mbps পর্যন্ত।

#একটা function কীভাবে চলে

Function মানে তোমার code আর তার configuration (runtime, memory, timeout, environment variable, execution role)। ঢোকার দরজা হলো handler, একটা function যাকে Lambda দুটো argument দিয়ে ডাকে: event (কী ঘটেছে, JSON-এ) আর context (request ID, আর কত সময় বাকি, memory-র সীমা)।

import json, os, boto3

s3 = boto3.client("s3")              # init code: প্রতি environment-এ একবার চলে
TABLE = os.environ["TABLE_NAME"]     # environment variable থেকে configuration

def handler(event, context):         # প্রতিটা invocation-এ একবার চলে
    record = event["Records"][0]["s3"]
    key = record["object"]["key"]
    print(f"resizing {key}, {context.get_remaining_time_in_millis()} ms left")
    return {"status": "ok", "key": key}

Request এল অথচ কোনো environment খালি নেই, তখন Lambda একটা বানায়: microVM চালু করে, তোমার code নামায়, runtime চালু করে আর তোমার init code চালায় (handler-এর বাইরের সবকিছু)। এটাই cold start, runtime আর package-এর আকার অনুযায়ী সাধারণত ১০০ ms থেকে এক সেকেন্ড বা তার বেশি। তারপর handler ডাকে। Handler ফেরত দিলে environment কিছুক্ষণ warm থাকে, পরের request সোজা handler-এ চলে যায়। এজন্যই SDK client আর database connection handler-এর বাইরে বানাতে হয়: warm invocation-গুলোতে সেগুলো আবার কাজে লাগে। Cold start, provisioned concurrency আর SnapStart lesson 15.2-এ।

Memory-তে বা /tmp-এ (default ৫১২ MB, ১০,২৪০ MB পর্যন্ত) যা রাখো, একই environment-এর পরের invocation-এ তা থেকেও যেতে পারে, কিন্তু কোনো নিশ্চয়তা নেই: প্রতিটা invocation-কে stateless ধরো, আর state রাখো DynamoDB, S3 বা কোনো cache-এ।

#Runtime

Slide-এ ভাষার তালিকা Node.js, Python, Java, C# / PowerShell, Ruby আর custom runtime। মোটা দাগে এখনো তাই, কিন্তু version প্রতি বছর বদলায়। ২০২৬-এর অক্টোবরে চালু managed runtime:

Slide-এর দুটো সংশোধন: managed Go 1.x runtime ২০২৪-এর জানুয়ারিতে অবসরে গেছে, তাই Go এখন চলে OS-only runtime-এ; আর পুরোনো Amazon Linux 2-ভিত্তিক runtime-গুলো (provided.al2, Python 3.10/3.11, Amazon Linux 2-এর Java) শেষ হয়ে গেছে বা শেষের পথে, কারণ Amazon Linux 2 নিজেই ২০২৬-এর জুনে end of life-এ পৌঁছেছে। কোনো runtime deprecated হলে AWS আর patch দেয় না; কিছুদিন পর সেই runtime দিয়ে নতুন function বানানো, তারপর পুরোনোটা update করাও বন্ধ হয়ে যায়। চালু সব runtime x86_64 আর arm64 (Graviton) দুটোতেই চলে।

#Container image

.zip file-এর বদলে (সরাসরি upload-এ zip করা অবস্থায় ৫০ MB, layer সহ খোলা অবস্থায় ২৫০ MB) function-কে ১০ GB পর্যন্ত একটা container image হিসেবেও পাঠানো যায়, যেটা থাকে Amazon ECR-এ (lesson 14.1)। বড় dependency (machine learning library, headless browser) থাকলে, বা team আগে থেকেই সব Docker দিয়ে build করলে এটা কাজের।

Slide-এর শর্তটা এখনো খাটে: image-কে Lambda Runtime API implement করতেই হবে, ছোট্ট একটা HTTP interface, যার মাধ্যমে function পরের event আনে আর ফল জমা দেয়। AWS-এর base image-এ (public.ecr.aws/lambda/python:3.13 ইত্যাদি) এটা দেওয়াই থাকে; নিজের base image হলে open-source runtime interface client যোগ করতে হয়। Runtime interface emulator দিয়ে image-টা নিজের machine-এ পরীক্ষা করা যায়। Function তবু function-ই: ১৫ মিনিট, প্রতি environment-এ একটা request, event এলে চলে।

FROM public.ecr.aws/lambda/python:3.13
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py ${LAMBDA_TASK_ROOT}
CMD ["app.handler"]

তাই পরীক্ষায় যখন বলে “একটা আগে থেকে বানানো, যেকোনো Docker image চালাও” (port-এ শুনতে থাকা web server, অনেকক্ষণ চলা worker), উত্তর Fargate-এর ওপর ECS বা EKS, Lambda না।

#Function-কে কে ডাকতে পারে

Slide-এর প্রধান integration-গুলো, আর প্রত্যেকে কীভাবে ডাকে (তিন রকমের ব্যাখ্যা পরের অংশে):

Event source mapping আরও পড়তে পারে Amazon MSK আর নিজের চালানো Kafka, Amazon MQ আর DocumentDB-র change stream। আর যেকোনো program SDK বা CLI দিয়ে Invoke API ডাকতে পারে।

#Function ডাকার তিনটা উপায়

প্রতিটা invocation এই তিন রকমের কোনো একটা, আর রকমটাই ঠিক করে কে অপেক্ষা করবে, কে আবার চেষ্টা করবে, আর ব্যর্থ হলে কী যাবে কোথায়। পরীক্ষা এটা খুব পছন্দ করে।

Synchronous (RequestResponse)। Caller ফলের জন্য অপেক্ষা করে। প্রতি দিকে payload ৬ MB পর্যন্ত (response streaming-এ ২০০ MB পর্যন্ত)। Error সোজা caller-এর কাছে ফেরে আর Lambda নিজে আবার চেষ্টা করে না: সিদ্ধান্ত caller-এর (SDK, client app)। Throttle হলে সাথে সাথে 429 TooManyRequestsException।

Asynchronous (Event)। Caller event-টা Lambda-র হাতে দিয়ে সাথে সাথে 202 পায়; Lambda event-টা নিজের ভেতরের একটা queue-তে রাখে আর পরে function চালায়। Event সর্বোচ্চ ১ MB (২০২৫-এ ২৫৬ KB থেকে বাড়ানো হয়েছে)। Function error দিলে default-এ Lambda আরও দুবার চেষ্টা করে (প্রায় ১ মিনিট পরে, তারপর আরও প্রায় ২ মিনিট পরে), ০ বা ১ করা যায়; throttle হওয়া event রেখে দিয়ে maximum event age পর্যন্ত বারবার চেষ্টা হয় (৬০ সেকেন্ড থেকে ৬ ঘণ্টা, default ৬ ঘণ্টা)। তারপর?

• Destination: invocation-এর একটা record পাঠানো যায় সফল হলে বা ব্যর্থ হলে কোনো target-এ। Target: SQS, SNS, EventBridge, আরেকটা Lambda function, আর (শুধু ব্যর্থতার জন্য, ২০২৪-এর নভেম্বর থেকে) একটা S3 bucket। Record-এ থাকে request, response বা error, আর কারণ। এখন এটাই পছন্দের পথ।
• Dead-letter queue (DLQ): পুরোনো পদ্ধতি; function-এ বসানো একটা SQS queue বা SNS topic, যেটা পায় শুধু ব্যর্থ event-টা, error-এর কোনো বিবরণ ছাড়া।
• কোনোটাই না থাকলে: event ফেলে দেওয়া হয়। আর ভেতরের queue eventually consistent বলে একই event একাধিকবারও আসতে পারে, তাই code-কে idempotent রাখো।

Event source mapping (polling)। SQS, Kinesis, DynamoDB Streams আর Kafka-র বেলায় কেউ Lambda-কে event ঠেলে পাঠায় না; Lambda service নিজের poller চালায়, সেগুলো source পড়ে আর একটা batch দিয়ে function-কে synchronous ভাবে ডাকে। ব্যর্থ হলে কী হবে, তা source-এর ওপর নির্ভর করে:

• SQS: ব্যর্থ message queue-তেই থেকে যায়, visibility timeout পেরোলে আবার দেখা দেয় আর আবার চেষ্টা হয়; maxReceiveCount পেরোলে সেগুলো নেয় queue-র নিজের redrive DLQ। Partial batch response (ReportBatchItemFailures) ফেরত দাও, যাতে একটা খারাপ message-এর জন্য পুরো batch আবার না চলে। Visibility timeout রাখো function timeout-এর অন্তত ছয় গুণ।
• Kinesis আর DynamoDB Streams: record প্রসেস হয় প্রতি shard-এ ক্রম মেনে, তাই বারবার ব্যর্থ হওয়া batch তার shard আটকে রাখে, যতক্ষণ না সফল হয় বা record মেয়াদ পেরোয়। Maximum retry attempts, maximum record age আর bisect batch on error দিয়ে সেটা সীমিত করো, আর বাদ পড়া record পাঠাও একটা on-failure destination-এ (SQS, SNS বা S3)।

#Permission: দুটো policy, দুই দিক

Lambda-র security-র দুটো দিক আছে, আর দুটো গুলিয়ে ফেলা পরীক্ষার পুরোনো ফাঁদ।

• Execution role (বাইরের দিকে: function কী ডাকতে পারবে)। একটা IAM role, যেটা lambda.amazonaws.com-কে বিশ্বাস করে। প্রতিটা invocation-এ Lambda role-টা নেয় আর অস্থায়ী credential তোমার code-কে দেয়; SDK নিজেই সেগুলো খুঁজে নেয়। Log লেখার জন্য managed policy AWSLambdaBasicExecutionRole লাগে; S3, DynamoDB বা অন্য কিছুর জন্য নিজের statement যোগ করো। Event source mapping-ও queue বা stream পড়তে এই role-টাই ব্যবহার করে।
• Resource-based policy (ভেতরের দিকে: কে function ডাকতে পারবে)। Function-এর গায়েই লাগানো একটা policy। যে AWS service event ঠেলে পাঠায় (S3, SNS, EventBridge, API Gateway, CloudWatch Logs) আর অন্য account-এর এখানে lambda:InvokeFunction-এর অনুমতি লাগে। Trigger যোগ করলে console নিজেই এটা বসায়; CLI-তে command aws lambda add-permission। Service principal-কে source ARN আর source account দিয়ে সীমিত করো।

Execution role-এর trust policy সবসময় একই রকম:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Account পেরোলে দুই দিকেরই allow লাগে, lesson 2.2-এর মতো: caller-এর identity policy আর function-এর resource-based policy। একই account-এর ভেতরে IAM user বা role-এর জন্য যেকোনো একটাই যথেষ্ট।

#Function URL

Function URL হলো একটা function-এর নিজস্ব HTTPS endpoint, https://<url-id>.lambda-url.<region>.on.aws, যেটা synchronous ভাবে ডাকে। এর জন্য আলাদা টাকা লাগে না (শুধু invocation-এর দাম), CORS setting আর response streaming আছে, আর webhook (payment gateway যখন তোমাকে ফিরতি খবর দেয়), এক-function-এর microservice বা ঝটপট একটা internal tool-এর জন্য মানানসই।

• AuthType AWS_IAM: caller-কে SigV4 দিয়ে request sign করতে হয়, আর তার lambda:InvokeFunctionUrl-এর অনুমতি লাগে, সাথে ২০২৫-এর অক্টোবর থেকে বানানো URL-এ lambda:InvokeFunction-ও।
• AuthType NONE: সবার জন্য খোলা; তবু resource-based policy-তে সবার জন্য invoke-এর অনুমতি থাকতে হয় (console নিজেই যোগ করে)। কোনো token যাচাই করতে হলে তোমার code-কেই করতে হবে।

Function URL-এর নিজের কোনো API key, usage plan, request validation, caching বা WAF নেই। এগুলো লাগলে API Gateway নাও (lesson 15.6), নয়তো URL-এর সামনে CloudFront বসাও (CloudFront origin access control দিয়ে URL-এ নিজের request sign করতে পারে, তাতে শুধু CloudFront-ই ডাকতে পারে)।

#Version আর alias

Develop করার সময় তুমি বদলাও $LATEST। Publish করলে একটা নম্বরওয়ালা version (১, ২, ৩…) তৈরি হয়: code আর configuration-এর অপরিবর্তনীয় একটা ছবি, নিজের ARN সহ (…:function:checkout:7)। Alias হলো একটা version-এর দিকে তাক করা নামওয়ালা pointer (…:function:checkout:live), যেটা সরানো যায়। Trigger, API Gateway আর event source mapping-কে alias-এর দিকে তাক করে রাখা উচিত, তাতে release বা rollback মানে শুধু alias সরানো।

Alias দুটো version-এর মধ্যে weight দিয়ে traffic ভাগও করতে পারে (৯০% version 7-এ, ১০% version 8-এ): এটাই canary। AWS CodeDeploy এটা স্বয়ংক্রিয় করে (canary, linear বা একবারে সরানো, CloudWatch alarm বাজলে ফিরে যাওয়া), আর AWS SAM কয়েক লাইনেই সেটা সাজিয়ে দেয়। Provisioned concurrency-ও (lesson 15.2) বসে alias বা version-এ, কখনো $LATEST-এ না।

#দুটো চেনা উদাহরণ

Slide-এ Lambda-র পরিচয় শেষ হয় দুটো ছোট architecture দিয়ে। পরীক্ষার প্রশ্নে দুটোই নানা ছদ্মবেশে আসে।

১. Upload হলেই thumbnail। একটা S3 event notification (s3:ObjectCreated:*, শুধু .jpg) function-কে asynchronous ভাবে ডাকে। Function ছবিটা নামায়, thumbnail লেখে আরেকটা bucket-এ, আর metadata (নাম, size, তৈরির তারিখ, thumbnail-এর key) লেখে একটা DynamoDB table-এ। Upload-এর অপেক্ষায় কোনো server বসে থাকে না; shop প্রতি ছবিতে কয়েকশো millisecond-এর টাকা দেয়।

২. Serverless cron job। একটা EventBridge schedule (slide এখনো বলে CloudWatch Events) প্রতি ঘণ্টায়, বা cron expression ধরে, function চালিয়ে একটা কাজ করায়। নতুন schedule-এর জন্য AWS এখন সুপারিশ করে EventBridge Scheduler: একবারের বা বারবারের, time zone আর flexible window সহ, আর এক account-এ লাখ লাখ schedule।

#Lambda-র দাম কীভাবে ধরা হয়

তুমি টাকা দাও দুটো জিনিসের, আর বাড়তি কিছু ব্যবহার করলে তার:

1. Request: প্রতি দশ লাখ invocation-এ ০.২০ USD (প্রতিটা ০.০০০০০০২ USD)।
2. Duration × memory, মাপা হয় GB-second-এ: GB-তে ঠিক করা memory × সেকেন্ডে চলার সময়, millisecond পর্যন্ত ওপরের দিকে গোল করে। US East (N. Virginia)-তে: x86-এ প্রতি GB-second ০.০০০০১৬৬৬৬৭ USD আর Arm (Graviton)-এ ০.০০০০১৩৩৩৩৪ USD, অর্থাৎ ২০% কম। মাসে x86-এ ৬০০ কোটি আর Arm-এ ৭৫০ কোটি GB-second-এর ওপরে আরও সস্তা ধাপ শুরু হয়। ২০২৫-এর আগস্ট থেকে cold start-এর init phase-ও duration হিসেবে bill হয়।

Free tier, প্রতি মাসে, প্রতি account-এ, সব function মিলিয়ে: ১০ লাখ request আর ৪,০০,০০০ GB-second। ৪,০০,০০০ GB-second মানে ১ GB-তে ৪,০০,০০০ সেকেন্ড, ১২৮ MB-তে (০.১২৫ GB) ৩২,০০,০০০ সেকেন্ড, বা ৫১২ MB-তে ৮,০০,০০০ সেকেন্ড।

বাড়তি খরচ: ফ্রি ৫১২ MB-র বেশি ephemeral storage, provisioned concurrency (lesson 15.2), বাইরে যাওয়া data transfer, আর CloudWatch Logs-এ log জমা (বেশি কথা বলা function-এর বেলায় প্রায়ই Lambda-র bill-এর চেয়ে বড়)। Compute Savings Plans (lesson 4.4) Lambda-র duration-ও কভার করে।

#একটা হিসাব করে দেখা

Thumbnail function: মাসে ৩০ লাখ invocation, ৫১২ MB, গড়ে ৮০০ ms, x86, free tier পাওয়া যাচ্ছে।

1. Compute: ৩০,০০,০০০ × ০.৫ GB × ০.৮ s = ১২,০০,০০০ GB-second। ফ্রি ৪,০০,০০০ বাদ দিলে ৮,০০,০০০ bill হবে। ৮,০০,০০০ × ০.০০০০১৬৬৬৬৭ = ১৩.৩৩ USD।
2. Request: ৩০,০০,০০০ − ১০,০০,০০০ ফ্রি = ২০,০০,০০০ × প্রতি দশ লাখে ০.২০ USD = ০.৪০ USD।
3. মোট: মাসে ১৩.৭৩ USD। Arm-এ: ৮,০০,০০০ × ০.০০০০১৩৩৩৩৪ = ১০.৬৭, যোগ ০.৪০ = ১১.০৭ USD।

সারা মাস চালু একটা t3.small-এর খরচ ০.০২০৮ × ৭৩০ = ১৫.১৮ USD, EBS volume ছাড়াই, আর সেটা রাতের বেশির ভাগ সময় অলস বসে থাকত, sale-এর সময় হিমশিম খেত। এবার ৫ কোটি invocation ধরে দেখো: Lambda মাসে ২০০ USD ছাড়িয়ে যায়, অথচ কয়েকটা instance একই কাজ কম টাকায় করে দিত। হঠাৎ-হঠাৎ আসা আর কম-থেকে-মাঝারি traffic-এ Lambda জেতে; একটানা ভারী load-এ server।

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

#System design-এ Lambda

Lambda-কে ব্যবহার করো architecture-এর আঠা আর event সামলানোর লোক হিসেবে: হঠাৎ-হঠাৎ traffic আসা API-র backend, S3-এ file নামতেই প্রসেস, queue আর stream থেকে পড়া, schedule ধরে চলা কাজ, AWS-এর event-এ সাড়া দেওয়া (EC2-র state বদল, GuardDuty-র কোনো finding), আর ছোটখাটো automation। এর শক্তি: অলস সময়ের খরচ শূন্য, কয়েক সেকেন্ডে scale, আর চালানোর কোনো ঝামেলা নেই।

সীমাগুলো মাথায় রাখো: প্রতি invocation-এ ১৫ মিনিট, default-এ প্রতি Region-এ ১,০০০টা concurrent execution, synchronous payload ৬ MB, নতুন environment-এ cold start, আর VPC-তে না জুড়লে private VPC resource-এ পৌঁছানো যায় না (lesson 15.3)। Chapter 14-এর chooser ছোট, event-চালিত কাজ পাঠিয়েছিল Lambda-তে আর অনেকক্ষণ চলা container Fargate-এ; lesson 15.8 পুরো architecture ধরে Lambda, Fargate আর EC2-কে পাশাপাশি রাখবে।

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

এই command-গুলো CLI দিয়ে ap-southeast-1-এ thumbnail function বানায়। একটা sandbox account ব্যবহার করো; সবকিছু free tier-এর ভেতরেই থাকবে।

REGION=ap-southeast-1
ACCOUNT=111122223333

# ১. Lambda-কে বিশ্বাস করে এমন execution role, log-এর policy সহ
aws iam create-role --role-name thumbnail-role \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
  "Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name thumbnail-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

# ২. app.py-কে function.zip বানিয়ে function তৈরি (arm64-এ ২০% সস্তা)
zip function.zip app.py
aws lambda create-function --function-name thumbnail-example \
  --runtime python3.13 --architectures arm64 --handler app.handler \
  --role arn:aws:iam::$ACCOUNT:role/thumbnail-role \
  --memory-size 512 --timeout 30 --zip-file fileb://function.zip \
  --environment "Variables={TABLE_NAME=photos}" --region $REGION
# { "FunctionName": "thumbnail-example", "State": "Pending", "Runtime": "python3.13", ... }

# ৩. Synchronous ভাবে ডেকে ফল পড়ো
aws lambda invoke --function-name thumbnail-example --cli-binary-format raw-in-base64-out \
  --payload '{"Records":[{"s3":{"object":{"key":"products/saree-042.jpg"}}}]}' out.json
# { "StatusCode": 200, "ExecutedVersion": "$LATEST" }
cat out.json
# {"status": "ok", "key": "products/saree-042.jpg"}

# ৪. Asynchronous ভাবে ডাকো: Lambda শুধু জানায় event নিয়েছে
aws lambda invoke --function-name thumbnail-example --invocation-type Event \
  --cli-binary-format raw-in-base64-out --payload '{"Records":[]}' out.json
# { "StatusCode": 202 }

# ৫. Asynchronous setting: ১ বার retry, সর্বোচ্চ বয়স ১ ঘণ্টা, ব্যর্থ হলে SQS queue-তে
aws lambda put-function-event-invoke-config --function-name thumbnail-example \
  --maximum-retry-attempts 1 --maximum-event-age-in-seconds 3600 \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:ap-southeast-1:111122223333:thumb-failures-example"}}'

# ৬. Uploads bucket-কে function ডাকার অনুমতি (resource-based policy)
aws lambda add-permission --function-name thumbnail-example --statement-id s3-uploads \
  --action lambda:InvokeFunction --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::uploads-example --source-account $ACCOUNT
aws lambda get-policy --function-name thumbnail-example --query Policy --output text

# ৭. Version 1 publish করো, alias "live" তার দিকে তাক করো
aws lambda publish-version --function-name thumbnail-example
# { "Version": "1", "FunctionArn": "arn:aws:lambda:ap-southeast-1:111122223333:function:thumbnail-example:1", ... }
aws lambda create-alias --function-name thumbnail-example --name live --function-version 1
# পরে: traffic-এর ১০% version 2-এ
aws lambda update-alias --function-name thumbnail-example --name live --function-version 1 \
  --routing-config '{"AdditionalVersionWeights":{"2":0.1}}'

# ৮. Function URL (IAM দিয়ে যাচাই)
aws lambda create-function-url-config --function-name thumbnail-example --auth-type AWS_IAM
# { "FunctionUrl": "https://abcdefghijklmnopqrstuvwxyz123456.lambda-url.ap-southeast-1.on.aws/", "AuthType": "AWS_IAM" }

# ৯. Serverless cron: EventBridge Scheduler দিয়ে প্রতিদিন ঢাকার সময় সকাল ৬টায়
aws scheduler create-schedule --name nightly-report-example \
  --schedule-expression "cron(0 6 * * ? *)" --schedule-expression-timezone Asia/Dhaka \
  --flexible-time-window Mode=OFF \
  --target '{"Arn":"arn:aws:lambda:ap-southeast-1:111122223333:function:report-example",
             "RoleArn":"arn:aws:iam::111122223333:role/scheduler-invoke-example"}'

# ১০. Log দেখো, তারপর পরিষ্কার করো
aws logs tail /aws/lambda/thumbnail-example --follow
aws lambda delete-function --function-name thumbnail-example

ধাপ ৩ দুবার চালিয়ে log-এর Init Duration লাইনটা মিলিয়ে দেখো: এটা আসে শুধু cold start-এ। তারপর aws lambda update-function-configuration দিয়ে memory ১,৭৬৯ MB করো, CPU-ভারী code-এ Duration কমে যেতে দেখবে। EventBridge Scheduler function ডাকে নিজের IAM role (RoleArn) দিয়ে, তাই তার জন্য resource-based policy-তে কোনো statement লাগে না।

#সারসংক্ষেপ

মূল কথা

• Serverless = manage করার মতো server নেই, যতটুকু ব্যবহার ততটুকু টাকা, শূন্য পর্যন্ত নিজে থেকে scale। শুরু FaaS আর AWS Lambda দিয়ে, এখন এর মধ্যে DynamoDB, API Gateway, S3, SNS/SQS, Data Firehose, Aurora Serverless, Step Functions, Fargate, Cognito আর EventBridge।
• EC2 সবসময় চলে, সীমা CPU আর RAM, scale করে কয়েক মিনিটে instance যোগ করে। Lambda চলে প্রতি event-এ, সীমা সময় (১৫ মিনিট), প্রতি request-এ কয়েক সেকেন্ডে scale করে (default-এ প্রতি Region-এ ১,০০০ concurrent execution), আর bill হয় request আর millisecond ধরে।
• Memory ১২৮ MB থেকে ১০,২৪০ MB; memory-র সাথে CPU বাড়ে (১,৭৬৯ MB = ১ vCPU)। Log আর metric নিজে থেকেই যায় CloudWatch-এ।
• Runtime (অক্টোবর ২০২৬): Node.js 22/24, Python 3.11–3.14, Java 8–25, .NET 8/10 (C#, PowerShell), Ruby 3.3–4.0, আর Go, Rust ইত্যাদির জন্য OS-only provided.al2023। Go 1.x আর Amazon Linux 2-এর runtime অবসরে বা শেষের পথে। ১০ GB পর্যন্ত container image-কে Lambda Runtime API implement করতে হয়; যেকোনো image চালাতে ECS/Fargate।
• Synchronous (API Gateway, ALB, function URL, Cognito): caller অপেক্ষা করে, caller-ই আবার চেষ্টা করে, ৬ MB। Asynchronous (S3, SNS, EventBridge): 202, Lambda দুবার retry করে, ১ MB, তারপর on-failure destination বা DLQ। Event source mapping (SQS, Kinesis, DynamoDB Streams): Lambda poll করে batch পাঠায়; SQS-এর ব্যর্থ message যায় queue-র DLQ-তে।
• Execution role = function কী ডাকতে পারবে। Resource-based policy = কে তাকে ডাকতে পারবে (S3, SNS, EventBridge, API Gateway, অন্য account)। Function URL = নিজস্ব HTTPS endpoint, AWS_IAM বা NONE।
• Version অপরিবর্তনীয় ছবি; alias তাদের দিকে তাক করে, আর canary ও মুহূর্তে rollback-এর জন্য traffic ভাগ করতে পারে।
• চেনা নকশা: S3 upload → Lambda → আরেক bucket-এ thumbnail + DynamoDB-তে metadata; EventBridge schedule → Lambda, serverless cron হিসেবে।
• দাম = প্রতি দশ লাখ request-এ ০.২০ USD + GB-second (x86 ০.০০০০১৬৬৬৬৭, Arm ২০% কম), ১ ms পর্যন্ত গোল করে; free tier মাসে ১০ লাখ request + ৪,০০,০০০ GB-second। হঠাৎ-হঠাৎ কাজে সস্তা; একটানা ভারী load-এ server সস্তা।

নিজেকে যাচাই করো: Lambda-র গোড়ার কথা আর খরচ৩০টি প্রশ্ন