AWS for DevOps — Event-Driven Architecture

9.5 — Event-Driven Architecture

In an event-driven architecture, services communicate through events. Something happens (file uploaded, message sent, schedule fires) → a Lambda function reacts.

Common Event Sources

  S3 (file upload)  ──┐
  SQS (message)     ──┤
  SNS (notification)──┤──▶  Lambda  ──▶  Process / Store / Notify
  EventBridge (rule) ──┤
  DynamoDB Streams   ──┤
  Kinesis (stream)   ──┘

S3 Event Triggers

Trigger a Lambda when a file is uploaded to S3:

# Add S3 trigger to Lambda
$ aws s3api put-bucket-notification-configuration \
    --bucket my-uploads-bucket \
    --notification-configuration '{
        "LambdaFunctionConfigurations": [
            {
                "LambdaFunctionArn": "arn:aws:lambda:ap-south-1:123456789012:function:process-upload",
                "Events": ["s3:ObjectCreated:*"],
                "Filter": {
                    "Key": {
                        "FilterRules": [
                            {"Name": "suffix", "Value": ".csv"}
                        ]
                    }
                }
            }
        ]
    }'

The Lambda receives an event like:

{
  "Records": [
    {
      "s3": {
        "bucket": { "name": "my-uploads-bucket" },
        "object": { "key": "data/report.csv", "size": 1024 }
      }
    }
  ]
}

SQS Triggers

Lambda polls the SQS queue and processes messages in batches:

$ aws lambda create-event-source-mapping \
    --function-name process-orders \
    --event-source-arn arn:aws:sqs:ap-south-1:123456789012:orders-queue \
    --batch-size 10 \
    --maximum-batching-window-in-seconds 5

Setting	Purpose
batch-size	Max messages per invocation (1-10,000)
maximum-batching-window	Wait up to N seconds to fill the batch

SNS Triggers

SNS pushes notifications to Lambda (no polling):

$ aws sns subscribe \
    --topic-arn arn:aws:sns:ap-south-1:123456789012:deployment-alerts \
    --protocol lambda \
    --notification-endpoint arn:aws:lambda:ap-south-1:123456789012:function:handle-alert

EventBridge Rules

EventBridge is the event bus for AWS — routes events based on patterns:

# Schedule: run every 5 minutes
$ aws events put-rule \
    --name health-check-schedule \
    --schedule-expression "rate(5 minutes)"

# Pattern: react to ECS task state changes
$ aws events put-rule \
    --name ecs-task-stopped \
    --event-pattern '{
        "source": ["aws.ecs"],
        "detail-type": ["ECS Task State Change"],
        "detail": { "lastStatus": ["STOPPED"] }
    }'

# Add Lambda as the target
$ aws events put-targets \
    --rule ecs-task-stopped \
    --targets Id=1,Arn=arn:aws:lambda:ap-south-1:123456789012:function:alert-on-stop

DynamoDB Streams

React to changes in a DynamoDB table:

# Enable streams on a table
$ aws dynamodb update-table \
    --table-name Orders \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

# Connect stream to Lambda
$ aws lambda create-event-source-mapping \
    --function-name process-order-change \
    --event-source-arn arn:aws:dynamodb:ap-south-1:123456789012:table/Orders/stream/2026-01-01T00:00:00.000 \
    --starting-position LATEST \
    --batch-size 100

Step Functions — Orchestrating Workflows

For complex multi-step workflows, use Step Functions instead of chaining Lambdas:

  Start
    │
    ▼
  Validate Input (Lambda)
    │
    ├── Valid ──▶ Process Order (Lambda)
    │                 │
    │                 ▼
    │            Send Confirmation (Lambda)
    │                 │
    │                 ▼
    │              Success
    │
    └── Invalid ──▶ Send Error Notification (Lambda)
                       │
                       ▼
                     Fail

Event Source Comparison

Source	Invocation Type	Lambda Behaviour	Use Case
API Gateway	Synchronous	Returns response to client	REST APIs
S3	Asynchronous	Retries twice on failure	File processing
SQS	Poll-based	Deletes message on success	Work queues
SNS	Asynchronous	Push notification	Fan-out
EventBridge	Asynchronous	Rule-based routing	Event routing, scheduling
DynamoDB Streams	Poll-based	Processes in order	Change data capture

Dead Letter Queues

Failed asynchronous invocations need a safety net:

$ aws lambda update-function-configuration \
    --function-name process-upload \
    --dead-letter-config TargetArn=arn:aws:sqs:ap-south-1:123456789012:failed-uploads-dlq

Common Mistakes

Mistake	Why It Hurts	Fix
No DLQ on async functions	Failed events lost forever	Always configure a DLQ
Lambda chaining (A calls B calls C)	Tight coupling, hard to debug	Use Step Functions for orchestration
SQS visibility timeout < Lambda timeout	Message reprocessed while still running	Set visibility timeout = 6× Lambda timeout
No idempotency	Duplicate processing on retries	Design handlers to be idempotent

Quick Reference

Task	Command
Add SQS trigger	aws lambda create-event-source-mapping --function-name FN --event-source-arn SQS_ARN
Add SNS subscription	aws sns subscribe --topic-arn TOPIC --protocol lambda --notification-endpoint LAMBDA_ARN
Create EventBridge rule	aws events put-rule --name RULE --schedule-expression "rate(5 minutes)"
Add EventBridge target	aws events put-targets --rule RULE --targets Id=1,Arn=LAMBDA_ARN
Set DLQ	aws lambda update-function-configuration --function-name FN --dead-letter-config TargetArn=DLQ_ARN

---

Next → Serverless Practice Exercises