An AWS Cloud architecture for web hosting - 3 Tiers

Public Terraform source: https://github.com/nhancv/terraform.aws.public

Best practice: https://docs.aws.amazon.com/whitepapers/latest/web-application-hosting-best-practices/an-aws-cloud-architecture-for-web-hosting.html

I saw some mistakes of Full-stack developers about web hosting. To deliver better app should check some points:

  • Make sure you optimize the app logic first. (redundancy requests, too much bad interval calling, asynchronous callback handling, crashing loop, heavy process — need split them to smaller logic or put to async response with queue, unsafe type, …….. a lot =]] )
  • Design infrastructure before deployment, estimate and make sure the arch scalable, upgradeable, fault tolerance and high availability
  • Stress-test and security checking the system before live. (Spoofing email, Leak server IPs, WAF, Rate limiting, Bad url request, user agent, CDN to cache big/static files, ….)

This post just share about basic 3 tiers architecture and deploy to AWS Cloud via Terraform script

About scaling application, I suggest you should consider about microservices approach:

We should have a separate Database service to control all access to the database, do not allow other service access to db directly, it’s suck

And this is a base template for each microservice 

This post shares about basic 3 tiers architecture and deployment to AWS Cloud via Terraform script

  • Use us-east-1 as main region
  • 1 VPC: 10.0.0.0/16
  • 2 Availability Zones: 1a, 1b
  • 1 Public subnet each zone: Deploy NAT gateway and NAT instance (bastion host) with ASG (Auto Scaling Group), ALB (Application Load Balancing) for Frontend subnet
  • 3 Private subnet each zone:
    ++ Frontend subnet: receive traffic from ALB (public subnet, internet facing) forward to ASG target of Frontend website instances
    ++ Backend subnet: receive traffic from internal ALB and forward to Backend ASG to solve private business logic
    ++ Database subnet: receive traffic from internal ALB of Database microservice which handle all access to database
  • Each ASG enables health checks of EC2 status and ELB also. Scaling Policy apply on 2 types:
    ++ Predictive status for scaling automatically
    ++ Dynamic with Cloudwatch alarm based on EC2 CPU status

Clone the repo. Read and follow README.md

Run:

terraform apply -auto-approve

Apply results

Try to access public frontend DNS:

frontend1frontend2
This image has an empty alt attribute; its file name is 9e48408b-16fa-436e-9d9a-0f5a2c7c9ec0This image has an empty alt attribute; its file name is dc9d39ba-6e19-43b8-9cdb-ec2166ebe4aa

Load Balancers

Instances

Auto Scaling Groups

Automatic Scaling

Subnets

Access to instance

SSH to Bastion using public IP

ssh -i key_pairs/draft-project-key-bastion [email protected]

SSH to Frontend private instance

Only available in Bastion host

Destroy deployment

terraform destroy

Everything destroyed, don’t worry any leak resources impact to your billing now. :3 

Leave a Reply

Your email address will not be published.Required fields are marked *