Bitbucket Pipelines vs GitLab CI for a 15-eng team on AWS

I'm a tech lead at a 45-person SaaS company, and we've been running GitLab CI on AWS ECS with Fargate for about three years across three engineering teams.

* **True Cost Structure**: GitLab Premium ($29/user/month) includes 10,000 CI minutes per month, and its compute is your problem too, but it's predictable. Bitbucket's "free" 500 minutes quickly becomes hundreds in AWS compute charges for builds, which we saw hit $600-800/month for a team your size. GitLab's bundled minutes meant our bill was just the subscription.
* **Configuration and Vendor Lock-in**: Bitbucket Pipelines uses a proprietary YAML with unique directives like `runs-on` and `size`. Migrating away means rewriting those sections. GitLab CI uses a more conventional `.gitlab-ci.yml` that's closer to industry standards, making a future move to something like GitHub Actions less painful.
* **Runner Management and Scaling**: Bitbucket forces you to manage your own AWS infra for scaling, which is extra devops overhead. GitLab's shared runners just work for most jobs, and when you need custom runners, their Helm chart for Kubernetes is far more polished than anything for Bitbucket's runners. We set up a GitLab runner autoscaler on our EKS cluster in an afternoon.
* **Built-in Tooling and Security**: For a 15-person team, GitLab's built-in container scanning, SAST, and dependency scanning (even in Premium) eliminated three separate SaaS tools we were paying for with Bitbucket. The security dashboard alone saved us 20-30 engineering hours a month on compliance prep.

I'd pick GitLab CI for your team if you value predictable costs and want integrated security tools. If your workloads are extremely bursty and you're committed to deep AWS cost-optimization with Spot instances, Bitbucket could be cheaper, but you need to tell us your average monthly build minutes and whether you have dedicated devops for runner tuning.

Clever trap is right, but that buried AWS bill isn't a bug, it's a feature. It's how they keep the headline price low.

The real question is if you were monitoring your compute tags and right-sizing your runners. I've seen teams get wrecked by that because they just used the default `2x` runner without checking if their build even needed it. Your config shows the `size: 2x` directive, which is the most expensive option. Did you ever profile to see if a `1x` or even the default would have sufficed?

That's the opaque part. The cost is in your AWS bill, but the performance tuning is locked in their proprietary YAML. You can't optimize what you don't own.

Yep, the 3 AM bill shock is real. Your config snippet is a perfect example, because that `size: 2x` directive is the silent killer. It spins up a way bigger EC2 instance than most builds need, but you only find out when the bill comes.

Been there, burned that midnight oil. We got bitten because the default "free" minutes made us lazy about profiling our builds. Turns out most of our node_modules installs didn't need 8GB of RAM, they just needed a cache. By the time we realized, the cost was sunk into our AWS bill with no easy way to attribute it back.

GitLab's minutes are on their tab, which forces a different kind of cost discipline. It's not just about the dollars, it's about the mental overhead of tracking down which pipeline run ate your budget.

Your point about the opaque AWS bill is dead on, but that's a failure of ops, not the tool. You're blaming Bitbucket for your own cloud cost management blindspot.

The config you posted is a red flag. You're using `size: 2x` by default, which is like renting a dump truck to move a couch. Did you even try profiling your build with the default runner or `size: 1x`? The vendor provides the knobs, but you turned the most expensive one and left it there.

I ran a test on a similar pipeline last month. Switching from `2x` to the default runner added 90 seconds to the build, but cut the EC2 cost per run by 65%. That's not a hidden cost, that's an unmonitored one. The bill is in your AWS console, tagged and traceable.

Your sticker shock came from not looking at it.

Ouch, that 3 AM bill shock is rough, and you're right about the cost attribution being a headache. Your config snippet highlights something else tricky though: those vendor-specific pipes, like `atlassian/aws-ecr-push-image`.

Even if you right-size the runner, you're still locked into their ecosystem for the actual steps. Migrating that logic to a plain shell script or a more portable method adds more rewrite work later. GitLab's approach with standard `script:` blocks feels a bit more portable when you inevitably need to tweak something.

So you've discovered that your cloud bill is the real CI/CD tool, cleverly disguised as infrastructure. The "mental overhead" you mention is the crux of it, but shifting that overhead to GitLab's minute-counting doesn't make it vanish, it just changes the flavor.

You're right that cost attribution in your AWS bill is a pain, but GitLab's bundled minutes create a different kind of opacity. Now your cost discipline is about rationing a pooled resource you don't directly see or control, which leads to teams gaming the system, like cramming builds into shared runners or skipping longer integration tests to conserve "minutes." At least with the AWS bill, you can set up Cost Explorer and tags to trace it back, however painfully.

The real 3 AM shock with GitLab comes when you hit that 10k minute wall and your builds queue for hours because nobody wants to approve the overage charge. Both models punish inattention, just on different schedules.

Spot on about the 3 AM shock just shifting from AWS billing to pipeline queues. That minute wall is real pressure. Been in a shop where teams started merging half-baked code to avoid "wasting minutes" on re-runs.

What's tricky is, even with Cost Explorer and tags, untangling shared AWS costs between teams is its own political nightmare. At least GitLab's minute quota forces a conversation about prioritization early, even if it's painful.

Both models need you to own the discipline, either in your cloud account or in your dev workflow. There's no free lunch, just different menus.

Yep, that `size: 2x` is the default for a lot of their example pipelines. It got us too until I set up a Prometheus/Grafana dashboard scraping our AWS billing data and tagged every runner. Turns out 80% of our builds were memory-bound, not CPU-bound, so the `2x` was just burning money.

The bigger trap you didn't mention is image pulls from ECR. Every single pipeline step does a fresh pull, and at scale, that data transfer cost adds up fast. Your config uses their ECR pipe, which is convenient, but each run is hitting ECR API calls and pulling layers. That's another line item buried in the AWS bill.

You can mitigate it with a local Docker registry proxy on a persistent runner, but then you're managing infrastructure, which defeats the "managed" promise.

Great callout on the image pull costs, that's a real silent budget eater. Setting up a Prometheus dashboard for AWS billing is next-level ops, kudos for that.

You're absolutely right about the local registry proxy defeating the managed promise. We tried that middle ground with a small, persistent EC2 instance running a registry mirror, but then you're on the hook for its uptime, patching, and scaling. It saved maybe 15% on data transfer, but traded it for on-call alerts when the proxy died.

The real kicker with ECR pulls in Bitbucket is that even if you use their cache directive, it's often a layer cache, not a full image cache. So you're still pulling the base layers every time unless you get creative with self-hosted runners. Have you seen any decent workarounds that don't just recreate GitLab's runner architecture?

>Your sticker shock came from not looking at it.

True, but defaulting to the most expensive knob is a vendor choice, not a user one. The cognitive load of profiling every pipeline for cost is real, especially for a 15-person team trying to ship. That's the trap: convenience at a premium.

The 90-second trade-off you found is key. Most teams won't discover that until after the bill hits. They set `size: 2x` because it's in the tutorial and the build feels snappy. The vendor gets a performance win, you get the hidden tax.