Skip to main content

AWS Solutions Library

Guidance for Canary Deployments for Queue Processing Workloads in Amazon ECS

Zero-downtime deployments with monitoring and instant rollbacks

Go to sample code

Overview

This Guidance shows how to implement canary deployments for backend or queue processing workloads without using a load balancer. By using AWS CodePipeline, you can orchestrate a workflow that first deploys the canary release to a low-capacity service instance for testing before propagating it to a high-capacity service instance to complete the deployment. Additionally, you can use AWS monitoring capabilities and alarms to automatically initiate a rollback, allowing you to better implement safe deployments when deploying new changes to your application.

Important: This Guidance requires the use of AWS CodeCommit, which is no longer available to new customers. Existing customers of AWS CodeCommit can continue using and deploying this Guidance as normal.

How it works

This architecture diagram shows how to implement canary deployments for backend or queue processing workloads in Amazon Elastic Container Service (Amazon ECS) without a load balancer.

Download the architecture diagram

Well-Architected Pillars

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

CodePipeline and CodeBuild automate the CI/CD process for building and deploying new code changes. This Guidance deploys the changes in Amazon ECS and AWS Fargate, fully managed serverless services that help you offload operational overhead tasks like upgrading, patching, and scaling various compute resources.

Read the Operational Excellence whitepaper 

All the services in this Guidance use AWS Identity and Access Management (IAM) for authentication and authorization. IAM roles and policies, which can grant short-term access credentials, protect AWS resources, and manage access. By scoping IAM policies to the minimum permissions required, you can limit unauthorized access to resources.

Read the Security whitepaper 

This Guidance deploys Amazon ECS and Fargate tasks, Amazon SQS queues, and Lambda functions across multiple Availability Zones (AZs) by default, helping you achieve high availability. Additionally, Amazon SQS queues implement decoupling between application components, and a DLQ captures any processing failures for investigation and retry.

Read the Reliability whitepaper 

CodePipeline and CodeBuild implement the CI/CD process when you need to push new code changes to the CodeCommit repository. Amazon ECS uses Application Auto Scaling to automatically adjust the number of Amazon ECS and Fargate tasks running in the cluster based on the Amazon SQS queue depth.

Read the Performance Efficiency whitepaper 

All the services used in this Guidance are serverless, which means you can run code without provisioning or managing servers, and you only pay for what you use. CodeBuild, which provides on-demand compute capacity, is billed for the duration of code building, and CodePipeline is billed for the number of pipelines per month. Additionally, CodeBuild is responsible for building the application code. Application Auto Scaling automatically adjusts the number of Amazon ECS and Fargate tasks running in the cluster to meet demand, thus minimizing the overall compute costs. Additionally, you can choose an ARM64 CPU architecture, spot capacity, and compute savings plans to further reduce compute costs. For example, you can use Fargate Spot if the workload tolerates interruptions.

Read the Cost Optimization whitepaper 

This Guidance uses serverless services that let you run code without provisioning or managing servers. These services can scale based on your workloads so that you can avoid overprovisioning resources, ultimately lowering your carbon footprint. For example, Application Auto Scaling automatically adjusts the number of Amazon ECS and Fargate tasks running to meet demand, thus minimizing compute. You can also run Fargate on the ARM64 architecture to further reduce power consumption.

Read the Sustainability whitepaper 

Implementation Resources

The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Open sample code on GitHub

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.