g6f.4xlarge, half an L4, 12 GB of GPU memory, runs about $0.95 an hour on-demand in us-east-1. A full 24 GB L4 on g6.xlarge is about $0.80. So the "fractional" half-card costs more than the whole card. That comparison, pulled from Vantage's EC2 pages the week Amazon announced fractional GPU scheduling for ECS, is the part I keep coming back to. On August 6, an ECS task can ask for GPU=0.125, 0.25, or 0.5 and land on a matching G6f size. Smallest slice: one-eighth of an L4, roughly 3 GB, for embeddings and other jobs that have been wasting a whole accelerator overnight.
Scheduler sugar on pre-cut G6f sizes
ECS is not carving a live card the way Nvidia MIG does inside Kubernetes. G6f instances were already pre-partitioned L4 hardware. Nitro does the split at the instance boundary. August 6 just lets the task definition say "I need a fraction" and have the scheduler pick the size instead of an operator typing an instance type. Works on ECS Managed Instances and ECS on EC2. Managed Instances also get GPU metrics in Container Insights and automatic replacement when health checks smell a dead GPU. That last bit, replace the sick GPU without a human paging into the cluster at 2 a.m., is the kind of operational detail that survives longer than the launch blog post.
g6f.large and g6f.xlarge are both one-eighth L4 / 3 GB, xlarge just brings more CPU and RAM. G6f.2xlarge: quarter card, 6 GB. G6f.4xlarge: half, 12 GB. No full 24 GB L4 in the G6f line. That lives on regular G6 starting at g6.xlarge. GPU=0.5 means a half-card G6f machine, not half of a full-card box you already own. A lot of secondary coverage blurred that. If your mental model was "MIG but for ECS," rewrite it: this is instance-size selection with nicer task-definition syntax.
Small-model inference, embeddings, light rendering, those are the workloads AWS keeps naming. Fair. They're also the workloads people have been overprovisioning for two years because the scheduler wouldn't let them ask for less than a whole accelerator. The feature closes that gap on ECS. It does not invent a new chip.
Absolute dollars versus the fraction fantasy
us-east-1 on-demand, again via Vantage: g6f.large ~$0.20 for 3 GB, g6f.xlarge ~$0.24 for the same GPU with more CPU, g6f.2xlarge $0.475 for 6 GB, g6f.4xlarge $0.95 for 12 GB, g6.xlarge ~$0.80 for 24 GB. Need 12 GB? The half-card fractional size is the wrong buy on price alone. Eighth and quarter sizes still cut the absolute hourly bill versus parking a full card under a 2 GB job, that part is real when the alternative was an idle L4 humming all night. They do not give you 8× or 4× cheaper GPU the way the fraction labels imply. Per gigabyte, every G6f size currently looks dearer than a full g6.xlarge.
I ran the napkin math twice because the half-versus-full comparison felt like a typo the first time. It wasn't. Marketing can say "fractional GPU". Finance will say "why are we paying more for less memory." Both sentences can appear in the same Slack thread next month.
Spot and Savings Plans move the absolute numbers. Unless your region's card looks wildly different from Virginia, the relative pattern holds. Price against the G6f/G6 list, not against "0.125" printed in the task JSON. The August 6 note also skimps on what happens when a container blows past the fraction it requested. OOM? Throttle? Noisy neighbor on a sibling partition? I'd find that out in a staging cluster before production teaches you. Coverage is thin here, and I'm not going to invent a failure mode AWS didn't document.
Same two weeks: three quiet EKS fixes
July 22: EKS Auto Mode and Karpenter got native EFA and placement-group config, so distributed training shops can set interconnect and placement from the node pool instead of bolting it on. July 27: PrivateLink for the cluster OIDC/JWKS endpoint IRSA depends on, eksctl, Terraform, custom validators inside a VPC with no internet egress. July 28: HPA sync concurrency on Provisioned Control Plane clusters up to ~40× the default Kubernetes value, no config flip required. AWS says that last one only bites when you run hundreds or thousands of HPA objects.
None of it is keynote candy. All of it squeezes more work out of accelerators AWS already sells. AWS does not ship frontier models the way Google and Microsoft do. The pitch is cheaper, less brittle hosting of other people's workloads. Fractional ECS fits that thesis. So does the fragmentation tax: ECS now has G6f fractions, EKS still leans on device plugins / MIG / time-slicing with DRA maturing separately, SageMaker has its own multi-model story. No clean bridge. Pick an orchestrator for unrelated reasons and your GPU path gets chosen for you, a coordination cost that shows up in engineering time, not on the GPU line item.
I sat with a platform team last month that had standardized on EKS for everything else and was still hand-picking G-family sizes for a handful of embedding jobs. Fractional ECS would have been nicer for them on paper. On paper they also weren't about to re-platform those jobs onto ECS for a scheduler convenience. That conversation is going to repeat across a lot of AWS accounts.
G6f-only, by the way, no retroactive magic for G4/G5/G6 fleets. Available where G6f is, which is not "everywhere." Confirm capacity in your region before you design a fleet around eighth-cards. MIG and time-slicing have existed on Kubernetes for years. GKE already does time-sharing and MIG. Shipping the scheduler version on ECS first just got Amazon to market faster. Whether GPU-heavy teams still standardize on EKS and leave this for shops already married to plain ECS is an open bet. I'd wait on the rate card either way, and I'd still price the half-card against a full g6.xlarge before anyone celebrates a fraction.
Who this is actually for
Shops already on ECS with lots of small inference jobs: this is for you, if G6f exists in your regions and your staging tests don't explode when a container exceeds its slice. Shops standardized on EKS with MIG already working: nice to know AWS cares about GPU density, probably not a migration trigger. Everyone else reading "fractional GPU" on a headline and updating a budget spreadsheet without opening Vantage: please open Vantage. The half-card versus full-card comparison alone is worth the click.
I'll be curious whether AWS eventually flattens the per-GB weirdness on G6f or just lets buyers discover it. Until then, the feature is real, the scheduler sugar is real, and the unit economics are a homework assignment. Bring a calculator to the homework, preferably before the first G6f invoice lands.
- Kubernetes
- Edge Computing
