Documentation

AWS Batch

AWS Batch is the AWS managed batch-computing service that runs containerized jobs on EC2, Fargate, or EKS compute environments fronted by job queues. Polysync integrates with AWS Batch using the official AWS SDK for .NET v4 (AWSSDK.Batch and AWSSDK.SecurityToken). Polysync can list job definitions, submit jobs to a queue with parameter substitution, poll job status, cancel queued or running jobs, and surface a direct link to the AWS Batch console for monitoring.

Required attributes

  • Region — the AWS region in which the Batch compute environments, queues, and job definitions are deployed (e.g., us-east-1, eu-west-1). All Batch API calls are region-scoped.

Optional platform-level defaults

  • Default Job Queue — the name or ARN of the Batch job queue used when a job does not specify its own queue. Every SubmitJob call requires a queue, so this default avoids per-job configuration when all jobs target the same queue.

Authentication methods

  • Web Identity Federation ⭐ (recommended for Polysync SaaS) — Polysync exchanges its Microsoft Entra ID workload identity token for short-lived AWS credentials via sts:AssumeRoleWithWebIdentity. No long-lived secrets stored. Required attributes: Role ARN.
    • In AWS, create an IAM Identity Provider (OIDC) trusting Polysync's Entra ID issuer (https://login.microsoftonline.com/<polysync-tenant-id>/v2.0) with audience sts.amazonaws.com.
    • Create an IAM role whose trust policy allows sts:AssumeRoleWithWebIdentity from that provider with a condition on the Polysync workload identity's sub / oid claim.
  • Access Key — Provide Access Key Id, Secret Access Key, and optionally Session Token. Simplest, but the secret must be rotated and stored in a Secret Vault.
  • Assume Role — Provide a bootstrap Access Key Id and Secret Access Key, plus the Role ARN to assume. The bootstrap user only needs sts:AssumeRole on the target role; the assumed role holds the Batch permissions.
  • Instance Profile — Uses the host EC2/ECS instance profile. Only viable when Polysync is deployed inside AWS.

IAM permissions checklist

The role / user used by Polysync needs (at minimum):

  • batch:DescribeJobQueues — connectivity test and queue lookup.
  • batch:DescribeJobDefinitions — discover job definitions (Polysync filters by Status=ACTIVE).
  • batch:SubmitJob — submit jobs (scope to specific queue / definition ARNs in production).
  • batch:DescribeJobs — poll job status.
  • batch:TerminateJob — cancel queued or running jobs.
  • iam:PassRole (on the job definition's job role ARN, if one is declared) — required for Batch to launch containers under that role.

The job definition's own job role / execution role needs whatever permissions its container requires (S3, ECR pulls, CloudWatch Logs, etc.) — these are defined on the role attached to the job definition, not on the Polysync caller.

Supported jobs

  • AWS Batch Job — submits a job to a Batch queue with parameter substitution into the registered job definition.

Troubleshooting

  • Web Identity Federation InvalidIdentityToken — check that the IAM Identity Provider's thumbprint matches login.microsoftonline.com, the audience is sts.amazonaws.com, and the role trust policy allows the Polysync workload identity's sub / oid.
  • AccessDeniedException on listing job definitions — the caller is missing batch:DescribeJobDefinitions in the target region.

Scope notes

This provider integrates AWS Batch single jobs — submitting one Batch job definition per Polysync job. Multi-node parallel jobs and array jobs are supported transparently by AWS Batch itself (declared inside the job definition), but Polysync does not yet expose per-child status as first-class concepts; an array job appears as a single Polysync run whose status reflects the parent job's aggregate state.