GitLab + AWS CodeBuild: managed runners con acceso a tu VPC

Uno de los retos en integración continua aparece cuando los procesos de construcción y prueba necesitan acceder a recursos dentro de nuestra VPC (servicios internos, APIs privadas) que no son accesibles desde internet. Un caso típico: integrar con herramientas como SonarQube alojadas en redes privadas.

Tradicionalmente, la solución pasaba por usar agentes de CI personalizados — por ejemplo runners de GitLab alojados en instancias EC2. Esa estrategia funciona, pero trae carga operativa: gestionar las EC2, monitorear disponibilidad y rendimiento, aplicar parches de seguridad y resolver el escalamiento.

Una alternativa más simple llegó con AWS CodeBuild y su funcionalidad para usarse como managed GitLab runner con acceso a recursos de tu VPC. Veamos cómo configurarlo.

1. Crear la conexión entre GitLab y CodeBuild

El primer paso es conectar la cuenta de GitLab con los servicios Code de AWS. Buscamos el servicio CodeBuild en la consola.

1. En AWS CodeBuild, ve a Settings → Connections y haz clic en Create Connection.
2. Selecciona GitLab como proveedor, ingresa un nombre para la conexión y haz clic en Connect to GitLab.
3. Autoriza la conexión en GitLab haciendo clic en Authorize AWS Connector for GitLab.
4. Haz clic en Connect.
5. La conexión queda lista y visible en la lista de Connections.

2. Crear un proyecto de CodeBuild

Configuramos un proyecto de CodeBuild que use GitLab como proveedor de código fuente:

1. En la barra de navegación, Build → Build Projects → Create build project.
2. Ingresa un nombre para el proyecto (en este ejemplo lo llamamos gitlab-runner).
3. En la sección Managed default source credentials, selecciona GitLab como Source Provider.
4. La primera vez debes configurar la conexión: clic en Managed default source credentials.
5. Selecciona el CodeConnection configurado en el paso anterior y haz clic en Save.
6. Selecciona el repositorio de GitLab con el que quieres trabajar.
7. En Primary source webhook events, selecciona la opción Rebuild every time a code change is pushed to this repository. En Event Type elige WORKFLOW_JOB_QUEUED.
8. Deja las configuraciones restantes como predeterminadas y haz clic en Create build project.

3. Crear el pipeline en GitLab

Ahora configuramos el pipeline en GitLab para ejecutar las tareas de CI/CD usando CodeBuild.

En la raíz de tu repositorio GitLab, crea un archivo .gitlab-ci.yml:

workflow:
  name: HelloWorld

stages:
  - build

build-job:
  stage: build
  script:
    - echo "Hello World!"
  tags:
    - codebuild-gitlab-runner-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME

Importante: reemplaza gitlab-runner por el nombre de tu propio proyecto de CodeBuild. El resto del tag puede quedar tal cual — las variables $CI_PROJECT_ID, $CI_PIPELINE_IID y $CI_JOB_NAME son asignadas automáticamente por GitLab.

Ejemplo:

tags:
  - codebuild-mi-proyecto-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME

4. Ver el pipeline en acción

Una vez guardado el archivo .gitlab-ci.yml, GitLab arranca el pipeline. Para verificar:

• En GitLab, ve a Build → Jobs dentro del repositorio y selecciona el job recién creado para ver los detalles de la ejecución.
• También puedes verificar la ejecución en AWS CodeBuild revisando el proyecto creado.

¡Eso es todo! Con esta configuración, AWS CodeBuild gestiona los trabajos de CI/CD de GitLab aprovechando la infraestructura administrada de AWS.

¿Por qué hacer este cambio?

Aspecto	EC2 self-managed runners	CodeBuild managed runners
Gestión de instancias	Manual (parches, escalado, monitoreo)	AWS lo gestiona
Acceso a VPC	Sí, configurable	Sí, configurable
Pago	Por instancia 24×7 (o spot)	Pago por minuto de build
Escalamiento	Spot Fleet o ASG	Automático e instantáneo
Mantenimiento	Carga operativa significativa	Bajo

Para equipos con cargas de CI variables (lo común), el modelo CodeBuild reduce el costo total y libera al equipo de la gestión de infra. Para volumen muy alto y constante, las soluciones con Jenkins + Spot Fleet siguen siendo competitivas en costo unitario.

Cómo lo aplicamos en Caleidos

Para clientes que ya operan en GitLab y quieren modernizar su CI/CD, esta arquitectura suele ser la de menor fricción operativa: integración nativa, acceso a VPC, escalamiento automático y costo proporcional al uso real. Combinado con Feature Flags en AppConfig y observabilidad con Fluent Bit en EKS, conforma una plataforma DevOps moderna sobre AWS.

Caleidos diseña, implementa y opera plataformas DevOps end-to-end como parte de nuestro servicio DevOps & Automatización. Operación continua con Caleidos Lens©.

¿Quieres simplificar tu plataforma de CI/CD? Hablemos →