Continuous Delivery on AWS - From CI Pipeline to Production in Practice

This guide covers how we implement continuous delivery for production workloads on AWS - the pipeline stages, environment promotion patterns, rollback strategies, and the cost of getting it right versus getting it wrong.

What continuous delivery actually means in production

There is a persistent confusion between continuous integration, continuous delivery, and continuous deployment. In practice:

• Continuous integration - every commit triggers automated build and test. Developers merge to main frequently. Broken builds are fixed immediately.
• Continuous delivery - the pipeline produces a production-ready artifact on every commit. Deployment to production requires a deliberate human decision (an approval gate), but the technical capability exists at all times.
• Continuous deployment - every commit that passes all pipeline stages deploys to production automatically. No human gate.

The key distinction: continuous delivery means deployment is a business decision, not a technical event. Your pipeline is always ready. You choose when to release.

For most teams we work with - especially in fintech, healthtech, and regulated SaaS - continuous delivery with a manual promotion gate is the right choice. It provides speed without giving up control.

For a broader overview of CI/CD terminology, tools, and pipeline fundamentals, see our CI/CD in DevOps guide.

Continuous delivery pipeline stages on AWS

A production continuous delivery pipeline on AWS follows this sequence:

1. Build and unit test (GitHub Actions)

Every push to main triggers a workflow that:

• Checks out the code
• Runs linting and static analysis
• Executes unit tests
• Builds a container image (multi-stage Docker build)
• Tags the image with the Git SHA for traceability

We use GitHub Actions as the default CI engine because of its native Git integration, strong ecosystem, and OIDC authentication to AWS (no long-lived credentials). For teams on Azure, Azure DevOps is a valid alternative - but the pipeline patterns remain the same.

2. Container image security and push to ECR

Before the image leaves CI, it passes through:

• Vulnerability scanning (Trivy or ECR native scanning)
• Image signing (cosign / Sigstore)
• Push to Amazon ECR with immutable tags

The same image artifact deploys to every environment. You never rebuild for staging or production. This eliminates “works on my machine” drift between environments.

3. Deploy to staging (automatic)

Once the image is in ECR, the pipeline automatically deploys to staging:

• On ECS Fargate: Update the task definition with the new image tag, trigger a service deployment
• On EKS: Update the Kubernetes manifest (image tag) and apply via ArgoCD or Helm

Staging uses the same infrastructure-as-code (Terraform) as production, with environment-specific configuration pulled from AWS Systems Manager Parameter Store or Secrets Manager. Same VPC layout, same security groups, different scale.

4. Integration and smoke tests against staging

Automated tests validate the deployment:

• API contract tests (does the service respond correctly?)
• Integration tests against real AWS services (RDS, SQS, S3)
• Smoke tests for critical user paths

If tests fail, the pipeline stops. No promotion to production.

5. Promote to production (approval gate)

This is where continuous delivery differs from continuous deployment. The pipeline pauses and waits for explicit approval:

• In GitHub Actions: an environment protection rule requiring a team member’s approval
• In CodePipeline: a manual approval action
• In ArgoCD: a sync that requires manual trigger

Once approved, the exact same container image (same SHA, same artifact) deploys to production using the same mechanism as staging.

6. Post-deployment validation

After production deployment:

• Health checks confirm the new version is serving traffic
• CloudWatch alarms watch error rates for the first 5-10 minutes
• If errors spike beyond threshold, automatic rollback triggers

Environment promotion: dev → staging → production

The core principle: same artifact, different configuration.

Your container image is built once. It moves through environments unchanged. What changes between environments:

This pattern prevents the classic failure mode where “it worked in staging” because staging was running a different build, different config, or different infrastructure.

Deployment strategies on AWS

Rolling deployment (ECS default). New tasks start before old ones drain. Zero downtime but both versions serve traffic simultaneously during rollout. Good for stateless services.

