Escopo do projeto
Avaliação da aplicação (linguagem, framework, estado em memória, arquivos locais, tarefas agendadas, dependências de sistema operacional). Empacotamento em imagem de contêiner, com separação de configuração e segredos. Escolha entre Amazon ECS com AWS Fargate (padrão para PME, com a plataforma administrada pela AWS) e Amazon EKS (quando o time já opera Kubernetes ou o fornecedor entrega manifestos Kubernetes).
Serviço em duas zonas de disponibilidade atrás de um Application Load Balancer, com verificação de saúde e escala automática por métrica. Pipeline de build e implantação com troca gradual de versão e reversão. Banco em Amazon RDS Multi-AZ (migrado pelo exemplo Banco de dados com AWS DMS quando ainda estiver em servidor próprio). Arquivos locais movidos para Amazon S3 ou Amazon EFS. Observabilidade, alarmes e orçamento com alerta. Operação assistida e transferência de conhecimento.
Desafio e problemas de hoje
- Aplicação de fornecedor ou própria que precisa continuar como está por enquanto, mas precisa sair do servidor sempre ligado.
- "Funciona na minha máquina": ambientes diferentes entre desenvolvimento, homologação e produção.
- Atualização é um evento: janela, plantão, medo de rollback.
- Um servidor só: queda ou patch derruba a aplicação inteira.
- Segredos (senhas de banco, chaves de API) em arquivo de configuração no servidor.
- Equipe pequena, com a operação de cluster fora do alcance.
O ambiente de partida (perfil típico deste exemplo)
| Item | O que costuma existir |
|---|---|
| Aplicação | Monólito ou poucos serviços (Java, .NET, Node.js, PHP ou Python), de 1 a 4 servidores, às vezes já em Docker num servidor só |
| Banco | Relacional em servidor próprio ou Amazon RDS |
| Entrega | Implantação manual por cópia de arquivos ou script; pipeline inexistente ou parcial |
| Configuração | Arquivos de configuração e segredos no servidor; diferenças entre ambientes |
| Dependências | Arquivos locais (uploads, relatórios), tarefas agendadas no servidor, sessão em memória |
| Restrições | Janela de parada inexistente em horário comercial; dados pessoais sob LGPD; fornecedor homologa versões; time com operação compartilhada |
Perfil típico, com faixas, construído a partir de projetos desse tipo. O inventário real é o primeiro entregável do diagnóstico.
Requisitos
- R1Rodar a aplicação com servidor e cluster administrados pela AWS.
- R2Duas zonas de disponibilidade e escala automática por demanda.
- R3Atualizações frequentes com troca gradual de versão e reversão rápida.
- R4Ambientes idênticos (desenvolvimento, homologação, produção) a partir da mesma imagem.
- R5Segredos fora da imagem e fora do servidor, com rotação.
- R6Arquivos e sessão fora do contêiner, para permitir escala e substituição.
- R7Observabilidade por serviço e orçamento com alerta.
O que desenhamos para cada requisito
| Requisito | Decisão de arquitetura | Serviço AWS |
|---|---|---|
| R1 | Tarefas em contêiner com a plataforma administrada pela AWS; cluster gerenciado | Amazon ECS, AWS Fargate (Amazon EKS quando o time já opera Kubernetes) |
| R2 | Serviço com tarefas distribuídas em duas zonas, atrás de balanceador com verificação de saúde; escala por CPU, memória ou requisições | Elastic Load Balancing (Application Load Balancer), Amazon ECS |
| R3 | Pipeline que constrói a imagem, publica no registro e implanta com troca gradual; reversão para a imagem anterior | Amazon ECR, AWS CodePipeline e AWS CodeBuild (ou pipeline do repositório da empresa) |
| R4 | Uma imagem por versão, promovida entre ambientes; configuração por variável de ambiente | Amazon ECR, AWS Systems Manager Parameter Store |
| R5 | Segredos injetados em tempo de execução, com rotação e acesso por função | AWS Secrets Manager, AWS Identity and Access Management (IAM) |
| R6 | Uploads e relatórios em armazenamento de objetos ou sistema de arquivos compartilhado; sessão em cache gerenciado quando necessário | Amazon S3, Amazon EFS, Amazon ElastiCache (opcional) |
| R7 | Logs por tarefa, métricas por serviço, alarmes e painel; orçamento mensal com alerta | Amazon CloudWatch, AWS Budgets |
Arquitetura
Componentes e fluxos deste diagrama
- Usuários: acesso por HTTPS ao Elastic Load Balancing (Application Load Balancer).
- Elastic Load Balancing: distribui as requisições para as tarefas em cada zona de disponibilidade.
- Amazon ECS: orquestra as tarefas do AWS Fargate nas zonas A e B; recebe as imagens do Amazon ECR.
- AWS Fargate (tarefas), zonas A e B: rodam a aplicação; recebem segredos do AWS Secrets Manager em tempo de execução.
- Amazon RDS primário (zona A) e Amazon RDS em espera (zona B): dados das tarefas, com réplica síncrona entre os dois.
- Amazon S3: arquivos gravados pelas tarefas.
- Amazon CloudWatch: logs e métricas do Amazon ECS.
Ganhos: o que medimos no projeto
| Indicador | Como medimos | O que muda |
|---|---|---|
| Servidores e clusters a administrar | Contagem de hosts com sistema operacional sob responsabilidade do time | De servidores sempre ligados para zero hosts administrados |
| Frequência e duração da atualização | Implantações por semana, minutos de implantação, tempo de reversão | De evento com plantão para troca gradual de versão com reversão rápida |
| Disponibilidade na troca de versão e no patch | Erros durante implantações e durante manutenção da plataforma | De parada a cada atualização para implantação com a aplicação no ar |
| Paridade entre ambientes | Incidentes causados por diferença de ambiente | De "funciona na minha máquina" para a mesma imagem nos três ambientes |
| Segredos expostos | Segredos em arquivo ou repositório encontrados em varredura | De senha em arquivo para segredo gerenciado com rotação |
| Custo por demanda | Tarefas em execução por hora do dia e parcela da fatura que varia | De servidor fixo para capacidade que acompanha o uso |
Indicadores de um projeto típico, medidos no próprio projeto: resultado típico, não garantia.
Escopo e entregáveis por fase
| Fase | O que acontece | Entregáveis | Duração |
|---|---|---|---|
| 1. Avaliação | Dependências, estado, arquivos, tarefas agendadas, escolha ECS ou EKS, plano de empacotamento | Relatório de avaliação, arquitetura alvo, plano de transição | 1 semana |
| 2. Empacotamento e fundação | Imagem de contêiner, registro, segredos, parâmetros, cluster, balanceador, rede em duas zonas, observabilidade | Imagem publicada, ambiente de desenvolvimento em contêiner, painéis e alarmes | de 2 a 3 semanas |
| 3. Pipeline e homologação | Pipeline de build e implantação, promoção entre ambientes, testes com o fornecedor ou o time | Pipeline funcionando, homologação aprovada | de 1 a 3 semanas |
| 4. Produção e operação assistida | Virada do tráfego para o novo ambiente, escala automática, ajuste de tamanho, documentação, transferência para o time, desligamento do servidor antigo | Aplicação em produção em duas zonas, runbook, documentação, relatório de ajuste | de 2 a 4 semanas |
Durações típicas, em faixa. O plano do projeto fixa as datas reais.
Algo a mais: Amazon ECS ou Amazon EKS, como escolhemos
| Critério | Amazon ECS com AWS Fargate | Amazon EKS |
|---|---|---|
| Quem opera | A AWS administra a plataforma; o cluster fica por conta do serviço | Kubernetes gerenciado; o time ou a RFX administra o que roda dentro |
| Quando faz sentido | A maioria das PMEs, aplicação própria ou de fornecedor em Docker | Time já opera Kubernetes, fornecedor entrega manifestos Kubernetes, múltiplos times |
| O que fica igual | Pipeline, registro de imagens, segredos, observabilidade, orçamento | Pipeline, registro de imagens, segredos, observabilidade, orçamento |
Na dúvida, começamos pelo Amazon ECS com AWS Fargate; a imagem é a mesma e a mudança para EKS, se um dia fizer sentido, preserva a aplicação como está.
Perguntas frequentes deste exemplo
Em geral, a aplicação segue como está. O que muda é como ela é empacotada, configurada e entregue. Pontos de atenção são estado em memória, arquivos locais e tarefas agendadas, tratados na avaliação.
Com Amazon ECS e AWS Fargate, a plataforma fica com a AWS. O Amazon EKS entra quando o time já opera Kubernetes ou o fornecedor exige.
Precisa homologar a versão em contêiner. Envolvemos o fornecedor desde a avaliação; muitos já entregam imagem Docker.
Em Amazon RDS Multi-AZ. Se ainda estiver em servidor próprio, a migração segue o exemplo Banco de dados com AWS DMS, feita antes ou junto.
Viram tarefas agendadas do próprio Amazon ECS ou funções AWS Lambda disparadas pelo Amazon EventBridge, fora do contêiner da aplicação.
Serviços AWS deste exemplo
- Amazon ECS
- AWS Fargate
- Amazon ECR
- Elastic Load Balancing (Application Load Balancer)
- AWS CodePipeline
- AWS CodeBuild
- AWS Systems Manager Parameter Store
- AWS Secrets Manager
- AWS Identity and Access Management (IAM)
- Amazon RDS
- Amazon S3
- Amazon EFS
- Amazon CloudWatch
- AWS Budgets
- Amazon VPC
- Amazon EKS (variante)
- Amazon ElastiCache (opcional)
Incentivos AWS
A RFX busca para o projeto os programas de incentivo e créditos da AWS aplicáveis, sempre sujeitos a aprovação da AWS.