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:
frontend1 | frontend2 |
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