If you're willing to put in extra effort, you never need to have scheduled downtime.<p>A few simple examples.<p>1) Deploying new code? Spin up a new server behind your load balancer with the new code. At this moment, you have both the old and new code live, so everything needs to still work with both versions out there. This requires extra work. Then you can take down the old server running the old code.<p>2) Updating a database schema? Fork the database, apply the schema update to the fork. Ensure writes can be applied to both the old and the new schema. Update your code to read from the new schema. Remove the old database schema. Again this process requires extra work.<p>The analogy for this is "changing the tires on a car while driving down the highway". It's easier to pull over and change a tire, but you could find a way to change a tire while driving if you really needed to.
If Amazon is down, it is losing money.<p>Amazon's infrastructure was designed to prevent downtime at all costs. This was primarily through services deployed across data center clusters to ensure that even if a data center (or two!) went down, everything would continue to work.<p>AWS grew out of Amazon's "excess" infrastructure that was not used after holiday peaks had ended. AWS follows the same "no down time" design and most AWS products offer service agreements with strong estimates about how many "nines of availability" the service meets.