AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 66“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Project 3: Serverless Event-Driven Order Platform

TechLearningPro sells course seats, exam vouchers, and lab credits. Synchronous “one Lambda does everything” checkout collapses under retries, partial failures, and notification fa

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Project 3: Serverless Event-Driven Order Platform

AWS Cloud & DevOps Engineering · Lesson 66 · Production Projects and Interview

Lesson Overview

TechLearningPro sells course seats, exam vouchers, and lab credits. Synchronous “one Lambda does everything” checkout collapses under retries, partial failures, and notification fan-out. This portfolio project builds an event-driven order platform: Amazon API Gateway accepts the order command; AWS Lambda validates and writes the order; Amazon EventBridge (and/or Amazon SQS) decouples fulfillment; Amazon DynamoDB stores order state; optional AWS Step Functions orchestrates multi-step confirmation. You will prove intake → process → notify → failure replay with IaC, least-privilege IAM, observability, failure tests, cost notes, and cleanup.

Continuity: Lambda and API Gateway (14–15), EventBridge/SNS/SQS (22), Step Functions (23), DynamoDB ops (53), IaC and CI from Module 3, PRR habits from 63. Tag Project=tlp-lesson66. Budgets first; destroy after evidence.

Learning Objectives

Frame the business problem for asynchronous order processing at TechLearningPro.
Write FRs and NFRs including idempotency, durability, and replay.
Select API Gateway, Lambda, EventBridge/SQS, DynamoDB (and optional Step Functions) with explicit rationale.
Draw request and event flows including DLQ and replay.
Design DynamoDB keys for order access patterns without inventing undocumented features.
Structure a serverless repo (src/, infra/, events/, docs/adr/).
Implement IaC (SAM, CDK, or Terraform) with remote state or stack discipline.
Apply least-privilege Lambda roles per function.
Secure the API (IAM, JWT/Cognito, or API keys per current docs—pick one and ADR it).
Add CloudWatch metrics, alarms, and structured logs with correlation IDs.
Test success path plus poison message and authorization failure paths.
Document cost drivers (requests, GB-seconds, DynamoDB, EventBridge, API calls) as illustrative with pricing dates.
Deliver deploy and destroy procedures.
Package portfolio artifacts for interviews.
Explain when not to use serverless (long-running, specialized networking).
Design idempotent order creation using client tokens or conditional writes.
Place SQS between producers and consumers when buffering is required.
Use EventBridge for fan-out to email/SMS/analytics consumers.
Connect to Project 5 (lesson 68) telemetry and DR expectations.
Produce ADRs for sync vs async boundary and for EventBridge vs SQS primary bus.

Prerequisites

Lessons 14–15, 22–23, 53, and Module 3 IaC/CI familiarity.
Sandbox account with budgets; permission to create API Gateway, Lambda, DynamoDB, EventBridge/SQS.
Ability to invoke APIs with curl or Postman and to read CloudWatch Logs.

Detailed Core Concepts

Business problem

When a learner purchases a seat, TechLearningPro must record the order, reserve inventory or entitlement, notify the learner, and update analytics—without losing events when the notification provider is slow and without double-charging on client retries.

Functional requirements

POST /orders accepts an order command and returns an order id (accepted/created semantics documented).
Persist order state in DynamoDB with clear status transitions (RECEIVED → PROCESSING → CONFIRMED / FAILED).
Emit domain events for confirmation and failure.
Notify via a consumer (email stub or SNS).
Support replay from DLQ after fixing a bug.

Non-functional requirements

Idempotency for duplicate POSTs; at-least-once processing with safe handlers; encryption at rest (DynamoDB/SQS defaults or CMK—confirm current options); least privilege; p95 latency target for accept path (illustrative, measure in lab); observability; budget and destroyability.

Service selection rationale

Service	Role	Why
API Gateway	HTTPS edge for commands	Managed auth options, throttling, mapping
Lambda	Validate, write, emit	Pay-per-use; fits bursty checkout
DynamoDB	Order store	Single-digit ms; serverless scaling
EventBridge	Fan-out domain events	Decouple notifiers/analytics
SQS (+ DLQ)	Buffer / retry	Absorb spikes; poison isolation
Step Functions (optional)	Multi-step confirm	Visible orchestration, retries, audit

Prefer API → Lambda → DynamoDB → EventBridge as the primary happy path; insert SQS when a consumer must scale independently or needs DLQ-first operations. Use Step Functions when the confirmation workflow has multiple compensating steps.

