AWS conception des applications et stratégie de migration

La conception et la documentation de l'état futur de votre application constituent un facteur clé de réussite de la migration. Nous vous recommandons de créer un design pour tout type de stratégie de migration, qu'elle soit simple ou complexe. La création de la conception mettra en évidence les bloqueurs potentiels, les dépendances et les opportunités d'optimisation de l'application, même dans les cas où l'architecture ne devrait pas changer.

Nous recommandons également d'aborder l'état futur de l'application sous l'angle AWS de la stratégie de migration. À ce stade, assurez-vous de définir à quoi ressemblera l'application à la AWS suite de cette migration. La conception qui en résultera servira de base à une évolution ultérieure après la migration.

La liste suivante contient des ressources destinées à faciliter le processus de conception :

• AWS Architecture Center combine des outils et des conseils, tels que le AWS Well-Architected Framework. Il fournit également des architectures de référence que vous pouvez utiliser pour votre application.

• L'Amazon Builders' Library contient plusieurs ressources sur la façon dont Amazon crée et exploite des logiciels.

• AWS La bibliothèque de solutions propose une collection de solutions basées sur le cloud, approuvées par AWS, pour des dizaines de problèmes techniques et commerciaux. Il inclut une vaste collection d'architectures de référence.

• AWS Les directives prescriptives fournissent des stratégies, des guides et des modèles qui facilitent le processus de conception et les meilleures pratiques de migration.

• AWS Documentationcontient des informations sur les AWS services, notamment des guides d'utilisation et des références d'API.

• Le centre de ressources Getting Started propose plusieurs didacticiels pratiques et des plongées approfondies pour apprendre les principes de base afin que vous puissiez commencer à vous intégrer AWS.

Selon l'état d'avancement de votre transition vers le cloud, AWS les bases peuvent déjà exister. Ces AWS fondements sont notamment les suivants :

• Régions AWS ont été identifiés.

• Des comptes ont été créés ou peuvent être obtenus sur demande.

• La mise en réseau générale a été mise en place.

• Les AWS services de base ont été déployés au sein des comptes.

À l'inverse, il se peut que vous en soyez au début du processus et que AWS les bases ne soient pas encore établies. L'absence de bases établies pourrait limiter la portée de la conception de votre application ou nécessiter des travaux supplémentaires pour les définir. Si tel est le cas, nous recommandons de définir et de mettre en œuvre la conception fondamentale de la zone d'atterrissage en parallèle avec le travail de conception de l'application. La conception de l'application permet d'identifier les exigences telles que Compte AWS la structure, le réseau, le cloud privé virtuel (VPCs), les plages de routage interdomaines sans classe (CIDR), les services partagés, la sécurité et les opérations cloud.

AWS Control Towerconstitue le moyen le plus simple de configurer et de gérer un AWS environnement multi-comptes sécurisé, appelé zone d'atterrissage. AWS Control Tower crée votre zone de landing zone en utilisant AWS Organizations, qui assure la gestion et la gouvernance continues des comptes et la mise en œuvre d'une expérience basée sur les AWS meilleures pratiques en travaillant avec des milliers de clients lors de leur migration vers le cloud.

État futur de l'application

Commencez par établir la stratégie de migration initiale pour cette application. À ce stade, la stratégie est considérée comme initiale car elle pourrait changer dans le cadre de la future conception de l'état, ce qui peut révéler des limites potentielles. Pour valider les hypothèses initiales, consultez l'arbre de décision des 6 R. Documentez également les phases de migration potentielles. Par exemple, cette application sera-t-elle migrée en un seul événement (tous les composants seront migrés en même temps) ? Ou s'agit-il d'une migration progressive (certains composants sont migrés ultérieurement) ?

Notez que les stratégies de migration pour une application donnée peuvent ne pas être uniques. Cela est dû au fait que plusieurs types R peuvent être utilisés pour migrer les composants de l'application. Par exemple, l'approche initiale pourrait consister à lever et à déplacer l'application sans la modifier. Cependant, les composants d'une application peuvent résider dans différents actifs d'infrastructure qui peuvent nécessiter divers traitements. Par exemple, une application est composée de trois composants, chacun s'exécutant sur un serveur distinct, et l'un des serveurs exécute un ancien système d'exploitation qui n'est pas pris en charge dans le cloud. Ce composant nécessitera une approche de replateforme, tandis que les deux autres composants, exécutés dans des versions de serveur prises en charge, peuvent être réhébergés. Il est essentiel d'attribuer une stratégie de migration à chaque composant d'application et à l'infrastructure associée faisant l'objet de la migration.

Ensuite, documentez le contexte et le problème, puis liez les artefacts existants qui définissent l'état actuel :

• Pourquoi cette application est-elle migrée ?

• Quels sont les changements proposés ?

• Quels en sont les avantages ?

• Existe-t-il des risques ou des bloqueurs majeurs ?

• Quels sont les inconvénients actuels ?

