AWS PIOPS SSD backed

The question of what the technology backing EBS Provisioned IOPS volumes comes up often.  PIOPS volumes are backed by Solid-State Drives (SSDs), Provisioned IOPS volumes support up to 30 IOPS per GB which enables you to provision 4000 IOPS on a volume as small as 134 GB. 

More details here:
https://aws.amazon.com/ebs/details/

Redshift cluster sizes

100 nodes maximum for each configuration.

Dense Storage (DW1) nodes are available in two sizes.   These are HDD backed instances.

A. The Extra Large has three HDDs with a total of 2TB of magnetic storage. Maximum of 200 TB of storage.

B. The Eight Extra Large has 24 HDDs with a total of 16TB of magnetic storage. Maximum of 1.6 Pedabyte of storage. 

Dense Compute (DW2) nodes are also available in two sizes.  These are SSD back instances.

A. The Large has 160GB of SSD storage per EC2 instance with a maximum is 1.6 TB

B The Eight Extra Large is sixteen times bigger (then the dense compute large) with 2.56TB of SSD storage on the EC2 instance for a maximum of 256TB of SSD storage.

SAP HANA on AWS

There are two offerings for running SAP HANA on AWS

1. AWS Marketplace : https://aws.amazon.com/marketplace/pp/B009KA3CRY. This runs on the Cluster Compute 8XL (cc2.8xlarge) instance type with 60.5 GB of memory. This includes the SAP HANA One licenses. 

2. SAP Cloud Appliance Library (CAL) : http://marketplace.saphana.com/New/SAP-HANA-%3A-infrastructure-subscription-by-AWS/p/1871. This uses a AWS CloudFormation template to deploy a cr1.8xlarge cluster compute instance (244 GB of memory and 240 GB of SSD instance storage) with Amazon PIOPS volumes.

Oracle Database on SSD

New options for running the Oracle Database on EC2 using SSD storage for your database. The I2 instances feature the latest generation of Intel Ivy Bridge processors - each virtual CPU (vCPU) is a hardware hyperthread from an Intel Xeon E5-2670 v2 (Ivy Bridge) processor. I2 instances are available in four sizes as listed in the table below. Instance Type vCPUs ECU Rating Memory (GiB) Instance Storage SSD (GB) Note           i2.xlarge 4 14 30.5 1 x 800 800 GB of SSD i2.2xlarge 8 27 61 2 x 800 1.6 TB of SSD i2.4xlarge 16 53 122 4 x 800 3.2 TB of SSD. hi.4xlarge with 2 TB  of SSD was previously largest SSD instance type i2.8xlarge 32 104 244 8 x 800 6.4 TB of SSD The i2.8xlarge instance size is capable of providing over 365,000 4 kilobyte (KB) random read IOPS and over 315,000 4 KB random write IOPS.   Great for Oracle databases that have high IO requirements.  This document has more on configuring Oracle Databases on EC2 and using SSD based instances : http://cloudconclave.blogspot.com/2013/11/aws-database-reference-implementation.html

Data stores compatible with Amazon EMR

There are a number of different file systems that can be used

1. Hadoop Distributed File System (HDFS) : EC2 local/ephemeral disk is where HDFS  resides.  The obvious disadvantage is that it’s ephemeral storage which is reclaimed when the cluster ends. It can be used for caching the results produced by intermediate job-flow steps during a large EMR job.
2. Local (ephemeral) EC2 disk :  Each EMR node comes with local disk.  This disk works well for temporary storage of data that is continually changing, such as buffers, caches, scratch data, and other temporary content.
3. S3 native : Used for input (data set to be reduced) and output/results.
4. S3 block : Stay away from as not as performant as the other options.
5. HBase : HBase is an open source, non-relational, distributed database that runs on top of HDFS.  HBase works with Hadoop/EMR, sharing its file system and serving as a direct input and output to EMR jobs. HBase also integrates with Apache Hive, enabling SQL-like queries over HBase tables, joins with Hive-based tables, and support for Java Database Connectivity (JDBC).

More information here:
http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-file-systems.html

Oracle Database on ephemeral drives

Using EC2 ephemeral storage (either disk or SSD) is a way to achieve higher IO throughput.
You could use the design pattern Redshift uses (these use the HS1.* instances which have similar storage characteristics to the hi1.4xlarge instances) - "the first line of defense consists of two replicated copies of your data, spread out over up to 24 drives on different nodes within your data warehouse cluster".  This includes:

  1.  All data written to a node in your cluster is automatically replicated to other nodes within the cluster
  2.  All data is continuously backed up to Amazon S3

Oracle on SSD as it is recommendation to get highest level of IO when running Oracle on EC2.

SSD for Oracle Databases

Here are a couple of articles/web site with the pros and cons of running your Oracle database on SSD:

http://www.pythian.com/blog/de-confusing-ssd-for-oracle-databases/
http://www.slideshare.net/gwenshap/ssd-collab13

If your Oracle database is less than 2 TB you could run it on the  hi1.4xlarge instance type.  This instance type has  2 SSD-based volumes each with 1024 GB of instance storage.  More on AWS instance types here: http://aws.amazon.com/ec2/instance-types/

You could also just use Oracle RDS on AWS.  With PIOPS for RDS, you can get up to 25K IOPS on your Oracle database. 
Instagram uses SSD : http://m.cio.com/article/716829/SSDs_Boost_Instagram_39_s_Speed_on_Amazon_EC2