Blue-green deployment (ECS with CodeDeploy). A completely new target group receives the new version. Traffic shifts all at once (or gradually). Instant rollback by pointing back to the old target group. Higher cost (double capacity during deployment) but maximum safety.

Canary deployment (EKS with ArgoCD/Argo Rollouts). New version receives 5-10% of traffic. Metrics are monitored automatically. If error rates stay below threshold, traffic gradually shifts to 100%. If not, automatic rollback.

For teams running Kubernetes workloads on EKS, ArgoCD with GitOps is the natural choice for the delivery mechanism. Git becomes the single source of truth for what should be running in the cluster.

Continuous delivery vs continuous deployment: when to choose what

Choose continuous delivery when:

• You handle financial transactions, health data, or PII
• Your test suite does not cover enough edge cases for full automation yet
• Compliance requires documented approval before production changes
• Multiple teams deploy to shared infrastructure

Choose continuous deployment when:

• You have 90%+ test coverage including integration tests
• You operate internal tools with a small blast radius
• You have automated rollback that triggers within seconds
• Your team has high confidence in the pipeline’s quality gates

Most teams we consult start with continuous delivery, then graduate individual services to continuous deployment as test coverage and monitoring mature.

Cost of implementing continuous delivery on AWS

Pipeline infrastructure cost on AWS is relatively low. The real cost is in engineering time to build and maintain it.

Infrastructure costs (monthly, typical setup)

Total pipeline overhead: $50-140/month - trivial compared to the engineering time saved.

Engineering time cost

Building a production-grade CD pipeline from scratch takes a senior DevOps engineer 2-4 weeks. That includes CI workflows, ECR setup, ECS/EKS deployment automation, environment promotion, secrets management, monitoring, and runbooks.

If your team does not have that expertise in-house, a CI/CD consulting engagement delivers the same result in 3-4 weeks with full knowledge transfer. The cost of a consulting engagement (EUR 3,000-6,000) is typically recovered within 2-3 months through reduced deployment incidents and recovered developer time.

Common failures in continuous delivery pipelines

After auditing dozens of CD pipelines across teams of 5 to 200 engineers, these are the patterns that consistently cause problems:

No rollback strategy. The pipeline deploys forward only. When something breaks, the “rollback plan” is reverting a commit and waiting 15 minutes for a new build. On AWS, use ECS deployment circuit breakers or CodeDeploy automatic rollback to recover in seconds, not minutes.

Staging that drifts from production. Staging was set up 6 months ago and nobody updates it. Config is different, database schema is behind, infrastructure differs. The solution: staging and production share the same Terraform modules with environment-specific variables. Drift is impossible when both environments are declared in code.

Secrets in environment variables or repo. AWS credentials hardcoded in workflow files. API keys in .env committed to Git. Use OIDC for GitHub Actions → AWS authentication. Use Secrets Manager for application secrets. Never store credentials as long-lived tokens.

Tests that don’t test the deployment. Unit tests pass, but nobody tests whether the deployed service actually responds correctly in its target environment. Add post-deployment smoke tests that hit real endpoints in staging before allowing promotion.

Manual steps hidden in “automation.” The pipeline is “automated” but someone needs to manually update a parameter, or run a database migration separately, or click a button in the AWS console. If it is not in the pipeline YAML, it will be forgotten at 2am during an incident.

When to bring in CI/CD consulting

If your team relates to three or more of these situations, a structured CI/CD consulting engagement will pay for itself quickly:

• Deployments require a specific person who “knows how to do it”
• Your team avoids Friday releases because nobody trusts the process
• Builds take 15+ minutes and developers stop running them locally
• There is no staging environment, or staging is weeks behind production
• You cannot answer “what version is running in production right now?”
• Rollback means “revert the commit and hope”

We design and implement continuous delivery pipelines that your team can maintain independently. No proprietary tooling, no vendor lock-in - just well-structured pipeline-as-code committed to your repository.

Learn more about our CI/CD consulting services →