Precificação, gerenciamento de custos e governança na nuvem

Uma fatura de nuvem é composta por unidades de precificação. A computação pode ser cobrada por segundo ou hora, o armazenamento por GB-mês e as requisições por 1.000 ou milhão de operações. Funções sem servidor costumam combinar uma cobrança por invocação com o tempo de execução multiplicado pela memória atribuída. Aumentar a memória atribuída altera a cobrança por memória e tempo.

Relacione a quantidade à tarifa

Para uma máquina virtual com tarifa de exemplo de R$ 0,10 por hora, um mês de 730 horas custa R$ 73. Executá-la por 10 horas em cada um de 22 dias úteis consome 220 horas e custa R$ 22. Seu disco de 100 GB a R$ 0,08 por GB-mês acrescenta R$ 8 em qualquer dos casos se permanecer provisionado durante todo o mês. A computação programada mais o armazenamento mantido totalizam R$ 30.

A convenção de 730 horas calcula a média de 8.760 horas anuais por 12 meses; os meses do calendário variam. Muitas máquinas virtuais usam cobrança por segundo com mínimo de um minuto, enquanto outros produtos cobram por minuto ou hora.

Capacidade ociosa ainda pode custar dinheiro

Capacidade provisionada é a capacidade reservada para seu recurso. Uma máquina virtual em execução ou um banco de dados provisionado gera cobranças por tamanho e tempo mesmo quando realiza pouco trabalho. Requisições de objetos e invocações de funções acompanham o uso mais diretamente. Um disco provisionado é cobrado pelo tamanho alocado, não apenas pelos arquivos gravados nele.

Parar uma instância do AWS EC2 encerra sua cobrança de computação. No Azure, a máquina virtual precisa ser parada e desalocada para encerrar a cobrança de computação. Desligar seu sistema operacional a mantém alocada e sujeita a cobrança. Discos e instantâneos continuam sendo recursos cobrados separadamente; endereços IP públicos mantidos também podem gerar cobranças.

Compare configurações equivalentes

Uma comparação de preços deve manter constantes as vCPUs, a memória, a região, o sistema operacional e o modelo de compra. Imagens do Windows Server ou SQL Server podem incluir uma licença de software em sua tarifa. Licenças existentes elegíveis podem reduzir a tarifa. A região afeta preço, latência e residência de dados.

Softwares de marketplace acrescentam cobranças de terceiros à fatura do provedor. A conversão de moeda e os impostos podem então alterar o total da fatura. A AWS Pricing Calculator exclui impostos; as faturas podem acrescentar impostos sobre vendas, IVA ou GST conforme o local de faturamento e a situação do cliente.

Entenda as ofertas gratuitas

Ofertas gratuitas incluem franquias mensais recorrentes, testes por tempo limitado e créditos. A AWS oferece até R$ 200 em créditos para novas contas. Seu plano Free é encerrado após seis meses ou quando os créditos acabam, o que ocorrer primeiro, a menos que seja atualizado para o plano Paid. Contas pagas geram cobranças normais além de suas franquias ou após o fim dos créditos. Defina um alerta de orçamento para uma conta de teste paga, mesmo quando suas primeiras cargas de trabalho se enquadram em uma oferta gratuita.

Estime em conjunto a quantidade armazenada, as operações, a recuperação, a retenção, a redundância e a movimentação de dados.

Calcule o preço conforme o uso dos dados

As camadas de objetos para acesso frequente incluem Amazon S3 Standard, Azure Blob hot e Google Cloud Storage Standard. Elas cobram mais pelo armazenamento que as camadas de acesso menos frequente e não têm tarifa de recuperação. Entre as opções de acesso menos frequente estão S3 Standard-IA e as classes Glacier, Azure cool, cold e archive e Google Nearline, Coldline e Archive. Elas oferecem armazenamento mais barato em troca de cobranças de recuperação e, para alguns produtos de arquivo, uma demora de horas na restauração.

Com tarifas de exemplo, 10.000 GB em uma camada padrão a R$ 0,023 por GB-mês custam R$ 230 por mês. Uma camada de arquivo a R$ 0,002 custa R$ 20 pelo armazenamento. Recuperar 2.000 GB a R$ 0,02 por GB acrescenta R$ 40, totalizando R$ 60 antes das operações e de outras cobranças aplicáveis. Recuperar todos os 10.000 GB acrescenta R$ 200, elevando esses dois componentes a R$ 220. A recuperação frequente pode eliminar a economia, enquanto atrasos de restauração podem inviabilizar a camada de arquivo.

Considere retenção e capacidade

Uma duração mínima de armazenamento significa que a exclusão ou movimentação antecipada pode gerar uma cobrança pelo tempo restante. O Google Coldline tem um mínimo de 90 dias; o Azure archive tem um mínimo de 180 dias. Se um objeto for excluído após 30 dias em uma camada de 90 dias, os 60 dias restantes ainda serão cobrados.

Discos em blocos geralmente são cobrados pelo tamanho provisionado e às vezes pelo desempenho provisionado. Um disco de 500 GB com 50 GB gravados ainda é precificado como 500 GB. O armazenamento de objetos cobra pelos dados armazenados. Instantâneos e cópias de segurança acrescentam suas próprias cobranças por dados armazenados. A redundância acrescenta cópias, e uma cópia em uma segunda região pode acrescentar custos de armazenamento e transferência.

Acompanhe a direção da transferência

Entrada de dados é o recebimento de dados; saída de dados é o envio de dados. A entrada de dados da internet geralmente é gratuita, incluindo dados comuns transferidos da internet para a AWS. A saída de dados para a internet costuma ser precificada por GB, com faixas e franquias. Cópias entre regiões também são cobradas, geralmente como tráfego de saída da região de origem.

Para uma aplicação de exemplo, 2.000 GB enviados a usuários na internet a R$ 0,09 por GB custam R$ 180. Replicar 500 GB para outra região a R$ 0,02 acrescenta R$ 10. Receber 300 GB de uploads sem cobrança acrescenta zero. O subtotal de transferência é R$ 190. A fatura de armazenamento dos dados replicados é separada.

A transferência entre zonas também pode custar dinheiro. Na AWS, o tráfego do EC2 entre zonas de disponibilidade pode gerar cobranças nos dois lados da transferência; outros serviços têm suas próprias regras e isenções. O tráfego por endereços privados dentro de uma zona geralmente é gratuito. Acompanhe cada caminho pelos serviços efetivamente usados e consulte suas páginas de preços, incluindo as franquias. Inclua transferências de saída ao planejar uma futura migração para outro provedor.

A menor tarifa por hora só é útil quando suas condições são adequadas à carga de trabalho. Compare a flexibilidade, a obrigação de longo prazo e a capacidade de tolerar interrupções antes de selecionar um modelo de compra.

Uso flexível ou compromisso para demanda estável

A precificação sob demanda não exige compromisso de longo prazo: paga-se a tarifa regular pelo tempo usado. Ela é adequada a cargas de trabalho curtas, incertas e variáveis. Um compromisso reduz a tarifa em troca de uma obrigação de um ou três anos. Um prazo de três anos oferece um desconto maior que um de um ano. Compromissos de recursos correspondem a atributos como tipo de recurso e região; compromissos de gastos cobrem o uso elegível até um valor por hora.

