This is a step-by-step AWS CodePipeline tutorial for anyone who needs to deploy to EC2 using CodeCommit, CodeBuild, and CodeDeploy together. I set this exact pipeline up recently and kept notes as I went, so this is the walkthrough I wish I'd had — console clicks and all.
The pipeline covers the standard flow: pull source from CodeCommit, build it with CodeBuild, and deploy straight to an EC2 instance with CodeDeploy. No test stage, no load balancer — just the core CodePipeline setup most small-to-mid apps actually need to get from git push to a running EC2 instance.
If you want to cross-check any step against the source, AWS's own walkthrough for this exact flow is here: Tutorial: Create a simple pipeline (CodeCommit repository).
Before you start
Make sure you've got:
- Console access with permissions for CodePipeline, CodeCommit, CodeBuild, and CodeDeploy
- Your source code already pushed to a CodeCommit repo
- Three IAM service roles created ahead of time: one for CodePipeline, one for CodeBuild, one for CodeDeploy (EC2)
- A target EC2 instance with the CodeDeploy agent installed and an IAM instance profile attached
- A
buildspec.ymlin the root of your repo
If any of those are missing, sort them out first — the pipeline wizard will let you create some things inline, but the IAM roles are much easier to set up beforehand.
Step 1: Confirm your CodeCommit repo exists
Nothing fancy here — just make sure the repository you want to build from is already in CodeCommit with your code pushed to the branch you plan to deploy from.
Step 2: Open CodePipeline and start a new pipeline
From the AWS Console, go to CodePipeline → Create pipeline.
Step 3: Choose "Build custom pipeline"
This gives you full control over each stage instead of using one of the templated flows.
Step 4: Configure the pipeline basics
| Setting | Value |
|---|---|
| Pipeline name | whatever makes sense for your app/environment |
| Execution mode | Superseded |
| Service role | Existing service role |
| Role ARN | arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourCodePipelineServiceRole> |
| Advanced settings | Defaults are fine to start |
Step 5: Add the source stage
| Setting | Value |
|---|---|
| Source provider | AWS CodeCommit |
| Repository name | your repo |
| Branch name | whichever branch this pipeline should track (e.g. main, qa, staging) |
| Other settings | Defaults |
Step 6: Setting up the CodeBuild stage
Set Build provider to AWS CodeBuild.
If you already have a CodeBuild project for this app, just search for it and select it. If not, here's what a fresh project looks like (full console walkthrough here):
| Setting | Value |
|---|---|
| Project name | name it after your app |
| Environment – OS | Amazon Linux |
| Environment – Runtime | Standard |
| Environment – Image | aws/codebuild/standard:6.0 |
| Service role | Existing service role |
| Role ARN | arn:aws:iam::<YOUR_ACCOUNT_ID>:role/service-role/<YourCodeBuildServiceRole> |
| Buildspec | Use a buildspec file |
| Batch configuration / Logs | Defaults |
After creating it, go back and select it from the project list — the wizard doesn't always auto-select a project you just created.
Optional environment variables, if your build needs them:
| Name | Example value |
|---|---|
PROFILE_NAME |
qa |
HOST_ENTRY |
<your-ec2-hostname>:<your-ec2-private-ip> |
Leave build type as Single build unless you specifically need batch builds.
Step 7: Skip the test stage
Unless you're wiring up an automated test stage separately, you can skip this one entirely.
Step 8: Setting up the CodeDeploy stage for EC2 deployment
| Setting | Value |
|---|---|
| Deploy provider | AWS CodeDeploy |
| Input artifacts | BuildArtifact |
| Application name | select existing, or create new |
If you don't have a CodeDeploy application yet:
- Go to CodeDeploy → Applications → Create application
- Set Compute platform to EC2/On-Premises
- Create a deployment group with:
| Setting | Value |
|---|---|
| Service role ARN | arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourEC2CodeDeployRole> |
| Deployment type | Default (in-place, unless you need blue/green) |
| Environment configuration | Amazon EC2 instances |
| Instance name/tag | whatever tag identifies your target instance(s) |
| Load balancer | leave unchecked if you're not using one |
Step 9: Review and create
Double check every stage, then hit Create pipeline. It'll kick off an initial run immediately.
A few things I'd flag for anyone doing this
- Double-check your IAM trust relationships before you start. Half the "pipeline failed" errors I hit came down to a service role missing a trust policy, not the pipeline config itself.
- Never commit real account IDs, role ARNs, or internal hostnames into a public repo or a public writeup. It's an easy habit to slip into when you're copying from your own working setup — always swap in placeholders before sharing.
-
Validate your
buildspec.ymllocally (or withaws codebuild start-buildfirst) before wiring it into a full pipeline. Debugging a broken buildspec through the pipeline UI is slower than catching it upfront. - If you're running this across multiple environments (dev/QA/prod), keep the environment-specific values — account IDs, hostnames, role ARNs — in a separate config reference rather than hardcoding them per pipeline. Makes it much easier to replicate later.
That's the whole flow. Happy to answer questions if anyone's stuck on a specific stage.
Top comments (0)