AWS CI/CD

Continuous integration and continuous delivery describe successive degrees of automation in the path from commit to production, and the terms are routinely used loosely.

Continuous integration means changes are merged back to the main branch frequently and every merge triggers an automated build, unit tests and linting. Its purpose is to keep the main branch releasable and to surface integration failures within minutes rather than at the end of a release cycle.

Continuous delivery adds an automated release process: every build that passes is packaged and could be deployed on a single approval. A human still decides when.

Continuous deployment removes that human. A merge to the main branch that passes every gate goes to production unattended. It is only safe when the deployment strategy can detect a bad release and roll it back automatically.

The AWS developer tools

CodePipeline orchestrates the workflow. It defines stages, each containing actions — source, build, test, approve, deploy — and moves artefacts between them. It supports manual approval gates and can assume roles into other accounts, which is what makes multi-account deployment possible.

CodeBuild is the managed build service: it compiles source, runs tests and produces deployable artefacts from a buildspec.yml. It scales per build, so there is no build fleet to keep patched.

CodeDeploy performs the deployment onto EC2 instances (through an agent), Amazon ECS services, AWS Lambda aliases and on-premises servers. It owns the traffic-shifting behaviour — all-at-once, linear, canary — and the automatic rollback on a CloudWatch alarm.

CodeArtifact is a private package repository compatible with npm, pip, Maven, NuGet and similar. It gives an organisation a single place to publish internal packages and to proxy and cache approved open-source ones.

Source stages

CodePipeline can take source from several places. For most teams the source of truth already lives in GitHub, GitLab or Bitbucket, and the connection is made through AWS CodeConnections (the CodeStarSourceConnection action). One connection per provider covers every repository with that provider, and the connection manages change detection, so no webhook has to be wired by hand.

AWS CodeCommit is AWS’s own managed Git service and can still be used. Its availability has been unstable: AWS closed it to new customers on 25 July 2024, then returned it to full general availability on 24 November 2025. Existing pipelines built on it work; new work is more commonly sourced from an external provider through CodeConnections, because that is where the rest of the development workflow — pull requests, code review, issue tracking — already lives.

Amazon S3 and Amazon ECR are also valid source actions, for pipelines that start from a pre-built artefact or image rather than from source.

Single-account pipeline

The simplest shape puts everything in one account:

1. A commit lands on the tracked branch of the source repository.
2. CodePipeline detects the change and starts an execution.
3. CodeBuild compiles the code, runs unit tests and produces build artefacts.
4. Artefacts are written to the pipeline’s S3 artefact store.
5. An optional test stage runs integration tests against a temporary environment.
6. CodeDeploy deploys the artefact to the target instances, ECS service or Lambda alias.

This is fine for a single team on a single workload. It stops being fine as soon as the same pipeline can reach production, because everyone who can edit the pipeline can reach production.

Multi-account pipelines

Separating environments into their own AWS accounts is the standard way to limit blast radius. Two shapes are common.

Centralised pipeline

One pipeline, in a tooling or DevOps account, deploys into every environment account.

1. Source and build happen in the tooling account; artefacts (application packages, CloudFormation templates) land in a shared, KMS-encrypted S3 bucket.
2. The pipeline assumes a deployment role in the staging account and deploys.
3. On success — and, usually, after a manual approval — it assumes a deployment role in the production account and deploys the identical artefact.

The build happens once, so the thing tested in staging is bit-for-bit the thing that reaches production. The cost is that the tooling account holds credentials that can reach production, so the roles it assumes must be tightly scoped and the pipeline definition must itself be controlled.

Distributed pipelines

Each environment account owns a pipeline of its own.

1. The repository lives in a shared account.
2. Branch-specific events are forwarded to EventBridge in the relevant environment account.
3. Each account’s own pipeline builds and deploys within that account.

No account holds a role that can deploy into another, which is the strongest isolation available. The trade-off is that each account builds independently, so “the same artefact” has to be enforced deliberately rather than being a property of the design.

Supporting services

AWS X-Ray provides distributed tracing for the deployed application: it follows a single request across API Gateway, Lambda, containers and downstream AWS services and shows where the latency and errors are. It does not visualise pipelines — pipeline execution history and stage state live in the CodePipeline console and in CloudWatch Events.

Amazon Q Developer and Amazon Inspector code security provide automated code review and vulnerability scanning. They are the replacement for Amazon CodeGuru Reviewer, which stopped accepting new repository associations on 7 November 2025.

Two tools that older CI/CD material recommends can no longer be adopted. AWS Cloud9, the browser-based IDE, is closed to new customers; AWS directs new users to the AWS IDE toolkits or AWS CloudShell. AWS CodeStar, which bundled a preconfigured pipeline and permission set, ended support on 31 July 2024 and its documentation has been withdrawn.

Designing an enterprise pipeline

Isolation. Keep production resources in a separate account. Give the pipeline a deployment role in that account scoped to the resources it actually manages, and nothing broader.

Least privilege. The pipeline’s own service role, the CodeBuild project role and the cross-account deployment roles are three different things with three different permission sets. Collapsing them into one role is the most common way a pipeline ends up with production administrator rights.

Artefact integrity. Encrypt the artefact bucket with a customer-managed KMS key, grant decrypt only to the deployment roles that need it, and keep bucket versioning on so a rollback has something to roll back to.

Auditability. Deploy through infrastructure as code rather than console changes, so every production change is a reviewed commit. CloudTrail then records who ran what, and the repository records what it was.

Gates. Put the manual approval where the risk changes — usually between staging and production — not at every stage boundary, where it becomes a rubber stamp.

Rollback. Decide the rollback mechanism before the first production deployment, and test it. CodeDeploy can roll back automatically on a CloudWatch alarm; that is worth configuring even if the intention is to roll forward, because it bounds the duration of a bad release.

For how the cutover itself should be shaped, see software deployment strategies. For getting the same baseline infrastructure into many accounts, see cross-account infrastructure deployment.