Step Functions

Last updated: Nov 3, 2026

---

Rationale

Fluid Attacks uses Step Functions to orchestrate the execution of workflows in the cloud. Fluid Attacks chose Step Functions over other alternatives for these reasons:

• It is SaaS (software as a service). Thus, Fluid Attacks does not manage infrastructure directly.
• It is not expensive. Fluid Attacks pays only for the state transitions and the compute resources (for example, Lambda functions, EC2 instances, or Batch tasks) that execute the workflow steps.
• It complies with many certifications from ISO and CSA. Many of these certifications make sure that the entity uses best practices for secure cloud-based environments and information security.
• Fluid Attacks can monitor the workflow execution and the state transitions with CloudWatch.
• The workflows are highly resilient, with built-in error handling and retry mechanisms. This feature is very important when workflows orchestrate long processes that take many hours or days.
• It supports visual workflow design and shows the workflow execution visually. Thus, it is easier to understand and debug complex workflows.
• Fluid Attacks can write all its settings as code with Terraform.
• It supports parallel execution of workflow branches. Thus, Fluid Attacks can run many tasks at the same time and make the workflows faster.
• It supports conditional branching and dynamic routing. Thus, workflows can use complex logic that depends on data conditions.
• It supports automatic retries with configurable retry policies for temporary failures.
• It integrates with more than 200 AWS services, for example, Lambda, ECS, Batch, DynamoDB, SNS, and SQS.
• It integrates with Identity and Access Management (IAM). Thus, Fluid Attacks can apply least privilege to authentication and authorization.
• It keeps the execution history for a maximum of 90 days. Thus, Fluid Attacks can see the workflow execution and find the cause of problems more easily.

Alternatives

AWS Batch

Fluid Attacks uses Batch to run batch processing jobs. Batch is very good at the execution of individual jobs. But Step Functions is better at orchestration when Fluid Attacks must coordinate many steps, use complex branching logic, or integrate many AWS services in a workflow.

Fluid Attacks uses Step Functions instead of Batch for these needs:

• Orchestration of workflows that have more than one step with dependencies
• Conditional logic and dynamic routing
• Integration of many AWS services in one workflow
• Visual workflow representation and debugging

Fluid Attacks uses Batch instead of Step Functions for these needs:

• Execution of single, long batch processing jobs
• Compute resource management as the primary need, and not workflow orchestration

Apache Airflow

Apache Airflow is a popular open-source workflow orchestration platform.

Advantages:

• It is highly flexible and extensible.
• It has a large ecosystem of operators and integrations.
• It has strong community support.

Disadvantages:

• It requires infrastructure management and maintenance.
• Its setup and configuration are more complex.
• It needs more operational work.
• Its native integration with AWS services is less than that of Step Functions.

Temporal

Temporal is a modern workflow orchestration platform.

Advantages:

• It gives a very good developer experience with SDKs in many languages.
• It has strong support for long workflows.
• It has good observability and debugging tools.
• It can manage complex workflow patterns.

Disadvantages:

• It requires infrastructure management, unless the team uses Temporal Cloud, which is a paid service.
• Its native integration with AWS services is less.
• It is more difficult to learn for teams that do not know Temporal concepts.

Custom orchestration logic

Before Step Functions, Fluid Attacks used a custom orchestration method built with Python code, DynamoDB, and Batch. With this method, imperative Python code found the workflow steps, the team managed dependencies manually, and DynamoDB was the job queue.

Advantages:

• The team can write complex business logic directly in the code.
• Orchestration has no additional service costs (only DynamoDB and Batch costs).
• It works well with the current Python codebase and patterns.
• It integrates easily with the current data loaders and business logic.

Disadvantages:

• The workflow logic is imperative and in many parts of the code. Thus, it is more difficult to understand the full workflows.
• Workflows have no visual representation. Thus, debugging and onboarding are more difficult.
• Manual dependency management requires careful code maintenance.
• It is more difficult to understand complex workflows that have many steps.
• There are no built-in retry policies or error handling at the orchestration level.
• Workflow changes require code changes and deployments.
• The observability of the workflow execution state and history is limited.
• It is difficult to test the workflow logic in isolation.

Usage

Fluid Attacks uses Step Functions to orchestrate these workflows:

• Repository synchronization for the repositories of its clients. This includes cloning, post-processing, and vulnerability reporting.
• Scheduled workflows that EventBridge starts, for example, the cloning and SCA queue and the weekly Sorts pipeline.
• Scanner runs, Sifts runs, runs for each root, component analysis, and SBOM emails (state machines).