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á.
# 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. Além disso, o design resultante servirá como base para uma maior evolução após a migração.
Além da importância do processo de design, ele também pode se tornar um bloqueador e afetar a velocidade da migração. Isso acontece devido aos processos legados de revisão arquitetônica que foram concebidos para sistemas locais. Recomendamos que você revise seu processo de revisão e aprovação arquitetônica e se concentre em estabelecer padrões ou tipos de arquitetura que possam ser pré-aprovados. Não subestime o esforço de revisar as arquiteturas de centenas ou milhares de aplicativos e aproveite a oportunidade para modernizar o processo.
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 Biblioteca de Soluções](https://aws.amazon.com/solutions/) oferece uma coleção de soluções baseadas em nuvem, avaliadas pela 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 fundações 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 Inter-Domain roteamento 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.
## To-be arquitetura
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, conta Região da AWS, VPCs 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) | Description | 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 | Gerenciador de certificados da AWS |
| 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 |
| Função do AWS Lambda | 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 Transform MGN](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.AWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)](https://aws.amazon.com/dms/schema-conversion-tool/) 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 arquitetura alvo da AWS, use [AWS Calculadora de Preços](https://calculator.aws/)o. 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 nas Serviços da AWS que você usará.