# Burstable performance instances
Many general purpose workloads are on average not busy, and do not require a high level of sustained CPU performance. The following graph illustrates the CPU utilization for many common workloads that customers run in the AWS Cloud today.
![\[Many common workloads look like this: the average CPU utilization is at or below the baseline, with some spikes above the baseline.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/CPU-common-workloads.png)
These low-to-moderate CPU utilization workloads lead to wastage of CPU cycles and, as a result, you pay for more than you use. To overcome this, you can leverage the low-cost burstable general purpose instances, which are the T instances.
The T instance family provides a baseline CPU performance with the ability to burst above the baseline at any time for as long as required. The baseline CPU is defined to meet the needs of the majority of general purpose workloads, including large-scale micro-services, web servers, small and medium databases, data logging, code repositories, virtual desktops, development and test environments, and business-critical applications. The T instances offer a balance of compute, memory, and network resources, and provide you with the most cost-effective way to run a broad spectrum of general purpose applications that have a low-to-moderate CPU usage. They can save you up to 15% in costs when compared to M instances, and can lead to even more cost savings with smaller, more economical instance sizes, offering as low as 2 vCPUs and 0.5 GiB of memory. The smaller T instance sizes, such as nano, micro, small, and medium, are well suited for workloads that need a small amount of memory and do not expect high CPU usage.
**Note**
This topic describes burstable CPU. For information about burstable network performance, see [Amazon EC2 instance network bandwidth](ec2-instance-network-bandwidth.md).
## EC2 burstable instance types
The EC2 burstable instances consist of T4g, T3a, and T3 instance types, and the previous generation T2 instance types.
The T4g instance types are the latest generation of burstable instances. They provide the best price for performance, and provide you with the lowest cost of all the EC2 instance types. The T4g instance types are powered by Arm-based [AWS Graviton2](https://aws.amazon.com/ec2/graviton/) processors with extensive ecosystem support from operating systems vendors, independent software vendors, and popular AWS services and applications.
The following table summarizes the key differences between the burstable instance types.
****
| Type | Description | Processor family |
| --- | --- | --- |
| Latest generation |
| T4g | Lowest cost EC2 instance type with up to 40% higher price/performance and 20% lower costs vs T3 | AWS Graviton2 processors with Arm Neoverse N1 cores |
| T3a | Lowest cost x86-based instances with 10% lower costs vs T3 instances | AMD 1st gen EPYC processors |
| T3 | Best peak price/performance for x86 workloads with up to 30% lower price/performance vs previous generation T2 instances | Intel Xeon Scalable (Skylake, Cascade Lake processors) |
| Previous generation |
| T2 | Previous generation burstable instances | Intel Xeon processors |
For information about instance pricing and additional specifications, see [Amazon EC2 Pricing](https://aws.amazon.com/ec2/pricing/) and [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/). For information about burstable network performance, see [Amazon EC2 instance network bandwidth](ec2-instance-network-bandwidth.md).
If your created your AWS account before July 15, 2025 and it's less than 12 months old, you can use a `t2.micro` instance for free (or a `t3.micro` instance in Regions where `t2.micro` is unavailable) within certain usage limits. If you created your AWS account on or after July 15, 2025, you can use `t3.micro`, `t3.small`, `t4g.micro`, `t4g.small` instance types for 6 months or until your credits are used up. For more information, see [AWS Free Tier](https://aws.amazon.com/free/).
**Supported purchasing options for T instances**
+ On-Demand Instances
+ Reserved Instances
+ Dedicated Instances (T3 only)
+ Dedicated Hosts (T3 only, in `standard` mode only)
+ Spot Instances
For more information, see [Amazon EC2 billing and purchasing options](instance-purchasing-options.md).
**Topics**
+ [EC2 burstable instance types](#burstable-instance-types)
+ [Best practices](#burstable-performance-instances-best-practices)
+ [Key concepts for burstable performance instances](burstable-credits-baseline-concepts.md)
+ [Unlimited mode for burstable performance instances](burstable-performance-instances-unlimited-mode.md)
+ [Standard mode for burstable performance instances](burstable-performance-instances-standard-mode.md)
+ [Configure burstable performance instances](burstable-performance-instances-how-to.md)
+ [Monitor CPU credits for burstable instances](burstable-performance-instances-monitoring-cpu-credits.md)
## Best practices
Follow these best practices to get the maximum benefit from burstable performance instances.
+ Ensure that the instance size you choose passes the minimum memory requirements of your operating system and applications. Operating systems with graphical user interfaces that consume significant memory and CPU resources (for example, Windows) might require a `t3.micro` or larger instance size for many use cases. As the memory and CPU requirements of your workload grow over time, you have the flexibility with the T instances to scale to larger instance sizes of the same instance type, or to select another instance type.
+ Enable [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/getting-started/) for your account and review the Compute Optimizer recommendations for your workload. Compute Optimizer can help assess whether instances should be upsized to improve performance or downsized for cost savings. Compute Optimizer may also recommend a different instance type based on your scenario. For more information, see [Viewing EC2 instance recommendations](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ec2-recommendations.html) in the *AWS Compute Optimizer User Guide*.
# Key concepts for burstable performance instances
Traditional Amazon EC2 instance types provide fixed CPU resources, while burstable performance instances provide a baseline level of CPU utilization with the ability to burst CPU utilization above the baseline level. This ensures that you pay only for baseline CPU plus any additional burst CPU usage resulting in lower compute costs. The baseline utilization and ability to burst are governed by CPU credits. Burstable performance instances are the only instance types that use credits for CPU usage.
Each burstable performance instance continuously earns credits when it stays below the CPU baseline, and continuously spends credits when it bursts above the baseline. The amount of credits earned or spent depends on the CPU utilization of the instance:
+ If the CPU utilization is below baseline, then credits earned are greater than credits spent.
+ If the CPU utilization is equal to baseline, then credits earned are equal to credits spent.
+ If the CPU utilization is higher than baseline, then credits spent are higher than credits earned.
When the credits earned are greater than credits spent, then the difference is called accrued credits, which can be used later to burst above baseline CPU utilization. Similarly, when the credits spent are more than credits earned, then the instance behavior depends on the credit configuration mode—Standard mode or Unlimited mode.
In Standard mode, when credits spent are more than credits earned, the instance uses the accrued credits to burst above baseline CPU utilization. If there are no accrued credits remaining, then the instance gradually comes down to baseline CPU utilization and cannot burst above baseline until it accrues more credits.
In Unlimited mode, if the instance bursts above baseline CPU utilization, then the instance first uses the accrued credits to burst. If there are no accrued credits remaining, then the instance spends surplus credits to burst. When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-hour.
**Contents**
+ [Key concepts and definitions](#key-concepts)
+ [Earn CPU credits](#earning-CPU-credits)
+ [CPU credit earn rate](#CPU-credit-earn-rate)
+ [CPU credit accrual limit](#CPU-credit-accrual-limit)
+ [Accrued CPU credits life span](#accrued-CPU-credits-life-span)
+ [Baseline utilization](#baseline_performance)
## Key concepts and definitions
The following key concepts and definitions are applicable to burstable performance instances.
**CPU utilization**
CPU utilization is the percentage of allocated EC2 compute units that are currently in use on the instance. This metric measures the percentage of allocated CPU cycles that are being utilized on an instance. The CPU Utilization CloudWatch metric shows CPU usage per instance and not CPU usage per core. The baseline CPU specification of an instance is also based on the CPU usage per instance. To measure CPU utilization using the AWS Management Console or the AWS CLI, see [Get statistics for a specific instance](US_SingleMetricPerInstance.md).
**CPU credit**
A unit of vCPU-time.
Examples:
1 CPU credit = 1 vCPU \$1 100% utilization \$1 1 minute.
1 CPU credit = 1 vCPU \$1 50% utilization \$1 2 minutes
1 CPU credit = 2 vCPU \$1 25% utilization \$1 2 minutes
**Baseline utilization**
The baseline utilization is the level at which the CPU can be utilized for a net credit balance of zero, when the number of CPU credits being earned matches the number of CPU credits being used. Baseline utilization is also known as the baseline. Baseline utilization is expressed as a percentage of vCPU utilization, which is calculated as follows: Baseline utilization % = (number of credits earned/number of vCPUs)/60 minutes.
For the baseline utilization of each burstable performance instance type, see the [credit table](#burstable-performance-instances-credit-table).
**Earned credits**
Credits earned continuously by an instance when it is running.
Number of credits earned per hour = % baseline utilization \$1 number of vCPUs \$1 60 minutes
Example:
A t3.nano with 2 vCPUs and a baseline utilization of 5% earns 6 credits per hour, calculated as follows:
2 vCPUs \$1 5% baseline \$1 60 minutes = 6 credits per hour
**Spent or used credits**
Credits used continuously by an instance when it is running.
CPU credits spent per minute = Number of vCPUs \$1 CPU utilization \$1 1 minute
**Accrued credits**
Unspent CPU credits when an instance uses fewer credits than is required for baseline utilization. In other words, accrued credits = (Earned credits – Used credits) below baseline.
Example:
If a t3.nano is running at 2% CPU utilization, which is below its baseline of 5% for an hour, the accrued credits is calculated as follows:
Accrued CPU credits = (Earned credits per hour – Used credits per hour) = 6 – 2 vCPUs \$1 2% CPU utilization \$1 60 minutes = 6 – 2.4 = 3.6 accrued credits per hour
**Credit accrual limit**
Depends on the instance size but in general is equal to the number of maximum credits earned in 24 hours.
Example:
For t3.nano, the credit accrual limit = 24 \$1 6 = 144 credits
**Launch credits**
Only applicable for T2 instances configured for Standard mode. Launch credits are a limited number of CPU credits that are allocated to a new T2 instance so that, when launched in Standard mode, it can burst above the baseline.
**Surplus credits**
Credits that are spent by an instance after it depletes its accrued credit balance. The surplus credits are designed for burstable instances to sustain high performance for an extended period of time, and are only used in Unlimited mode. The surplus credits balance is used to determine how many credits were used by the instance for bursting in Unlimited mode.
**Standard mode**
Credit configuration mode, which allows an instance to burst above the baseline by spending credits it has accrued in its credit balance.
**Unlimited mode**
Credit configuration mode, which allows an instance to burst above the baseline by sustaining high CPU utilization for any period of time whenever required. The hourly instance price automatically covers all CPU usage spikes if the average CPU utilization of the instance is at or below the baseline over a rolling 24-hour period or the instance lifetime, whichever is shorter. If the instance runs at higher CPU utilization for a prolonged period, it can do so for a [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-hour.
The following table summarizes the key credit differences between the burstable instance types.
****
| Type | Type of CPU credits supported | Credit configuration modes | Accrued CPU credits lifespan between instance starts and stops |
| --- | --- | --- | --- |
| Latest generation |
| T4g | Earned credits, Accrued credits, Spent credits, Surplus credits (Unlimited mode only) | Standard, Unlimited (default) | 7 days (credits persist for 7 days after an instance stops) |
| T3a | Earned credits, Accrued credits, Spent credits, Surplus credits (Unlimited mode only) | Standard, Unlimited (default) | 7 days (credits persist for 7 days after an instance stops) |
| T3 | Earned credits, Accrued credits, Spent credits, Surplus credits (Unlimited mode only) | Standard, Unlimited (default) | 7 days (credits persist for 7 days after an instance stops) |
| Previous generation |
| T2 | Earned credits, Accrued credits, Spent credits, Launch credits (Standard mode only), Surplus credits (Unlimited mode only) | Standard (default), Unlimited | 0 days (credits are lost when an instance stops) |
**Note**
Unlimited mode is not supported for T3 instances that are launched on a Dedicated Host.
## Earn CPU credits
Each burstable performance instance continuously earns (at a millisecond-level resolution) a set rate of CPU credits per hour, depending on the instance size. The accounting process for whether credits are accrued or spent also happens at a millisecond-level resolution, so you don't have to worry about overspending CPU credits; a short burst of CPU uses a small fraction of a CPU credit.
If a burstable performance instance uses fewer CPU resources than is required for baseline utilization (such as when it is idle), the unspent CPU credits are accrued in the CPU credit balance. If a burstable performance instance needs to burst above the baseline utilization level, it spends the accrued credits. The more credits that a burstable performance instance has accrued, the more time it can burst beyond its baseline when more CPU utilization is needed.
The following table lists the burstable performance instance types, the rate at which CPU credits are earned per hour, the maximum number of earned CPU credits that an instance can accrue, the number of vCPUs per instance, and the baseline utilization as a percentage of a full core (using a single vCPU).
| Instance type | CPU credits earned per hour | Maximum earned credits that can be accrued\$1 | vCPUs\$1\$1\$1 | Baseline utilization per vCPU |
| --- | --- | --- | --- | --- |
| **T2** | | | | |
| t2.nano | 3 | 72 | 1 | 5% |
| t2.micro | 6 | 144 | 1 | 10% |
| t2.small | 12 | 288 | 1 | 20% |
| t2.medium | 24 | 576 | 2 | 20%\$1\$1 |
| t2.large | 36 | 864 | 2 | 30%\$1\$1 |
| t2.xlarge | 54 | 1296 | 4 | 22.5%\$1\$1 |
| t2.2xlarge | 81.6 | 1958.4 | 8 | 17%\$1\$1 |
| **T3** | | | | |
| t3.nano | 6 | 144 | 2 | 5%\$1\$1 |
| t3.micro | 12 | 288 | 2 | 10%\$1\$1 |
| t3.small | 24 | 576 | 2 | 20%\$1\$1 |
| t3.medium | 24 | 576 | 2 | 20%\$1\$1 |
| t3.large | 36 | 864 | 2 | 30%\$1\$1 |
| t3.xlarge | 96 | 2304 | 4 | 40%\$1\$1 |
| t3.2xlarge | 192 | 4608 | 8 | 40%\$1\$1 |
| **T3a** | | | | |
| t3a.nano | 6 | 144 | 2 | 5%\$1\$1 |
| t3a.micro | 12 | 288 | 2 | 10%\$1\$1 |
| t3a.small | 24 | 576 | 2 | 20%\$1\$1 |
| t3a.medium | 24 | 576 | 2 | 20%\$1\$1 |
| t3a.large | 36 | 864 | 2 | 30%\$1\$1 |
| t3a.xlarge | 96 | 2304 | 4 | 40%\$1\$1 |
| t3a.2xlarge | 192 | 4608 | 8 | 40%\$1\$1 |
| **T4g** | | | | |
| t4g.nano | 6 | 144 | 2 | 5%\$1\$1 |
| t4g.micro | 12 | 288 | 2 | 10%\$1\$1 |
| t4g.small | 24 | 576 | 2 | 20%\$1\$1 |
| t4g.medium | 24 | 576 | 2 | 20%\$1\$1 |
| t4g.large | 36 | 864 | 2 | 30%\$1\$1 |
| t4g.xlarge | 96 | 2304 | 4 | 40%\$1\$1 |
| t4g.2xlarge | 192 | 4608 | 8 | 40%\$1\$1 |
| |
| --- |
| \$1 The number of credits that can be accrued is equivalent to the number of credits that can be earned in a 24-hour period. |
| \$1\$1 The percentage baseline utilization in the table is per vCPU. In CloudWatch, CPU utilization is shown per vCPU. For example, the CPU utilization for a `t3.large` instance operating at the baseline level is shown as 30% in CloudWatch CPU metrics. For information about how to calculate the baseline utilization, see [Baseline utilization](#baseline_performance). |
| \$1\$1\$1 Each vCPU is a thread of either an Intel Xeon core or an AMD EPYC core, except for T2 and T4g instances. |
## CPU credit earn rate
The number of CPU credits earned per hour is determined by the instance size. For example, a `t3.nano` earns six credits per hour, while a `t3.small` earns 24 credits per hour. The preceding table lists the credit earn rate for all instances.
## CPU credit accrual limit
While earned credits never expire on a running instance, there is a limit to the number of earned credits that an instance can accrue. The limit is determined by the CPU credit balance limit. After the limit is reached, any new credits that are earned are discarded, as indicated by the following image. The full bucket indicates the CPU credit balance limit, and the spillover indicates the newly earned credits that exceed the limit.
![\[New credits earned are discarded once the limit is exceeded.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-t3-bucket.png)
The CPU credit balance limit differs for each instance size. For example, a `t3.micro` instance can accrue a maximum of 288 earned CPU credits in the CPU credit balance. The preceding table lists the maximum number of earned credits that each instance can accrue.
T2 Standard instances also earn launch credits. Launch credits do not count towards the CPU credit balance limit. If a T2 instance has not spent its launch credits, and remains idle over a 24-hour period while accruing earned credits, its CPU credit balance appears as over the limit. For more information, see [Launch credits](burstable-performance-instances-standard-mode-concepts.md#launch-credits).
T4g, T3a, and T3 instances do not earn launch credits. These instances launch as `unlimited` by default, and therefore can burst immediately upon start without any launch credits. T3 instances launched on a Dedicated Host launch as `standard` by default; `unlimited` mode is not supported for T3 instances on a Dedicated Host.
## Accrued CPU credits life span
CPU credits on a running instance do not expire.
For T2, the CPU credit balance does not persist between instance stops and starts. If you stop a T2 instance, the instance loses all its accrued credits.
For T4g, T3a, and T3, the CPU credit balance persists for seven days after an instance stops and the credits are lost thereafter. If you start the instance within seven days, no credits are lost.
For more information, see `CPUCreditBalance` in the [CloudWatch metrics table](burstable-performance-instances-monitoring-cpu-credits.md#burstable-performance-instances-CW-metrics-table).
## Baseline utilization
The *baseline utilization* is the level at which the CPU can be utilized for a net credit balance of zero, when the number of CPU credits being earned matches the number of CPU credits being used. Baseline utilization is also known as *the baseline*.
Baseline utilization is expressed as a percentage of vCPU utilization, which is calculated as follows:
`(number of credits earned/number of vCPUs)/60 minutes = % baseline utilization`
For example, a `t3.nano` instance, with 2 vCPUs, earns 6 credits per hour, resulting in a baseline utilization of 5% , which is calculated as follows:
`(6 credits earned/2 vCPUs)/60 minutes = 5% baseline utilization`
A `t3.large` instance, with 2 vCPUs, earns 36 credits per hour, resulting in a baseline utilization of 30% (`(36/2)/60`).
The following graph provides an example of a `t3.large` with an average CPU utilization below the baseline.
![\[A graph of a t3.large instance with an average CPU utilization below baseline.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/baseline-utilization.png)
# Unlimited mode for burstable performance instances
A burstable performance instance configured as `unlimited` can sustain high CPU utilization for any period of time whenever required. The hourly instance price automatically covers all CPU usage spikes if the average CPU utilization of the instance is at or below the baseline over a rolling 24-hour period or the instance lifetime, whichever is shorter.
For the vast majority of general-purpose workloads, instances configured as `unlimited` provide ample performance without any additional charges. If the instance runs at higher CPU utilization for a prolonged period, it can do so for a flat additional rate per vCPU-hour. For information about pricing, see [Amazon EC2 pricing](https://aws.amazon.com/ec2/pricing/) and [T2/T3/T4 Unlimited Mode Pricing](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing).
If your created your AWS account before July 15, 2025 and you use a `t2.micro` or `t3.micro` instance under the [AWS Free Tier](https://aws.amazon.com/free/) offer and use it in `unlimited` mode, charges might apply if your average utilization over a rolling 24-hour period exceeds the [baseline utilization](burstable-credits-baseline-concepts.md#baseline_performance) of the instance.
T4g, T3a, and T3 instances launch as `unlimited` by default (unless you [change the default](burstable-performance-instances-how-to.md#burstable-performance-instance-set-default-credit-specification-for-account)). If the average CPU usage over a 24-hour period exceeds the baseline, you incur charges for surplus credits. If you launch Spot Instances as `unlimited` and plan to use them immediately and for a short duration, with no idle time for accruing CPU credits, you incur charges for surplus credits. We recommend that you launch your Spot Instances in [standard](burstable-performance-instances-standard-mode.md) mode to avoid paying higher costs. For more information, see [Surplus credits can incur charges](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-surplus-credits) and [Launch burstable performance instances](how-spot-instances-work.md#burstable-spot-instances).
**Note**
T3 instances launched on a Dedicated Host launch as `standard` by default; `unlimited` mode is not supported for T3 instances on a Dedicated Host.
**Contents**
+ [Unlimited mode concepts for burstable instances](burstable-performance-instances-unlimited-mode-concepts.md)
+ [How Unlimited burstable performance instances work](burstable-performance-instances-unlimited-mode-concepts.md#how-burstable-performance-instances-unlimited-works)
+ [When to use unlimited mode versus fixed CPU](burstable-performance-instances-unlimited-mode-concepts.md#when-to-use-unlimited-mode)
+ [Surplus credits can incur charges](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-surplus-credits)
+ [How much does unlimited burstable performance cost?](burstable-performance-instances-unlimited-mode-concepts.md#how-much-does-unlimited-burstable-performance-cost)
+ [No launch credits for T2 Unlimited instances](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-no-launch-credits)
+ [Enable unlimited mode](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-enabling)
+ [What happens to credits when switching between Unlimited and Standard](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-switching-and-credits)
+ [Monitor credit usage](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-monitoring-credit-usage)
+ [Unlimited mode examples for burstable instances](unlimited-mode-examples.md)
+ [Example 1: Explain credit use with T3 Unlimited](unlimited-mode-examples.md#t3_unlimited_example)
+ [Example 2: Explain credit use with T2 Unlimited](unlimited-mode-examples.md#t2_unlimited_example)
# Unlimited mode concepts for burstable instances
The `unlimited` mode is a credit configuration option for burstable performance instances. It can be enabled or disabled at any time for a running or stopped instance. You can [set `unlimited` as the default credit option](burstable-performance-instances-how-to.md#burstable-performance-instance-set-default-credit-specification-for-account) at the account level per AWS Region, per burstable performance instance family, so that all new burstable performance instances in the account launch using the default credit option.
## How Unlimited burstable performance instances work
If a burstable performance instance configured as `unlimited` depletes its CPU credit balance, it can spend *surplus* credits to burst beyond the [baseline](burstable-credits-baseline-concepts.md#baseline_performance). When its CPU utilization falls below the baseline, it uses the CPU credits that it earns to pay down the surplus credits that it spent earlier. The ability to earn CPU credits to pay down surplus credits enables Amazon EC2 to average the CPU utilization of an instance over a 24-hour period. If the average CPU usage over a 24-hour period exceeds the baseline, the instance is billed for the additional usage at a [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-hour.
The following graph shows the CPU usage of a `t3.large`. The baseline CPU utilization for a `t3.large` is 30%. If the instance runs at 30% CPU utilization or less on average over a 24-hour period, there is no additional charge because the cost is already covered by the instance hourly price. However, if the instance runs at 40% CPU utilization on average over a 24-hour period, as shown in the graph, the instance is billed for the additional 10% CPU usage at a [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-hour.
![\[CPU billing usage of a t3.large instance.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t3-cpu-usage.png)
For more information about the baseline utilization per vCPU for each instance type and how many credits each instance type earns, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table).
## When to use unlimited mode versus fixed CPU
When determining whether you should use a burstable performance instance in `unlimited` mode, such as T3, or a fixed performance instance, such as M5, you need to determine the breakeven CPU usage. The breakeven CPU usage for a burstable performance instance is the point at which a burstable performance instance costs the same as a fixed performance instance. The breakeven CPU usage helps you determine the following:
+ If the average CPU usage over a 24-hour period is at or below the breakeven CPU usage, use a burstable performance instance in `unlimited` mode so that you can benefit from the lower price of a burstable performance instance while getting the same performance as a fixed performance instance.
+ If the average CPU usage over a 24-hour period is above the breakeven CPU usage, the burstable performance instance will cost more than the equivalently-sized fixed performance instance. If a T3 instance continuously bursts at 100% CPU, you end up paying approximately 1.5 times the price of an equivalently-sized M5 instance.
The following graph shows the breakeven CPU usage point where a `t3.large` costs the same as an `m5.large`. The breakeven CPU usage point for a `t3.large` is 42.5%. If the average CPU usage is at 42.5%, the cost of running the `t3.large` is the same as an `m5.large`, and is more expensive if the average CPU usage is above 42.5%. If the workload needs less than 42.5% average CPU usage, you can benefit from the lower price of the `t3.large` while getting the same performance as an `m5.large`.
![\[The breakeven CPU usage point for a t3.large instance is 42.5%.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/T3-unltd-when-to-use.png)
The following table shows how to calculate the breakeven CPU usage threshold so that you can determine when it's less expensive to use a burstable performance instance in `unlimited` mode or a fixed performance instance. The columns in the table are labeled A through K.
| Instance type | vCPUs | T3 price\$1/hour | M5 price\$1/hour | Price difference | T3 baseline utilization per vCPU (%) | Charge per vCPU hour for surplus credits | Charge per vCPU minute | Additional burst minutes available per vCPU | Additional CPU % available | Breakeven CPU % |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| A | B | C | D | E = D - C | F | G | H = G / 60 | I = E / H | J = (I / 60) / B | K = F \$1 J |
| t3.large | 2 | \$10.0835 | \$10.096 | \$10.0125 | 30% | \$10.05 | \$10.000833 | 15 | 12.5% | 42.5% |
| |
| --- |
| \$1 Price is based on us-east-1 and Linux OS. |
The table provides the following information:
+ Column A shows the instance type, `t3.large`.
+ Column B shows the number of vCPUs for the `t3.large`.
+ Column C shows the price of a `t3.large` per hour.
+ Column D shows the price of an `m5.large` per hour.
+ Column E shows the price difference between the `t3.large` and the `m5.large`.
+ Column F shows the baseline utilization per vCPU of the `t3.large`, which is 30%. At the baseline, the hourly cost of the instance covers the cost of the CPU usage.
+ Column G shows the [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-hour that an instance is charged if it bursts at 100% CPU after it has depleted its earned credits.
+ Column H shows the [flat additional rate](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) per vCPU-minute that an instance is charged if it bursts at 100% CPU after it has depleted its earned credits.
+ Column I shows the number of additional minutes that the `t3.large` can burst per hour at 100% CPU while paying the same price per hour as an `m5.large`.
+ Column J shows the additional CPU usage (in %) over baseline that the instance can burst while paying the same price per hour as an `m5.large`.
+ Column K shows the breakeven CPU usage (in %) that the `t3.large` can burst without paying more than the `m5.large`. Anything above this, and the `t3.large` costs more than the `m5.large`.
The following table shows the breakeven CPU usage (in %) for T3 instance types compared to the similarly-sized M5 instance types.
| T3 instance type | Breakeven CPU usage (in %) for T3 compared to M5 |
| --- | --- |
| t3.large | 42.5% |
| t3.xlarge | 52.5% |
| t3.2xlarge | 52.5% |
## Surplus credits can incur charges
If the average CPU utilization of an instance is at or below the baseline, the instance incurs no additional charges. Because an instance earns a [maximum number of credits](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table) in a 24-hour period (for example, a `t3.micro` instance can earn a maximum of 288 credits in a 24-hour period), it can spend surplus credits up to that maximum without being charged.
However, if CPU utilization stays above the baseline, the instance cannot earn enough credits to pay down the surplus credits that it has spent. The surplus credits that are not paid down are charged at a flat additional rate per vCPU-hour. For information about the rate, see [ T2/T3/T4g Unlimited Mode Pricing](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing).
Surplus credits that were spent earlier are charged when any of the following occurs:
+ The spent surplus credits exceed the [maximum number of credits](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table) the instance can earn in a 24-hour period. Spent surplus credits above the maximum are charged at the end of the hour.
+ The instance is stopped or terminated.
+ The instance is switched from `unlimited` to `standard`.
Spent surplus credits are tracked by the CloudWatch metric `CPUSurplusCreditBalance`. Surplus credits that are charged are tracked by the CloudWatch metric `CPUSurplusCreditsCharged`. For more information, see [Additional CloudWatch metrics for burstable performance instances](burstable-performance-instances-monitoring-cpu-credits.md#burstable-performance-instances-cw-metrics).
## How much does unlimited burstable performance cost?
If you use surplus credits and they're not paid down by earned credits (see [Surplus credits can incur charges](#unlimited-mode-surplus-credits)), you pay a flat additional rate per vCPU-hour for the surplus credits. The rate is listed in the [T2/T3/T4g Unlimited Mode Pricing](https://aws.amazon.com/ec2/pricing/on-demand/#T2.2FT3.2FT4g_Unlimited_Mode_Pricing) section on the *Amazon EC2 On-Demand Pricing* page.
## No launch credits for T2 Unlimited instances
T2 Standard instances receive [launch credits](burstable-performance-instances-standard-mode-concepts.md#launch-credits), but T2 Unlimited instances do not. A T2 Unlimited instance can burst beyond the baseline at any time with no additional charge, as long as its average CPU utilization is at or below the baseline over a rolling 24-hour window or its lifetime, whichever is shorter. As such, T2 Unlimited instances do not require launch credits to achieve high performance immediately after launch.
If a T2 instance is switched from `standard` to `unlimited`, any accrued launch credits are removed from the `CPUCreditBalance` before the remaining `CPUCreditBalance` is carried over.
T4g, T3a, and T3 instances never receive launch credits because they launch in Unlimited mode by default, and therefore can burst immediately upon start. The Unlimited mode credit configuration enables T4g, T3a, and T3 instances to use as much CPU as needed to burst beyond the baseline and for as long as needed.
## Enable unlimited mode
You can switch from `unlimited` to `standard`, and from `standard` to `unlimited`, at any time on a running or stopped instance. For more information, see [Configure the credit specification at launch](burstable-performance-instances-how-to.md#launch-burstable-performance-instances) and [Manage the credit specification of a burstable performance instance](burstable-performance-instances-how-to.md#modify-burstable-performance-instances).
You can set `unlimited` as the default credit option at the account level per AWS Region, per burstable performance instance family, so that all new burstable performance instances in the account launch using the default credit option. For more information, see [Manage the default credit specification for an account](burstable-performance-instances-how-to.md#burstable-performance-instance-set-default-credit-specification-for-account).
You can check whether your burstable performance instance is configured as `unlimited` or `standard` using the Amazon EC2 console or the AWS CLI. For more information, see [Configure burstable performance instances](burstable-performance-instances-how-to.md).
## What happens to credits when switching between Unlimited and Standard
`CPUCreditBalance` is a CloudWatch metric that tracks the number of credits accrued by an instance. `CPUSurplusCreditBalance` is a CloudWatch metric that tracks the number of surplus credits spent by an instance.
When you change an instance configured as `unlimited` to `standard`, the following occurs:
+ The `CPUCreditBalance` value remains unchanged and is carried over.
+ The `CPUSurplusCreditBalance` value is immediately charged.
When a `standard` instance is switched to `unlimited`, the following occurs:
+ The `CPUCreditBalance` value containing accrued earned credits is carried over.
+ For T2 Standard instances, any launch credits are removed from the `CPUCreditBalance` value, and the remaining `CPUCreditBalance` value containing accrued earned credits is carried over.
## Monitor credit usage
To see if your instance is spending more credits than the baseline provides, you can use CloudWatch metrics to track usage, and you can set up hourly alarms to be notified of credit usage. For more information, see [Monitor CPU credits for burstable instances](burstable-performance-instances-monitoring-cpu-credits.md).
# Unlimited mode examples for burstable instances
The following examples explain credit use for instances that are configured as `unlimited`.
**Topics**
+ [Example 1: Explain credit use with T3 Unlimited](#t3_unlimited_example)
+ [Example 2: Explain credit use with T2 Unlimited](#t2_unlimited_example)
## Example 1: Explain credit use with T3 Unlimited
In this example, you see the CPU utilization of a `t3.nano` instance launched as `unlimited`, and how it spends *earned* and *surplus* credits to sustain CPU utilization.
A `t3.nano` instance earns 144 CPU credits over a rolling 24-hour period, which it can redeem for 144 minutes of vCPU use. When it depletes its CPU credit balance (represented by the CloudWatch metric `CPUCreditBalance`), it can spend *surplus* CPU credits—that it has *not yet earned*—to burst for as long as it needs. Because a `t3.nano` instance earns a maximum of 144 credits in a 24-hour period, it can spend surplus credits up to that maximum without being charged immediately. If it spends more than 144 CPU credits, it is charged for the difference at the end of the hour.
The intent of the example, illustrated by the following graph, is to show how an instance can burst using surplus credits even after it depletes its `CPUCreditBalance`. The following workflow references the numbered points on the graph:
**P1** – At 0 hours on the graph, the instance is launched as `unlimited` and immediately begins to earn credits. The instance remains idle from the time it is launched—CPU utilization is 0%—and no credits are spent. All unspent credits are accrued in the credit balance. For the first 24 hours, `CPUCreditUsage` is at 0, and the `CPUCreditBalance` value reaches its maximum of 144.
**P2** – For the next 12 hours, CPU utilization is at 2.5%, which is below the 5% baseline. The instance earns more credits than it spends, but the `CPUCreditBalance` value cannot exceed its maximum of 144 credits.
**P3** – For the next 24 hours, CPU utilization is at 7% (above the baseline), which requires a spend of 57.6 credits. The instance spends more credits than it earns, and the `CPUCreditBalance` value reduces to 86.4 credits.
**P4** – For the next 12 hours, CPU utilization decreases to 2.5% (below the baseline), which requires a spend of 36 credits. In the same time, the instance earns 72 credits. The instance earns more credits than it spends, and the `CPUCreditBalance` value increases to 122 credits.
**P5** – For the next 5 hours, the instance bursts at 100% CPU utilization, and spends a total of 570 credits to sustain the burst. About an hour into this period, the instance depletes its entire `CPUCreditBalance` of 122 credits, and starts to spend surplus credits to sustain the high CPU utilization, totaling 448 surplus credits in this period (570-122=448). When the `CPUSurplusCreditBalance` value reaches 144 CPU credits (the maximum a `t3.nano` instance can earn in a 24-hour period), any surplus credits spent thereafter cannot be offset by earned credits. The surplus credits spent thereafter amounts to 304 credits (448-144=304), which results in a small additional charge at the end of the hour for 304 credits.
**P6** – For the next 13 hours, CPU utilization is at 5% (the baseline). The instance earns as many credits as it spends, with no excess to pay down the `CPUSurplusCreditBalance`. The `CPUSurplusCreditBalance` value remains at 144 credits.
**P7** – For the last 24 hours in this example, the instance is idle and CPU utilization is 0%. During this time, the instance earns 144 credits, which it uses to pay down the `CPUSurplusCreditBalance`.
![\[The t3 instance earned 144 credits after 24 hours.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t3_unlimited_graph.png)
## Example 2: Explain credit use with T2 Unlimited
In this example, you see the CPU utilization of a `t2.nano` instance launched as `unlimited`, and how it spends *earned* and *surplus* credits to sustain CPU utilization.
A `t2.nano` instance earns 72 CPU credits over a rolling 24-hour period, which it can redeem for 72 minutes of vCPU use. When it depletes its CPU credit balance (represented by the CloudWatch metric `CPUCreditBalance`), it can spend *surplus* CPU credits—that it has *not yet earned*—to burst for as long as it needs. Because a `t2.nano` instance earns a maximum of 72 credits in a 24-hour period, it can spend surplus credits up to that maximum without being charged immediately. If it spends more than 72 CPU credits, it is charged for the difference at the end of the hour.
The intent of the example, illustrated by the following graph, is to show how an instance can burst using surplus credits even after it depletes its `CPUCreditBalance`. You can assume that, at the start of the time line in the graph, the instance has an accrued credit balance equal to the maximum number of credits it can earn in 24 hours. The following workflow references the numbered points on the graph:
**1** – In the first 10 minutes, `CPUCreditUsage` is at 0, and the `CPUCreditBalance` value remains at its maximum of 72.
**2** – At 23:40, as CPU utilization increases, the instance spends CPU credits and the `CPUCreditBalance` value decreases.
**3** – At around 00:47, the instance depletes its entire `CPUCreditBalance`, and starts to spend surplus credits to sustain high CPU utilization.
**4** – Surplus credits are spent until 01:55, when the `CPUSurplusCreditBalance` value reaches 72 CPU credits. This is equal to the maximum a `t2.nano` instance can earn in a 24-hour period. Any surplus credits spent thereafter cannot be offset by earned credits within the 24-hour period, which results in a small additional charge at the end of the hour.
**5** – The instance continues to spend surplus credits until around 02:20. At this time, CPU utilization falls below the baseline, and the instance starts to earn credits at 3 credits per hour (or 0.25 credits every 5 minutes), which it uses to pay down the `CPUSurplusCreditBalance`. After the `CPUSurplusCreditBalance` value reduces to 0, the instance starts to accrue earned credits in its `CPUCreditBalance` at 0.25 credits every 5 minutes.
![\[Graphed CPU utilization of a t2.nano instance launched as unlimited.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2_unlimited_graph.png)
**Calculating the bill (Linux instance)**
Surplus credits cost \$10.05 per vCPU-hour. The instance spent approximately 25 surplus credits between 01:55 and 02:20, which is equivalent to 0.42 vCPU-hours. Additional charges for this instance are 0.42 vCPU-hours x \$10.05/vCPU-hour = \$10.021, rounded to \$10.02. Here is the month-end bill for this T2 Unlimited instance:
![\[Example bill for a T2 Unlimited instance.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2_unlimited_bill_linux.png)
**Calculating the bill (Windows instance)**
Surplus credits cost \$10.096 per vCPU-hour. The instance spent approximately 25 surplus credits between 01:55 and 02:20, which is equivalent to 0.42 vCPU-hours. Additional charges for this instance are 0.42 vCPU-hours x \$10.096/vCPU-hour = \$10.04032, rounded to \$10.04. Here is the month-end bill for this T2 Unlimited instance:
![\[Example bill for a T2 Unlimited instance.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2_unlimited_bill_windows.png)
You can set billing alerts to be notified every hour of any accruing charges, and take action if required.
# Standard mode for burstable performance instances
A burstable performance instance configured as `standard` is suited to workloads with an average CPU utilization that is consistently below the baseline CPU utilization of the instance. To burst above the baseline, the instance spends credits that it has accrued in its CPU credit balance. If the instance is running low on accrued credits, CPU utilization is gradually lowered to the baseline level, so that the instance does not experience a sharp performance drop-off when its accrued CPU credit balance is depleted. For more information, see [Key concepts for burstable performance instances](burstable-credits-baseline-concepts.md).
**Contents**
+ [Standard mode concepts for burstable instances](burstable-performance-instances-standard-mode-concepts.md)
+ [How standard burstable performance instances work](burstable-performance-instances-standard-mode-concepts.md#how-burstable-performance-instances-standard-works)
+ [Launch credits](burstable-performance-instances-standard-mode-concepts.md#launch-credits)
+ [Launch credit limits](burstable-performance-instances-standard-mode-concepts.md#launch-credit-limits)
+ [Differences between launch credits and earned credits](burstable-performance-instances-standard-mode-concepts.md#burstable-performance-instances-diff-launch-earned-credits)
+ [Standard mode examples for burstable instances](standard-mode-examples.md)
+ [Example 1: Explain credit use with T3 Standard](standard-mode-examples.md#t3_standard_example)
+ [Example 2: Explain credit use with T2 Standard](standard-mode-examples.md#t2-standard-example)
+ [Period 1: 1 – 24 hours](standard-mode-examples.md#period-1)
+ [Period 2: 25 – 36 hours](standard-mode-examples.md#period-2)
+ [Period 3: 37 – 61 hours](standard-mode-examples.md#period-3)
+ [Period 4: 62 – 72 hours](standard-mode-examples.md#period-4)
+ [Period 5: 73 – 75 hours](standard-mode-examples.md#period-5)
+ [Period 6: 76 – 90 hours](standard-mode-examples.md#period-6)
+ [Period 7: 91 – 96 hours](standard-mode-examples.md#period-7)
# Standard mode concepts for burstable instances
The `standard` mode is a configuration option for burstable performance instances. It can be enabled or disabled at any time for a running or stopped instance. You can [set `standard` as the default credit option](burstable-performance-instances-how-to.md#burstable-performance-instance-set-default-credit-specification-for-account) at the account level per AWS Region, per burstable performance instance family, so that all new burstable performance instances in the account launch using the default credit option.
## How standard burstable performance instances work
When a burstable performance instance configured as `standard` is in a running state, it continuously earns (at a millisecond-level resolution) a set rate of earned credits per hour. For T2 Standard, when the instance is stopped, it loses all its accrued credits, and its credit balance is reset to zero. When it is restarted, it receives a new set of launch credits, and begins to accrue earned credits. For T4g, T3a, and T3 Standard instances, the CPU credit balance persists for seven days after the instance stops and the credits are lost thereafter. If you start the instance within seven days, no credits are lost.
T2 Standard instances receive two types of [CPU credits](burstable-credits-baseline-concepts.md#key-concepts): *earned credits* and *launch credits*. When a T2 Standard instance is in a running state, it continuously earns (at a millisecond-level resolution) a set rate of earned credits per hour. At start, it has not yet earned credits for a good startup experience; therefore, to provide a good startup experience, it receives launch credits at start, which it spends first while it accrues earned credits.
T4g, T3a, and T3 instances do not receive launch credits because they support Unlimited mode. The Unlimited mode credit configuration enables T4g, T3a, and T3 instances to use as much CPU as needed to burst beyond baseline and for as long as needed.
## Launch credits
T2 Standard instances get 30 launch credits per vCPU at launch or start, and T1 Standard instances get 15 launch credits. For example, a `t2.micro` instance has one vCPU and gets 30 launch credits, while a `t2.xlarge` instance has four vCPUs and gets 120 launch credits. Launch credits are designed to provide a good startup experience to allow instances to burst immediately after launch before they have accrued earned credits.
Launch credits are spent first, before earned credits. Unspent launch credits are accrued in the CPU credit balance, but do not count towards the CPU credit balance limit. For example, a `t2.micro` instance has a CPU credit balance limit of 144 earned credits. If it is launched and remains idle for 24 hours, its CPU credit balance reaches 174 (30 launch credits \$1 144 earned credits), which is over the limit. However, after the instance spends the 30 launch credits, the credit balance cannot exceed 144. For more information about the CPU credit balance limit for each instance size, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table).
The following table lists the initial CPU credit allocation received at launch or start, and the number of vCPUs.
| Instance type | Launch credits | vCPUs |
| --- | --- | --- |
| t1.micro | 15 | 1 |
| t2.nano | 30 | 1 |
| t2.micro | 30 | 1 |
| t2.small | 30 | 1 |
| t2.medium | 60 | 2 |
| t2.large | 60 | 2 |
| t2.xlarge | 120 | 4 |
| t2.2xlarge | 240 | 8 |
## Launch credit limits
There is a limit to the number of times T2 Standard instances can receive launch credits. The default limit is 100 launches or starts of all T2 Standard instances combined per account, per Region, per rolling 24-hour period. For example, the limit is reached when one instance is stopped and started 100 times within a 24-hour period, or when 100 instances are launched within a 24-hour period, or other combinations that equate to 100 starts. New accounts may have a lower limit, which increases over time based on your usage.
**Tip**
To ensure that your workloads always get the performance they need, switch to [Unlimited mode for burstable performance instances](burstable-performance-instances-unlimited-mode.md) or consider using a larger instance size.
## Differences between launch credits and earned credits
The following table lists the differences between launch credits and earned credits.
| | Launch credits | Earned credits |
| --- | --- | --- |
| **Credit earn rate** | T2 Standard instances get 30 launch credits per vCPU at launch or start. If a T2 instance is switched from `unlimited` to `standard`, it does not get launch credits at the time of switching. | Each T2 instance continuously earns (at a millisecond-level resolution) a set rate of CPU credits per hour, depending on the instance size. For more information about the number of CPU credits earned per instance size, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table). |
| **Credit earn limit** | The limit for receiving launch credits is 100 launches or starts of all T2 Standard instances combined per account, per Region, per rolling 24-hour period. New accounts may have a lower limit, which increases over time based on your usage. | A T2 instance cannot accrue more credits than the CPU credit balance limit. If the CPU credit balance has reached its limit, any credits that are earned after the limit is reached are discarded. Launch credits do not count towards the limit. For more information about the CPU credit balance limit for each T2 instance size, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table). |
| **Credit use** | Launch credits are spent first, before earned credits. | Earned credits are spent only after all launch credits are spent. |
| **Credit expiration** | When a T2 Standard instance is running, launch credits do not expire. When a T2 Standard instance stops or is switched to T2 Unlimited, all launch credits are lost. | When a T2 instance is running, earned credits that have accrued do not expire. When the T2 instance stops, all accrued earned credits are lost. |
The number of accrued launch credits and accrued earned credits is tracked by the CloudWatch metric `CPUCreditBalance`. For more information, see `CPUCreditBalance` in the [CloudWatch metrics table](burstable-performance-instances-monitoring-cpu-credits.md#burstable-performance-instances-CW-metrics-table).
# Standard mode examples for burstable instances
The following examples explain credit use when instances are configured as `standard`.
**Topics**
+ [Example 1: Explain credit use with T3 Standard](#t3_standard_example)
+ [Example 2: Explain credit use with T2 Standard](#t2-standard-example)
## Example 1: Explain credit use with T3 Standard
In this example, you see how a `t3.nano` instance launched as `standard` earns, accrues, and spends *earned* credits. You see how the credit balance reflects the accrued *earned* credits.
A running `t3.nano` instance earns 144 credits every 24 hours. Its credit balance limit is 144 earned credits. After the limit is reached, new credits that are earned are discarded. For more information about the number of credits that can be earned and accrued, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table).
You might launch a T3 Standard instance and use it immediately. Or, you might launch a T3 Standard instance and leave it idle for a few days before running applications on it. Whether an instance is used or remains idle determines if credits are spent or accrued. If an instance remains idle for 24 hours from the time it is launched, the credit balance reaches it limit, which is the maximum number of earned credits that can be accrued.
This example describes an instance that remains idle for 24 hours from the time it is launched, and walks you through seven periods of time over a 96-hour period, showing the rate at which credits are earned, accrued, spent, and discarded, and the value of the credit balance at the end of each period.
The following workflow references the numbered points on the graph:
**P1** – At 0 hours on the graph, the instance is launched as `standard` and immediately begins to earn credits. The instance remains idle from the time it is launched—CPU utilization is 0%—and no credits are spent. All unspent credits are accrued in the credit balance. For the first 24 hours, `CPUCreditUsage` is at 0, and the `CPUCreditBalance` value reaches its maximum of 144.
**P2** – For the next 12 hours, CPU utilization is at 2.5%, which is below the 5% baseline. The instance earns more credits than it spends, but the `CPUCreditBalance` value cannot exceed its maximum of 144 credits. Any credits that are earned in excess of the limit are discarded.
**P3** – For the next 24 hours, CPU utilization is at 7% (above the baseline), which requires a spend of 57.6 credits. The instance spends more credits than it earns, and the `CPUCreditBalance` value reduces to 86.4 credits.
**P4** – For the next 12 hours, CPU utilization decreases to 2.5% (below the baseline), which requires a spend of 36 credits. In the same time, the instance earns 72 credits. The instance earns more credits than it spends, and the `CPUCreditBalance` value increases to 122 credits.
**P5** – For the next two hours, the instance bursts at 60% CPU utilization, and depletes its entire `CPUCreditBalance` value of 122 credits. At the end of this period, with the `CPUCreditBalance` at zero, CPU utilization is forced to drop to the baseline utilization level of 5%. At the baseline, the instance earns as many credits as it spends.
**P6** – For the next 14 hours, CPU utilization is at 5% (the baseline). The instance earns as many credits as it spends. The `CPUCreditBalance` value remains at 0.
**P7** – For the last 24 hours in this example, the instance is idle and CPU utilization is 0%. During this time, the instance earns 144 credits, which it accrues in its `CPUCreditBalance`.
![\[T3 Standard instance CPU utilization.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t3_standard_graph.png)
## Example 2: Explain credit use with T2 Standard
In this example, you see how a `t2.nano` instance launched as `standard` earns, accrues, and spends *launch* and *earned* credits. You see how the credit balance reflects not only accrued *earned* credits, but also accrued *launch* credits.
A `t2.nano` instance gets 30 launch credits when it is launched, and earns 72 credits every 24 hours. Its credit balance limit is 72 earned credits; launch credits do not count towards the limit. After the limit is reached, new credits that are earned are discarded. For more information about the number of credits that can be earned and accrued, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table). For more information about limits, see [Launch credit limits](burstable-performance-instances-standard-mode-concepts.md#launch-credit-limits).
You might launch a T2 Standard instance and use it immediately. Or, you might launch a T2 Standard instance and leave it idle for a few days before running applications on it. Whether an instance is used or remains idle determines if credits are spent or accrued. If an instance remains idle for 24 hours from the time it is launched, the credit balance appears to exceed its limit because the balance reflects both accrued earned credits and accrued launch credits. However, after CPU is used, the launch credits are spent first. Thereafter, the limit always reflects the maximum number of earned credits that can be accrued.
This example describes an instance that remains idle for 24 hours from the time it is launched, and walks you through seven periods of time over a 96-hour period, showing the rate at which credits are earned, accrued, spent, and discarded, and the value of the credit balance at the end of each period.
### Period 1: 1 – 24 hours
At 0 hours on the graph, the T2 instance is launched as `standard` and immediately gets 30 launch credits. It earns credits while in the running state. The instance remains idle from the time it is launched—CPU utilization is 0%—and no credits are spent. All unspent credits are accrued in the credit balance. At approximately 14 hours after launch, the credit balance is 72 (30 launch credits \$1 42 earned credits), which is equivalent to what the instance can earn in 24 hours. At 24 hours after launch, the credit balance exceeds 72 credits because the unspent launch credits are accrued in the credit balance—the credit balance is 102 credits: 30 launch credits \$1 72 earned credits.
![\[In period 1 for the T2 standard, the credit balance is 102 credits.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph1.png)
| | |
| --- |--- |
| Credit Spend Rate | 0 credits per 24 hours (0% CPU utilization) |
| Credit Earn Rate | 72 credits per 24 hours |
| Credit Discard Rate | 0 credits per 24 hours |
| Credit Balance | 102 credits (30 launch credits \$1 72 earned credits) |
**Conclusion**
If there is no CPU utilization after launch, the instance accrues more credits than what it can earn in 24 hours (30 launch credits \$1 72 earned credits = 102 credits).
In a real-world scenario, an EC2 instance consumes a small number of credits while launching and running, which prevents the balance from reaching the maximum theoretical value in this example.
### Period 2: 25 – 36 hours
For the next 12 hours, the instance continues to remain idle and earn credits, but the credit balance does not increase. It plateaus at 102 credits (30 launch credits \$1 72 earned credits). The credit balance has reached its limit of 72 accrued earned credits, so newly earned credits are discarded.
![\[The credit balance has reached its limit of 72 accrued earned credits.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph2.png)
| | |
| --- |--- |
| Credit Spend Rate | 0 credits per 24 hours (0% CPU utilization) |
| Credit Earn Rate | 72 credits per 24 hours (3 credits per hour) |
| Credit Discard Rate | 72 credits per 24 hours (100% of credit earn rate) |
| Credit Balance | 102 credits (30 launch credits \$1 72 earned credits)—balance is unchanged |
**Conclusion**
An instance constantly earns credits, but it cannot accrue more earned credits if the credit balance has reached its limit. After the limit is reached, newly earned credits are discarded. Launch credits do not count towards the credit balance limit. If the balance includes accrued launch credits, the balance appears to be over the limit.
### Period 3: 37 – 61 hours
For the next 25 hours, the instance uses 2% CPU, which requires 30 credits. In the same period, it earns 75 credits, but the credit balance decreases. The balance decreases because the accrued *launch* credits are spent first, while newly earned credits are discarded because the credit balance is already at its limit of 72 earned credits.
![\[Newly earned credits are discarded because the credit balance is already at its limit.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph3.png)
| | |
| --- |--- |
| Credit Spend Rate | 28.8 credits per 24 hours (1.2 credits per hour, 2% CPU utilization, 40% of credit earn rate)—30 credits over 25 hours |
| Credit Earn Rate | 72 credits per 24 hours |
| Credit Discard Rate | 72 credits per 24 hours (100% of credit earn rate) |
| Credit Balance | 72 credits (30 launch credits were spent; 72 earned credits remain unspent) |
**Conclusion**
An instance spends launch credits first, before spending earned credits. Launch credits do not count towards the credit limit. After the launch credits are spent, the balance can never go higher than what can be earned in 24 hours. Furthermore, while an instance is running, it cannot get more launch credits.
### Period 4: 62 – 72 hours
For the next 11 hours, the instance uses 2% CPU, which requires 13.2 credits. This is the same CPU utilization as in the previous period, but the balance does not decrease. It stays at 72 credits.
The balance does not decrease because the credit earn rate is higher than the credit spend rate. In the time that the instance spends 13.2 credits, it also earns 33 credits. However, the balance limit is 72 credits, so any earned credits that exceed the limit are discarded. The balance plateaus at 72 credits, which is different from the plateau of 102 credits during Period 2, because there are no accrued launch credits.
![\[The balance plateaus at 72 credits, because there are no accrued launch credits.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph4.png)
| | |
| --- |--- |
| Credit Spend Rate | 28.8 credits per 24 hours (1.2 credits per hour, 2% CPU utilization, 40% of credit earn rate)—13.2 credits over 11 hours |
| Credit Earn Rate | 72 credits per 24 hours |
| Credit Discard Rate | 43.2 credits per 24 hours (60% of credit earn rate) |
| Credit Balance | 72 credits (0 launch credits, 72 earned credits)—balance is at its limit |
**Conclusion**
After launch credits are spent, the credit balance limit is determined by the number of credits that an instance can earn in 24 hours. If the instance earns more credits than it spends, newly earned credits over the limit are discarded.
### Period 5: 73 – 75 hours
For the next three hours, the instance bursts at 20% CPU utilization, which requires 36 credits. The instance earns nine credits in the same three hours, which results in a net balance decrease of 27 credits. At the end of three hours, the credit balance is 45 accrued earned credits.
![\[At the end of three hours, the credit balance is 45 accrued earned credits.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph5.png)
| | |
| --- |--- |
| Credit Spend Rate | 288 credits per 24 hours (12 credits per hour, 20% CPU utilization, 400% of credit earn rate)—36 credits over 3 hours |
| Credit Earn Rate | 72 credits per 24 hours (9 credits over 3 hours) |
| Credit Discard Rate | 0 credits per 24 hours |
| Credit Balance | 45 credits (previous balance (72) - spent credits (36) \$1 earned credits (9))—balance decreases at a rate of 216 credits per 24 hours (spend rate 288/24 \$1 earn rate 72/24 = balance decrease rate 216/24) |
**Conclusion**
If an instance spends more credits than it earns, its credit balance decreases.
### Period 6: 76 – 90 hours
For the next 15 hours, the instance uses 2% CPU, which requires 18 credits. This is the same CPU utilization as in Periods 3 and 4. However, the balance increases in this period, whereas it decreased in Period 3 and plateaued in Period 4.
In Period 3, the accrued launch credits were spent, and any earned credits that exceeded the credit limit were discarded, resulting in a decrease in the credit balance. In Period 4, the instance spent fewer credits than it earned. Any earned credits that exceeded the limit were discarded, so the balance plateaued at its maximum of 72 credits.
In this period, there are no accrued launch credits, and the number of accrued earned credits in the balance is below the limit. No earned credits are discarded. Furthermore, the instance earns more credits than it spends, resulting in an increase in the credit balance.
![\[The instance earns more credits than it spends.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph6.png)
| | |
| --- |--- |
| Credit Spend Rate | 28.8 credits per 24 hours (1.2 credits per hour, 2% CPU utilization, 40% of credit earn rate)—18 credits over 15 hours |
| Credit Earn Rate | 72 credits per 24 hours (45 credits over 15 hours) |
| Credit Discard Rate | 0 credits per 24 hours |
| Credit Balance | 72 credits (balance increases at a rate of 43.2 credits per 24 hours—change rate = spend rate 28.8/24 \$1 earn rate 72/24) |
**Conclusion**
If an instance spends fewer credits than it earns, its credit balance increases.
### Period 7: 91 – 96 hours
For the next six hours, the instance remains idle—CPU utilization is 0%—and no credits are spent. This is the same CPU utilization as in Period 2, but the balance does not plateau at 102 credits—it plateaus at 72 credits, which is the credit balance limit for the instance.
In Period 2, the credit balance included 30 accrued launch credits. The launch credits were spent in Period 3. A running instance cannot get more launch credits. After its credit balance limit is reached, any earned credits that exceed the limit are discarded.
![\[Earned credits that exceed the limit are discarded.\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/images/t2-graph7.png)
| | |
| --- |--- |
| Credit Spend Rate | 0 credits per 24 hours (0% CPU utilization) |
| Credit Earn Rate | 72 credits per 24 hours |
| Credit Discard Rate | 72 credits per 24 hours (100% of credit earn rate) |
| Credit Balance | 72 credits (0 launch credits, 72 earned credits) |
**Conclusion**
An instance constantly earns credits, but cannot accrue more earned credits if the credit balance limit has been reached. After the limit is reached, newly earned credits are discarded. The credit balance limit is determined by the number of credits that an instance can earn in 24 hours. For more information about credit balance limits, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table).
# Configure burstable performance instances
The steps for launching, monitoring, and modifying burstable performance instances (T instances) are similar. The key difference is the default credit specification when they launch.
Each T instance family comes with the following *default credit specification*:
+ T4g, T3a, and T3 instances launch as `unlimited`
+ T3 instances on a Dedicated Host can only launch as `standard`
+ T2 instances launch as `standard`
You can [change the default credit specification](#burstable-performance-instance-set-default-credit-specification-for-account) for the account.
**Topics**
+ [Configure the credit specification at launch](#launch-burstable-performance-instances)
+ [Configure an Auto Scaling group to set the credit specification as unlimited](#burstable-performance-instances-auto-scaling-grp)
+ [Manage the credit specification of a burstable performance instance](#modify-burstable-performance-instances)
+ [Manage the default credit specification for an account](#burstable-performance-instance-set-default-credit-specification-for-account)
## Configure the credit specification at launch
You can launch your T instances with a credit specification of `unlimited` or `standard`.
The following procedures describe how to use the EC2 console or the AWS CLI. For information about using an Auto Scaling group, see [Configure an Auto Scaling group to set the credit specification as unlimited](#burstable-performance-instances-auto-scaling-grp).
------
#### [ Console ]
**To configure the credit specification of an instance at launch**
1. Follow the procedure to [launch an instance](ec2-launch-instance-wizard.md).
1. Under **Instance type**, select a T instance type.
1. Expand **Advanced details**. For **Credit specification**, select a credit specification.
1. In the **Summary** panel, review your instance configuration, and then choose **Launch instance**.
------
#### [ AWS CLI ]
**To set the credit specification of an instance at launch**
Use the [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) command with the `--credit-specification` option.
```
--credit-specification CpuCredits=unlimited
```
------
#### [ PowerShell ]
**To set the credit specification of an instance at launch**
Use the [New-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) cmdlet with the `-CreditSpecification_CpuCredit` parameter.
```
-CreditSpecification_CpuCredit unlimited
```
------
## Configure an Auto Scaling group to set the credit specification as unlimited
When T instances are launched or started, they require CPU credits for a good bootstrapping experience. If you use an Auto Scaling group to launch your instances, we recommend that you configure your instances as `unlimited`. If you do, the instances use surplus credits when they are automatically launched or restarted by the Auto Scaling group. Using surplus credits prevents performance restrictions.
### Create a launch template
You must use a *launch template* for launching instances as `unlimited` in an Auto Scaling group. A launch configuration does not support launching instances as `unlimited`.
------
#### [ Console ]
**To create a launch template that sets the credit specification**
1. Follow the [Create a launch template using advanced settings](https://docs.aws.amazon.com/autoscaling/ec2/userguide/advanced-settings-for-your-launch-template.html) procedure in the *Amazon EC2 Auto Scaling User Guide*.
1. In **Launch template contents**, for **Instance type**, choose an instance size.
1. To launch instances as `unlimited` in an Auto Scaling group, under **Advanced details**, for **Credit specification**, choose **Unlimited**.
1. When you've finished defining the launch template parameters, choose **Create launch template**.
------
#### [ AWS CLI ]
**To create a launch template that sets the credit specification**
Use the [create-launch-template](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html) command.
```
aws ec2 create-launch-template \
--launch-template-name my-launch-template \
--version-description FirstVersion \
--launch-template-data CreditSpecification={CpuCredits=unlimited}
```
------
#### [ PowerShell ]
**To create a launch template that sets the credit specification**
Use the [New-EC2LaunchTemplate](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2LaunchTemplate.html) cmdlet. Define the credit specification for the launch template data as follows.
```
$creditSpec = New-Object Amazon.EC2.Model.CreditSpecificationRequest
$creditSpec.CpuCredits = "unlimited"
$launchTemplateData = New-Object Amazon.EC2.Model.RequestLaunchTemplateData
$launchTemplateData.CreditSpecification = $creditSpec
```
------
### Associate an Auto Scaling group with a launch template
To associate the launch template with an Auto Scaling group, create the Auto Scaling group using the launch template, or add the launch template to an existing Auto Scaling group.
------
#### [ Console ]
**To create an Auto Scaling group using a launch template**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. On the navigation bar at the top of the screen, select the same Region that you used when you created the launch template.
1. In the navigation pane, choose **Auto Scaling Groups**, **Create Auto Scaling group**.
1. Choose **Launch Template**, select your launch template, and then choose **Next Step**.
1. Complete the fields for the Auto Scaling group. When you've finished reviewing your configuration settings on the **Review page**, choose **Create Auto Scaling group**. For more information, see [Creating an Auto Scaling Group Using a Launch Template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html) in the *Amazon EC2 Auto Scaling User Guide*.
**To add a launch template to an existing Auto Scaling group**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. On the navigation bar at the top of the screen, select the same Region that you used when you created the launch template.
1. In the navigation pane, choose **Auto Scaling Groups**.
1. From the Auto Scaling group list, select an Auto Scaling group, and choose **Actions**, **Edit**.
1. On the **Details** tab, for **Launch Template**, choose a launch template, and then choose **Save**.
------
#### [ AWS CLI ]
**To create an Auto Scaling group using a launch template**
Use the [create-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-auto-scaling-group.html) command and specify the `--launch-template` parameter.
**To add a launch template to an existing Auto Scaling group**
Use the [update-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html) command and specify the `--launch-template` parameter.
------
#### [ PowerShell ]
**To create an Auto Scaling group using a launch template**
Use the [New-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) cmdlet and specify the `-LaunchTemplate_LaunchTemplateId` or `-LaunchTemplate_LaunchTemplateName` parameter.
**To add a launch template to an existing Auto Scaling group**
Use the [Update-ASAutoScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-ASAutoScalingGroup.html) cmdlet and specify the `-LaunchTemplate_LaunchTemplateId` or `-LaunchTemplate_LaunchTemplateName` parameter.
------
## Manage the credit specification of a burstable performance instance
You can switch the credit specification of a running or stopped T instance at any time between `unlimited` and `standard`.
Note that in `unlimited` mode, an instance can spend surplus credits, which might incur an additional charge. For more information, see [Surplus credits can incur charges](burstable-performance-instances-unlimited-mode-concepts.md#unlimited-mode-surplus-credits).
------
#### [ Console ]
**To manage the credit specification of an instance**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the left navigation pane, choose **Instances**.
1. (Optional) Select an instance. On its **Details** tab, find **Credit specification**. The value is either `unlimited` or `standard`.
1. (Optional) To modify the credit specification for multiple instances at the same time, select them all.
1. Choose **Actions**, **Instance settings**, **Change credit specification**. This option is enabled only if you selected a T instance.
1. For **Unlimited mode**, select or clear the checkbox next to each instance ID.
------
#### [ AWS CLI ]
**To get the credit specification of an instance**
Use the [describe-instance-credit-specifications](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-credit-specifications.html) command. If you do not specify an instance ID, all instances with the credit specification of `unlimited` are returned. The output would also include instances that were previously configured with the `unlimited` credit specification. For example, if you resize a T3 instance to an M4 instance, while it is configured as `unlimited`, Amazon EC2 returns the M4 instance.
```
aws ec2 describe-instance-credit-specifications \
--instance-id i-1234567890abcdef0 \
--query InstanceCreditSpecifications[].CpuCredits \
--output text
```
The following is example output.
```
unlimited
```
**To set the credit specification of an instance**
Use the [modify-instance-credit-specification](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-credit-specification.html) command.
```
aws ec2 modify-instance-credit-specification \
--region us-east-1 \
--instance-credit-specification "InstanceId=i-1234567890abcdef0,CpuCredits=unlimited"
```
------
#### [ PowerShell ]
**To get the credit specification of an instance**
Use the [Get-EC2CreditSpecification](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2CreditSpecification.html) cmdlet.
```
(Get-EC2CreditSpecification `
-InstanceId i-1234567890abcdef0).CpuCredits
```
The following is example output.
```
unlimited
```
**To set the credit specification of an instance**
Use the [Edit-EC2InstanceCreditSpecification](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceCreditSpecification.html) cmdlet.
```
Edit-EC2InstanceCreditSpecification `
-Region us-east-1 `
-InstanceCreditSpecification @({InstanceId="i-1234567890abcdef0" CpuCredits="unlimited"})
```
------
## Manage the default credit specification for an account
Each T instance family comes with a [default credit specification](#default-credit-spec). You can change the default credit specification for each T instance family at the account level per AWS Region. The valid values for the default credit specification are `unlimited` and `standard`.
If you use the launch instance wizard in the EC2 console to launch instances, the value you select for the credit specification overrides the account-level default credit specification. If you use the AWS CLI to launch instances, all new T instances in the account launch using the default credit specification. The credit specification for existing running or stopped instances is not affected.
**Consideration**
The default credit specification for an instance family can be modified only once in a rolling 5-minute period, and up to four times in a rolling 24-hour period.
------
#### [ Console ]
**To manage the default credit specification**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. To change the AWS Region, use the Region selector in the upper-right corner of the page.
1. In the navigation pane, choose **Dashboard**.
1. On the **Account attributes** card, under **Settings**, choose **Default credit specification**.
1. Choose **Manage**.
1. For each instance family, choose **Unlimited** or **Standard**, and then choose **Update**.
------
#### [ AWS CLI ]
**To get the default credit specification**
Use the [get-default-credit-specification](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-default-credit-specification.html) command.
```
aws ec2 get-default-credit-specification \
--region us-east-1 \
--instance-family t2 \
--query InstanceFamilyCreditSpecifications[].CpuCredits \
--output text
```
The following is example output.
```
standard
```
**To set the default credit specification**
Use the [modify-default-credit-specification](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-default-credit-specification.html) command. The following example sets the value to `unlimited`.
```
aws ec2 modify-default-credit-specification \
--region us-east-1 \
--instance-family t2 \
--cpu-credits unlimited
```
------
#### [ PowerShell ]
**To get the default credit specification**
Use the [Get-EC2DefaultCreditSpecification](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2DefaultCreditSpecification.html) cmdlet.
```
(Get-EC2DefaultCreditSpecification `
-Region us-east-1 `
-InstanceFamily t2).CpuCredits
```
The following is example output.
```
standard
```
**To set the default credit specification**
Use the [Edit-EC2DefaultCreditSpecification](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2DefaultCreditSpecification.html) cmdlet. The following example sets the value to `unlimited`.
```
Edit-EC2DefaultCreditSpecification `
-Region us-east-1 `
-InstanceFamily t2 `
-CpuCredit unlimited
```
------
# Monitor CPU credits for burstable instances
EC2 sends metrics to Amazon CloudWatch. You can see the CPU credit metrics in the Amazon EC2 per-instance metrics of the CloudWatch console or by using the AWS CLI to list the metrics for each instance. For more information, see [CloudWatch metrics that are available for your instances](viewing_metrics_with_cloudwatch.md).
**Topics**
+ [Additional CloudWatch metrics for burstable performance instances](#burstable-performance-instances-cw-metrics)
+ [Calculate CPU credit usage](#burstable-performance-instances-calculating-credit-use)
## Additional CloudWatch metrics for burstable performance instances
Burstable performance instances have these additional CloudWatch metrics, which are updated every five minutes:
+ `CPUCreditUsage` – The number of CPU credits spent during the measurement period.
+ `CPUCreditBalance` – The number of CPU credits that an instance has accrued. This balance is depleted when the CPU bursts and CPU credits are spent more quickly than they are earned.
+ `CPUSurplusCreditBalance` – The number of surplus CPU credits spent to sustain CPU utilization when the `CPUCreditBalance` value is zero.
+ `CPUSurplusCreditsCharged` – The number of surplus CPU credits exceeding the [maximum number of CPU credits](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table) that can be earned in a 24-hour period, and thus attracting an additional charge.
The last two metrics apply only to instances configured as `unlimited`.
The following table describes the CloudWatch metrics for burstable performance instances. For more information, see [CloudWatch metrics that are available for your instances](viewing_metrics_with_cloudwatch.md).
| Metric | Description |
| --- | --- |
| CPUCreditUsage | The number of CPU credits spent by the instance for CPU utilization. One CPU credit equals one vCPU running at 100% utilization for one minute or an equivalent combination of vCPUs, utilization, and time (for example, one vCPU running at 50% utilization for two minutes or two vCPUs running at 25% utilization for two minutes). CPU credit metrics are available at a five-minute frequency only. If you specify a period greater than five minutes, use the `Sum` statistic instead of the `Average` statistic. Units: Credits (vCPU-minutes) |
| CPUCreditBalance | The number of earned CPU credits that an instance has accrued since it was launched or started. For T2 Standard, the `CPUCreditBalance` also includes the number of launch credits that have been accrued. Credits are accrued in the credit balance after they are earned, and removed from the credit balance when they are spent. The credit balance has a maximum limit, determined by the instance size. After the limit is reached, any new credits that are earned are discarded. For T2 Standard, launch credits do not count towards the limit. The credits in the `CPUCreditBalance` are available for the instance to spend to burst beyond its baseline CPU utilization. When an instance is running, credits in the `CPUCreditBalance` do not expire. When a T4g, T3a or T3 instance stops, the `CPUCreditBalance` value persists for seven days. Thereafter, all accrued credits are lost. When a T2 instance stops, the `CPUCreditBalance` value does not persist, and all accrued credits are lost. CPU credit metrics are available at a five-minute frequency only. Units: Credits (vCPU-minutes) |
| CPUSurplusCreditBalance | The number of surplus credits that have been spent by an `unlimited` instance when its `CPUCreditBalance` value is zero. The `CPUSurplusCreditBalance` value is paid down by earned CPU credits. If the number of surplus credits exceeds the maximum number of credits that the instance can earn in a 24-hour period, the spent surplus credits above the maximum incur an additional charge. Units: Credits (vCPU-minutes) |
| CPUSurplusCreditsCharged | The number of spent surplus credits that are not paid down by earned CPU credits, and which thus incur an additional charge. Spent surplus credits are charged when any of the following occurs: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-monitoring-cpu-credits.html) Units: Credits (vCPU-minutes) |
## Calculate CPU credit usage
The CPU credit usage of instances is calculated using the instance CloudWatch metrics described in the preceding table.
Amazon EC2 sends the metrics to CloudWatch every five minutes. A reference to the *prior* value of a metric at any point in time implies the previous value of the metric, sent *five minutes ago*.
### Calculate CPU credit usage for Standard instances
+ The CPU credit balance increases if CPU utilization is below the baseline, when the credits spent are less than the credits earned in the prior five-minute interval.
+ The CPU credit balance decreases if CPU utilization is above the baseline, when the credits spent are more than the credits earned in the prior five-minute interval.
Mathematically, this is captured by the following equation:
**Example**
```
CPUCreditBalance = prior CPUCreditBalance + [Credits earned per hour * (5/60) - CPUCreditUsage]
```
The size of the instance determines the number of credits that the instance can earn per hour and the number of earned credits that it can accrue in the credit balance. For information about the number of credits earned per hour, and the credit balance limit for each instance size, see the [credit table](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table).
**Example**
This example uses a `t3.nano` instance. To calculate the `CPUCreditBalance` value of the instance, use the preceding equation as follows:
+ `CPUCreditBalance` – The current credit balance to calculate.
+ `prior CPUCreditBalance` – The credit balance five minutes ago. In this example, the instance had accrued two credits.
+ `Credits earned per hour` – A `t3.nano` instance earns six credits per hour.
+ `5/60` – Represents the five-minute interval between CloudWatch metric publication. Multiply the credits earned per hour by 5/60 (five minutes) to get the number of credits that the instance earned in the past five minutes. A `t3.nano` instance earns 0.5 credits every five minutes.
+ `CPUCreditUsage` – How many credits the instance spent in the past five minutes. In this example, the instance spent one credit in the past five minutes.
Using these values, you can calculate the `CPUCreditBalance` value:
**Example**
```
CPUCreditBalance = 2 + [0.5 - 1] = 1.5
```
### Calculate CPU credit usage for Unlimited instances
When a burstable performance instance needs to burst above the baseline, it always spends accrued credits before spending surplus credits. When it depletes its accrued CPU credit balance, it can spend surplus credits to burst CPU for as long as it needs. When CPU utilization falls below the baseline, surplus credits are always paid down before the instance accrues earned credits.
We use the term `Adjusted balance` in the following equations to reflect the activity that occurs in this five-minute interval. We use this value to arrive at the values for the `CPUCreditBalance` and `CPUSurplusCreditBalance` CloudWatch metrics.
**Example**
```
Adjusted balance = [prior CPUCreditBalance - prior CPUSurplusCreditBalance] + [Credits earned per hour * (5/60) - CPUCreditUsage]
```
A value of `0` for `Adjusted balance` indicates that the instance spent all its earned credits for bursting, and no surplus credits were spent. As a result, both `CPUCreditBalance` and `CPUSurplusCreditBalance` are set to `0`.
A positive `Adjusted balance` value indicates that the instance accrued earned credits, and previous surplus credits, if any, were paid down. As a result, the `Adjusted balance` value is assigned to `CPUCreditBalance`, and the `CPUSurplusCreditBalance` is set to `0`. The instance size determines the [maximum number of credits](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table) that it can accrue.
**Example**
```
CPUCreditBalance = min [max earned credit balance, Adjusted balance]
CPUSurplusCreditBalance = 0
```
A negative `Adjusted balance` value indicates that the instance spent all its earned credits that it accrued and, in addition, also spent surplus credits for bursting. As a result, the `Adjusted balance` value is assigned to `CPUSurplusCreditBalance` and `CPUCreditBalance` is set to `0`. Again, the instance size determines the [maximum number of credits](burstable-credits-baseline-concepts.md#burstable-performance-instances-credit-table) that it can accrue.
**Example**
```
CPUSurplusCreditBalance = min [max earned credit balance, -Adjusted balance]
CPUCreditBalance = 0
```
If the surplus credits spent exceed the maximum credits that the instance can accrue, the surplus credit balance is set to the maximum, as shown in the preceding equation. The remaining surplus credits are charged as represented by the `CPUSurplusCreditsCharged` metric.
**Example**
```
CPUSurplusCreditsCharged = max [-Adjusted balance - max earned credit balance, 0]
```
Finally, when the instance terminates, any surplus credits tracked by the `CPUSurplusCreditBalance` are charged. If the instance is switched from `unlimited` to `standard`, any remaining `CPUSurplusCreditBalance` is also charged.