Amazon EventBridge

#EventBridge কেন: কিছু ঘটলেই সাড়া দাও

আগের চারটা লেসন ছিল নজর রাখা নিয়ে: metric, log, alarm আর Insights বলে দেয় সবকিছু কেমন চলছে। এই লেসন সাড়া দেওয়া নিয়ে: তোমার account-এ, তোমার application-এ বা কোনো partner-এর কাছে কিছু একটা ঘটলে, অন্য কিছু চালু হয়ে যাবে, আর সেটা জানতে কাউকে বারবার খোঁজ নেওয়ার code লিখতে হবে না।

#সমস্যাটা কী

ঢাকার Pathao-ধাঁচের একটা ride-sharing app ঘণ্টায় হাজার হাজার ride শেষ করে। প্রতিটা শেষ হওয়া ride-এর খবর যেতে হবে billing-এ, driver-কে টাকা দেওয়ার workflow-এ, loyalty point-এর service-এ, আর সামনের মাস থেকে একটা fraud model-এও। Trip service যদি নিজে এদের প্রত্যেককে সরাসরি call করে, তাহলে তাকে সবাইকে চিনতে হবে, সবার জন্য অপেক্ষা করতে হবে, আর নতুন একটা team যোগ হলেই নিজের code বদলাতে হবে। এদের একটা বন্ধ থাকলে trip service-ও ব্যর্থ হবে।

ওদিকে operations team চায় production-এর কোনো EC2 instance বন্ধ হলেই একটা email, security team চায় কেউ port 22 খুললেই একটা Lambda function চলুক, আর wallet team চায় তাদের payment gateway থেকে refund-এর খবর। এর প্রত্যেকটার জন্য আলাদা poller লেখা মানে ধীর, খরুচে আর নড়বড়ে একটা ব্যবস্থা।

#EventBridge জিনিসটা কী

Amazon EventBridge (আগের নাম CloudWatch Events; কিছু IAM action-এর নামে আর পুরোনো documentation-এ এখনো সেটা দেখবে) হলো একটা serverless event bus:

• Event হলো ছোট একটা JSON document, যেটা বলে কিছু একটা ঘটেছে: একটা instance বন্ধ হলো, একটা object upload হলো, একটা ride শেষ হলো।
• Event bus event গ্রহণ করে। Producer bus-এ event রেখে নিজের কাজে চলে যায়; কে শুনছে, সে জানে না।
• Bus-এর ওপর একটা rule-এর থাকে একটা event pattern। প্রত্যেকটা event প্রত্যেকটা rule-এর সাথে মিলিয়ে দেখা হয়; মিলে গেলে event যায় rule-এর target-গুলোতে (সর্বোচ্চ পাঁচটা), যেমন Lambda function, SQS queue, SNS topic বা Step Functions state machine।
• চালানোর মতো কোনো server নেই, scale করার কিছু নেই। টাকা দাও publish করা event ধরে (default bus-এ আসা AWS service event বিনা পয়সায়), আর যে feature ব্যবহার করো সেটার জন্য।

এটাই event-driven architecture: producer আর consumer একে অপরের থেকে decoupled, আর নতুন consumer মানে নতুন একটা rule, producer-এ কোনো পরিবর্তন না।

#Event: দেখতে কেমন

Bus-এর প্রতিটা event-এর খামটা একই রকম। একটা instance বন্ধ হলে EC2 এই event পাঠায়:

{
  "version": "0",
  "id": "7bf73129-1428-4cd3-a780-95db273d1602",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2026-11-01T06:30:00Z",
  "region": "ap-southeast-1",
  "resources": ["arn:aws:ec2:ap-southeast-1:111122223333:instance/i-0abcd1234example"],
  "detail": { "instance-id": "i-0abcd1234example", "state": "stopped" }
}

January 2026 থেকে একটা event সর্বোচ্চ 1 MB হতে পারে (তার আগে সীমা ছিল 256 KB, অনেক পরীক্ষার প্রশ্ন আর course এখনো এই সংখ্যাটাই ব্যবহার করে)। Custom event-এর bill হয় 64 KB-র টুকরো ধরে।

#Event কোথা থেকে আসে

• AWS service-গুলো নিজে থেকেই default bus-এ event দেয়: EC2-এর state change, Auto Scaling-এর কাজ, ECS task-এর state change, CodeBuild আর CodePipeline-এর ফল, GuardDuty আর Security Hub-এর finding, AWS Health event, Trusted Advisor check, পরিকল্পিত পরিবর্তনের নোটিশ, আরও অনেক।
• CloudTrail যে যেকোনো API call লেখে, সেটা আসে AWS API Call via CloudTrail event হিসেবে, তাই নিজস্ব event নেই এমন service-ও rule চালু করতে পারে (উদাহরণ লেসন ১৯.৬-এ)।
• Amazon S3 bucket-এ Send notifications to Amazon EventBridge চালু করলে নিজের event সরাসরি EventBridge-এ পাঠায় (লেসন ১০.৭)।
• তোমার application একটা bus-এ PutEvents call করে (SDK, CLI)।
• SaaS partner-রা তোমার account-এর একটা partner event source-এ event পাঠায়।
• Schedule নির্দিষ্ট সময়ে target চালু করে (নিচের অংশে)।

