The goal is minimal downtime during deployment and fast rollback if problems occur. In Elastic Beanstalk, the approach that best satisfies both is a blue/green deployment.
With blue/green, the developer deploys the new application version to a separate environment (green) while the current production environment (blue) continues serving traffic. Once validation is complete (health checks, smoke tests), the developer performs a controlled CNAME swap (or routing switch) so traffic shifts from blue to green with near-zero downtime. This reduces risk because the existing environment remains intact and can immediately resume traffic if issues are detected.
Rollback time is also minimized because reverting is simply switching traffic back to the original environment (swap back), rather than rolling back changes across the same environment.
Why the other options are weaker:
All-at-once (C) introduces the highest downtime and risk because it replaces all instances at once, potentially taking the application fully offline and making rollback slower.
Rolling (A) reduces downtime compared to all-at-once, but instances are still updated in-place; if issues appear mid-deployment, rollback is more complex and slower than swapping environments.
Rolling with additional batches (B) can further reduce capacity impact by adding extra instances during deployment, but rollback still involves reversing updates in the same environment and is typically slower than blue/green.
Therefore, deploying to a new environment and using blue/green provides the least downtime and the fastest rollback.
