CI/CD on AWS — the options, a reference pipeline, and who builds it.

IWhat "good CI/CD on AWS" actually means in 2026

CI/CD is two things people often conflate. Continuous Integration is "every commit is built, tested, and scanned automatically." Continuous Delivery/Deployment is "every change that passes can be released to an environment safely, on demand or automatically." On AWS, the moving parts are well understood; the difference between a pipeline that helps and one that bites you is in the details below.

A good pipeline is fast (a developer gets a pass/fail signal in minutes, not after a coffee break), reproducible (the same commit produces the same artifact every time — you build the container image once and promote that exact image through environments, you do not rebuild per environment), and safe (a bad deploy is caught before it reaches production, or rolled back automatically within seconds when it does).

It is also auditable and least-privilege. Every deploy is traceable to a commit and an actor; the pipeline assumes a narrowly-scoped IAM role rather than holding god-mode credentials; nothing has a static AWS access key sitting in a CI secret. In 2026, long-lived AWS_ACCESS_KEY_ID values in CI are a code smell — OIDC federation removes them entirely, and we treat their presence as a finding.

The honest framing for this page: the tooling is genuinely commoditized. GitHub Actions, GitLab CI, CodePipeline, Jenkins, and Argo CD can all ship code to AWS reliably. What is not commoditized is the surrounding design — environment promotion, approval gates, ephemeral preview environments, the blue-green or canary rollout, secrets handling, infrastructure-as-code in the same flow, and a rollback path you have actually tested. That is the work. That is also exactly the work a good AWS partner does for you in a week or two.

IIThe options: GitHub Actions, GitLab CI, CodePipeline/CodeBuild, Jenkins, Argo CD

There is no single right answer — the right tool depends on where your code lives, how much you want inside the AWS IAM boundary, and whether you are deploying to Kubernetes. Here is how the five real options actually differ.

Read these as archetypes, not religion. Plenty of teams run GitHub Actions for build-and-test and Argo CD for the Kubernetes deploy, or CodeBuild as a compute backend behind a GitHub-triggered workflow. Mixing is normal.

IIIA reference pipeline: build → test → scan → push to ECR → deploy

Here is a concrete, tool-agnostic reference for a containerized service on AWS. The same six stages apply whether the orchestrator is GitHub Actions, GitLab CI, or CodePipeline; only the syntax changes. Build the artifact once; promote that artifact.

The unit of promotion is an immutable container image tagged with the commit SHA (e.g. :git-9f3a1c2), stored in Amazon ECR. You do not rebuild for staging and again for production — you build once, and the exact image that passed tests in staging is the image that runs in production. This single decision eliminates a whole class of "it worked in staging" failures.

• 1. Build — Check out the commit, build the container image (multi-stage Dockerfile, pinned base image). Use layer caching to keep builds fast. Tag with the commit SHA so the artifact is traceable.
• 2. Test — Run unit and integration tests against the built artifact. Fail fast and loud — this is the signal developers wait on, so keep it under a few minutes where possible. Publish coverage and test reports as build artifacts.
• 3. Scan — Static analysis (SAST) on the code, dependency/SCA scan for known CVEs, container image scan (Amazon ECR scan-on-push powered by Amazon Inspector, or Trivy/Grype in-pipeline), and IaC scan (Checkov/tfsec/Trivy) on your Terraform/CDK. Optionally scan for leaked secrets. Set a severity threshold that fails the build.
• 4. Push to ECR — Push the tested, scanned image to Amazon Elastic Container Registry. ECR enforces scan-on-push, lifecycle policies (expire old images), and immutable tags so an image cannot be silently overwritten.
• 5. Deploy — Roll the new image out to the target — ECS service (Fargate or EC2), EKS deployment, or a Lambda function/alias. Use a controlled rollout strategy (rolling, blue-green, or canary — see section V) rather than a hard replace. Update the task definition / manifest / function config to the new image tag.
• 6. Verify + smoke-test — Post-deploy health checks and smoke tests against the live environment, with automatic rollback if they fail. CodeDeploy can gate the traffic shift on CloudWatch alarms; Argo Rollouts can gate on metrics. A deploy is not "done" until the new version is proven healthy in front of real traffic.

The deploy target shapes stage 5 the most. ECS on Fargate is the lowest-operational-overhead path — no nodes to manage, native CodeDeploy blue-green, and a registered task definition per release. EKS gives you full Kubernetes (and the GitOps/Argo CD pattern) at the cost of running a cluster. Lambda deploys are function-and-alias based with weighted-alias canaries via CodeDeploy — ideal for event-driven and bursty workloads. Most early-stage product teams we route are best served by ECS Fargate; the team graduates to EKS when Kubernetes-specific needs (complex networking, operators, multi-tenant platform) actually appear.

IVEnvironments, approval gates, and ephemeral preview envs

A pipeline is only as good as the path a change takes from merge to production. Three things define that path: how many environments you promote through, where the human approval sits, and whether every pull request gets its own throwaway environment to test in.

A sane default is three persistent environments — dev, staging, and production — ideally in separate AWS accounts under AWS Organizations, so a mistake in dev cannot touch production data or quotas. The same image flows dev → staging → production. Promotion to production is the point where you usually insert a manual approval gate (a required reviewer in GitHub Actions environments, a when: manual job in GitLab, or a manual-approval action in CodePipeline). Lower environments deploy automatically; production deploys on approval — or fully automatically once you trust your test suite and rollback enough to practice continuous deployment.

