As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Modos e aplicativos ou cargas de trabalho do AMS
Considere os requisitos operacionais e de governança para seus aplicativos ao selecionar o modo certo, seja solicitando uma nova conta de aplicativo ou hospedando o aplicativo em uma conta de aplicativo existente. A seleção do modo AMS apropriado para cada aplicativo ou carga de trabalho depende dos seguintes fatores:
O tipo de função do ciclo de vida do SDLC que o ambiente fornecerá (por exemplo, sandbox com mudanças não moderadas, UAT com algumas mudanças frequentes, produção com alterações mínimas e altamente regulamentada)
As políticas de governança necessárias (aplicadas SCPs no nível da OU)
Modelo operacional (se você quiser assumir a responsabilidade operacional ou terceirizá-la para a AMS)
Os resultados comerciais desejados, como tempo para operar na nuvem e custo das operações.
nota
Para obter uma descrição dos tipos de modo por serviço do AMS, consulte Tipos de modos e contas no AMS.
Para casos de uso reais dos diferentes modos, consulte Casos de uso do mundo real para modos AMS
A tabela a seguir descreve as principais considerações para os proprietários de aplicativos ajudarem a decidir sobre o modo AMS mais adequado. Os proprietários do aplicativo devem incluir uma fase de avaliação antes da migração do aplicativo para entender completamente qual modo se aplica ao aplicativo específico. Exemplo: Para aplicativos baseados em serviços nativos da nuvem ou arquitetura sem servidor, a melhor opção pode ser começar a criar e iterar no modo Desenvolvedor e implantar a infraestrutura final como código usando o modo AMS Managed — SSP. Nesse caso, a refatoração leve pode ser necessária para garantir que todos os CloudFormation modelos criados para implantação automatizada atendam às diretrizes de ingestão estabelecidas pela AMS. Além disso, todas as permissões do IAM precisam ser aprovadas pela AMS Security para garantir que sigam o modelo de menor privilégio.
O modo AMS selecionado para hospedar o aplicativo pode ajudar a permitir que você desenvolva o modelo operacional de nuvem desejado.
nota
Mais de um modelo operacional em nuvem pode existir em uma única zona de aterrissagem gerenciada pelo AMS com base nos diferentes modos do AMS selecionados para hospedar os aplicativos.
| Problemas de decisão | Modo CM padrão/ OOD * | AWS Service Catalog | Modo de mudança direta | Provisionamento por autoatendimento | Modo de desenvolvedor | Gerenciado pelo cliente |
|---|---|---|---|---|---|---|
| Prontidão operacional | ||||||
| Registro, monitoramento e gerenciamento de eventos | AMS responsável por toda a infraestrutura gerenciada | Cliente responsável pelos serviços provisionados de autoatendimento (SSP) | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | Cliente responsável | ||
| Gerenciamento de continuidade | Responsabilidade do AMS de executar o plano de backup selecionado pelo cliente | Cliente responsável pelos serviços provisionados de autoatendimento (SSP) | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | |||
| Gerenciamento de acesso em nível de instância | Gerenciado pelo AMS por meio de confiança unidirecional do AD com domínio local. Requer infraestrutura gerenciada para ingressar no domínio AMS | Não aplicável | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | |||
| Gerenciamento de segurança e gerenciamento de acesso em nível de conta | Responsabilidade do AMS por todas as contas gerenciadas | AMS responsável por todas as contas gerenciadas | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | |||
| Gerenciamento de patches | Responsabilidade do AMS por todas as contas gerenciadas | Cliente responsável pelos serviços provisionados de autoatendimento (SSP) | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | |||
| Gerenciamento de alterações | Responsabilidade do AMS por todas as contas gerenciadas | Cliente responsável pelos serviços provisionados de autoatendimento (SSP) | Cliente responsável pelos recursos provisionados usando a função IAM de desenvolvedor fora do sistema AMS CM | |||
| Gerenciamento de provisionamento | Prescritivo e padronizado para as opções de provisionamento oferecidas no AMS | Flexibilidade para usar diretamente a API de serviços da AWS para o AWS Service Catalog seguindo os padrões prescritivos da AMS | Flexibilidade para usar diretamente a API de serviços da AWS seguindo os padrões prescritivos da AMS | Flexibilidade para usar diretamente o serviço da AWS APIs para serviços SSP | Flexibilidade para usar diretamente a API de serviços da AWS para provisionamento | |
| Gerenciamento e auditoria de incidentes | AMS responsável por todas as contas gerenciadas | Cliente responsável pelos recursos provisionados usando a função de desenvolvedor IAM fora do AMS Change Management System | ||||
| GuardRails e infraestrutura compartilhada (rede) e estrutura de segurança | Prescritivo e padronizado, aproveitando as contas principais do AMS | Aproveitando as contas principais do AMS de forma flexível e personalizada | ||||
| Prontidão de aplicação | ||||||
| Refatoração de aplicativos | A refatoração da luz é necessária | A refatoração de luz é necessária (se provisionada usando o AMS Standard CM) | Não há necessidade de refatoração | |||
| Support para serviços da AWS | Limitado ao que é suportado pelo AMS | Não limitado | ||||
| Considerações de negócios | ||||||
| Tempo até a prontidão operacional | Três a seis meses | Mais de 6 meses, dependendo das competências operacionais de aplicativos do cliente | 6 a 18 meses, dependendo da infraestrutura do cliente e das competências em operações de aplicativos | |||
| Custos | $$$$ | $$$ | $$ | $ | ||
| Exemplos de aplicação | Servidor web com pilha de 3 níveis, aplicativos com requisitos regulatórios e de conformidade | Servidor web usando API Gateway, aplicativo em contêiner que utiliza ECS/EKS | Iterando/otimizando no aplicativo Data Lake que usa Lambda, Glue, Athena etc. | Descentralizado, accounts/applications como sandbox, aplicativos gerenciados por terceiros | ||
* Operations On Demand (OOD) tem uma oferta para clientes que usam o modo CM padrão para gerenciar suas alterações por meio de recursos dedicados. Para obter mais detalhes, consulte o catálogo de ofertas do Operations on Demand e fale com seu gerente de prestação de serviços em nuvem (CSDM).
nota
A comparação de preços entre o modo SSP e o modo Desenvolvedor pressupõe que os mesmos serviços da AWS sejam provisionados.
Comparando os modos AMS com os objetivos de negócios e de TI
Conforme mostrado, se você estiver procurando por um modelo de governança altamente controlado e padronizado para seus aplicativos, os modos Standard Change, AWS Service Catalog ou Direct Change gerenciados pela AMS são os mais adequados. Se você precisar de um modelo de governança personalizado com foco na inovação de aplicativos sem a necessidade de prontidão operacional, selecione o modo Gerenciado pelo Cliente. Com o modo Gerenciado pelo Cliente, pode levar mais tempo para operacionalizar seus aplicativos, pois você assume a responsabilidade de estabelecer pessoas, processos e ferramentas para dar suporte a recursos operacionais, como gerenciamento de incidentes, gerenciamento de configuração, gerenciamento de provisionamento, gerenciamento de segurança, gerenciamento de patches etc.
