AWS Cloud Practitioner Study Notes · Part 33
EC2 Scaling: Vertical, Horizontal, and Auto Scaling Groups
AWS Cloud Practitioner study notes explaining EC2 scale up, scale out, Auto Scaling Groups, launch templates, policies, health checks, and load balancers.
EC2 scaling means adjusting compute capacity as demand changes. You can make one instance larger, add more instances, or automate both the decision and the replacement of unhealthy instances. The most common highly available pattern combines an Auto Scaling group with an Elastic Load Balancer.
This is Part 33 of the AWS Cloud Practitioner Study Notes. Part 16 introduced EC2 instance families and lifecycle states, while Part 28 covered the VPC and subnet foundations around EC2 workloads.
Vertical and horizontal scaling
| Scaling type | What changes | Example |
|---|---|---|
| Vertical scaling, or scale up/down | Size of one instance | t3.small → m7i.large |
| Horizontal scaling, or scale out/in | Number of instances | 2 EC2 instances → 6 EC2 instances |
Vertical scaling: use a bigger instance
Vertical scaling increases the CPU, memory, or other capacity available to one EC2 instance.
Application
│
▼
t3.micro → t3.small → m7i.largeIt is straightforward and can help a database or application server that needs more memory or CPU. However, the instance still has a maximum size, may require a stop and start for the change, and remains a single point of failure unless another availability design is added.
Exam shortcut: “increase RAM,” “larger instance,” or “more CPU on the existing server” → vertical scaling.
Horizontal scaling: use more instances
Horizontal scaling adds or removes instances instead of making one instance larger.
Load balancer
/ | \
EC2 EC2 EC2Horizontal scaling can improve capacity and availability because traffic can be spread across multiple instances. It works best when the application is designed to run across interchangeable instances, with shared or externalised state where necessary.
Exam shortcut: “add more servers,” “distribute traffic,” or “scale out” → horizontal scaling.
What an Auto Scaling Group does
An Amazon EC2 Auto Scaling group is a logical group of EC2 instances that maintains capacity, performs health-check replacement, and applies scaling policies. It launches enough instances to meet the desired capacity and keeps the group between the configured minimum and maximum.
Auto Scaling Group
├── Minimum capacity: 2
├── Desired capacity: 3
└── Maximum capacity: 10- Minimum capacity: the group should not normally go below this number.
- Desired capacity: the target number of running instances.
- Maximum capacity: the upper limit for automatic scale-out.
If an instance becomes unhealthy, the group can terminate it and launch a replacement. This is different from scaling because the goal is to restore the desired capacity, not necessarily to respond to higher or lower demand.
The components required for automatic EC2 scaling
An Auto Scaling design normally includes these components:
| Component | Responsibility |
|---|---|
| Launch template | Blueprint for new EC2 instances |
| Auto Scaling group | Maintains and adjusts instance capacity |
| CloudWatch | Provides metrics and alarms used by scaling policies |
| Scaling policy | Defines when and how capacity changes |
| Elastic Load Balancer | Distributes requests across healthy instances |
| Health checks | Detect unhealthy instances or application targets |
| User data or lifecycle hook | Bootstraps the instance and application when needed |
The load balancer is not strictly required for an Auto Scaling group, but it is strongly recommended for a web application. Without it, new instances may exist without a reliable way for users to reach them.
Step 1: Create a launch template
A launch template tells the Auto Scaling group how to create a new EC2 instance. It can specify:
- AMI ID
- Instance type
- Security groups
- IAM instance profile
- Key pair, if required
- EBS volume mappings
- User data script
- Tags and other launch settings
Launch template
│
▼
Repeatable EC2 instance configurationTreat the template as a versioned, repeatable blueprint. If the application is deployed with an immutable image, the AMI can already contain the runtime and application. If not, user data can install packages and start the service during boot.
Step 2: Create the Auto Scaling group
Create the group using the launch template and choose the VPC subnets or Availability Zones where instances should run. Then set the minimum, desired, and maximum capacity.
Example:
Minimum = 2
Desired = 3
Maximum = 10The group launches enough instances to reach the desired capacity and keeps the count within the bounds as policies change the desired capacity.
For high availability, use subnets in more than one Availability Zone. The group can then replace an instance in another zone if one zone or instance becomes unavailable, subject to the configured capacity and placement strategy.
Step 3: Attach an Elastic Load Balancer
An Application Load Balancer can be associated with the Auto Scaling group through a target group. The load balancer becomes the stable entry point, while instances can be added and removed behind it.
Users
│
▼
Application Load Balancer
│ │ │
EC2 EC2 EC2The load balancer routes requests to healthy registered targets. When a new instance is registered and passes its initial health check, it can begin receiving traffic.
Step 4: Configure health checks
Auto Scaling uses EC2 status checks by default and can also use Elastic Load Balancing health checks when the group is attached to a load balancer.
An EC2 status check can show that the virtual machine is running, while an application health check can test whether the service actually responds:
GET /health → HTTP 200 → healthy targetThis distinction matters. An instance may be running while its web server or application process has crashed. The ALB health check can mark the target unhealthy and stop sending it requests, while the Auto Scaling group can replace it when configured to use ELB health checks.
Step 5: Choose a scaling policy
Scaling policies change the desired capacity of the Auto Scaling group within its minimum and maximum limits.
Target tracking scaling
Target tracking maintains a target value, similar to a thermostat. For example, you might target average CPU utilisation of 50%. EC2 Auto Scaling creates and manages the CloudWatch alarms needed to move capacity toward that target.
Step scaling
Step scaling changes capacity by different amounts depending on how far a CloudWatch alarm is beyond its threshold. For example:
CPU 60–75% → add 1 instance
CPU 75–90% → add 2 instances
CPU > 90% → add 4 instancesScheduled scaling
Scheduled scaling is useful when demand follows a known schedule. If traffic reliably increases every Friday evening, increase desired capacity before the expected event and reduce it afterwards.
Predictive scaling
Predictive scaling uses historical usage patterns to forecast future demand and schedule capacity changes. It is useful when recurring traffic patterns can be learned from metrics.
Exam shortcut: react to current metrics → dynamic scaling; fixed known time → scheduled scaling; forecast future demand → predictive scaling.
Step 6: CloudWatch provides the signals
Scaling policies use CloudWatch metrics. Common signals include:
- Average CPU utilisation
- Network traffic
- Application Load Balancer request count per target
- Latency or response time
- Custom application metrics
- Queue depth, such as messages waiting in Amazon SQS
Memory is not automatically available as a standard EC2 metric in the same way as CPU. If memory should drive scaling, install and configure the CloudWatch agent or publish a custom metric.
The general flow is:
Metric increases
│
▼
CloudWatch alarm or target-tracking evaluation
│
▼
Scaling policy changes desired capacity
│
▼
Auto Scaling group launches or terminates instancesScale-out workflow
Suppose an online store experiences a flash sale and average CPU rises above the policy target.
1. CloudWatch observes the metric
2. Scaling policy evaluates the target or alarm
3. Auto Scaling group increases desired capacity
4. Group launches an EC2 instance from the launch template
5. EBS, security groups, IAM role, and user data are applied
6. Operating system and application start
7. Instance is registered with the load balancer
8. Health check passes
9. Load balancer routes traffic to the new instanceThe instance may take time to boot and become ready. Configure instance warmup, health-check grace periods, and application startup so the policy does not repeatedly launch more instances while new capacity is still coming online.
If bootstrapping takes significant time, a lifecycle hook can pause the instance in a wait state while automation installs the application, loads configuration, or performs registration. The hook can then signal that the instance is ready to continue.
Scale-in workflow
When demand falls, the group can reduce desired capacity:
1. CloudWatch observes lower demand
2. Scaling policy allows scale-in
3. Auto Scaling group selects an instance to terminate
4. Instance is deregistered from the load balancer
5. Existing connections are allowed to drain
6. Optional termination lifecycle hook runs
7. EC2 instance is terminatedElastic Load Balancing uses a deregistration delay so new requests go to other targets while in-flight requests can complete. This protects users from an instance disappearing while it is still serving a request.
Automatic replacement is not the same as scale-out
These two events can look similar but have different causes:
Unhealthy instance → replace it to restore desired capacity
High demand → add capacity to serve more traffic
Low demand → remove excess capacity to reduce costAn Auto Scaling group handles all three when configured appropriately. Health checks maintain instance quality; scaling policies respond to capacity demand.
Complete production architecture
Internet
│
Application Load Balancer
/ | \
EC2 EC2 EC2
\ | /
Auto Scaling Group
min=2, desired=3, max=10
│
CloudWatch metrics
│
Scaling policy
│
Launch templateFor a stateful application, do not assume that adding instances automatically solves every problem. Sessions, uploaded files, caches, database connections, and background jobs may need external services or careful coordination so each instance can be replaced safely.
Common exam questions
| Scenario | Likely answer |
|---|---|
| Increase CPU or RAM on one EC2 instance | Vertical scaling |
| Add more EC2 instances | Horizontal scaling |
| Automatically add or remove instances | Auto Scaling group |
| Distribute requests across instances | Elastic Load Balancer |
| Replace unhealthy instances | Auto Scaling group health checks |
| Scale when CPU or request count changes | Dynamic scaling policy |
| Scale at a known time | Scheduled scaling |
| Scale before recurring predicted demand | Predictive scaling |
| Define how new instances are created | Launch template |
| Ensure a new instance serves only after the app is ready | Load-balancer health check, optionally with a lifecycle hook |
Common exam traps
Vertical scaling versus horizontal scaling
Changing t3.small to m7i.large is vertical scaling. Adding three more EC2 instances is horizontal scaling.
Auto Scaling versus load balancing
An Auto Scaling group changes the number of instances. An Elastic Load Balancer distributes requests. They complement each other but are not the same service.
CPU scaling versus memory scaling
CPU is a common EC2 metric. Memory usually requires the CloudWatch agent or a custom metric.
Readiness versus instance status
An EC2 instance being running does not prove that the application is ready. Use an application health endpoint and appropriate warmup or lifecycle controls.
Scaling versus backups
Adding instances improves compute capacity and availability. It does not back up application data or make a stateful database horizontally scalable by itself.
Memory map for CLF-C02
- Need a bigger server? → Vertical scaling
- Need more servers? → Horizontal scaling
- Need automatic capacity changes? → Auto Scaling group
- Need traffic distribution? → Elastic Load Balancer
- Need a repeatable instance blueprint? → Launch template
- Need to react to CPU or request metrics? → Dynamic scaling
- Need to scale at a fixed time? → Scheduled scaling
- Need a forecast-based capacity change? → Predictive scaling
- Need to replace an unhealthy instance? → Auto Scaling group health checks
Conclusion
EC2 scaling is a system, not a single button. A launch template defines the instance, an Auto Scaling group maintains capacity, CloudWatch supplies metrics, scaling policies decide when capacity changes, and an Elastic Load Balancer routes traffic to healthy instances.
For scale-out, AWS launches and bootstraps a new instance, waits for health checks, and registers it with the load balancer. For scale-in, AWS deregisters the instance, allows connections to drain, and then terminates it. Understanding this lifecycle makes the exam concepts more concrete and helps you design safer production deployments.