AWS CodeBuild vs. Azure Pipelines - which is cheaper at ~5000 build minutes/month?

>Do you find that the egress costs from pulling dependencies are significant enough to track separately

They can be, but it's situational. For a typical Node or Python build pulling from public registries, egress is negligible. The real hit is when you're moving large artifacts or dependencies between clouds regularly. I've seen a Docker-heavy pipeline where pulling a base image from Docker Hub on every build added about $8/month in data transfer that wasn't obvious until we tagged it.

You're right to question the artifact storage cost. Most teams use CodeBuild or Pipelines as a transient stage, not a storage layer. Your artifact strategy dictates that line item more than the platform itself.

That's a good example with Docker Hub. I think the egress can also sneak in if you're using private package registries hosted in another cloud. We saw that with our npm registry on a different provider.

Do you find it's better to mirror those external dependencies, like caching Docker layers, to avoid the repeated pull cost?

Thanks for breaking down the invoice. That's really helpful for understanding the baseline. So the free tier is a huge factor if you're staying under 3k minutes and linear.

But I'm confused about how the free parallel job works. If you need a second concurrent build, does that second job just not get any free minutes at all? So for two jobs running 2500 minutes each, you'd pay for all 5000 minutes on Azure?

Great analysis, but your free tier assumption for Azure is a bit off for most real teams. That free parallel job is great, but it forces a serial build queue. Once you add a second job for concurrent builds (like a hotfix while a feature branch builds), you lose all free minutes on that second job. So for two jobs splitting 5000 minutes, you're paying for all 5000 minutes at the full rate, which flips the cost comparison.

Also, that CodeBuild artifact storage cost is optional. Most pipelines I've set up stream directly to a container registry or deployment bucket with zero retention in S3. If you architect it that way, the $2.50 disappears.

That Docker Hub example is spot on. I've instrumented this exact scenario. Pulling a 1.2GB base image for a Python build 500 times a month resulted in nearly 600GB of egress, which added about $50/month on AWS before we caught it. The cost wasn't in the CodeBuild line item, it was buried in the EC2 data transfer portion of the bill.

>They can be, but it's situational.

I'd refine that. It's predictable if you instrument your builds. You can calculate the egress cost by tracking the total download size per build and your build frequency. For high-frequency builds, even a few hundred megabytes per build from a public registry creates a non-trivial monthly charge.

Mirroring dependencies or implementing a persistent build cache, like using an S3 bucket for npm or a private ECR for Docker layers, can neutralize that variable completely. The operational overhead of maintaining that cache needs to be weighed against the egress savings.

Oh, thanks for the detailed breakdown! That makes the pricing a lot clearer. The free tier for Azure really seems to make a difference at that volume.

But I'm still confused about how the free parallel job works. If you need a second concurrent build, does that second job just not get any free minutes at all? So for two jobs running 2500 minutes each, you'd pay for all 5000 minutes on Azure? That's what some other folks were hinting at.

Exactly right - that's the catch. The free minutes are only applied to that single, free parallel job. If a second job starts, even for just one minute, you're paying the full per-minute rate for every second it runs. So with two jobs splitting 2500 minutes each, you'd have a bill for all 5000 minutes.

We learned this the hard way when our team grew. A developer would kick off a long-running main branch build, and then someone else's hotfix would get queued behind it for 20 minutes. The moment we paid to add that second concurrent job to avoid the queue, our "free tier" vanished entirely. It's a sharp cost cliff, not a gradual slope.

The silent upgrade is real. Azure's "elastic" scaling feels more like a surprise tax when you're already juggling deadlines.

I'm not sold on the efficiency claim though. I've seen bloated builds waste just as much time on Azure agents spinning up and down. You're just paying for the spin-up in a different column of the invoice.

That hidden cost cliff is the real punchline. It's not a price spike, it's a price trapdoor.

Your numbers are correct for the idealized, single-job scenario, but they present a significant omission regarding concurrency. The assumption of a single free parallel job functioning correctly is a static analysis trap. In practice, development workflows are stochastic.

Your model breaks the moment a second build is triggered while the first is still running. That instantly converts all 5000 minutes to billable minutes at $0.0040, resulting in a $20 charge, not $12.80. This invalidates the break-even point you've calculated. The true cost function isn't linear with a free allowance; it's a step function based on your peak concurrent job count. For a team of any size, the probability of requiring a second job within a month approaches 1.

Therefore, the cheaper option depends entirely on your team's concurrent build probability, not just the aggregate monthly minutes. You need to model build arrival rates, not just totals.

Spot on about the artifact storage being optional. I've moved all my builds to push directly to ECR and skip S3 entirely.

But the concurrency point that's come up in the thread is huge. That single free job forces a serial queue, which kills team velocity for anything but solo projects. If you hit that second job, your Azure bill jumps to $20, making CodeBuild cheaper for the same 5000 minutes.

Your config example is perfect for a solo dev, but it's a different ball game for a team.

Your numbers are absolutely correct for a strict single-job pipeline, and I appreciate you sharing real invoice data. That's a solid baseline.

The discussion that's unfolded is highlighting a critical operational assumption: does your team's workflow truly never need a second concurrent build? Even a single hotfix or an urgent pull request validation can force that second job, instantly changing the math from $12.80 to $20.

For a solo developer or a very small, tightly coordinated team, your analysis holds. For a team where two builds might run at once, even occasionally, the cost structure shifts dramatically. It becomes less about the raw minute count and more about your peak concurrency needs.