Before going deep into CodePipeline itself, a few continuous delivery concepts need to be sharp at an intermediate level.

Stages, Actions, and Artifacts

A pipeline is made of stages that run in order — for example Source, Build, Test, and Deploy. Each stage contains one or more actions, the actual units of work like “pull code from a repository” or “run a build project.” Artifacts are the files passed from one action to the next, such as source code moving from the Source stage into the Build stage, or a compiled package moving from Build into Deploy.

Continuous Integration vs. Continuous Delivery vs. Continuous Deployment

Continuous integration means automatically building and testing every code change as it is merged. Continuous delivery extends that by automatically preparing a release that is always ready to deploy, typically pausing for a human approval before production. Continuous deployment goes one step further and removes that manual gate entirely, pushing every passing change straight to production without a person clicking anything.

CodePipeline itself is an orchestrator — it does not build or test code directly, but coordinates other services that do.

A typical pipeline starts with a Source stage connected to a repository such as CodeCommit, GitHub, Bitbucket, or an S3 bucket, watching for new commits or uploaded objects. From there, a Build stage commonly invokes AWS CodeBuild to compile code and run automated tests, though CodePipeline can also call third-party build tools through partner actions. A Deploy stage then pushes the built artifact out using a target service like AWS CodeDeploy, Amazon ECS, AWS Elastic Beanstalk, or CloudFormation.

graph LR
    A[Source Stage - CodeCommit/GitHub] --> B[Build Stage - CodeBuild]
    B --> C[Test Stage - Automated Tests]
    C --> D[Manual Approval Stage]
    D --> E[Deploy Stage - CodeDeploy/ECS/CloudFormation]
    F[(S3 Artifact Bucket)] -.stores artifacts.-> A
    F -.stores artifacts.-> B
    F -.stores artifacts.-> C
        

Every artifact produced by one stage is stored in an Amazon S3 bucket that CodePipeline manages as the handoff point between stages — this is why a Build stage doesn’t need to know anything about how the Deploy stage will use its output; it simply writes an artifact, and CodePipeline makes it available to whatever comes next.

Understanding how CodePipeline actually triggers and sequences work removes a lot of the mystery around “why did my pipeline run twice” or “why is it stuck.”

A pipeline execution begins when its source is triggered — typically a webhook event from a Git provider, or an Amazon EventBridge rule watching for a new commit or a new object in S3. CodePipeline then walks through stages strictly in order: every action inside a stage must succeed before the next stage begins, and if any action fails, the entire pipeline execution stops at that point rather than continuing forward with a broken artifact.

Only one execution of a given pipeline typically runs its stages at a time in the default configuration, meaning a second commit arriving while a pipeline is already mid-run will queue behind it rather than racing it through the same stages simultaneously — though superseding behavior can let a newer execution skip ahead of a stale, already-outdated one in later stages.

Manual approval actions pause the pipeline entirely, sending a notification (often through Amazon SNS) and waiting indefinitely — or until a configured timeout — for a human to approve or reject before the pipeline proceeds or stops.

A code change’s journey through CodePipeline follows a consistent lifecycle from commit to running in production.

Many pipelines repeat the Build-through-Deploy sequence twice — once against a staging environment, and again against production — so the exact same artifact that passed staging is the one promoted forward, rather than rebuilding from source a second time and risking a subtly different result.

Choosing CodePipeline over a third-party CI/CD platform, or over fully manual deployment, involves real trade-offs.

Pipeline speed is mostly determined by how the stages are structured, not by CodePipeline’s own overhead.

Actions within the same stage can run in parallel if they don’t depend on each other’s output, which is a common way to speed up a Build stage — for example running unit tests and a security scan side by side instead of one after the other. Sequential stages, by contrast, are inherently serial, since each depends on the artifact the previous stage produced.

For CodeBuild-backed stages, choosing a larger compute instance type reduces build time for CPU-heavy compilation or test suites, and enabling build caching avoids re-downloading dependencies on every single run. At the pipeline level, splitting one enormous pipeline into smaller, independently triggered pipelines per service is a common scaling pattern for large organizations with many microservices.

A delivery pipeline needs to be reliable in two directions — CodePipeline staying available, and deployments themselves not breaking production.

As a fully managed, multi-Availability-Zone service, CodePipeline’s own control plane does not require you to manage redundant infrastructure. The reliability work that falls to engineering teams is designing safe deployment strategies: rolling deployments replace instances gradually, blue/green deployments stand up a fully separate new environment before switching traffic over, and canary deployments send a small percentage of traffic to the new version before a full rollout.