A AWS usa Reserved Instances e Savings Plans; o Azure oferece Reservations e o savings plan for compute. O Google Cloud oferece descontos por compromisso de uso baseado em recursos e em gastos. A AWS anuncia economia de até 72% para Reserved Instances e Savings Plans. A economia máxima anunciada não é a economia de todas as configurações.

Um compromisso é pago por cada hora de seu prazo, incluindo horas não utilizadas. A R$ 10 por hora durante um ano, a obrigação é de R$ 87.600. Se uma hora tiver apenas R$ 8 de uso elegível às tarifas do plano, essa hora ainda custará R$ 10. Os R$ 2 não utilizados não podem ser transferidos para uma hora de maior uso. O uso acima do compromisso é cobrado às tarifas sob demanda.

Calcule o ponto de equilíbrio

Uma máquina virtual de exemplo custa R$ 0,20 por hora sob demanda ou R$ 0,13 por hora em um compromisso de um ano. O compromisso custa R$ 1.138,80 por 8.760 horas. O uso sob demanda durante todo o ano custa R$ 1.752, uma economia de R$ 613,20, ou 35%.

Para atingir o ponto de equilíbrio, as horas sob demanda devem custar R$ 1.138,80: divida por R$ 0,20 para obter 5.694 horas. Isso corresponde a 65% do ano. Acima de 65% de uso, o compromisso compensa; em 65%, os totais são iguais. Uma carga de trabalho usada apenas em dias úteis por 2.080 horas custa apenas R$ 416 sob demanda. Assuma um compromisso para uma demanda de base medida, não para o máximo que uma carga de trabalho atinge brevemente.

As opções de pagamento da AWS são All Upfront, Partial Upfront e No Upfront; pagamentos antecipados maiores geralmente aumentam o desconto. Os Azure savings plans têm o mesmo custo total quando pagos mensalmente ou antecipadamente e não podem ser cancelados nem reembolsados.

Saiba o que uma reserva promete

Uma AWS Reserved Instance é um benefício de faturamento, não um servidor físico dedicado. A correspondência inclui atributos da instância, região, sistema operacional e locação. Reservas regionais se aplicam entre zonas; as zonais também reservam capacidade em uma zona escolhida. Standard Reserved Instances podem ser modificadas, mas não trocadas; as Convertible podem ser trocadas por atributos diferentes com um desconto menor. Quando o prazo termina, as instâncias em execução continuam às tarifas sob demanda.

Use capacidade spot quando o trabalho puder recomeçar

A capacidade spot usa capacidade excedente que o provedor pode retomar. A AWS anuncia até 90% de desconto; o Google Cloud, até 91%. A AWS normalmente avisa sobre a interrupção com dois minutos de antecedência; o Azure envia um aviso sem garantia de entrega com até 30 segundos de antecedência.

Com tarifas de exemplo, 400 horas de computação custam R$ 80 sob demanda a R$ 0,20 ou R$ 24 em capacidade spot a R$ 0,06. Se novas tentativas aumentarem o trabalho em 10% para 440 horas, a capacidade spot custará R$ 26,40. Tarefas em lote, renderização, compilações e análises que podem recomeçar podem ser adequadas à capacidade spot; um banco de dados único que precisa permanecer disponível não é. Uma combinação útil é usar compromissos para demanda estável, recursos sob demanda para demanda variável e capacidade spot para tarefas que podem recomeçar.

Os descontos por uso contínuo do Google são diferentes: tipos de máquina elegíveis, incluindo N1 e N2, podem receber descontos automáticos após mais de 25% de uso mensal sem compromisso, chegando a até 20% ou 30%, conforme o tipo.

Três necessidades distintas podem justificar uma opção especial de compra: hardware exclusivo, capacidade garantida ou licenciamento de software elegível. Primeiro identifique a necessidade e depois compare o custo da opção que a atende.

Compartilhar um servidor ou controlar um host

Na locação compartilhada, máquinas virtuais de diferentes clientes ocupam o mesmo servidor físico, isoladas pelo hipervisor. Essa é a opção econômica padrão para muitas cargas de trabalho. As Instâncias Dedicadas da AWS funcionam em hardware usado por um cliente, mas não permitem que ele escolha o host nem tenha visibilidade do servidor físico.

Um host dedicado oferece um servidor inteiro e visibilidade de seus soquetes e núcleos. AWS Dedicated Hosts, Azure Dedicated Host e Google Cloud sole-tenant nodes atendem a essa necessidade. Os clientes podem controlar a alocação de máquinas virtuais nesse host. Requisitos de conformidade que exigem uso exclusivo por um cliente e licenças vinculadas a núcleos ou soquetes físicos podem tornar essa opção útil.

O host inteiro é cobrado mesmo quando está parcialmente vazio. Com uma tarifa de exemplo de R$ 5 por hora, um host custa R$ 3.650 em um mês de 730 horas. Se comportar 12 máquinas virtuais, o custo horário do host será, em média, cerca de R$ 0,42 por máquina virtual quando estiver cheio. Com apenas quatro máquinas virtuais, a média será de R$ 1,25. É a mesma fatura do host dividida entre menos máquinas úteis. Compare a ocupação esperada e também a tarifa anunciada do host.

Reservar capacidade é uma compra diferente

Uma reserva de capacidade mantém disponível a capacidade de computação correspondente para quando for necessária. AWS e Azure oferecem reservas zonais de capacidade sob demanda. As reservas do Google Cloud também são zonais, com escopo de consumo que depende da reserva e do serviço. Especifique os atributos e o local exigidos para a máquina.

Uma reserva de capacidade gera cobranças pela capacidade reservada mesmo quando ela não é usada. Ela não cria um desconto por si só; um benefício de compromisso de uso compatível pode reduzir a fatura. Ela também não torna o host físico exclusivo de um cliente. Para um evento planejado ou local de recuperação, avalie separadamente se a capacidade precisa estar disponível e se uma tarifa menor por compromisso de uso compensa.

A distinção também explica a terminologia da AWS. Uma Instância Reservada regional oferece um desconto de faturamento. Uma Instância Reservada zonal combina um desconto de faturamento com uma reserva de capacidade. Um host dedicado atende à questão da locação. Nomes semelhantes não tornam essas opções intercambiáveis.

Verifique a elegibilidade do software

Imagens com licença incluída incorporam a licença de software à tarifa de nuvem. O uso de licença própria, ou BYOL, usa licenças elegíveis que o cliente já possui. A elegibilidade depende dos termos do software; possuir uma licença, por si só, não estabelece o direito de usá-la em qualquer servidor de nuvem.

O Benefício Híbrido do Azure oferece suporte a licenças elegíveis do Windows Server e SQL Server com Software Assurance ou assinaturas qualificadas. O AWS License Manager ajuda a acompanhar o uso de licenças. Algumas licenças exigem um host físico conhecido, o que pode tornar a hospedagem dedicada parte da decisão de licenciamento.

Suponha que uma equipe precise de um preço menor para um serviço em execução contínua, mas não tenha uma regra de uso exclusivo por um cliente. Um compromisso de uso em locação compartilhada atende ao objetivo de preço. Se a equipe precisar de capacidade garantida em uma zona para um lançamento, acrescente uma reserva de capacidade. Se uma licença precisar estar vinculada a núcleos físicos, avalie um host dedicado e sua ocupação. Preço, disponibilidade e locação são características distintas que devem ser escolhidas de forma consciente.

