AWS 148: AWS Step Functions
Why this lesson matters
Coordinate tasks with explicit state, retries, catches, timeouts, parallelism, maps, callbacks, execution history, and Standard or Express workflow trade-offs.
What you will be able to do
By the end, you can:
- explain aws step functions 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-identityprivately. 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 is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- 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
| Question | What it means in this lesson |
|---|---|
| Purpose | Coordinate tasks with explicit state, retries, catches, timeouts, parallelism, maps, callbacks, execution history, and Standard or Express workflow trade-offs. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for AWS Step Functions. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Step Functions. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid hiding a simple one-step call in a workflow or retrying non-idempotent payment work without compensation. |
How the request flows
+----------------------+
| Start execution |
+----------------------+
|
v
+------------------------+
| State and transition |
+------------------------+
|
v
+--------------------------------+
| AWS service or activity task |
+--------------------------------+
|
v
+--------------------------------------------+
| History, catch, compensation, and result |
+--------------------------------------------+For AWS Step Functions, 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 AWS Step Functions. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for AWS Step Functions. 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
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Step Functions when visible durable orchestration, branching, waiting, human callbacks, or service integrations reduce custom coordination code. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid hiding a simple one-step call in a workflow or retrying non-idempotent payment work without compensation. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Workflow types and state semantics
Standard Workflows fit durable, auditable, potentially long-running orchestrations with exactly-once workflow execution semantics except where service integration behavior requires idempotency; execution history is retained according to service behavior. Express Workflows fit high-rate, short-duration flows, use at-least-once asynchronous execution (or at-most-once synchronous semantics), and rely heavily on logs for history. Confirm current duration, history, logging, pricing and integration support rather than mixing the types.
Amazon States Language defines Task, Pass, Choice, Wait, Succeed, Fail, Parallel and Map states. JSONPath or JSONata selection/transformation controls input/output; careless payload growth can exceed limits or leak secrets. Distributed Map processes large S3-backed data sets with separate child executions and concurrency controls; Inline Map shares parent-history constraints. Direct AWS SDK/optimized service integrations often remove unnecessary Lambda functions.
Each Task needs a timeout. Retry matches named errors with interval, backoff, maximum attempts and optional jitter/current options; Catch transitions after retries and should preserve error plus original business context. Retrying validation errors wastes transitions. Retrying payment after an ambiguous timeout can double-charge unless the provider uses the same idempotency key. A saga records completed steps and applies semantic compensation in reverse where possible; compensation is a business action, not database rollback.
Request/response waits for an API result; .sync waits for supported job completion; callback with task token pauses until an authorized worker returns success/failure. Tokens are secrets and need heartbeat/timeout. Execution role permissions should be generated/reviewed per integrated resource. Starting an execution needs caller permission; activities/callback callers have separate permissions. Encrypt/log carefully because workflow input, output and history can contain sensitive data.
Definition versions and aliases support controlled workflow releases where currently supported. A running Standard execution generally continues its started definition; aliases route new starts. Correlation requires execution ARN/name, state-entered timestamps, service request IDs, X-Ray/logs and downstream business IDs. Avoid execution-name collisions and ensure redrive/restart does not repeat side effects.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open Step Functions, State machines and Executions; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- 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 listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws stepfunctions list-state-machines --query 'stateMachines[].{Name:name,Type:type,Arn:stateMachineArn}' --output table
aws stepfunctions list-executions --state-machine-arn replace-with-state-machine-arn --max-results 10 --output tableExpected interpretation
Execution status and history explain orchestration steps. They do not prove downstream business correctness unless task outputs and side effects are validated.
Practical work
Model order validation, payment, inventory, notification, and compensation. Add timeouts, retryable errors, non-retryable errors, idempotency, parallel work, catch paths, and final business status.
Produce ASL plus a state-transition table. Compare Standard, Express and Lambda durable functions. Test validation failure, transient throttle, payment timeout after commit, inventory rejection requiring compensation, callback expiry, one Parallel branch failure, Map partial failure, payload-limit avoidance and alias rollback. Estimate Standard transitions versus Express duration/request/logging and downstream costs.
Diagnose this topic from its own evidence
Use execution event history from the first failed state: input after transformation, resource ARN/integration pattern, error/cause, retry count and timeout/heartbeat. States.Timeout, States.TaskFailed, permissions, path/query evaluation and payload-size failures have different repairs. A workflow marked succeeded can still encode a failed business result if Catch routes carelessly; validate final business state. Never restart an ambiguous payment execution until its idempotency record/provider result is reconciled.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Coordinate tasks with explicit state, retries, catches, timeouts, parallelism, maps, callbacks, execution history, and Standard or Express workflow trade-offs.
- 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 AWS Step Functions.
- 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 AWS Step Functions.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid hiding a simple one-step call in a workflow or retrying non-idempotent payment work without compensation.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner selects Standard/Express from guarantees and limits, uses native states/integrations, bounds every wait/task/retry, preserves input/error context, and designs idempotent saga compensation. Evidence must include definition/version rollback, permissions, observability, eight failure tests and cost. Fail if retries are universal, Catch converts failure to false success, task tokens leak, or orchestration history is mistaken for downstream correctness.