Casos de uso do mundo real para modos AMS

Caso de uso 1, imperativo comercial de reduzir custos com uma saída urgente do data center: uma empresa com um evento comercial atraente, como a saída de um data center, está interessada em rehospedar seus aplicativos locais na nuvem. A maior parte do inventário local consiste em servidores Windows e Linux com uma combinação de versões do sistema operacional. Ao fazer isso, o cliente também quer aproveitar a economia de custos que a mudança para a nuvem oferece e melhorar a postura técnica e de segurança de seus aplicativos. O cliente quer agir rapidamente, mas ainda não tem a experiência interna em operações de nuvem desenvolvida. O cliente precisa encontrar um equilíbrio entre a refatoração. Refatorar demais pode ser arriscado em um cronograma apertado. No entanto, com algumas refatorações, como atualizar as versões do sistema operacional e otimizar bancos de dados, os aplicativos podem alcançar o próximo nível de desempenho. Neste exemplo, o cliente pode selecionar o modo RFC gerenciado pelo AMS para rehospedar a maioria de seus aplicativos. O AMS fornece operações de infraestrutura, além de orientar as equipes de operações do cliente sobre as melhores práticas para operar com segurança na nuvem.

O AWS Service Catalog gerenciado pela AMS e o modo Direct Change gerenciado pela AMS oferecem ao cliente uma flexibilidade extra, ao mesmo tempo em que alcança os mesmos resultados e objetivos comerciais. Além disso, o cliente pode usar a oferta do AMS Operations On Demand (OOD) para ter engenheiros de operações dedicados do AMS para priorizar a execução de solicitações de mudança (). RFCs

Ao transferir as tarefas operacionais indiferenciadas da infraestrutura (aplicação de patches, backups, gerenciamento de contas etc.) para o AMS, o cliente pode continuar se concentrando na otimização de seus aplicativos e na capacitação de suas equipes internas nas operações em nuvem. O AMS fornece relatórios mensais ao cliente sobre economia de custos e faz recomendações sobre otimizações de recursos. Nesse caso de uso, se houvesse end-of-life aplicativos hospedados em versões antigas do sistema operacional, como Windows 2003 e 2008, que o cliente decidisse não refatorar, eles também podem ser migrados para o AMS e hospedados em uma conta que utiliza o modo Gerenciado pelo Cliente.

Caso de uso 2, criando um data lake com Lambda, Glue e Athena dentro do limite seguro do AMS: uma empresa está procurando configurar um data lake para atender às necessidades de geração de relatórios de vários aplicativos no AMS. O cliente quer usar buckets S3 para o armazenamento de conjuntos de dados e o AWS Athena para consultar o conjunto de dados para cada relatório. O S3 e o AWS Athena serão implantados em contas gerenciadas separadas pelo AMS. A conta com o S3 também tem outros serviços, como Glue, Lambda e Step Functions, para criar um pipeline de ingestão de dados. Glue, Lambda, Athena e Step Functions são considerados serviços de provisionamento de autoatendimento (SSP) nesse caso. O cliente também implantou uma EC2 instância na conta que atua como um servidor ad hoc tooling/scripting . O cliente começa solicitando que o AMS habilite os serviços SSP em sua conta gerenciada pelo AMS. O AMS provisiona uma função do IAM para cada serviço que o cliente pode assumir, uma vez que a função é integrada à solução de federação do cliente. Para facilitar o gerenciamento, o cliente também pode combinar as políticas para as funções separadas do IAM em uma função personalizada, aliviando a necessidade de alternar funções ao trabalhar entre os serviços da AWS. Depois que a função é ativada na conta, o cliente pode configurar os serviços de acordo com seus requisitos. No entanto, o cliente deve trabalhar com o sistema de gerenciamento de alterações do AMS para solicitar permissões adicionais, dependendo do caso de uso.

Por exemplo, para acessar o Glue Crawlers, o Glue precisa de permissões adicionais. Também serão necessárias permissões adicionais para criar fontes de eventos para o Lambda. O cliente trabalhará com o AMS para atualizar as funções do IAM para permitir o acesso entre contas para que o Athena consulte buckets do S3. Atualizações nas funções de serviço ou funções vinculadas a serviços também serão necessárias por meio do gerenciamento de alterações do AMS para que o Lambda chame o serviço Step Functions e o Glue para ler e gravar em todos os buckets do S3. O AMS trabalha com os clientes para garantir que o modelo de acesso com privilégios mínimos seja seguido e que as alterações solicitadas no IAM não sejam excessivamente permissivas e exponham o ambiente a riscos desnecessários. A equipe de data lake do cliente gasta tempo planejando todas as permissões do IAM necessárias para os serviços específicos da arquitetura do cliente e solicita que o AMS as habilite. Isso ocorre porque todas as alterações do IAM são processadas manualmente e submetidas à análise da equipe de segurança do AMS. O tempo para processar essas solicitações deve ser contabilizado no cronograma de implantação do aplicativo.