#Event bus: default, custom আর partner

Event bus হলো সেই পথ, যেটা event গ্রহণ করে আর তার ওপর rule চালায়। Bus regional, আর এটা তিন রকমের:

Custom bus একটা application-এর event-কে AWS-এর নিজের event থেকে আলাদা রাখে: নিজের rule, নিজের resource policy, নিজের archive। AWS-এর event-এ সাড়া দেওয়ার ঠিক জায়গা default bus।

পরিস্থিতি

Default bus: AWS-এর eventCustom bus: নিজের eventPartner bus: SaaS-এর event

একটা EC2 instance বন্ধ হলো; কেউ কোনো code লেখেনি, তবু একটা Lambda function আর একটা email সাড়া দেয়।

EC2 instancestate: stopped

Ride appride.app

Payment gatewaySaaS partner

Default busdefault

Custom busrides

Partner busaws.partner/…

Ruleevent pattern

Lambda function

Step Functions

SNS topic

SQS queue

event

Event-টা (JSON)

source

aws.ec2

detail-type

EC2 Instance State-change Notification

account

111122223333

region

ap-southeast-1

detail.state

stopped

Play

ধাপ 1 / 4

1

Production-এর একটা EC2 instance বন্ধ হয়ে গেল। EC2 নিজেই এই account আর Region-এর default bus-এ একটা state-change event পাঠায়। কিছু চালু করতে হয়নি: প্রত্যেক account-এ একটা default bus থাকেই, আর AWS service-গুলো নিজে থেকেই তাতে লেখে।

#Rule আর event pattern

একটা rule একটা bus-এর অংশ, আর তাতে থাকে একটা event pattern (মেলা event-এ সাড়া দাও) অথবা একটা schedule (legacy, নিচে দেখো), সাথে সর্বোচ্চ পাঁচটা target। Default হিসেবে একটা bus-এ ৩০০টা rule থাকতে পারে (বাড়ানো যায়)। প্রত্যেক rule তার bus-এর প্রত্যেকটা event দেখে, তাই একটা event অনেকগুলো rule চালু করতে পারে।

Event pattern হলো JSON, যেটার গঠন যে event-এর সাথে মেলাবে, ঠিক তার মতো:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": { "state": ["stopped", "terminated"] }
}

মেলানোর নিয়ম সহজ, কিন্তু কড়া:

• Pattern-এ যে যে field-এর নাম আছে, সবগুলো মিলতে হবে (AND)। Pattern যেসব field-এর নাম নেয় না, সেগুলো উপেক্ষা হয়।
• একটা field-এর মান একটা তালিকা; তার যেকোনো একটা মিললেই হলো (OR)।
• Operator ব্যবহার না করলে মেলানো হুবহু আর case-sensitive।
• Event-এর field যদি একটা তালিকা হয়, তাহলে তার যেকোনো একটা উপাদান মিললেই pattern মেলে।
• Event-এ যে field নেই, সেটায় মেলানো ব্যর্থ হয় (exists: false ছাড়া)।

Operator-গুলো বসে তালিকার ভেতরে:

{  "version": "0",  "id": "7bf73129-1428-4cd3-a780-95db273d1602",  "detail-type": "EC2 Instance State-change Notification",  "source": "aws.ec2",  "account": "111122223333",  "time": "2026-11-01T06:30:00Z",  "region": "ap-southeast-1",  "resources": [    "arn:aws:ec2:ap-southeast-1:111122223333:instance/i-0abcd1234example"  ],  "detail": {    "instance-id": "i-0abcd1234example",    "state": "stopped"  }}

{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EC2 Instance State-change Notification"
  ],
  "detail": {
    "state": [
      "stopped",
      "terminated"
    ]
  }
}

#Target

Event মিলে গেলে rule সেটা তার প্রত্যেক target-এ পাঠায় (একসাথে, এক rule-এ সর্বোচ্চ পাঁচটা)। চেনা target-গুলো:

• Compute: Lambda function, ECS task (Fargate বা EC2), AWS Batch job queue, Step Functions state machine, Systems Manager Run Command বা Automation, SageMaker pipeline।
• Messaging আর integration: SQS queue (standard, আর message group সহ FIFO), SNS topic, Kinesis Data Streams, Amazon Data Firehose (যেমন S3-এ জমা করতে), আরেকটা event bus, একটা API destination, API Gateway, AppSync।
• Operations: CloudWatch log group, Incident Manager response plan, CodeBuild, CodePipeline, আর EC2-এর কাজ (EBS snapshot নেওয়া, instance reboot, stop, terminate)।