Repo structure

text
tlp-order-platform/
  src/functions/accept_order/
  src/functions/process_order/
  src/functions/notify/
  events/schemas/          # example event JSON (document, not invent APIs)
  infra/                   # SAM template, CDK app, or Terraform
  pipelines/
  docs/adr/
  evidence/
  README.md

IaC approach

AWS SAM or CDK for rapid Lambda+API wiring; Terraform if org standard. Parameterize stage names; enable tracing only if you will clean up and understand X-Ray costs (lesson 38).

Security

One role per function; DynamoDB resource ARNs scoped to table/index; no wildcard dynamodb:* on *. API auth: choose Cognito JWT, IAM, or private API—document in ADR-6601. Encrypt env; secrets in Secrets Manager if needed. Enable CloudTrail for management events in the account.

CI/CD

Lint/unit test → sam/build or cdk synth → deploy to lab account via OIDC → integration test → optional promote. Never deploy from laptops with admin keys in portfolio demos.

Monitoring

API 4xx/5xx; Lambda errors/throttles/duration; DynamoDB throttles; SQS DLQ depth; EventBridge failed invocations (confirm metric names in current docs). Alarm on DLQ > 0.

Failure and replay

Poison message → DLQ → fix code → replay tool/runbook (redrive per current SQS docs). Idempotent processors mandatory.

Cost

API Gateway requests; Lambda GB-seconds; DynamoDB RCU/WCU or on-demand; EventBridge events; SQS requests; log ingestion. Idle cost is usually low—still destroy unused APIs and tables to avoid surprise retention and continuous log costs.

Architecture and Design Diagrams

mermaid
flowchart LR
  Client[Client / checkout UI] --> APIGW[API Gateway]
  APIGW --> Accept[Lambda accept_order]
  Accept --> DDB[(DynamoDB Orders)]
  Accept --> Bus[EventBridge bus]
  Bus --> Proc[Lambda process / Step Functions]
  Proc --> DDB
  Proc --> Q[SQS notify queue]
  Q --> Notify[Lambda notify]
  Q --> DLQ[DLQ]
  Notify --> SNS[SNS / email stub]

mermaid
stateDiagram-v2
  [*] --> RECEIVED
  RECEIVED --> PROCESSING
  PROCESSING --> CONFIRMED
  PROCESSING --> FAILED
  FAILED --> PROCESSING: replay after fix

mermaid
sequenceDiagram
  participant C as Client
  participant A as API+Accept Lambda
  participant D as DynamoDB
  participant E as EventBridge
  participant N as Notify
  C->>A: POST /orders Idempotency-Key
  A->>D: Conditional put order
  A->>E: OrderReceived
  A-->>C: 202/201 + orderId
  E->>N: rule target
  N->>N: send notification

Technical Explanation

Idempotency

Clients send an idempotency key (header or body). Accept Lambda conditional-writes the order item; duplicates return the original order id. Document the exact attribute names you choose—they are your schema, not an invented AWS API.

Event contract

Define a JSON envelope: detail-type, source, detail.orderId, detail.status. Version the schema in events/schemas/. Consumers must tolerate additive fields.

DynamoDB access patterns

PK ORDER#<id> or CUSTOMER#<id> with SK ORDER#<id> depending on list-by-customer needs. Avoid scans in the hot path. Use on-demand capacity for lab simplicity unless you practice provisioned.

EventBridge vs SQS

EventBridge: many targets, content filtering, archive/replay features as documented today. SQS: competing consumers, visibility timeout, DLQ. Many designs use EventBridge → SQS target for a specific worker.

Step Functions optional path

If confirmation includes payment authorize → entitlement grant → receipt, a state machine makes retries and compensations visible. Keep the lab optional to control cost/time; ADR if deferred.

Partial failure

Accept succeeded but notify failed: order remains PROCESSING/CONFIRMED with notifyStatus=PENDING; DLQ holds the event; ops replays. Never delete DLQ messages without triage notes.

Authorization failure test

Call API without token/signature; expect 401/403; capture evidence. Misconfigured resource policy is a common portfolio miss.

Networking note

Lambda in VPC only if it must reach private resources—default non-VPC is fine for DynamoDB public endpoint with IAM. VPC adds ENI/NAT cost (lesson 50).

Practical Implementation or Design Walkthrough

Problem

