AWS CodePipeline

What CodePipeline is

CodePipeline is the conductor of an AWS-native CI/CD release. You describe your release as a pipeline: an ordered list of stages — typically Source, Build, Test, Deploy, with optional manual-approval and invoke steps — and each stage holds one or more actions. When a change hits your source, CodePipeline runs the pipeline top to bottom, moving artifacts from stage to stage until the change is deployed.

CodePipeline itself builds and deploys nothing — it has no build servers and no deploy agents. It detects a source change, then calls out to other services to do the real work, passing files between stages through an S3 artifact store, all under an IAM service role.

Design Beaver models CodePipeline as the orchestration node it actually is, so it validates the action providers each stage drives, and the IAM those edges need, as you draw — before a broken edge becomes a broken pipeline.

When to use CodePipeline (and when not to)

Reach for CodePipeline when you want a repeatable, automated path from a commit to a deployed release, staying inside AWS. It fits when you already use CodeBuild or CodeDeploy and want to chain them into stages, or when you need approval gates, sequential or parallel execution, and artifacts passed between steps — without running your own orchestrator.

Don’t reach for it when your team already runs CI/CD in GitHub Actions, GitLab CI, or Jenkins and has no reason to move. It’s also the wrong layer if you only need to build code (that’s CodeBuild) or only deploy to instances (that’s CodeDeploy) — CodePipeline sits on top of those, it doesn’t replace either. A one-off manual deploy doesn’t need a pipeline, and arbitrary business-logic workflows belong in Step Functions, not a release pipeline.

Variants: pipeline types, not stage layouts

You pick a type when you create the pipeline. It changes the feature set and the billing model, not the stages you build.

CodePipeline pricing in plain English

The pricing question is really two questions, because V2 and V1 bill differently — one per action-execution minute, one flat per active pipeline per month.

The cost that surprises people: the CodePipeline charge is only for orchestration. The real bill is usually the actions’ underlying resources — CodeBuild build minutes, the S3 artifact store, and whatever the deploy targets cost — billed separately by those services.

How CodePipeline connects to other services

CodePipeline’s connections are its action providers — the services each stage drives. This is where a diagram of boxes and arrows hides the real work: which service is the source, which does the build, which handles the deploy, and the IAM each of those edges needs to actually function. Design Beaver models each connection, so it knows what a pipeline can drive and what that edge requires to be correct.

• →CodeCommit

  A CodeCommit repository is the pipeline's source action — a commit to the tracked branch starts the pipeline, and CodePipeline pulls the source into the source stage's output artifact

• →ECR

  An Amazon ECR image repository is a source for the pipeline — pushing a new image tag can start the pipeline (an ECR source action), which is the typical trigger for a container deployment flow

• →S3

  The mandatory artifact store — CodePipeline reads and writes each stage's input/output artifacts as objects in an S3 bucket in the pipeline's account and Region (one bucket per Region the pipeline runs actions in)

• →CodeBuild

  CodeBuild is the build (and often test) action provider — the build stage hands CodeBuild the source artifact, CodeBuild compiles/tests it per its buildspec, and returns an output artifact for later stages

• →CodeDeploy

  CodeDeploy is a deploy action provider — the deploy stage passes the built artifact to a CodeDeploy application/deployment group, which rolls it out to the deployment fleet (EC2/on-premises instances) with CodeDeploy's rollback and traffic-shifting logic

• →ECS

  Amazon ECS is a deploy target — an ECS deploy action (standard, or blue/green through CodeDeploy) updates the ECS service to run a new task-definition revision, typically the image the pipeline just built and pushed

• →Lambda

  A Lambda invoke action runs a Lambda function as a custom step in the pipeline — e.g. a validation/gate check, an integration test trigger, or a bespoke deployment task — and the function reports success or failure back to the pipeline

One edge worth calling out: S3 plays three separate roles here. It’s the mandatory artifact store where every stage’s input and output artifacts live, and it can also be an S3 source action or an S3 deploy target. Same service, three different jobs — Design Beaver keeps them distinct.

What CodePipeline can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕CodeArtifact

  CodeArtifact is not a CodePipeline action provider — a pipeline has no source, build, or deploy action that targets CodeArtifact directly. A package repository is consumed during a build: it is the CodeBuild project (in the build stage) that authenticates to CodeArtifact and pulls/publishes packages, so that relationship is an edge on CodeBuild, not on CodePipeline.

Anti-patterns Design Beaver catches

These are the CodePipeline mistakes that pass a diagram review but over-privilege the orchestrator or leak your artifacts — the ones the validation engine flags as you draw.

Gotchas that bite in production

• CodePipeline orchestrates; it doesn’t do the work. The build runs in CodeBuild, the rollout runs in CodeDeploy or ECS — each under its own IAM role. Keep the pipeline’s service role scoped to starting and monitoring actions and reading the artifact store. Don’t pile the build’s and deploy’s permissions onto it.
• Two roles, easily confused. The pipeline service role lets CodePipeline invoke a CodeBuild project; the CodeBuild project’s own role is what lets the build pull dependencies, read secrets, or push images. Granting one does not grant the other. The same split applies to CodeDeploy and ECS.
• The artifact-store bucket holds your release artifacts in the open. It’s easy to overlook because CodePipeline uses it as infrastructure. Keep it private and default-encrypted — KMS if the artifacts are sensitive.
• Artifact-store bucket is not the S3 source or deploy bucket. They’re the same service playing three different roles, and mixing them up is a common source of confusion.
• A Lambda invoke action must signal back. The function has to report job success or failure to CodePipeline. If it never does, the action just sits until it times out.
• Prefer event-based change detection over polling. EventBridge-based detection — the default for CodeCommit and S3 sources, and webhooks for external Git via CodeConnections — starts the pipeline on the actual change, without the latency and wasted work of polling.

Further reading

• Official AWS documentation
• Why we built a validation engine