Qual é a melhor prática para separar ambientes de produção e teste na AWS?
Posso pensar em 2 opções (vamos supor que meu site se chama: blue-sky.com)
Crie 2 contas da AWS: blue-sky e test-blue-sky (Crie um usuário de teste na conta de teste e um usuário de produção na conta de produção).
Crie 1 conta da AWS: blue-sky. Crie 2 usuários, produção e teste. O usuário de teste tem acesso aos servidores de teste e o usuário de produção tem acesso aos servidores de produção.
Qual é melhor? Alguma abordagem alternativa?
Ambos os cenários acima têm a mesma desvantagem. Digamos que nosso gerente de versão tenha acesso ao servidor de teste e de produção. Ele quer explodir um Test Server, pois tem as credenciais para ambos os ambientes, ele faz login por engano com as credenciais do Prod e exclui o Prod Server.
Se você quer fazer certo, dê um passo adiante.
Primeiro sobre suas contas de usuário.
Tenha 3 contas - login , teste e prod . Todos os seus usuários do IAM estão apenas na conta de login e todos têm o MFA habilitado para segurança.
Nas contas de teste e produção , você só tem funções do IAM que podem ser assumidas a partir da conta de login .
Confira Acesso entre contas para obter mais detalhes.
Em seguida, suas implantações.
Não se preocupe em usar credenciais de Prod para teste - suas implantações de Prod devem ser totalmente automatizadas por meio de CI/CD e você nunca precisará fazer login na conta de Prod para fazer implantações manualmente.
Aproveite o CloudFormation junto com o AWS CodePipeline , CodeBuild e CodeDeploy para automatizar suas compilações e implantações. Ou use algumas outras ferramentas como Jenkins , GoCD , etc, não importa, desde que as implantações para Test e Prod sejam feitas a partir do mesmo pipeline de CI/CD.
De fato, haverá casos em Test em que você terá que fazer login no console para testar algo, depurar algo, etc. Mas isso será pregado em Test antes de ser promovido a Prod por meio de sua automação.
Dessa forma, você terá implantações 100% consistentes e replicáveis e não precisará se preocupar em cometer um erro que derrube seu ambiente de produção.
Espero que ajude :)
Resposta geral curta: uma conta por ambiente reduz o risco, reduz as chances de atingir os limites e oferece o melhor isolamento.
--
Resposta mais longa: não há uma resposta para esta pergunta, mas aqui estão algumas opções:
Uma conta por aplicativo por ambiente. Melhor isolamento para cargas de trabalho e usuários, menor risco, menor chance de uma conta de teste atingir o máximo e atingir os limites da AWS. É preciso mais esforço para proteger e monitorar tudo e pode custar mais para a rede.
Uma conta por aplicativo, um ambiente por VPC. Bom isolamento entre aplicativos, mas os aplicativos são vulneráveis a problemas do usuário, limites, etc. Você pode contornar o acesso do usuário com tags e políticas, mas é mais trabalhoso. Mesmo comentário sobre os custos acima, mas um pouco menos.
Uma conta, uma VPC por aplicativo ou por aplicativo por ambiente. Fácil de configurar, requer mais trabalho para fazer um bom isolamento. Risco ainda maior de atingir os limites.
Uma conta, uma VPC, vários aplicativos. Você pode ver para onde isso está indo - maior risco novamente basicamente.
Em todos os cenários, existe o risco de um usuário descuidado excluir o recurso errado. As implantações automatizadas, como sugeridas pelo MLU, são uma maneira de mitigar esse risco.
Qualquer implantação importante em qualquer servidor/nuvem deve ter uma boa estratégia de backup. Algumas regulamentações financeiras exigem que todos os dados armazenados na nuvem sejam armazenados em um segundo local, como no local, em um data center de propriedade da organização. Para minhas próprias implantações pessoais, faço backup no S3 todas as noites, sincronizo o S3 com meu PC e faço um backup incremental que é armazenado fora do local.