sequenceDiagram
    participant P as Pipeline
    participant D as Deploy Action
    participant Prod as Production Fleet
    P->>D: Trigger deployment
    D->>Prod: Deploy to 10% of instances (canary)
    Prod-->>D: Health metrics
    alt Metrics healthy
        D->>Prod: Continue rollout to 100%
    else Metrics degraded
        D->>Prod: Roll back automatically
    end
        

A pipeline that can deploy to production is, by definition, a powerful and sensitive piece of infrastructure that deserves careful access control.

IAM Roles and Permissions

Each pipeline uses an IAM service role that determines exactly what it is allowed to touch — which source repositories, which build projects, and which deployment targets. Scoping this role narrowly means a compromised or misconfigured pipeline cannot reach far beyond what it actually needs to do its job.

Cross-account Deployments

Larger organizations often run a central pipeline account that deploys into separate development, staging, and production AWS accounts, using cross-account IAM roles rather than one shared account holding every environment — limiting the blast radius if any single account is compromised.

Secrets and Approval Gates

Sensitive values like API keys and database credentials should be stored in AWS Secrets Manager or Systems Manager Parameter Store and referenced at build or deploy time, rather than hardcoded into pipeline configuration or source code. Manual approval stages also serve a security function — they are a natural checkpoint for confirming a change is expected before it reaches production.

Pipeline visibility is what turns “a deployment happened” into “we know exactly what happened, when, and why it succeeded or failed.”

CodePipeline emits execution state changes to Amazon EventBridge, which teams commonly wire into Slack or email notifications so the right people hear about failures immediately rather than discovering them later. CodeBuild logs stream to Amazon CloudWatch Logs, giving engineers the full build and test output for debugging a failure without needing separate log aggregation tooling.

CodePipeline is designed to sit at the center of a larger AWS delivery toolchain rather than working alone.

Pipelines are defined through the console, CLI, CloudFormation, CDK, or Terraform, which lets the pipeline definition itself be version-controlled alongside application code — a practice often called “pipeline as code.” Depending on the deployment target, the final stage might invoke CodeDeploy for EC2 or on-premises servers, update an ECS service for containerized applications, deploy a Lambda function directly, or apply a CloudFormation stack update for full infrastructure changes.

flowchart LR
    A[Git Push] --> B[CodePipeline - Source]
    B --> C[CodeBuild - Build & Test]
    C --> D[Manual Approval]
    D --> E{Deployment Target}
    E --> F[Amazon ECS]
    E --> G[AWS Lambda]
    E --> H[CloudFormation Stack]
        

Third-party integrations extend the pipeline further — connecting to Jira for change tracking, Slack for notifications, or a security scanning tool as a custom action — so the pipeline becomes the coordination point for the entire release process, not just the code deployment step.

Certain patterns show up again and again in mature CodePipeline setups — and so do certain mistakes.

Most pipeline-related incidents trace back to a handful of recurring, avoidable oversights.

The continuous delivery model behind CodePipeline underpins release practices across very different kinds of organizations.

What these examples share is not the specific industry, but the shape of the problem: the need to ship software changes frequently and safely, with a repeatable, auditable process that catches mistakes before they reach real users.

A few questions come up in nearly every team’s first serious CodePipeline evaluation.

No — while CodePipeline integrates deeply with AWS’s own build and deploy services, it also supports third-party tools and custom actions, so teams can mix AWS-native and external tools within the same pipeline.

The pipeline execution stops at the failed action, later stages do not run, and the pipeline reports a failed status, typically triggering a notification so the team can investigate before retrying or fixing the issue.

Yes, cross-account and cross-region deployments are supported through IAM roles configured for cross-account access and replicated artifact buckets in each target region.

Pricing depends on the pipeline type — the V1 type charges a flat monthly fee per active pipeline, while the V2 type charges per pipeline execution, which can be more cost-effective for pipelines that run infrequently.

No, manual approval is optional and typically reserved for sensitive environments like production, while lower environments often deploy fully automatically with no human gate at all.

AWS CodePipeline takes the repeatable sequence of building, testing, and deploying software and turns it into a managed, automated workflow that runs the same way every single time. The underlying engineering decisions — what tests actually matter, which deployment strategy fits the risk profile, where a human should be in the loop — remain the team’s responsibility, because CodePipeline provides the conveyor belt, not the judgment about what quality bar each station should enforce. Understanding stages, artifacts, deployment strategies, and IAM scoping is what separates a delivery pipeline teams trust from one people quietly route around.