Case 1: WhatIsTheTime.com
Simple start
- Use T2 instance
- EIP to public access
CONS:
- When more people come to your website, T2 instance is not enough to handle.
- Change T2 to M5 to vertically scale out EC2
CONS:
- When change from T2 to T5, users experience downtime
- We grow horizontally by adding more M5 instances with EIPs
CONS:
- Users need to remember the IP addresses
- We have to manage more infrstrures
Route 53
- We don't user EIP anymore
- We use Route 53 A Record point to EC2' public IP
- With TTL 1 hours
CONS:
- When we remove one instance, users for that instances cannot access app anymore, downtime for 1 hour
Load Balaner
- We have EC2 instances in one AZ
- We add ELB health check
- Security group for EC2, only allow connection from ELB
- Since we are using ELB, the IP address change all the time, we have to use Route 53 Alias Record.
- Now load balacner + health check, we won't experience downtime anymore when we add/remove instance
CONS:
- Adding / removing EC2 is hard to do manully
ASG
- With ASG, we are able to scale up/down based on traffic or time
- We also make EC2 instance in private subnet to make it enhance security
CONS:
- How about disaster happen to that AZ?
- Deploy EC2 in multi AZ for DR
- ELB also in multi AZ
CONS:
- How about cost?
- If we know that we have to use 2 AZs, then we must have at least 2 EC2 instances in total, one for each.
- Then we can reserve instances for cost saving
Summary
- Public vs Private IP and EC2 instanes
- EIP vs Route 53 vs Load Balancers
- Route 53 TTL, A record and Alias Recoreds
- ASG vs Maintaining EC2 instances manually
- Multi AZ to survive disasters
- ELB Health Checks
- Security Group Rules
- Reservation of capacity for costing saving when possible
- 5 Pillars for well architected application:
- Performance
- Reliabillity
- Security
- Cost
- Operational excellence
Case 2
For a stateless application, it doesn't matter, everytime users visit page, traffic goes to the same EC2 instance or not.
But for stateful application, it does matter. Imaging shopping cart app, suddendly after refresh the page, data is lost. That is really bad.
- We can enable ELB Affinity (stickniess), so that everytime, same user goes to same instance.
CONS:
- We might still lose the data once one EC2 goes down.
- Let's say that we want to make EC2 instance stateless by store the shopping cart information in Cookies
CONS:
- Secuirty risk by alert cookies
- More validations needed
- Limit on Cookies size 4 KB
- Now let's try to use Session with Session ID
- Instead of sending whole shopping cart information, we just send session_id from client
- We can use ElastiCahe or DynamoDB to store shopping cart information by session_id
- Now that each request can go to different EC2 instace
- And we still able to get all the information needed from DB
- We can use RDS to stroe the data
CONS:
- Read performance
- Create Read Replicas for read operations
or
- Can use ElastiCache to cache the content with Write Through, so keep the cache up to date
- Enable multi AZ for ELB, ElasticCache, RDS
- Simpfiy with Aurora with Multi AZ
Summary
- 3-tier architecture for web applications
- ELB sticky sessions
- Web clients for storing cookies and making our web app stateless
- ElastiCache
- For storing session (or DynamoDB)
- For caching data from RDS
- Multi AZ
- RDS
- For storing user data
- Read replicas for scaling reads
- Multi AZ for disaster recovery
- Tight Security Group referencing each other
- Aurora
Case 3 Wordpress
- We can save the images/files into EFS
- Each instances should has ENI to talk to EFS
Case 4 Instantiating Applications quickly
- EC2 Instances
- Use a Golden AMI: Install your app, OS dependencies etc... beforehand and launch your EC2instance from the Golden AMI
- Boostrap using User Data: For dynamic configuration, use User Data Scripts
- Hybrid: mix Golden AMI and User Data (Elastic Beanstalk)
- RDS
- Restore from a snaphost: the database will have schemas and data ready
- EBS
- Restore from a snapshot: then disk will already be formatted and have data