AWS is built on commodity hardware and it is software virtual machine based. AWS documentation states that:

It's inevitable that EC2 instances will fail, and you need to plan for it.

As a rule of thumb, you should be a pessimist when designing architecture for the cloud.

That means that putting your Oracle databases on AWS cloud should be accompanied with carefully thought out fault tolerance and DR procedures.

It is likely that:

1. An AWS instance running Oracle database will fail
   
2. Some of volumes ( EBS storage ) attached to an instance running Oracle database will fail, i.e., you will lose access to your instance and data at some point.

Usual practice of performing Oracle database backups should be carefully implemented and monitored. Databases can be backed up efficiently and conveniently to AWS S3 disk based storage using RMAN/S3 MML interface. This includes lower, non-production environments, to reduce rebuild time and preserve database side structures - tables and stored procedures.

File system configuration and Oracle database configuration should be recorded and stored safely away to serve as a starting point for server rebuild. Adding new EBS volumes should be done via a command tool that will automatically append volume creation command to volume recreation script. This script will be executed first when volumes need to be rebuilt.

Oracle configuration files ( spfile, listener.ora, OraInventory directory ) and Oracle binaries should be backed up daily via EBS snapshots. Oracle binaries can be restored either via recreation from AMI or by using EBS snapshots.  Database itself can then be restored either from the latest RMAN/S3 backup or from hot backup stored as an EBS snapshot.

Production databases that can not afford restore downtime need to have DR ( physical standby database ) set up. AWS also recommends taking periodic EBS snapshots to increase volume durability. Be sure to put database in hot backup mode (begin backup) before taking snapshots of EBS volumes containing Oracle datafiles. These snapshots can be used as a secondary recovery method.

Use AWS Elastic IPs so that IP addresses can be easily reassigned to newly started instance on instance failure.

According to AWS using custom-made RAID solutions on top of EBS is not of much help and should not be considered.

All database restore scripts should be ready and tested, as well as DR switchover/failover scripts and procedures for mission-critical databases. Monitoring should be in place to periodically check for  instance and storage health and to alert on failure.