username

aws_access_key_id

aws_secret_access_key

aws_region

Github_Token

domain

Git_username

Become an AWS pro with insights from a seasoned Amazon engineer. Get hands-on with essential AWS services like DynamoDB, S3, and EC2. No setup, no cleanup, no hassle.

local.tar.gz

NodeHelloWorld

NodePackageChange

NodeGithub

InfrastructureAsCode

ADCodebuildGithub

AutomaticDeployments1

AutomaticDeployments2

LoadBalancing1

Scaling1

Production1

CustomDomain1

Https1

NetworkSecurity1

NodeGithub-copy

AutomaticDeployments1-copy

Production1-copy

CustomDomain1-copy

Https1-copy

NetworkSecurity1-copy

This is not your typical AWS reference course. You won’t find most of the knowledge that's shared here in the AWS docs. The goal here is to help you realize which AWS features you’d be foolish not to use — features that have passed the test of time by being at the backbone of most things on the Internet.

In this course, you'll learn a technique used to help make reliable technical choices without getting paralyzed in the face of so many options. You’ll start by going through the most fundamental services AWS offers such as DynamoDB, S3, EC2. Each section breaks down how it’s used, the pros and cons, why you should (or shouldn't) be using it, and more.

This course was written by a former Amazon engineer with 15 years of experience working on AWS.

The Good Parts of AWS: Cutting Through the Clutter

Amazon will tell you that Auto Scaling allows you to automatically add or remove EC2 instances based on the fluctuating demands of your application. This sounds great in theory, and while we’ve certainly seen that work successfully in a few places, it’s almost never useful except in very specific situations. 
You will almost never need to use the auto part of Auto Scaling for the reason it exists.



## When to use Auto Scaling?

Let’s start by seeing how you should decide how many EC2 instances to run. 

### Capacity headroom

You obviously need to have enough instances to meet your expected peak demand. But you probably don’t want your capacity to exactly match the demand with no leeway. You will want to have some headroom too. This headroom is not waste—it will act as a safety buffer that can absorb many types of unpredictable events. For example:
- If an availability zone were to go down and you lost half of your instances, the headroom in the remaining instances can compensate for the lost capacity. 
- Or if there were to be a sudden increase in demand, the same headroom will be immediately available to take it. 
- Or if for some reason the performance of your system were to degrade abruptly (due to a software bug, a bad instance, etc.), that same headroom may help compensate the excess load.

So, a capacity headroom is a wonderful thing. You definitely need some. And if you can afford to, it’s probably wise to have a lot of it. It can help you sleep well at night—sometimes in the literal sense.

### Cost usage ratio


The main premise of Auto Scaling is that once you decide how much headroom you want, you’ll be able to make that headroom a constant size, even as the demand for your instances fluctuates. Therefore, a simpler way to look at Auto Scaling is to see it as just a cost reduction tool. Because what’s wrong with having excess headroom during off-peak periods? Absolutely nothing, except cost.

Therefore, the first question you should ask yourself is: 

- Are your EC2 costs high enough that any reduction in usage will be materially significant? 

- As a thought experiment, consider if your EC2 bill were to go down by 30%—would that be a big deal for your business? 

If not, the effort and complexity of getting Auto Scaling working properly is probably not going to be worth it. You might as well just keep the extra headroom during off-peak periods and let it work for you in case of an emergency.





# When to use Auto Scaling?

Let’s start by seeing how you should decide how many EC2 instances to run. 

## Capacity headroom

You obviously need to have enough instances to meet your expected peak demand. But you probably don’t want your capacity to exactly match the demand with no leeway. You will want to have some headroom too. This headroom is not waste—it will act as a safety buffer that can absorb many types of unpredictable events. For example:
- If an availability zone were to go down and you lost half of your instances, the headroom in the remaining instances can compensate for the lost capacity. 
- Or if there were to be a sudden increase in demand, the same headroom will be immediately available to take it. 
- Or if for some reason the performance of your system were to degrade abruptly (due to a software bug, a bad instance, etc.), that same headroom may help compensate the excess load.

So, a capacity headroom is a wonderful thing. You definitely need some. And if you can afford to, it’s probably wise to have a lot of it. It can help you sleep well at night—sometimes in the literal sense.

## Cost usage ratio


The main premise of Auto Scaling is that once you decide how much headroom you want, you’ll be able to make that headroom a constant size, even as the demand for your instances fluctuates. Therefore, a simpler way to look at Auto Scaling is to see it as just a cost reduction tool. Because what’s wrong with having excess headroom during off-peak periods? Absolutely nothing, except cost.

Therefore, the first question you should ask yourself is: 

- Are your EC2 costs high enough that any reduction in usage will be materially significant? 

- As a thought experiment, consider if your EC2 bill were to go down by 30%—would that be a big deal for your business? 

If not, the effort and complexity of getting Auto Scaling working properly is probably not going to be worth it. You might as well just keep the extra headroom during off-peak periods and let it work for you in case of an emergency.



Compute: EC2 Auto Scaling

Before Getting Started

Part 1: The Good Parts

Part 2: The Bootstrap Guide

Host Our Application on EC2 Instance

Infrastructure as Code

Automatic Deployments: Create a CI/CD Pipeline

Load Balancing: Add an Application Load Balancer

Scaling: Add an Auto Scaling Group

Conclusion

Compute: EC2 Auto Scaling

When to use Auto Scaling?

Capacity headroom