একটা event-এর জন্য পাঁচটার বেশি target লাগবে? একই pattern দিয়ে কয়েকটা rule বানাও, অথবা এমন একটা target দাও যেটা নিজেই ছড়িয়ে দেয় (একটা SNS topic, বা আরেকটা bus)।

#Target কী পাবে, সেটা সাজানো

Default হিসেবে target পুরো event-টা পায়। প্রতিটা target-এর জন্য এর বদলে পাঠাতে পারো:

• event-এর একটা অংশ, একটা JSON path দিয়ে, যেমন $.detail;
• একটা নির্দিষ্ট JSON text;
• একটা input transformer: path দিয়ে মান তুলে নাও, তারপর একটা template-এ বসাও।

{
  "InputPathsMap": { "ride": "$.detail.ride-id", "fare": "$.detail.fare" },
  "InputTemplate": "{\"text\": \"Ride <ride> earned <fare> taka\"}"
}

কোনো API যে body চায় সেটা মেলাতে, Lambda function-কে ছোট পরিষ্কার input দিতে, বা পড়ার মতো একটা SNS email লিখতে transformer-ই উপায়।

#Retry আর dead-letter queue

কোনো target-এ পৌঁছানো না গেলে (throttle, বন্ধ, network-এর সমস্যা) EventBridge exponential back-off আর jitter দিয়ে retry করে। প্রতিটা target-এর একটা retry policy থাকে:

• Event-এর সর্বোচ্চ বয়স: ৬০ সেকেন্ড থেকে ২৪ ঘণ্টা (default ২৪ ঘণ্টা)।
• Retry-র সংখ্যা: ০ থেকে ১৮৫ (default ১৮৫)।

Retry ফুরালে event ফেলে দেওয়া হয়, যদি না target-এর একটা dead-letter queue (DLQ) থাকে: rule-এর একই Region-এ একটা standard SQS queue (FIFO না)। DLQ-র message-এ থাকে RULE_ARN, TARGET_ARN, ERROR_CODE, EXHAUSTED_RETRY_CONDITION-এর মতো attribute, যাতে তুমি কারণ ঠিক করে আবার পাঠাতে পারো।

কিছু error-এ একদমই retry হয় না, কারণ আবার চেষ্টায় লাভ নেই: permission নেই, target আর নেই, ঠিকানা ভুল। এসব event সোজা DLQ-তে যায় (বা হারায়)। Delivery হলো at least once, তাই target-কে idempotent হতে হবে।

দুই রকম নীরবতা আলাদা করে চিনে রাখো: যে event কোনো rule-এর সাথে মেলে না, সেটা কখনো পাঠানো হয় না, DLQ-তেও যায় না (MatchedEvents metric দেখো); আর যে event মিলেছিল কিন্তু পৌঁছাতে ব্যর্থ, সেটায় retry হয়, তারপর হারায় বা DLQ-তে যায় (FailedInvocations দেখো, আর তাতে alarm বসাও, লেসন ১৯.৩)।

#Target-এর permission

Rule চললে target-কে call করে EventBridge, তাই EventBridge-এর ওই target-এ permission লাগে। দুটো উপায়:

২০২৫ থেকে Lambda, SNS আর SQS target-এও একটা execution role ব্যবহার করা যায় (CloudWatch Logs target-এ এখনো resource policy লাগে), তবে পরীক্ষা ওপরের পুরোনো ভাগটাই জিজ্ঞেস করে। Target যদি customer managed KMS key দিয়ে encrypted হয় (যেমন SSE-KMS-ওয়ালা একটা SQS queue), তাহলে key policy-তেও EventBridge-কে key ব্যবহারের অনুমতি দিতে হবে।

পরিস্থিতি

Throttle, তারপর পৌঁছালRetry ফুরাল → DLQDLQ নেই: হারালPermission নেই

সাময়িক error হলে back-off দিয়ে বারবার চেষ্টা চলে, যতক্ষণ না target event-টা নিতে পারে।

Custom busrides

Payout rule

Payout Lambda

Target DLQstandard queue

On-call engineer

মিলল

Play

ধাপ 1 / 4

1

ঈদের সন্ধ্যা, একসাথে হাজার হাজার ride শেষ হচ্ছে। Event-টা payout rule-এর সাথে মেলে, যার target হলো Lambda function-টা।

#Schedule: scheduled rule আর EventBridge Scheduler

cron চালানো একটা server-এর বদলে EventBridge বরাবরই সময়সূচি ধরে target চালু করতে পারত:

