When somebody’s cron job is your AWS orchestration strategy

Somewhere in your organization, there is a script. It runs on a cron schedule on an EC2 instance nobody remembers provisioning. It checks an SAP system every five minutes to see whether a job has finished, and when it has, it calls an AWS API to kick off whatever comes next. A contractor wrote it two years ago. It has never been in version control, nobody has reviewed it since and it breaks every time an upstream format changes.

That script exists because of a problem almost every enterprise running AWS has. It sits between the AWS boundary and everything on the other side of it. Multiply that script by every system boundary in your enterprise, and the scope of the problem comes into focus.

Hybrid is the architecture, not a phase

For a decade, the industry narrative said cloud consolidation was the destination and that on-premises systems, ERP estates and private infrastructure were transitional states waiting to be resolved. Reality settled somewhere else. 

Gartner forecasts that 90% of organizations will adopt a hybrid cloud approach through 2027. SAP contracts run for decades. Regulated workloads stay on-premises. AWS grows alongside those systems instead of replacing them.

Hybrid is simply the standard operating model of the modern enterprise. Few enterprises seriously considered going all-in on AWS. The real work has always been getting AWS to work alongside the SAP systems, on-premises infrastructure and other platforms already running the business. 

The building blocks aren’t the problem

AWS services are excellent at what they do. 

• Amazon EventBridge is an elegant way to route events between applications
• Amazon SQS has been reliable for nearly two decades
• Amazon ECS and AWS Fargate made container operations accessible to teams that had no interest in running Kubernetes 
• AWS Step Functions, AWS Lambda, Amazon Managed Workflows for Apache Airflow (MWAA) and Amazon Aurora are best-in-class building blocks for serverless orchestration and distributed applications, and enterprises are right to build on them

The problem starts the moment a workflow crosses the AWS boundary.

Think of an AWS Batch job that can’t start until an SAP financial close completes, or a goods receipt in SAP that should trigger downstream AWS processing in real time, or a data pipeline that begins with an on-premises extraction and ends in Snowflake. AWS-native orchestration tools like Step Functions and EventBridge Scheduler work well inside the boundary, using a state machine and the Amazon States Language to manage task state, wait states and retry logic across a workflow. But they can’t see an SAP job chain, enforce a dependency on an on-premises process or govern an end-to-end SLA that spans both worlds.

So enterprises bridge that boundary the only way they can: with custom scripts, scheduled polling, Lambda wrappers and manual coordination. A team writes one script to solve a specific handoff. Another team writes a different script for a different handoff six months later. None of it appears on an architecture diagram, and after a few years, the integration layer holding SAP and AWS together is really just a pile of undocumented cron jobs. 

The disconnect has a price tag

Deloitte’s 2026 Global Technology Leadership Study estimates that technical debt absorbs 21% to 40% of total IT spending, and the custom integration code accumulating at every system boundary adds to that figure with every new program. Flexera adds another dimension: 29% of cloud spend is wasted on idle or underutilized resources, often because nothing is orchestrating when infrastructure should be running.

The more visceral cost shows up at 9 AM on a Tuesday. A dashboard shows stale data. Was the failure in SAP? In the AWS pipeline? In the handoff between them? SAP logs live in one world, CloudWatch in another and the script connecting them logs to neither. Multiple teams are pulled in, and what should have been a five-minute diagnosis becomes an entire afternoon. Because the trigger was a polling schedule, the failure happened hours before anyone noticed.

Every new AWS service an enterprise adopts adds another boundary, another handoff, another script. The estate keeps growing. The distance between AWS and everything it depends on never closes.

A different model: An orchestration layer above the blocks

With orchestration, it’s a simple division of labor: AWS runs the cloud, and the orchestration layer runs the enterprise.

RunMyJobs by Redwood sits above the AWS execution tier. It doesn’t compete with EventBridge or Step Functions; it extends them to the systems they can’t reach. In this model, an SAP business event doesn’t wait for a polling window. RunMyJobs orchestrates the wider business service and publishes natively to EventBridge or populates application queues in SQS the moment the business event occurs, and the customer’s event-driven and serverless architecture takes it from there. 

A container task on ECS, a Batch job and an Airflow DAG on MWAA can also each become governed steps in a chain that started inside SAP and might end with Snowflake, Microsoft PowerBI, Box or ServiceNow, with one dependency map, one SLA policy and one audit trail across the whole thing.

This works because the integration is native at every layer of the AWS stack.

• The application layer: Connectors for EventBridge, SQS and SNS make orchestrated workflows first-class participants in event-driven architectures. They publish events, manage queues and fan out notifications using the same primitives AWS applications use to talk to each other.
• The compute layer: EC2, ECS and Fargate, Batch and Lambda run as governed execution steps, with IAM roles controlling exactly what each one is allowed to touch. Instances start and stop around workloads, containers run and are monitored to completion and exit codes propagate into the dependency chain.
• The data layer: S3, DataSync, Glue, AppFlow, MWAA and Amazon RDS govern the pipeline end to end. They ingest from on-premises and SaaS sources into a data lake or warehouse, trigger transformations, execute SQL and monitor Airflow DAGs as steps in a larger, governed whole.

Walking the chain: One retailer’s overnight run

Here’s what that looks like end to end.

Picture a retailer whose stores send the day’s transactions to SAP Customer Activity Repository overnight, where every cash register and every store is validated and audited. Merchandising needs those numbers on dashboards before the morning trade meeting.

The moment SAP confirms the data is complete, RunMyJobs publishes a “POS data ready” event to EventBridge, and every AWS application subscribed to it, from replenishment to store operations, knows instantly. There is no fixed 2 AM schedule and no guessing. In the same governed chain, RunMyJobs places a message on an SQS queue for each store’s dataset, and processing workers consume them at a pace downstream systems can handle. 

A containerized ECS task enriches the audited data. The operational reporting database on RDS is refreshed, started for the load and stopped when idle, because nobody should pay for a database running at 4 AM for no reason. An MWAA pipeline aggregates by store, region and product line. The final datasets land in Snowflake, and the dashboards are live before the meeting starts.

Seven services. One SAP system of record. One dependency chain. If a store’s data never arrives, the team knows right away, rather than when the merchandising director is staring at incomplete numbers.

Nothing in that chain required a polling script or custom middleware at the SAP-to-AWS boundary.

Every migration wave, the same problem

One group experiences this disconnect as an active, funded problem rather than chronic background pain: teams in the middle of a migration to AWS.

Migrations move in waves, sequenced by risk and dependency. Compute and databases typically lift and shift first, and workloads modernize onto containers, serverless and managed pipelines as each one is ready. Every wave that introduces a new AWS service also introduces a new dependency that the old on-premises scheduler can’t reach, which leaves teams with the same choice each time: stop the wave and rebuild the connection back to SAP and on-premises, or move on and leave it broken. Either way, the orchestration layer becomes the migration’s bottleneck rather than the workload move itself, and every custom script written to patch the boundary is more technical debt.

When every AWS service in the migration path already has a native connector, that choice disappears. Each wave goes live with its dependencies already governed. The migration stays on the timeline the business case promised, and the orchestration layer is the one thing that never needs to be re-evaluated at the next wave.

RunMyJobs will change your answer to all three. It’s the SaaS-native orchestration platform with native connectors across the AWS stack, deep SAP integration as the only SAP Endorsed App in workload automation and orchestration and a 99.95% uptime SLA. Every connector works without deploying infrastructure. Get a demo of RunMyJobs for AWS.