Developer Tools and DevOps

There are two broad options, and they mix well: keep the pipeline in the system that already hosts the code (GitHub Actions, GitLab CI/CD, Jenkins) and let it call AWS with short-lived credentials, or use the AWS-native services that run entirely inside the account.

A pipeline should never hold an access key. GitHub issues each workflow job a signed OIDC token, and the official aws-actions/configure-aws-credentials action exchanges it with AWS STS for a short-lived session of an IAM role. The identity provider, the role and its trust policy are created once; see Identity and Access for the console and CLI steps and the trust policy JSON. The workflow then needs only the id-token: write permission and the role ARN, which is an identifier and not a secret.

Three details matter in practice:

CodeBuild is a managed build service: each build runs in a fresh container (or a Lambda-based environment, a reserved-capacity fleet instance, or a macOS instance) that executes the commands in a buildspec.yml. There is no build server to patch, and you pay per build minute for the compute type used.

CodePipeline models a release process as stages (source, build, test, approval, deploy) made of actions. Two pipeline types exist, and the choice affects both features and price:

Source: What type of pipeline is right for me?. A typical Bookshelf pipeline is source (a GitHub repository through a CodeConnections connection) → build (CodeBuild, producing imagedefinitions.json) → approval (manual) → deploy (the Amazon ECS standard action, which updates the service with the new image).

CodeDeploy automates deployments to three compute platforms: EC2/on-premises servers (in-place or blue/green, with an agent on each instance), Lambda (traffic shifting between function versions with canary, linear or all-at-once configurations) and Amazon ECS (blue/green with a replacement task set). The unit of deployment is an application revision described by an AppSpec file. An EC2 deployment of a Spring Boot jar looks like this:

Derived from the AppSpec file reference. The instances need an instance profile with read access to the revision bucket and the CodeDeploy agent installed and running (see Amazon EC2 and Auto Scaling for launch templates and Auto Scaling groups that install it).

Derived from create-deployment-group and create-deployment. In the console, use CodeDeploy → Applications → Create application, then Create deployment group.

CodeDeploy is no longer the only way to do blue/green on ECS. ECS has native blue/green deployments (since 2025-07) and linear and canary strategies (since 2025-10), and CloudFormation can also drive an ECS blue/green deployment. Older guides that wire two target groups and a test listener through CodeDeploy describe a pattern that now has simpler alternatives; see ECS Deployments, Scaling and Networking. CodeDeploy remains the right tool for EC2 fleets and for Lambda traffic shifting outside SAM (SAM’s DeploymentPreference uses it under the hood).

CodeArtifact is a managed package repository for Maven, Gradle, npm, pip, NuGet and other formats. Repositories live in a domain, can chain upstream repositories, and can have an external connection to a public registry such as Maven Central or npmjs, which gives builds a cached, access-controlled path to open-source dependencies. Packages in CodeArtifact cannot be made public, and every client authenticates with a short-lived authorization token created from AWS credentials.

Derived from the CodeArtifact CLI reference. The Maven settings.xml then references ${env.CODEARTIFACT_AUTH_TOKEN} as the password for the endpoint URL (see Use CodeArtifact with mvn). In a CodeBuild buildspec, fetch the token in pre_build; in GitHub Actions, fetch it after configure-aws-credentials. In the console, open CodeArtifact → Domains → Create domain, then Repositories → Create repository and add the upstream or external connection in the repository settings.

CodeCommit hosts private Git repositories in your account, with IAM access control and pull requests. Its status matters because older guides disagree: it stopped accepting new customers in mid-2024, and AWS announced on 2025-11-24 that it is back in full general availability, with new customer sign-ups open, unchanged pricing and a roadmap that includes Git LFS support and additional Regions. Treat an older statement that CodeCommit is closed or being retired as out of date. For a team starting today the practical question is not availability but ecosystem: GitHub, GitLab and Bitbucket integrate with more tools, while CodeCommit keeps source code inside the account and under IAM, which can matter for regulated workloads.

Derived from create-repository and the git-remote-codecommit setup page (install git-remote-codecommit first so the remote helper can use your CLI credentials). CodeCommit repositories work as CodePipeline sources and CodeBuild sources like any other. The service’s own documentation lists workloads that suit Git poorly (frequently changing large files, databases, audit trails, backups) and points to S3, DynamoDB and AWS Backup instead.