• Qu'est-ce qui est inclus dans le champ d'application et qu'est-ce qui est hors de portée ?

Répétabilité

Tout au long du travail de conception, réfléchissez à la manière dont cette solution et cette architecture de cette application peuvent être réutilisées pour d'autres applications. Cette solution peut-elle être généralisée ?

Prérequis

Documentez les exigences fonctionnelles et non fonctionnelles de cette application, y compris en matière de sécurité. Cela inclut les exigences actuelles et futures de l'État, en fonction de la stratégie de migration choisie. Utilisez les informations recueillies lors de l'évaluation détaillée de la demande pour guider ce processus.

Architecture à venir

Décrivez la future architecture de cette application. Envisagez de créer un modèle de diagramme réutilisable contenant des éléments de base pour votre environnement source (sur site) et votre AWS environnement cible (par exemple Région AWS, cible VPCs, compte et zones de disponibilité).

Créez un tableau des composants en cours de migration et des composants qui seront nouveaux. Incluez d'autres applications et services (sur site ou dans le cloud) qui interagissent avec cette application.

Le tableau suivant répertorie des exemples de composants. Il ne représente pas une architecture de référence ou une configuration approuvée.

Name (Nom)	Description	Détails
Application	Service externe (connexion entrante)	Le service consomme les données de l'API exposée.
DNS	Résolution du nom (interne)	Amazon Route 53 déployé dans le cadre des paramètres de base du compte
Application Load Balancer	Répartit le trafic entre les services principaux	Remplace l'équilibreur de charge local. Migrer le pool A.
Sécurité des applications	Protection contre les attaques DDoS	Implémenté en utilisant AWS Shield
Groupe de sécurité	Pare-feu virtuel	Limitez l'accès aux instances d'application sur le port 443 (entrant).
Serveur A	Front-end	Réhébergez à l'aide d'Amazon Elastic Compute Cloud (Amazon EC2).
Serveur B	Front-end	Réhébergez à l'aide d'Amazon EC2.
Serveur C	Logique de l'application	Réhébergez à l'aide d'Amazon EC2.
Serveur D	Logique de l'application	Réhébergez à l'aide d'Amazon EC2.
Amazon Relational Database Service (Amazon RDS) — Amazon Aurora	Base de données	Remplace les serveurs E et F
Surveillance et alertes	Contrôle des modifications	Amazon CloudWatch
Journaux d’audit	Contrôle des modifications	AWS CloudTrail
Correctifs et accès à distance	Maintenance	AWS Systems Manager
Accès aux ressources	Contrôle d'accès sécurisé	AWS Identity and Access Management (JE SUIS)
Authentification	Accès utilisateur	Amazon Cognito
Certificats	SSL/TLS	AWS Certificate Manager
API 1	API externe	Amazon API Gateway
Stockage d'objets	Hébergement d'images	Amazon Simple Storage Service (Amazon S3)
Informations d’identification	Gestion et hébergement des informations d'identification	AWS Secrets Manager
AWS Lambda fonction	Récupération des informations d'identification de base de données et des clés d'API	AWS Lambda
Passerelle Internet	Accès Internet sortant	Passerelle Internet vers un VPC
Sous-réseau privé 1	Backend et base de données	Zone de disponibilité 1 — VPC 1
Sous-réseau privé 2	Backend et base de données	Zone de disponibilité 2 — VPC 1
Sous-réseau public 1	Front-end	Zone de disponibilité 1 — VPC 1
Sous-réseau public 2	Front-end	Zone de disponibilité 2 — VPC 1
Services de Backup	Sauvegarde des bases de données et des EC2 instances	AWS Backup
DR	EC2 Résilience d'Amazon	AWS Elastic Disaster Recovery

Une fois les composants identifiés, tracez-les dans un diagramme à l'aide de l'outil de votre choix. Partagez la conception initiale avec les principales parties prenantes de l'application, notamment les propriétaires des applications, les architectes d'entreprise, les équipes chargées de la plateforme et de la migration. Pensez à vous poser les questions suivantes :

• L'équipe est-elle généralement d'accord avec le design ?

• Les équipes opérationnelles peuvent-elles le soutenir ?

• Le design peut-il être modifié ?

• Y a-t-il d'autres options ?

• La conception est-elle conforme aux normes architecturales et aux politiques de sécurité ?

• Des composants sont-ils manquants (par exemple, des référentiels de code, des outils CI/CD, des points de terminaison VPC) ?

Décisions architecturales

Dans le cadre du processus de conception, vous trouverez probablement plus d'options pour l'architecture globale ou pour des parties spécifiques de celle-ci. Documentez ces options ainsi que la justification de l'option préférée ou sélectionnée. Ces décisions peuvent être documentées en tant que décisions architecturales.

Assurez-vous que les principales options sont répertoriées et décrites avec suffisamment de détails pour qu'un nouveau lecteur puisse comprendre les options et les raisons qui sous-tendent la décision d'utiliser une option plutôt qu'une autre.