• একটা scheduled rule (legacy)-এ থাকে একটা rate() expression (rate(4 hours)) বা ছয় field-এর একটা cron() expression (cron(0 20 * * ? *) = প্রতিদিন ২০:০০), এটা থাকে শুধু default bus-এ, সবসময় চলে UTC-তে, নির্ভুলতা এক মিনিট, আর target সর্বোচ্চ পাঁচটা।
• Amazon EventBridge Scheduler (২০২২) আলাদা, শুধু schedule-এর জন্য বানানো একটা service, আর AWS এখন এটাই সুপারিশ করে। এতে আছে time zone (daylight saving-সহ), একবারের schedule (at(2026-11-11T00:00:00)), চলার পর নিজে থেকে মুছে যাওয়া schedule, শুরু আর শেষের তারিখ, কয়েক মিনিটে invoke ছড়িয়ে দেওয়ার flexible time window, প্রতিটা schedule-এ retry policy আর DLQ, এক account-এ লক্ষ লক্ষ schedule, আর universal target দিয়ে ২৭০-এর বেশি service-এর যেকোনো API action, শুধু পুরোনো target-তালিকা না। মাসে প্রথম ১ কোটি ৪০ লক্ষ invoke বিনা পয়সায়, তারপর প্রতি দশ লক্ষে ১ USD।

পরিস্থিতি

প্রতি রাতে, ঢাকার সময়েপুরোনো rule: UTC-র ফাঁদএকবারের: ১১.১১ sale

Scheduler তোমার বেছে নেওয়া time zone-এ একটা cron expression চালায়।

EventBridge Schedulerschedule০২:০০ Asia/Dhaka

Scheduled rulelegacy, UTC

Lambda function

Report bucket

Play

ধাপ 1 / 3

1

Schedule: cron(0 2 * * ? *), time zone Asia/Dhaka। Scheduler time zone আর daylight saving বোঝে, তাই সারা বছর ২টা মানে স্থানীয় সময় ২টাই।

#API destination: যেকোনো HTTPS endpoint call করো

API destination হলো এমন একটা target, যেটা যেকোনো জায়গার একটা HTTPS endpoint: কোনো SaaS-এর API (Salesforce, Slack, কোনো courier company-র booking API), বা তোমার নিজের service। এর অংশগুলো:

• একটা connection, যেটায় থাকে authorization: Basic (user নাম আর password), OAuth client credentials (EventBridge নিজেই token আনে আর নবায়ন করে) বা একটা API key header। Secret-টা তোমার হয়ে AWS Secrets Manager-এ রাখা হয় (লেসন ২১.৩);
• endpoint-এর URL আর HTTP method;
• সেকেন্ডে কতবার invoke করা যাবে তার সীমা (default ৩০০, বাড়ানো যায়), যাতে হঠাৎ একগাদা event partner-কে চাপা না দেয়: বাড়তি invoke দেরিতে হয়, হারায় না (retry policy-র ভেতরে)।

API যে body চায়, সেটা বানাতে input transformer ব্যবহার করো। Retry আর DLQ অন্য target-এর মতোই কাজ করে। ২০২৪-এর শেষ থেকে একটা connection VPC-র ভেতরের বা on-premises-এর private endpoint-এও পৌঁছাতে পারে (VPC Lattice resource configuration দিয়ে), প্রতি account-এ ছোট একটা quota-সহ।

#Schema registry আর schema discovery

Schema একটা event-এর গঠন বর্ণনা করে: detail-এ কোন কোন field আছে আর তাদের type কী (OpenAPI 3 বা JSON Schema Draft 4)।

• Schema registry schema-গুলো এক জায়গায় রাখে, যাতে code লেখার আগেই একজন developer দেখতে পারে একটা event-এ কী আছে। AWS-এর event-এর schema আগে থেকেই aws.events registry-তে আছে; নিজের event-এর জন্য নিজের registry বানাও। Schema-র version থাকে।
• একটা bus-এ schema discovery চালু করলে, সেটা ভেতর দিয়ে যাওয়া event দেখে নিজে থেকেই তাদের schema বুঝে নেয়, আর গঠন বদলালে নতুন version যোগ করে।
• Code binding: একটা schema থেকে EventBridge Java, Python, TypeScript আর Go-র জন্য strongly-typed class বানিয়ে দেয়, ফলে application-এর code কাঁচা JSON ঘাঁটার বদলে RideCompleted.getFare()-এর মতো করে কাজ করে।

Registry বিনা পয়সায়; discovery-র bill হয় মাসে প্রথম ৫০ লক্ষ event-এর পর থেকে, প্রতিটা ঢোকা event ধরে।

#অন্য account আর অন্য Region-এ

#Bus-এর resource-based policy

একটা bus-কে রক্ষা করে একটা resource-based policy, যারা call করে সেই মানুষ আর role-দের IAM (identity-based) policy-র পাশাপাশি। Bus policy ঠিক করে বাইরের কে এতে event দিতে পারবে (আর কে এর rule সামলাতে পারবে):

