AWS CodePipeline: What It Is and When to Use It

Definition

AWS CodePipeline is a fully managed continuous delivery (CD) service that models and automates the release process for applications and infrastructure. You define a pipeline as a sequence of stages, each containing one or more actions, and CodePipeline runs the pipeline whenever the source changes — checking out code, building, testing, deploying, and gating on manual approvals where required. It integrates natively with the AWS developer tools (CodeCommit / CodeBuild / CodeDeploy / CloudFormation / ECS / Lambda / Elastic Beanstalk) and with popular third-party sources like GitHub and Bitbucket, plus build tools like Jenkins.

How It Works

A CodePipeline pipeline is a directed series of stages. Each stage contains actions that run in parallel or in sequence. Transitions between stages can be automatic or gated by a manual approval.

Typical structure:

Source (CodeCommit / GitHub / S3)
  ↓
Build (CodeBuild / Jenkins)
  ↓
Test (CodeBuild / third-party)
  ↓
Staging Deploy (CodeDeploy / CloudFormation / ECS / Lambda / Elastic Beanstalk)
  ↓  (Manual Approval)
Production Deploy

Each action has:

• An action type (Source, Build, Test, Approval, Deploy, Invoke).
• An action provider (the integration, e.g., CodeCommit, CodeBuild, CodeDeploy, CloudFormation, ECS, Lambda, S3, Jenkins, GitHub).
• Input artifacts (zip files pulled from S3) and output artifacts passed to later stages.

Artifacts flow between stages through an artifact store — an S3 bucket that CodePipeline manages per pipeline and Region. A source commit in CodeCommit or a merged PR in GitHub triggers the pipeline via EventBridge (webhooks for external sources, EventBridge rules for AWS sources).

Key Features and Limits

• Source providers — AWS CodeCommit, GitHub (via app or OAuth), GitHub Enterprise, Bitbucket, AWS CodeStar Connections, S3 (zip), and Amazon ECR (image push).
• Build providers — AWS CodeBuild (native), Jenkins (self-hosted), TeamCity, third-party via custom actions.
• Test providers — CodeBuild, Ghost Inspector, BlazeMeter, Micro Focus, and any custom action returning pass/fail.
• Deploy providers — AWS CodeDeploy (EC2/Lambda/ECS), AWS CloudFormation, Amazon ECS, AWS Lambda, AWS Elastic Beanstalk, AWS OpsWorks, AWS AppConfig, AWS Service Catalog, Amazon S3.
• Manual approval action — pauses the pipeline; approver receives an SNS notification and clicks approve/reject in the console.
• Parallel actions — multiple actions in the same stage run simultaneously (e.g., deploy to two Regions at once).
• Cross-Region actions — a single pipeline can deploy to multiple Regions from one orchestrator Region.
• Pipeline types — V1 (legacy, simple) and V2 (supports triggers on Git tags and branches, pipeline variables, and richer parameters). V2 is now the default.
• Pipeline variables — dynamic values set at execution start or by earlier actions, passed into later actions.
• Detect-and-fetch vs webhook triggers — GitHub uses webhooks (recommended) or polling.
• EventBridge integration — every state transition emits an event; common to route pipeline failures to SNS/Slack.
• Lambda invoke action — custom steps, e.g., running smoke tests, calling an external API, promoting artifacts.
• Rollback — built into some deploy providers (CodeDeploy blue/green, CloudFormation stack rollback, ECS rollback).
• Limits — max 50 stages per pipeline, max 50 actions per stage, default 300 pipelines per account per Region (soft).

Common Use Cases

1. Classic three-stage CD — Source → Build → Deploy across dev/staging/prod with manual approval before prod.
2. CloudFormation pipelines — Source → Build (cdk synth / aws cloudformation package) → Change Set create → Manual approval → Change Set execute.
3. Container pipelines — Source → CodeBuild (docker build/push to ECR) → ECS deploy (rolling or CodeDeploy blue/green).
4. Serverless pipelines — Source → Build (SAM/CDK) → Deploy Lambda with CodeDeploy canary traffic shifting.
5. Multi-Region active-active — parallel deploy actions to several Regions.
6. Multi-account — source in a shared services account, deploy actions using cross-account IAM roles into prod accounts.
7. Infra + app pipelines — separate pipelines for Terraform/CDK and application code, or a combined pipeline using variables.

Pricing Model

CodePipeline V1 charges per active pipeline-month — a pipeline that has at least one change within the month. Pipelines without activity do not incur the monthly fee. The first V1 pipeline is free every month.

