So how do you define what's the right tiering when you're designing in AWS? Now to make this make sense, I want you to think of two cakes, right? One cake is a single layer birthday cake. It's an average-size cake for an average-size birthday party. The cake icing, however, is divided into thirds.

So one third of the cake's icing is red. One third is white, and the last third is blue so it looks a bit like a flat beach ball. Our other cake is a pretty big wedding cake. So it's designed for 50 plus guests, and it has three separate layers. So each layer of the wedding cake has a different colored icing on it. The top layer is iced with red icing. The second layer has white icing and our bottom layer has the blue icing. Now each of our layers are separated by little strats or holders so that each layer is pretty much separate or a cake into itself. So keep clear in your mind that our single layer birthday cake has all three icing colors on it, on that one cake, and our wedding cake on the other hand has a separate layer for each icing color. Now it turns out that the red icing is really popular. 

The third of the birthday cake with the red icing on it at your birthday party all gets eaten in the first hour. Now at your wedding, the red icing is super popular as well, but luckily there is a whole layer of red icing. So when the red icing layer is all gone, the waiting staff just sneak out with a replacement layer and they put it back in there and there's plenty of cake for all once again. Okay, so now let's take a quantum leap and think about our two cakes as being computers and the icing on each cake being parts of our business application. So the red icing is our presentation service. The white icing is our logic service, and the blue icing is our data service. So the immediate difference between these two is that the wedding cake has more cake, right? So it's got icing for each layer so it's obviously gonna last a lot longer, but there's another unique difference here. If the red icing is super popular, and that red layer all gets eaten up, we can just quickly add a new red layer to our cake. Our wedding cake is still there, functioning as a cake and serving hungry eaters. On the other hand, once the red icing has all been gobbled up on our birthday cake, that's it, we need to bake a new cake if we want more red icing. So in our analogy, the birthday cake is a single tier architecture and the wedding cake is a multi-tier architecture. And each of these two architectures has their own benefits. So the core benefit of the multi-tier architecture is that each of the layers is independent of the other layers. 

With a multi-tier architecture, each layer can be scaled up or down to meet a specific demand for that layer. The single-layered cake is easy to make, right? Very fast, very simple, but the base under the icing is shared. So if one section of that base runs out, we have to replace the whole cake. So leaping back to computing, if we have a layer or a tier for each of our services, this means each layer is more flexible. Each of the layers is independent of the other layers, and can have its own controls and be sized appropriately. Now that multi-tier design really suits cloud environments, where we can run each layer on truly scalable base infrastructure. So multi-tier architecture simply means that we have more than one layer and one layer for each of our respective services. 

The three-tier architecture is the most popular implementation of a multi-tier architecture. So going back to our business application that usually consists of a presentation tier, a logic tier, and a data tier. Now services in each tier can run on computers, they can be EC2 instances that were provisioned in the AWS cloud. They can be run as serverless functions within AWS, i.e. run on managed infrastructure, and not even need dedicated machines or an instance to run on. So in short, the tiers could be different services or technologies. The name of a tier or even the type of technology used in it isn't really important. The reason for wanting to separate out the layers is so that each can operate and scale independently of the other. The benefit of that is that if one layer becomes overwhelmed, it doesn't impact the other tiers. And more importantly, again, if one tier does become overwhelmed, we can increase the resources available to that tier, without having to scale the other tiers.