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.

Please note: [Disclaimer]

Architecture Diagram

[Architecture diagram description]

Download the architecture diagram PDF 

Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

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.

[Content Type]


This [blog post/e-book/Guidance/sample code] demonstrates how [insert short description].


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.

References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.

Was this page helpful?