00:02Hey, this is Sloth from Flow Pro Dev

00:05This amazing visualization has been making its rounds on LinkedIn and other platforms, and I thought we'd take a look at what's actually going on here

00:08It was made by Ankit Jodhani, the link is in the description

00:14So, on top, we see traffic coming in, and it's going to Route 53, a DNS service that resolves the domain and routes it to the appropriate CloudFront distribution

00:24In between, we see AWS Web Application Firewall, or WAF

00:26This will filter common web exploits such as SQL injection or cross-site scripting

00:32We could add AWS Shield for more protection against bots and DDOS, but Here, the author chose not to do that

00:39The CloudFront distribution is then connected to what we call a standard three-tier architecture, with a web or front-end tier, an application or back-end tier, and the database tier

00:51On the left side, we see the three-tier setup sits in a single VPC, a virtual network, on the region U.S

00:56East 1

01:01The VPC will give us a common network address space, just like an on-premise network would

01:06On the left and right, we see the VPC spends two availability zones, which we can imagine is different data centers of AWS

01:13This offers better fault tolerance should one AZ have problems, the entry Point for the data is an elastic load balancer, which is always in an active-active configuration

01:24That means both availability zones are used by default

01:28We'll see an example of an active-passive config in a bit

01:33The elastic load balancer then sends the data to EC2 instances, the AWS virtual machines, in an auto-scaling group

01:38The auto-scaling group automatically increases or decreases the number of EC2 instances based on load

01:45We can, for instance, target an average load of 80 percent, and if we go above, ASG will add more instances, so the website code running on the web server EC2 instances will send their

02:00request to the app servers, or sometimes called back-end servers

02:04The backend service can then contact the database tier on the bottom here

02:06The author chose Amazon RDS

02:09This database service supports many popular SQL databases such as MySQL, SQL server, or Postgres

02:17We see that we have separate subnets for each tier and availability zone

02:21This is considered best practice as it gives a separation, so instances within one subnet could communicate with each other, but nobody from the outside can access them unless explicitly allowed

02:32In this case, the load balancers have security group or Access Control

02:37list settings to be able to talk to the instances in the subnet

02:42On the top, we see two public subnets, this means they have connectivity to the internet, unlike the other private subnets

02:49This is considered best practice in order to access the instances in private subnets for administration purposes inside the two NAT gateways

02:55The NAT gateways will be used if private instances want to communicate with the outside world, such as getting security patches and updates

03:04We also have a Bastion host, which is good for administration in general

03:10We also see two AWS backup instances to which the web and Application servers can send important data to a backup Vault

03:18If we zoom out again, we see that on the right, we have to reach in U.S

03:22West 2 with an identical setup in a so-called active passive configuration

03:26That means the CloudFront service on the top will only send data to this region when the primary region fails

03:31This allows for extreme fault tolerance, the so-called five nines, which is 99.999, or an average maximum downtime of 5.2 minutes per year

03:46In order to make this possible, the backup Vault we talked about is performing a constant cross region backup, and a backup Vault on the other region uses

03:53backup restore to keep the weapon application tier up to date, the same goes for the database tier

03:57We see that RDS has an active and secondary instance in one region that is again connected to the other region via a cross region replica

04:07That means we always have an up-to-date database instance standing by

04:13With such a setup, we can indefinitely scale in case our demand goes up

04:16At the same time, every single component can fail, and if it fails, will be replaced by something else

04:25This could be either something on an instance level, if they fail, there will be other instances that are available and the auto scaling

04:32groups will make sure that there are new instances to use if there is something more severe, and the availability zone fails, we have a different one in the same region

04:40And if that's not enough, if the entire region goes out, there is this active passive failover on the CloudFront distribution that will just switch to a different region with the same setup

04:53Such a setup is considered best practice at the moment for large corporations, or when you really have a need for fault tolerance

04:59It adds quite a bit of extra cost because, depending on how quickly you want it to be able to kick in, you need to have quite some infrastructure standing by that is unused, but on the other hand, all the auto scaling will automatically scale things up in a crunch

05:15This can take a few minutes, however, so if you need absolutely no downtime in between and want the regions to switch over directly, you should maybe choose an active active configuration here as well

05:26This has been flow from Flow Pro Dev

05:29If you found this video helpful, give it a like and subscribe to stay updated on new AWS features.