Lesson 151 · AWS Learning Path

AWS 151: Build a Lambda, API Gateway, SQS, SNS, EventBridge, and Step Functions flow

Anil Jalela · Published Nov 23, 2025 · 11 min read

Why this lesson matters

Build a small, named, observable event flow with API Gateway, Lambda, SQS, SNS, EventBridge, and Step Functions, then prove each boundary and retain it only for AWS152.

This lab converts the preceding concepts into one traceable transaction. The order must enter through an IAM-authorized HTTP route, become a domain event, start a durable workflow, reach a buffered worker exactly as transport allows, and produce an independently observable notification. You must prove each hop and then deliberately break it in AWS152.

What you will be able to do

By the end, you can:

• explain build a lambda, api gateway, sqs, sns, eventbridge, and step functions flow in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This lesson has an optional live path. Check current prices, obtain the account owner's approval, set a hard timer, use course tags, and complete the stated cleanup. The evidence path is a complete alternative.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+----------------------+
|      POST order      |
+----------------------+
           |
           v
+--------------------------+
|  API Gateway and Lambda  |
+--------------------------+
             |
             v
+-------------------------------+
|  Queue, topic, and event bus  |
+-------------------------------+
               |
               v
+-------------------------------------------------+
|  Step Functions result and correlated evidence  |
+-------------------------------------------------+

For Serverless order-flow lab, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Serverless order-flow lab. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Serverless order-flow lab. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open API Gateway, Lambda, SQS, SNS, EventBridge, and Step Functions using the nw-p07- prefix; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws lambda list-functions --query 'Functions[?starts_with(FunctionName, `nw-p07-`)].FunctionName' --output table
aws sqs list-queues --queue-name-prefix nw-p07- --output table
aws sns list-topics --query 'Topics[?contains(TopicArn, `nw-p07-`)].TopicArn' --output table
aws events list-rules --name-prefix nw-p07- --output table
aws stepfunctions list-state-machines --query 'stateMachines[?starts_with(name, `nw-p07-`)].name' --output table

Expected interpretation

All named components must appear, one test order must carry the same correlation ID through logs and messages, and the retained-state ledger must name AWS152 as owner with a same-day expiry.

Practical work

Complete the supplied CloudFormation or Console-first build plan, invoke one approved test, capture API response, Lambda log, queue state, topic/event routing, workflow history, cost timer, and retained inventory.

Guided live build

Use the prefix nw-p07- everywhere and a single fake order such as order-lab-001. Do not use customer data or subscribe a personal email address. The required architecture is small:

IAM-signed HTTP API -> intake Lambda -> EventBridge custom bus/rule
                                            |
                                            v
                                  Step Functions Standard
                                            |
                                            v
                                      SQS + DLQ
                                            |
                                            v
                             DynamoDB idempotency <- worker Lambda
                                            |
                                            v
                                        SNS topic

Download the reviewed P07 CloudFormation template. Read every resource and IAM statement before deployment. It creates named IAM roles, so deployment requires owner-approved CAPABILITY_NAMED_IAM. Use a clean learning account only.

Phase 0: preflight and bounded deployment

Download the template from course materials into CloudShell as template.yaml. Start a two-hour timer, check the current Pricing Calculator/service prices and create p07-evidence.md with caller ARN (redacted), Region, UTC start/deletion deadline, stack name, expected resources and starting inventory. Validate before deploying:

set -euo pipefail
export AWS_DEFAULT_REGION="ap-south-1"
export STACK_NAME="nw-p07-serverless-order-flow"
aws sts get-caller-identity --query Arn --output text
aws cloudformation validate-template --template-body file://template.yaml >/dev/null
aws cloudformation deploy \
  --stack-name "$STACK_NAME" \
  --template-file template.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides LabPrefix=nw-p07 LogRetentionDays=7 \
  --tags Project=NitWings-P07 ExpiresAt=REPLACE_WITH_UTC_DEADLINE
aws cloudformation describe-stacks --stack-name "$STACK_NAME" \
  --query 'Stacks[0].Outputs' --output table

Stop if the change set includes resources outside the template or the names collide. CloudFormation is the owner: do not manually delete a component while the stack exists.

Phase 1: understand the generated controls

The template intentionally uses one path, avoiding the earlier design's accidental double enqueue. Intake can only write to the named bus. EventBridge can only start the named workflow. The workflow can only send to the named queue. The worker can consume that queue, conditionally claim the order ID in the named DynamoDB table and publish to the named topic. API Gateway invokes intake through a source-ARN-limited function permission. Both functions can write only their named log groups.

