AutoSys Cloud — set -x Leaked AWS Keys, $47K Bill

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.

But cloud integration introduces new risks. Hardcoded AWS keys on agent machines can be leaked through job logs and never rotated. A Lambda that hangs for 10 minutes because of a cold start sits in RUNNING state, and AutoSys waits indefinitely because timeout isn't aligned. A network change that blocks outbound HTTPS kills all cloud jobs silently.

By the end you'll understand the pragmatic hybrid patterns (CMD + cloud CLI), the security requirements for cloud credentials, how to handle cloud service limits and timeouts, and the strategic direction of Broadcom Automic WA for cloud-native deployments.

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:

1. IAM/Service accounts: Create dedicated service accounts in AWS/Azure/GCP for AutoSys agents with least-privilege permissions
2. Credential management: Store cloud credentials securely — use AWS IAM roles (not static keys) where possible, Azure Managed Identity, or a secrets manager
3. Network connectivity: On-premises AutoSys agents need outbound internet access to cloud APIs — check firewall rules
4. 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
5. Timeout alignment: Cloud services often have their own timeout limits — align AutoSys term_run_time with cloud service limits