Section - High Availability and Scaling Flashcards
1
Q
What is a Launch Template?
A
- A launch template specifies all the needed settings that go into building out an EC2 instance.
- It is a collection of settings you can configure so you don’t have to walk through the EC2 wizard over and over.
- You need to know it includes the AMI, EC2 instance size, security groups amd potentially network information.
- NB: When network information is added, template cannot be used on auto-scaling.
2
Q
Launch Templates Vs. Launch Configurations?
A
Templates:
- More than just autoscaling
- Supports versioning
- More granularity
- AWS recommended
Configurations:
- Only for autoscaling
- Immutable
- Limited configurations options
- Don’t use them
3
Q
What are Auto Scaling Groups?
A
- An Auto Scaling Group contains a collection of EC2 instances that are treated as a collective group for purposes of scaling and management.
- Steps of Auto Scaling:
- Define your Template
- Networking and Purchasing (Multipe AZs, Instance types: spot instances/ on demand or reserved )
- ELB configuration
- Set Scaling Policies (desired capacity)
- Notifications (SNS)
4
Q
What are the Setting Capacity Limits?
A
-
Minimum
- This is the lowest number of EC2 instances you’ll ever have online. you won’t dip bellow this.
- Always set a minimum of 2 instances (high availability)
-
Maximum
- The highest number of EC2 instances you’ll ever provision.
-
Desired capacity
- How many instances do you want right now. never lower than minimum and never higher than maximum.
5
Q
Exam Tips: Auto Scaling and High Availability?
A
- Auto Scaling is important for creating a high available application
- Remember to select an answer that spread resources out over multiple Availability Zones and utilize load balancers.
-
Networking
- Auto Scaling groups will contain the location of where your instances live.
- Always select answers that include the elastic load balancer as well as the use of the ELB health checks.
6
Q
Instance Warm-Up and Cooldown?
A
-
Warm-up
- Stops instances from being placed behind the load balancer, failing the health check, and being terminated.
-
Cooldown
- Pauses Auto Scaling for a set amount of time. Helps avoid runaway scaling events.
-
Avoid Thrashing
- You want to create instances quickly and spin them down slowly.
7
Q
Scaling Types?
A
-
Reactive Scaling
- You playing catchup, Once the load is there, you measure it and then determine if you need to create more resources.
-
Scheduled Scaling
- If you have a predictable workload, create a scaling event to get your resources ready to go before they’re actually needeed.
-
Predictive Scaling
- AWS uses it’s machine learning algorithms to determine when you’ll need to scale. They are reevaluated every 24 hours to create a forecast for the next 48 hours.
8
Q
4 Ways to Scale relation database?
A
-
Vertical Scaling
- Resizing the database from one size to another can create greater performance
-
Scaling Storage
- Storage can be resized, but it’s only able to go up, NOT DOWN.
-
Read Replicas
- Creating read-only copies of our data can help spread out the workload.
-
Aurora Serverless
- We can offload the scaling to AWS. Excels with unpredictable workloads.
9
Q
What is DynamoDB?
A
- Fully Managed AWS database
- Scaling is simplified when using DynamoDB
-
Provisioned Capacity:
- Use Case
- Generally predictable workload
- Effort to Use
- Need to review past usage to set upper and lower slaing bounds
- Cost
- Most cost-effective model
- Use Case
-
On-Demand Capacity:
- Use Case
- Sporadic workload
- Effort to use
- Simple select on-demand
- Cost
- Pay small amount of money per read and write. Less cost effective.
- Use Case
10
Q
Exam Tips: DynamoDB?
A
- Predictable workload: Pick provisioned capacity
- Sporadic: Pick on-demand
-
Switching:
- You can switch, but only once per 24 hours per table
11
Q
4 Questions to Ask in the Exam?
A
- Is it highly available (Prioritize)
- Which is appropriate for situation:
- Horizontal Scaling or Vertical Scaling
- Is the scaling solution cost effective
- Would switching databases fix the problem.
- Auto Scaling is only for EC2 , no other servce cab be scaled using Auto Scaling.
- Get ahead of the workload: whenever possible, favor solutions that are predictive rather than reactive. If the work loads is predictive and starts @05:00, try to pick an earlier start time.
- Bake AMIs to reduce build times. You can avoid long provisioning times by putting everything in an AMI. This is better than using user data whenever possible.
- Spread out. Make sure your’re spreading your Auto Scalling groups over multiple Availability Zones.
-
Steady State Groups allow us to create situation where the failure of a legacy codebase or resource that can’t be scaled can automatically recover from failure.
- 1 Minimum
- 1 desired
- 1 Maximum
- Elastic load balancers are essential. Make sure to enable health checks from load balancers otherwise, instances won’t be terminated and replaced when they fail health checks.