• একটা account-কে অনুমতি: "Principal": {"AWS": "arn:aws:iam::111122223333:root"}, action events:PutEvents।
• পুরো একটা AWS Organization-কে অনুমতি: principal *, সাথে শর্ত aws:PrincipalOrgID (Organizations হলো লেসন ২০.১)।

পাঠানো account একটা rule বানায়, যার target অন্য account-এর bus-এর ARN, সাথে একটা IAM role যেটা EventBridge assume করে (March 2023 থেকে প্রত্যেক নতুন cross-account bus target-এ বাধ্যতামূলক, যাতে organization-এর SCP খাটে)। গ্রহণকারী নিজের bus-এ rule বানায়, ভালো হয় pattern-এ account field দিয়ে, যাতে শুধু প্রত্যাশিত পাঠানোওয়ালারাই rule চালু করতে পারে। Account পার হওয়া event-এর bill হয় পাঠানো account-এর, custom event হিসেবে।

চেনা একটা design হলো slide-এর central event bus: organization-এর প্রত্যেক account বাছাই করা event (security group-এর পরিবর্তন, GuardDuty finding, root sign-in) একটা security বা operations account-এর একটা bus-এ পাঠায়, যেখানে এক সেট rule সবগুলোর ওপর কাজ করে।

দুটো সীমা মনে রাখো: শুধু এক hop (অন্য account থেকে event পাওয়া একটা bus সেটা তৃতীয় কোনো account-এ আর পাঠাতে পারে না), আর সরাসরি cross-account target (January 2025 থেকে), যেটায় একটা rule মাঝখানে কোনো bus ছাড়াই অন্য account-এর SQS queue, Lambda function, SNS topic, Kinesis stream বা API Gateway-তে সোজা পৌঁছে দেয়, যদি ওই resource-এর policy অনুমতি দেয়।

#Cross-Region

একটা rule অন্য Region-এর event bus-কে target করতে পারে (একই বা অন্য account)। সব Region-এর event এক জায়গায় জড়ো করতে, বা disaster recovery-র জন্য একটা copy রাখতে এটা ব্যবহার করো। মনে রেখো default bus regional: ap-southeast-1-এর একটা rule eu-west-1-এর event কখনো দেখে না, আর IAM sign-in-এর মতো global service-এর event আসে us-east-1-এ (লেসন ১৯.৬)।

পরিস্থিতি

Bus policy নেই: আটকে গেলBus policy যোগ হলোঅন্য account-এর queue-তে সরাসরি

পাঠানোর দিকে rule আছে, কিন্তু গ্রহণকারী bus account-টাকে কখনো অনুমতি দেয়নি।

Workload account111122223333

Security account444455556666

CloudTrailAPI call

Default busrule → central

Central busorg-events

Alert Lambda

Audit queue

API call event

Play

ধাপ 1 / 3

1

১২টায় কেউ একটা workload account-এ port 22 সবার জন্য খুলে দিল। CloudTrail security group-এর ওই API call-টা লিখে রাখে, আর EventBridge default bus-এ একটা AWS API Call via CloudTrail event দেয় (লেসন ১৯.৬)।

#Archive আর replay

• একটা archive একটা bus-এ পাঠানো event জমা রাখে: সবগুলো, বা শুধু একটা event pattern-এর সাথে মেলাগুলো, নির্দিষ্ট কয়েক দিন বা চিরকাল। শুরুতে এটা খালি, আর তৈরি হওয়ার পরে আসা event-ই শুধু রাখে।
• একটা replay বেছে নেওয়া একটা সময়ের archive-এর event আবার পাঠায় archive যে bus-এর, সেই bus-এই, সব rule-এ বা শুধু তোমার বেছে নেওয়া rule-গুলোতে। Replay হওয়া event-এ একটা replay-name field থাকে। আগের ক্রমেই আসবে এমন নিশ্চয়তা নেই।

কাজে লাগে: bug fix-এর পর আবার process করতে, retry policy-র চেয়ে বেশি সময় target বন্ধ থাকার পর ঘাটতি পূরণে, আসল পুরোনো traffic দিয়ে নতুন consumer পরীক্ষা করতে, বা একটা read model আবার গড়তে। Consumer-কে idempotent বানাও: replay এমন event-ও পাঠায়, যেগুলো সে হয়তো আগেই একবার সামলেছে।

খরচ: archive-এর process প্রতি GB আর জমা রাখা প্রতি GB-মাস; replay হওয়া event-এর bill হয় custom event-এর মতো।

পরিস্থিতি

Archive করাBug ঠিক → replayArchive দেরিতে বানানো

Bus-এর ওপর একটা archive সব event, বা শুধু তার pattern-এর সাথে মেলে এমন event, নির্দিষ্ট সময় বা চিরকাল জমা রাখে।

Ride app

Custom busrides

Fare Lambdarule target

Archiverides-archive

Play

ধাপ 1 / 3

1