The HTTP route uses AWS_IAM; invoke it using the CloudShell session's temporary credentials and SigV4. The template outputs OrderEndpoint. Use the SDK/botocore signing method supplied with the lab materials or API Gateway's IAM-authorized test tooling - never change the route to NONE as a shortcut. Send:

{"orderId":"order-lab-001","poison":false}

with header x-correlation-id: p07-correlation-001. Expected HTTP status is 202. Reusing the order ID is a deliberate duplicate test, not a new real order.

Phase 2: trace one correlation ID

For the same ID, record:

1. API access log request ID, route and integration status;
2. intake log order_accepted and successful per-entry PutEvents result behavior;
3. matching EventBridge rule invocation metric;
4. Step Functions execution input/history showing ValidateEvent then EnqueueOrder;
5. SQS sent/received/deleted metrics and no DLQ message;
6. DynamoDB idempotency item for the fake order and worker order_processed, SQS message ID and SNS message ID;
7. SNS publication metric.

The SNS topic deliberately has no human subscriber. Publication proves the worker reached SNS; it does not prove an end-user notification. Add no email or SMS endpoint. The worker uses partial-batch response and conditionally writes the order ID to a DynamoDB idempotency table before publishing. Repeating the same fake order must log duplicate_skipped and must not publish again. This simple claim is educational; a production design must define claim states, lease/expiry, failed-side-effect recovery and atomicity boundaries.

Build in this order when following the Console rather than CloudFormation:

1. Create nw-p07-orders-dlq and nw-p07-orders in SQS. Set the source redrive policy to the DLQ with a small lab receive count. Keep server-side encryption on.
2. Create SNS topic nw-p07-order-events. Add the source queue only if its queue policy permits the topic. No email endpoint is required.
3. Create EventBridge custom bus nw-p07-bus, then a rule matching source equal to nitwings.orders and detail-type equal to OrderCreated.
4. Create a Standard Step Functions state machine named nw-p07-order-workflow that validates the EventBridge envelope and sends its detail once to SQS. Add total/task timeout, bounded retry and catch states.
5. Create two Python Lambda functions, nw-p07-intake and nw-p07-worker. Give each a separate execution role. Intake can publish only to the named event bus. Worker can consume only the source queue and publish only to the named topic.
6. Add the SQS event source mapping to the worker with a small batch. The queue visibility timeout must exceed the function's maximum processing time with retry margin.
7. Create an API Gateway HTTP API route POST /orders integrated with intake. Require IAM authorization, enable structured access logs and use the lab stage.
8. Send one fake request. Carry one correlation ID through the API response, both functions, message attributes, event detail, workflow input, and logs.

Before AWS152, write the exact retained inventory and expiry in UTC. Retain only these named lab resources. Do not leave the stack overnight.

Diagnose this topic from its own evidence

Follow the correlation ID until the first missing hop. No API log means endpoint, SigV4, route/stage or caller permission. API 5xx plus intake log means handler or PutEvents; inspect per-entry failures. Intake success without workflow means bus/rule pattern, target role or EventBridge failed-invocation metric/DLQ. Failed workflow history names the state, input and SQS error. Queue growth means ESM, concurrency, worker or SNS dependency. Worker partial failure/receive count predicts DLQ. Change only the first failed boundary and use a new correlation ID for the retest.

Cost and cleanup

Requests, state transitions, logs, queue and event operations are usually small but not promised free. Retained logs and failed cleanup can continue to cost.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Build a small, named, observable event flow with API Gateway, Lambda, SQS, SNS, EventBridge, and Step Functions, then prove each boundary and retain it only for AWS152.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Serverless order-flow lab.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Serverless order-flow lab.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid email subscriptions, production data, broad roles, unbounded retries, or leaving any component after AWS152.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, state transitions, logs, queue and event operations are usually small but not promised free. Retained logs and failed cleanup can continue to cost.

Lesson acceptance

Pass when the template validates/deploys under an approved identity; the learner explains every resource and least-privilege arrow; one signed request carries the same correlation ID through API, Lambda, EventBridge, Standard workflow, SQS and SNS evidence; encryption, visibility, retry/DLQ, partial batch, logs and cost are interpreted; and a complete retained-state ledger hands the stack to AWS152 with same-day expiry. Fail if the API is made anonymously writable, the two paths enqueue duplicates, broad managed administrator policies are added, or service status substitutes for end-to-end evidence.

Official sources

• Serverless applications
• Event-driven architecture
• Lambda Developer Guide
• Serverless Lens
• P07 CloudFormation template