| « PreviousNext » | |
![]() ![]() ![]() | Did this page help you? Yes | No | Tell us about it... |
High I/O 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 following scenarios:
NoSQL databases (for example, Cassandra and MongoDB)
Clustered databases
Online transaction processing (OLTP) systems
By default, you can run up to two high I/O instances. If you need more than two high I/O instances, you can request more using the Amazon EC2 Instance Request Form.
You can cluster high I/O instances in a cluster placement group. The placement group cannot contain other cluster instances.
The hi1.4xlarge instance type is based on solid-state drive (SSD) technology.
The hardware specifications for hi1.4xlarge instances are described in the following table.
| Item | Description |
|---|---|
| Processor | 35 EC2 compute units |
| Virtual cores | 16 virtual cores (8 cores + 8 hyperthreads) |
| Memory | 60.5 GiB |
| Platform | 64-bit |
| Network | 10 Gbps Ethernet |
| Instance store volumes | 2 x 1 TiB (SSD) |
Using Linux paravirtual (PV) AMIs, high I/O 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 1 TiB data volumes. For hardware virtual machines (HVM) and Windows AMIs, performance is approximately 90,000 4 KB random read IOPS and between 9,000 and 75,000 4 KB random write IOPS.
The maximum sequential throughput on all AMI types (Linux PV, Linux HVM, and Windows) per second is approximately 2 GB read and 1.1 GB write.
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.
High I/O instances use an 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 high I/O instance is 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 depth (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. High I/O instances 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 high I/O instances at this time. We hope to add TRIM support in the future.