HI1 instances (
hi1.4xlarge) can deliver tens of thousands of low-latency,
random I/O operations per second (IOPS) to applications. They are well suited for the
NoSQL databases (for example, Cassandra and MongoDB)
Online transaction processing (OLTP) systems
You can cluster HI1 instances in a placement group. For more information, see Placement Groups.
By default, you can run up to two
hi1.4xlarge instances. If you need more than two
instances, you can request more using the Amazon EC2 Instance Request
hi1.4xlarge instance type is based on solid-state drive (SSD) technology.
For more information about the hardware specifications for each Amazon EC2 instance type, see Instance Type Details.
Using Linux paravirtual (PV) AMIs, HI1 instances can deliver more than 120,000 4 KB random read IOPS and between 10,000 and 85,000 4 KB random write IOPS (depending on active logical block addressing span) to applications across two SSD data volumes. Using hardware virtual machine (HVM) AMIs, performance is approximately 90,000 4 KB random read IOPS and between 9,000 and 75,000 4 KB random write IOPS.
HI1 Windows instances deliver approximately 90,000 4 KB random read IOPS and between 9,000 and 75,000 4 KB random write IOPS.
The maximum sequential throughput is approximately 2 GB read per second and 1.1 GB write per second.
This section contains important information you need to know about SSD storage. With SSD storage:
The primary data source is an instance store with SSD storage.
Read performance is consistent and write performance can vary.
Write amplification can occur.
The TRIM command is not currently supported.
hi1.4xlarge instances use an Amazon EBS-backed root device. However,
their primary data storage is provided by the SSD volumes in the instance store. Like
other instance store volumes, these instance store volumes persist only for the life of
the instance. Because the root device of the
hi1.4xlarge instance is
Amazon EBS-backed, you can still start and stop your instance. When you stop an instance,
your application persists, but your production data in the instance store does not
persist. For more information about instance store volumes, see Amazon EC2 Instance Store.
Write performance depends on how your applications utilize logical block addressing (LBA) space. If your applications use the total LBA space, write performance can degrade by about 90 percent. Benchmark your applications and monitor the queue length (the number of pending I/O requests for a volume) and I/O size.
Write amplification refers to an undesirable condition associated with flash memory
and SSDs, where the actual amount of physical information written is a multiple of the logical
amount intended to be written. Because flash memory must be erased before it can be rewritten,
the process to perform these operations results in moving (or rewriting) user data and
metadata more than once. This multiplying effect increases the number of writes required over
the life of the SSD, which shortens the time that it can reliably operate. The
are designed with a provisioning model intended to minimize write amplification.
Random writes have a much more severe impact on write amplification than serial writes. If you are concerned about write amplification, allocate less than the full tebibyte of storage for your application (also known as over provisioning).
The TRIM command enables the operating system to notify an SSD that blocks of previously saved data are considered no longer in use. TRIM limits the impact of write amplification.
TRIM support is not available for HI1 instances. For TRIM support, use I2 instances. For more information, see I2 Instances.