{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifujqmhxluguwrsstv357opjralnikxrhnqe5z3jog2u5tubmayli",
    "uri": "at://did:plc:4kcuqw6uzvwdbzmwtn65rtxx/app.bsky.feed.post/3mipnzhoerai2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreibqz6sjg426cvyo3h63kvbphfsndjz34knpehhkubzl2v2u7q7wc4"
    },
    "mimeType": "image/png",
    "size": 161310
  },
  "description": "Step-by-step setup for linking CodeBuild and CodePipeline: IAM roles, buildspec, artefacts, permissions and troubleshooting.",
  "path": "/codebuild-codepipeline-integration-step-by-step/",
  "publishedAt": "2026-04-05T01:50:05.000Z",
  "site": "https://aws.criticalcloud.ai",
  "tags": [
    "AWS CodeBuild",
    "AWS Free Tier vs paid services",
    "AWS CodePipeline",
    "GitHub",
    "Amazon S3",
    "AWS CodeCommit",
    "Bitbucket",
    "GitLab",
    "unnecessary costs",
    "Amazon Linux 2",
    "Ubuntu",
    "Docker",
    "Amazon ECR",
    "Choosing cost-effective AWS services",
    "AWS performance best practices",
    "Amazon CloudWatch",
    "AWS SNS",
    "Slack",
    "5 Steps to Set Up AWS Incident Manager",
    "5 Steps to Start with AWS CodeBuild",
    "Best Practices for AWS Test Automation Design",
    "Serverless Workflow Automation: Best Practices on AWS"
  ],
  "textContent": "**Manual deployments slow you down.** Automating your CI/CD workflow with AWS CodeBuild and CodePipeline eliminates these delays. Here's how it works:\n\n  * **CodePipeline** orchestrates your workflow, moving code through stages like Source → Build → Deploy.\n  * **CodeBuild** handles building, testing, and packaging your code - fully managed and serverless.\n  * Together, they reduce release cycle times, minimise errors, and streamline deployments.\n\n\n\nThis guide explains how to set up CodeBuild and CodePipeline for automated deployments. You'll learn about permissions, configuration, and testing to create a reliable CI/CD pipeline. Perfect for small teams, especially with AWS Free Tier vs paid services eligibility.\n\n**Key Steps:**\n\n  1. Set up IAM roles with precise permissions.\n  2. Configure your source code repository and `buildspec.yml`.\n  3. Create and link a CodeBuild project to CodePipeline.\n  4. Test and troubleshoot the pipeline for smooth operation.\n\n\n\n5-Step AWS CodeBuild and CodePipeline Integration Workflow\n\n## How to Integrate AWS CodePipeline with GitHub and CodeBuild: Complete Guide for CI/CD\n\n###### sbb-itb-0f2792e\n\n## Prerequisites for Integration\n\nBefore linking CodeBuild with CodePipeline, you need to set up a few key components. This groundwork helps prevent configuration problems down the line.\n\n### AWS Account and IAM Role Setup\n\nStart with an active AWS account and correctly configured IAM roles. You'll need **two separate service roles** : one for CodePipeline to manage the workflow and another for CodeBuild to handle the builds. The CodePipeline service role must include permissions like `codebuild:StartBuild` and `codebuild:BatchGetBuilds` to initiate and monitor builds. The CodeBuild service role, on the other hand, needs a trust policy that allows `codebuild.amazonaws.com` to assume the role via `sts:AssumeRole`.\n\nThe CodeBuild role also requires permissions for CloudWatch Logs (to log build activities), S3 (to fetch source code and store build outputs), and access to your source repository. If you're storing sensitive data in Systems Manager Parameter Store or Secrets Manager, grant the relevant permissions, such as `ssm:GetParameters` or `secretsmanager:GetSecretValue`. Additionally, the IAM user or role setting up the pipeline must have `iam:PassRole` permissions. Without this, assigning service roles during the setup process won't be possible.\n\n### Source Code Repository Requirements\n\nCodePipeline supports various source providers, including Amazon S3, AWS CodeCommit, GitHub, GitHub Enterprise Server, Bitbucket, GitLab, and GitLab Self Managed. For third-party repositories like GitHub or Bitbucket, AWS uses CodeConnections for authorisation. Ensure your CodePipeline service role includes the `codestar-connections:UseConnection` permission.\n\nYour repository should include a `buildspec.yml` file in its root directory. This file outlines the build commands and phases that CodeBuild will execute. If you're using GitHub or Bitbucket with the \"Full Clone\" option (which allows CodeBuild access to Git metadata), add the `codestar-connections:UseConnection` permission to the CodeBuild service role. **Tip** : Disable CodeBuild webhooks within the pipeline to avoid duplicate builds and unnecessary costs.\n\n### AWS Regions and Compatibility\n\nIt's crucial that all resources are in the same AWS Region. Your source repository, CodeBuild project, and CodePipeline must be created in a region where both services are supported. Additionally, CodePipeline requires a dedicated S3 bucket (known as the artifact store) in the same region to store intermediate data between pipeline stages. This bucket is separate from any S3 source bucket you might use. While CodePipeline supports cross-region actions for certain scenarios, keeping everything in one region simplifies the setup process and reduces latency.\n\nOnce these prerequisites are in place, you're ready to move forward and create your CodeBuild project.\n\n## Step 1: Create an AWS CodeBuild Project\n\nOnce you've got your prerequisites ready, it's time to set up the CodeBuild project that will handle your builds. Head over to the CodeBuild console and click on **\"Create build project\"**. Start by giving your project a **unique and meaningful name**.\n\n### Configure the Build Environment\n\nThe build environment determines how and where your builds are executed. You can choose from AWS-managed images, such as Amazon Linux 2 or Ubuntu Standard, or supply a custom Docker image from Amazon ECR or another registry. Next, pick a compute type: EC2 offers flexibility, while Lambda provides quicker start-up times.\n\nIf you're working with Docker image builds, make sure to enable **privileged mode** (note that this isn't supported for Windows). For environment variables, you can use Plaintext, Parameter Store, or Secrets Manager. Always avoid storing sensitive information, like AWS credentials or passwords, in plaintext. Instead, rely on **Secrets Manager** or **Parameter Store** to keep them secure and hidden from logs.\n\n### Set Artifacts and Buildspec File\n\nThe `buildspec.yml` file is where you define the commands that CodeBuild will run. By default, CodeBuild looks for this file in the root directory of your repository. Make sure your `buildspec.yml` includes build phases and an artifacts section (version 0.2 is recommended).\n\nWhen setting up the artifacts for your project, you can either select \"No artifacts\" or configure an S3 bucket as the destination. Even though CodePipeline will override these settings during execution, this configuration is still necessary to ensure compatibility with the pipeline setup wizard.\n\n**Important** : If you're planning to integrate this project with CodePipeline, make sure to disable the webhook option in the CodeBuild console. If left enabled, every commit will trigger two builds - one from the webhook and another from the pipeline - leading to unnecessary double billing and higher costs. Choosing cost-effective AWS services is essential for maintaining a lean pipeline..\n\nOnce these steps are complete, you can move on to assigning the required IAM role.\n\n### Assign IAM Roles\n\nFor CodeBuild to access AWS resources, it needs a service role. Assign a service role with the permissions it requires. Refer to the **AWS Account and IAM Role Setup** for a detailed list of permissions. Keep in mind that a single service role can be linked to up to 10 build projects.\n\n## Step 2: Set Up an AWS CodePipeline\n\nOnce your CodeBuild project is ready, the next step is to create a pipeline in the AWS CodePipeline console. Start by selecting **\"Create pipeline\"** , followed by **\"Build custom pipeline\"**.\n\n### Create the Pipeline\n\nBegin by giving your pipeline a **unique name**. Opt for **\"V2\"** to access advanced features such as stage-level retries and pipeline-level variables.\n\nFor the service role, you can either choose **\"New service role\"** - allowing CodePipeline to automatically generate the required IAM permissions - or select an **\"Existing service role\"** if you've already set one up. CodePipeline requires an S3 bucket for storing pipeline artefacts. You can use the **\"Default location\"** , where AWS creates a bucket named `codepipeline-[region-ID]-[random-number]`, or specify a **\"Custom location\"** if you prefer to use an existing bucket in the same region.\n\n### Add Source Stage\n\nThe first stage of every pipeline must be the source stage. Here, you'll connect your source code repository. CodePipeline supports several source providers, including **AWS CodeCommit** , **Amazon S3** , **GitHub (Version 2)** , **Bitbucket** , and **GitLab**.\n\nIf you're using **GitHub (Version 2)** , you'll need to create a connection via the AWS Connector for GitHub. Then, select your repository and branch. For **Amazon S3** , ensure the bucket has **versioning enabled** , as CodePipeline requires this to trigger automatically on changes. Specify the bucket name and the S3 object key (the ZIP file containing your source code). For **CodeCommit** , simply choose the repository name and branch (e.g., `main` or `master`).\n\nWhen setting the output artefact format, you can choose between **\"CodePipeline default\"** (which zips the source files) or **\"Full clone\"** (which performs a Git clone to include Git metadata). If your CodeBuild project needs to execute Git commands or access commit history, select \"Full clone\".\n\nBelow is a quick overview of the required configurations for each source provider:\n\nSource Provider | Required Configuration Fields | Change Detection Method\n---|---|---\n**AWS CodeCommit** | Repository name, Branch name, Output artefact format | CloudWatch Events\n**Amazon S3** | Bucket name (versioning enabled), S3 object key | CloudWatch Events / CloudTrail\n**GitHub (v2)** | Connection, Repository, Branch, Output artefact format | Webhooks / Connection events\n**Bitbucket Cloud** | Connection, Repository, Branch | Webhooks / Connection events\n\nOnce you've configured the source stage, you're ready to link it to your CodeBuild project in the build stage.\n\n### Prepare for Build Stage Integration\n\nWith the source stage configured, set up the pipeline to pass the output artefact to CodeBuild. The source stage generates an **\"Output artefact\"** (commonly named `SourceArtifact` by default), which will be used as the **\"Input artefact\"** for your CodeBuild project in the build stage.\n\nIt's important to ensure that all resources, such as S3 buckets and repositories, are located in the same region, as specified in the prerequisites. With this setup complete, you’re ready to integrate your CodeBuild project into the pipeline's build stage.\n\n## Step 3: Add CodeBuild to the CodePipeline Build Stage\n\n### Attach the CodeBuild Project\n\nOnce you've set up the source stage, click on **\"Add build stage\"** in the pipeline wizard. From the options, choose **AWS CodeBuild** as your build provider. Then, select your existing CodeBuild project from the **Project name** dropdown. Make sure the project is located in the same AWS Region as your pipeline.\n\nIn the **Input artefacts** field, select `SourceArtifact` from the previous stage. This step ensures that CodeBuild receives the source code from your repository. If your buildspec file generates compiled code or packages needed for later stages, specify an **Output artefacts** name, such as `BuildArtifact`.\n\nIf multiple input artefacts are involved, use the **PrimarySource** parameter to identify which artefact contains the buildspec file. Ensure the input artefact name matches the output artefact name exactly from the prior stage.\n\nComplete the build stage setup by configuring the appropriate settings to link CodeBuild with CodePipeline.\n\n### Configure Build Stage Settings\n\nYou can customise or add **environment variables** by specifying their Name, Value, and Type. Use **Plaintext** for non-sensitive data. For sensitive information, opt for **Parameter** (via Systems Manager Parameter Store) or **Secrets Manager**. Avoid storing sensitive credentials in plaintext to maintain security.\n\nFor build specifications, you can either use the _buildspec.yml_ file from your repository or input the build commands directly in the console. If you need to handle multiple builds at the same time, enable **Batch build** and select **Combine artefacts** to consolidate all outputs into a single file for the next stage.\n\nTo avoid duplicate builds and potential extra charges, make sure to disable webhooks in your CodeBuild project settings when it's part of a pipeline.\n\n## Step 4: Configure Permissions and IAM Policies\n\n### Service Role Permissions\n\nOnce the initial IAM setup is complete, it's time to refine service role permissions to ensure secure communication between AWS services. This alignment with AWS performance best practices ensures your infrastructure remains efficient and cost-effective. Both **CodePipeline** and **CodeBuild** require their own service roles to access the necessary resources. If you're using the AWS Console to create a pipeline, AWS can automatically generate a service role for you. This role, typically named `AWSCodePipelineServiceRole-[Region]-[Pipeline_Name]`, comes pre-configured with permissions for services like CodeBuild and S3.\n\nFor **CodeBuild** , its service role must allow `codebuild.amazonaws.com` to assume the role. It also needs permissions for CloudWatch Logs (such as `logs:CreateLogGroup`, `logs:CreateLogStream`, and `logs:PutLogEvents`), S3 artefact operations, and, if applicable, access to Amazon ECR for Docker images.\n\nTo follow the principle of least privilege, avoid using wildcards (`*`) when specifying ARNs for S3 buckets or CodeBuild projects. Instead, define exact ARNs. Additionally, include the `aws:SourceAccount` and `aws:SourceArn` condition keys in the CodeBuild trust policy. These measures help mitigate security risks, such as the \"confused deputy\" issue. Be aware that insufficient S3 permissions can cause the pipeline to fail, even if the build stage succeeds, as artefacts may not be stored correctly for subsequent stages.\n\n### Minimum Permissions for Users\n\nUsers responsible for creating or managing pipelines need the `iam:PassRole` permission, as highlighted in the prerequisites, to assign service roles to CodePipeline and CodeBuild resources. For most developers, the **`AWSCodeBuildDeveloperAccess`** managed policy is suitable. This policy provides all necessary functionality except for deleting projects or report groups. For users requiring full administrative control, the **`AWSCodeBuildAdminAccess`** policy is more appropriate, while auditors or monitoring users can use **`AWSCodeBuildReadOnlyAccess`**.\n\nIf users require access via the AWS Console, additional \"describe\" and \"list\" permissions for S3, CloudWatch, and IAM are necessary. However, these are not required for API-only access. For those using CodeCommit on Windows, ensure you clear outdated credentials from the Windows Credential Manager. This step prevents Git from using cached credentials that might lead to silent failures due to unauthorised access.\n\nWith these permissions in place, you can move forward to testing and verifying your pipeline configuration in the next step.\n\n## Step 5: Test and Verify the Pipeline\n\n### Run the Pipeline\n\nOnce the pipeline is set up, it will automatically start running. If you need to test it again later, you can manually trigger it by clicking the **Release change** button in the CodePipeline console. The console will show the progress of each stage - Source, Build, and Deploy - using statuses like Succeeded, In Progress, or Failed. CodePipeline relies on Amazon CloudWatch Events (or EventBridge) to monitor changes in your source repository (such as CodeCommit, S3, or GitHub). Every time you push new code, the pipeline is triggered automatically.\n\nAfter running the pipeline, confirm that the build has completed successfully and that all artefacts are stored correctly.\n\n### Verify Build and Artefacts\n\nTo check the build status, click on the **Details** or **CodeBuild** link in the Build stage. This will take you to the CodeBuild console, where you can view the **Build history**. Use the **View entire log** link to open Amazon CloudWatch Logs and review the logs for each phase - install, pre_build, build, and post_build. Ensure all phases complete without errors.\n\nNext, check the S3 bucket where the build artefacts are stored. The bucket name usually follows this format: `codepipeline-[region]-[random-number]`. Navigate to the folder named after your pipeline and its relevant subfolder for output artefacts. Download the latest ZIP file (sorted by 'Last Modified' date) and extract its contents. Verify that all the expected files and directories are present. For Docker-based builds, ensure the Amazon ECR repository contains the newly created image with the correct tag, such as the one specified by `IMAGE_TAG` or `CODEBUILD_RESOLVED_SOURCE_VERSION`.\n\nIf you encounter any issues, use the debugging tips provided below.\n\n### Debug Common Issues\n\nHere’s a quick troubleshooting guide for common problems:\n\nIssue Category | Symptom | Tool\n---|---|---\n**Permissions** | \"Access Denied\" or failure to fetch parameters | IAM Policy Simulator / CodeBuild Service Role settings\n**Environment** | Docker daemon fails to start | CodeBuild Project Environment \"Privileged\" flag\n**Source/Artefact** | Downstream stage cannot find files | Amazon S3 Artefact Bucket (check ZIP contents)\n**Logic/Tests** | Build succeeds but application fails | Amazon CloudWatch Logs (check test phase output)\n**Configuration** | Pipeline fails on start | CodePipeline \"Variables\" configuration\n\nIf the build fails at the beginning, check if the CodePipeline service role has `iam:PassRole` permissions. Also, confirm that the CodeBuild service role has the necessary access to the S3 artefact bucket. For Docker-based builds, ensure the \"Privileged\" flag is enabled in the environment configuration. Without this, builds requiring elevated privileges will fail.\n\nTo pinpoint issues, you can add `echo` commands in different phases of your `buildspec.yml` file. These commands will print variable values and execution steps in the logs, making it easier to trace where the problem lies.\n\n## Conclusion\n\nIntegrating **AWS CodeBuild** with **AWS CodePipeline** transforms how small and medium-sized businesses (SMBs) approach software delivery. By linking these services, you can create an automated pipeline where **CodePipeline** manages the workflow, and **CodeBuild** takes care of compiling, testing, and packaging - all without worrying about servers or infrastructure. This automation reduces manual errors, speeds up release cycles, and allows small teams to deploy quickly and efficiently.\n\nUsing the configuration outlined earlier, this integration simplifies operations while lowering deployment risks. With **AWS CodeBuild's** pay-as-you-go pricing, you only pay for the build minutes you use. Plus, many CI/CD setups qualify under the **AWS Free Tier**.\n\nOnce the setup is complete, you can expand its capabilities further. Automate unit tests, securely manage variables using **Systems Manager Parameter Store** , and enable real-time notifications through **AWS SNS** or tools like Slack. If you're managing multiple environments, consider setting up separate pipelines for development, staging, and production. This approach helps maintain structure and reduces potential risks.\n\nAs Full-Stack Developer Adekola Olawale explains:\n\n> Continuous Integration and Continuous Deployment (CI/CD) has become the backbone of modern software delivery.\n\n## FAQs\n\n### Why do I need separate IAM roles for CodePipeline and CodeBuild?\n\nWhen using AWS, assigning **separate IAM roles** for CodePipeline and CodeBuild is a smart move to maintain **security** and enforce **least privilege access**. CodeBuild requires a role that focuses solely on permissions for build-related tasks, while CodePipeline needs a role to handle pipeline stages, such as triggering CodeBuild and managing deployments. By keeping these roles distinct, you minimise security risks, avoid privilege escalation, and gain better control over permissions tailored to the specific needs of each service.\n\n### What’s the minimum IAM permission set to get this pipeline working?\n\nTo configure the pipeline, you'll need permissions for the following actions: `codepipeline:*`, `iam:ListRoles`, `iam:PassRole`, and several S3-related actions such as `s3:CreateBucket`, `s3:GetBucketPolicy`, `s3:GetObject`, `s3:ListAllMyBuckets`, `s3:ListBucket`, and `s3:PutBucketPolicy`. Additionally, make sure the CodeBuild service role is granted only the permissions it requires to interact with AWS services, adhering to the principle of least privilege.\n\n### How do I stop duplicate builds (and extra costs) in CodeBuild + CodePipeline?\n\nTo cut down on duplicate builds and unnecessary expenses in AWS CodeBuild when using CodePipeline, you can manually stop unwanted builds.\n\n  * **Using the AWS Console** : Navigate to the **Build history** , select the build you want to stop, and click **Stop build**.\n  * **Using the AWS CLI** : Run the command `aws codebuild stop-build --id <build-id>` to halt the build.\n\n\n\nTo prevent these builds from starting automatically, consider disabling webhooks (e.g., for GitHub) or tweaking your pipeline triggers to avoid triggering builds unnecessarily.\n\n## Related Blog Posts\n\n  * 5 Steps to Set Up AWS Incident Manager\n  * 5 Steps to Start with AWS CodeBuild\n  * Best Practices for AWS Test Automation Design\n  * Serverless Workflow Automation: Best Practices on AWS\n\n",
  "title": "Integrate CodeBuild with CodePipeline: Step-by-Step",
  "updatedAt": "2026-05-05T10:01:43.096Z"
}