O custo total de propriedade, ou TCO, soma os custos de possuir e operar um sistema durante um período escolhido, muitas vezes de três a cinco anos. Ele oferece uma comparação mais justa do que colocar uma fatura de nuvem ao lado do preço de compra de hardware. As duas opções devem entregar o mesmo serviço exigido durante o mesmo período.

Separe os custos de compra dos custos de operação

A despesa de capital, ou CapEx, compra ativos como servidores e edifícios que são usados e depreciados ao longo de vários anos. A despesa operacional, ou OpEx, paga serviços contínuos e custos de operação. A nuvem transfere grande parte dos gastos de compras antecipadas de hardware para cobranças recorrentes de serviços.

Um centro de dados próprio tem muitos custos fixos mesmo quando é pouco utilizado. As cobranças de uso da nuvem podem crescer ou diminuir, mas compromissos de uso e recursos provisionados ainda criam obrigações. Uma mudança no tipo de gasto afeta o fluxo de caixa e a flexibilidade; seu custo total ainda precisa ser calculado.

Para sistemas nas instalações da organização, inclua hardware, licenças, espaço, energia, refrigeração, manutenção, segurança física, tempo da equipe, renovações, capacidade para picos e recuperação de desastres. Para a nuvem, inclua computação, armazenamento, transferência, serviços gerenciados, suporte, tempo da equipe, treinamento e migração. Durante uma migração, a organização pode pagar pelos dois ambientes ao mesmo tempo.

O tempo da equipe é um dado a ser estimado a partir das responsabilidades reais. Um provedor de nuvem gerencia o hardware físico, mas o cliente ainda gerencia configurações, dados, decisões de segurança e sistemas operacionais de máquinas virtuais. Avalie o trabalho e as habilidades necessários em vez de supor que os custos de pessoal desaparecem.

Elabore uma comparação passo a passo

1. Defina o escopo do serviço e o período de comparação.
2. Inventarie os servidores e o armazenamento existentes e a utilização medida.
3. Some os custos de compra e operação nas instalações da organização.
4. Dimensione o sistema de nuvem para a demanda observada e calcule o preço de seus componentes.
5. Acrescente migração, treinamento e eventual período de sobreposição.
6. Compare os totais e depois teste as premissas de crescimento e dimensionamento.

Considere um exemplo de três anos. Nas instalações da organização, o hardware custa R$ 60.000. Os custos anuais são R$ 9.000 para energia e refrigeração, R$ 6.000 para espaço, R$ 40.000 para pessoal, R$ 10.000 para licenças e R$ 5.000 para manutenção. Esses custos anuais totalizam R$ 70.000. Três anos custam R$ 60.000 mais R$ 210.000, resultando em R$ 270.000.

A alternativa em nuvem usa R$ 3.500 mensais para computação e armazenamento, R$ 300 para transferência e R$ 350 para suporte. Os R$ 4.150 mensais tornam-se R$ 149.400 em 36 meses. Acrescente R$ 60.000 por três anos de tempo da equipe e R$ 25.000 de migração: R$ 234.400. A diferença é de R$ 35.600, cerca de 13% do total nas instalações da organização.

Teste o que poderia mudar o resultado

Uma configuração de nuvem maior, crescimento mais rápido ou mais saída de dados pode reduzir essa economia. Um compromisso de uso pode reduzir tarifas, mas acrescenta uma obrigação. Copiar para a nuvem a capacidade comprada para picos pode superestimar o necessário; a utilização medida ajuda a dimensionar adequadamente a estimativa.

O AWS Migration Evaluator, a análise de viabilidade do Azure Migrate e o Google Cloud Migration Center ajudam a inventariar sistemas e comparar custos. Seus resultados dependem do inventário e das premissas inseridos. Mantenha benefícios difíceis de precificar, como entrega mais rápida, alcance global, elasticidade e resiliência, ao lado do cálculo monetário. Economias de escala ajudam os provedores a reduzir custos, mas uma carga de trabalho estável migrada sem alterações e paga às tarifas sob demanda ainda pode custar tanto quanto, ou mais que, sua alternativa nas instalações da organização.

Uma calculadora de preços converte uma configuração de nuvem planejada em uma cobrança estimada. AWS, Azure e Google Cloud oferecem calculadoras web gratuitas. Insira todos os componentes e um uso realista antes de comparar projetos.

Inventarie todos os componentes

Comece pela arquitetura: máquinas virtuais da aplicação, banco de dados, discos, dados de objetos, requisições, cópias de segurança e caminhos de transferência. Inclua ambientes de desenvolvimento e teste, não apenas o de produção. Escolha região, sistema operacional, tamanhos dos recursos, horas de funcionamento e modelo de precificação para cada serviço. Acrescente o plano de suporte separadamente se ele ainda não estiver incluído.

Use a mesma base de tempo em toda a estimativa. Use 730 horas para um mês estimado de funcionamento contínuo. Um sistema de teste usado em dias úteis precisa de sua programação real, enquanto discos mantidos podem precisar de um mês completo de armazenamento. Converta as contagens brutas de requisições em milhões antes de aplicar uma tarifa por milhão.

Some os itens

Para uma pequena aplicação web, use estas tarifas de exemplo e quantidades mensais:

O total desses quatro itens é R$ 325,26 mensais, ou R$ 3.903,12 anuais. Acrescente a esse subtotal as cópias de segurança, o suporte e os outros serviços necessários.

Se um compromisso de um ano reduzir apenas a tarifa das máquinas virtuais em 35%, o item das máquinas virtuais passa a ser R$ 140,16 multiplicado por 0,65, ou R$ 91,104 antes do arredondamento. Some o banco de dados, o armazenamento e a saída de dados sem alterações para obter R$ 276,204, apresentado como R$ 276,20 mensais. Aplicar 35% à estimativa inteira descontaria incorretamente serviços fora dessa oferta para máquinas virtuais.

Registre o significado da estimativa

Revise em conjunto as cobranças mensais, os pagamentos antecipados e os totais anuais. Uma oferta paga integralmente antecipada pode mostrar uma pequena fatura recorrente, mas exigir dinheiro no início. Registre a data, a região, a configuração, as horas, a transferência, o prazo do compromisso e a base de preços. Estimativas públicas usam tarifas de tabela; algumas calculadoras podem usar preços negociados. A calculadora do Google pode usar preços contratuais quando vinculada a uma conta de faturamento elegível.

A AWS Pricing Calculator exclui impostos. Listas de preços e APIs, como AWS Price List API e Azure Retail Prices API, fornecem tarifas para ferramentas e scripts; as tarifas podem mudar após uma estimativa ser salva.

Agrupe a estimativa por carga de trabalho, salve um link compartilhável e exporte-a para revisão. A AWS permite exportações em CSV e PDF. Após a implantação, compare cada item principal com o relatório de custos. Investigue diferenças nas horas reais, no armazenamento e na transferência em relação às quantidades salvas.

Uma entidade central de faturamento pode pagar pelas contas, assinaturas ou projetos separados de várias equipes. Acompanhe tanto o pagador quanto o responsável pelo recurso.

Encontre a entidade pagadora

