Configuring your own MySQL cluster (with replication in multi regions) will be time consuming, costly, and require expert advice to help setup and maintain. Having said that it can be more reliable than the current RDS solution (only if you've done it properly) as it could survive a whole region failure.
If you really need 100% uptime then rolling your own solution is an option you should look at. Do you have the money, time and resources to do so? Can you afford to invest the thousands and thousands of dollars or would it be cheaper to possibly have a little bit of down time?
RDS has suffered issues before (as recently as 2012). Interestingly the following site reports that this risk could be greatly minimised by using the "Point-in-Time Restore option"...
http://www.networkworld.com/news/2012/102312-amazon-outage-263617.html
Like with the EBS issue, AWS reminded customers that if they enabled
Point-in-Time Restore option, then they could launch a new database
instances using a backup of the impacted database in another
availability zone.
Another option could be to simply make sure you have access to your backups. For example if you have daily backups you might send those to S3 for easy access (or maybe outside Amazon once a week if you're paranoid). In the event of an EBS/RDS failure you might be able to create a new RDS instance and restore it quicker from S3 in the case that RDS has some serious issues. This solution assumes you're okay with a few hours of downtime in favor of not having to do lots of work engineering some crazy cross region solution.
Finally, depending on your application it might be cheaper to try and take advantage of an non-relational database. I know you've stated that you need a relational DB, however re-engineering some or all of your application to use a non-relational DB may be easier & cheaper then rolling your own MySQL across multi-regions (non-relational also give you other benefits around scale etc). This solution isn't for everyone, and may be in the too hard basket for you (however future projects might be easier to implement this way!).