COST05-BP03 Executar uma análise completa de cada componente
Observe o custo geral de cada componente para a organização. Calcule o custo total de propriedade considerando o custo de operações e gerenciamento, especialmente ao usar serviços gerenciados pelo provedor de nuvem. O esforço de análise deve refletir o benefício potencial (por exemplo, o tempo gasto na análise é proporcional ao custo do componente).
Nível de exposição a riscos quando esta prática recomendada não é estabelecida: Alto
Orientações para a implementação
Considere a economia de tempo que permitirá que sua equipe se concentre na retirada de recursos de endividamento técnico, inovação, agregação de valor e criação do que diferencia os negócios. Por exemplo, talvez você precise mover sem alterações (lift-and-shift) seu ambiente on-premises para a nuvem (também conhecido como redefinir a hospedagem) e otimizar mais tarde. Vale a pena explorar as possíveis economias obtidas com o uso de serviços gerenciados na AWS que removem ou reduzem os custos de licença. Serviços gerenciados na AWS eliminam a sobrecarga operacional e administrativa da manutenção de um serviço, como aplicação de patches ou atualização do sistema operacional, e permitem que você se concentre na inovação e nos negócios.
Uma vez que os serviços gerenciados operam em escala da nuvem, eles podem oferecer menor custo por transação ou serviço. Você pode realizar possíveis otimizações para alcançar alguns benefícios tangíveis, sem alterar a arquitetura principal da aplicação. Por exemplo, você pode tentar reduzir o tempo gasto no gerenciamento de instâncias de banco de dados migrando para uma plataforma de banco de dados como serviço, como o Amazon Relational Database Service (Amazon RDS)
Geralmente, os serviços gerenciados têm atributos que você pode definir para garantir capacidade suficiente. Você deve definir e monitorar esses atributos para que sua capacidade em excesso seja mínima e a performance seja maximizada. Você pode modificar os atributos do AWS Managed Services usando o AWS Management Console ou as APIs e os SDKs da AWS para alinhar as necessidades de recursos com a demanda em constante mudança. Por exemplo, você pode aumentar ou diminuir o número de nós em um cluster do Amazon EMR (ou em um cluster do Amazon Redshift) para aumentar ou reduzir a escala horizontalmente.
Você também pode unir várias instâncias em um recurso da AWS para ativar usos de maior densidade. Por exemplo, você pode provisionar vários bancos de dados pequenos em uma única instância de banco de dados do Amazon Relational Database Service (Amazon RDS). Conforme o uso aumenta, você pode migrar um dos bancos de dados para uma instância de banco de dados Amazon RDS dedicada usando um processo de snapshot e restauração.
Ao provisionar workloads em serviços gerenciados, você deve compreender os requisitos de ajuste da capacidade do serviço. Esses requisitos geralmente são tempo, esforço e qualquer impacto na operação normal da workload. O recurso provisionado deve permitir tempo para que as alterações ocorram, provisionar a sobrecarga necessária para permitir isso. O trabalho contínuo necessário para modificar os serviços pode ser reduzido a praticamente zero usando APIs e SDKs integrados a ferramentas de sistema e monitoramento como o Amazon CloudWatch.
O Amazon RDS
AMS
Etapas da implementação
-
Realização de uma análise completa: usando a lista de componentes, trabalhe com cada componente da maior prioridade para a menor. Para componentes de prioridade maior e mais caros, execute análises adicionais e avalie todas as opções disponíveis e o impacto a longo prazo. Para componentes de prioridade menor, avalie se alterações no uso alterariam a prioridade do componente e, em seguida, execute uma análise de esforço apropriado.
-
Comparação de recursos gerenciados e não gerenciados: considere o custo operacional dos recursos que você gerencia e compare-os com recursos gerenciados pela AWS. Por exemplo, analise seus bancos de dados em execução em instâncias do Amazon EC2 e compare-os com as opções do Amazon RDS (um serviço gerenciado pela AWS) ou do Amazon EMR em comparação com a execução do Apache Spark no Amazon EC2. Ao migrar de uma workload autogerenciada para uma workload totalmente gerenciada pela AWS, pesquise suas opções com cuidado. Os três fatores mais importantes a serem considerados são o tipo de serviço gerenciado
que você deseja usar, o processo utilizado para migrar seus dados e o entendimento do modelo de responsabilidade compartilhada da AWS .
Recursos
Documentos relacionados:
-
AWS Total Cost of Ownership (TCO) Calculator
(Calculadora de custo total de propriedade (TCO) da AWS)
Vídeos relacionados:
-
Why move to a managed database?
(Por que migrar para um banco de dados gerenciado?) -
What is Amazon EMR and how can I use it for processing data?
(O que é o Amazon EMR e como usá-lo para processar dados?)
Exemplos relacionados:
-
Why to move to a managed database
(Por que migrar para um banco de dados gerenciado?) -
Consolidate data from identical SQL Server databases into a single Amazon RDS for SQL Server database using AWS DMS
(Consolidar dados de bancos de dados idênticos do Consolidate SQL Server em um banco de dados único do Amazon RDS for SQL Server usando o AWS DMS) -
Deliver data at scale to Amazon Managed Streaming for Apache Kafka (Amazon MSK)
(Entregar dados em grande escala para o Amazon Managed Streaming for Apache Kafka (Amazon MSK)) -
Migrate an ASP.NET web application to AWS Elastic Beanstalk
(Migrar uma aplicação Web ASP.NET para o AWS Elastic Beanstalk)