Na AWS, uma organização no AWS Organizations tem uma conta de gerenciamento que paga por suas contas-membro por meio do faturamento consolidado. No Azure, as assinaturas ficam sob uma conta de faturamento; em um Microsoft Customer Agreement, perfis de faturamento e seções de fatura organizam o pagamento. No Google Cloud, cada projeto é vinculado a uma conta do Cloud Billing que paga suas cobranças.

Uma fatura normalmente abrange um mês do calendário. Seus agrupamentos por serviço, tipo de uso, região e conta ou projeto explicam as cobranças. Créditos, reembolsos e impostos afetam o valor devido. Itens detalhados relacionam uma quantidade medida a uma tarifa e, quando disponível, a um recurso.

Combine o uso elegível para precificação por volume

O faturamento consolidado da AWS não tem tarifa adicional e combina o uso elegível para as faixas de volume. Considere tarifas de armazenamento de exemplo: R$ 0,023 por GB-mês para os primeiros 50.000 GB e R$ 0,022 acima disso. Três contas armazenam 20.000 GB cada uma por um mês.

Cobradas separadamente, cada uma paga R$ 460 e o total combinado é R$ 1.380. O uso consolidado é de 60.000 GB: os primeiros 50.000 custam R$ 1.150 e os 10.000 restantes custam R$ 220. O total consolidado é R$ 1.370.

Somente a quantidade acima do limite da faixa recebe a tarifa menor. Precificar todos os 60.000 GB a R$ 0,022 resultaria em R$ 1.320 e estenderia incorretamente a faixa mais barata ao uso anterior.

Acompanhe os benefícios compartilhados de compromissos de uso

Benefícios de Instâncias Reservadas e Savings Plans também podem ser compartilhados entre contas elegíveis. Se a conta A possuir uma Instância Reservada, mas não tiver uso correspondente em uma hora, a instância correspondente em execução na conta B poderá receber o benefício. A conta de gerenciamento pode desativar o compartilhamento para contas selecionadas.

A fatura exibida de uma conta-membro é, portanto, uma visualização informativa das cobranças e dos benefícios alocados. Aplique a regra central de alocação quando outra equipe consumir o benefício comprado.

Contas, assinaturas ou projetos separados tornam a responsabilidade visível porque as cobranças já pertencem a esses limites. As etiquetas dividem ainda mais os custos dentro deles, por exemplo, por aplicação ou ambiente.

O acesso ao faturamento ainda exige permissão. Dê a quem visualiza custos a capacidade de consultar relatórios sem também conceder o direito de alterar dados de pagamento ou comprar compromissos de uso. Separe a visualização de custos, as alterações de pagamento e as compras de compromissos por meio de permissões de privilégio mínimo.

Use relatórios de custos para encontrar o serviço, o recurso e o responsável por uma mudança nos gastos.

Escolha uma visualização útil

O AWS Cost Explorer, a análise de custos no Microsoft Cost Management e os relatórios do Google Cloud Billing mostram os gastos ao longo do tempo. Filtre e agrupe por serviço, conta ou projeto, região, tipo de uso e etiquetas. As previsões projetam custos futuros com base em padrões de uso anteriores.

Para uma análise detalhada, exporte registros de faturamento. Os dados do AWS Cost and Usage Report podem ser entregues pelo AWS Data Exports ao S3, as exportações do Azure Cost Management gravam em uma conta de armazenamento e as exportações de faturamento do Google Cloud vão para o BigQuery. Esses conjuntos de dados permitem que analistas consultem IDs de recursos, quantidades e etiquetas ou criem seus próprios painéis.

Separe o momento do pagamento do custo ao longo do tempo

Uma visualização de custo real mostra as cobranças no período faturado. Uma visualização de custo amortizado distribui as cobranças antecipadas de compromissos de uso ao longo do prazo. Se um compromisso de um ano custar R$ 8.760 antecipadamente, o mês da compra mostrará R$ 8.760 em uma visualização real. Uma visualização mensal amortizada simples distribui o valor como cerca de R$ 730 por mês.

Use custos reais para o momento do pagamento e custos amortizados para comparar períodos; uma compra antecipada não é um aumento repentino de uso.

Detalhe a maior mudança

Suponha que a fatura suba de R$ 10.000 para R$ 12.000. O aumento de R$ 2.000 representa 20% do mês anterior. O agrupamento por serviço revela:

A transferência explica R$ 1.900 do aumento líquido de R$ 2.000, ou 95%. Comece por aí: agrupe a transferência por região, depois por conta ou etiqueta e então examine o recurso e o tipo de uso. Um aumento em um caminho de replicação exige uma resposta diferente do crescimento de downloads pelos clientes. Atribua um responsável e uma ação depois de localizar a causa.

Considere atrasos e mudanças ocultas

Os relatórios de faturamento chegam com atraso em relação à atividade dos recursos. Os dados de orçamento da AWS são atualizados até três vezes por dia; os dados de custos do Azure normalmente chegam em 8 a 24 horas. Uma nova carga de trabalho pode estar gerando gastos antes que seu custo apareça. Compare períodos e visualizações de custo equivalentes ao verificar um alerta.

Ferramentas de detecção de anomalias identificam padrões incomuns de gastos. O AWS Cost Anomaly Detection, os alertas de anomalias do Microsoft Cost Management e a detecção de anomalias do Google Cloud podem sinalizar um cluster esquecido ou um aumento repentino de transferência. Serviços de recomendação como AWS Trusted Advisor, Azure Advisor e Google Cloud Recommender sugerem economias a investigar.

Um total estável pode esconder o crescimento de um banco de dados compensado pela queda dos custos de máquinas virtuais. Compare as mudanças por serviço junto com os agrupamentos por conta e etiqueta para identificar tanto o uso quanto a responsabilidade.

Um orçamento define um valor planejado para um período e um escopo. Alertas comparam custo ou uso com esse plano. Eles ajudam alguém a agir antes da fatura final, portanto seu escopo, seus limites e seu destinatário são tão importantes quanto seu valor.

Defina o escopo e a finalidade

AWS Budgets, orçamentos do Microsoft Cost Management e orçamentos do Google Cloud Billing podem acompanhar uma conta ou uma parte mais restrita. Exemplos incluem uma assinatura ou grupo de recursos do Azure, um projeto do Google ou um filtro por serviço ou etiqueta. O Azure permite reinícios mensais, trimestrais e anuais; a AWS também permite períodos personalizados, como a duração de um projeto.

A AWS oferece orçamentos de custo e uso, além de orçamentos de utilização e cobertura para Instâncias Reservadas e Savings Plans. Utilização indica quanto do compromisso comprado é usado. Cobertura indica quanto do uso elegível recebe um benefício de compromisso de uso. Uma equipe pode ter alta utilização, mas baixa cobertura, se um pequeno compromisso for usado integralmente por uma carga de trabalho muito maior.

Use limites para custos reais e previstos

Um alerta de custo real compara os gastos até o momento com um limite. Um alerta de custo previsto compara os gastos esperados para todo o período com um limite. Os limites padrão sugeridos pelo Google incluem 50%, 90% e 100%; escolha níveis que deixem tempo para o responsável agir.

