Sou um grande fã da AWS em geral ... mas RDS, nem tanto.
O @RolandoMySQLDBA apontou alguns bons pontos contra ele.
A única vantagem que vejo no RDS em comparação ao MySQL no EC2 é a capacidade de apontar e clicar em snapshots, clones e recuperação point-in-time, mas elas não são suficientes para compensar a perda de controle e flexibilidade, e elas certamente não justifica que o preço seja mais alto. O RDS é sexy em alguns aspectos, mas você não pode confiar no que não pode consertar, porque não consegue acessar todas as partes móveis.
Eu não gosto de não ter o SUPERprivilégio. Eu não gosto de não conseguir seguir o log de erros. Não gosto de não poder executar "top" ou "iostat" no meu servidor de banco de dados para ver como os núcleos e as unidades estão aproveitando a carga. Não gosto de não ter acesso ao mecanismo de armazenamento federado. Não gosto de pagar por uma máquina principal de backup em espera (multi-AZ) que nem sequer posso aproveitar como réplica de leitura. Certamente, existem explicações perfeitamente razoáveis para que todas essas restrições tenham que existir para que o MySQL seja empacotado e vendido com sucesso como RDBMS-in-a-box. A única coisa é que o RDBMS-in-a-box "resolve" toda uma série de problemas que não tenho ... e entra no meu caminho, causando novos problemas.
Mas o ponto crucial para mim com o RDS é a completa falta de acesso aos logs binários e à replicação. Os binlogs, especialmente baseados em linhas, são uma ferramenta de recuperação fantástica para desastres menores, mas não ajudam em nada se você não puder acessá-los. Deseja configurar um servidor local no seu escritório como uma réplica de leitura do banco de dados de produção no RDS? Algo para obter backups locais, os relatórios têm em mãos para recuperação de desastres, caso algo impensável aconteça com seus dados que residem no RDS? Essa é uma ideia simultaneamente óbvia e brilhante.
Ops, desculpe, o acesso direto à replicação não está disponível. Claro, você pode pagar por réplicas de leitura ... mas apenas como outras instâncias do RDS. Não é uma proposta de valor no meu livro.
Atualização: Uma mudança significativa no RDS para MySQL 5.6
Eu ainda prefiro executar meu próprio servidor (mesmo no EC2) em vez de executar o RDS por vários motivos, incluindo a falta de suporte a funções definidas pelo usuário , a incapacidade de usar o Federated Storage Engine e a incapacidade de ter o único conexão extra disponível para acesso de emergência ... no entanto ...
A Amazon fez uma alteração significativa no MySQL 5.6 para RDS que elimina uma das minhas principais objeções - talvez a minha maior objeção: os logs binários agora estão acessíveis e você pode executar uma instância não-RDS como escravo ou conectar outros utilitários ao servidor que lê o fluxo binlog.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html
Oficialmente, a documentação indica que eles estão expondo isso para que você possa configurar um escravo com a finalidade de fazer uma migração ao vivo - você sincroniza o futuro servidor mestre estrangeiro da instância RDS existente usando mysqldumpe conecta-o ao RDS como escravo para obter um feed ao vivo de atualizações por meio do fluxo de replicação até que seu aplicativo seja migrado para o novo mestre - mas não oficialmente, você pode fazer isso continuamente, desde que não espere que eles o ajudem ... o que, para mim, parece razoável.
Isso foi confirmado em um webinar recente , em uma conversa que começa por volta das 56:45:
"Você pode mantê-lo em um estado replicado indefinidamente ...
"... desde que você assuma a responsabilidade de manter a replicação ..."
"Não estamos impedindo que você faça replicação contínua, se é isso que você deseja".
Esse novo recurso foi suficiente para que eu deixasse de lado minha objeção geral ao uso do RDS em nossas instâncias do MySQL voltadas para o público, onde não usamos FEDERATEDou algumas das outras coisas tanto ou de maneira alguma.
Portanto, ainda não sou a favor, mas não sou mais contra, pois ter uma transmissão ao vivo dos logs binários me coloca no controle dos dados em tempo real e na responsabilidade de garantir que nenhuma transação seja realizada. perdido em uma interrupção catastrófica está de volta comigo, porque eu, como o DBA, estou de volta ao controle - que é exatamente como eu quero. Ter um fornecedor terceirizado para apontar o dedo ou entrar com uma ação contra, ou o que seja, não recupera os dados perdidos se desaparecerem em um buraco negro dentro de uma caixa preta.
A gerência parece gostar da "idéia" do RDS e não se opõe à diferença de custo; portanto, estamos lançando todos os novos sites com o RDS por trás deles.
A recuperação point-in-time point-and-click, eu admito, é um recurso interessante no RDS ... não altera nem atrapalha sua máquina existente - em vez disso, inicia uma instância totalmente nova, usando o backup que foi mais próximo do ponto selecionado no tempo e, em seguida, aplica os binlogs necessários para levar a nova máquina para o ponto especificado.
Relacionado a isso, mas na outra direção, também é possível, agora, usar uma estratégia semelhante para migrar um banco de dados MySQL ao vivo para o RDS ... você pode conectar um mestre do RDS (presumivelmente, normalmente, esse seria um novo recurso implantado). exemplo) como escravo de um sistema existente para que a instância do RDS tenha a versão ao vivo dos dados no momento em que você migra para ele. Diferentemente do acesso aos binlogs do RDS para replicação externa, que funciona apenas na 5.6, a replicação interna é suportada no RDS, começando com 5.5.33 e 5.6.13.