I don't really see a benefit in updating existing instances in this manner. Launching replacement instances with the new code is much easier for us, and it also provides a super fast means of rollback.
We update existing instances because in our test environment we deploy at every single new commit (we absolutely love that), and we have hundreds (or more) a day. At that pace, replacing instances would be more time consuming (again, for our specific use case) and less cost efficient.
Plus, updating existing instances is handled automatically by AWS Code Deploy, which provides a very good deploying pipeline that you can control using the aws cli tool.
There are other minor advantages but those are the two main ones.
Does something verify every commit in the testing environment too?
However best practices always evolve...
I'd say that rolling out containers on ECS is starting to really show advantages.
It is now generally:
- easier to build and push an image than burn an AMI - faster to boot a container than an instance - faster to finish a deploy with options like min containers in service and a slack instance or two
To be honest most teams don't actually need the extra agility that containers promise.
But if I was starting an AWS setup from scratch I'd strongly consider containers on ECS.
In addition to the speed there is more portability with containers and a whole new generation of tools coming in the ecosystem.