Escopo do projeto
Leitura da curva de uso, hora a hora, dos últimos 30 a 90 dias, depois do rightsizing, para o compromisso nascer sobre o tamanho certo. Identificação da base estável por família e região, e das cargas que toleram interrupção (processamento noturno, filas, pipelines, dev, teste).
Recomendações de Savings Plans do AWS Cost Explorer (Compute Savings Plans para flexibilidade entre Amazon EC2, AWS Fargate e AWS Lambda; EC2 Instance Savings Plans quando a família é fixa) e de instâncias reservadas para Amazon RDS, com prazo de 1 ou 3 anos e forma de pagamento definidos com o financeiro. Compra escalonada: parte agora, parte após 30 dias de observação, para o compromisso ficar abaixo da base.
Spot: grupos do Amazon EC2 Auto Scaling com diversificação de tipos e estratégia de alocação adequada, tratamento do aviso de interrupção, e AWS Batch para lote. Orçamentos de cobertura e utilização no AWS Budgets para avisar quando o compromisso ficar sobrando ou faltando. Termina com os itens Compromisso e Spot na rotina mensal.
Desafio e problemas de hoje
- Tudo é pago sob demanda há anos, inclusive o banco que fica ligado o tempo todo.
- Já tentaram comprar reserva uma vez, erraram o tamanho e o compromisso sobrou; o trauma travou novas compras.
- Processamento noturno roda em servidor fixo que fica ligado o dia inteiro esperando a noite.
- Ninguém sabe qual parte do uso é estável e qual é pico.
- A decisão envolve o financeiro (prazo, pagamento) e a TI (família, região), e os dois ainda vão sentar juntos.
O ambiente de partida (perfil típico deste exemplo)
| Item | O que costuma existir |
|---|---|
| Base estável | De 5 a 30 instâncias Amazon EC2 e de 1 a 4 instâncias Amazon RDS ligadas 24x7 há mais de 6 meses, tudo sob demanda |
| Variação | Picos previsíveis (fechamento, campanha) e aleatórios, hoje cobertos pelo mesmo sob demanda |
| Lote e filas | Processamento noturno, integrações, geração de relatórios, em servidor fixo |
| Dev e teste | Ambientes que podem ser recriados, mas rodam em sob demanda fixo |
| Cobertura atual | Nenhum Savings Plans e nenhuma instância reservada; ou compromissos antigos vencidos ou mal dimensionados |
| Restrições | Financeiro quer previsibilidade e evita pagamento antecipado grande; TI teme travar família errada |
Perfil típico, com faixas. O retrato real da sua conta é o primeiro entregável do diagnóstico FinOps.
Requisitos
- R1Compromisso dimensionado sobre a base estável medida, abaixo do pico, e só depois do rightsizing.
- R2Flexibilidade preservada onde a arquitetura ainda pode mudar (família, região, contêiner, serverless).
- R3Prazo e forma de pagamento decididos com o financeiro, com simulação de fluxo de caixa.
- R4Spot só para carga que tolera interrupção, com tratamento do aviso e fallback para sob demanda.
- R5Alerta automático quando a cobertura ou a utilização do compromisso sair da faixa.
- R6Compra escalonada, revisada a cada 30 dias no primeiro trimestre.
O que desenhamos para cada requisito
| Requisito | Decisão de arquitetura | Serviço AWS |
|---|---|---|
| R1 | Curva horária de 30 a 90 dias; base = percentil baixo sustentado; recomendações nativas como ponto de partida, validadas contra o plano de mudanças | AWS Cost Explorer (recomendações de Savings Plans e instâncias reservadas) |
| R2 | Compute Savings Plans para a parte que pode virar Fargate ou Lambda; EC2 Instance Savings Plans só para família fixa; instâncias reservadas do RDS por motor e classe, comparadas com Database Savings Plans quando o banco ainda pode mudar de motor ou família | Savings Plans (Compute, EC2 Instance e Database), Amazon RDS (instâncias reservadas) |
| R3 | Simulação de 1 ano e 3 anos, sem pagamento antecipado, parcial e total, apresentada ao financeiro; decisão registrada | AWS Cost Explorer, planilha RFX |
| R4 | Grupos de Auto Scaling mistos com vários tipos de instância, estratégia de alocação orientada a capacidade, rebalanceamento e aviso de interrupção tratado; AWS Batch para lote com fila Spot e fallback | Amazon EC2 Auto Scaling, instâncias Spot do Amazon EC2, AWS Batch |
| R5 | Orçamentos de cobertura e de utilização de Savings Plans e de instâncias reservadas com alerta por e-mail e Amazon SNS | AWS Budgets, Amazon SNS |
| R6 | Primeira compra cobrindo parte da base; segunda após 30 dias; revisão mensal na rotina | AWS Cost Explorer |
Arquitetura
Componentes e fluxos deste diagrama
- Nuvem AWS, grupo Base estável (Savings Plans e instâncias reservadas): Amazon EC2, AWS Fargate, AWS Lambda e Amazon RDS.
- Grupo Variação (sob demanda): Amazon EC2.
- Grupo Interrompível (Spot): Amazon EC2 Auto Scaling e AWS Batch.
- Fora da nuvem: Equipe RFX e Financeiro.
- AWS Cost Explorer envia a curva de uso à Equipe RFX.
- Equipe RFX decide a compra junto com o Financeiro (prazo e pagamento).
- Savings Plans aplica o desconto sobre a base estável.
- AWS Budgets envia alertas de cobertura e utilização à Equipe RFX.
As três camadas
Base estável
O que fica ligado o tempo todo; compra com compromisso, em troca de desconto sobre o preço sob demanda.
- Savings Plans para Amazon EC2, AWS Fargate e AWS Lambda.
- Instâncias reservadas do Amazon RDS.
Variação
Picos e oscilações do dia; fica sob demanda.
- Amazon EC2 sob demanda.
Interrompível
Lote, filas, desenvolvimento e teste; roda em Spot, em troca de aceitar interrupção com aviso curto.
- Instâncias Spot do Amazon EC2 com Amazon EC2 Auto Scaling.
- AWS Batch para lote.
Ganhos: o que medimos no projeto
| Indicador | Como medimos | O que muda |
|---|---|---|
| Cobertura de Savings Plans e instâncias reservadas | Parcela do uso elegível coberta por compromisso, relatório do AWS Cost Explorer | De zero cobertura para a faixa combinada com o financeiro, sem sobra |
| Utilização do compromisso | Parcela do compromisso efetivamente usada, no mesmo relatório | Compromisso sem sobra: utilização próxima do total é o alvo |
| Custo mensal de computação por camada | Cost Explorer filtrado por opção de compra (sob demanda, Savings Plans, reservada, Spot) | De tudo sob demanda para base em compromisso, lote em Spot e sob demanda só na variação |
| Horas de Spot e taxa de interrupção | Métricas dos grupos de Auto Scaling e do AWS Batch | Lote e dev rodando em Spot com interrupções tratadas, sem falha de negócio |
| Alertas de cobertura e utilização tratados | Alertas do AWS Budgets com resposta registrada | De compra esquecida para revisão mensal com dono |
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. Curva de uso | Leitura horária, identificação da base e das cargas interrompíveis, mapa de mudanças previstas | Mapa das três camadas por família e região | Semana 1 |
| 2. Decisão com o financeiro | Simulação de prazos e pagamentos, escolha de Compute ou EC2 Instance, instâncias reservadas do RDS | Plano de compra escalonado, aprovado pelo financeiro | Semana 2 |
| 3. Spot e primeira compra | Auto Scaling misto, AWS Batch, primeira tranche de Savings Plans e reservas, orçamentos de cobertura | Lote, dev e teste em Spot; cobertura inicial ativa | Semanas 3 e 4 |
| 4. Segunda tranche | Releitura da curva, complemento do compromisso, ajuste de alertas, entrega da rotina ao time do cliente | Cobertura na faixa combinada; itens Compromisso e Spot na rotina | Após 30 dias de observação |
Durações típicas, em faixa. O plano do projeto fixa as datas reais.
Algo a mais: compromisso que acompanha a modernização
Como o Compute Savings Plans vale para Amazon EC2, AWS Fargate e AWS Lambda, o compromisso continua útil se a empresa conteinerizar ou migrar parte da carga para serverless depois. A RFX registra, no plano de compra, o que pode mudar nos próximos 12 meses, para que o compromisso acompanhe a evolução.
Para o banco, a RFX compara duas alavancas na simulação: instâncias reservadas do Amazon RDS, por motor, classe e região, e os Database Savings Plans, que se aplicam ao Amazon RDS, ao Amazon Aurora e a outros bancos gerenciados da AWS independentemente de motor, família ou região.
Ver os exemplos de modernização com contêineres e serverless
Perguntas frequentes deste exemplo
É arriscado comprar antes de medir e antes de ajustar o tamanho. Por isso o compromisso vem depois do rightsizing, é dimensionado sobre a base estável e é comprado em partes. Com orçamento de utilização, você sabe no primeiro mês se algo sobrou.
Spot é capacidade ociosa que a AWS pode retomar com aviso curto, por isso serve para lote, filas, desenvolvimento e teste: cargas que toleram interrupção e recomeçam. Banco de produção fica na base estável, com instância reservada.
Há opções sem pagamento antecipado, parcial e total; a escolha é do financeiro, com a simulação na mão.
A rotina mensal mostra o vencimento com antecedência; a renovação é uma nova leitura da curva, com o ambiente daquele momento.
Serviços AWS deste exemplo
- Savings Plans
- Instâncias reservadas do Amazon RDS
- Instâncias Spot do Amazon EC2
- Amazon EC2 Auto Scaling
- AWS Batch
- AWS Fargate
- AWS Lambda
- AWS Cost Explorer
- AWS Budgets
- Amazon SNS
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.