Implement order intake, processing, notification, and failure replay for TechLearningPro checkout.

Steps

Budget + tags Project=tlp-lesson66.
Create DynamoDB table with chosen keys; enable PITR if practicing DR toward lesson 68.
Implement accept/process/notify functions with structured logging.
Wire API Gateway route to accept; IAM/JWT auth per ADR.
Emit EventBridge event; rule to SQS or Lambda; configure DLQ.
Deploy via SAM/CDK/Terraform; run success POST.
Failure test: force notify throw → message in DLQ → fix → redrive → evidence.
Failure test: unauthorized call → denied evidence.
Write ADRs; package portfolio; destroy stacks; confirm no orphan APIs/tables/log groups you intend to delete.

Enterprise Real-World Scenarios

Double-click checkout

Learner double-submits; without idempotency, two charges. Conditional write saves finance.

Analytics consumer breaks

Bad rule floods errors; EventBridge metrics + DLQ protect the accept path.

“Let’s put payment in the accept Lambda”

Timeouts and PCI scope explode. Fix: async boundary after validate+record intent; payment worker separate.

Infinite retry storm

No DLQ; poison message burns Lambda concurrency. Fix: max receive count → DLQ + alarm.

Step Functions everywhere

Simple notify wrapped in a state machine adds cost and complexity. Fix: use only for multi-step compensations.

Best Practices

Idempotent command handling.
Explicit status machine in data store.
One responsibility per Lambda.
DLQ on every critical queue.
Alarm on DLQ depth and Lambda errors.
Least-privilege roles per function.
Version event schemas.
Prefer async for fan-out side effects.
Document auth choice in ADR.
Integration tests in CI against lab stage.
Correlation IDs across logs.
Budget and destroy discipline.
Avoid VPC Lambda unless required.
PITR/backups considered for production orders.
Link runbooks for redrive.

Common Mistakes and Anti-Patterns

God-Lambda doing payment+email+analytics.
No idempotency key.
Catching exceptions and acknowledging poison messages.
Shared admin role for all functions.
Scanning DynamoDB for every read.
Hardcoding table names without stages.
Inventing EventBridge API fields.
Leaving API open to the world “for the demo.”
No destroy of custom domains/logs.
Treating 200 on accept as “fully fulfilled.”

Troubleshooting and Design Review

Symptom	Cause	Action
502 from API	Lambda error/timeout	Check logs; raise timeout carefully
Duplicate orders	Missing idempotency	Conditional write + key
DLQ filling	Poison payload / bug	Fix code; redrive sample
Throttles	Burst vs concurrency	Reserved concurrency / notify SQS buffer
Auth always 401	Wrong authorizer config	Align token/issuer with docs
High cost	Chatty logs / over-provision	Retention; on-demand review

Interview Questions and Answers

Q1: Why event-driven orders? A: Decouple accept from side effects; survive slow notifiers; scale consumers independently.
Q2: EventBridge vs SQS? A: Fan-out/filtering vs buffer/competing consumers/DLQ—often combined.
Q3: Idempotency? A: Client key + conditional DynamoDB put.
Q4: DLQ purpose? A: Isolate poison messages for fix-and-replay.
Q5: When Step Functions? A: Multi-step workflows needing visible retries/compensations.
Q6: Auth options? A: Cognito JWT, IAM, private API—pick and ADR.
Q7: Failure tests? A: Unauthorized call; forced notify failure → DLQ → redrive.
Q8: Cost drivers? A: Requests, GB-s, DynamoDB mode, logs.
Q9: Why not one EC2? A: Ops tax and scaling for spiky checkout; serverless fits.
Q10: Observability? A: API metrics, Lambda errors, DLQ depth, traces optional.
Q11: Schema evolution? A: Version envelopes; additive changes.
Q12: Least privilege? A: Per-function roles; table ARNs.
Q13: Link to containers project? A: Sync BFF may sit on ECS while orders async here.
Q14: Replay safety? A: Idempotent consumers; status checks.
Q15: Portfolio proof? A: Diagram, IaC, success+DLQ evidence, ADR, cleanup.

Deep dive: Example event envelope (illustrative schema — your contract)

json
{
  "source": "tlp.orders",
  "detail-type": "OrderReceived",
  "detail": {
    "orderId": "ord_123",
    "customerId": "cus_9",
    "sku": "COURSE-AWS-70",
    "amount": "199.00",
    "currency": "USD",
    "idempotencyKey": "idem_abc",
    "status": "RECEIVED"
  }
}

