Solucionado
Olá a todos, como mantenho as informações da ec2, se em cada codedeploy eu mato a instancia anterior? É muito ruim ficar adicionando novos id no dashborad a cada deploy, fora que ao longo do tempo não é viável. Exemplo: evolução da CPU conforme deploy.
Olá Guilherme, tudo bem? Nesse ponto temos algumas coisas pra analisar, porque é preciso destruir a máquina em toda atualização que você implementar? Realmente não é muito viável isso, porque a maneira mais adequada seria criar backup ou então criar snapshots da máquina, porém ambos vão ficar consumindo discos, o que não é tão barato pensando que você vai ter muitas versões. Nesse ponto não seria melhor utilizar um outro serviço? Talvez o AWS ECS (EC2 Container Service), que usa por baixo dos panos máquinas EC2 para criar e executar containers, assim seria mais fácil, ou então o AWS Elastic Beanstalk que também abstrai toda essa parte da EC2 mais é muito mais tranquilo o gerenciamento e a utilização de várias versões, e centralizando outras coisas como banco de dados em um serviço como o RDS e para arquivos usar o S3. Mas você poderia falar um pouco mais sobre o seu problema pra gente poder ajudar da melhor forma possível!
Fico aguardando retorno!
Obrigado pela atenção Jonilson, hoje tenho um ambiente "artesanal" utilizando a EC2 como data center (banco, app, domínio e deploy gradativo sobre o IIS).
Mantenho um base line do ambiente que facilita resolução de problemas ou aumento de hardware, ou escala.
Da forma atual está funcionando, mas estou tentado utilizar mais os recursos da AWS. Notei que utilizando o autoscalling, codedeploy ou Ec2spots a máquina anterior morre após a máquina nova estiver saudável e com isso perdendo o gráfico de memória já montado porque agora quem está atendendo é outro id-instance.
Assim sendo, minha dúvida é, como manter um baseline do ambiente para resolução de problemas nessas condições?
Como saber o comportamento da v1 comparado com o da v2?
Talvez esteja focado muito no cloudwatch e para monitora esse ambiente de máquina tenha que usa outra mentalidade/recursos.
É complicado já que não tem a máquina em execução, e fica muito restrito aos números e analises do Cloudwatch, acho que como sua base está começando a ficar mais completa, acho que a resolução de problemas seria bem melhor se você dividisse as responsabilidades, é algo quem vem muito da programação mas que funciona bem em outros contextos como é o seu, como falei no meu outro post, seria melhor usar mais serviços da AWS e dividir as responsabilidades, usando um banco de dados no RDS fica mais tranquilo controlar e resolver os problemas relacionados ao banco de dados, usando o S3 para armazenamento de arquivos e ou backups fica mais fácil identificar e ou ir removendo arquivos antigos para gerenciar melhor e trabalhar com os arquivos mais recentes e ainda economizar (financeiramente), e ter a máquina EC2 apenas com a aplicação ou ainda utilizar containers acho que para esse contexto de resolução de problemas, container seria uma solução ideial, qualquer problema, você poderia subir rapidamente outro container novo com a aplicação funcionando corretamente e então acessar o container que houve o problema e poder identificar e resolver o problema caso apareça novamente. Penso que seja a melhor abordagem.