AWS 'Exalytics' on AWS

Exalytics is YAOES (Yet Another Oracle Engineered System). 
https://blogs.oracle.com/emeapartnerbiepm/entry/lastest_bic2g_and_exalytics_demonstration

This web page mentions: The Business Intelligence Challenge to Go (BIC2g) is a demonstration, training, and POC business intelligence platform for Oracle Partners. It is a comprehensive platform, containing the full EPM, BI, and BI Apps (including full ETL with DW) product suites, with extensive (40+) demos. It is available in the Amazon Cloud (not as a download).

This demonstration is actually the test drive for OBIEE (which is the core software stack on the Exalytics machine) on the AWS web site here :

http://aws.amazon.com/solutions/global-solution-providers/oracle/labs/#Oracle_Fusion_Middleware

Importing on premise Oracle Database into AWS RDS

There is an article here but does not get into specifics on the performance of each option. http://aws.amazon.com/articles/4173109646282306

Oracle data pump is one of the fastest ways to move data between Oracle databases.  However, the approach shown in the above article uses database links which can be very slow.  A more performant method would be to use data pump file mode. Unfortunately, AWS Oracle RDS does not off access to the OS.  There is a workaround to this by using a little known feature of the Oracle database called Oracle Managed File System

http://docs.oracle.com/cd/B13789_01/server.101/b10739/omf.htm#i1006122

Oracle RDS has access to this Oracle Managed File (OMF) system. Once the file exported from the on premise database and moved to the Oracle RDS OMF you can use the  UTL_FILE capability in the database and import a file into the RDS instance, and then do impdb (data pump import) from there.

Things to keep in mind:

1.       Since the file sits on the Oracle managed file system, it consumes the space allocated for the database. So you will need to make sure you allocate enough space for the instance

2.       Once you do the impdb operation, you can delete the file but till then it will consume space on the instance

3.       File sizes will need to be less than 400-500 GB since the largest instance currently is 1 TB, and you will need space for both the file as well as the database

4.       As you do the import, you will consume IOPS for reading the dump file and then writing to the database.

AWS shared disk options

Here the four options most often discussed when considering NAS/shared disk/storage on AWS:

1. S3 : Sometimes NAS isn't the right solution to the problem; it's just something that's relatively easy to implement.
2. GlusterFS, Lustre, openAFS : implementation of a distributed filesystem (GlusterFS, Lustre, openAFS, etc).  Write performance can be below writing to EBS.
3. S3-back 'filesystem' : Use a S3-backed "filesystem" (such as s3fs or Danilo's yas3fs), which is definitely easier to implement. However, write performance could become an issue.
4. NFS : You could just run NFS on another EC2 instances. However, this will not provide the fault tolerance and scalability that is built into a solution such as GlusterFS, or a solution such a Zadara. With Zadara you can have a central repository/shared file system in a NFS mount that will be accesible from EC2 machines.  You can mount Zadara from EC2 via NFS or iSCSI.
5. Of course, when you are running an Oracle database you will probably not use one of these options.  This would be like putting your on premise Oracle database storage on NFS.