Not quite, of course. Until you reach a certain scale, that's not as easy to maintain as a smaller grouping of pet servers. While you can certainly run with that pattern on Amazon, EC2 instances aren't quite as friendly about overcoming access issues as other providers are. That's to say, even if you have access to the AWS account there's no interface for forcing a root password change or the like.
But sometimes you need that, as an End Point client did recently. It was a legacy platform, and the party that set up the environment wasn't available. However an issue popped up that needed solved, so we needed a way to get in. The process involves some EBS surgery and does involve a little bit of downtime, but is fairly straightforward. The client's system was effectively down already, so taking it all the way offline had little impact.
Also do make sure this is the actual problem, and not that the connection is blocked by security group configuration or some such.
That's not the only approach, of course. If you have a partially functional system, for example, you may be better off immediately creating a volume from the snapshot created in step 0, mounting that in another instance for the modifications, and then performing the stop, root volume swap, and start in quick succession. That'll minimize any actual downtime, at the potential expense of losing any data changes happening in between the snapshot and the reboot.
Either way just remember there are options, and all is not lost!