Most FinOps teams have a solid handle on the usual levers - rightsizing instances and buying reservations, maybe finally shutting down that staging environment from two quarters ago. That playbook works. But if you've already run it and your compute bill still feels higher than it should, it's worth asking a different question: not what your workloads run on, but how they run.

Data pipelines that restart from scratch every time a late step fails. Worker fleets sized for worst-case load and left running around the clock, even when demand drops off a cliff overnight. This is workflow execution waste - compute spend driven by how inefficiently work executes rather than by the underlying infrastructure itself. It doesn't get its own line item on your bill, and it doesn't trigger anomaly alerts. It just sits inside your existing compute costs, looking normal.

Where Workflow Execution Waste Shows Up on Your Cloud Bill

To put some numbers on it: say your team runs a fleet of 10 always-on worker containers (c5.xlarge at $0.17/hr each) to process background jobs. That fleet costs about $1,240/month. But if most of those jobs only need a fraction of that capacity for a fraction of the day, the actual required compute might be closer to 4 containers plus some burst capacity - roughly $500/month. That's $740/month in waste, and it's workflow execution waste specifically - the fleet is oversized because the workflows have no way to scale with actual demand or right-size per step. Multiply that across three or four teams and you're looking at real money.

The same pattern plays out with retries. An ETL pipeline that takes 30 minutes on a c5.2xlarge ($0.34/hr) and fails at the final step doesn't just cost you the failed run - it costs you the full re-run from scratch. At two failures a week across 20 pipelines, that's around $140/month in wasted compute just on redundant retries. Add in duplicate job executions from overlapping cron triggers or webhook retries, and you're looking at another $50-100/month that isn't being tracked.

Here's what that looks like in aggregate for a mid-size team:

Estimated monthly workflow waste for a team running background jobs on AWS EC2.

On a yearly basis, that's nearly $11,600 from a single mid-size team. For larger enterprises running dozens of pipeline fleets across multiple business units, multiply accordingly - it's not unusual for this kind of waste to reach six figures annually. And the frustrating part is that none of it triggers cost anomaly alerts because it's not anomalous. It's the steady-state baseline. You have to go looking for it.

How to Audit Your Workflow Costs

Before recommending any tooling changes, it's worth understanding where you stand. We've seen teams skip this step and jump straight to evaluating orchestration tools - which is like buying a new car because your current one has a flat tire. Here's a practical way to scope the problem.

1. Identify your pipeline compute. In AWS Cost Explorer, filter by the services backing your batch and pipeline workloads - typically EC2, ECS, Lambda, or Fargate. Tag-based filtering helps here: if your pipelines are tagged by team or application, isolate that spend. What you're looking for is always-on compute tied to workloads that don't actually run 24/7 - that gap between "always running" and "always needed" is where workflow execution waste lives.

2. Check failure and retry rates. Most monitoring tools already track this - check CloudWatch or Datadog, or look at your queue system's built-in dashboard (Sidekiq and Celery both surface job failure counts). What you want to know isn't just how often jobs fail, but what happens when they do. Do they resume from the point of failure or restart from scratch? Most queue-based systems restart from scratch by default. If a pipeline takes 30 minutes and fails at minute 25, that's 25 minutes of compute thrown away on every failure.

3. Check for duplicate executions. If jobs are triggered by webhooks or cron schedules, there's a good chance some are running more than once. Look at job queue metrics for runs with identical inputs or overlapping timestamps. Most queue systems don't surface this unless you go looking for it.

4. Compare resource allocation across pipeline steps. If every step in a multi-step pipeline runs on the same instance type, you're almost certainly over-provisioned for at least some of them. Step one might need 512MB of memory; step three might need 8GB. If everything runs on the 8GB box, that's wasted capacity on every step except the most demanding one.

Even a quick pass through these four areas usually turns something up.

Reducing Workflow Costs Without New Tools

