Migrá tu CI/CD de GitLab a AWS en 12 horas
Migrar CI/CD de GitLab a AWS CodeBuild no es algo que uno planifique con calma: en el caso de Brian Becker, VP de Software Engineering en Flower Shop Network, fue una decisión forzada cuando GitLab agotó los minutos gratuitos a mitad de un deploy en mayo de 2026. En 12 horas, con ayuda de Claude, el pipeline completo estaba corriendo en AWS sin interrumpir el equipo.
En 30 segundos
- GitLab CI agotó los 400 minutos gratuitos en producción: el escalón mínimo para continuar era $120/año, el siguiente $348.
- La migración a AWS CodeBuild incluyó IAM, Secrets Manager, CodeConnections, ECR mirrors para el rate limit de Docker Hub y un fallback con buildx en arm64.
- Tiempo total: 12 horas desde decisión hasta build verde en AWS.
- El ahorro no es solo plata: con CodeBuild pagás por minuto de build, sin mínimos fijos ni seats.
- Los errores más caros en este tipo de migración son permisos IAM mal configurados y no tener un fallback activo durante la transición.
Claude es un asistente de inteligencia artificial desarrollado por Anthropic, basado en un modelo de lenguaje grande diseñado para asistir en programación, análisis de código y tareas de desarrollo de software. Fue entrenado con técnicas de aprendizaje reforzado con retroalimentación humana (RLHF).
Por qué migrar CI/CD de GitLab a AWS en 2026
AWS CodeBuild es un servicio gestionado de integración continua que compila código fuente, ejecuta tests y produce artefactos, cobrando por minuto de build en lugar de por seat o plan mensual. GitLab CI, en cambio, incluye CI/CD como parte de su plataforma SaaS con un tier gratuito de 400 minutos por mes y planes que arrancan en $120/año para uso básico, según precios vigentes en mayo de 2026.
El problema concreto que describe Brian Becker en dev.to es un clásico: los 400 minutos gratuitos se agotaron a mitad de un deploy. La solución obvia era topear con $10, pero GitLab no ofrece esa opción con claridad. El camino más corto era un plan de $120/año, y si necesitabas más control, el siguiente paso era Premium a $348 prepago para un solo seat. No es una cifra enorme, pero el modelo de precios no encajaba con el tamaño y la lógica del equipo.
Ahí aparece AWS CodeBuild como alternativa. Pagás por lo que usás, sin mínimos fijos, y se integra directo con el ecosistema AWS que probablemente ya estés usando para despliegue.
Diferencias clave entre GitLab CI y AWS CodeBuild
La diferencia más práctica está en el modelo mental, no en las features. GitLab CI asume que tu código vive en GitLab y tu pipeline es parte de esa plataforma. CodeBuild asume que vos armás la integración: conectás tu repo (GitHub, Bitbucket, CodeCommit o lo que uses), definís el buildspec.yml y configurás los permisos IAM vos mismo.
| Característica | GitLab CI | AWS CodeBuild |
|---|---|---|
| Modelo de precios | Por seat o plan (desde $120/año) | Pay-per-use ($0.005/min en x86 small, mayo 2026) |
| Configuración | .gitlab-ci.yml | buildspec.yml |
| Integración con repos externos | Limitada en tier gratuito | GitHub, Bitbucket, CodeCommit |
| Secrets | GitLab CI Variables | AWS Secrets Manager / Parameter Store |
| Registry de imágenes | GitLab Container Registry | Amazon ECR |
| Escalado | Shared runners (gratuito) o self-hosted | Automático, sin configuración |
| Curva de aprendizaje | Baja si ya usás GitLab | Media-alta si no conocés AWS IAM |
Lo que gana CodeBuild en flexibilidad lo pierde en fricción inicial. IAM es el filtro más duro: si no definís bien los permisos, el build ni arranca.
Análisis de costo: ¿cuánto pagás realmente?
Tomemos un equipo mediano: 50 desarrolladores, 200 builds por día, promedio de 10 minutos por build. Son 2.000 minutos diarios, 60.000 minutos al mes. En comparación entre Jenkins y GitHub Actions profundizamos sobre esto.
| Plataforma | Costo estimado/mes (mayo 2026) | Modelo |
|---|---|---|
| GitLab Premium | ~$1.200 | $29/user/mes × 50 developers |
| GitHub Actions | ~$480-$4.800 | 2.000 min gratuitos + $0.008/min extra |
| CircleCI | ~$1.800 | Plan Performance según créditos |
| AWS CodeBuild (x86 small) | ~$300-$600 | $0.005/min × 60.000 min |
Los números de CodeBuild varían según el tipo de instancia y la región, pero para builds estándar en Linux el costo suele estar muy por debajo de las alternativas SaaS con precios fijos. Los valores mostrados son cotización vigente a mayo de 2026 y pueden variar según cambios en las políticas de precios de cada proveedor. El catch: necesitás sumar el tiempo de configuración y eventual soporte, que no es gratis.
Pasos para migrar tu pipeline
El proceso tiene partes técnicas y partes de gestión. Las técnicas son más predecibles. La gestión del equipo durante el corte es donde suelen aparecer los problemas.
1. Análisis del .gitlab-ci.yml actual
Antes de tocar nada en AWS, documentá tu pipeline completo: stages, variables de entorno, secrets, artefactos que genera, imágenes base que usa. GitLab CI tiene algunas features que no tienen equivalente directo en CodeBuild (environments, review apps, merge train). Si las usás, necesitás un plan alternativo.
2. Configurar AWS CodeBuild con buildspec.yml
El buildspec.yml divide el proceso en fases. Una configuración típica con Docker y ECR según la documentación oficial de AWS tiene esta estructura:
- pre_build: login en ECR con
aws ecr get-login-password, definición de variables comoAWS_ACCOUNT_IDeIMAGE_REPO_NAME - build: construcción de imagen con
docker build, tagging - post_build: push a ECR, notificaciones opcionales
Los secrets que antes vivían en GitLab CI Variables van a AWS Secrets Manager. CodeBuild puede leerlos directamente en el buildspec con secrets-manager en la sección env. (Spoiler: si no configurás esto bien antes del primer run, el build va a fallar de forma poco descriptiva.)
3. CodeConnections para conectar tu repo
AWS CodeConnections (antes CodeStar Connections) es el puente entre CodeBuild y repositorios externos. Si tu código está en GitHub o Bitbucket, esta es la pieza que permite que un push dispare el build. La configuración requiere autorizar la conexión desde la consola de AWS, que abre un flujo OAuth con el proveedor del repo.
4. ECR mirrors para el rate limit de Docker Hub
Docker Hub tiene un rate limit de 100 pulls anónimos por 6 horas o 200 autenticado en el plan gratuito. En un pipeline de CI con 200 builds diarios ese límite lo alcanzás en minutos. La solución que usó el equipo de Flower Shop Network: mirrors de imágenes base en ECR. Una vez que las imágenes están cacheadas en tu propio registry de AWS, el rate limit de Docker Hub deja de ser un problema. Relacionado: herramientas de IA para automatización.
5. Testing en paralelo antes del corte
Correr ambos pipelines en paralelo durante uno o dos días es la manera más segura de validar. GitLab CI sigue activo como fuente de verdad; CodeBuild corre en paralelo y vos comparás los resultados. Cuando CodeBuild da verde consistentemente, hacés el cutover.
El timeline en el caso de Flower Shop Network fue 12 horas, pero eso incluía un desarrollador (o una IA) con contexto completo del proyecto. Para migraciones más complejas con múltiples stages, dependencias entre pipelines o builds de plataformas cruzadas, contá entre 2 y 5 días.
Errores críticos y cómo evitarlos
Acá viene lo que realmente importa. La parte técnica la podés leer en la documentación; estos son los errores que te cuestan horas:
Permisos IAM insuficientes o demasiado amplios
El error más común en cualquier migración a AWS. CodeBuild necesita un rol IAM con permisos específicos: acceso a ECR para pull y push, acceso a Secrets Manager para leer las credenciales, acceso a S3 si usás artifacts, y permisos para escribir logs en CloudWatch. Si arrancás con un rol demasiado restrictivo, el build falla con mensajes de error que no siempre son claros sobre qué permiso falta exactamente. Si lo hacés demasiado amplio para “que funcione y después lo ajusto”, ese “después” nunca llega.
No tener un fallback activo durante la migración
Brian Becker lo describe explícitamente: mientras el nuevo pipeline de AWS subía, mantuvieron un fallback manual usando buildx en un host arm64 para no bloquear al equipo. Si tu plan de migración no tiene una respuesta para “¿qué hacemos si CodeBuild no levanta hoy?”, no estás listo para migrar.
Diferencias sintácticas entre plataformas
El .gitlab-ci.yml y el buildspec.yml tienen filosofías diferentes. GitLab usa stages con jobs que pueden correr en paralelo dentro del mismo stage. BuildSpec tiene fases secuenciales (pre_build, build, post_build) sin paralelismo nativo a menos que uses CodePipeline para orquestar múltiples proyectos. Si tu pipeline de GitLab tenía jobs paralelos, necesitás pensar la equivalencia antes de copiar y pegar configuración. Complementá con alternativas de IA para pipelines.
Ignorar el rate limit de Docker Hub
Ya lo mencionamos arriba, pero lo vale repetir: si no configurás ECR mirrors desde el principio, los builds van a empezar a fallar con errores de rate limit cuando menos lo esperás. No es un problema que aparece en el primer build; aparece cuando el volumen sube.
El caso real: Flower Shop Network en 12 horas
Ponele que sos VP de Software Engineering y a mitad de un deploy tu pipeline de CI se corta porque agotaste los minutos gratuitos. ¿Qué hacés? Brian Becker, con 46 años de experiencia en software, decidió migrar a AWS en el mismo día.
El stack resultante: AWS CodeBuild para ejecutar los builds, IAM con roles específicos para cada recurso, Secrets Manager para las credenciales, CodeConnections para conectar el repo, ECR con mirrors de las imágenes base de Docker Hub para evitar rate limits, y buildx corriendo en local en un host arm64 como fallback mientras el pipeline nuevo levantaba.
¿Resultado? Build verde en 12 horas desde la decisión inicial. Cero downtime para el equipo porque el fallback estaba activo. Eliminación del costo de GitLab Premium ($348/año para un seat) y ganancia de flexibilidad total sobre el entorno de build.
Lo interesante es que la parte de configuración técnica la hizo Claude (el modelo de Anthropic), con Becker supervisando. El retrospectivo que publicó en dev.to lo escribió el propio modelo, no el humano. Tomalo con pinzas en cuanto a qué tan generalizable es el caso, pero los datos técnicos del setup son reales y verificables.
Preguntas Frecuentes
¿Cómo migrar CI/CD de GitLab a AWS CodeBuild?
El proceso tiene cinco pasos: documentar el pipeline actual en GitLab, crear el proyecto en CodeBuild con buildspec.yml equivalente, configurar el rol IAM con los permisos necesarios, conectar el repo via CodeConnections, y correr ambos pipelines en paralelo antes del cutover. Para equipos pequeños con pipelines sin dependencias complejas, el proceso toma entre 12 horas y 2 días. Te puede servir nuestra cobertura de asistentes de IA en DevOps.
¿Cuánto cuesta AWS CodeBuild comparado con GitLab CI?
CodeBuild cobra $0.005 por minuto en instancias Linux small, según precios vigentes en mayo de 2026. Para un equipo de 50 personas con 60.000 minutos de build mensuales, el costo ronda los $300-$600/mes. GitLab Premium para el mismo equipo cuesta alrededor de $1.200/mes ($29/user/mes). El ahorro es real, pero hay que sumar el tiempo de configuración y la mayor complejidad operacional de administrar AWS IAM.
¿Se puede hacer una migración de pipeline sin downtime?
Sí, con un fallback activo. La estrategia es correr ambos pipelines en paralelo durante la transición: GitLab CI sigue siendo la fuente de verdad mientras CodeBuild se configura y valida. Una vez que CodeBuild da resultados consistentes, se hace el cutover. Como backup adicional durante la configuración, un build local con buildx garantiza que el equipo no se quede bloqueado.
¿Qué es buildspec.yml y cómo se diferencia de .gitlab-ci.yml?
El buildspec.yml es el archivo de configuración de AWS CodeBuild, equivalente al .gitlab-ci.yml de GitLab. A diferencia de GitLab, que organiza el pipeline en stages con jobs paralelos, buildspec.yml usa fases secuenciales (pre_build, build, post_build). No tiene paralelismo nativo dentro de un proyecto; para pipelines complejos con jobs paralelos, necesitás orquestar múltiples proyectos con CodePipeline.
¿Cuánto tiempo lleva migrar un pipeline completo?
Depende de la complejidad. Un pipeline simple de build y push a ECR puede migrarse en 12 horas como demostró el caso de Flower Shop Network. Pipelines con múltiples stages, tests de integración, deployments a varios entornos o dependencias entre proyectos requieren entre 2 y 5 días. El tiempo más alto suele estar en la configuración de IAM y en la validación paralela antes del corte.
Conclusión
Migrar CI/CD de GitLab a AWS no es una decisión de arquitectura sofisticada: en el caso que disparó este artículo fue una respuesta pragmática a un problema de precios. Los minutos se agotaron, el escalón de costo no tenía sentido para el tamaño del equipo, y AWS CodeBuild era la alternativa lógica para alguien que ya vive en el ecosistema AWS.
Lo que cambia con esta migración es el modelo mental: dejás una plataforma donde el CI viene incluido y pasás a un servicio que vos configurás y orquestás. Más control, más responsabilidad sobre IAM y la infraestructura subyacente. Para equipos que ya gestionan infraestructura en AWS, el overhead es mínimo. Para equipos que no tienen esa base, puede ser un salto más alto de lo esperado.
Si estás evaluando la migración, el checklist mínimo antes de empezar: documentar el pipeline actual en detalle, tener un fallback activo durante la transición, planificar los ECR mirrors desde el principio, y ser preciso con los permisos IAM desde el día uno. Para el hosting y los servicios de infraestructura que acompañan al proyecto, donweb.com tiene opciones de cloud y servidores para complementar el stack.