Team rides bus-এর ওপর একটা archive বানায়, একটা event pattern দিয়ে (শুধু Ride Completed), আর retention ৩৬৫ দিন। Retention চিরকালও রাখা যায়। Pattern না দিলে archive bus-এর সব event রাখে।

#EventBridge Pipes

Bus হলো অনেকের সাথে অনেকের routing-এর জন্য। প্রায়ই তোমার দরকার শুধু একটা source থেকে একটা target-এ ডেটা নেওয়া, হয়তো filter করে আর কিছু তথ্য যোগ করে। Pipes-এর আগে এর মানে ছিল একটা Lambda function লেখা, যেটা queue বা stream poll করে, filter করে, অন্য service call করে, তারপর এগিয়ে দেয়। EventBridge Pipes এটা code ছাড়াই করে:

1. Source: একটা SQS queue, Kinesis Data Streams, DynamoDB Streams, Amazon MSK, self-managed Apache Kafka বা Amazon MQ। Pipe তোমার হয়ে batch ধরে poll করে।
2. Filter (ঐচ্ছিক): একটা event pattern, rule-এর মতো একই ভাষা। যে event মেলে না, সেটা বাদ পড়ে, আর তার bill হয় না।
3. Enrichment (ঐচ্ছিক): একটা Lambda function, একটা Step Functions Express workflow, একটা API Gateway API বা একটা API destination call করো, আর তার উত্তরটাই হয় নতুন event।
4. Target: অনেকগুলোর একটা, যেমন Step Functions, একটা event bus, Kinesis, Firehose, SQS, SNS, Lambda, ECS task, API destination, Redshift আরও অনেক। একটা input transformer ডেটা নতুন করে সাজাতে পারে।

Error-এর নিয়ম source অনুযায়ী: ব্যর্থ SQS message queue-তে ফেরত যায়, আর maxReceiveCount পেরোলে queue-এর নিজের DLQ-তে; stream source-এ retry setting আর DLQ থাকে pipe-এর ওপর। Filter-এর পর প্রতি দশ লক্ষ request-এ Pipes-এর খরচ ০.৪০ USD।

পরিস্থিতি

টাকা দেওয়া order পার হয়Test order বাদ পড়েEnrichment ব্যর্থ

Pipe queue থেকে টেনে নেয়, filter করে, তথ্য যোগ করে, আর target চালু করে।

Pipe: orders-to-delivery

SQS queuesource

Filterevent pattern

EnrichmentLambda

Step Functionstarget

order paid

Play

ধাপ 1 / 4

1

Pipe নিজেই queue পড়ে: কোনো Lambda poller বা worker server লিখতে হয় না। Source হতে পারে SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MSK, self-managed Kafka বা Amazon MQ।

#EventBridge, SNS নাকি SQS?

তিনটাই producer আর consumer-কে আলাদা করে, তাই scenario-র প্রশ্নে এরা গুলিয়ে যায়। লেসন ১৩.৭-এ messaging service-গুলোর বিস্তারিত তুলনা আছে; সংক্ষেপে:

মনে রাখার নিয়ম: AWS service-এর event, SaaS-এর event, account পার হওয়া routing আর schedule → EventBridge। অসংখ্য subscriber-এ বিশাল fan-out, মানুষকে SMS বা email → SNS। Worker-দের জন্য কাজ জমা রাখা, হঠাৎ ভিড় সামলানো → SQS (প্রায়ই EventBridge বা SNS-এর target হিসেবে)।

#কী কী ভুল হয়

