The AWS workloads RunMyJobs doesn’t know about yet

I’ve spent nearly three decades working with Redwood Software customers on the jobs, schedulers, scripts and workflows that run large enterprises. What used to be scheduler environments are now hybrid automation estates spanning cloud services, enterprise applications, data platforms and on-premises systems. No two look the same, but the pattern is familiar.

If you already trust RunMyJobs by Redwood with your mission-critical work, you have a foundation many teams are still trying to build. Maybe RunMyJobs runs your SAP processes. Maybe it coordinates your finance workflows, overnight dependencies or reporting chains. Whatever the mix, your most important work already runs through a reliable, governed orchestration layer. The opportunity before you now is to extend that model to the workflows still operating outside it.

In many estates I see, AWS workloads arrive through a different path. For example, a Lambda function solves a specific problem. An AWS Glue job becomes part of a data pipeline. An Amazon S3 bucket turns into a handoff point. A Step Functions workflow grows from a team-level solution into part of a larger business process. Nobody plans these parallel automation models on a whiteboard. They accumulate as practical answers to real needs. 

Those AWS services belong in your estate, but the question is whether they should still be operating outside the orchestration model you already trust.

The edges of your coverage

When I talk with customers about AWS, I usually start with a simple exercise: draw the edge of your current RunMyJobs coverage. Not the whole architecture, nor every service inventory — and not the ideal future state. Just the practical boundary between the workflows RunMyJobs already governs and the ones that still operate elsewhere.

That boundary is revealing.

On one side, you have the processes that already inherit the RunMyJobs operating model: dependency logic, calendars, role-based access, approvals, audit history and service-level visibility. On the other side are the workflows that have grown up around AWS, data platforms or SaaS applications on their own timelines. They’re usually perfectly reasonable workflows, but they’re running on a fixed schedule, polling script, local trigger or point integration. Hence, orchestration sprawl happens unintentionally.

I see this most often around processes that cross boundaries: AWS into SAP, AWS into an on-premises application, AWS into a data platform, etc. Each environment has its own logs and controls, but the business process doesn’t stop to respect those boundaries. Hidden risk lives right there.

The next best candidate for moving to RunMyJobs is the workflow that works most days, until it doesn’t.

What’s running on trust?

Look first for workflows that still depend on:

• Fixed schedules that assume upstream work finished on time
• Polling scripts that check whether a file, job or message is ready
• Manual handoffs between AWS and non-AWS systems
• Data pipelines where every technical step can succeed, while the business result is late or stale

Those are examples of the AWS workloads RunMyJobs may not know about yet. Some may look small, but if they connect to a business process, they carry operational weight. If they still rely on informal coordination, they carry costs, too.

A bill nobody can quite explain

The cost conversation often starts in AWS, with an instance running longer than expected, a development environment staying up or a batch host waiting most of the day for a few hours of work. FinOps teams can usually identify those patterns. The harder question is what depends on them. No one wants to stop the instance that might still be holding up month-end close or retire the polling script no one fully owns.

That’s why cost optimization is often blocked by uncertainty, not lack of visibility into the bill. When more AWS and hybrid workflows are managed through RunMyJobs, you can see how work starts, waits, runs and completes across the full process. That turns cost from something your team can explain into something your team can act on.

2 versions of the same workflow

AWS-native services are strong building blocks. Step Functions, EventBridge, Lambda, Glue, Managed Workflows for Apache Airflow (MWAA) and other AWS services help teams build scalable, event-driven processes inside AWS. They should keep doing that work.

But what happens when the business process crosses the AWS boundary?

Curious whether a specific AWS service is already covered? See the full list of AWS connectors RunMyJobs supports today.  

The part AI can’t do for you

I get asked about AI in this context more often now: “We’re already putting AI agents on this, so does it matter that some of it still runs outside RunMyJobs?” My answer goes something like: an agent deciding what should happen is not the same as the work safely getting done.

An agent may recommend restarting a failed step, refreshing a data pipeline, triggering a reforecast or escalating an approval. But that action still has to move through the same governed, auditable business processes you already operate. If a workflow sits outside RunMyJobs today, AI doesn’t make it safer by touching it. The handoff still needs ownership, access control, dependency context and an audit trail.

So, coverage matters here too. With capabilities like Model Context Protocol (MCP) support, RunMyJobs can expose existing workflows to AI agents through governed access, rather than giving agents raw access to production systems. Your production workflows remain controlled, governed and scoped to the same permissions and process logic you already trust.