CI/CD in Cloud Environments

CI/CD in cloud environments is the practice of designing pipelines that integrate natively with cloud provider services — authentication systems, container registries, deployment targets, secrets managers, and artifact stores — to build, test, and deploy applications to AWS, GCP, Azure, or multi-cloud infrastructure. Cloud providers offer services that replace or augment every component of a traditional CI/CD pipeline, from managed container registries to serverless deployment targets to native secrets management. Understanding how to use these services securely — particularly for authentication — is what separates pipelines that are cloud-native from pipelines that happen to run against cloud infrastructure.

OIDC Authentication — The Cloud-Native Credential Model

The single most impactful cloud CI/CD pattern is using OpenID Connect (OIDC) for pipeline-to-cloud authentication, as introduced in Lesson 23. Every major cloud provider supports OIDC federation with GitHub Actions, eliminating the need to store long-lived cloud credentials in GitHub Secrets. The pipeline proves its identity to the cloud provider through a cryptographically signed token issued by GitHub, receives a short-lived session credential, uses it for the duration of the job, and leaves nothing behind that could be leaked or misused.

Cloud-Native CI/CD Services

Each major cloud provider offers a suite of CI/CD-adjacent services that pipelines can integrate with natively. Using these services — rather than running equivalent open-source tools on a generic runner — typically provides better performance, tighter IAM integration, and reduced operational overhead. Understanding what each provider offers helps teams make informed decisions about whether to use cloud-native services or portable open-source alternatives.

Multi-Region Deployments — Patterns and Pipeline Implications

High-availability applications often deploy across multiple cloud regions — to reduce latency for geographically distributed users, to provide failover if a region becomes unavailable, or to satisfy data residency requirements. Multi-region deployments require a pipeline architecture that can deploy the same artifact to multiple targets in sequence or in parallel, with rollback coordination across regions.

The safest multi-region rollout pattern is sequential with a canary region first — deploy to a low-traffic region, monitor for 15–30 minutes, then deploy to all remaining regions. This provides the benefits of a canary deployment at the region level: if the new version causes problems, only a fraction of global traffic is affected before the rollout is halted. GitHub Actions implements this through matrix strategies with a max-parallel: 1 constraint for sequential deployment, or without the constraint for parallel deployment to all regions simultaneously.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    strategy:
      max-parallel: 1                    # Sequential — one region at a time
      matrix:
        region:
          - eu-west-1                    # Canary region — low traffic, deployed first
          - us-east-1                    # Primary region
          - ap-southeast-1               # APAC region
    permissions:
      id-token: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE }}
          aws-region: ${{ matrix.region }}     # OIDC token is region-scoped

      - name: Deploy to region
        run: |
          aws ecs update-service \
            --cluster myapp-production \
            --service api \
            --force-new-deployment \
            --region ${{ matrix.region }}
          aws ecs wait services-stable \
            --cluster myapp-production \
            --services api \
            --region ${{ matrix.region }}

      - name: Smoke test this region
        run: |
          ENDPOINT=$(aws ssm get-parameter \
            --name "/myapp/${{ matrix.region }}/endpoint" \
            --query "Parameter.Value" --output text)
          ./smoke-test.sh "$ENDPOINT"
          # If this fails, the matrix job fails and subsequent regions are skipped

Cost and Compliance in Cloud CI/CD

Cloud CI/CD pipelines consume compute resources that cost real money — and in unmanaged pipelines, costs accumulate invisibly. Runners that run unnecessarily long jobs, build caches that are never invalidated, Docker images that are rebuilt from scratch on every run because caching is misconfigured, and test suites that are not parallelised all translate directly to cloud spend. The practices that make pipelines faster — caching, parallelism, skipping unchanged services — also make them cheaper.

Compliance requirements add another dimension to cloud CI/CD architecture. Regulated industries — financial services, healthcare, government — often require audit trails for every deployment, separation of duties between the engineer who writes code and the person who approves its deployment, deployment windows that restrict when changes can reach production, and geographic restrictions on where data can be processed. These requirements are not incompatible with CI/CD — environment protection rules, manual approval gates, restricted deployment branches, and OIDC trust policies scoped to specific environments all support them — but they must be designed into the pipeline architecture from the beginning, not retrofitted after a compliance audit.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz