Let’s start with the pros:

Testing parity: this is THE feature. Testing parity means that tests truly mirror the reality of production. This is what Dan and Jez were looking for when they devised blue-green. By running tests on the same hardware and software, they made them more useful and meaningful.

Deploy at any time: no downtime means that we can make releases at any time. There is no need to wait for maintenance windows.

Instant cut-over: users are switched to the new version instantaneously, or nearly so. Everyone sees the latest release at the same time.

Instant rollback: the cut-over works both ways. If we decide to go back to the previous version, we can switch all users back in an instant.

Hot standby: blue-green can save us from disaster scenarios. Suppose that one data center goes offline, bringing the live environment down. No biggie, we’ll switch to the other until the problem is fixed. This will work as long we have had the precaution of not putting blue and green on the same availability zone.

Postmortem: debugging failed releases is hard with in-place deployments. When faced with downtime, the priority is always to return to normality. Collecting debugging data is secondary, so a lot of valuable information may be lost during the rollback. Blue-green doesn’t suffer from this problem—rollbacks always leave the failed deployment intact for analysis.

https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/introduction.html