Para um orçamento mensal de R$ 5.000, um limite de custo real de 80% é R$ 4.000. No 12º dia de um mês de 30 dias, os gastos são de R$ 2.400. Isso representa 48% do orçamento, portanto o limite de custo real ainda não foi atingido. No ritmo atual de R$ 200 por dia, uma previsão simples chega a R$ 6.000, ou 120% do orçamento. Um limite de custo previsto de 100% avisa agora.

O orçamento restante é de R$ 2.600 para 18 dias. Divida para obter cerca de R$ 144,44 por dia. Essa é a média de gastos restante necessária para cumprir o plano; reduzir o ritmo futuro não elimina cobranças já incorridas.

Decida o que acontece após o alerta

Um orçamento comum é um alerta, não uma interrupção padrão dos gastos. As notificações de orçamento do Azure não afetam os recursos. Os orçamentos do Google que apenas alertam não limitam o consumo. Os dados de faturamento chegam com atraso, portanto os custos podem ultrapassar um limite antes que a notificação chegue a alguém.

A automação exige configuração. Ações de orçamento da AWS podem aplicar políticas de IAM ou de controle de serviço ou parar instâncias EC2 e RDS. Grupos de ações do Azure podem invocar Functions, Logic Apps ou webhooks. Notificações do Google Pub/Sub podem acionar automações; o Google também oferece orçamentos com limite de gastos configurados separadamente que pausam serviços compatíveis em um projeto.

Escolha a ação considerando as necessidades de disponibilidade da carga de trabalho. Parar automaticamente um sistema de teste pode ser aceitável; parar o único banco de dados de produção pode criar uma interrupção dispendiosa. Teste o escopo e as permissões de uma ação automatizada antes de depender dela.

Atribua um responsável ao orçamento

As notificações podem chegar por e-mail, tópicos do AWS SNS e aplicativos de chat, grupos de ações do Azure e aplicativo móvel, ou canais do Google Pub/Sub e Cloud Monitoring. Identifique a pessoa ou equipe que deve investigar e defina como os alertas urgentes serão tratados. Uma caixa de entrada compartilhada só é útil quando alguém é responsável por responder. Durante revisões regulares, verifique se o escopo ainda corresponde à carga de trabalho e se os destinatários ainda têm autoridade para agir.

Uma etiqueta é uma marcação de chave e valor em um recurso, como “Environment = Production” ou “CostCenter = 4410”. Etiquetas conectam recursos técnicos às pessoas e finalidades de negócios por trás de seus custos. AWS e Azure usam tags para isso; o Google Cloud usa rótulos para detalhar o faturamento e tags separadas principalmente para políticas condicionais.

Defina um padrão único

Chaves úteis incluem CostCenter, Owner, Environment, Project e Application. Defina nomes e valores permitidos e aplique-os quando os recursos forem criados. “Environment = Production” e “environment = prod” podem dividir um grupo pretendido em dois. As chaves e os valores de etiquetas da AWS diferenciam maiúsculas de minúsculas. Os nomes de etiquetas do Azure não fazem essa distinção nas operações, enquanto os valores fazem.

A separação de contas oferece um limite amplo de responsabilidade; as etiquetas acrescentam detalhes dentro dele. Uma conta compartilhada pode conter recursos “Application = Orders” e “Application = Search”, permitindo que um relatório de custos separe essas aplicações sem movê-las.

Torne as marcações utilizáveis no faturamento

Na AWS, uma conta de gerenciamento ou independente deve ativar etiquetas como etiquetas de alocação de custos no Billing and Cost Management. As etiquetas definidas pelo usuário coexistem com as geradas pela AWS com o prefixo “aws:”, como “aws:createdBy”. A ativação e a disponibilização podem levar tempo, incluindo até 24 horas para aparecer. Um preenchimento retroativo solicitado pode aplicar etiquetas a até 12 meses de dados de custos anteriores de recursos que já as tinham.

Os recursos do Azure não herdam por padrão as etiquetas de grupos de recursos ou assinaturas. O Azure Policy pode adicionar ou herdar etiquetas nos recursos. A herança de etiquetas do Cost Management aplica etiquetas de níveis superiores aos registros de uso; esse recurso de relatório é diferente de gravar etiquetas nos próprios recursos. O Azure permite até 50 etiquetas por recurso, grupo de recursos ou assinatura.

Aloque explicitamente custos compartilhados e sem etiqueta

Nem todo tipo de recurso oferece suporte a etiquetas, e tarifas de suporte, impostos e algumas cobranças de transferência podem não ter uma etiqueta de recurso. Mantenha uma categoria não alocada e combine como distribuir custos que são de fato compartilhados.

Suponha que as cobranças de recursos totalizem R$ 5.000: a Equipe A tem R$ 3.000, a Equipe B tem R$ 1.500 e R$ 500 não têm etiqueta. Os custos etiquetados totalizam R$ 4.500. Uma tarifa de suporte separada de R$ 400 é alocada proporcionalmente aos custos etiquetados. A Equipe A recebe R$ 3.000 divididos por R$ 4.500 da tarifa, ou R$ 266,67. A Equipe B recebe R$ 133,33. A fatura completa é R$ 5.400, e os R$ 500 sem etiqueta permanecem para os responsáveis resolverem. Não os distribua silenciosamente como se seu responsável fosse conhecido.

O demonstrativo interno de custos informa uma equipe sobre seus custos. A cobrança interna de custos lança esses custos em seu orçamento interno. Ambos precisam de responsabilidade confiável pelos recursos e de um método de alocação que explique as cobranças compartilhadas.

Mantenha as etiquetas precisas e seguras

Aplique o padrão por meio de infraestrutura como código e dos processos de criação de recursos. As políticas de etiquetas da AWS padronizam chaves e valores de etiquetas compatíveis; use controles adicionais para detectar ou impedir a ausência de etiquetas. O Azure Policy pode exigir uma etiqueta, adicionar um valor ou negar uma criação não conforme. Acompanhe a cobertura de etiquetas como a parcela do custo relevante que tem as etiquetas exigidas e investigue a falta de cobertura.

As etiquetas aparecem em texto claro em relatórios, registros e exportações. Mantenha senhas, dados pessoais e outros valores sensíveis fora delas. Uma etiqueta por si só é um metadado; regras de acesso precisam de uma política separada que a utilize.

A governança da nuvem combina regras, processos e controles. Um controle preventivo bloqueia uma ação indesejada, um controle detectivo informa um problema e um controle corretivo o corrige. Associe o controle ao requisito real: quem pode agir, qual estado de recurso é permitido ou o que deve ser protegido contra alterações acidentais.

Aplique regras de recursos do Azure

O RBAC do Azure controla quem pode executar ações. O Azure Policy verifica propriedades dos recursos independentemente de quem envia a requisição. Um Contributor pode ter permissão para criar máquinas virtuais, mas uma política Allowed locations ainda pode negar uma região não aprovada.

Uma definição de política contém uma regra e um efeito. Uma iniciativa agrupa definições. Uma atribuição aplica uma delas a um grupo de gerenciamento, assinatura, grupo de recursos ou recurso; escopos inferiores a herdam, com exclusões quando configuradas.

O efeito determina a resposta. audit registra a não conformidade; deny bloqueia uma alteração não conforme. modify e append podem alterar uma requisição, por exemplo, adicionando uma etiqueta. auditIfNotExists verifica recursos relacionados e deployIfNotExists pode implantá-los. denyAction bloqueia ações especificadas, como exclusão; disabled desativa a avaliação. Recursos existentes podem precisar de tarefas de correção. As avaliações ocorrem em alterações relevantes e em verificações normalmente executadas a cada 24 horas. Comece com auditoria quando precisar entender o impacto de uma atribuição antes de aplicar a negação.