Environnements du cycle de vie logiciel

Documentez toute modification apportée aux environnements actuels. Par exemple, les environnements de test et de développement seront recréés AWS et non migrés.

Identification

Décrivez le balisage obligatoire et recommandé pour chaque composant de l'infrastructure ainsi que la valeur du balisage pour cette conception.

Stratégie de migration

À ce stade de la conception, les hypothèses initiales concernant la stratégie de migration devraient être validées. Confirmez qu'il existe un consensus sur la stratégie R choisie. Documentez la stratégie globale de migration des applications et les stratégies relatives aux différents composants de l'application. Comme indiqué précédemment, les différents composants de l'application peuvent nécessiter différents types de R pour la migration.

En outre, adaptez la stratégie de migration aux principaux moteurs et résultats commerciaux. Décrivez également toute approche progressive de la migration, telle que le déplacement des composants lors de différents événements de migration.

Pour plus d'informations sur la détermination de vos 6 R, consultez les recommandations AWS Migration Hub stratégiques.

Modèles et outils de migration

Grâce à une stratégie de migration définie pour les composants de l'application et de l'infrastructure, vous pouvez désormais explorer des modèles techniques spécifiques. Par exemple, une stratégie de réhébergement peut être mise en œuvre à l'aide d'outils de migration tels que. AWS Application Migration Service Si vous n'avez pas besoin de répliquer l'état ou les données, vous pouvez obtenir le même résultat en redéployant l'application à l'aide d'une Amazon Machine Image (AMI) et d'un pipeline de déploiement d'applications.

De même, pour reconfigurer ou refactoriser (reconfigurer) une application, vous pouvez utiliser des outils tels que AWS App2Container, AWS Database Migration Service (AWS DMS), (), AWS Schema Conversion Tool.AWS SCTAWS DataSync Pour la conteneurisation, vous pouvez utiliser Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) ou. AWS Fargate Lors du rachat, vous pouvez utiliser une AMI pour un produit spécifique ou une solution logicielle en tant que service (SaaS) de AWS Marketplace.

Évaluez les différents modèles et options disponibles pour atteindre l'objectif. Tenez compte des avantages et des inconvénients, ainsi que de l'état de préparation opérationnelle à la migration. Pour vous aider dans votre analyse, posez-vous les questions suivantes :

• Les équipes de migration peuvent-elles accepter ces modèles ?

• Quel est l'équilibre entre les coûts et les avantages ?

• Cette application, ce service ou ce composant peut-il être déplacé vers un service géré ?

• Quels sont les efforts déployés pour mettre en œuvre ce modèle ?

• Existe-t-il une réglementation ou une politique de conformité empêchant l'utilisation d'un modèle spécifique ?

• Ce modèle peut-il être réutilisé ? Les modèles réutilisables sont préférés. Cependant, il arrive qu'un modèle ne soit utilisé qu'une seule fois. Tenez compte de l'équilibre entre l'effort d'un modèle à usage unique et celui d'un autre modèle réutilisable.

AWS Les directives prescriptives contiennent une variété de modèles et de techniques de migration.

Gestion des services et opérations

Lorsque vous créez des conceptions d'applications destinées à la migration AWS, tenez compte de l'état de préparation opérationnelle. Lorsque vous évaluez les exigences de préparation avec vos équipes chargées des applications et de l'infrastructure, posez-vous les questions suivantes :

• Sont-ils prêts à le faire fonctionner ?

• Les procédures de réponse aux incidents sont-elles définies ?

• Quel est le contrat de niveau de service (SLA) attendu ?

• La séparation des tâches est-elle requise ?

• Les différentes équipes sont-elles prêtes à coordonner les actions de soutien ?

• Qui est responsable de quoi ?

Considérations relatives au passage

Compte tenu de la stratégie et des modèles de migration, que faut-il savoir au moment de la migration de l'application ? La planification de la transition est une activité postérieure à la conception. Cependant, documentez toutes les considérations relatives aux activités et aux exigences qui peuvent être anticipées. Par exemple, documentez l'exigence de réaliser une preuve de concept, le cas échéant, et décrivez les exigences en matière de test, d'audit ou de validation.

Risques, hypothèses, problèmes et dépendances

Documentez les risques ouverts, les hypothèses et les problèmes potentiels qui ne sont pas encore résolus. Attribuez clairement la responsabilité de ces éléments et suivez les progrès afin que la conception globale et la stratégie puissent être approuvées pour la mise en œuvre. En outre, documentez les principales dépendances pour la mise en œuvre de cette conception.

Estimation du coût de fonctionnement

Pour estimer le coût de votre AWS architecture cible, utilisez le calculateur de AWS prix. Ajoutez les composants de votre infrastructure tels que définis par votre conception et obtenez une estimation du coût d'exploitation. Tenez compte des licences logicielles requises pour les composants de votre application et qui ne sont pas déjà incluses dans les AWS services que vous utiliserez.