Database – Best way to migrate a large database from EC2 to RDS MySQL

What does it provide? Quite a lot, if you're not a DBA.

1. Automated snapshots to the second for the previous five minutes (configurable up to 8 days)
2. DB snapshots are automatically scheduled, managed, and stored
3. HA without having to think about it? Sign me up!

As for your additional questions; the RDS DB is persistant, and it's equivalent to setting up an EC2 instance with an Elastic Block Storage (EBS) and storing your database files on it. So yes, you've got a semi-equivalent machine--albeit, you're now responsible for managing backups et al, and scalability will be an issue should you need more machines.

RDS is aimed primarily at people who want to use a database--but don't want to manage it. Perfectly agreeable, and friends and peers I've talked to about Amazon's services in general have smiled on RDS. It costs a bit more, but it also gives you more. You'll just have to weigh how much you like maintaining your database.

You do likely need log_bin_trust_function_creators = 1 on RDS but that isn't the issue, here.

You can specify a DEFINER value other than your own account only if you have the SUPER privilege.

^{— http://dev.mysql.com/doc/refman/5.6/en/stored-programs-security.html}

When a stored program (proc, function, event, or trigger) is running, everything it does has the permissions of the user who defined it, or of the user explicitly stated with a DEFINER declaration. This allows, among other things, for stored programs to permit other users to do things to data they don't directly have permission to manipulate, as long as they have permission to use the stored program itself.

It would be a serious vulnerability, then, if a non-SUPER user could create a procedure with an arbitrary definer, because the user could escalate his or her privileges at will.

This is also true of views, of course, when the definer security context is used, as in the example you posted.

One of the biggest complaints I have with RDS is that you can't have SUPER... and now it can be one of yours, too :) because that fact is the cause of the problem you are having.

Of course, if I were running a managed MySQL service, I wouldn't give anybody SUPER, either, so their security model makes sense, even if it is sometimes unwieldy.

If all of your objects have the same definer, a workaround would be to restore the dump using that account instead of the one you're using now, but that seems unlikely.

Deleting just the line with the DEFINER declaration should make the dumpfile work in cases where it appears on a line by itself, or you could use sed or perl to modify the file... an idea that I already know you're not fond of, but it really is a nice thing about MySQL that such hackery is quite legitimate, and not really all that far afield from the kinds of things I have to do as a DBA even in a non-RDS envirnoment.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

...possibly not the answer you hoped for, but you could run that against your dumpfile and should end up with a slightly more usable file.