How to Build a CI/CD Pipeline on AWS Using Developer Tools

A CI/CD pipeline on AWS is usually built from CodePipeline, CodeBuild, CodeDeploy, and a source repository such as CodeCommit or GitHub. The goal is simple. Every approved code change should build, test, scan, and deploy with as little manual handling as possible.

If your workloads already run on AWS, native Developer Tools are a practical choice. They work directly with IAM, Amazon S3 artifacts, Amazon ECR images, Lambda, EC2, ECS, Elastic Beanstalk, and CloudFormation. That tight fit matters when you deploy across staging, production, and sometimes multiple AWS accounts.

What AWS Developer Tools Do in a CI/CD Pipeline

AWS Developer Tools are managed services. You do not maintain Jenkins controllers, patch build agents, or run your own deployment scheduler. For many teams that is a fair trade. You lose some plugin depth compared with Jenkins or GitLab CI, but you gain native IAM controls and less platform maintenance.

Core services

• AWS CodePipeline: Orchestrates the release flow. It connects source, build, test, approval, and deployment stages.
• AWS CodeBuild: Runs build commands, tests, packaging, container builds, linting, and security checks inside managed build environments.
• AWS CodeDeploy: Automates deployments to EC2, on-premises servers, Lambda, and other supported targets.
• AWS CodeCommit: AWS managed Git source control. Note that CodeCommit is no longer available to new AWS customers, although existing customers can continue using it. New projects often use GitHub, GitLab, or Bitbucket through CodePipeline integrations.
• AWS CDK and CloudFormation: Define the pipeline and infrastructure as code so the same setup can be repeated across teams and accounts.
• Amazon ECR: Stores container images built by CodeBuild for ECS, EKS, or other container platforms.

A common production pattern is source, build, security checks, staging deploy, integration tests, manual approval, then production deploy. Keep it boring. Boring pipelines are easier to debug at 2 a.m.

Reference Architecture for a CI/CD Pipeline on AWS

For a typical web application running on EC2 or ECS, the pipeline looks like this:

1. A developer pushes code to the main branch.
2. CodePipeline detects the change through an event or webhook.
3. CodeBuild installs dependencies, runs tests, and creates an artifact or Docker image.
4. Optional parallel CodeBuild actions run linting, dependency scanning, and policy checks.
5. The artifact is deployed to staging with CodeDeploy, ECS, Lambda, or Elastic Beanstalk.
6. Integration tests run against staging.
7. A manual approval gate protects production.
8. CodeDeploy or the target AWS service rolls the release into production.

For container workloads, CodeBuild usually builds the Docker image, tags it with the commit SHA, pushes it to Amazon ECR, and passes image metadata to the deploy stage. For Lambda, CodeBuild commonly packages a zip file or synthesizes infrastructure using AWS SAM or CDK.

Prerequisites Before You Start

Do these first. Skipping IAM setup is the fastest way to get a pipeline that fails in three different stages for three different reasons.

• Create or choose a source repository. Use CodeCommit if your AWS account already has access, or use GitHub, GitLab, or Bitbucket.
• Install Git and AWS CLI v2 locally.
• Create an S3 artifact bucket, or let CodePipeline create one.
• Create service roles for CodePipeline, CodeBuild, and CodeDeploy.
• Decide your target runtime: EC2, Lambda, ECS, EKS, Elastic Beanstalk, or on-premises servers.
• Add a buildspec.yml file for CodeBuild.
• Add an appspec.yml file if you use CodeDeploy for EC2 or Lambda deployments.

Use least privilege IAM. In training labs, broad policies save time. In a real account, they create audit pain later.

Step 1: Connect the Source Stage

In CodePipeline, create a new pipeline and add a source stage. If you use GitHub, configure the connection through the AWS console. AWS uses a managed connection model rather than asking every pipeline to store a long-lived token.

Select the repository and branch. Most teams start with main for production-bound changes, then add branch-based pipelines later. Do not overcomplicate the first version.

Step 2: Configure CodeBuild

Create a CodeBuild project and point it at the source artifact from CodePipeline. Choose a managed image unless you need custom compilers or pinned operating system packages. For many Node.js, Python, Java, and .NET workloads, managed images are enough.

A basic buildspec.yml for a Node.js service might look like this:

version: 0.2
phases:
  install:
    runtime-versions:
      nodejs: 20
    commands:
      - npm ci
  pre_build:
    commands:
      - npm test
      - npm audit --audit-level=high
  build:
    commands:
      - npm run build
artifacts:
  files:
    - '**/*'

One small detail trips people up. Artifact paths are relative to the build environment working directory. If your build writes to dist but your artifact section points somewhere else, CodeBuild may fail during artifact upload with CLIENT_ERROR: no matching artifact paths found. The build can pass and still fail at the end. Check the upload phase, not only the test phase.

For production pipelines, add separate CodeBuild actions for:

