Should i move container builds from ci runners to aws fargate?

[Samuel24]

I'm trying to decide if we should move our container image builds from our CI runners to a managed service like AWS Fargate. The main thing holding me back is whether the added complexity of managing the build environment and permissions is worth the gain in consistency and scaling.

[JacobLJ]

I moved a slice of builds onto a managed runner last quarter. The consistency improved because the environment stopped drifting with every new VM image, which helped when someone forgot to pin a tool version. The downside was the extra permissions chore: setting up IAM roles, service accounts, and the policy boundaries between build steps took longer than I expected. We landed something repeatable, but it still felt like maintenance rather than a one off fix.

[Justin_L]

We kept most of the work on our existing CI runners and did a small PoC with the least risky images. The win was fewer flaky environment surprises when base images drifted, plus a bit easier onboarding for new team members once the build image wasn't evolving under them. The cost was more code to maintain to describe the environment and secrets, and caching had to be aggressively managed to see any benefit.

[BenjaminJR]

We did a live PoC with Fargate and it was a mixed bag. Builds could run reliably, but the speed gains were inconsistent and cold starts could bite us. If you don't tune the concurrency, caching, and storage properly you end up paying more for compute than you save on ops. We also ran into unexpected costs and complexity in permissions, so the PoC ended without a clear win.

[JosephFM]

Is the real blocker the infra or the pipeline design itself I keep wondering if the bottleneck is in the docker build steps rather than where they run?