Papiha Joharapurkar

call me for your architecture diagram interpretation needs

Lots of more AWS exam preparation today. I am now fully confident and able to read and understand twisty-windy architecture diagrams like the following. Feel free to contact me to assist your comprehension of complicated architecture diagrams if you're out of tokens :)

Here's an aggregate summary of many days topics on how your architecture flow would look like if you needed to access a web application (instance) on AWS infra. I will be following the below diagram which is an easier diagram to explain than the one above:

  • First, you as the user would need to navigate to the web-address for the application (let us imagine the web address is the ELB which redirects traffic to one of three instances for the web application you are interested in)
  • If you have visited the address prior, through DNS caching, then you will be able to visit immediately else you will have to navigate the Route 53 process to find the correct web address
  • Then you will navigate to the ELB, which is hosted in public subnet i.e. accessible over public internet
  • Following this, the ELB will forward the request to be fulfilled by a instance in a private-subnet
  • Let us also imagine the ELB and private subnet and data subnets are all in the VPC (virtual private cloud). The ELB is simply in the public subnet of the VPC.
  • This means these subnets in the VPC can route to each other through local routes and security groups can determine if these are allowable connections i.e. instance to ElastiCache is allow
  • Then the request from your instance in the private subnet will redirect to the ElastiCache and if request has been cached, will return the request to the instance. Else, it will go to the RDS and read/write data and also cache that request in ElastiCache (if lazy-loading strategy)
  • Then the request will go back to your private subnet and then ELB and then back to the end-user

All daily logs