MySQL on RDS has its pros and cons. Only your organization can decide if the solution meets your needs. Migrating from a traditonal MySQL database to RDS may not be a simple task.
WARNING: As with many AWS services, RDS is evolving at a rapid pace. Please verify my statements before making any important decisions.
Given the backup, failover and scaling capabilities of RDS, smaller organizations might postpone the inevitable hiring of an expensive, full time DBA
Multi-Zone RDS provides automatic failover between zones within a few minutes, which is acceptable to most small businesses.
Storage, instance extension
Cloudwatch, graphs, etc.
Databases don’t run themselves.
At a certain stage of growth, the performance, storage and management needs of your database will exceed the abilities of your development team.
If you choose RDS now to postpone hiring a DBA for 6months, prepare for the eventual necessity of migrating back to a native mysql implementation next year.
Advanced diagnostic functionality my be buried with the RDS API, which could hinder an experienced DBA who is comfortable with traditional unix tools such as netstat, df, iostat, tcpdump, lsof, sar, etc.
DNS, DNS everywhere!
The RDS high availability model (similar to other AWS offerings) is implemented with DNS. Mysql client connect strings must be resolved to their RDS hostnames (db-name.customerid.us-west-1.rds.amazonaws.com:3306). This introduces the overhead of performing a lookup but also an additional point of failure; the availability and performance of amazonaws.com DNS !
At this time, region->region replication is NOT supported by Mysql on RDS.
Nor is logshipping. zone->zone replication is supported by Multi-AZ internally for inter-zone failover, and read slaves are provided per availability zone to offload read-only queries.
Major modifications to your app may be costly or time prohibitive. You won’t know if your code works until you test it.
LOAD DATA INFILE workarounds
– Federated tables