AutoSys Cloud Workload Automation — Scheduling in the Cloud Era
- AutoSys can orchestrate cloud workloads via CMD jobs with cloud CLIs, native cloud job types, or the newer Automic WA platform
- Hybrid orchestration (on-prem + cloud) is the most common current pattern — AutoSys as the central control plane
- Use IAM roles and managed identities rather than static credentials for cloud integrations
Enterprise batch environments don't exist purely on-premises anymore. Data pipelines increasingly span AWS S3, Azure Data Factory, GCP BigQuery, and containerised workloads. Broadcom has evolved AutoSys to handle these cloud and hybrid scenarios under the Broadcom Automic Workload Automation (AWA) umbrella, while maintaining backward compatibility with traditional AutoSys environments.
This article covers what cloud integration actually looks like in practice for AutoSys shops making the hybrid transition.
Hybrid orchestration — the most common pattern
Most enterprises don't go fully cloud overnight. The most common pattern is hybrid: on-premises AutoSys jobs orchestrate a mix of traditional server-based jobs and cloud jobs. AutoSys acts as the central control plane for the entire workflow regardless of where each step actually executes.
/* Step 1: On-premises extract (traditional CMD job) */ insert_job: PRD_HYBRID_EXTRACT_DB job_type: CMD command: /scripts/extract_to_s3.sh machine: onprem-server-01 owner: batchuser condition: success(PRD_EOD_SETTLE_BOX) alarm_if_fail: 1 /* Step 2: Trigger AWS Lambda function via CLI */ insert_job: PRD_HYBRID_AWS_TRANSFORM job_type: CMD command: "aws lambda invoke --function-name transform-pipeline --payload '{\"date\":\"$(date +%Y%m%d)\"}' /tmp/lambda_response.json" machine: onprem-server-01 /* runs AWS CLI from on-prem server */ owner: awsbatch condition: success(PRD_HYBRID_EXTRACT_DB) alarm_if_fail: 1 /* Step 3: Wait for cloud processing and load to on-prem data warehouse */ insert_job: PRD_HYBRID_DW_LOAD job_type: CMD command: /scripts/load_from_s3.sh machine: dw-server-01 owner: batchuser condition: success(PRD_HYBRID_AWS_TRANSFORM) alarm_if_fail: 1
Broadcom Automic WA — the native cloud evolution
Broadcom's strategic direction is Automic Workload Automation (AWA), which extends AutoSys capabilities with: - Native cloud job types for AWS, Azure, and GCP resources - Container orchestration (Kubernetes, Docker) - RESTful API integration for triggering any cloud service - Modern web UI replacing the older WCC interface
If you're starting a new AutoSys-compatible deployment in 2026, Automic WA is worth evaluating alongside traditional AutoSys.
# Automic WA concepts equivalent to AutoSys: # AutoSys 'job' → Automic 'task' # AutoSys 'box' → Automic 'workflow' # AutoSys 'JIL' → Automic 'XML/YAML definitions' # AutoSys 'WCC' → Automic 'AWI (Automation Engine Web Interface)' # Many enterprises run both side-by-side during migration # AutoSys handles legacy on-prem jobs # Automic handles new cloud-native workloads # Both are orchestrated from a unified control plane
Practical cloud integration checklist
If you're extending your AutoSys environment to include cloud workloads, work through this checklist:
- IAM/Service accounts: Create dedicated service accounts in AWS/Azure/GCP for AutoSys agents with least-privilege permissions
- Credential management: Store cloud credentials securely — use AWS IAM roles (not static keys) where possible, Azure Managed Identity, or a secrets manager
- Network connectivity: On-premises AutoSys agents need outbound internet access to cloud APIs — check firewall rules
- Logging: Cloud-invoked jobs may log to cloud-native services (CloudWatch, Azure Monitor) — ensure stdout/stderr are also captured locally for AutoSys error log viewing
- Timeout alignment: Cloud services often have their own timeout limits — align AutoSys term_run_time with cloud service limits
| Cloud integration method | Complexity | Best for |
|---|---|---|
| CMD + cloud CLI (aws/az/gcloud) | Low | Simple cloud triggers, pragmatic approach |
| AutoSys native cloud job types | Medium | Deeper cloud integration with status monitoring |
| Broadcom Automic WA | High (new platform) | New cloud-native deployments, container workloads |
| REST API calls from CMD job | Low-Medium | Triggering any cloud service with an API endpoint |
🎯 Key Takeaways
- AutoSys can orchestrate cloud workloads via CMD jobs with cloud CLIs, native cloud job types, or the newer Automic WA platform
- Hybrid orchestration (on-prem + cloud) is the most common current pattern — AutoSys as the central control plane
- Use IAM roles and managed identities rather than static credentials for cloud integrations
- Broadcom Automic WA is the strategic evolution of AutoSys for cloud-native workloads
⚠ Common Mistakes to Avoid
- ✕Using static AWS access keys on agent machines instead of IAM roles — security risk and key rotation nightmare
- ✕Not setting term_run_time on cloud-triggered jobs — cloud API calls can hang if the cloud service is unresponsive
- ✕Logging cloud job output only to cloud-native logging (CloudWatch) and not capturing it locally — makes AutoSys error investigation harder
- ✕Not accounting for cloud region latency and service limits when setting AutoSys scheduling times
Interview Questions on This Topic
- QHow does AutoSys handle cloud workloads?
- QWhat is the difference between traditional AutoSys and Broadcom Automic WA?
- QHow would you trigger an AWS Lambda function from AutoSys?
- QWhat security considerations are important when AutoSys agents call cloud services?
- QHow do you handle a scenario where your batch workflow spans both on-premises and cloud systems?
Frequently Asked Questions
Can AutoSys run cloud workloads?
Yes. AutoSys can trigger cloud workloads through CMD jobs that invoke cloud CLI tools (aws, az, gcloud), through native cloud job types in newer AutoSys versions, or via the Broadcom Automic WA platform for deeper cloud-native integration.
What is Broadcom Automic WA?
Automic Workload Automation (AWA) is Broadcom's next-generation workload automation platform that extends traditional AutoSys capabilities with native cloud job types, container orchestration, and RESTful API integration. It's the strategic direction for new deployments while traditional AutoSys remains supported for existing environments.
How do I trigger an AWS Lambda from AutoSys?
The simplest approach: create a CMD job that runs the AWS CLI. Install the AWS CLI on the agent machine, configure IAM credentials or a role, and use aws lambda invoke --function-name your-function as the command. Capture the response file with std_out_file.
What cloud credentials should AutoSys agents use?
Use the least-privilege principle. For AWS, prefer IAM roles assigned to EC2 instances over static access keys. For Azure, use Managed Identities. For GCP, use Service Accounts with minimal permissions. Avoid storing long-lived static credentials on agent machines.
Does AutoSys work in a fully cloud environment?
Yes, but it requires agents deployed on cloud infrastructure (EC2, Azure VMs, GCE instances) or the use of Broadcom Automic WA which is cloud-native. Traditional AutoSys with cloud-deployed agents is a common pattern for enterprises lifting-and-shifting their batch environments to cloud.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.