You've really isolated the core trade-off well. The >forced concurrency purchase< is exactly what bit us. We had to buy a tier for our worst-case Monday morning rush, then watched those parallel jobs sit idle most of the week. The per-minute billing just fits reality better.
One thing to double-check on that CodeBuild config, though: you're showing a Linux compute type, but the Azure comparison uses `windows-latest`. For a fair cost comparison on the same workload, were you building a Java app that genuinely runs cross-platform? If there's a Windows dependency, switching to `BUILD_GENERAL1_MEDIUM` (Windows) will close that cost gap pretty fast. The Linux instance is a big part of that 25% edge.
Wow, a 25% cost difference is huge at that scale. Thanks for sharing the numbers, that's really helpful.
The per-minute vs. flat concurrency fee makes total sense. It's like paying for a full-time employee you don't always need vs. just hiring a contractor when the work comes in.
Quick question: were you guys already using AWS for other things? I'm wondering how much of a factor the existing EDP played, and if switching to Azure DevOps would mean missing out on that kind of volume discount.
>existing EDP played
That's the kicker right there. A lot of those eye-popping savings comparisons quietly assume you're already committed to a massive AWS spend. The EDP discount isn't magic - it's a contract that locks you in.
If you're not already spending six or seven figures on AWS, those per-minute CodeBuild rates look a lot different. Azure's flat fee can be simpler to budget, even with the waste. The real question is whether finance wants variable operational expense tied directly to dev activity, or a predictable line item.
show me the bill
Oh, the classic "same workload" assumption. You're comparing a Windows agent on Azure to a Linux compute type on AWS. For a finance team, I'd bet good money there's a .NET Core or full framework dependency in that `mvn clean package` that ties you to Windows. If you rerun that cost analysis on a `BUILD_GENERAL1_MEDIUM` Windows instance, that 25% gap evaporates, or might even flip.
Everyone gets dazzled by the per-minute billing until they realize their app isn't a portable Java service and they're locked into a specific OS. The real question is whether that 8.2-minute build actually *needs* that Windows image, or if it's just inertia.
FOSS advocate