• Rule কখনো চালু হয় না। Pattern মেলে না: detail-type-এ বানান ভুল, ছোট-বড় হাতের অক্ষরের পার্থক্য, সংখ্যা string হিসেবে লেখা ("420" numeric শর্তে মেলে না), ভুল স্তরে nested field, বা rule ভুল bus-এ বা ভুল Region-এ। aws events test-event-pattern দিয়ে পরীক্ষা করো, আর MatchedEvents দেখো।
• Root sign-in বা IAM-এর rule তোমার Region-এ চালু হয় না। IAM আর অন্য global service-এর event আসে us-east-1-এ, আর root-এর console sign-in আসে us-east-1, us-east-2 বা us-west-2-এ; rule সেখানে বানাও (লেসন ১৯.৬)।
• CLI বা IaC দিয়ে deploy করার পর Lambda target কখনো invoke হয় না: events.amazonaws.com-এর জন্য resource-based permission নেই। Event যায় DLQ-তে NO_PERMISSIONS নিয়ে, বা হারায়।
• Retry policy-র চেয়ে লম্বা বিভ্রাটের পর event হারিয়ে যায়, কারণ DLQ দেওয়া ছিল না। গুরুত্বপূর্ণ প্রতিটা target-এ DLQ দাও, আর FailedInvocations-এ alarm বসাও।
• Retry বা replay-এর পর একই event দুবার: delivery at least once। একটা idempotency key ব্যবহার করো (ride ID, order ID)।
• অন্য account-এর event কখনো পৌঁছায় না: গ্রহণকারীর bus policy নেই, পাঠানোওয়ালার target-এ IAM role নেই, বা তৃতীয় account-এ দ্বিতীয় hop।
• অসীম loop: S3 বা DynamoDB-র পরিবর্তনে চালু হওয়া একটা Lambda function একই ধরনের পরিবর্তন লেখে, যেটা তাকে আবার চালু করে। Pattern সরু করো (একটা prefix, এমন field যেটা function নিজে বসায় না), আর invoke-এর সংখ্যায় alert রাখো।
• Schedule-এর কাজ ভুল ঘণ্টায় চলে: UTC-তে চলা একটা legacy scheduled rule। Time zone-সহ Scheduler ব্যবহার করো।
• Throttling: PutEvents আর target invoke-এর প্রতি Region-এ quota আছে (সেকেন্ডে হাজার হাজার, বাড়ানো যায়)। PutEvents batch করে পাঠাও, আর sale বা ঈদের ভিড়ের আগেই quota বাড়ানোর অনুরোধ করো।
• Replay কিছুই পায় না: event ঘটার পরে archive বানানো হয়েছিল।
• SaaS integration কিছুই পাঠায় না: partner event source-কে কখনো partner bus-এর সাথে জোড়া দেওয়া হয়নি।

#System design-এ EventBridge

• Event-driven microservice: প্রত্যেক service নিজের domain event (Order Placed, Ride Completed) একটা custom bus-এ publish করে; অন্য service-গুলো rule দিয়ে subscribe করে। নতুন consumer যোগ করতে producer-এ হাত দিতে হয় না। ধীর consumer-এর সামনে একটা SQS queue রাখো, ভিড় সামলাতে।
• Operations-এর স্বয়ংক্রিয় কাজ: EC2, ECS, Auto Scaling আর AWS Health-এর event Lambda function, Systems Manager Automation runbook বা ticket চালু করে; CloudWatch alarm-এর state change-ও একটা event।
• Security-র স্বয়ংক্রিয় কাজ: CloudTrail API call (root sign-in, DeleteTrail, security group-এর পরিবর্তন), GuardDuty আর Security Hub-এর finding, Config-এর compliance পরিবর্তন → একটা rule → isolate করতে Lambda, সতর্ক করতে SNS (লেসন ১৯.৬, লেসন ২১.৭)।
• S3-এর processing fan-out: একটা bucket, সমৃদ্ধ filter (size, key, metadata) দিয়ে অনেকগুলো স্বাধীন workflow, Step Functions আর FIFO queue-সহ (লেসন ১০.৭)।
• দুই দিকেই SaaS integration: ভেতরে আনতে partner bus, বাইরে পাঠাতে API destination।
• Security আর audit event-এর জন্য প্রতি organization-এ একটা central event bus, aws:PrincipalOrgID দিয়ে policy।
• Serverless cron: EventBridge Scheduler দিয়ে Lambda function, ECS task (লেসন ১৪.৩) বা Step Functions workflow চালু করা; শুধু crontab চালানোর জন্য কোনো instance রাখতে হয় না।

যখন এটা ভুল হাতিয়ার: লম্বা সময় জমা রাখা আর প্রতি message-এ একজন consumer-ওয়ালা টেকসই work queue দরকার (SQS), অনেক পাঠক আর বেশি throughput-সহ ক্রমবদ্ধ, replay-যোগ্য stream দরকার (Kinesis Data Streams বা MSK), বা বিশাল পরিসরে মানুষকে SMS আর email পাঠাতে হবে (SNS)।

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

এই command-গুলো ap-southeast-1-এ AWS CLI v2 দিয়ে। Custom event-এ প্রতি দশ লক্ষে ১ USD লাগে; শেষে সব মুছে ফেলো।

# 1. A custom bus and a rule with an event pattern
aws events create-event-bus --name rides
aws events put-rule --name ride-completed --event-bus-name rides \
  --event-pattern '{"source":["ride.app"],"detail-type":["Ride Completed"],"detail":{"fare":[{"numeric":[">",0]}]}}'
# { "RuleArn": "arn:aws:events:ap-southeast-1:111122223333:rule/rides/ride-completed" }

# 2. Test the pattern against a sample event before trusting it
aws events test-event-pattern \
  --event-pattern '{"source":["ride.app"],"detail":{"city":[{"anything-but":["Dhaka"]}]}}' \
  --event '{"id":"1","account":"111122223333","source":"ride.app","time":"2026-11-01T06:32:40Z","region":"ap-southeast-1","resources":[],"detail-type":"Ride Completed","detail":{"fare":420,"city":"Chattogram"}}'
# { "Result": true }

