Chapter 17: Scaling

17.3 Manual scaling

By Ravindra Bagale · Last updated: 3 October 2026

In short: Manual scaling means a person adds or removes capacity.

Manual scaling means a person adds or removes capacity. There is no alarm yet. You are the policy. That is enough when you can see the busy time coming and you will be at the console: a demo at 6 pm, a workshop you are teaching, a sale you scheduled. It is not enough for the 3 am spike, or for the reel that goes viral while you are on a train. Those need the alarm in the next sections. The knobs are the same either way. Manual means your hand turns the knob.

Two ways. This section walks through both. The first one launches a real second instance. The second one only changes a number, and you will click it again in section 17.6 after the Auto Scaling group exists. Do not invent a group in this section.

Worked example: launch a second instance from the same AMI

You already have instance A, the t3.micro that serves example.com, back on t3.micro after section 17.1. Section 14.2 showed you how to create an AMI from an instance. Use that AMI if you have it. If you do not, create one from instance A before you rely on a second copy: the second computer must boot with Nginx and the site already on the disk. An empty Amazon Linux AMI is not example.com.

Instance B must be the same architecture. The AMI of an x86 t3.micro launches another x86 instance. Do not pick t4g.micro.

Build the front door first, so B is not an empty room.

1. EC2, Target groups, Create target group. Target type Instances. Name example-web-tg. Protocol HTTP, port 80. VPC: the VPC of instance A. Health check path /. Create. Names may vary.
2. Load balancers, Create, Application Load Balancer. Name example-web-alb. Scheme Internet-facing. Pick the same VPC and two subnets in different Availability Zones. Security group: allow HTTP 80 from the internet for this lab.
3. Listener HTTP : 80, forward to example-web-tg. Create the balancer. Wait until the state is Active. Copy its DNS name.
4. Register instance A in example-web-tg on port 80. The security group of instance A must allow port 80 from the balancer's security group. Not from the whole internet, if you can avoid it. The balancer is who talks to the instance.
5. Point a test in your browser at the balancer DNS name. You should see the same page as example.com. When you are ready to use the real name, point example.com at that DNS name the way Chapter 9 points a name at a target. Until DNS is changed, the balancer's own name is the proof.

Launch instance B from the AMI.

1. EC2, Launch instance. Name example-web-b.
2. My AMIs, the AMI you took from instance A. Instance type t3.micro. Same key pair as A, so you can SSH.
3. Network: same VPC, a subnet the balancer can reach. Security group: the same rules as A, including port 80 from the balancer and port 22 from your IP so you can log in.
4. Launch. Wait until the state checks pass.
5. Target groups, example-web-tg, Register targets, choose instance B, port 80. Wait until the health check says healthy. A target that is still "initial" is booting. Give it a minute.

What you should see. The target group lists two healthy t3.micro instances. Refresh the balancer URL several times. You are not required to see different pages. You are required to see the site keep answering if you stop instance A as a test and start it again. That is the difference from section 17.1. Stop one web server, example.com (through the balancer) still answers from the other. Start A again, and both are back.

Then put the lab down. Deregister B if you are not going straight into section 17.6, and terminate B. An Application Load Balancer left behind also keeps running. Delete the lab balancer and the target group when the chapter lab is over, or reuse this same target group in section 17.6 and delete it at the end. Do not finish the day with a second instance you forgot.

# on instance B, after SSH, prove it is the same kind of server
nproc
free -h
sudo service nginx status

nproc is 2 and free -h is about 1 GiB, because B is a t3.micro, not a t3.small. The AMI did not change the type. You chose the type at launch.

The other manual knob: desired capacity

When the instances belong to an Auto Scaling group, you do not launch instance B by hand. You open the group and change Desired capacity from 1 to 2. The group launches the extra instance from the launch template. Set desired back to 1 and the group terminates one. Your hand, the group's machinery. Section 17.6 builds the group. The number you type is the whole action: no SSH, no second trip through the launch wizard.

When manual is enough