# Performance Tuning and Rightsizing

> Chapter 14 of the Courseiva AWS-SYSOPS-ASSOCIATE curriculum — https://courseiva.com/learn/aws-sysops-associate/performance-tuning-and-rightsizing

**Official objective:** 3.2 — Identify and implement performance improvements and rightsizing for EC2 and other services

## Introduction

How do you make sure your cloud servers are fast enough for busy periods but not so oversized that you are wasting money on resources you never use?

That's the core challenge of performance tuning and rightsizing for the AWS Certified SysOps Administrator exam. You will need to understand how to monitor a server's CPU, memory, and network usage, then adjust the server's size or configuration so it runs efficiently and cost-effectively—like buying the right-size vehicle for your daily commute instead of driving a 12-seater minibus when you only carry one passenger.

## The Coffee Shop Renovation Analogy

Have you ever run a coffee shop on a Saturday morning, with customers lined up out the door, and realised your single espresso machine can only make one drink every 90 seconds?

That's exactly the problem performance tuning and rightsizing solves in the cloud. Your coffee shop is like an Amazon EC2 instance—a virtual server. The espresso machine is its CPU (the brain that does calculations). The grinder is the memory (RAM, or random access memory, which holds short-term data for quick access). The fridge is the storage (the hard drive). Your staff are the network bandwidth (how much data can move in and out).

On a slow Tuesday, you might have only one barista, one machine, and five customers an hour—plenty of capacity. But on Saturday, you need two machines, a bigger fridge for more milk, extra staff, and a faster grinder to keep up. Performance tuning means tweaking what you already have: calibrating the grinder to be finer, rearranging the workflow so staff don't bump into each other, and pre-pouring milk before the rush. Rightsizing means swapping your tiny espresso machine for a bigger one (choosing a larger EC2 instance type), or replacing your cramped shop with a double-storey space (moving to a different instance family with more resources).