Treat field names as your application schema. EventBridge envelope field names must match current EventBridge documentation when you put events via the AWS API—verify Entries structure against the PutEvents API reference rather than inventing property names.

Deep dive: Accept-path latency budget

Break the accept path into API Gateway overhead, Lambda cold/warm start, DynamoDB write, and EventBridge put. Measure in your lab with CloudWatch duration metrics. Cold starts are a reliability and UX concern under concurrent spikes—mitigations include provisioned concurrency only when measured need justifies cost (confirm current feature behavior and pricing pages). Document the decision in ADR if you enable it.

Deep dive: Entitlement side effect

After CONFIRMED, a consumer should grant course access in TechLearningPro’s entitlement store (another table or existing user service). Keep that consumer idempotent: granting twice must not duplicate seats. Portfolio demos can stub entitlement as a DynamoDB update with a entitlementGranted flag.

Hands-On Exercises

Exercise: Order intake, processing, notification, and failure replay

Deliverable: Working serverless stack, two failure tests, ADRs, cost+cleanup, portfolio README.

Challenge ADR

Under a constrained budget, defer Step Functions and use EventBridge→SQS only; revisit orchestration ADR after traffic grows.

Lab evidence checklist

architecture diagram, IaC template, success POST evidence, DLQ+redrive evidence, unauthorized deny evidence, ADRs; budget/cleanup confirmation.

Narrative: A poison notification payload burned concurrency until DLQ+alarm and idempotent redrive restored calm during a flash sale

A poison notification payload burned concurrency until DLQ+alarm and idempotent redrive restored calm during a flash sale.

Continuity

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Deep dive: ADR template (TechLearningPro)

text
# ADR-NNNN: Title
Date:
Status: Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
Context:
Decision:
Consequences:
Evidence / links:

Deep dive: Portfolio README skeleton

text
TechLearningPro Project — Lesson 66
- Problem / NFRs
- Architecture (diagram + service rationale)
- Repo layout
- Deploy / destroy
- Security checklist
- Observability
- Failure tests
- Cost notes (illustrative; verify pricing)
- ADRs

Deep dive: Budget and tagging

Create or verify a budget with email/SNS subscriber before any apply. Tag Project=tlp-lesson66, Owner=<you>, Environment=lab. Screenshot Cost Explorer filtered by tag after destroy to prove idle cost returned near zero (allow for delayed billing).

Extended enterprise scenario: acquisition pressure

Leadership wants the lab promoted as “production-ready marketing copy.” Refuse without PRR evidence from lesson 63, WAR risks from lesson 58, and failure-test artifacts from this lesson.

Extended enterprise scenario: disputed decision

Two senior engineers disagree on the primary architecture choice. Run a timeboxed RFC, record ADR with revisit date, and keep the rejected alternative documented so interviews and audits see the trade-off—not silence.

Extended practice scenario 1 — 66 serverless event-driven order platform

Confirm AWS Budgets alerts exist for the sandbox; tag every resource Project=tlp-lesson66. Do not proceed without a budget subscriber.

In a timed drill for Serverless event-driven order platform at TechLearningPro, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: architecture diagram, IaC template, success POST evidence, DLQ+redrive evidence, unauthorized deny evidence, ADRs, and destroy confirmation for any lab resources.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating Serverless event-driven order platform as a mystery.

Extended practice scenario 2 — 66 serverless event-driven order platform

Document the lesson's primary architecture decision in a ten-line ADR: context, decision, status, consequences.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 3 — 66 serverless event-driven order platform

Map identity paths: who can create/modify the resources in this lesson; which IAM roles are least privilege.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 4 — 66 serverless event-driven order platform

Design observability: CloudWatch metrics/alarms or equivalent signals that prove the control works.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 5 — 66 serverless event-driven order platform

Run or design a negative test: denied access, misconfiguration, or failed dependency—capture evidence.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 6 — 66 serverless event-driven order platform

Estimate cost dimensions for this lesson's activities. Label figures illustrative; verify pricing pages with dates.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 7 — 66 serverless event-driven order platform

Produce a cleanup checklist and execute destroy for any billable lab resources created for lesson 66.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 8 — 66 serverless event-driven order platform

Cross-link prior course lessons that this design depends on; list two failure modes inherited from those layers.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 9 — 66 serverless event-driven order platform

