Canary Deployment

Canary deployment is a release strategy that limits initial exposure to a new version while validating it under real production conditions. Instead of replacing the entire workload immediately, engineers direct a small share of requests or a selected user cohort to the candidate version. The stable version continues serving the remaining traffic. If the candidate satisfies predefined health and performance criteria during an observation period, the release proceeds; otherwise, traffic returns to the stable version.

A practical example is an API release that initially receives 5% of requests while the existing version receives 95%. The deployment pipeline compares version-specific error rates, tail latency, resource saturation, and business outcomes such as successful checkout completion. After enough representative requests and a suitable observation period, the pipeline can promote the candidate to full traffic. Some implementations use one initial canary step followed by complete promotion; others increase exposure through several stages. Neither a particular percentage nor a fixed number of stages defines the concept.

Cloud implementations separate deployment from traffic exposure. For virtual machines, engineers can provision a small candidate fleet and use weighted load-balancer target groups or another routing layer to control traffic. Deploying to a small percentage of instances does not necessarily produce the same percentage of requests, because instance capacity, connection reuse, and routing behavior affect distribution. For containers, stable and candidate task sets or Kubernetes workloads can coexist behind weighted routing. A standard rolling update does not by itself provide a metric-gated canary release.

For serverless functions, a versioned alias can split invocations between an established version and a candidate. AWS CodeDeploy supports canary traffic shifting for Lambda and Amazon ECS deployments, including predefined configurations and configurable rollback behavior. Its EC2/on-premises deployment configurations do not provide the same predefined weighted canary traffic shifting; instance-based canaries require an appropriate orchestration and routing design. A CI/CD pipeline should publish immutable artifacts, execute validation hooks, start the rollout, evaluate its outcome, and retain the previous artifact for recovery.

Machine learning deployments apply the same principle to model-serving endpoints. A candidate model initially receives limited live inference traffic while engineers monitor invocation failures, latency, capacity, and model-specific quality indicators. Amazon SageMaker AI deployment guardrails support canary traffic shifting for supported real-time endpoint updates, with CloudWatch alarm-based rollback when configured. Operational health alone does not establish model quality: accuracy, business impact, or fairness measures may require delayed labels and longer observation. Shadow testing differs because copied requests normally do not determine the response returned to the user.

The main trade-offs are additional capacity, longer release duration, and more complex routing and observability. Metrics must distinguish stable and candidate versions; an aggregate error rate can hide a severe failure affecting only a small canary population. Low traffic may produce too few observations for a reliable decision. Random request weighting also does not guarantee that a user consistently reaches one version, so session-sensitive applications may need cohort assignment or suitable stickiness.

Canary and blue/green deployment are related but not identical. Blue/green describes maintaining separate current and replacement environments, while canary describes limiting and evaluating initial exposure; a blue/green deployment can therefore use canary traffic shifting. Canary deployment is also not primarily an A/B experiment, whose purpose is comparing alternatives rather than validating a release. Finally, rollback requires explicit configuration and cannot undo external side effects or incompatible database changes. Backward-compatible schemas, idempotent operations, and tested recovery procedures remain necessary.