2022-02-16 Chapter 13 - High Availability & Scaling

service-autoscaling-001; A {{c1::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.

service-autoscaling-002; A {{c1::launch template}} comprises the AMI, EC2 instance size, security groups and potentially networking information and user data.

service-autoscaling-003; Launch templates can be used for {{c1::autoscaling}} and other use cases.

service-autoscaling-004; Launch templates support v{{c1::ersioning}}.

service-autoscaling-005; Launch configurations are {{c1::older}} alternatives to {{c1::launch templates}}. They only support autoscaling, are immutable and offer relatively limited configuration options. Consider using {{c1::launch templates}} instead of launch configurations.

service-autoscaling-006; Auto scaling groups can span multiple {{c1::availability zones}}. Auto scaling will then {{c1::balance}} the number of instances across the {{c1::availability zones}}.

service-autoscaling-007; Auto scaling groups contain collections of {{c1::EC2 instances}} that are treated as a collective group for purposes for scaling and management.

service-autoscaling-008; Auto scaling groups can specify n{{c1::etworking}} s{{c1::pace}} and EC2 instance types.

service-autoscaling-009; Auto scaling groups can be set to use a {{c1::load balancer}} and respect {{c1::load balancer health checks}}.

service-autoscaling-010; Auto scaling groups allow you to specify a {{c1::minimum}}, {{c1::maximum}} and {{c1::desired}} capacity.

service-autoscaling-011; Auto scaling groups can inform an {{c1::SNS topic}} when a scaling event happens.

service-autoscaling-012; In autoscaling, an example of a {{c1::scaling out}} policy is "add 10 instances when average memory utilisation across live instances is 60-80%".

service-autoscaling-013; In autoscaling, an example of a {{c1::scaling in}} policy is "terminate 10 instances when average memory utilisation across live instances is 20-40%".

service-autoscaling-014; Autoscaling allows you to configure a {{c1::warm-up}} period during which instances are placed behind the load balancer, in order that {{c1::health-checks}} are not improperly failed.

service-autoscaling-015; Autoscaling allows you to configure a {{c1::cooldown}} period in which autoscaling is paused for a set amount of time (default = 5 mins). This helps to avoid {{c1::runaway}} scaling events.

service-autoscaling-016; AWS autoscaling supports three distinct types of scaling. 1) {{c1::reactive}} scaling in autoscaling takes action in response to observed metrics 2) {{c1::scheduled}} scaling creates resources ahead of a predictable increase in workload 3) {{c1::predictive}} scaling uses machine learning algorithms to predict usage over the coming 48 hours, updated every 24 hours.

service-autoscaling-017; A specific "steady-state" autoscaling configuration is where minimum, maximum and desired capacity instances are all set to {{c1::1}}. This allows high-availability for legacy applications that can {{c1::only run on one machine at a time}}.

service-autoscaling-018; It's possible to bake {{c1::dependencies into AMIs}} to reduce provisioning times for new instances. This is generally faster than using the user data.

service-autoscaling-019; A sensible approach for autoscaling is to scale out {{c1::aggressively}} and scale in {{c1::conservatively}}.

service-autoscaling-020; There are 4 types of scaling which are relevant for RDS. 1) vertical scaling, where you resize a database from one {{c1::instance type}} to another 2) scaling {{c1::storage}}, although it's only possible to go up (not down) if you're not using Aurora (Aurora scales {{c1::storage}} automatically ) 3) {{c1::read-replicas}} can help to spread a read-heavy workload and 4) {{c1::Aurora Serverless}} automatically scales and excels with unpredictable workloads.

service-autoscaling-021; Refactoring and changing to {{c1::DynamoDB}} is a viable scaling choice for RDS instances, even though this would be a time-consuming option in the real world.

service-autoscaling-022; DynamoDB offers a {{c1::provisioned}} scaling model, for generally predictable workloads. This requires that you review past usage and set upper and lower bounds. {{c1::Provisioned}} capacity can use flat capacity, or variable capacity based on target utilisation.

service-autoscaling-023; DynamoDB offers an {{c1::on-demand}} scaling model, for sporadic workloads. This requires less planning effort on the part of the user, but is less cost-effective as users pay a small amount of money per read and write.

service-autoscaling-024; Avoiding "hot keys" will lead to better performance in {{c1::DynamoDB}}.

service-autoscaling-025; You can switch a DynamoDB capacity type (provisioned <=> on-demand), but only once every {{c1::24 hours}} per table.

service-autoscaling-026; The Default Termination Policy for autoscaling groups ensures that instances using the {{c1::oldest}} launch template or configuration are terminated {{c1::before}} those {{c1::using}} newer templates or configurations.

service-autoscaling-027; Fault tolerance is a higher bar than high availability as it implies {{c1::totally concealing faults from the user}}.