These type of deployments follow a phased approach where a whole new environment is deployed alongside an existing live environment. You can perform an end-to-end test on the new environment before deciding whether to cut the traffic over, sending all of the traffic to the new live environment, and sending none to the old (previously live) one. There is a higher-level piece of infrastructure or routing logic that needs to be present to enable the traffic switching:

Careful attention should be given to your key monitoring metrics after the switch. A rollback in this method is a complete cutover back to the previous environment. For deployment and subsequent cutovers, this is deemed successful since the old environment isn't needed anymore and can be terminated. 

To make this process easier, the new environment usually uses the same data store as the live environment. This reduces the complexity (and inherent risk) of creating new data stores and keeping them in synchronization. 

Amazon CloudFront and Route 53 are two options that can help direct traffic to your chosen environment. Implementing the blue/green strategy using CloudFront can be achieved by having two origins in your distribution: one for the live environment and one for the new environment. The switchover is then a change in the behavior for the default path pattern. The time it takes for the configuration to propagate to all of the edge locations can be restrictive if your environments are simple.

For these more simple environments, it's better to use Route 53 and run a DNS-based cutover by changing the CNAME or ALIAS records. For this method, we are only restricted by the TTL we have set for our zone. We're also relying on our clients respecting the TTL and not caching the DNS address for longer than specified.

It's a good idea to run a blue/green or canary strategy (explained in the next section) when releasing changes to production because it gives you a chance to verify that the new environment has been created correctly before serving real traffic. Rollbacks are also much more simple and less error-prone because we are failing back whole environments, instead of partial environments in an unknown state. 

In the Serverless Framework, blue/green deployments are not easily accomplished out of the box. It would be possible to employ a higher-level piece of infrastructure to perform a switchover, but it would be better to manage this outside the project. Let's look at another way of dealing with this.