# 3. Let EventBridge invoke the function (resource-based policy), then add it as a target
#    with a retry policy and a DLQ (a standard SQS queue whose policy allows events.amazonaws.com)
aws lambda add-permission --function-name payout --statement-id eb-ride-completed \
  --action lambda:InvokeFunction --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-southeast-1:111122223333:rule/rides/ride-completed
aws events put-targets --rule ride-completed --event-bus-name rides --targets '[{
  "Id": "payout",
  "Arn": "arn:aws:lambda:ap-southeast-1:111122223333:function:payout",
  "RetryPolicy": { "MaximumRetryAttempts": 10, "MaximumEventAgeInSeconds": 3600 },
  "DeadLetterConfig": { "Arn": "arn:aws:sqs:ap-southeast-1:111122223333:payout-dlq" },
  "InputTransformer": {
    "InputPathsMap": { "ride": "$.detail.ride-id", "fare": "$.detail.fare" },
    "InputTemplate": "{\"ride\": <ride>, \"fare\": <fare>}" } }]'
# { "FailedEntryCount": 0, "FailedEntries": [] }

# 4. Publish an event
aws events put-events --entries '[{"EventBusName":"rides","Source":"ride.app","DetailType":"Ride Completed","Detail":"{\"ride-id\":\"r-88412\",\"fare\":420,\"city\":\"Chattogram\"}"}]'
# { "FailedEntryCount": 0, "Entries": [ { "EventId": "b1e0c4a2-6f3d-4c1e-9a77-2f0d5e8c9a10" } ] }

# 5. Archive Ride Completed events for a year, and replay a time window later
aws events create-archive --archive-name rides-archive \
  --event-source-arn arn:aws:events:ap-southeast-1:111122223333:event-bus/rides \
  --event-pattern '{"detail-type":["Ride Completed"]}' --retention-days 365
aws events start-replay --replay-name fare-fix-1101 \
  --event-source-arn arn:aws:events:ap-southeast-1:111122223333:archive/rides-archive \
  --event-start-time 2026-11-01T03:00:00Z --event-end-time 2026-11-01T05:00:00Z \
  --destination '{"Arn":"arn:aws:events:ap-southeast-1:111122223333:event-bus/rides","FilterArns":["arn:aws:events:ap-southeast-1:111122223333:rule/rides/ride-completed"]}'
# { "ReplayArn": "...:replay/fare-fix-1101", "State": "STARTING" }

# 6. Allow every account of the organization to put events on the bus
aws events put-permission --event-bus-name rides --action events:PutEvents \
  --principal '*' --statement-id whole-org \
  --condition '{"Type":"StringEquals","Key":"aws:PrincipalOrgID","Value":"o-a1b2c3d4e5"}'

# 7. A nightly job at 02:00 Dhaka time with EventBridge Scheduler
aws scheduler create-schedule --name nightly-report \
  --schedule-expression 'cron(0 2 * * ? *)' --schedule-expression-timezone 'Asia/Dhaka' \
  --flexible-time-window '{"Mode":"OFF"}' \
  --target '{"Arn":"arn:aws:lambda:ap-southeast-1:111122223333:function:report","RoleArn":"arn:aws:iam::111122223333:role/scheduler-invoke-report"}'
# { "ScheduleArn": "arn:aws:scheduler:ap-southeast-1:111122223333:schedule/default/nightly-report" }

# 8. A pipe: SQS → filter → Lambda enrichment → Step Functions
aws pipes create-pipe --name orders-to-delivery \
  --role-arn arn:aws:iam::111122223333:role/pipe-orders \
  --source arn:aws:sqs:ap-southeast-1:111122223333:orders \
  --source-parameters '{"FilterCriteria":{"Filters":[{"Pattern":"{\"body\":{\"status\":[\"paid\"]}}"}]}}' \
  --enrichment arn:aws:lambda:ap-southeast-1:111122223333:function:add-address \
  --target arn:aws:states:ap-southeast-1:111122223333:stateMachine:delivery
# { "Name": "orders-to-delivery", "CurrentState": "CREATING", "DesiredState": "RUNNING" }

# 9. Clean up
aws pipes delete-pipe --name orders-to-delivery
aws scheduler delete-schedule --name nightly-report
aws events delete-archive --archive-name rides-archive
aws events remove-targets --rule ride-completed --event-bus-name rides --ids payout
aws events delete-rule --name ride-completed --event-bus-name rides
aws events delete-event-bus --name rides

Console-এও চেষ্টা করো: default bus-এ EventBridge → Rules → Create rule খোলো, AWS events বেছে নাও, EC2 আর EC2 Instance State-change Notification বাছো, আর নমুনা event-এর সাথে pattern পরীক্ষা করতে sandbox ব্যবহার করো। তারপর একটা test instance বন্ধ করে CloudWatch-এ rule-এর MatchedEvents আর Invocations metric দেখো।

#সারসংক্ষেপ