CDK Pipelines (the aws-cdk-lib.pipelines module) builds a CodePipeline-based pipeline from CDK code. It is self-mutating: when you add a stage or stack to the application, the pipeline first updates itself, then deploys the new stacks, typically to several accounts. Every target environment must be bootstrapped (cdk bootstrap) with a trust relationship to the pipeline account. Source can be GitHub through a connection, CodeCommit or S3. See Continuous integration and delivery (CI/CD) using CDK Pipelines.

SAM pipelines generate pipeline definitions for serverless applications:

Derived from the SAM CI/CD documentation. Supported targets include CodePipeline, GitHub Actions, GitLab CI/CD, Bitbucket Pipelines and Jenkins, and the bootstrap step can configure OIDC so no long-lived keys are stored. Both tools produce what this page already showed by hand; use them when you manage several accounts or stages and want the pipeline kept consistent.

AWS CloudShell is a browser-based shell launched from the console (the terminal icon in the navigation bar). It is already authenticated with your console credentials, so there is nothing to configure before running aws commands, and it offers Bash, PowerShell and Zsh. The environment is based on Amazon Linux 2023 with the AWS CLI v2, Git, Python, Node.js, tmux, vim and other tools pre-installed. Each Region gives you 1 GB of persistent storage in $HOME at no additional charge; the rest of the environment is recycled when the session ends. CloudShell has no extra charge, you pay only for the resources you create from it. VPC environments place the shell in a subnet of your VPC with chosen security groups (to reach private databases, for example), but they have no persistent storage and time out after 20 to 30 minutes of inactivity. Use CloudShell for one-off commands and walkthroughs from this section when you do not want to install the CLI locally; use a local shell with SSO profiles for daily work (see Getting Started with AWS).

See What is AWS CloudShell?.

AWS Cloud9 was a browser IDE backed by an EC2 instance. It is no longer available to new customers (closed since 2024-07); existing customers can continue to use it, and AWS publishes a blog post on migrating to the IDE toolkits or CloudShell. Older guides that start a tutorial by launching a Cloud9 environment should be followed from a local IDE with the AWS Toolkit, or from CloudShell, instead.

Amazon CodeCatalyst (an integrated project, repository, workflow and dev-environment service) is also no longer open to new customers (closed 2025-11-07); existing customers can continue, and the documentation has a migration guide. See What is AWS Cloud9? and What is Amazon CodeCatalyst?.

AWS Amplify Hosting is a Git-based hosting service for web applications: connect a repository (GitHub, Bitbucket, GitLab or CodeCommit), and each push builds and deploys to the AWS content delivery network with feature-branch environments, pull-request previews, custom domains, redirects and rewrites, and password-protected branches. It supports server-rendered frameworks (such as Next.js and Nuxt), single-page applications (React, Angular, Vue) and static site generators. Amplify Gen 2 adds a TypeScript, code-first way to define a backend (data, authentication, storage, functions) that deploys as CloudFormation through CDK. It is a good fit when a small team wants one opinionated workflow for a JavaScript front end; for the Bookshelf static front end with full control over the bucket, certificate and cache behaviour, the S3 plus CloudFront pattern in S3 Security and Static Hosting and CloudFront and CDN Delivery is the more explicit alternative, and the build and deployment steps for common front-end frameworks are in Build and Deployment and Deployment & Self-Hosting. See AWS Amplify Hosting User Guide.

No prices are repeated here because they change; use the dated pricing pages linked in the references.

Defaults checked on 2026-10-01; most are adjustable through Service Quotas.

The other services' quotas (CodePipeline pipelines and actions, CodeDeploy deployment groups, CodeArtifact repositories and package sizes) are on their own quota pages, linked below. AssumeRoleWithWebIdentity sessions obtained by configure-aws-credentials have a configurable duration limited by the role’s maximum session duration (one hour by default), so very long jobs need a longer maximum or a credential refresh step.

Delete in dependency order. IAM roles created for the pipelines are removed after the resources that use them, and the OIDC provider is shared with other pipelines, so delete it only if nothing else uses it (see Identity and Access).

Derived from the CLI reference pages for delete-pipeline, delete-project, delete-application and delete-domain. A CodeArtifact domain can only be deleted after its repositories. A pipeline’s artifact bucket may be versioned; if so, empty all versions and delete markers first (see S3 Object Storage). delete-repository on CodeCommit is irreversible, so confirm the code exists elsewhere. CloudShell and the IDE toolkits create nothing to clean up beyond the resources you deployed through them; stacks deployed with SAM or CDK are removed with sam delete or cdk destroy.