• Unit tests
• Static analysis
• Dependency vulnerability checks
• Container image scanning
• Infrastructure template validation

AWS Prescriptive Guidance shows CDK-based pipelines with multiple parallel jobs, such as linting, security checks, and validation. That is a good pattern because slow security scans do not block fast unit tests from starting.

Step 3: Configure CodeDeploy

If you deploy to EC2, install and start the CodeDeploy agent on target instances. Attach an IAM instance profile so the instances can fetch deployment artifacts. Then create a CodeDeploy application and deployment group.

Your deployment group can target EC2 instances by tag, Auto Scaling groups, or other supported targets. Tag carefully. A mistyped environment tag can send staging code to the wrong fleet. I have seen this happen, and the post-incident meeting is not fun.

A simple EC2 appspec.yml often includes file copy instructions and lifecycle hooks such as BeforeInstall, AfterInstall, and ApplicationStart. Keep scripts idempotent. If ApplicationStart runs twice, it should not break the service.

For Lambda, CodeDeploy supports traffic shifting deployment configurations, including canary and linear options. Use them. Shipping 100 percent of traffic to a fresh function version is risky when a five-minute canary would catch many failures.

Step 4: Add Staging, Tests, and Approval Gates

A pipeline that deploys straight to production after unit tests is fine for a demo. It is not enough for most teams.

Add a staging deploy stage first. After staging, run integration tests through CodeBuild. These can call real endpoints, verify database migrations, check health routes, and test authentication flows.

Then add a manual approval action before production. Manual approvals are not anti-DevOps. They are useful when releases carry business risk, regulatory impact, or scheduled customer communication.

Step 5: Define the Pipeline as Code with AWS CDK

Clicking through the console is acceptable for learning. For anything long-lived, define the CI/CD pipeline on AWS with CDK v2 or CloudFormation.

CDK lets you version the pipeline, review changes in pull requests, and reproduce the same setup for another service. It also supports self-mutating pipelines, where a pipeline updates its own definition after a CDK change. That sounds magical the first time. Treat it with care. Require code review on pipeline code, because a bad change can remove a stage or loosen a permission.

A good CDK pipeline setup usually includes:

• Artifact bucket encryption
• Separate IAM roles per service
• Explicit environment accounts for dev, staging, and production
• Manual approvals for production
• Parallel CodeBuild validation steps
• CloudWatch alarms or deployment rollback signals

Security Practices You Should Add Early

Security checks should not be an afterthought. Put them in the pipeline from day one, even if the first version is basic.

• Scan dependencies: Use npm audit, pip-audit, OWASP Dependency-Check, Snyk, or your approved scanner.
• Scan containers: Use Amazon ECR image scanning or third-party tooling where policy requires it.
• Validate infrastructure: Run cdk synth, cfn-lint, and policy checks before deployment.
• Protect secrets: Store secrets in AWS Secrets Manager or Systems Manager Parameter Store, not in buildspec files.
• Review IAM: Avoid wildcard permissions in CodeBuild and CodePipeline roles unless there is a documented reason.

The xz Utils backdoor, tracked as CVE-2024-3094, was a reminder that build environments and dependencies are part of your attack surface. Pin critical tooling. Rebuild images regularly. Know what runs inside CodeBuild.

When AWS Native CI/CD Is the Right Choice

Use AWS Developer Tools when your deployment targets are mostly AWS, your security model depends on IAM, and your team wants managed pipeline infrastructure. It fits EC2, Lambda, ECS, EKS, Elastic Beanstalk, and multi-account AWS deployments well.

Use GitHub Actions, GitLab CI, Bitbucket Pipelines, or another external platform when your organization has already standardized there, especially for cross-cloud builds. A hybrid model is common. External CI builds the artifact, then AWS CodeDeploy or ECS performs the deployment.

To be blunt, do not choose AWS CodePipeline only because it is native. Choose it because its IAM integration, auditability, and AWS service coverage solve your actual release problem.

Skills to Build Next

If you want to build production-grade AWS pipelines, learn these in order:

1. Git workflow and branching strategy
2. IAM roles, policies, and trust relationships
3. CodeBuild buildspec syntax
4. CodeDeploy appspec files and rollback behavior
5. CodePipeline stages, actions, and artifacts
6. AWS CDK v2 for pipeline as code
7. Security scanning and policy-as-code basics

For structured learning, use this article as a hands-on lab outline and pair it with Global Tech Council courses in AWS, DevOps, cloud computing, and cybersecurity. If you are preparing for cloud engineering or DevOps roles, build one pipeline for a small app, then rebuild it with CDK. That second pass is where the real learning happens.

Final Next Step

Create a small API, add a buildspec file, deploy it to a staging environment, and put one manual approval before production. Once that works, move the whole CI/CD pipeline on AWS into CDK and add security checks as separate CodeBuild actions.