Service 48

CodePipeline, CodeBuild & CodeDeploy

Dev ToolsCI/CDInfra

AWS's native CI/CD trio fits together cleanly: CodeBuild compiles and tests, CodeDeploy rolls out to targets, and CodePipeline orchestrates the stages. Code flows source → build → test → deploy.

You can use them together or any subset. CodeCommit, AWS's managed-Git piece, briefly stopped accepting new customers in 2024 but returned to general availability for new sign-ups in November 2025; even so, most teams use GitHub, GitLab, or Bitbucket as the source.

CodeBuild and CodeDeploy

CodeBuild runs builds in a fresh managed container per build, driven by a buildspec.yml in your repo, publishing artifacts to S3 or the next stage. No build servers to keep alive — you pay per build-minute with zero idle cost.

CodeDeploy handles rollouts to EC2, on-prem servers, ECS, and Lambda, with deployment configurations (one-at-a-time, half, all-at-once, weighted canary), lifecycle hooks, and automatic rollback on failure or CloudWatch alarm. It is the canonical AWS-native way to do blue/green on ECS and Lambda.

CodePipeline and the GitHub Actions Question

A pipeline is a sequence of stages (source, build, test, deploy), each with one or more actions, including manual-approval and parallel actions. CodePipeline V2 adds richer triggers and parameterized pipelines for multi-environment deploys.

The real-world choice is usually Code* versus GitHub Actions. GitHub Actions wins when your code is on GitHub. Code* wins for AWS-native IAM auth without managing tokens, AWS-specific deployment patterns (blue/green ECS, Lambda canary), or regulated workloads that must stay inside AWS — and many teams mix GitHub Actions with a bit of CodeDeploy.

Code* trio vs GitHub Actions

Code* services — AWS-native IAM auth, AWS-specific deploy patterns, or regulated pipelines that must run inside AWS.

GitHub Actions — the default when code lives on GitHub — tighter integration, larger marketplace.

CodeDeploy alone — the pragmatic middle: GitHub Actions for CI plus CodeDeploy for blue/green ECS or Lambda canary.

Common Mistakes

Defining the build steps in the CodeBuild project instead of a buildspec.yml in the repo, losing review and version history.
Baking secrets into environment variables instead of injecting them from Parameter Store or Secrets Manager.
Deploying straight to production with no manual-approval action when test coverage does not justify it.
Letting pipeline failures go unnoticed instead of streaming them to Slack via EventBridge.
Migrating a working GitHub Actions setup to CodePipeline for little gain.
Skipping CodeDeploy's automatic rollback (on deployment failure or a CloudWatch alarm), so a bad ECS or Lambda release keeps serving traffic until someone notices.

Best Practices

Keep buildspec.yml in the repo, not in the CodeBuild project.
Inject secrets through Parameter Store or Secrets Manager.
Use CodeDeploy blue/green for ECS or Lambda when you need controlled traffic shifting and alarm-based rollback.
Add manual-approval actions to production stages unless test coverage is high.
Stream pipeline failures to a Slack channel via EventBridge.
Connect your Git host (GitHub, GitLab, Bitbucket, or CodeCommit) through CodeStar Connections as the pipeline source.

Comparable services GCP Cloud Build, Cloud DeployAzure Azure DevOps Pipelines

Knowledge Check

What is each service's role in the Code* trio?

CodeBuild builds and tests, CodeDeploy rolls out, CodePipeline orchestrates the stages
CodePipeline builds and tests the code, CodeBuild deploys it, and CodeDeploy orchestrates the run
They are three names for one bundled service you adopt together
CodeDeploy builds, CodeBuild orchestrates, CodePipeline tests

Where should the build steps live?

In a buildspec.yml file in the repository, for review and versioning
Hard-coded directly in the CodeBuild project settings in the AWS console
In the CodePipeline source stage that fetches the code
In an environment variable passed to the build

When do the Code* services win over GitHub Actions?

For AWS-native IAM auth, AWS deploy patterns, or pipelines that must stay inside AWS
Whenever the source code already lives in a GitHub repository
For every project without exception, simply because they are first-party AWS services
Only for deploying static websites to an S3 bucket

What is the canonical AWS-native way to do blue/green deployments on ECS and Lambda?

CodeDeploy, which shifts traffic to the new version and rolls back on alarm
CodeBuild running a custom buildspec script that shifts traffic in canary steps
CloudFormation drift detection wired to an auto-rollback handler on divergence
A plain ECS rolling update that replaces the service's tasks in place

You got correct