CI/CD on AWS: the options, a reference pipeline, and who builds it.
A working AWS pipeline is build, test, scan, push to Amazon ECR, deploy to ECS, EKS or Lambda, and verify, with environments, approvals, OIDC instead of stored keys, and a rollback that works. For most teams the default is GitHub Actions (or GitLab CI) over OIDC deploying to ECS on Fargate. This page covers the real options, a reference pipeline, blue-green and canary rollouts, secrets, IaC and rollback.
- A real AWS CI/CD pipeline has six stages: build, test, security scan, push the image to Amazon ECR, deploy (ECS, EKS or Lambda), and verify. The tool matters less than how you handle environments, approvals, secrets and rollback.
- For most teams in 2026 the default is GitHub Actions or GitLab CI authenticating to AWS over OIDC (no long-lived keys), deploying to ECS on Fargate or EKS, with infrastructure as code (Terraform, OpenTofu or CDK) in the same pipeline. CodePipeline and CodeBuild fit when you want everything inside your AWS account; Argo CD when you do GitOps on Kubernetes.
- Build the image once, tag it with the commit SHA and promote that exact image to production. Use blue-green or canary with automatic rollback on CloudWatch alarms for production, and keep database migrations backward-compatible so rollback is safe.
IWhat good CI/CD on AWS means in 2026
Continuous integration: every commit is built, tested and scanned automatically. Continuous delivery: every change that passes can be released safely, on demand or automatically.
A good pipeline is fast (pass or fail in minutes), reproducible (build the container image once and promote that exact image; never rebuild per environment) and safe (a bad deploy is caught before production or rolled back automatically). It is also auditable and least-privilege: every deploy traces to a commit and an actor, and the pipeline assumes a narrowly scoped IAM role. A long-lived AWS_ACCESS_KEY_ID in CI is a finding; OIDC federation removes it.
The tools are commoditized: GitHub Actions, GitLab CI, CodePipeline, Jenkins and Argo CD all ship code to AWS reliably. The work is the design around them: environment promotion, approval gates, preview environments, the rollout strategy, secrets, IaC in the same flow, and a tested rollback.
IIThe options: GitHub Actions, GitLab CI, CodePipeline, Jenkins, Argo CD
The right tool depends on where your code lives, how much you want inside the AWS IAM boundary, and whether you deploy to Kubernetes. Mixing is normal.
GitHub Actions: the default for code on GitHub
Authenticate with aws-actions/configure-aws-credentials over OIDC. Pin third-party actions to a commit SHA (unpinned actions are a supply-chain risk), and consider self-hosted runners on EC2 or Fargate for heavy builds or jobs that need VPC access.
GitLab CI: one tool for source, CI and registry
Supports OIDC to AWS. Self-managed runners are infrastructure you own, and built-in scanning depends on your license tier.
AWS CodePipeline and CodeBuild: everything inside the account
Pipeline, build compute and deploy all live inside your AWS account and IAM boundary. CodeBuild runs a buildspec.yml; CodeDeploy handles ECS, Lambda and EC2 deploys with native blue-green and canary; CodeConnections links GitHub or GitLab as the source. A good fit for regulated teams. CodeCommit is effectively legacy for new repos.
Jenkins: when you already have it
Flexible and runs anywhere, but it is a server fleet you operate. For a greenfield AWS project in 2026, most teams pick GitHub Actions or CodePipeline instead.
Argo CD: GitOps on EKS
Git is the source of truth for cluster state and Argo CD reconciles the cluster to match. It pairs with a CI tool (CI builds the image and bumps the manifest; Argo CD deploys). Kubernetes only.
IIIA reference pipeline: build, test, scan, push to ECR, deploy, verify
The same six stages apply in GitHub Actions, GitLab CI or CodePipeline; only the syntax changes. The unit of promotion is an immutable image in Amazon ECR, tagged with the commit SHA (for example :git-9f3a1c2).
- 1. Build: Build the container image from a multi-stage Dockerfile with a pinned base image and layer caching. Tag it with the commit SHA.
- 2. Test: Unit and integration tests against the built artifact. Keep it to a few minutes where possible.
- 3. Scan: SAST on the code, dependency scanning for known CVEs, image scanning (ECR scan-on-push with Amazon Inspector, or Trivy or Grype), IaC scanning (Checkov, tfsec) and secret scanning, with a severity threshold that fails the build.
- 4. Push to ECR: Push the tested image to Amazon ECR with immutable tags and lifecycle policies.
- 5. Deploy: Roll the new image to an ECS service, an EKS deployment or a Lambda alias with a controlled rollout (rolling, blue-green or canary), not a hard replace.
- 6. Verify: Post-deploy health checks and smoke tests with automatic rollback on failure. CodeDeploy can gate on CloudWatch alarms; Argo Rollouts on metrics.
ECS on Fargate is the lowest-overhead target: no nodes, native CodeDeploy blue-green. EKS gives you full Kubernetes and GitOps at the cost of running a cluster. Lambda deploys use versions and weighted aliases. Most early-stage teams are best served by ECS on Fargate and move to EKS when Kubernetes-specific needs appear.
Build the image once, tag it with the commit SHA, and promote that exact artifact through every environment. Rebuilding per environment is the most common source of "passed in staging, broke in prod."
IVEnvironments, approval gates and preview environments
The path from merge to production is defined by how many environments you promote through, where the human approval sits, and whether each pull request gets its own environment.
A sane default is dev, staging and production, ideally in separate AWS accounts under Organizations. The same image flows through all three. Lower environments deploy automatically; production deploys after a manual approval (a required reviewer in GitHub environments, a manual job in GitLab, a manual-approval action in CodePipeline) until you trust your tests and rollback enough for continuous deployment.
Preview environments are the high-leverage upgrade: each pull request gets a short-lived copy of the app (its own ECS service or Kubernetes namespace and URL) that is torn down when the PR closes. Add branch protection, required status checks, required reviewers and a rule that only an approved workflow on main can assume the production deploy role. Auditors and enterprise customers ask about these.
VRolling, blue-green and canary: how the rollout happens
How traffic moves to the new version is where outages are prevented or caused. AWS supports all three patterns natively.
Rolling replaces tasks a few at a time; simplest and cheapest, the ECS and EKS default, but old and new versions serve together and a bad release reaches some users first. Blue-green runs a full parallel environment, validates it and flips traffic at the load balancer; rollback is instant because the old version is still running. Canary sends a small slice of traffic (say 10%) first, watches alarms, then shifts the rest or rolls back automatically.
On ECS and Lambda, AWS CodeDeploy does blue-green and canary with automatic rollback on CloudWatch alarms (for example the ECSCanary10Percent5Minutes configuration). On EKS, Argo Rollouts (or Flagger) gives metric-gated canaries. At the raw layer it is two ALB target groups with weighted forwarding. Recommendation: rolling for dev and staging, blue-green or canary for production, gated on error rate, latency and a synthetic smoke test.
| Strategy | How traffic shifts | Rollback | Extra cost | Native AWS support |
|---|---|---|---|---|
| Rolling | Replace a few tasks at a time | Redeploy the previous version | None | ECS and EKS default |
| Blue-green | Validate green, flip 100% at the load balancer | Instant: flip back to blue | Two environments briefly | CodeDeploy (ECS, Lambda) |
| Canary | Small share first, then the rest if healthy | Automatic on alarm; only a slice exposed | Small | CodeDeploy, Argo Rollouts |
VISecrets, IaC in the pipeline, and rollback
Authentication, infrastructure and rollback are where most homegrown pipelines are weakest.
Secrets: OIDC for AWS access, Secrets Manager for the app
The pipeline authenticates to AWS with OIDC: an IAM OIDC identity provider plus a role whose trust policy is scoped to a specific repo, branch and environment. The job gets short-lived credentials; there is no key to rotate or leak.
Application secrets (database URLs, API keys) live in AWS Secrets Manager or SSM Parameter Store, encrypted with KMS and injected into ECS tasks, EKS pods or Lambda at deploy time. Never bake them into the image or print them in CI logs.
Infrastructure as code in the pipeline
Terraform (BSL-licensed), OpenTofu (the open fork), AWS CDK, CloudFormation or Pulumi. Run a plan on the pull request so reviewers see the change, and an apply on merge behind the production approval. Use remote locked state, post plan output to the PR, and block non-compliant changes with policy as code (Checkov, OPA).
Rollback you have tested
With an immutable SHA-tagged image, rollback is "redeploy the previous tag": blue-green flips back in seconds, canary rolls back on the alarm, rolling redeploys the last good task definition. Database migrations are the exception: make them backward-compatible (expand, then contract: add the new column, write both, backfill, remove the old one later) so the previous version still runs against the new schema. Rehearse the rollback before you need it.
VIIBest practices and common pitfalls
None of these are exotic. All are skipped under deadline pressure, and all are cheap to fix early.
- Build once, promote the artifact: One SHA-tagged image through every environment.
- OIDC, not static keys: Zero long-lived access keys in CI secrets.
- Least-privilege deploy roles: A role scoped to exactly what the pipeline deploys, not a shared admin role.
- Fail the build on real findings: Tests, dependency, image and IaC scans with a threshold that blocks merges.
- Gate production on signals: Health checks, error-rate and latency alarms and a smoke test that can trigger rollback.
- IaC planned on pull requests: Plan on PR, apply on merge, remote locked state, policy as code.
- Keep pipelines fast: Cache dependencies and layers and run test and scan stages in parallel.
Avoid: long-lived AWS keys in CI; one admin role shared by the whole pipeline; rebuilding the image per environment; hard-replace deploys with no health gate; secrets in images or logs; terraform apply from a laptop; console drift; unpinned third-party actions; and a rollback procedure nobody has run.
VIIIDoing it yourself, or with a partner
Everything above is doable in-house. If nobody on the team has time to become a pipeline expert, a vetted AWS partner can build it.
CloudRoute matches you with one vetted AWS partner who builds the pipeline end to end: CI/CD in the tool that fits your stack, OIDC, the ECR and ECS, EKS or Lambda deploy, blue-green or canary, secrets in Secrets Manager, IaC, preview environments, and a rollback handed over tested. We reply within 24 hours; your matched partner reaches out within 5 business days.
Who pays: a pipeline build on its own is normal paid work. AWS funding that a partner can file comes through three routes: MAP when you migrate to AWS (for example, moving off Heroku), POC when you test something, and incremental workload (IW) funding when you are already on AWS and launch new work such as a new product, customer or AI feature. If your pipeline work is part of one of those, the partner checks whether it qualifies: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself: AWS Activate Founders ($1,000 to start, up to $5,000) if no investor backs you, or AWS Activate Portfolio (up to $200,000) with the Org ID from your VC, accelerator or angel group if it is an Activate Provider. A consulting partner cannot file Activate for you, and credits pay for AWS usage, not a partner's invoice.
Repo access, which AWS accounts, your deploy target (ECS, EKS or Lambda) and how hands-on you want to stay. The partner returns a working pipeline, the IaC in your repo, preview environments on pull requests, and a rollback you have watched work.
GitHub Actions vs CodePipeline vs GitLab CI vs Jenkins
The four general-purpose orchestrators. Argo CD is not in the table because it is a Kubernetes deployer that pairs with one of these.
| Dimension | GitHub Actions | AWS CodePipeline/CodeBuild | GitLab CI | Jenkins |
|---|---|---|---|---|
| Where it runs | GitHub-hosted or self-hosted runners | Inside your AWS account | GitLab SaaS or self-managed runners | Self-hosted server and agents |
| Config | YAML in .github/workflows | buildspec.yml and pipeline definition | .gitlab-ci.yml | Jenkinsfile (Groovy) |
| AWS auth | OIDC (no stored keys) | Native IAM (in-account) | OIDC (no stored keys) | OIDC, instance role or keys |
| Native AWS deploy | Actions plus CodeDeploy | CodeDeploy: ECS, Lambda, EC2 | Scripts plus CodeDeploy | Plugins or scripts |
| Best fit | GitHub teams; the fast default | AWS-native or regulated teams | GitLab-centric teams | Existing Jenkins investment |
| Ops burden on you | Low (hosted) to medium (self-hosted) | Low to medium | Medium (runners) | High |
| Greenfield 2026 pick? | Usually yes | Yes, if standardizing on AWS | Yes, if on GitLab | Rarely; keep if invested |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks which funding fits
Your matched partner scopes the work with you. Then it checks which partner-filed funding fits: MAP if you are moving to AWS, POC if you want to test something, or incremental workload (IW) funding if you are already on AWS and launching new work.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is the simplest CI/CD setup for a small team on AWS?
Should I use AWS CodePipeline or GitHub Actions?
How do I avoid storing AWS access keys in CI?
Where should application secrets live?
What is the difference between blue-green and canary deployments?
How should infrastructure as code fit into the pipeline?
How do rollbacks work, and what about database migrations?
Can CloudRoute get the pipeline built for us, and who pays?
Want a production AWS pipeline without hiring for it?
CloudRoute matches you with a vetted AWS partner who builds your CI/CD, IaC and deploy strategy end to end. If it is part of a migration, a test or new work on AWS, the partner also checks MAP, POC or IW funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.