The long and short of it is that you do not have an account with super access (you can't perform normal actions like killing threads, viewing processlists, change variables, etc). You instead have to use special stored procedures to perform basic administrative functions.

Also, you can't take advantage of replication (aside from their own read replicas within other RDS instances) or binary backups. Anything that requires access to the machine itself is impossible except through Amazon's support channels.

Its gotten better than it was, but it's still a headache to monitor and manage as a DBA.

For MySQL RDS instances, it's most certainly possible to do offsite asynchronous replication without the use of read replicas, as described in their documentation here: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL....

The guide does mention using a read replica to replicate from, an intermediate RDS instance between your offsite, but I've had no trouble replicating directly from the master instance.

One thing they don't cover is replication over SSL. AWS has failed to mention this shortcoming in the docs last time I checked. To have MySQL replicate over SSL, the master and slave both need an SSL certificate signed by the same CA, which would require you to obtain a cert+key signed by the AWS RDS CA.

Of course you have the option of tunneling the replication connection into a haproxy or stunnel running on an ec2 instance, but that has it's other shortcomings. You can't use the ELBs, since you can't register the RDS instance with an ELB.

Am I missing something or not following correctly? You can view processlist and kill queries like normal and you can edit variables via their control panel. I'd assume you can't edit every variable