AWS gives you tools like CloudWatch (a dashboard that shows your shop's metrics—cups per hour, wait times, fridge temperature) and Auto Scaling (an automatic system that brings in a second mobile espresso cart when the line gets long). The goal is to serve every customer quickly without renting so many machines that your profit disappears. You don't want the shop to be empty and slow in the afternoon while you pay for six baristas, nor do you want to lose customers because your single machine can't handle the morning rush.

## Core explanation

Performance tuning and rightsizing are two connected ideas that help you get the best speed and reliability from your AWS resources (like virtual servers, databases, and storage) while paying the lowest possible price. Let's break both down separately, then see how they work together.

First, what is a virtual server in AWS? It is called an EC2 instance (Elastic Compute Cloud). EC2 is a service that lets you rent a slice of a physical computer inside one of Amazon's data centres. That slice behaves exactly like your own computer: it has a CPU (the processor that does calculations), memory (RAM—random access memory, used for running applications), storage (a virtual hard disk called an EBS volume—Elastic Block Store), and network bandwidth (the speed at which data travels to and from the internet or other AWS services).

When you launch an EC2 instance, you pick an instance type, which defines the exact mix of CPU, memory, and network speed. For example, a t2.micro has 1 virtual CPU and 1 GB of RAM. A c5.xlarge has 4 virtual CPUs and 8 GB of RAM. There are families designed for different workloads: compute-optimised (C series) for heavy number crunching, memory-optimised (R series) for big databases that need lots of RAM, and general-purpose (M or T series) for average web servers.

Performance tuning means adjusting the configuration of your running instance so it uses its resources more efficiently. You might not need to change the instance type at all. Instead, you could:

- Optimise the software running on the instance—for example, configuring a web server like Apache or Nginx to use fewer CPU cycles per request.
- Adjust the application's code or database queries so they don't make unnecessary requests.
- Tune the operating system's kernel parameters (the low-level settings that control how the OS manages memory and processes).
- Use caching (temporarily storing frequently accessed data in fast memory) to reduce the load on the CPU and storage.

Rightsizing, on the other hand, means changing the instance type itself to better match your actual workload. If your monitoring shows you are consistently using only 10% of your CPU but 90% of your memory, you are not well matched—you could switch to an instance with less CPU and more memory, saving money. Rightsizing can involve:

- Moving to a smaller instance type (downgrading) when usage is low over a long period.
- Moving to a larger instance type (upgrading) when you are hitting the ceiling—for example, your CPU is pegged at 100% and your app is slow.
- Switching to a different instance family—for instance, from a general-purpose t3.medium to a compute-optimised c5.large if your workload is CPU-bound.

How do you know when to tune versus when to rightsize? This is where monitoring becomes critical. AWS provides Amazon CloudWatch, a service that collects metrics (measurements) from your instances, such as CPU utilisation (the percentage of the CPU's time that is busy), memory utilisation, disk read/write operations, and network traffic. You can set alarms that trigger when a metric crosses a threshold—for example, if CPU utilisation stays above 80% for 10 minutes, CloudWatch can send you a notification.

Another important tool is AWS Compute Optimiser. This service analyses your historical usage patterns across all your EC2 instances and makes specific recommendations. It might say: 'Your web-server-1 instance has been using 15% CPU and 50% memory for the last two weeks. We recommend moving from a t3.large to a t3.medium, which will save you 40% per month.' Compute Optimiser uses machine learning (a type of artificial intelligence that learns from data patterns) to give these suggestions.

Finally, there is Auto Scaling. This is not directly a rightsizing tool, but it works closely with it. Auto Scaling automatically adjusts the number of EC2 instances in a group based on demand. For example, from 9 AM to 5 PM, your e-commerce site might need 10 instances; at night it might need only 2. Auto Scaling can spin up new instances during the busy period and shut them down during the slow period, so you pay only for what you use. Rightsizing complements this by ensuring each individual instance is the appropriate size—there is no point having 10 instances if each one is huge and wasteful.

## Real-world context

Imagine you work as a SysOps administrator for an online retail company that runs its entire website on AWS. The website gets most of its traffic between 10 AM and 2 PM on weekdays, and also gets spikes during sales events like Black Friday. You have about 50 EC2 instances total—some for the web server, some for the database, and some for background processing of orders.

A few weeks after you join, your manager notices the AWS bill has been growing every month. She asks you to investigate and reduce costs without slowing down the site. Where do you start?

First, you log into the AWS Management Console and open CloudWatch. You look at the 'CPUUtilization' metric for each of your 50 instances over the last 30 days. You notice that 20 of the instances—the ones running the database—never go above 15% CPU usage. That means you are paying for a Ferrari when a bicycle would do the job. You also see that 10 of the web server instances hit 95% CPU for an hour each afternoon, then drop to 30% the rest of the day. That suggests you need something flexible.

Your next step is to use AWS Compute Optimiser. You click 'Get recommendations' and it returns a list of suggested changes. For the database instances, it recommends downgrading from an r5.large (2 vCPUs, 16 GB RAM) to an r5.small (1 vCPU, 8 GB RAM). You apply that change one at a time, monitoring the database's response time to ensure it does not slow down. After switching all 20, you see an immediate drop in the monthly bill.

For the web servers that spike in the afternoon, rightsizing alone is not enough—you need elasticity. You set up an Auto Scaling group. You configure it to start with 5 instances as a minimum, then add 1 instance for every 10% increase in CPU utilisation above 60%, up to a maximum of 15 instances. You also adjust the health check settings so that if an instance becomes unresponsive for 30 seconds, Auto Scaling replaces it automatically.

Finally, you check the remaining 20 instances—these run background batch jobs that process inventory updates once a day. They complete within 30 minutes but then sit idle for 23.5 hours. You change these to use EC2 Spot Instances, which are spare compute capacity that AWS sells at up to 90% discount. Spot Instances can be reclaimed by AWS at any time, but for a short batch job that can restart from where it stopped, that's fine. You also set up a lifecycle hook so the job finishes gracefully if AWS reclaims the instance.

Over the next month, the company's EC2 bill drops by 35%. The website stays fast during peak hours because Auto Scaling kicks in. The database continues to perform well because you rightsized correctly. Your manager is happy, and you just saved the company thousands of dollars a month.

## Exam focus

The SOA-C02 exam tests performance tuning and rightsizing in a very specific, predictable way. You need to know the exact AWS services involved, the metrics they provide, and the most common mistakes exam writers love to trap you with.

First, know the tools:

- Amazon CloudWatch: The central monitoring service. It collects metrics like CPUUtilization, NetworkIn, NetworkOut, DiskReadOps, and DiskWriteOps. You should be able to interpret these metrics to decide whether to scale up (rightsize) or scale out (increase instance count).
- AWS Compute Optimiser: This is the rightsizing recommendation engine. It uses machine learning to suggest instance type changes. It requires at least 30 hours of historical metric data before it can make recommendations.
- AWS Trusted Advisor: A service that gives general best-practice checks, including cost optimisation recommendations like underutilised instances.
- Auto Scaling: Not directly rightsizing, but the exam loves questions where you must choose between rightsizing a single instance and adding more instances via Auto Scaling.

Common exam traps:

- Trap 1: The exam gives you a scenario with high CPU utilisation and asks for the solution. Beginners often think the answer is always to resize to a larger instance. But the correct answer might be to use Auto Scaling to add more instances (horizontal scaling) rather than making one instance bigger (vertical scaling). The exam rewards understanding when to scale out versus scale up.
- Trap 2: You are asked to identify the best instance type for a workload. The exam will list multiple instance families. If the workload is memory-intensive (like a large in-memory database), the correct family is the R series (memory-optimised). If it is CPU-intensive (like video encoding), the C series (compute-optimised). If it is a web server with variable traffic, the T series (burstable) is often the correct choice because T instances can burst to high CPU for short periods using CPU credits.\- Trap 3: The exam tests whether you know that CloudWatch does not track memory utilisation by default. You must install the CloudWatch Agent on the instance to send memory metrics. If a question says 'you see memory usage in CloudWatch', it implies the agent is already installed—but many beginners assume memory metrics are automatic.\- Trap 4: Questions about Spot Instances often include a distractor like 'Spot Instances are cheaper and always available'—but Spot Instances can be terminated by AWS with a two-minute warning. The exam expects you to know that Spot Instances are good for fault-tolerant, stateless, or interruptible workloads, not for critical, stateful applications.

Key definitions you must memorise:

- Burstable performance: T2 and T3 instances can burst to high CPU performance for a limited time using CPU credits. When credits are exhausted, performance is throttled back to baseline. This is cost-effective for workloads that spike only occasionally.\- CPU credits: One credit equals one minute of using one virtual CPU at 100% utilisation. T instances earn credits when idle and spend them when busy.\- Baseline utilisation: The consistent performance level a burstable instance can maintain indefinitely without credits. For a t3.medium, baseline is 20% of one virtual CPU.\- Vertical scaling: Increasing the size (resources) of an existing instance—for example, changing from t3.medium to t3.large.\- Horizontal scaling: Adding more instances to distribute the load—for example, going from one web server to five web servers behind a load balancer.

Finally, memorise the exact phrasing the exam uses: 'Which AWS service provides rightsizing recommendations?' Answer: AWS Compute Optimiser. 'Which metric indicates an instance is under-provisioned?' Answer: CPUUtilisation consistently near 100% or high memory usage. 'Which action should you take to reduce costs for a low-utilisation instance?' Answer: Rightsize to a smaller instance type.

## Step by step

1. **Collect Baseline Metrics** — Use CloudWatch to gather at least 2 weeks of metrics (CPUUtilization, MemoryUtilization if the CloudWatch Agent is installed, DiskReadOps, DiskWriteOps, NetworkIn, NetworkOut) for each EC2 instance. This gives you a clear picture of current usage patterns and helps identify under- or over-utilised resources.
2. **Analyse the Bottleneck** — Look at the metrics to determine which resource is the limiting factor. If CPU is consistently near 100% while memory is at 30%, the bottleneck is CPU. If memory is at 90% while CPU is low, memory is the issue. This step is critical because the wrong fix (e.g., adding more RAM when CPU is the problem) will waste time and money.
3. **Use AWS Compute Optimiser for Recommendations** — Open the Compute Optimiser console and view the recommendations for EC2 instances. It will suggest specific instance types to switch to, along with estimated monthly savings. It considers both performance requirements and cost. Accept recommendations one at a time, especially for production instances, to avoid sudden performance degradation.
4. **Apply Rightsizing or Tuning Changes** — If the recommendation is a different instance type, stop the instance, change the instance type in the EC2 console, and start it again. If the recommendation is performance tuning (e.g., enabling caching or adjusting kernel parameters), implement the change on the running instance. Always test the change in a staging environment first if possible.
5. **Monitor Post-Change Performance** — After applying changes, continue monitoring CloudWatch metrics for at least 48 hours to ensure the new configuration handles the load correctly. Look for improvements in response time, reduced bottleneck metrics, and stable or lower costs. Adjust further if needed.
6. **Set Up Automatic Monitoring and Alerts** — Configure CloudWatch alarms for key metrics (e.g., CPU > 80% for 10 minutes) to trigger SNS notifications or automated actions like Auto Scaling. This ensures you are alerted quickly if performance degrades again, allowing proactive tuning rather than reactive firefighting.

## Comparisons

### Vertical Scaling (Rightsizing) vs Horizontal Scaling (Auto Scaling)

**Vertical Scaling (Rightsizing):**
- Changes the size of a single instance (e.g., from t3.medium to t3.large).
- Requires stopping the instance to make the change.
- Better for stateful applications that are difficult to distribute across multiple servers.

**Horizontal Scaling (Auto Scaling):**
- Adds or removes multiple instances of the same size.
- Can happen automatically without downtime (new instances start in parallel).
- Better for stateless web applications that can handle requests from any server.

### On-Demand Instances vs Reserved Instances / Savings Plans

**On-Demand Instances:**
- Pay per hour or per second with no upfront commitment.
- Highest per-unit cost but maximum flexibility to stop or change anytime.
- Ideal for unpredictable or short-term workloads.

**Reserved Instances / Savings Plans:**
- Commit to 1 or 3 years for a significant discount (up to 72%).
- Require upfront payment or monthly commitment; charges apply even if you do not use the instance.
- Ideal for steady-state, predictable workloads like production databases.

### Performance Tuning vs Rightsizing

**Performance Tuning:**
- Adjusts software configuration, caches, or code within the existing instance.
- Does not require stopping or changing the instance type.
- Often free (no additional AWS charges) but requires engineering effort.

**Rightsizing:**
- Changes the instance type itself to a different size or family.
- Requires stopping the instance, incurring potential downtime.
- Directly changes the AWS cost since you pay for the new instance type's pricing.

### Burstable Instances (T Series) vs Dedicated Instances (C, M, R Series)

**Burstable Instances (T Series):**
- Can burst to high CPU for limited periods using CPU credits.
- Cost-effective for workloads with sporadic spikes.
- Throttled to baseline performance when credits run out.

**Dedicated Instances (C, M, R Series):**
- Provide consistent, full CPU performance at all times.
- More expensive than burstable instances.
- Better for workloads with sustained high CPU usage, like video encoding or financial modelling.

## Diagram

_This flowchart shows the decision process for performance tuning and rightsizing: start with CloudWatch monitoring, identify the bottleneck, then decide whether to rightsize the instance or optimise performance through tuning._

```mermaid
flowchart TD
    A[Monitor Metrics with CloudWatch] --> B{Identify Bottleneck?
CPU% high? Memory% high?
Disk I/O? Network?}
    B -->|CPU is bottleneck| C[Consider Rightsizing to
larger instance type]
    B -->|Memory is bottleneck| D[Consider Memory-optimised
instance family (R series)]
    B -->|Disk I/O is bottleneck| E[Optimise storage: EBS gp3,
provisioned IOPS]
    B -->|Network is bottleneck| F[Consider enhanced networking
or larger instance]
    C --> G[Use AWS Compute Optimiser
for recommendations]
    D --> G
    E --> H[Apply performance tuning:
disk caching, query optimisation]
    F --> G
    G --> I[Apply rightsizing:
stop instance, change type,
start instance]
    I --> J[Monitor post-change metrics
with CloudWatch alarms]
```

## Common misconceptions

- **Misconception:** Rightsizing and performance tuning are the same thing. **Reality:** Rightsizing means changing the resource allocation (like instance type) to match the workload, while performance tuning means adjusting settings within an existing instance (like software configuration) to improve efficiency. (The terms sound similar, and many beginners lump them together because both aim to improve performance and reduce cost.)
- **Misconception:** More CPU is always better—if an application is slow, upgrade to a larger instance. **Reality:** The slowdown could be caused by high memory usage, disk I/O bottlenecks, or network limits. Upgrading CPU alone might waste money without fixing the actual problem. Use CloudWatch to identify the real bottleneck first. (In daily life, if a device is slow, people often assume it needs a faster processor. In the cloud, the bottleneck is often elsewhere.)
- **Misconception:** CloudWatch automatically tracks memory usage for every EC2 instance. **Reality:** CloudWatch does not track memory usage by default. You must install the CloudWatch Agent and configure it to send memory metrics. Memory is a guest-level metric, not hypervisor-level. (Many beginners assume that since CloudWatch tracks CPU automatically, it also tracks memory.)
- **Misconception:** Auto Scaling and rightsizing are always used together in every solution. **Reality:** Auto Scaling adjusts the number of instances, while rightsizing adjusts the size of each instance. They address different problems and can be used separately. A perfectly rightsized fleet may still need Auto Scaling to handle variable traffic. (The exam often presents scenarios where you must pick one approach over the other, and beginners incorrectly assume both are always required.)
- **Misconception:** Spot Instances are a good choice for any workload because they are cheap. **Reality:** Spot Instances can be interrupted by AWS with short notice. They are suitable only for workloads that are fault-tolerant, stateless, or can be restarted from a checkpoint. Critical production databases or stateful web servers should use On-Demand or Reserved Instances. (The low price is tempting, and beginners overlook the interruption risk because it is not intuitive that a cloud server could be taken away suddenly.)
- **Misconception:** If CPU utilisation is low, the instance is definitely rightsized and costs are optimised. **Reality:** Low CPU might mean the instance is oversized, but it could also mean the application is idle. However, low utilisation could still be acceptable if the instance is needed for other reasons (e.g., a web server that handles infrequent but critical requests). The key is to consider other metrics like memory, disk I/O, and network, as well as business requirements. (Beginners often fixate on CPU utilisation alone as the sole indicator of rightsizing, ignoring the full context.)

## Key takeaways

- Performance tuning optimises the configuration of an existing EC2 instance without changing its size, while rightsizing changes the instance type to better match the workload.
- CloudWatch tracks basic metrics like CPU utilisation automatically, but memory metrics require installing the CloudWatch Agent.
- AWS Compute Optimiser provides machine learning-based rightsizing recommendations after analysing at least 30 hours of historical data.
- Burstable T2 and T3 instances are cost-effective for workloads with sporadic spikes because they earn CPU credits when idle and spend them during bursts.
- Auto Scaling handles horizontal scaling (adding/removing instances) to manage variable traffic, whereas rightsizing addresses vertical scaling (resizing individual instances).
- Spot Instances can save up to 90% but are suitable only for fault-tolerant, stateless, or interruptible workloads due to potential termination with a two-minute warning.
- Always identify the specific bottleneck (CPU, memory, disk I/O, or network) using CloudWatch metrics before deciding whether to rightsize or apply performance tuning.
- Reserved Instances and Savings Plans offer significant discounts for steady-state workloads, but they require you to commit to a one- or three-year term.

## FAQ

**What is the difference between rightsizing and scaling?**

Rightsizing means changing the size of an existing instance (e.g., from t3.medium to t3.large) to match the workload, while scaling means adding or removing instances (horizontal scaling) or increasing/decreasing resources of a single instance (vertical scaling). Rightsizing is a one-time adjustment; scaling is dynamic.

**Can I rightsize a running EC2 instance without stopping it?**

No, you must stop the EC2 instance to change its instance type. Stopping the instance changes its public IP address unless you have an Elastic IP attached. Plan maintenance windows to avoid disrupting users.

**Does CloudWatch automatically track memory usage on EC2?**

No. CloudWatch tracks hypervisor-level metrics like CPU utilisation automatically, but memory is a guest-level metric. You must install the CloudWatch Agent on the EC2 instance and configure it to send memory metrics to CloudWatch.

**How long does AWS Compute Optimiser need to generate recommendations?**

Compute Optimiser requires a minimum of 30 hours of historical usage data before it can make recommendations. The more data you have (weeks or months), the more accurate the recommendations become.

**What are CPU credits on burstable instances?**

CPU credits are a system that allows T2 and T3 instances to burst beyond their baseline performance for limited periods. One credit equals one minute of one virtual CPU at 100% utilisation. Instances earn credits when they are idle and spend them when they are busy. When credits run out, performance is throttled to the baseline.

**When should I use Spot Instances instead of On-Demand?**

Use Spot Instances for workloads that can tolerate interruptions, such as batch processing, data analytics, testing, and stateless web servers. Avoid Spot Instances for critical production databases, stateful applications, or any workload that cannot handle abrupt termination.

**How do Auto Scaling and rightsizing work together?**

Rightsizing ensures each individual instance is the appropriate size for its workload. Auto Scaling then adjusts the number of those instances based on real-time demand. Together, they optimise both cost and performance by ensuring neither too many nor too few, nor too large nor too small, instances are running.

## Check your understanding

1. **What is the first step you should take when you suspect an EC2 instance is underperforming?**

   Answer: Check CloudWatch metrics (CPUUtilization, MemoryUtilization, Disk I/O, Network) to identify the specific bottleneck before making any changes.

2. **Which AWS service provides automated rightsizing recommendations for EC2 instances?**

   Answer: AWS Compute Optimiser provides machine learning-based recommendations for instance type changes based on historical usage.

3. **What happens to a T3 burstable instance when it runs out of CPU credits?**

   Answer: The instance is throttled to its baseline performance level, meaning it can no longer burst to higher CPU utilisation until it earns more credits by being idle.

4. **Why can CloudWatch not show memory utilisation by default on an EC2 instance?**

   Answer: Because memory is a guest-level metric—the hypervisor does not have direct visibility into the instance's memory usage. You must install the CloudWatch Agent to send memory metrics.

5. **When would you choose a Spot Instance over an On-Demand Instance?**

   Answer: When the workload is fault-tolerant, stateless, or can be interrupted (e.g., batch processing, data analysis, or test environments), because Spot Instances offer significant cost savings but can be terminated by AWS with short notice.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-sysops-associate/performance-tuning-and-rightsizing