AWS Batch Compute Environment
Does ZopNight manage AWS Batch Compute Environment?
AWS Batch adds no charge of its own; the meter is the EC2, Spot, or Fargate capacity its compute environments provision to run jobs. Oversized or always-on environments bill while queues sit empty. ZopNight discovers Batch on the 6-hour cycle and attributes its cost through the underlying compute from Cost Explorer or CUR 2.0.
Rules that fire on AWS Batch Compute Environment
No active rule family targets AWS Batch Compute Environment today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
AWS Batch runs containerized batch computing workloads on managed compute environments. Cost comes from the EC2 or Fargate capacity the environment provisions, so oversized or always-on compute environments inflate spend even when queues are empty.
The service is free; the environment is not
Batch itself carries no meter: no per-job fee, no orchestration charge. Everything bills through the compute environment: managed environments launch EC2 instances (on-demand or Spot) or Fargate tasks to work the queues, and those resources bill at their normal rates for as long as they exist. The critical setting is the environment’s minimum vCPU count. At zero, capacity scales away when queues drain and the idle cost is nothing; above zero, the environment keeps that many vCPUs of instances running permanently, converting a burst service into a standing fleet.
Attribution through the compute layer
ZopNight discovers Batch on the 6-hour cycle and attributes its cost through the underlying capacity from Cost Explorer or CUR 2.0, folding it into the same idle and rightsizing analysis as directly run compute. That framing matches how Batch waste actually appears: not as a Batch line item but as EC2 instances with sawtooth utilization, or a floor of always-running capacity whose tag trail leads back to a compute environment’s minimum setting. Scheduling is not applied at the Batch layer. The environment’s own scaling settings are the control.
Queue-side habits that cost compute
Minimum vCPUs set above zero “to keep jobs starting fast” is the standing leak. Instance-type lists narrowed to a single large type force big instances for small jobs, stranding unused capacity inside each host. All-on-demand environments run work that would tolerate Spot at a fraction of the price, batch workloads being the canonical Spot use case. And abandoned queues keep their environments alive: no jobs for months, but the environment and its minimum capacity persist.
Checking environments and minimums
The Batch console’s Compute environments view shows each environment’s type, instance configuration, and vCPU minimum, maximum, and desired. Minimum above zero plus an empty job queue is the finding; confirming with the linked Auto Scaling group or Fargate usage closes the loop.