In red-black deployment, before standing up a new version of a system, first, perform canary testing. The canary replaces around 1% of its existing production system with the latest version of the application and monitors the newest version for errors. If the canary clears this initial test, the system is deemed ready for deployment.

In preparation for the switchover, a new version of the system stands up side by side with the old version of the system. The initial capacity of the new system is set manually by examining how many instances are currently running in production and setting this number as the desired capacity for the new Auto Scaling group. Once the new system is up and running, both systems are red. The current version is the only version accepting traffic.

Using the DNS service, the system is then cut over from the existing version to the new version. At this point, the old version is regarded as black; it is still running but is not receiving any traffic. If any issues are detected with the new version, then reverting becomes as simple as pointing the DNS server back to the load balancer hosting the old version.

Red-black deployment is also known as dark launch and is slightly different from blue-green deployment. In red-black deployment, you do sudden DNS cutover from the old version to the new version, while in blue-green deployment, the DNS gradually increases traffic to the new version. Blue-green deployments and dark launches can be combined to deploy both versions of software side by side. Two separate code paths are used, but only one is activated. A feature flag activates the other code path. This deployment can be used as a beta test where you can explicitly enable the new features.