Security review: encryption at rest/in transit, public exposure checks, CloudTrail visibility for management events.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 10 — 66 serverless event-driven order platform

Reliability review: failure injection, rollback path, how detection and recovery work.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 11 — 66 serverless event-driven order platform

Performance review: throughput, latency, or scaling limits relevant to Serverless event-driven order platform at TechLearningPro.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 12 — 66 serverless event-driven order platform

Write a runbook section for on-call: symptoms, first three diagnostic steps, escalation, rollback.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 13 — 66 serverless event-driven order platform

Config/compliance angle: which controls must be true before production promotion.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 14 — 66 serverless event-driven order platform

Multi-account consideration: how this workload sits in landing-zone OU boundaries from lessons 48–49 and 67.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 15 — 66 serverless event-driven order platform

Interview drill: explain Serverless event-driven order platform at TechLearningPro to a hiring manager in three minutes without inventing APIs.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 16 — 66 serverless event-driven order platform

Pair review: partner stops any invented CLI flags, hardcoded secrets, or fake current prices.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 17 — 66 serverless event-driven order platform

FinOps continuity from lesson 47: idle resources, data transfer, and when to decommission lab stacks.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 18 — 66 serverless event-driven order platform

DR continuity from lesson 45 and 68: recoverability must survive the change you are shipping.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 19 — 66 serverless event-driven order platform

Produce evidence pack: diagrams, configs, test results, cleanup proof.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 20 — 66 serverless event-driven order platform

Challenge constraint: tighter monthly budget—what do you sequence differently?

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 21 — 66 serverless event-driven order platform

Challenge constraint: stricter compliance—what evidence gates promotion?

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 22 — 66 serverless event-driven order platform

Challenge constraint: shorter maintenance window—what pre-staging changes?

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 23 — 66 serverless event-driven order platform

Teach-back: recite the Lesson Overview paragraph, then check against the text; flashcard gaps.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 24 — 66 serverless event-driven order platform

Dress rehearsal: tabletop under a timer with observer notes.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Extended practice scenario 25 — 66 serverless event-driven order platform

Final synthesis note: one paragraph connecting Serverless event-driven order platform at TechLearningPro to TechLearningPro production ownership.

Follows Project 2 containers (65) and precedes landing zone (67) and observability/DR (68).

Compliance evidence pack for auditors / platform leads

Budget configs, tagging proof (Project=tlp-lesson66), architecture diagram, ADR, negative-test evidence, encryption settings notes, CloudTrail/Config references where applicable, pricing-page retrieval dates for any dollar claims, cleanup confirmation.

Glossary drill

Review every bold term introduced in Detailed Core Concepts and Interview Q&A. Write one sentence definitions from memory; correct against the lesson. Unfamiliar AWS console navigation becomes a lab note, not a guess. Focus terms: idempotency key, DLQ, EventBridge rule, competing consumer, conditional write.

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers. I deleted or scheduled deletion for orphan lab resources from lesson 66 named ____. I labeled every savings or cost figure with pricing-page retrieval dates or marked it illustrative. Signed ________ date ________.

Interview story to memorize

Craft a 60-second story: TechLearningPro needed Serverless event-driven order platform; you chose a design with explicit trade-offs; you proved it with tests; you governed cost with budgets and tags; you left an ADR so the next engineer does not reverse the decision blindly. Emphasize async boundary and replay.

Self-assessment rubric

Area	Weight
Conceptual accuracy and service selection	20%
Working design/lab and reproducibility	25%
Security and least-privilege	20%
Reliability, observability, troubleshooting	20%
Documentation, ADR, cleanup	15%

Final synthesis before summary

Mastery of Serverless event-driven order platform at TechLearningPro is not logo recognition—it is owning failure modes, cost meters, identity boundaries, and the written decision that keeps TechLearningPro coherent under change.

Extended facilitation script (print for guild leads)

Open with lost orders during a sale. Ask where idempotency lives, how DLQ is triaged, and what destroy removes. Require ADR on EventBridge vs SQS. Close by assigning lesson 68 SLO ownership for accept latency and DLQ.

Lesson Summary

TechLearningPro’s serverless order platform accepts commands at API Gateway, records durable state in DynamoDB, and fans out work through EventBridge/SQS with DLQ replay—proving async boundaries, idempotency, least privilege, and destroyable IaC. Tag Project=tlp-lesson66.

Next: Project 4: Terraform Multi-Account Landing Zone.