When should we consider a single-tier design? Single-tier generally implies that all the replication services are running on the one machine or instance.

 So the benefit of a single-tier architecture is that we have everything in one tier. So potentially one instance or group of instances can run our entire application. The three tiers will be sharing the memory, process, and storage of that one machine or group of machines. And that is fine when we just need a simple service, say a Dev or Test environment, or we have a very small application that may not need to scale up or down to meet demand. 

However, keep in mind to scale a single-tier architecture, you're generally going to need to scale an instance or machine vertically, i.e, you're gonna need a bigger machine. Yes, you can run single-tier on multiple availability zones. So yes, a single-tier architecture can be made more resilient by running it in AWS. And yes, you can put your single-tier machine or instance into an order scale group so that it effectively scales based on demand. However, the design floor in doing that is that you are not decoupling your services so that they can scale independently. That's the big benefit of running Cloud services in a decoupled environment. 

So if you are asked to make that a single-tier application highly available and fault tolerant, you will need to refactor it as a multi-tier architecture. In a single-tier design, you are going to have all your services on the same machine using the same resources, which can create an availability risk. If the server is down, then the entire application will be down. If availability is a requirement, you need a decoupled multi-tiered architecture. If an exam scenario describes a very simple application that doesn't need to be highly available and fault resilient, then running their application on a single-tier architecture may be a consideration. 

The key thing to remember is that the benefit of multi-tier architecture is that the tiers are decoupled, which means they can be scaled to meet demand. And it is a major benefit of building applications in the Cloud. If the presentation layer is suddenly hit with a 100,000 user requests, that presentation layer can be scaled to meet that demand. If the application tier needs to run end of month report, and so it's very busy for two or three days at the end of the month, their application tier can be scaled out to meet that demand and then scale back in to its usual operating level. Responding to this type of burst activity, really suits cloud environments and specifically suits AWS Auto Scaling, and more specifically Auto Scale groups.