Ephemeral / preview environments are the high-leverage upgrade. On each pull request, the pipeline spins up a short-lived, fully-isolated copy of the app (its own ECS service or Kubernetes namespace, its own URL, often a seeded throwaway database) so reviewers and QA can click through the actual change before it merges. When the PR closes, the environment is torn down automatically so you are not paying for it. This is straightforward to wire up with IaC (each PR gets a parameterized stack) and it is one of the biggest quality-of-life wins a partner can hand a product team.

The governance layer around all of this is worth getting right once: branch protection (no direct pushes to main), required status checks (build + test + scan must pass to merge), required reviewers, and an environment-protection rule so that the production deploy role can only be assumed by an approved workflow on the main branch. These are cheap to set up and they are what auditors and enterprise customers ask about.

VBlue-green and canary: how the rollout actually happens

How you shift traffic to the new version is where outages are prevented or caused. The three patterns — rolling, blue-green, and canary — trade off speed, blast radius, and infrastructure cost. AWS has native support for all three.

Rolling update replaces instances/tasks a few at a time behind the load balancer. It is the simplest and cheapest (no duplicate fleet), and it is the ECS/EKS default. The downside: during the roll, both old and new versions serve traffic, and a bad version is live for some users before you notice — so rolling depends heavily on good health checks.

Blue-green stands up a complete parallel "green" environment alongside the live "blue" one, runs validation against green, then flips traffic over at the load balancer in one move. Rollback is instant — you flip back to blue, which is still running. AWS CodeDeploy does this natively for ECS and Lambda, and it can hold the old version warm for a defined window before terminating it. The cost is briefly running two full environments.

Canary shifts a small slice of traffic (say 10%) to the new version, watches metrics and alarms for a few minutes, then shifts the rest if everything looks healthy — or rolls back automatically if a CloudWatch alarm trips. CodeDeploy ships predefined canary configurations (e.g. "10% for 5 minutes, then 100%"); for Kubernetes, Argo Rollouts gives you metric-gated canaries. Canary is the safest pattern for high-traffic production services because a bad release only ever touches a fraction of users, briefly.

The practical recommendation: rolling for dev/staging, blue-green or canary for production. Wire the production rollout to gate on real signals — error rate, latency, and a synthetic smoke test — so the system itself rolls back without waiting for a human at 3 a.m.

VISecrets (OIDC + Secrets Manager), IaC in the pipeline, and rollback

These three are where most homegrown pipelines are weakest — and where a partner engagement pays for itself. Get authentication, infrastructure, and rollback right and the rest of the pipeline is comparatively easy.

VIIBest practices and the common pitfalls

The patterns that consistently separate pipelines that help from pipelines that hurt. None of these are exotic; all of them are skipped under deadline pressure, and all of them are cheap to fix early and expensive to retrofit late.

Do these:

• Build once, promote the artifact — One SHA-tagged image flows through every environment. Never rebuild per environment.
• OIDC, not static keys — Federate CI to AWS over OIDC with a scoped role. Zero long-lived access keys in CI secrets.
• Least-privilege deploy roles — The pipeline assumes a role scoped to exactly what it deploys — not an admin role, not a shared role.
• Fail the build on real findings — Tests, SCA/CVE, container scan, and IaC scan with a severity threshold that actually blocks merges.
• Gate production on signals — Health checks, error-rate and latency alarms, and a synthetic smoke test that can trigger automatic rollback.
• Infrastructure as code, planned on PRs — Terraform/OpenTofu/CDK with plan-on-PR and apply-on-merge, remote locked state, and policy-as-code.
• Keep pipelines fast — Cache dependencies and layers, parallelize test and scan stages, and keep the developer feedback loop under a few minutes.

Avoid these (the recurring pitfalls): long-lived AWS keys stored in CI (replace with OIDC); a single god-mode IAM role the whole pipeline shares; rebuilding the image separately for each environment; "deploy" being a hard replace with no health gate and no rollback; secrets baked into images or printed in build logs; manual terraform apply from someone's laptop with state on their disk; click-ops drift where the console no longer matches the code; an unpinned forest of third-party CI actions you have never reviewed; and a rollback procedure that exists only in a wiki page nobody has run. Each of these is a familiar incident waiting to happen, and each is exactly the kind of thing a vetted partner remediates as part of building the pipeline.

VIIIHave a partner build your pipeline — often AWS-funded

You can build everything above yourself; this page gives you the map. But most teams searching "ci/cd aws" do not actually want to spend three weeks becoming pipeline experts — they want a production-grade pipeline shipped, correctly, so the team can get back to the product. That is what CloudRoute routes you to.

CloudRoute matches you to a vetted AWS partner who builds the pipeline end to end: the CI/CD itself (GitHub Actions, GitLab CI, or CodePipeline — whichever fits your stack), OIDC authentication, the ECR + ECS/EKS/Lambda deploy, blue-green or canary rollout, secrets via Secrets Manager, the infrastructure as code, ephemeral preview environments, and a rollback path they hand over tested. You get the work done by people who do this for a living, without running a hiring loop or vetting agencies yourself.

The commercial part, stated honestly: for credit-eligible companies, the partner engagement is frequently AWS-funded — the partner is paid through AWS partner-funding programs and your AWS usage during the build is covered by credits — so the customer pays $0 or low cost. If you are not credit-eligible, it is a straightforward vetted-partner referral: you still skip the hiring-and-vetting slog, you just pay the partner for the engagement directly. CloudRoute is paid a commission by the partner, not by you. We will tell you which bucket you are in up front; we do not pretend everything is free.

If you also want the AWS credits themselves — which is what funds the engagement — that runs in parallel. See the AWS credits routes (the $100K Activate Portfolio tier is the common one for funded startups) and the startup persona page below; the pipeline build and the credit application are typically filed by the same partner in the same week.