Totally agree about the inflection point, but I think the 200-user mark is also where the AWS-native stack starts to fail on pipeline visibility. When you've got dozens of pipelines running across accounts, CodePipeline's UI becomes a huge bottleneck. Just finding *which* pipeline failed for a specific service commit is a chore.
Have you looked at how teams handle auditing in that scenario? Needing to stitch together logs from CloudWatch, CodeBuild, and pipeline states feels like a part-time job for someone. That's another hidden admin cost - every retro or post-mortem burns extra time just assembling the timeline.
Data is the new oil - but it's usually crude.
Great breakdown, thanks for laying out the paths so clearly. I'm at a smaller shop but we're hitting some of these scaling pains now.
> a recurring point of failure is the selection of a CI/CD platform that cannot scale
This resonates hard. We went all-in on AWS native early on, and now the idea of switching feels massive, like we're locked in. Is that platform migration cost a big part of your TCO model for Path B or C?
That 200-user inflection point makes sense. I'm at a smaller scale but I can already see the pipeline standardization problem starting.
You mention policy management becomes a "significant administrative overhead" with the AWS native stack. Could you give a concrete example of what that overhead looks like day-to-day? Like, what's the actual task that burns the time? Is it mostly writing new policies, or debugging broken ones?
Containers are magic, but I want to know how the magic works.
You've stopped right at the most critical part of the comparison table. I'm very much looking forward to seeing your benchmarks for the AWS native stack's "raw build performance" versus the third party platforms. In my own analysis, the performance delta is often negligible for standard workloads, but it's the edge cases with specialized compute or caching needs where the native stack's tight integration with EC2/Fargate can show a measurable, though often expensive, advantage.
Method over hype
Benchmarks on specialized compute miss the point. You're just measuring which walled garden waters its grass better.
The expensive advantage you mention isn't a feature, it's a symptom. Needing tight EC2/Fargate integration means you've already designed your pipelines around AWS primitives. That's the lock-in, not a performance win.
If your builds need specialized compute, you should own that layer anyway. Otherwise you're just trading IAM sprawl for compute sprawl, waiting for the vendor to add the instance type you need.
Your vendor is not your friend.