The per-vCPU arithmetic carries the argument. Fill all 64 vCPUs and that host works out at about 3.4 cents per vCPU-hour [1]. Run a single 2-vCPU job on it and you are paying $1.09 per vCPU-hour for the same machine, 32 times the packed rate [2]. Closing that gap is the packer's entire job [9], and it is also the size of the penalty when placement goes wrong.
The boot numbers push the same direction. A microVM comes up in under 200ms [5]; the EC2 host underneath it takes 30 to 60 seconds, which is 150 to 300 times longer [4]. Booting a host per job pays for the full 64 vCPUs on a 2-vCPU workload and eats that cold start as well [8]. The fast boot is therefore a property of warm hosts only [9], and a warm host bills about $52 a day, roughly $1,570 a month, empty or not [3]. A packer that regularly leaves hosts warm and idle is one instance per job with extra steps and a worse invoice.
Firecracker's own contract is narrow. Three things per microVM: the binary, a kernel image, and a rootfs carrying the job's tools [18]. That rootfs has to be on the worker's own filesystem before Firecracker will hand it over, arriving from S3 at boot or pre-baked into the AMI [10], and every microVM that boots takes a private copy of it so concurrent VMs do not collide on writes [11]. Placement computed from CPU and memory [17] does not see those copies, and it does not see the S3 pull a fresh worker performs at boot [12]. Both bind hardest during exactly the burst the packer exists to absorb.
What the post reports going wrong is consistent with that. Its author lists a surprise AWS bill and a bug in his own code that was working against itself [14], without saying in this excerpt what either was. Those sit in the layer he wrote: the queue, the placement decision, the rootfs distribution.
The assumption underneath the design is the part worth watching. Firecracker needs direct KVM access, and the build assumed a .metal instance is the only way to get it on AWS [6]. AWS has since added a NestedVirtualization CPU option to c8i, m8i, r8i and their flex variants, with no bare metal host required [15]. If that exposes a KVM device Firecracker can use cleanly, the author writes, you could keep smaller and cheaper instances warm instead [16]. The post does not show that tested. Until someone tests it, the fixed hourly floor that justifies bin packing rests on a constraint AWS has already published a way around, and the case for microVMs over the Kubernetes pods that ARC already packs [13] comes down to whether a per-job kernel and disk [3] is worth a scheduler you maintain yourself.
