T1 Micro instances (
t1.micro) provide a small amount of consistent CPU resources
and allow you to increase CPU capacity in short bursts when additional cycles are available.
They are well suited for lower throughput applications and websites that require additional
compute cycles periodically.
t1.micro is a previous generation instance and it has been
replaced by the
t2.micro, which has a much better performance
profile. We recommend using the
t2.micro instance type instead of
t1.micro. For more information, see T2 Instances.
t1.micro instance is available as an Amazon EBS-backed instance only.
This documentation describes how
t1.micro instances work so that you can understand how to
apply them. It's not our intent to specify exact behavior, but to give you visibility into the
instance's behavior so you can understand its performance.
For more information about the hardware specifications for each Amazon EC2 instance type, see Amazon EC2 Instances.
t1.micro instance provides spiky CPU resources for workloads that have a CPU usage
profile similar to what is shown in the following figure.
The instance is designed to operate with its CPU usage at essentially only two levels:
the normal low background level, and then at brief spiked levels much higher than the
background level. We allow the instance to operate at up to 2 EC2 compute units (ECUs)
(one ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor).
The ratio between the maximum level
and the background level is designed to be large. We designed
to support tens of requests per minute on your application. However, actual performance can
vary significantly depending on the amount of CPU resources required for each request on
Your application might have a different CPU usage profile than that described in the
preceding section. The next figure shows the profile for an application that isn't
appropriate for a
t1.micro instance. The application requires continuous data-crunching CPU
resources for each request, resulting in plateaus of CPU usage that the
isn't designed to handle.
The next figure shows another profile that isn't appropriate for a
Here the spikes in CPU use are brief, but they occur too frequently to be serviced by a
The next figure shows another profile that isn't appropriate for a
Here the spikes aren't too frequent, but the background level between spikes is too high
to be serviced by a
In each of the preceding cases of workloads not appropriate for a
t1.micro instance, we
recommend that you consider using a different instance type. For more information about
instance types, see Instance Types.
When your instance bursts to accommodate a spike in demand for compute resources, it uses unused resources on the host. The amount available depends on how much contention there is when the spike occurs. The instance is never left with zero CPU resources, whether other instances on the host are spiking or not.
We expect your application to consume only a certain amount of CPU resources in a period of time. If the application consumes more than your instance's allotted CPU resources, we temporarily limit the instance so it operates at a low CPU level. If your instance continues to use all of its allotted resources, its performance will degrade. We will increase the time that we limit its CPU level, thus increasing the time before the instance is allowed to burst again.
If you enable CloudWatch monitoring for your
t1.micro instance, you can use the "Avg
CPU Utilization" graph in the AWS Management Console to determine whether your instance is regularly
using all its allotted CPU resources. We recommend that you look at the maximum value
reached during each given period. If the maximum value is 100%, we recommend that you
use Auto Scaling to scale out (with additional
t1.micro instances and a load
balancer), or move to a larger instance type. For more information, see the
Auto Scaling Developer Guide.
The following figures show the three suboptimal profiles from the preceding section and what it might look like when the instance consumes its allotted resources and we have to limit its CPU level. If the instance consumes its allotted resources, we restrict it to the low background level.
The next figure shows the situation with the long plateaus of data-crunching CPU usage. The CPU hits the maximum allowed level and stays there until the instance's allotted resources are consumed for the period. At that point, we limit the instance to operate at the low background level, and it operates there until we allow it to burst above that level again. The instance again stays there until the allotted resources are consumed and we limit it again (not seen on the graph).
The next figure shows the situation where the requests are too frequent. The instance uses its allotted resources after only a few requests and so we limit it. After we lift the restriction, the instance maxes out its CPU usage trying to keep up with the requests, and we limit it again.
The next figure shows the situation where the background level is too high. Notice that the instance doesn't have to be operating at the maximum CPU level for us to limit it. We limit the instance when it's operating above the normal background level and has consumed its allotted resources for the given period. In this case (as in the preceding one), the instance can't keep up with the work, and we limit it again.
t1.micro instance provides different levels of CPU resources at different times (up
to 2 ECUs). By comparison, the
m1.small instance type provides 1 ECU at all times. The
following figure illustrates the difference.
The following figures compare the CPU usage of a
t1.micro instance with an
for the various scenarios we've discussed in the preceding sections.
The first figure that follows shows an optimal scenario for a
t1.micro instance (the left
graph) and how it might look for an
m1.small instance (the right graph). In this case,
we don't need to limit the
t1.micro instance. The processing time on the
would be longer for each spike in CPU demand compared to the
The next figure shows the scenario with the data-crunching requests that used up the
allotted resources on the
t1.micro instance, and how they might look with the
The next figure shows the frequent requests that used up the allotted resources on the
t1.micro instance, and how they might look on the
The next figure shows the situation where the background level used up the allotted
resources on the
t1.micro instance, and how it might look on the
We recommend that you follow these best practices when optimizing an AMI for the
Design the AMI to run on 600 MB of RAM
Limit the number of recurring processes that use CPU time (for example, cron jobs, daemons)
You can optimize performance using swap space and virtual memory (for example, by setting up swap space in a separate partition from the root file system).