Let's move into design mode. So, we'll review the design of a multi-tier architecture for web services, architecture patterns using instances and load balancers. Then we'll review how we could create a similar solution using serverless services, and then using a full microservice design. So for a multi-tier design, we need to implement the following AWS services. We're going to need to use the virtual private cloud or VPC. So, we're building our solution within the Virtual Private Cloud. 

Now there's four basic patterns of VPC an Amazon VPC can have a single public subnet only. And that design would suit a single-tier architecture where we need to run perhaps a very low traffic server or service and have it available to the internet. So in this design, we'd have one instance within that public subnet, which ran all of our services. Like our front end, our logic layer and our database layer on that one machine. We can have an Amazon VPC with private and public subnets and that might suit our multi-tier architectures. Where we want to have our presentation layer available to the internet. And our logic and data tiers hidden from the internet in a private subnet. We can also have a VPC with public and private subnets and VPN access. So, here is an example of a three tier highly available VPC design, we have public subnets for our presentation tier, we have private subnets for our logic and database tiers. We want to have separate subnets for unique routing requirements. AWS provides us with areas called availability zones. So, using more than one availability zone allows us to build redundancy into our design and so we can spread our services within our tiers across these multiple availability zones. So, if one availability zone is taken out by an earthquake or a disaster of sorts, your application can continue to run because you're spread across two availability zones. Now you can have up to four availability zones depending on the region and that gives you a really high availability and disaster recovery potential. So, let's talk a little bit about subnets before we move on, so without delving too deep into subnetting, here is what you need to remember about subnets. A subnet can be either public or private. 

A subnet is public, if it has an internet gateway, and a route to that internet gateway, okay? If it doesn't have a route to an internet gateway, then it is a private subnet. All right, public subnets have a default route table, which enables us to allow inbound and outbound traffic to that subnet. Private subnets need a route table to direct flow within the VPC. So remember, public subnets have an internet gateway and a route to the internet gateway. Without both the gateway and the route being present. You have a private subnet. Okay, so the internet gateway is like the doorway to the outside world of your VPC. So, imagine this VPC as your big fat VPC wedding and you want to make part of your VPC wedding available as your wedding reception. So, think of the internet gateway as the entrance to your VPC wedding and the reception area one of your subnets, in the VPC. If you want to invite your friends, you're going to need to make the reception subnet of your VPC wedding public. You need to add the internet gateway, and update the route map to direct guests from the internet gateway to the reception subnet. So, once you've set up the internet gateway, you then need to control who can come in and out of the internet gateway, because it is going to be visible to the public. And if you have that doorway, you need a security team working on it. 

So, our first line of defense for our VPC wedding are security groups. They are the bouncers of your VPC wedding. Security groups control access to resources, so they work at the instance level. They work to control inbound and outbound traffic to instances within the subnet. They don't work at the subnet level. They work at the instance level. So, network access control lists or ACL's act as another form of firewall to control inbound and outbound traffic at the subnet level. So, we want to have a network ACL protect the subnet in each availability zone. So, network ACL's provide individual controls that you can customize as a second layer of defense. Independent routing tables need to be configured for every private subnet to control the flow of traffic within and outside of the VPC. So remember, a subnet is a public subnet if it has the internet gateway and a route to the internet gateway. Okay, not too difficult. Hopefully it's starting to make a bit of sense.