Proteja recursos contra alterações acidentais

Os bloqueios do Azure se aplicam no escopo de assinatura, grupo de recursos ou recurso e são herdados. CanNotDelete, exibido como Delete no portal, permite leitura e modificação, mas bloqueia a exclusão. ReadOnly permite apenas leitura e pode bloquear operações de gerenciamento inesperadas, incluindo iniciar uma máquina virtual ou listar chaves de armazenamento.

Somente funções com permissões de bloqueio, como Owner ou User Access Administrator, podem gerenciar bloqueios. Um bloqueio pode impedir uma ação que de outra forma seria permitida, mas alguém autorizado a removê-lo pode retirar essa proteção. Os bloqueios protegem operações de gerenciamento, não dados armazenados: um bloqueio de conta de armazenamento não impede a exclusão de blobs pelo plano de dados. Um recurso bloqueado pode impedir a exclusão de todo o seu grupo de recursos.

Use os controles de proteção organizacionais correspondentes

As políticas de controle de serviço da AWS, ou SCPs, definem as permissões máximas para usuários e funções de IAM nas contas-membro, incluindo usuários raiz dessas contas. Elas não concedem permissões por si só e não restringem a conta de gerenciamento. Uma SCP pode negar ações fora das regiões aprovadas. As regras do AWS Config detectam não conformidade de recursos; o Control Tower ajuda a estabelecer contas e controles. Políticas de etiquetas padronizam valores de etiquetas compatíveis, mas uma regra para etiquetas ausentes precisa de aplicação adicional adequada.

O Google Cloud Organization Policy Service aplica restrições no escopo da organização, de pastas ou de projetos, herdadas pelos níveis inferiores da hierarquia. Os três provedores usam cotas para limitar quantidades como vCPUs. Uma cota restringe a quantidade de recursos, não a fatura total de todos os serviços.

Para “regiões aprovadas da UE, uma etiqueta CostCenter e proteção contra exclusão do banco de dados”, o Azure precisa de políticas de região e etiqueta e de um bloqueio CanNotDelete. A AWS combina SCPs regionais, padrões e verificações de etiquetas e proteção contra exclusão do banco de dados. O Google combina restrições de locais de recursos, verificações de rótulos e proteção contra exclusão.

O Microsoft Purview tem outra finalidade: descobrir, classificar, catalogar e proteger dados em diferentes ambientes e apoiar a conformidade. Restrinja tamanhos de máquinas virtuais e regiões com políticas de recursos, não com um catálogo de dados.

Uma pessoa com permissões de nuvem pode criar um recurso cobrável em minutos. A governança financeira, portanto, precisa de uma prática contínua: mostrar custos, atribuir responsabilidades, agir diante de mudanças e revisar se os controles ainda são adequados ao negócio.

Conecte pessoas, processos e tecnologia

O FinOps reúne equipes de finanças, engenharia e negócios para tomar decisões de gastos fundamentadas. Engenheiros entendem os sistemas e podem mudar seu uso. A equipe financeira define orçamentos e previsões. Líderes de negócios decidem como equilibrar custo, velocidade, confiabilidade e qualidade.

Atribua a cada conta, assinatura ou projeto um responsável identificado pelos custos. Uma equipe central de FinOps ou um centro de excelência em nuvem define padrões comuns, prepara relatórios e coordena compromissos de uso para a demanda de base compartilhada. Ela apoia as decisões das equipes de engenharia em vez de fazer por elas todas as escolhas diárias de recursos.

As ferramentas apoiam esse trabalho: estruturas de contas, etiquetas, relatórios de custos, orçamentos, alertas de anomalias, políticas, cotas e recomendações. Um painel sem responsável não decide o que fazer; um alerta sem processo de resposta pode permanecer sem leitura.

Repita as fases do FinOps

O FinOps Framework nomeia três fases que se repetem:

• Informar: tornar os gastos visíveis e alocá-los aos responsáveis.
• Otimizar: melhorar o uso e as tarifas enquanto atende aos requisitos.
• Operar: definir metas e políticas, agir por meio de processos acordados e melhorar a prática.

Elas formam um ciclo, não um projeto feito uma única vez. Uma revisão mensal pode comparar custos reais com previsões, examinar mudanças por equipe, verificar a cobertura de etiquetas e revisar compromissos de uso não utilizados. Entre as revisões, um processo de anomalias trata mudanças urgentes. Um processo de compra de compromissos deve identificar quem pode aprovar a obrigação e qual demanda de base a sustenta.

A hierarquia de recursos do Google, organização, pastas, projetos e recursos, ajuda a combinar responsabilidade com políticas de acesso e organizacionais herdadas. A visibilidade de custos, os limites de permissão e a auditoria devem se adequar a essa estrutura para que o responsável por um projeto possa investigar seus gastos.

Relacione o custo ao resultado útil

A economia unitária divide o custo por um resultado de negócios, como pedidos processados. Com R$ 12.000 para 400.000 pedidos, o custo é R$ 0,03 por pedido. Com R$ 15.000 para 600.000 pedidos, ele cai para R$ 0,025 por pedido.

A fatura cresceu 25%, enquanto os pedidos cresceram 50%. Uma fatura maior pode, portanto, acompanhar uma melhora no custo por unidade. Verifique o total e a medida unitária: o total importa para o orçamento, enquanto a medida unitária explica a eficiência conforme o resultado muda. Um custo unitário menor pode coexistir com recursos ociosos, portanto continue examinando os custos por recurso.

Conclua o ciclo após um incidente

Suponha que uma anomalia semanal mostre um aumento de 40%. O alerta chega ao responsável pela conta, que agrupa o relatório por etiqueta e encontra um cluster de teste deixado no tamanho completo. A equipe interrompe o trabalho desnecessário, confirma o efeito nos dados de custos posteriores e acrescenta uma data de término às solicitações de recursos de teste. Na próxima revisão, ela atualiza o padrão e verifica se existem recursos semelhantes.

Essa sequência dá uma finalidade a cada ferramenta: o alerta detecta, o relatório explica, o responsável age e o processo reduz a recorrência. Antes de cortar um custo, verifique seu efeito sobre segurança, desempenho e confiabilidade. A governança financeira busca resultados úteis para o negócio a partir dos gastos com nuvem, com as vantagens e desvantagens visíveis para os responsáveis.

Um plano de suporte compra acesso a ajuda sob condições definidas. Escolha-o com base no impacto da carga de trabalho e na primeira resposta necessária e depois calcule a tarifa. Uma meta de resposta informa quando a ajuda começa, não quando a aplicação será corrigida.

Compare os níveis de suporte

Planos básicos incluem ajuda para contas e faturamento, documentação e acesso à comunidade. Planos pagos acrescentam chamados técnicos e respostas mais rápidas para incidentes graves. Faixas superiores podem acrescentar orientação de arquitetura e um gerente técnico de conta, ou TAM, que oferece orientação contínua. Abra chamados pelo console do provedor, como AWS Support Center ou Ajuda + suporte do Azure.

