What CI/CD Is and the AWS Developer Tools Suite
This is the first part
Deploying an app the first time is easy: SSH into the server, git pull, restart the service, done. The trouble starts on the tenth time — when you have to remember the exact order of steps at midnight, when a skipped step breaks production, or when a new teammate has no idea what "deploy" actually involves. A process that lives in one person's head is not a process. This series builds the replacement: an automated pipeline that carries code from commit to running on a server, using AWS's own CI/CD tooling, and everything done with the AWS CLI.
This first article creates no resources. We need to understand first what CI/CD is, which pieces AWS provides, and how they fit together — so that in later articles, when you type a command, you know what you're building.
CI and CD: two terms often conflated
Continuous Integration (CI) is the habit of integrating code frequently: every time you push code, a system automatically rebuilds and runs tests, so bugs surface in minutes instead of near release. Continuous Delivery (CD) goes one step further: after build and test, the software is always in a release-ready state, and promoting it to a given environment is a button press (or automatic). The AWS docs describe CodePipeline as a "continuous delivery service for modeling, visualizing, and automating the steps required to release your software."
The easiest way to picture it is a chain: new code enters at one end, runs through the stages (source, build, test, staging, production), and comes out the other end ready to run in production. Each stage does one job, the next stage only starts when the previous one finishes, and if a stage fails the chain stops — no broken code can slip through to production.
commit code
│
▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────────┐
│ Source │──▶│ Build │──▶│ Test │──▶│ Deploy │──▶ production
│ (repo) │ │ compile │ │ run test│ │ to server │
└─────────┘ └─────────┘ └─────────┘ └─────────────┘
fail at any stage ──▶ chain stops, no deploy
The AWS Developer Tools suite
AWS doesn't package CI/CD as a single product but as several separate services, each handling one stage. Wiring them together is your job — and that's also the strength: you can swap individual pieces. The five services we use in this series:
CodeCommit handles the source stage. It's AWS's Git hosting service — a private, encrypted Git repo, integrated with IAM for access control. Your code lives here, and CodePipeline listens for each new commit to kick off the chain. (An honest note: AWS stopped onboarding new customers to CodeCommit in 2024, so an account that has never used it may not be able to create a repo; we use it here because it's the original source piece of the Code* suite and integrates most cleanly with the rest.)
CodeBuild handles the build and test stage. The docs describe it as a "fully managed build service that compiles source code, runs tests, and produces artifacts, scaling automatically." You declare the build steps in a buildspec.yml file, CodeBuild stands up a temporary environment, runs those steps, then throws the environment away — there's no build server for you to keep alive.
CodeDeploy handles the deploy stage. The docs: "a service that automates application deployments to EC2, on-premises machines, serverless Lambda functions, or ECS services." This series targets EC2: CodeDeploy pushes the new version to the instances, runs lifecycle scripts (stop the old app, install the new one, start it, validate), and can do both in-place and blue/green.
CodePipeline is the conductor. It models the whole chain as stages, each containing actions, and orchestrates them: run this stage, take the result (artifact), pass it to the next. It doesn't build or deploy anything itself — it calls the other services to do that.
CodeArtifact is the internal package store (npm, pip, Maven...). When a build needs the company's private libraries, or you want to control dependency versions, CodeArtifact sits in the middle.
Assembling them into a chain
The five pieces above combine into the picture we'll build up over the series:
CodeCommit repo
│ (new commit)
▼
┌──────────────────── CodePipeline ────────────────────┐
│ Source Build Deploy │
│ (pull code) ▶ CodeBuild ▶ CodeDeploy │
│ (buildspec.yml) (appspec.yml) │
└──────┬──────────────┬───────────────────┬────────────┘
│ │ │
artifact CodeArtifact EC2 / ASG
to S3 (internal packages) (via agent)
CodePipeline keeps time; CodeBuild turns source into an artifact (the built code bundle) stored on S3; CodeDeploy takes that artifact and pushes it to the EC2 instances. CodeCommit supplies the source, CodeArtifact supplies packages when the build needs them. We'll dissect each piece on its own (Part II–IV), then wire them together with CodePipeline (Part V), and close with a complete pipeline in the capstone.
Why use the Code* suite instead of Jenkins or GitHub Actions
Fair question, since the other tools also do CI/CD well. The reason to choose the AWS Developer Tools when the target is AWS infrastructure: it integrates deeply with IAM (access control via roles instead of stored keys), runs inside your VPC (build/deploy can reach internal resources without going over the Internet), and is fully managed by AWS (no runner or build server to operate). In exchange, it ties you more tightly to AWS. No choice is absolutely "right"; this series focuses on the case where the infrastructure lives on AWS, where the Code* suite pays off most.
Prerequisites
The series builds everything with AWS CLI v2. Check that it's installed and configured:
$ aws --version
aws-cli/2.34.33 Python/3.14.4 Darwin/25.3.0 exe/arm64
$ aws sts get-caller-identity --output table
-----------------------------------------------------
| GetCallerIdentity |
+---------+-----------------------------------------+
| Account| 111122223333 |
| Arn | arn:aws:iam::111122223333:user/admin |
| UserId | AIDAEXAMPLEID... |
+---------+-----------------------------------------+
get-caller-identity confirms which account and identity the CLI is using — always run it before you start so you don't accidentally operate on the wrong account (the real account number here has been replaced with 111122223333). The series uses region ap-southeast-1; you can set the default region:
$ aws configure get region
ap-southeast-1
You need enough IAM permissions to create the Code* resources, S3, EC2, and IAM roles. The lab stays on free-tier where possible; articles with EC2/ALB will cost a few cents if left running, so each one includes a cleanup step.
Wrap-up
CI automatically builds and tests on every push; CD keeps the software always release-ready. AWS splits CI/CD into separate services: CodeCommit holds the code, CodeBuild builds and tests, CodeDeploy deploys (we target EC2), CodePipeline orchestrates, CodeArtifact supplies packages. The overall picture is a chain CodeCommit → Source → Build → Deploy → EC2 that we'll build up incrementally.
The next article lays the foundation for everything that follows: creating the IAM service roles that CodeBuild, CodeDeploy, and CodePipeline need to function, plus an S3 bucket to hold artifacts — all with the AWS CLI. With that foundation in place, Article 3 builds a CodeCommit repo and pushes real code to it.
This is the first part