Como os serviços SSP estão operacionais na conta, o cliente pode solicitar suporte e relatar problemas por meio do gerenciamento de incidentes e solicitações de serviço do AMS. No entanto, o AMS não monitorará ativamente as métricas de desempenho e simultaneidade do Lambda ou as métricas de trabalho do Glue. É responsabilidade do cliente garantir que o registro e o monitoramento adequados estejam habilitados para os serviços SSP. A EC2 instância e o bucket S3 na conta são totalmente gerenciados pelo AMS.

Caso de uso 3, configuração rápida e flexível de um pipeline de implantação de CICD no AMS: um cliente está procurando configurar um pipeline de CICD baseado em Jenkins para implantar um pipeline de código em todas as contas de aplicativos no AMS. O cliente pode achar mais adequado hospedar esse pipeline do CICD no modo Direct Change (DCM) gerenciado pelo AMS ou no modo Desenvolvedor gerenciado pelo AMS, pois isso oferece flexibilidade para configurar o servidor Jenkins com a configuração personalizada necessária ativada EC2, com as permissões de acesso do IAM desejadas CloudFormation e os buckets do S3 que hospedam o repositório de artefatos. Embora isso também possa ser feito no modo RFC gerenciado pelo AMS, a equipe do cliente precisaria criar vários manuais para funções do IAM RFCs para iterar o conjunto menos permissivo de permissões aprovadas, que são revisadas manualmente pelo AMS. O DCM permite que os clientes atinjam suas metas operacionais na AWS, evitando a necessidade de criar vários manuais RFCs para funções do IAM, ao usar o modo RFC gerenciado pela AMS, para iterar no conjunto menos permissivo de permissões aprovadas, que são revisadas manualmente pelo AMS. Isso levaria tempo, além de educação por parte do cliente, para aprimorar os processos e ferramentas do AMS. Trabalhando com o modo Desenvolvedor, o cliente pode começar com uma “função de desenvolvedor” para provisionar a infraestrutura usando a AWS nativa APIs. A maneira mais rápida e flexível de configurar esse pipeline seria usar o modo AMS Managed-Developer. O modo de desenvolvedor oferece a maneira mais rápida e fácil, ao mesmo tempo que compromete a integração operacional, enquanto o DCM é menos flexível, mas fornece o mesmo nível de suporte operacional do modo RFC.

Caso de uso 4, modelo operacional personalizado dentro da base da AMS: um cliente está considerando a saída do data center com prazos determinados e um de seus aplicativos corporativos é totalmente gerenciado por um MSP terceirizado, incluindo operações de aplicativos e operações de infraestrutura. Supondo que o cliente não tenha tempo no cronograma para refatorar esse aplicativo para que ele possa ser operado pelo AMS, o modo Customer Managed é uma opção adequada. O cliente pode aproveitar a configuração rápida e automatizada da Zona de Aterrissagem gerenciada pela AMS. Eles podem aproveitar o gerenciamento centralizado de contas que controla a venda e a conectividade da conta por meio da conta de rede centralizada. Também simplifica o faturamento ao consolidar as cobranças de todas as contas gerenciadas pelo cliente por meio da conta AMS Payer. O cliente tem flexibilidade para configurar seu modelo de gerenciamento de acesso personalizado com o MSP, separado do gerenciamento de acesso padrão usado para contas gerenciadas pelo AMS. Dessa forma, usando o modo Customer Managed, eles podem configurar um ambiente gerenciado pelo AMS e, ao mesmo tempo, atender aos requisitos comerciais de desocupar seu ambiente local. Nesse caso, se o cliente também tiver aplicativos baseados no Windows que está migrando para a nuvem e optar por movê-los para uma conta gerenciada pelo cliente, o cliente será responsável por criar um modelo operacional em nuvem. Isso pode ser complexo, caro e demorado, dependendo da capacidade do cliente de transformar os processos tradicionais de TI e treinar pessoas. O cliente pode economizar tempo e custos “transferindo e transferindo” essas cargas de trabalho para uma conta gerenciada pelo AMS e transferindo as operações de infraestrutura para o AMS.