Em outubro de 2026, a AWS recomenda o Business Support+ como seu plano mínimo para produção. Ele inclui suporte técnico 24 horas por dia, 7 dias por semana por telefone, chat e e-mail, verificações completas do Trusted Advisor e uma meta de resposta em menos de 30 minutos para um sistema crítico para o negócio que esteja indisponível. O Enterprise Support acrescenta um TAM designado e revisões Well-Architected, com meta de menos de 15 minutos para essa gravidade. O Unified Operations acrescenta engenheiros de gerenciamento de incidentes com meta de menos de cinco minutos, especialistas e monitoramento de cargas de trabalho 24 horas por dia, 7 dias por semana.

A AWS está encerrando os planos antigos Developer, Business e Enterprise On-Ramp em 1º de janeiro de 2027 nas regiões comerciais. Usuários Developer e Business podem migrar para o Business Support+; usuários Enterprise On-Ramp estão migrando para o Enterprise Support.

Aplique as faixas e o mínimo

O Business Support+ custa o maior valor entre R$ 29 mensais por conta e porcentagens por faixas das cobranças mensais da AWS: 9% dos primeiros R$ 10.000, 7% de R$ 10.000 a R$ 80.000, 5% de R$ 80.000 a R$ 250.000 e 3% acima de R$ 250.000.

Com R$ 20.000 em cobranças, a primeira faixa contribui com R$ 900 e a seguinte com R$ 700, totalizando R$ 1.600. Não aplique 7% a todos os R$ 20.000: os gastos anteriores mantêm a tarifa de sua faixa. Com R$ 200 em cobranças, 9% resultam em R$ 18, portanto aplica-se o mínimo de R$ 29.

O Enterprise Support usa um mínimo de R$ 5.000 ou 10% dos primeiros R$ 150.000, 7% até R$ 500.000, 5% até R$ 1 milhão e 3% acima disso. Com R$ 100.000, a tarifa é R$ 10.000. O Unified Operations começa em R$ 50.000 mensais. Compare o mínimo com o total calculado após aplicar todas as faixas relevantes.

Escolha o plano conforme a necessidade

O Azure Basic inclui ajuda para faturamento e assinaturas. O Developer custa R$ 29 mensais para uso fora de produção, com casos de impacto mínimo respondidos em até oito horas úteis. O Standard custa R$ 100 para produção, com casos críticos em até uma hora. O Professional Direct custa R$ 1.000 para uso crítico para o negócio, com casos críticos em até uma hora e casos de impacto moderado em até duas horas. O Unified Enterprise tem preço personalizado, resposta para sistema Azure indisponível em até 15 minutos e suporte para outros produtos Microsoft.

O Google Cloud Customer Care tem os níveis Basic, Standard, Enhanced e Premium. Os níveis pagos melhoram as metas de resposta; o Premium acrescenta um TAM.

Uma loja virtual em produção que precisa de ajuda técnica a qualquer hora, sem um gerente de conta designado, pode se adequar ao AWS Business Support+ ou ao Azure Standard. A exigência de um TAM muda a comparação. Verifique em conjunto a gravidade, o horário de cobertura, a meta de tempo para a primeira resposta, a orientação incluída e o preço. O suporte ajuda a equipe do cliente; o cliente continua operando sua aplicação.

Um provedor oferece vários tipos de ajuda porque problemas diferentes exigem respostas diferentes. Comece identificando a tarefa: aprender uma configuração, investigar um incidente, revisar custos, comprar software ou planejar uma migração.

Aprenda e projete

A documentação oficial explica recursos e configurações. A AWS acrescenta documentos técnicos, blogs, o Prescriptive Guidance para estratégias e padrões e o Knowledge Center para perguntas comuns. O Microsoft Learn e o Azure Architecture Center fornecem referências semelhantes. A documentação do Google Cloud e o Architecture Center explicam serviços e padrões de projeto do Google.

As comunidades permitem que pessoas façam e respondam perguntas: AWS re:Post, Microsoft Q&A e comunidades do Azure e Google Cloud Community. Elas podem ajudar com uma dúvida de projeto ou uma experiência compartilhada. Para um incidente urgente em produção que exige uma meta de resposta, abra um chamado técnico no plano de suporte adequado.

Arquitetos de soluções da AWS orientam o projeto de cargas de trabalho, enquanto o AWS Professional Services ajuda a executar projetos maiores de consultoria. Parceiros podem projetar, migrar e operar ambientes. Fornecedores independentes de software, ou ISVs, vendem software; integradores de sistemas e parceiros de consultoria conectam sistemas e ajudam na implementação. Programas de parceiros dos provedores oferecem treinamento, certificação, eventos e benefícios comerciais.

Examine a integridade e as recomendações

Painéis de integridade informam eventos do lado do provedor. O AWS Health mostra o status público dos serviços e eventos que afetam sua conta; a AWS Health API permite que automações consumam esses eventos. O Azure Service Health informa problemas, manutenções e avisos relevantes para as assinaturas. Os serviços de integridade do Google Cloud fornecem informações sobre o status dos serviços e informações personalizadas sobre incidentes, quando disponíveis.

Uma página pública de status normal pode coexistir com um evento que afeta uma conta ou um recurso específico. Consulte a visualização da conta ou assinatura ao investigar uma interrupção e compare-a com o monitoramento da própria aplicação. A ausência de um evento listado é motivo para continuar investigando a aplicação, não para ignorar seus sintomas.

Ferramentas de orientação examinam configurações e uso. O AWS Trusted Advisor verifica custo, segurança, tolerância a falhas, desempenho, limites de serviço e excelência operacional. O Basic inclui verificações essenciais; os planos pagos incluem o conjunto completo. O Azure Advisor abrange confiabilidade, segurança, desempenho, custo e excelência operacional, com uma pontuação do Advisor. O Google Cloud Recommender, parte do Active Assist, sugere ações como redimensionar máquinas virtuais ociosas.

Compre, contrate ou denuncie

Marketplaces vendem software, dados e serviços de terceiros por meio da fatura de nuvem. Eles podem simplificar as compras e o acompanhamento dos direitos de uso, isto é, quem tem permissão para usar o software comprado. Eles não são filas de suporte técnico. Use um parceiro ou uma equipe de consultoria do provedor quando precisar de experiência para executar uma migração ou projetar a organização.

O AWS Trust and Safety trata suspeitas de abuso provenientes de recursos da AWS, como spam, varredura, tráfego de negação de serviço ou malware. Qualquer pessoa pode denunciar suspeitas de abuso; esse é um caminho diferente de um chamado de suporte sobre sua própria aplicação.

Associe uma solicitação concreta ao serviço: “O que mudou na integridade dos serviços da nossa assinatura?” pede a visualização personalizada de integridade. “Quem pode ajudar a executar nossa migração?” pede um parceiro de consultoria ou o Professional Services. “Onde podemos licenciar um firewall em nossa fatura de nuvem?” pede o marketplace. “Quais recursos parecem ociosos?” pede uma ferramenta de orientação ou recomendação, seguida da avaliação das necessidades da carga de trabalho pelo responsável.

Um framework de boa arquitetura organiza boas práticas para projetar e operar uma carga de trabalho. Seus pilares ajudam uma equipe a fazer perguntas equilibradas sobre o sistema. Ele oferece orientação para revisão e melhoria, não é uma certificação nem um padrão de conformidade.

