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á. # Avaliação priorizada de aplicativos Um dos principais resultados da etapa anterior, [descoberta do portfólio e planejamento inicial](portfolio-discovery-initial-planning.md), foi [priorizar um subconjunto de aplicativos](prioritization-and-migration-strategy.md#prioritizing-applications) para avaliação detalhada. Esta seção explora a avaliação detalhada dos aplicativos. Analisar os detalhes de alguns aplicativos logo no início impulsionará a aceleração. O processo de avaliação e o futuro projeto da arquitetura revelam possíveis bloqueadores e esclarecem tarefas importantes que são precursoras da migração de maior escopo. Essas tarefas incluem reunir requisitos para estabelecer AWS fundações, como a zona de pouso ativada AWS, ou para estender e validar a zona de pouso existente. Essa avaliação também é o momento de considerar as etapas e a estratégia para a migração. Os principais resultados desse estágio são os seguintes: + Lista validada de aplicativos priorizados + Arquitetura do estado atual documentada + Arquitetura de destino inicial e estratégia de migração documentadas para candidatos à migração + Padrões de migração e ferramentas identificados + Requisitos documentados da plataforma (segurança, AWS infraestrutura e operações) + Considerações de transição documentadas para o planejamento da migração + Taxa de AWS execução estimada # Compreender os requisitos detalhados de dados de avaliação A tabela a seguir descreve as informações necessárias para obter uma visão completa do portfólio dos aplicativos na migração e da infraestrutura associada. As tabelas usam as seguintes abreviações: + R, se necessário + O, para opcional + N/A, se não aplicável **Aplicativos** | **Nome do atributo** | **Descrição** | **Estratégia de descoberta, design e migração** | **Taxa de execução estimada** | **Nível de fidelidade recomendado (mínimo)** | | --- |--- |--- |--- |--- | | Identificador exclusivo | Por exemplo, ID do aplicativo. Normalmente disponível em inventários e sistemas de controle internos existentes CMDBs ou outros. Considere criar itens exclusivos IDs sempre que eles não estiverem definidos em sua organização. | R | O | Alto | | Nome da aplicação | Nome pelo qual esse aplicativo é conhecido pela sua organização. Inclua o nome comercial off-the-shelf (COTS) do fornecedor e do produto quando aplicável. | R | R | Alto | | É COTS? | Sim ou não. Seja um aplicativo comercial ou um desenvolvimento interno | R | R | Alto | | Produto e versão COTS | Nome e versão do produto de software comercial | R | R | Alto | | Description | Função e contexto primários do aplicativo | R | O | Alto | | Criticidade | Por exemplo, aplicativo estratégico ou gerador de receita ou suporte a uma função crítica | R | O | Alto | | Tipo | Por exemplo, banco de dados, gerenciamento de relacionamento com o cliente (CRM), aplicativo web, multimídia, serviço compartilhado de TI | R | O | Alto | | Environment | Por exemplo, produção, pré-produção, desenvolvimento, teste, sandbox | R | R | Alto | | Conformidade e regulamentação | Estruturas aplicáveis à carga de trabalho (por exemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e aos requisitos normativos | R | O | Alto | | Dependências | Dependências ascendentes e posteriores de aplicativos ou serviços internos e externos | R | N/D | Alto | | Mapeamento de infraestrutura | Mapeamento para ativos and/or virtuais físicos que compõem o aplicativo | R | R | Alto | | Licença | Tipo de licença de software comum (por exemplo, Microsoft SQL Server Enterprise) | R | R | Alto | | Custo | Custos de licença de software, operações e manutenção de software | N/D | R | Médio-alto | | Unidade de negócios | Por exemplo, marketing, finanças, vendas | R | O | Alto | | Detalhes do proprietário | Informações de contato do proprietário do aplicativo | R | O | Alto | | Tipo de arquitetura | Por exemplo, aplicativo web, 2 camadas, 3 camadas, microsserviços, arquitetura orientada a serviços (SOA) | R | R | Alto | | Objetivo de ponto de recuperação (RPO), objetivo de tempo de recuperação (RTO) e /contrato de nível de serviço (SLA) | Atributos atuais de gerenciamento de serviços | R | R | Alto | | Aplicativo gerador de receita ou aplicativo estratégico de negócios? | Sim, se o aplicativo influenciar direta ou indiretamente a receita da empresa ou for considerado estratégico pela empresa. | R | O | Médio-alto | | Número de usuários (simultâneo) | Por exemplo, usuários internos ou externos ou usuários/clientes and/or externos internos | R | R | Médio-alto | | Localização do usuário | Origem das sessões do usuário | R | R | Médio-alto | | Riscos e problemas | Riscos e problemas conhecidos | R | O | Médio-alto | | Considerações sobre a migração | Qualquer informação adicional que possa ser relevante para a migração | R | R | Médio-alto | | Estratégia de migração | Por exemplo, um dos AWS 6 Rs para migração | R | R | Médio-alto | | Detalhes do banco de dados | Por exemplo, particionamento, criptografia, replicação, extensões, suporte ao Secure Sockets Layer (SSL) | R | R | Alto | | Equipes de suporte | Por exemplo, nome da equipe de operações do aplicativo | R | O | Médio-alto | | Solução de monitoramento | Produto usado para monitorar este aplicativo | R | O | Médio-alto | | Requisitos de backup | Programação de backup necessária em AWS | R | R | Médio-alto | | Informações sobre DR | Por exemplo, componentes de recuperação de desastres para esse aplicativo | R | R | Médio-alto | | AWS Requisitos do alvo | Por exemplo, componentes, posicionamento da conta, rede, segurança | R | R | Alto | **Infraestrutura** | | | | | | | --- |--- |--- |--- |--- | | **Nome do atributo** | **Descrição** | **Estratégia de descoberta, design e migração** | **Taxa de execução estimada** | **Nível de fidelidade recomendado (mínimo)** | | Identificador exclusivo | Por exemplo, ID do servidor. Normalmente disponível em inventários e sistemas de controle internos existentes CMDBs ou outros. Considere criar itens exclusivos IDs sempre que eles não estiverem definidos em sua organização. | R | O | Alto | | Nome da rede | Nome do ativo na rede (por exemplo, nome do host) | R | O | Alto | | Nome DNS (nome de domínio totalmente qualificado ou FQDN) | Nome DNS | O | O | Médio-alto | | Endereço IP e máscara de rede | Endereços IP and/or públicos internos | R | R | Alto | | Asset type (Tipo de ativo) | Por exemplo, servidor físico ou virtual, hipervisor, contêiner, dispositivo, instância de banco de dados | R | R | Alto | | Nome do produto | Fornecedor comercial e nome do produto (por exemplo VMware ESXi, IBM Power Systems, Exadata) | R | R | Alto | | Sistema operacional | Por exemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Alto | | Configuração | CPU alocada, número de núcleos, threads por núcleo, memória total, armazenamento, placas de rede | R | R | Alto | | Utilização | Pico e média de CPU, memória e armazenamento. Taxa de transferência da instância de banco de dados. | R | R | Alto | | Licença | Tipo de licença de mercadoria (por exemplo, RHEL Standard) | R | R | Alto | | A infraestrutura é compartilhada? | Sim ou Não para indicar serviços de infraestrutura que fornecem serviços compartilhados, como provedor de autenticação, sistemas de monitoramento, serviços de backup e serviços similares | R | O | Alto | | Mapeamento de aplicativos | Aplicativos ou componentes de aplicativos que são executados nessa infraestrutura | R | O | Alto | | Dados de comunicação | Por exemplo, servidor para servidor em um nível de processo | R | N/D | Médio-alto | | AWS Requisitos do alvo | Por exemplo, tipos de instância, conta, sub-redes, grupos de segurança, roteamento | R | R | Alto | | Estratégia, padrões e ferramentas de migração | Por exemplo, um dos 6 Rs para migração, padrão técnico específico, ferramentas de migração | R | O | Alto | | Riscos e problemas | Riscos e problemas conhecidos | R | O | Médio-alto | # Avaliação detalhada da aplicação O objetivo de uma avaliação detalhada do aplicativo é a compreensão completa do aplicativo de destino e da infraestrutura associada (computação, armazenamento e rede). Dados de alta fidelidade são necessários para evitar armadilhas. Por exemplo, é comum que as organizações presumam que compreendem completamente o aplicativo. Isso é natural e é verdade em muitos casos. No entanto, para minimizar o risco para o negócio, é importante validar o conhecimento institucional e a documentação estática obtendo dados programáticos o máximo possível. Isso cuidará do trabalho pesado do processo de descoberta. Você pode se concentrar nos elementos de dados provenientes de fontes alternativas, como informações específicas da empresa, roteiros estratégicos e outros. A chave é evitar alterações de última hora durante e após a migração. Por exemplo, ao migrar, é importante evitar alterações com base em dependências não identificadas que possam exigir a inclusão de um servidor em uma onda de migração contínua. Logo após a migração, é importante evitar alterações com base nos requisitos da plataforma associada para permitir o tráfego ou implantar serviços adicionais. Esses tipos de mudanças não planejadas aumentam o risco de problemas operacionais e de segurança. É altamente recomendável usar ferramentas de descoberta programática para validar padrões de tráfego e dependências ao realizar avaliações detalhadas de aplicativos. No início da avaliação, você deve identificar as partes interessadas do aplicativo. Normalmente, são os seguintes: + Líderes da unidade de negócios + Proprietários da aplicação + Arquitetos + Operações e suporte + Equipes de capacitação na nuvem + Equipes de plataformas específicas, como computação, armazenamento e redes Existem duas abordagens para uma descoberta detalhada. A descoberta de cima para baixo começa com o aplicativo, ou mesmo com o usuário, e vai até a infraestrutura. Essa é a abordagem recomendada quando a identificação do aplicativo é clara. Por outro lado, a descoberta de baixo para cima começa com a infraestrutura e vai até o aplicativo ou serviço e seus usuários. Essa abordagem é útil quando os programas de migração são conduzidos por equipes de infraestrutura e quando o application-to-infrastructure mapeamento não é claro. Em geral, é provável que você use uma combinação de ambos. Para se aprofundar em um aplicativo, os diagramas de arquitetura existentes são um bom começo. Se eles não estiverem disponíveis, crie um com base no conhecimento atual. Não subestime a importância dessa tarefa, mesmo para estratégias simples de migração de rehospedagem ou realocação. A plotagem de diagramas arquitetônicos ajuda você a identificar ineficiências que podem ser resolvidas rapidamente com pequenas alterações quando na nuvem. Dependendo se você está executando uma abordagem de cima para baixo ou de baixo para cima, o diagrama inicial traçará componentes e serviços do aplicativo ou componentes de infraestrutura, como servidores e balanceadores de carga. Depois que os principais componentes e interfaces forem identificados, valide-os com dados programáticos de ferramentas de descoberta e ferramentas de monitoramento de desempenho de aplicativos. As ferramentas devem oferecer suporte à análise de dependências e fornecer informações de comunicação entre os componentes. Cada componente que compõe esse aplicativo deve ser identificado. Em seguida, documente as dependências de outros aplicativos e serviços, internos e externos. Na ausência de ferramentas para validar dependências e mapeamento, é necessária uma abordagem manual. Por exemplo, você pode fazer login em componentes de infraestrutura e executar scripts para coletar informações de comunicação, como portas abertas e conexões estabelecidas. Da mesma forma, você pode identificar os processos em execução e o software instalado. Não subestime o esforço necessário para a descoberta manual. As ferramentas programáticas podem capturar e relatar a maioria das dependências em alguns dias, exceto aquelas que ocorrem em intervalos maiores (normalmente uma pequena porcentagem). A descoberta manual pode levar semanas para coletar e mesclar todos os pontos de dados, e ainda pode estar sujeita a erros e dados perdidos. Prossiga com a obtenção das informações especificadas na seção de [requisitos de dados](understanding-detailed-assessment-data-requirements.md) para cada aplicativo priorizado e a infraestrutura mapeada. Em seguida, use o questionário a seguir para orientá-lo no processo detalhado de avaliação. Reúna-se com as partes interessadas identificadas para discutir as respostas a essas perguntas. ## Geral + Qual é o nível de criticidade desse aplicativo? É gerador de receita? É um aplicativo comercial estratégico ou de apoio aos negócios? É um serviço de infraestrutura central compartilhado por outros sistemas? + Há algum projeto de transformação em andamento para esse aplicativo? + Este é um aplicativo voltado para dentro ou para fora? ## Arquitetura + Qual é o tipo de arquitetura atual (por exemplo, SOA, microsserviços, monólito)? Quantos níveis a arquitetura tem? É fortemente acoplado ou fracamente acoplado? + Quais são os componentes (por exemplo, computação, bancos de dados, armazenamento remoto, balanceadores de carga, serviços de cache)? + O que é o APIs? Descreva-os, incluindo nome, operações URLs, portas e protocolos da API. + Qual é a latência máxima tolerada entre componentes e entre esse e outros aplicativos ou serviços? ## Operações + Em quais locais esse aplicativo opera? + Quem opera o aplicativo e a infraestrutura? Eles são operados por equipes internas ou AWS parceiras? + O que acontece se esse aplicativo cair? Quem é afetado? Qual é o impacto? + Onde estão localizados os usuários ou clientes? Como eles acessam o aplicativo? Qual é o número de usuários simultâneos? + Quando foi a última atualização tecnológica? Uma atualização está programada para o futuro? Se sim, quando? + Quais são os riscos e problemas conhecidos desse aplicativo? Qual é o histórico de interrupções e incidentes de gravidade média e alta? + Qual é o ciclo de uso (em horário comercial)? Qual é o fuso horário de operação? + Quais são os períodos de congelamento das alterações? + Qual solução é usada para monitorar esse aplicativo? ## desempenho + O que mostram as informações de desempenho coletadas? O uso é alto ou constante e previsível? Qual é o período, o intervalo e a data dos dados de desempenho disponíveis? + Há trabalhos em lotes agendados que fazem parte ou interagem com esse aplicativo? ## Ciclo de vida do software + Qual é a taxa de variação atual (semanal, mensal, trimestral ou anual)? + Qual é o ciclo de vida do desenvolvimento (por exemplo, teste, desenvolvimento, controle de qualidade, UAT, pré-produção, produção)? + Quais são os métodos de implantação para aplicativos e infraestrutura? + O que são as ferramentas de implantação? + Esse aplicativo ou infraestrutura usa integração contínua (CI) /entrega contínua (CD)? Qual é o nível de automação? Quais são as tarefas manuais? + Quais são os requisitos de licenciamento para o aplicativo e a infraestrutura? + O que é o contrato de nível de serviço (SLA)? + Quais são os mecanismos de teste atuais? Quais são as etapas do teste? ## Migração + Quais são as considerações sobre migração? Neste momento, observe todas as considerações ao migrar esse aplicativo. Para uma avaliação mais completa e precisa, obtenha respostas para essa pergunta das diferentes partes interessadas. Em seguida, compare seus conhecimentos e opiniões. ## Resiliência + Qual é o método de backup atual? Quais produtos são usados para backup? Qual é o cronograma de backup? Qual é a política de retenção de backup? + Quais são o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO) atuais? + Esse aplicativo tem um plano de recuperação de desastres (DR)? Em caso afirmativo, qual é a solução de DR? + Quando foi o último teste de DR? ## Segurança e conformidade + Quais são as estruturas regulatórias e de conformidade que se aplicam a esse aplicativo? Quais são as datas da última e da próxima auditoria? + Esse aplicativo hospeda dados confidenciais? O que é a classificação dos dados? + Os dados são criptografados em trânsito ou em repouso, ou ambos? O que é o mecanismo de criptografia? + Esse aplicativo usa certificados SSL? O que é a autoridade emissora? + Qual é o método de autenticação para usuários, componentes e outros aplicativos e serviços? ## Bancos de dados + Quais bancos de dados esse aplicativo usa? + Qual é o número típico de conexões simultâneas com o banco de dados? Quais são o número mínimo e o número máximo de conexões? + Qual é o método de conexão (por exemplo, JDBC, ODBC)? + As cadeias de conexão estão documentadas? Se sim, onde? + Quais são os esquemas do banco de dados? + O banco de dados usa tipos de dados personalizados? ## Dependências + Qual é a dependência entre os componentes? Observe todas as dependências que não podem ser resolvidas e que exigirão a migração dos componentes juntos. + Os componentes estão divididos entre os locais? Qual é a conectividade entre esses locais (por exemplo, WAN, VPN)? + Quais são as dependências desse aplicativo em relação a outros aplicativos ou serviços? + Quais são as dependências operacionais? Por exemplo, ciclos de manutenção e lançamento, como janelas de patches. # AWS design de aplicativos e estratégia de migração Projetar e documentar o estado futuro do seu aplicativo é um fator-chave para o sucesso da migração. Recomendamos criar um design para qualquer tipo de estratégia de migração, por mais simples ou complexa que seja. A criação do design revelará possíveis bloqueadores, dependências e oportunidades para otimizar o aplicativo, mesmo nos casos em que não se espera que a arquitetura mude. Também recomendamos abordar o estado futuro do aplicativo AWS com uma lente de estratégia de migração. Nesse estágio, certifique-se de definir a aparência do aplicativo AWS como resultado dessa migração. O design resultante servirá como base para uma maior evolução após a migração. A lista a seguir contém recursos para auxiliar no processo de design: + AWS O [Architecture Center](https://aws.amazon.com/architecture/) combina ferramentas e orientações, como o AWS Well-Architected Framework. Além disso, ele fornece arquiteturas de referência que você pode usar para seu aplicativo. + [A Amazon Builders' Library](https://aws.amazon.com/builders-library/) contém vários recursos sobre como a Amazon cria e opera software. + [AWS A Solutions Library](https://aws.amazon.com/solutions/) oferece uma coleção de soluções baseadas em nuvem, avaliadas por AWS, para dezenas de problemas técnicos e comerciais. Ele inclui uma grande coleção de arquiteturas de referência. + AWS A [orientação prescritiva](https://aws.amazon.com/prescriptive-guidance/) fornece estratégias, guias e padrões que auxiliam no processo de design e nas melhores práticas de migração. + [AWS Documentation](https://docs.aws.amazon.com/)contém informações sobre AWS serviços, incluindo guias do usuário e referências de API. + O [Getting Started Resource Center](https://aws.amazon.com/getting-started/) fornece vários tutoriais práticos e mergulhos aprofundados para aprender os fundamentos para que você possa começar a desenvolver. AWS Dependendo de onde você está na jornada para a nuvem, talvez já existam AWS bases. Essas AWS bases incluem o seguinte: + Regiões da AWS foram identificados. + As contas foram criadas ou podem ser obtidas sob demanda. + A rede geral foi implementada. + AWS Serviços básicos foram implantados nas contas. Por outro lado, você pode estar no início do processo e as AWS fundações ainda não estão estabelecidas. A falta de bases estabelecidas pode limitar o escopo do design do aplicativo ou exigir mais trabalho para defini-las. Se for esse o caso, recomendamos definir e implementar o design básico da landing zone em paralelo com o trabalho de design do aplicativo. O design do aplicativo ajuda a identificar requisitos como Conta da AWS estrutura, rede, nuvem privada virtual (VPCs), intervalos de roteamento entre domínios sem classe (CIDR), serviços compartilhados, segurança e operações em nuvem. [AWS Control Tower](https://aws.amazon.com/controltower/)fornece a maneira mais fácil de configurar e controlar um AWS ambiente seguro com várias contas, chamado de landing zone. AWS Control Tower cria sua landing zone usando AWS Organizations, que fornece gerenciamento e governança contínuos de contas e implementação da experiência baseada em AWS melhores práticas trabalhando com milhares de clientes à medida que eles migram para a nuvem. ## Estado futuro do aplicativo Comece estabelecendo a estratégia de migração inicial para esse aplicativo. Nesse ponto, a estratégia é considerada inicial porque pode mudar como parte do design do future state, o que pode revelar possíveis limitações. Para validar as suposições iniciais, consulte a árvore decisória de [6 Rs.](prioritization-and-migration-strategy.md#migration-r-type) Além disso, documente as possíveis fases de migração. Por exemplo, esse aplicativo será migrado em um único evento (todos os componentes serão migrados ao mesmo tempo)? Ou isso é uma migração em fases (alguns componentes são migrados posteriormente)? Observe que as estratégias de migração para um determinado aplicativo podem não ser exclusivas. Isso ocorre porque vários tipos de R podem ser usados para migrar os componentes do aplicativo. Por exemplo, a abordagem inicial pode ser levantar e deslocar o aplicativo sem alterações. No entanto, os componentes de um aplicativo podem residir em diferentes ativos de infraestrutura que podem exigir tratamentos diversos. Por exemplo, um aplicativo é composto por três componentes, cada um executado em um servidor separado, e um dos servidores executa um sistema operacional legado que não é suportado na nuvem. Esse componente exigirá uma abordagem de replataforma, enquanto os outros dois componentes, executados em versões de servidor suportadas, poderão ser hospedados novamente. É fundamental atribuir uma estratégia de migração a cada componente do aplicativo e à infraestrutura associada que está sendo migrada. Em seguida, documente o contexto e o problema e vincule os artefatos existentes que definem o estado atual: + Por que esse aplicativo está sendo migrado? + Quais são as mudanças propostas? + Quais são os benefícios? + Existem riscos ou bloqueadores importantes? + Quais são as desvantagens atuais? + O que está dentro e fora do escopo? ## Repetibilidade Durante todo o trabalho de design, considere como essa solução e a arquitetura desse aplicativo podem ser reutilizadas para outros aplicativos. Essa solução pode ser generalizada? ## Requisitos Documente os requisitos funcionais e não funcionais desse aplicativo, incluindo segurança. Isso inclui os requisitos do estado atual e futuro, dependendo da estratégia de migração escolhida. Use as informações coletadas durante a avaliação detalhada do aplicativo para orientar esse processo. ## Arquitetura futura Descreva a arquitetura futura desse aplicativo. Considere criar um modelo de diagrama reutilizável que contenha elementos básicos para seu ambiente de origem (local) e AWS ambiente de destino (por exemplo, destino Região da AWS VPCs, conta e zonas de disponibilidade). Crie uma tabela de componentes que estão sendo migrados e componentes que serão novos. Inclua outros aplicativos e serviços (no local ou na nuvem) que interajam com esse aplicativo. A tabela a seguir lista exemplos de componentes. Ela não representa uma arquitetura de referência nem uma configuração verificada. | **Name (Nome)** | **Descrição** | **Detalhes** | | --- |--- |--- | | Aplicação | Serviço externo (conexão de entrada) | O serviço consome dados da API exposta. | | DNS | Resolução de nomes (interna) | Amazon Route 53 implantado como parte das configurações básicas da conta | | Application Load Balancer | Distribui o tráfego entre os serviços de back-end | Substitui o balanceador de carga local. Migrar o pool A. | | Segurança de aplicações | Proteção contra DDoS | Implementado usando AWS Shield | | Grupo de segurança | Firewall virtual | Limite o acesso às instâncias do aplicativo na porta 443 (entrada). | | Servidor A | Front-end | Hospede novamente, usando o Amazon Elastic Compute Cloud (Amazon EC2). | | Servidor B | Front-end | Hospede novamente usando o Amazon EC2. | | Servidor C | Lógica do aplicativo | Hospede novamente usando o Amazon EC2. | | Servidor D | Lógica do aplicativo | Hospede novamente usando o Amazon EC2. | | Amazon Relational Database Service (Amazon RDS) — Amazon Aurora | Banco de dados | Substitui os servidores E e F | | Monitoramento e alertas | Controle de alterações | Amazon CloudWatch | | Registro em log de auditoria | Controle de alterações | AWS CloudTrail | | Aplicação de patches e acesso remoto | Manutenção | AWS Systems Manager | | Acesso ao recurso | Controle de acesso seguro | AWS Identity and Access Management (IAM) | | Autenticação | Acesso do usuário | Amazon Cognito | | Certificados | SSL/TLS | AWS Certificate Manager | | API 1 | API externa | Amazon API Gateway | | Armazenamento de objetos | Hospedagem de imagens | Amazon Simple Storage Service (Amazon S3) | | Credenciais | Gerenciamento e hospedagem de credenciais | AWS Secrets Manager | | AWS Lambda função | Recuperação de credenciais de banco de dados e chaves de API | AWS Lambda | | Gateway da Internet | Acesso de saída à Internet | Gateway de Internet para uma VPC | | Sub-rede privada 1 | Backend e banco de dados | Zona de disponibilidade 1 — VPC 1 | | Sub-rede privada 2 | Backend e banco de dados | Zona de disponibilidade 2 — VPC 1 | | Sub-rede pública 1 | Front-end | Zona de disponibilidade 1 — VPC 1 | | Sub-rede pública 2 | Front-end | Zona de disponibilidade 2 — VPC 1 | | Serviços de backup | Backup de bancos de dados e instâncias do EC2 | AWS Backup | | DR | Resiliência do Amazon EC2 | Recuperação de desastres do AWS Elastic | Depois que os componentes forem identificados, plote-os em um diagrama usando sua ferramenta preferida. Compartilhe o design inicial com as principais partes interessadas do aplicativo, incluindo proprietários de aplicativos, arquitetos corporativos e as equipes de plataforma e migração. Considere fazer as seguintes perguntas: + A equipe geralmente concorda com o design? + As equipes de operações podem apoiá-lo? + O design pode ser evoluído? + Há outras opções? + O design está em conformidade com os padrões arquitetônicos e as políticas de segurança? + Falta algum componente (por exemplo, repositórios de código, CI/CD ferramentas, endpoints de VPC)? ## Decisões arquitetônicas Como parte do processo de design, você provavelmente encontrará mais opções para a arquitetura geral ou partes específicas dela. Documente essas opções junto com a justificativa para uma opção preferida ou selecionada. Essas decisões podem ser documentadas como decisões arquitetônicas. Certifique-se de que as opções principais estejam listadas e descritas com detalhes suficientes para que um novo leitor entenda as opções e os motivos por trás da decisão de usar uma opção em vez de outra. ## Ambientes de ciclo de vida de software Documente todas as alterações nos ambientes atuais. Por exemplo, ambientes de teste e desenvolvimento serão recriados AWS e não migrados. ## Tags Descreva a marcação obrigatória e recomendada para cada componente da infraestrutura, bem como o valor da marcação para esse design. ## Estratégia de migração Nesse ponto do projeto, as suposições iniciais sobre a estratégia de migração devem ser validadas. Confirme se há consenso sobre a estratégia R escolhida. Documente a estratégia geral de migração de aplicativos e as estratégias para componentes individuais do aplicativo. Conforme mencionado anteriormente, diferentes componentes do aplicativo podem exigir diferentes tipos de R para migração. Além disso, alinhe a estratégia de migração aos principais fatores e resultados comerciais. Além disso, descreva qualquer abordagem em fases da migração, como a movimentação de componentes em diferentes eventos de migração. Para obter mais informações sobre como determinar seus 6 Rs, consulte as [recomendações de AWS Migration Hub estratégia](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Padrões e ferramentas de migração Com uma estratégia de migração definida para os componentes do aplicativo e da infraestrutura, agora você pode explorar padrões técnicos específicos. Por exemplo, uma estratégia de rehospedagem pode ser implementada por meio de ferramentas de migração, como. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Se você não precisar replicar o estado ou os dados, poderá obter o mesmo resultado reimplantando o aplicativo usando uma Amazon Machine Image (AMI) e um pipeline de implantação de aplicativos. Da mesma forma, para reformular ou refatorar (rearquitetar) um aplicativo, você pode usar ferramentas como [AWS App2Container](https://aws.amazon.com/app2container/), [AWS Database Migration Service (AWS DMS), ()](https://aws.amazon.com/dms/), [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/).AWS SCT[AWS DataSync](https://aws.amazon.com/datasync/) Para conteinerização, você pode usar o [Amazon Elastic Container Service (Amazon ECS), o Amazon](https://aws.amazon.com/ecs/) [Elastic Kubernetes Service (Amazon EKS](https://aws.amazon.com/eks/)) ou. [AWS Fargate](https://aws.amazon.com/fargate/) Ao recomprar, você pode usar uma AMI para um produto específico ou uma solução de software como serviço (SaaS) da. [AWS Marketplace](https://aws.amazon.com/marketplace/) Avalie os diferentes padrões e opções disponíveis para atingir a meta. Considere os prós e os contras e a prontidão operacional da migração. Para ajudar na sua análise, use as seguintes perguntas: + As equipes de migração podem suportar esses padrões? + Qual é o equilíbrio entre custo e benefícios? + Esse aplicativo, serviço ou componente pode ser movido para um serviço gerenciado? + Qual é o esforço para implementar esse padrão? + Existe alguma regulamentação ou política de conformidade que impeça o uso de um padrão específico? + Esse padrão pode ser reutilizado? Padrões reutilizáveis são preferidos. No entanto, às vezes, um padrão será usado apenas uma vez. Considere o equilíbrio entre o esforço de um padrão de uso único em relação a um padrão alternativo reutilizável. AWS A [orientação prescritiva](https://aws.amazon.com/prescriptive-guidance/) contém uma variedade de padrões e técnicas de migração. ## Gerenciamento e operações de serviços Ao criar designs de aplicativos para migração para AWS, considere a prontidão operacional. Ao avaliar os requisitos de prontidão com suas equipes de aplicativos e infraestrutura, considere as seguintes questões: + Eles estão prontos para operá-lo? + Os procedimentos de resposta a incidentes estão definidos? + Qual é o contrato de nível de serviço (SLA) esperado? + A separação de deveres é necessária? + As diferentes equipes estão prontas para coordenar as ações de apoio? + Quem é responsável pelo quê? ## Considerações de transição Considerando a estratégia e os padrões de migração, o que é importante saber no momento em que o aplicativo é migrado? O planejamento de transição é uma atividade de pós-design. No entanto, documente todas as considerações sobre atividades e requisitos que possam ser previstos. Por exemplo, documente a exigência de realizar uma prova de conceito, se aplicável, e descreva os requisitos de teste, auditoria ou validação. ## Riscos, suposições, problemas e dependências Documente todos os riscos em aberto, suposições e possíveis problemas que ainda não foram resolvidos. Atribua uma propriedade clara a esses itens e acompanhe o progresso para que o design e a estratégia gerais possam ser aprovados para implementação. Além disso, documente as principais dependências para implementar esse design. ## Estimando o custo de operação Para estimar o custo de sua AWS arquitetura alvo, use a [Calculadora AWS de preços](https://calculator.aws/). Adicione seus componentes de infraestrutura conforme definido pelo seu projeto e obtenha um custo operacional estimado. Considere as licenças de software que são necessárias para os componentes do seu aplicativo e que ainda não estão incluídas nos AWS serviços que você usará.