Not every optimization requires adopting a new platform. These are all things you can bring to your engineering team that don't require new infrastructure.

Add step-level checkpointing. Instead of restarting a pipeline from scratch on failure, save intermediate results to S3 or a database after each step. When a job fails, it picks up from the last checkpoint instead of re-running everything. This is the single highest-impact change for teams with failure-prone pipelines.

Implement deduplication at the queue level. If you're on AWS, SQS FIFO queues have built-in deduplication using message deduplication IDs. For other queue systems, adding an idempotency key check before processing a job (e.g., checking a database or Redis for whether a job ID has already been handled) prevents duplicate work.

Right-size workers per job type. Rather than running one uniform worker fleet, separate your workloads by resource profile. Memory-intensive jobs get one pool, lightweight jobs get another. On ECS or Kubernetes, this can be as simple as defining different task definitions or pod resource requests per job type.

Autoscale your worker fleet. If your pipeline workers run 24/7 but your workloads are heaviest during business hours, use autoscaling policies to scale down overnight and on weekends. Even scaling from 10 workers to 3 during off-peak hours saves roughly 50% on that fleet's monthly cost.

For most teams, this covers the majority of workflow waste without a migration or new vendor. And because each one has a direct cost justification, they're usually an easy sell in an engineering review.

When to Consider Orchestration Tools

If those fixes only get you partway there - or your pipeline complexity has outgrown what manual checkpointing and autoscaling can handle - dedicated orchestration tools are worth a look. They handle retry and deduplication out of the box, and they let you size each step independently - which means less custom code and fewer places for cost to leak. Two that come up most often:

Temporal

Temporal is a workflow orchestration engine built around durable execution. If a workflow fails mid-way through, it picks up exactly where it left off - not from the beginning. Here's a simplified workflow in TypeScript:

import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

const { fetchOrders, validateInventory, processPayment } = proxyActivities<typeof activities>({
  startToCloseTimeout: '5m',
  retry: { maximumAttempts: 3, backoffCoefficient: 2 },
});

export async function orderFulfillmentWorkflow(orderId: string): Promise<void> {
  const orders = await fetchOrders(orderId);
  const validated = await validateInventory(orders);
  await processPayment(validated);
}

If processPayment fails, Temporal retries just that step. The prior steps don't re-run - their results are already stored. That's the durable execution model, and it's what eliminates the full-pipeline retry waste we talked about earlier. Temporal also handles deduplication natively through Workflow IDs, so the same job can't accidentally execute twice. Temporal Cloud is priced on Actions and Storage - a new line item, but one that typically replaces compute spend that was costing more.

AWS Step Functions

If you're already on AWS, Step Functions gives you orchestration without managing separate infrastructure. You define a state machine, wire it to Lambda functions or ECS tasks, and pay per state transition - $0.025 per 1,000 transitions for Standard Workflows. Here's what the configuration looks like:

{
  "StartAt": "ResizeImage",
  "States": {
    "ResizeImage": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789:function:resize",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2 }],
      "Next": "RunModeration"
    },
    "RunModeration": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789:function:moderate",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2 }],
      "End": true
    }
  }
}

Each step runs on its own Lambda function with independent memory and timeout settings, so you're not over-provisioning across the board. For high-volume short-lived workloads, Step Functions Express Workflows are particularly cost-effective. The tradeoff is that you're locked into the AWS ecosystem, and the state machine JSON can feel clunky for complex logic compared to writing code directly in Temporal.

Wrapping Up

Workflow execution waste is the kind of cloud spend that hides in plain sight - it shows up as EC2 or Lambda costs, not as a line item you can filter for. But the patterns behind it are fixable, whether that means adding checkpointing to what you already have or adopting something like Temporal or Step Functions. Once you start pulling on this thread, the savings tend to stack up.

For tracking these costs alongside the rest of your infrastructure, Vantage supports both Temporal and AWS natively - so you can see workflow spend without digging through raw billing data.