Conheça os pilares e seus significados

A AWS tem seis pilares: excelência operacional, segurança, confiabilidade, eficiência de desempenho, otimização de custos e sustentabilidade. O Azure tem cinco: confiabilidade, segurança, otimização de custos, excelência operacional e eficiência de desempenho. O Google Cloud tem seis: excelência operacional; segurança, privacidade e conformidade; confiabilidade; otimização de custos; otimização de desempenho; e sustentabilidade.

Excelência operacional significa operar e melhorar sistemas por meio de monitoramento, automação e alterações seguras. Segurança protege sistemas e dados. Confiabilidade significa recuperar-se de falhas e continuar cumprindo as funções pretendidas. Eficiência ou otimização de desempenho significa atender à demanda com recursos adequados e escalonamento. Otimização de custos busca o menor custo adequado para o valor de negócios exigido. Sustentabilidade considera o impacto ambiental da carga de trabalho.

O pilar de custos conecta a precificação ao projeto: medir gastos, atribuí-los a responsáveis, escolher modelos de compra adequados e revisar o uso. Um serviço gerenciado pode reduzir o custo operacional total mesmo quando sua cobrança direta supera a cobrança da máquina virtual de uma alternativa gerenciada pelo próprio cliente.

Transforme perguntas em um plano de melhoria

O AWS Well-Architected Tool é um serviço gratuito no console para revisar uma carga de trabalho por meio de perguntas para cada pilar. Ele registra problemas de risco alto e médio e apoia um plano de melhoria. Lentes acrescentam perguntas para tipos de carga de trabalho, como as sem servidor. O Azure oferece uma avaliação Well-Architected Review, e o Azure Advisor organiza recomendações em torno de seus pilares.

Em uma revisão, a ausência de orçamento identifica um problema de custos. Um banco de dados em execução em uma zona de disponibilidade expõe um risco de confiabilidade. A ausência de autenticação multifator em contas de administrador é um problema de segurança. Implantações manuais sugerem riscos operacionais. Priorize a ausência de MFA e a exposição a falhas conforme os requisitos e o impacto da carga de trabalho; não trate todas as descobertas como igualmente urgentes.

Explique as vantagens e desvantagens

Uma segunda região pode melhorar a resiliência, mas acrescenta custos de infraestrutura, replicação e transferência. Uma duplicação completa aproximadamente dobra o custo dos componentes duplicados. Um ambiente em espera menor custa menos e geralmente leva mais tempo para restaurar a capacidade completa. Nenhuma das opções pode ser escolhida de forma sensata sem um requisito de tempo de interrupção e recuperação aceitável.

Uma redução de custos que elimina uma cópia necessária para recuperação pode prejudicar a confiabilidade. Controles adicionais de segurança podem acrescentar esforço e despesas enquanto reduzem riscos. O objetivo é um equilíbrio justificável, não a pontuação máxima possível em cada pilar separadamente.

Imagine um serviço que tolera uma interrupção de várias horas e outro que perde uma receita significativa após alguns minutos. O mesmo projeto caro com uma segunda região pode ter valores diferentes para os dois serviços. Registre o requisito de negócios por trás da escolha e revise-o quando o tráfego, a arquitetura ou a criticidade mudar.

Uma revisão de boa arquitetura se concentra em uma carga de trabalho. Um plano para toda a organização envolvendo habilidades, governança e migração usa um framework de adoção da nuvem. Mantenha os dois níveis conectados: padrões para toda a organização ajudam as equipes, enquanto descobertas nas cargas de trabalho revelam lacunas práticas nesses padrões.

Um framework de adoção da nuvem orienta a migração de uma organização para a nuvem. Ele conecta objetivos de negócios, pessoas, governança, segurança e operações ao trabalho técnico. Uma revisão de boa arquitetura pergunta como uma carga de trabalho deve funcionar; a orientação de adoção pergunta como a organização se prepara para desenvolver e operar muitas cargas de trabalho.

Use as perspectivas e fases da AWS

O AWS CAF agrupa capacidades em seis perspectivas. Business, People e Governance se concentram em capacidades de negócios. Platform, Security e Operations se concentram em capacidades técnicas. Uma análise de viabilidade pertence a Business; habilidades da equipe, a People; gerenciamento financeiro da nuvem, a Governance.

Suas fases de jornada são Envision, Align, Launch e Scale. A AWS descreve resultados desejados que incluem redução de riscos de negócios, melhoria do desempenho ambiental, social e de governança, aumento da receita e melhoria da eficiência operacional. As perspectivas descrevem áreas de capacidade; as fases descrevem a jornada. Elas respondem a diferentes perguntas de organização.

Situe as tarefas do Azure em seu framework

As sete fases da Microsoft são Strategy, Plan, Ready, Adopt, Govern, Secure e Manage. Strategy define por que adotar e como reconhecer o sucesso. Plan prepara pessoas e cargas de trabalho. Ready estabelece o ambiente. Adopt migra, moderniza e desenvolve cargas de trabalho. Govern controla o ambiente, Secure o protege e Manage o opera e melhora.

Govern, Secure e Manage continuam junto com as cargas de trabalho em execução. São responsabilidades contínuas, não três tarefas deixadas para depois que toda migração terminar.

Uma zona de destino é o ambiente preparado para cargas de trabalho, com contas ou assinaturas, identidade, rede, registros, políticas e estrutura de faturamento. As zonas de destino do Azure apoiam Ready; o AWS Control Tower ajuda a configurar um ambiente com várias contas e controles. Prepare essas bases antes que as equipes comecem a implantar cargas de trabalho em um ambiente sem governança.

Avalie a maturidade do Google Cloud

O Google Cloud Adoption Framework usa quatro temas: Learn, Lead, Scale e Secure. Ele avalia cada um nas fases tática, estratégica e transformacional da Escala de maturidade da nuvem do Google. O trabalho tático se concentra em cargas de trabalho individuais sem um plano de longo prazo. O trabalho estratégico prepara para necessidades futuras. Organizações transformacionais operam sem problemas e se concentram em inovação e dados.

Uma equipe pode precisar melhorar em liderança ou habilidades mesmo quando sua plataforma técnica é forte. Avalie os temas para identificar qual capacidade organizacional atrasa a adoção; comprar mais serviços não fornece pessoas treinadas nem um plano compartilhado.

Associe tarefas reais sem misturar os vocabulários

Para uma varejista, “reduzir os custos do centro de dados em 20% em três anos” pertence a Strategy da Microsoft e à perspectiva Business da AWS. “Treinar 40 funcionários” se encaixa em Plan da Microsoft e People da AWS. “Preparar contas, rede e políticas” se encaixa em Ready da Microsoft e Platform da AWS. Migrar 30 aplicações se encaixa em Adopt da Microsoft; etiquetas e orçamentos se encaixam em Govern e Governance da AWS. Monitorar serviços em execução se encaixa em Manage da Microsoft e Operations da AWS.

Use os nomes próprios de cada provedor ao explicar a associação. A AWS não tem uma fase chamada Ready, e o tema Learn do Google não é uma fase do Azure. Adapte a orientação aos objetivos da organização, ordene o trabalho conforme as dependências e mantenha a governança e as operações ativas após a chegada das primeiras cargas de trabalho.