Na minha experiência e com base em sua popularidade, os volumes do EBS não são lentos para a maioria dos aplicativos (incluindo o MySQL), especialmente se você estiver usando uma instância do EC2 que tenha alta largura de banda de E / S.
As instâncias t1.micro têm largura de banda de IO "baixa", mas ainda me pergunto se você está realmente com problemas de desempenho. Você tem métricas no iowait que mostram que esse é o problema?
Eu suspeito que é mais provável que o tipo de instância t1.micro não consiga sustentar atividades pesadas da CPU, como aquelas que podem ser necessárias em seu aplicativo.
Eu uso o t1.micro com o MySQL / Apache / etc. para sites dinâmicos que quase não têm usuários e funciona bem, mas assim que você acumula em qualquer tipo de carga sustentada, ele é cortado conforme projetado.
Dado o pequeno tamanho de memória de t1.micro, o MySQL não conseguirá armazenar em cache grande parte das tabelas de banco de dados na memória, assim você pode ser atingido por sua necessidade de continuar indo ao disco para obter resultados. Isso seria um problema, não importando o quão rápido EBS IO é, porque ele nunca será tão rápido quanto o acesso direto à memória.
Se você ainda acha que é um problema do EBS, você pode tentar adicionar uma camada de cache para fazer menos visitas ao banco de dados MySQL. No entanto, você vai rapidamente se deparar com o limite de memória no t1.micro. Talvez dê uma olhada no novo serviço ElastiCache da AWS: link
Se o t1.micro IO for o fator limitante, você não o corrigirá com o RAID, pois todos os volumes do EBS no RAID estarão usando o mesmo canal de E / S juntos.