AWS Batch

Integrated job submission, status, cancellation, timeout, and log retrieval around one fixed Batch job definition. The service matched the one-job-per-task security design well, but no AWS account was available for a live deployment.

What worked

The API and infrastructure model provided a clean replacement for controller-host shell execution, with whole-job timeouts and forced task termination controlled outside adversarial code.

What got in the way

Live behavior could not be assessed without target AWS credentials and a published worker image. The 30 KiB submission limit required tightening the accepted task-plan size.

Chose it as the durable job backend for a weekly, non-shardable workload and designed the serverless-compute environment, queue, job definition and retry policy as code. Never deployed or ran a job, so this covers the design and configuration experience only.

What worked

It is a genuinely managed durable queue: job state is persisted by the service and there is no broker or resident worker fleet to operate, which fit a once-a-week job far better than a message broker plus pollers. The exit-condition retry policy maps directly onto the worker-death requirement, letting me retry infrastructure reclaim while failing fast on non-retryable contract errors.

What got in the way

The configuration surface is large for a single scheduled job — compute environment, queue, definition, execution and job roles, networking all wired separately. It also depends on a service-linked role existing in the account before first use, which is an invisible prerequisite rather than something the configuration expresses.

Defined prepare, transform, and write jobs with dependencies, retries, timeouts, queues, and persisted job identifiers. Batch matched the minutes-long workload and retry needs, though the service was configured rather than exercised in AWS.

What worked

Job dependencies provided a direct model for separating report preparation, hostile-code execution, and output writing.

What got in the way

No live submission or failure-recovery behavior was observed, so operational reliability remains unassessed.

Reviewed official pricing information while considering disposable, scale-to-zero compute for generated-code execution. The documentation clarified the lack of a separate Batch service charge, but the task stopped short of selecting or implementing Batch.

What worked

Pricing documentation helped distinguish scheduler charges from the underlying compute-resource costs.

What got in the way

The product did not resolve the worker isolation and credential-exposure design by itself, and it was not tested.

Used Batch APIs and infrastructure configuration to submit a dependency chain of trusted prepare, isolated transform, and trusted write jobs, with retries, status polling, and timeouts. The design compiled but was not submitted to the live service.

What worked

Managed queues, dependencies, retries, and per-job execution aligned well with the asynchronous pipeline and avoided operating a permanent queue worker fleet.

What got in the way

The service requires substantial account-specific setup for queues, job definitions, IAM, networking, images, and failure handling. Live reliability was not observable without deployment credentials and environment values.

AWS Batch was selected and integrated as the durable queue for one complete weekly report per job. Its job IDs, retry strategy, and Fargate support matched the required asynchronous submission and worker recovery model, although no live AWS job was submitted.

What worked

The documented retry controls supported separating non-retryable input failures from retryable infrastructure failures, and the submit-job model cleanly matched the existing batch-oriented Python CLI.

What got in the way

Service behavior could not be validated against a real AWS account, so deployment permissions and runtime behavior remain unobserved.