ECS Finally Learns to Schedule a Slice of a GPU

In July 2025, AWS started renting GPUs by the slice: G6f instances carve a single NVIDIA L4 into halves, quarters, and eighths, each sold as an ordinary EC2 instance. The catch, if you ran containers: Amazon ECS couldn't schedule onto them. Task definitions only accepted whole-number GPU counts, and the ECS agent on a G6f box would detect the GPU's UUID and then report zero schedulable GPUs. re:Post threads document people hitting exactly this wall, and as recently as this January users reported that ECS Managed Instances couldn't select g6f types at all.

That gap just closed. ECS task definitions now accept decimal GPU values — 0.125, 0.25, or 0.5 — and the scheduler places those tasks on G6f instances exposing the matching slice. It works with ECS Managed Instances and ECS on EC2. A schema change this small shouldn't have taken a year, but it's here, and it makes ECS a legitimate place to run small-model inference. It also deserves a closer look than the announcement gives it, because "fractional GPU scheduling" is doing subtler work than the phrase suggests.

What shipped, exactly

The mechanics are one line in a container definition:

"resourceRequirements": [
  { "type": "GPU", "value": "0.25" }
]

Decimal and integer values are separate namespaces. Integer requests place only on full-GPU instances (g5, g6, and friends); decimals place only on the G6f size with the corresponding partition. You can mix both families in a single capacity provider and ECS routes each task by its declared value, so you no longer need a capacity provider per GPU family. One constraint to know before you design around it: only one container per task may request a fractional GPU, and no other container in that task can request GPU at all.

The slice sizes are fixed per instance type:

Three gigabytes comfortably holds embedding and reranker models; 6 GB fits a 4-bit-quantized 7B model with room for a modest KV cache; 12 GB handles roughly an 8B model at FP8, or Stable Diffusion XL. Fargate and ECS Anywhere are excluded — and Fargate still has no GPU support of any kind, which remains the loudest silence in AWS's container lineup.

The slicing happens below the scheduler

Here's the part worth internalizing: ECS is not dividing a GPU among your containers. EC2 already divided the physical card among instances — each G6f instance is a fixed slice, carved at the hypervisor with NVIDIA's vGPU stack (these instances require the GRID driver, which Managed Instances pre-installs). ECS just learned to match a decimal request to the right instance size. Your task gets the entire slice of its instance; there's no oversubscription and no bin-packing two 0.125 tasks onto a quarter-slice box.

That places this design in a specific spot on the isolation spectrum. It's stronger than Kubernetes-style time-slicing via the NVIDIA device plugin, where replicas share everything and one container's memory allocation can kill its neighbor. It's weaker than MIG, which fences off SMs and memory bandwidth in silicon — and which the L4 doesn't support at all. With vGPU, each slice gets a hard framebuffer allocation, while compute is apportioned by NVIDIA's virtual GPU manager in the hypervisor. AWS describes the slices as having dedicated memory and compute; read the memory claim as a hard boundary and the compute claim as a scheduler guarantee. Other tenants on the same physical card can't touch your 3 GB, but expect somewhat more p99 variance than a dedicated card gives you. Fine for most interactive inference; benchmark before you put a tight latency SLA on it.

Compare the do-it-yourself version on EKS: device-plugin time-slicing or MPS if you accept soft isolation, MIG if you're on A100/H100-class hardware, and Dynamic Resource Allocation — stable since Kubernetes 1.34 — as the emerging clean answer. ECS's version is far less flexible: three sizes, one card family, no oversubscription knob. But it's zero-assembly, and for a service whose whole pitch is predictability, refusing to oversubscribe is the right call.

Do the pricing math before you slice

The economics are where the announcement's framing needs an asterisk. On-demand list prices in us-east-1: a g6f.xlarge (1/8 of an L4, 4 vCPUs, 16 GiB) runs about $0.24/hour against $0.80 for a g6.xlarge with identical CPU and RAM and the whole 24 GB card. An eighth of the GPU for 30% of the price — good deal if the eighth is all you need.

But the discount curve is sublinear. The quarter slice costs about 48% of its full-card sibling ($0.47 vs. $0.98 at 2xlarge size), and the half slice about 72% ($0.95 vs. $1.32 at 4xlarge). Follow that to its awkward conclusion: a g6f.4xlarge — half an L4, 12 GB — costs more per hour than a g6.xlarge with the entire card. If your model needs 12 GB and your CPU needs are modest, the full GPU is the cheaper option. The half slice only earns its price when you need its 16 vCPUs and 64 GiB of RAM alongside.

Same logic at the other end: eight eighth-slices cost roughly $1.90/hour versus $0.80 for the whole card (granted, with 8x the CPU and RAM attached). Fractional GPUs win against the over-provisioned status quo — the embedding service idling at 5% utilization on a card it can't fill. They lose against consolidation: if you can multiplex several small models in one serving process on a full card, say with Triton's concurrent model execution, you'll get better throughput per dollar than any arrangement of slices. What you're buying with fractions is isolation, independent scaling, and per-service deploys — not cheaper FLOPs.

Where this leaves ECS

This is a real fix, not hype, and the shape of the winner is specific: teams already on ECS running a handful of small models — embedders, rerankers, quantized chat models — who've been paying full-card prices for single-digit utilization because that was the only isolation on offer. For them, adoption is a one-line task-definition change plus G6f types in the capacity provider, and the eighth and quarter slices genuinely cut the bill. Paired with Managed Instances — which pre-installs drivers, monitors GPU health, and cut its G-series management fees 35% in July — ECS now has a credible small-inference story that doesn't require adopting Kubernetes.

Throughput-focused inference shops should shrug and keep batching on full cards. And anyone hoping this was a step toward GPU Fargate should note that the serverless tier stayed conspicuously out of the announcement. The interesting decision here isn't the decimal point in the schema — it's AWS betting that GPU sharing belongs in the hypervisor, not the container scheduler. That keeps the operational model honest. Just check whether the slice you want is actually cheaper than the card.