---
title: AWS CodePipeline: CI/CD Pipeline Patterns for Production
description: CodePipeline isn't the most loved CI/CD tool, but it talks to every other AWS service natively. Pipeline architecture, CodeBuild configuration, cross-account deploys, and the patterns that ship code safely without bolting on a third-party runner.
url: https://www.joinhorizon.co/blog/aws-codepipeline-cicd-pipeline-patterns-for-production/
datePublished: 2026-02-22T00:00:00.000Z
dateModified: 2026-10-28T00:00:00.000Z
author: manojkumar-varatharajan
category: DevOps & CI/CD
tags: codepipeline, cicd, devops, aws, automation
---

# AWS CodePipeline: CI/CD Pipeline Patterns for Production

> CodePipeline isn't the most loved CI/CD tool, but it talks to every other AWS service natively. Pipeline architecture, CodeBuild configuration, cross-account deploys, and the patterns that ship code safely without bolting on a third-party runner.

CI/CD pipelines are the mechanism that turns code changes into running software automatically, reliably, and safely. Without CI/CD, deployments are manual processes that vary between team members, skip tests under time pressure, and introduce human error at a critical point in the software lifecycle. With CI/CD, every deployment follows the same path: build, test, stage, approve, deploy.

**June 2026 refresh:** Prefer **CodeConnections** (GitHub/GitLab/Bitbucket) over legacy OAuth connectors. AWS patches credential flows regularly and newer connections simplify rotation. For EKS delivery, many teams pair CodePipeline build stages with [GitOps reconciliation (Argo CD or Flux)](https://www.joinhorizon.co/blog/aws-gitops-eks-argocd-flux-2026/) instead of pushing manifests from the pipeline.

AWS CodePipeline orchestrates this flow using AWS-native services: CodeCommit or GitHub for source, CodeBuild for build and test, CodeDeploy for deployment, and [CloudFormation](https://www.joinhorizon.co/blog/aws-cloudformation-best-practices-infrastructure-as-code/) for infrastructure changes. This guide covers the pipeline patterns that work in production.

## Pipeline architecture

### Basic pipeline structure

![Architecture diagram of a repository triggering CodeBuild, then a manual approval, then an ECS production deploy](../../assets/images/blog/aws-codepipeline-cicd-pipeline-patterns-for-production-stages.webp)

_Figure: the minimum production pipeline in the article. CodeBuild compiles and tests. A person approves. Only then does the deploy reach production. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-codepipeline-cicd-pipeline-patterns-for-production/stages.drawio)._

Every pipeline follows the same fundamental stages:

```
Source → Build → Test → Stage Deploy → Approval → Production Deploy
```

**Minimum viable pipeline:**

```
Source (GitHub)
  → Build (CodeBuild: compile, unit test, lint)
    → Deploy (CodeDeploy/ECS: deploy to staging)
      → Manual Approval
        → Deploy (CodeDeploy/ECS: deploy to production)
```

**Production pipeline with quality gates:**

```
Source (GitHub)
  → Build (CodeBuild: compile, unit test, lint, SAST)
    → Deploy to Staging (ECS/CodeDeploy)
      → Integration Tests (CodeBuild: API tests, E2E tests)
        → Performance Tests (CodeBuild: load testing)
          → Manual Approval (with test results link)
            → Deploy to Production (ECS/CodeDeploy: blue-green)
              → Post-Deploy Validation (CodeBuild: smoke tests)
```

### CodePipeline V2

CodePipeline V2 introduces pipeline-level variables, triggers, and improved execution modes:

**Trigger types:**

- **Push:** Trigger on code push to specific branches
- **Pull request:** Trigger on PR creation or update
- **Tag:** Trigger on tag creation (release workflow)
- **Scheduled:** Trigger on a cron schedule (nightly builds)

**Execution modes:**

- **SUPERSEDED:** New execution cancels in-progress execution (default)
- **QUEUED:** Executions run in order, one at a time
- **PARALLEL:** Multiple executions run simultaneously (for independent branches)

**Recommendation:** Use QUEUED mode for production pipelines. SUPERSEDED can cancel a valid deployment mid-flight. PARALLEL is for feature branch pipelines where executions are independent.

## CodeBuild

### Build project configuration

CodeBuild runs your build commands in a managed container:

```yaml
# buildspec.yml
version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 20
    commands:
      - npm ci
  pre_build:
    commands:
      - npm run lint
      - npm run type-check
  build:
    commands:
      - npm run build
      - npm test -- --coverage
  post_build:
    commands:
      - docker build -t $ECR_REPO:$CODEBUILD_RESOLVED_SOURCE_VERSION .
      - docker push $ECR_REPO:$CODEBUILD_RESOLVED_SOURCE_VERSION
artifacts:
  files:
    - '**/*'
  base-directory: dist
reports:
  coverage:
    files:
      - coverage/clover.xml
    file-format: CLOVERXML
  tests:
    files:
      - junit.xml
    file-format: JUNITXML
cache:
  paths:
    - 'node_modules/**/*'
```

### Build environment

| Compute Type           | vCPU | Memory | Best For                                  |
| ---------------------- | ---- | ------ | ----------------------------------------- |
| BUILD_GENERAL1_SMALL   | 2    | 3 GB   | Simple builds, linting                    |
| BUILD_GENERAL1_MEDIUM  | 4    | 7 GB   | Standard builds, unit tests               |
| BUILD_GENERAL1_LARGE   | 8    | 15 GB  | Large builds, Docker, integration tests   |
| BUILD_GENERAL1_2XLARGE | 72   | 145 GB | Massive parallel tests, ML model builds   |
| BUILD_LAMBDA_1GB       | 2    | 1 GB   | Fast, lightweight builds (Lambda compute) |

**Lambda compute mode:** For builds that complete in under 15 minutes without Docker, Lambda compute starts faster (no container provisioning) and costs less. Use for lint, test, and simple build steps.

**Build caching:** Enable S3 or local caching for `node_modules`, `.m2`, `.gradle`, or other dependency directories. Caching reduces build times by 50-80% for dependency-heavy projects.

### Environment variables and secrets

```yaml
environment:
  variables:
    NODE_ENV: production
    AWS_DEFAULT_REGION: us-east-1
  parameter-store:
    DB_HOST: /myapp/prod/database/host
  secrets-manager:
    DB_PASSWORD: myapp/prod/db-password:password
```

Never hardcode secrets in `buildspec.yml`. Use [Parameter Store or Secrets Manager](https://www.joinhorizon.co/blog/aws-secrets-manager-vs-parameter-store-when-to-use-which/) references. CodeBuild resolves them at build time.

## Deployment strategies

### Rolling deployment

Replace instances/tasks in batches:

```
Batch 1 (25%): Deploy new version → Health check → Proceed
Batch 2 (25%): Deploy new version → Health check → Proceed
Batch 3 (25%): Deploy new version → Health check → Proceed
Batch 4 (25%): Deploy new version → Health check → Complete
```

**Pros:** No additional infrastructure cost, gradual rollout.
**Cons:** Mixed versions during deployment, rollback requires another deployment.

**Best for:** Internal applications, non-critical services where brief mixed-version state is acceptable.

### Blue-green deployment

Run two identical environments, deploy to the inactive one, then switch traffic:

```
Before: Traffic → Blue (v1.0) [active]    Green (idle)
Deploy: Traffic → Blue (v1.0) [active]    Green (v1.1) [deploying]
Switch: Traffic → Blue (v1.0) [standby]   Green (v1.1) [active]
```

**ECS blue-green with CodeDeploy:**

```
1. CodeDeploy creates new task set (green) with new task definition
2. Green tasks start and pass health checks
3. CodeDeploy shifts traffic: 10% to green (canary)
4. Wait 5 minutes, monitor alarms
5. Shift remaining 90% to green
6. Terminate blue task set after 1 hour (rollback window)
```

**Pros:** Zero-downtime, instant rollback (shift traffic back to blue).
**Cons:** Double infrastructure during deployment.

**Best for:** Production workloads where zero-downtime and fast rollback are requirements.

### Canary deployment

Route a small percentage of traffic to the new version, then gradually increase:

```
Step 1: 5% → new version, 95% → current version  (10 minutes)
Step 2: 25% → new version, 75% → current version  (10 minutes)
Step 3: 50% → new version, 50% → current version  (10 minutes)
Step 4: 100% → new version                         (complete)
```

**Automatic rollback:** If [CloudWatch alarms](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) trigger during any step (error rate increase, latency spike), CodeDeploy automatically rolls back to the previous version.

**CodeDeploy deployment configuration:**

```
CodeDeployDefault.ECSCanary10Percent5Minutes
  → 10% traffic shift, wait 5 minutes, then 100%

CodeDeployDefault.ECSLinear10PercentEvery3Minutes
  → 10% every 3 minutes until 100%

Custom:
  → 5% for 10 minutes, then 25% for 10 minutes, then 100%
```

### ECS deployments

For [ECS workloads](https://www.joinhorizon.co/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/), the pipeline builds a Docker image, pushes to ECR, and updates the task definition:

```
Source → CodeBuild (build + push to ECR)
  → Create new task definition revision
    → CodeDeploy: Blue-green deployment to ECS service
      → CloudWatch alarms monitor error rate
        → Auto-rollback if alarms trigger
```

**Image tagging strategy:**

```
ECR image tags:
  latest         ← don't use in production (mutable)
  v1.2.3         ← semantic version (for releases)
  abc123def      ← git commit SHA (for traceability, recommended)
```

Tag images with the git commit SHA. This creates a direct link from the running container back to the exact source code, which is essential for debugging production issues.

## Cross-account pipelines

![Architecture diagram of CodePipeline in a tools account assuming a role to deploy ECS in a workload account](../../assets/images/blog/aws-codepipeline-cicd-pipeline-patterns-for-production-accounts.webp)

_Figure: cross-account delivery in the article. The pipeline and build stay in the tools account. Deploy assumes a role in the workload account. That role is not an administrator. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-codepipeline-cicd-pipeline-patterns-for-production/accounts.drawio)._

In a [multi-account organization](https://www.joinhorizon.co/blog/aws-multi-account-strategy-landing-zone-best-practices/), the pipeline runs in a tools account and deploys to workload accounts:

```
Tools Account (pipeline + build):
  CodePipeline → CodeBuild
    → Assume role in Staging Account → Deploy to staging
      → Manual Approval
        → Assume role in Production Account → Deploy to production
```

### Cross-account setup

**1. Pipeline account (tools):** KMS key, S3 artifact bucket, CodePipeline, CodeBuild.

**2. Target accounts (staging, production):** IAM role that the pipeline assumes, with permissions to deploy (ECS, CodeDeploy, CloudFormation).

**3. KMS key policy:** Grant the target account roles access to decrypt pipeline artifacts.

**Principle:** The pipeline account has no direct access to workload resources. It assumes a deployment role in each target account, and that role has only the permissions needed for deployment, with no administrative access.

## Pipeline security

### IAM best practices

Apply [least privilege](https://www.joinhorizon.co/blog/aws-iam-best-practices-least-privilege-access-control/) to every pipeline component:

- **CodePipeline service role:** Access to source (CodeStar Connections), build (CodeBuild), deploy (CodeDeploy/ECS), and artifact bucket only
- **CodeBuild service role:** Access to ECR, artifact bucket, Parameter Store/Secrets Manager, CloudWatch Logs
- **CodeDeploy service role:** Access to ECS, ALB target groups, Auto Scaling
- **Artifact bucket policy:** Encrypted with KMS, access limited to pipeline roles

### Artifact encryption

All pipeline artifacts should be encrypted:

```
S3 artifact bucket:
  Encryption: AWS KMS (customer-managed key)
  Bucket policy: Deny unencrypted uploads
  Versioning: Enabled
  Lifecycle: Delete artifacts after 30 days
```

### Source authentication

**GitHub (via CodeStar Connections):** OAuth-based connection, with no access tokens stored in AWS. CodeStar Connections is the recommended way to connect GitHub to CodePipeline.

**CodeCommit:** IAM-based authentication. Use git-remote-codecommit for HTTPS (no SSH keys to manage).

## Testing in pipelines

### Test stages

| Stage           | Test Type              | Runs On   | Purpose                        |
| --------------- | ---------------------- | --------- | ------------------------------ |
| Build           | Unit tests             | CodeBuild | Verify code logic              |
| Build           | Lint + type check      | CodeBuild | Code quality                   |
| Build           | SAST (static analysis) | CodeBuild | Security vulnerabilities       |
| Post-staging    | Integration tests      | CodeBuild | API contract verification      |
| Post-staging    | E2E tests              | CodeBuild | User workflow verification     |
| Post-staging    | Load tests             | CodeBuild | Performance verification       |
| Post-production | Smoke tests            | CodeBuild | Production health verification |

### Test reports

CodeBuild supports test report groups that display results in the console:

- **JUnit XML:** Test results with pass/fail/skip counts
- **Clover/Cobertura XML:** Code coverage reports
- **Cucumber JSON:** BDD test results

Configure test reports in `buildspec.yml` to track test results and coverage trends over time.

## Monitoring

### Pipeline metrics

Set [CloudWatch alarms](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) for pipeline health:

| Metric                  | Alarm Condition | Indicates                     |
| ----------------------- | --------------- | ----------------------------- |
| Pipeline execution time | > 30 minutes    | Build performance degradation |
| Failed executions       | > 0             | Build or deployment failure   |
| Manual approval pending | > 4 hours       | Approval bottleneck           |

### Notifications

Configure pipeline notifications via SNS:

```
Events to notify:
  - Pipeline execution started
  - Pipeline execution failed (critical — page on-call)
  - Manual approval needed (notify approvers)
  - Deployment succeeded (notify team)
  - Deployment rolled back (critical — page on-call)
```

### Deployment tracking

Tag deployments with metadata for traceability:

```
Deployment:
  Commit: abc123def
  Author: jane@example.com
  Pipeline: my-app-pipeline
  Execution: 12345678-abcd-efgh
  Timestamp: 2026-10-05T14:30:00Z
```

Every production issue should be traceable to a specific deployment, commit, and author.

## Cost optimization

### Pricing

| Service                     | Cost                              |
| --------------------------- | --------------------------------- |
| CodePipeline V2             | $0.002/minute of action execution |
| CodeBuild (general1.medium) | $0.005/minute                     |
| CodeBuild (Lambda, 1 GB)    | $0.00003/second                   |
| CodeDeploy (ECS/Lambda)     | Free                              |
| CodeDeploy (EC2)            | Free for on-premises → AWS        |

### Reducing costs

- **Use Lambda compute** for CodeBuild steps that do not need Docker. It is 10x cheaper than general compute.
- **Cache dependencies:** Avoid downloading `node_modules` or Maven dependencies on every build
- **Optimize build steps:** Parallelize independent steps (lint + type-check + test simultaneously)
- **Right-size compute:** Do not use LARGE for a build that needs SMALL
- **Skip unnecessary stages:** Use pipeline variables and conditions to skip stages for non-critical changes

## Common mistakes

### Mistake 1: No rollback strategy

Deploying to production without automatic rollback on failure. Configure CloudWatch alarms that trigger automatic rollback when error rate or latency exceeds thresholds during deployment.

### Mistake 2: Secrets in source control

Storing database passwords, API keys, or credentials in `buildspec.yml` or application config files. Use Parameter Store and Secrets Manager references, and [never embed secrets](https://www.joinhorizon.co/blog/aws-secrets-manager-vs-parameter-store-when-to-use-which/) in source control.

### Mistake 3: No manual approval for production

Automated deployment straight to production without a manual approval gate. Even with extensive testing, production deployments should require human approval, at least until the team has high confidence in the test suite.

### Mistake 4: Oversized build environments

Using BUILD_GENERAL1_LARGE for every CodeBuild step. Most lint, test, and simple build steps run fine on SMALL or MEDIUM. Reserve LARGE for Docker builds and integration tests.

### Mistake 5: No artifact retention policy

Pipeline artifacts accumulate in S3 indefinitely. Configure lifecycle rules to delete artifacts after 30 days, since you rarely need build artifacts from months ago.

## Getting started

CI/CD pipelines turn code changes into reliable, repeatable deployments. Combined with [infrastructure as code](https://www.joinhorizon.co/blog/aws-cloudformation-best-practices-infrastructure-as-code/) for environment consistency, [container orchestration](https://www.joinhorizon.co/blog/aws-ecs-vs-eks-container-orchestration-decision-guide/) for application deployment, and [monitoring](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) for deployment validation, CodePipeline provides the deployment automation that production workloads require.

For adjacent platform patterns: [GitOps on EKS](https://www.joinhorizon.co/blog/aws-gitops-eks-argocd-flux-2026/), [cost-aware CI/CD](https://www.joinhorizon.co/blog/cost-aware-cicd-pipelines-aws/), [cross-account deploy topologies](https://www.joinhorizon.co/blog/aws-cross-account-patterns-beyond-landing-zone-2026/), and [FIS-backed deployment validation](https://www.joinhorizon.co/blog/aws-chaos-engineering-resilience-program-fis-2026/).

For CI/CD pipeline design, [DevOps implementation](https://www.joinhorizon.co/services/devops-pipeline-setup/), and [managed infrastructure services](https://www.joinhorizon.co/services/aws-managed-services/), talk to our team.

[Contact us to build your deployment pipeline →](https://www.joinhorizon.co/contact-us/)

---

*Source: https://www.joinhorizon.co/blog/aws-codepipeline-cicd-pipeline-patterns-for-production/*