CI/CD con GitLab en AWS: cómo montarlo y cuánto cuesta

¿Qué problemas resuelve un pipeline CI/CD?

Son los síntomas de un proceso de entrega sin automatizar. Ninguno se arregla con más cuidado al desplegar; se arreglan quitando pasos manuales.

¿Qué etapas debe tener un pipeline CI/CD con GitLab en AWS?

Esta es la secuencia que proponemos como punto de partida. Cada etapa tiene una regla de paso explícita: si no se cumple, el cambio no avanza.

Un esqueleto de .gitlab-ci.yml

El fragmento muestra las piezas que más se olvidan: plantillas de seguridad incluidas, credenciales de AWS por OIDC, un rol distinto por entorno y producción con paso manual. Las etapas de build y test se omiten por brevedad, y deploy.sh representa tu script de despliegue (por ejemplo, registrar la nueva definición de tarea de ECS con la imagen del commit y actualizar el servicio).

stages: [build, test, staging, production]

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

.aws:
  image:
    name: amazon/aws-cli
    entrypoint: [""]
  id_tokens:
    AWS_ID_TOKEN:
      aud: https://gitlab.com
  before_script:
    - echo "$AWS_ID_TOKEN" > /tmp/web-identity-token
    - export AWS_WEB_IDENTITY_TOKEN_FILE=/tmp/web-identity-token

deploy_staging:
  extends: .aws
  stage: staging
  environment: staging
  variables:
    AWS_ROLE_ARN: $ROLE_ARN_STAGING
  script:
    - ./deploy.sh staging "$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy_production:
  extends: .aws
  stage: production
  environment: production
  variables:
    AWS_ROLE_ARN: $ROLE_ARN_PRODUCTION
  script:
    - ./deploy.sh production "$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

La CLI de AWS asume el rol indicado en AWS_ROLE_ARN con el token del fichero de AWS_WEB_IDENTITY_TOKEN_FILE. Las variables ROLE_ARN_STAGING y ROLE_ARN_PRODUCTION se guardan como variables protegidas del proyecto, y el valor de aud debe coincidir con la audiencia configurada en el proveedor OIDC de IAM.

¿Cómo se conecta GitLab con AWS de forma segura?

• OIDC en lugar de claves. Un proveedor de identidad OIDC en IAM y un rol por entorno cuya política de confianza restringe la condición sub al proyecto y a la rama (por ejemplo, project_path:grupo/app:ref_type:branch:ref:main). Las variables CI_JOB_JWT se eliminaron en GitLab 17.0; si tu pipeline aún las usa, hay que migrar a id_tokens.
• Mínimo privilegio. El rol de staging no puede tocar producción, y el de despliegue no administra IAM.
• Secretos fuera del repositorio. Variables protegidas y enmascaradas en GitLab para lo imprescindible; el resto, en AWS Secrets Manager o Parameter Store, leído en tiempo de ejecución.
• Ramas y entornos protegidos. Solo la rama principal despliega, y producción exige un paso manual. Las aprobaciones obligatorias de despliegue y de merge request dependen del plan de GitLab que tengas.
• Runners bajo control. Los runners alojados de GitLab valen para empezar; con runners propios en tu cuenta AWS (en EC2 con autoescalado o en EKS) controlas red, coste y acceso a recursos privados.

Si quieres profundizar en los controles de seguridad del pipeline, lo desarrollamos en DevSecOps en GitLab y AWS.

¿Qué estrategia de despliegue conviene: rolling, blue/green o canary?

Blue/green y canary necesitan capacidad extra durante el cambio y métricas que digan si la versión nueva va bien. Sin observabilidad, un canary solo retrasa el problema.

Antes de automatizar: lo que conviene tener resuelto

• Repositorio Git único por aplicación y estrategia de ramas sencilla (trunk-based o similar).
• Al menos una batería mínima de tests que se ejecute en local y en CI.
• Un entorno de staging que se parezca a producción.
• Infraestructura descrita como código, o un plan para llevarla.
• Secretos fuera del código y de los ficheros de configuración.
• Alertas mínimas en producción: disponibilidad, errores 5xx y latencia.
• Un procedimiento escrito de vuelta atrás, aunque al principio sea manual.

¿Qué resultados se pueden esperar? Un caso real

Una startup SaaS desplegaba a mano, sin controles de seguridad, y eso retrasaba la entrega de nuevas funcionalidades. Implantamos un pipeline con GitLab CI, análisis estático con SonarQube en cada commit, contenedores Docker, despliegue automático a staging y producción con políticas de aprobación y rollback automático. Se hizo de forma incremental, con el despliegue manual como respaldo durante las primeras semanas.

El detalle, con arquitectura y decisiones, está en el caso del pipeline CI/CD para una startup SaaS. Como referencia general, los despliegues pueden ser hasta 10× más rápidos frente al proceso manual previo, en entornos con despliegue manual. El resultado depende del punto de partida.

¿Cuánto cuesta implantar CI/CD con GitLab en AWS?

Como referencia, el rango de mercado que manejamos para un servicio DevOps gestionado en España es de 2.000–8.000 €/mes. El precio exacto se da por escrito tras un diagnóstico gratuito: Sesión de 30 minutos para entender tu infraestructura y, en 24h, un informe con mapa de costes, riesgos y quick wins priorizadas. Todos los planes están en precios, y el alcance del servicio en DevOps y CI/CD.

¿Lo monta tu equipo o lo externalizas?

Si tu equipo tiene tiempo y experiencia en AWS, el esqueleto de arriba es un buen punto de partida. Si el pipeline compite con el desarrollo de producto, suele compensar externalizar la implantación y decidir después si se opera dentro o fuera. Lo comparamos en DevOps gestionado frente a equipo interno.