CodePipeline V2 uses per-action-execution pricing: you pay a small fee per action run (e.g., per Source pull, per Build invoke, per Deploy run). This can be cheaper for infrequent pipelines and more expensive for very busy ones; V2 gives you finer-grained billing aligned with usage.

You separately pay for underlying services: CodeBuild compute minutes, CodeDeploy (free on EC2 for core features), CloudFormation (free for AWS::* resources), S3 for artifact storage, and EventBridge for rule invocations (usually pennies).

Pros and Cons

Pros

• Fully managed — no CD server to patch or scale.
• Deep native integration with AWS services (CloudFormation, ECS, Lambda, CodeDeploy).
• Visual pipeline editor plus CloudFormation / CDK definitions.
• Cross-Region and cross-account deploys built-in.
• Pay-per-use (V2) aligns cost with real usage.

Cons

• Less flexible than dedicated CI/CD platforms (GitHub Actions, GitLab CI, CircleCI) for complex conditional logic.
• Artifact flow through S3 adds latency compared to in-memory systems.
• Limited parallelism across stages — you can parallelize within a stage, but stages run sequentially.
• UI can feel dated; visualization of complex pipelines gets cramped.
• Third-party integrations (Jenkins, non-AWS VCS) often need setup via Custom Actions or CodeStar Connections.

Comparison with Alternatives

| | CodePipeline | GitHub Actions | Jenkins | GitLab CI | | --- | --- | --- | --- | --- | | Hosting | Managed (AWS) | Managed (GitHub) | Self-hosted | Managed or self-hosted | | Source | AWS + GitHub/Bitbucket | GitHub only | Any | GitLab only | | AWS deploy | Native (best) | via actions | via plugins | via jobs | | Manual approval | Native | Environments | Plugin | Manual job | | Matrix / fan-out | Limited | Strong | Strong | Strong | | Best for | AWS-heavy orgs, compliance | GitHub-centric teams | Complex legacy builds | GitLab-centric teams |

Exam Relevance

• Developer Associate (DVA-C02) — understand stages, actions, artifacts, and typical Source → Build → Deploy shape.
• DevOps Professional (DOP-C02) — heavy coverage: multi-account / multi-Region pipelines, manual approvals, CloudFormation Change Set actions, CodeDeploy integration (blue/green, canary), rollback strategies, cross-account IAM with CodeStar Connections.
• SysOps Administrator (SOA-C02) — operational aspects: monitoring pipeline failures via EventBridge → SNS, artifact bucket encryption, and troubleshooting failed actions.

Exam trap: distinguishing CodePipeline (orchestrator) from CodeBuild (build engine) and CodeDeploy (deploy engine). CodePipeline doesn't build or deploy by itself — it orchestrates providers.

Frequently Asked Questions

Q: What's the difference between CodePipeline, CodeBuild, and CodeDeploy?

A: CodePipeline is the orchestrator — it defines the stages and transitions of your release process. CodeBuild is a managed build environment that runs buildspec.yml commands on ephemeral containers (compile, unit test, produce artifacts). CodeDeploy is a deployment agent service that takes a packaged artifact and deploys it to EC2, Lambda, or ECS with strategies like in-place, blue/green, canary, and linear. A full pipeline typically has CodePipeline calling CodeBuild for Build stages and CodeDeploy (or CloudFormation/ECS) for Deploy stages.

Q: How do manual approvals work in CodePipeline?

A: Add an Approval action to any stage. When the pipeline reaches it, execution pauses and CodePipeline optionally sends an SNS notification (often wired to email or Slack via AWS Chatbot). The approver opens the pipeline in the console (or calls PutApprovalResult via the API), writes an optional comment, and approves or rejects. Approval actions can include a review URL (e.g., a link to a staging environment or a CloudFormation Change Set) to help the approver decide. Approvals time out after 7 days by default.

Q: How do I deploy to multiple AWS accounts from one CodePipeline?

A: Keep the pipeline in a shared tools / CI account. In each target account (dev, staging, prod), create an IAM role that the pipeline assumes to perform deployments. The pipeline's deploy action specifies the cross-account role ARN (roleArn in the action config). Encrypt the artifact S3 bucket with a customer-managed KMS key and grant the cross-account roles kms:Decrypt on it. Use CodeStar Connections (AWS CodeConnections) for GitHub/Bitbucket access tied to the tools account, and propagate via cross-account roles. This is the standard multi-account CD pattern on AWS.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS CodePipeline documentation before making production decisions.