Recentemente atuei em uma migração de serviços do Azure para AWS, o objetivo era migrar WebApps(Azure) para o k8s(AWS), incluindo banco de dados gateway e outros serviços que envolviam as apps.

Não é um tarefa trivial, existem algumas diferenças relevantes entre as 2 clouds, desde KeyVault, Gateway até banco de dados, a ideia é comentar um pouco sobre os bancos que inclusive foi o principal motivador para não migrar os serviços.

O primeiro ponto de atenção sobre os bancos de dados foi referente ao modelo de contratação, nossas instâncias de banco de dados no azure são contratadas por DTUs e infelizmente não temos um modelo de contratação equivalente na AWS para SQL Server, existe o Amazon Aurora, porém seria necessário migrar os bancos que atualmente são SQL Server, por esse motivo o Aurora foi descartado.

O cenário ideal seria ter a mesma experiência que temos na cloud do azure, na AWS.

O primeiro passo foi tentar entender como funciona o modelo de contratação por DTUs e encontrar o equivalente a memória e processamento, me deparei com essa documentação da microsoft, que deixou claro que essa conta não seria tão fácil.

O segundo passo foi procurar por alguma maneira de converter o modelo de contratação por DTUs para vCore(ainda Azure), e encontrei esse script SQL que ajudou demais.

Com o resultado desse script para todas as bases consegui ter uma ideia de quais recursos seriam necessários na AWS para fazer essa migração de forma segura, mesmo com os resultados em vCore, foi possível extrair qual seria o tier equivalente em relação a memória e CPU(com certeza não seria tão assertivo, mas ajudou muito).

Ao comparar com o AWS RDS nos deparamos com uma questão que era muito importante para o negócio, um requisito para manter todas as certificações que a empresa possui é manter todos os dados em um banco criptografado, o que inviabiliza utilizar a licença web, a partir dessa restrição identificamos um grande problema, pois qualquer outra licença que não fosse web tornaria esse custo extremamente elevado.

Como se trata de uma migração de todos os serviços, a soma passaria de 100k/mês, o que anteriormente era pouco mais que 20k, isso considerando reservas no RDS e perdendo algo muito importante, hoje usando o Azure SQL Server nós temos a possibilidade de escalar os bancos praticamente em tempo real, o que seria impossível no RDS, a unica opção seria usando Aurora, que obrigaria a migração de mais de 20 bases.

Após avaliar tudo isso, nosso cenário foi:

Azure

• 20k;
• Escala de DTUs em tempo real;

AWS

• 100k+;
• Sem possibilidade de escalar os serviços em tempo real;

Para escalar o RDS SQL é necessário reiniciar o banco(acredito que ele use uma EC2).

Devido a essa grande diferença de valores e menos recursos, a decisão foi por não migrar os serviços para AWS e continuar no Azure, implementando o k8s ao invés de WebApps.

PS: Existe uma possibilidade na AWS que é o babelfish, porém na propria AWS ele é um recuso utilizado para processos de migração, e não como uma solução permanente, por isso decidimos seguir a recomendação e não utilizamos(já que não fariamos a migração posteriormente).