Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Évaluation des candidatures par ordre de priorité L'un des principaux résultats de l'étape précédente, à savoir la [découverte du portefeuille et la planification initiale](portfolio-discovery-initial-planning.md), a été de [prioriser un sous-ensemble de demandes](prioritization-and-migration-strategy.md#prioritizing-applications) pour une évaluation détaillée. Cette section explore l'évaluation détaillée des demandes. L'examen des détails de quelques applications dès le début stimulera l'accélération. Le processus d'évaluation et de conception de l'architecture à venir met en évidence les bloqueurs potentiels et clarifie les tâches importantes qui précèdent la migration à plus grande échelle. Ces tâches incluent le recueil des exigences pour établir AWS les fondations, telles que la zone d'atterrissage AWS, ou pour étendre et valider la zone d'atterrissage existante. Cette évaluation est également le moment de réfléchir aux étapes et à la stratégie de migration. Les principaux résultats de cette étape sont les suivants : + Liste validée des applications prioritaires + Architecture d'état actuelle documentée + Architecture cible initiale et stratégie de migration documentées pour les candidats à la migration + Modèles de migration et outils identifiés + Exigences de plate-forme documentées (sécurité, AWS infrastructure et opérations) + Considérations documentées relatives au transfert pour la planification de la migration + Fréquence d' AWS exécution estimée # Comprendre les exigences détaillées en matière de données d'évaluation Le tableau suivant décrit les informations requises pour obtenir une vue complète du portefeuille des applications concernées par la migration et de leur infrastructure associée. Les tableaux utilisent les abréviations suivantes : + R, pour obligatoire + O, en option + N/A, car non applicable **Applications** | **Nom d'attribut** | **Description** | **Stratégie de découverte, de conception et de migration** | **Fréquence d'exécution estimée** | **Niveau de fidélité recommandé (minimum)** | | --- |--- |--- |--- |--- | | Identifiant unique | Par exemple, l'ID de l'application. Généralement disponible sur les inventaires et systèmes de contrôle internes existants CMDBs ou autres. Envisagez de créer des IDs éléments uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation. | R | O | Élevée | | Application name (Nom de l'application) | Nom sous lequel cette application est connue de votre organisation. Incluez le fournisseur commercial off-the-shelf (COTS) et le nom du produit, le cas échéant. | R | R | Élevée | | Est-ce que COTS ? | Oui ou non Qu'il s'agisse d'une application commerciale ou d'un développement interne | R | R | Élevée | | Produit et version COTS | Nom et version du produit logiciel commercial | R | R | Élevée | | Description | Fonction et contexte principaux de l'application | R | O | Élevée | | Criticité | Par exemple, une application stratégique ou génératrice de revenus, ou le soutien d'une fonction critique | R | O | Élevée | | Type | Par exemple, base de données, gestion de la relation client (CRM), application Web, multimédia, service informatique partagé | R | O | Élevée | | Environnement | Par exemple, production, pré-production, développement, test, bac à sable | R | R | Élevée | | Conformité et réglementation | Cadres applicables à la charge de travail (par exemple, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) et aux exigences réglementaires | R | O | Élevée | | Dépendances | Dépendances en amont et en aval vis-à-vis d'applications ou de services internes et externes | R | N/A | Élevée | | Cartographie des infrastructures | Mappage vers les actifs and/or virtuels physiques qui constituent l'application | R | R | Élevée | | Licence | Type de licence logicielle standard (par exemple, Microsoft SQL Server Enterprise) | R | R | Élevée | | Cost | Coûts de licence logicielle, d'exploitation des logiciels et de maintenance | N/A | R | Moyenne-élevée\$1 | | Unité commerciale | Par exemple, le marketing, les finances, les ventes | R | O | Élevée | | Informations sur le propriétaire | Informations de contact pour le propriétaire de l'application | R | O | Élevée | | Type d'architecture | Par exemple, application Web, 2 niveaux, 3 niveaux, microservices, architecture orientée services (SOA) | R | R | Élevée | | Objectif de point de reprise (RPO), objectif de temps de restauration (RTO) et accord de niveau de service (SLA) | Attributs actuels de gestion des services | R | R | Élevée | | Application génératrice de revenus ou application stratégique pour l'entreprise ? | Oui, si l'application influence directement ou indirectement le chiffre d'affaires de l'entreprise ou est considérée comme stratégique par l'entreprise. | R | O | Moyenne-élevée\$1 | | Nombre d'utilisateurs (simultanés) | Par exemple, des utilisateurs internes ou externes ou des utilisateurs/clients internes and/or externes | R | R | Moyenne-élevée\$1 | | User location (Emplacement de l’utilisateur) | Origine des sessions utilisateur | R | R | Moyenne-élevée\$1 | | Risques et problèmes | Risques et problèmes connus | R | O | Moyenne-élevée\$1 | | Considérations concernant la migration | Toute information supplémentaire susceptible d'être pertinente pour la migration | R | R | Moyenne-élevée\$1 | | Stratégie de migration | Par exemple, l'un des AWS 6 R de la migration | R | R | Moyenne-élevée\$1 | | Détails de base de données | Par exemple, partitionnement, chiffrement, réplication, extensions, prise en charge du protocole SSL (Secure Sockets Layer) | R | R | Élevée | | Équipes de support | Par exemple, nom de l'équipe chargée des opérations de l'application | R | O | Moyenne-élevée\$1 | | Solution de surveillance | Produit utilisé pour surveiller cette application | R | O | Moyenne-élevée\$1 | | Exigences en matière de sauvegarde | Calendrier de sauvegarde requis dans AWS | R | R | Moyenne-élevée\$1 | | Informations DR | Par exemple, les composants de reprise après sinistre pour cette application | R | R | Moyenne-élevée\$1 | | AWS Exigences cibles | Par exemple, composants, placement de compte, mise en réseau, sécurité | R | R | Élevée | **Infrastructures** | | | | | | | --- |--- |--- |--- |--- | | **Nom de l'attribut** | **Description** | **Stratégie de découverte, de conception et de migration** | **Fréquence d'exécution estimée** | **Niveau de fidélité recommandé (minimum)** | | Identifiant unique | Par exemple, l'ID du serveur. Généralement disponible sur les inventaires et systèmes de contrôle internes existants CMDBs ou autres. Envisagez de créer des IDs éléments uniques chaque fois que ceux-ci ne sont pas définis dans votre organisation. | R | O | Élevée | | Nom du réseau | Nom de l'actif sur le réseau (par exemple, nom d'hôte) | R | O | Élevée | | Nom DNS (nom de domaine complet, ou FQDN) | Nom du DNS | O | O | Moyenne-élevée\$1 | | Adresse IP et masque réseau | Adresses IP and/or publiques internes | R | R | Élevée | | Type de ressource | Par exemple, serveur physique ou virtuel, hyperviseur, conteneur, appareil, instance de base de données | R | R | Élevée | | Nom du produit | Fournisseur commercial et nom du produit (par exemple VMware ESXi, IBM Power Systems, Exadata) | R | R | Élevée | | Système d’exploitation | Par exemple, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Élevée | | Configuration | Processeur alloué, nombre de cœurs, threads par cœur, mémoire totale, stockage, cartes réseau | R | R | Élevée | | Utilisation | Pic et moyenne du processeur, de la mémoire et du stockage. Débit des instances de base de données. | R | R | Élevée | | Licence | Type de licence de base (par exemple, RHEL Standard) | R | R | Élevée | | S'agit-il d'une infrastructure partagée ? | Oui ou Non pour désigner les services d'infrastructure qui fournissent des services partagés tels que le fournisseur d'authentification, les systèmes de surveillance, les services de sauvegarde et les services similaires | R | O | Élevée | | Cartographie des applications | Applications ou composants d'application qui s'exécutent dans cette infrastructure | R | O | Élevée | | Données de communication | Par exemple, serveur à serveur au niveau du processus | R | N/A | Moyenne-élevée\$1 | | AWS Exigences cibles | Par exemple, les types d'instances, les comptes, les sous-réseaux, les groupes de sécurité, le routage | R | R | Élevée | | Stratégie, modèles et outils de migration | Par exemple, l'un des 6 R pour la migration, un modèle technique spécifique, des outils de migration | R | O | Élevée | | Risques et problèmes | Risques et problèmes connus | R | O | Moyenne-élevée\$1 | # Évaluation détaillée de la demande L'objectif d'une évaluation détaillée des applications est de comprendre parfaitement l'application ciblée et son infrastructure associée (calcul, stockage et réseau). Des données de haute fidélité sont nécessaires pour éviter les pièges. Par exemple, il est courant que les organisations supposent qu'elles comprennent parfaitement l'application. C'est naturel, et c'est vrai dans de nombreux cas. Cependant, afin de minimiser les risques pour l'entreprise, il est important de valider les connaissances institutionnelles et la documentation statique en obtenant autant que possible des données programmatiques. Cela permettra de s'occuper du gros du processus de découverte. Vous pouvez vous concentrer sur les éléments de données provenant de sources alternatives, telles que les informations spécifiques à l'entreprise, les feuilles de route stratégiques, etc. L'essentiel est d'éviter les modifications de dernière minute pendant et après la migration. Par exemple, lors de la migration, il est important d'éviter les modifications basées sur des dépendances non identifiées qui pourraient nécessiter l'inclusion d'un serveur dans une vague de migration en cours. Peu de temps après la migration, il est important d'éviter les modifications en fonction des exigences associées à la plate-forme afin d'autoriser le trafic ou de déployer des services supplémentaires. Ces types de modifications imprévues augmentent le risque de problèmes opérationnels et de sécurité. Nous vous recommandons vivement d'utiliser des outils de découverte programmatique pour valider les modèles de trafic et les dépendances lors de l'évaluation détaillée des applications. Au début de l'évaluation, vous devez identifier les parties prenantes de l'application. Ce sont généralement les suivants : + Responsables des unités commerciales + Propriétaires de l'application + Architectes + Opérations et support + Équipes chargées de l'activation du cloud + Équipes de plateformes spécifiques telles que le calcul, le stockage et les réseaux Il existe deux approches pour une découverte détaillée. La découverte du haut vers le bas commence par l'application, voire par l'utilisateur, et s'étend jusqu'à l'infrastructure. Il s'agit de l'approche recommandée lorsque l'identification de l'application est claire. À l'inverse, la découverte ascendante commence par l'infrastructure et s'étend jusqu'à l'application ou au service et à ses utilisateurs. Cette approche est utile lorsque les programmes de migration sont pilotés par des équipes d'infrastructure et lorsque le application-to-infrastructure mappage n'est pas clair. En général, vous utiliserez probablement une combinaison des deux. Pour approfondir une application, les diagrammes d'architecture existants constituent un bon point de départ. S'ils ne sont pas disponibles, créez-en un en fonction des connaissances actuelles. Ne sous-estimez pas l'importance de cette tâche, même pour de simples stratégies de migration de réhébergement ou de relocalisation. Le tracé de diagrammes architecturaux vous aide à identifier les inefficiences qui peuvent être rapidement corrigées par des modifications mineures dans le cloud. Selon que vous adoptez une approche descendante ou ascendante, le diagramme initial tracera les composants et services de l'application ou les composants de l'infrastructure tels que les serveurs et les équilibreurs de charge. Une fois les principaux composants et interfaces identifiés, validez-les à l'aide des données programmatiques issues des outils de découverte et des outils de surveillance des performances des applications. Les outils doivent prendre en charge l'analyse des dépendances et fournir des informations de communication entre les composants. Chaque composant composant cette application doit être identifié. Documentez ensuite les dépendances vis-à-vis d'autres applications et services, internes et externes. En l'absence d'outils pour valider les dépendances et le mappage, une approche manuelle est requise. Par exemple, vous pouvez vous connecter aux composants de l'infrastructure et exécuter des scripts pour collecter des informations de communication telles que les ports ouverts et les connexions établies. De même, vous pouvez identifier les processus en cours d'exécution et les logiciels installés. Ne sous-estimez pas l'effort requis pour la découverte manuelle. Les outils de programmation peuvent capturer et signaler la plupart des dépendances en quelques jours, à l'exception de celles qui se produisent à des intervalles plus longs (généralement un faible pourcentage). La découverte manuelle peut prendre des semaines pour collecter et fusionner tous les points de données, et elle peut toujours être sujette à des erreurs et à des données manquantes. Procédez à l'obtention des informations spécifiées dans la section [des exigences en matière de données](understanding-detailed-assessment-data-requirements.md) pour chaque application priorisée et pour l'infrastructure mappée. Ensuite, utilisez le questionnaire suivant pour vous guider dans le processus d'évaluation détaillé. Rencontrez les parties prenantes identifiées pour discuter des réponses à ces questions. ## Général + Quel est le niveau de criticité de cette application ? Est-ce que cela génère des revenus ? S'agit-il d'une application stratégique ou d'une application commerciale de soutien ? S'agit-il d'un service d'infrastructure de base partagé par d'autres systèmes ? + Existe-t-il un projet de transformation en cours pour cette application ? + S'agit-il d'une application interne ou externe ? ## Architecture + Quel est le type d'architecture actuel (par exemple, SOA, microservices, monolith) ? Combien de niveaux comporte l'architecture ? Est-il étroitement accouplé ou faiblement couplé ? + Quels sont les composants (par exemple, calcul, bases de données, stockage à distance, équilibreurs de charge, services de mise en cache) ? + Qu'est-ce que les APIs ? Décrivez-les, notamment le nom de l'API, les opérations URLs, les ports et les protocoles. + Quelle est la latence maximale tolérée entre les composants et entre cette application et d'autres services ou applications ? ## Opérations + Dans quels lieux fonctionne cette application ? + Qui gère l'application et l'infrastructure ? Sont-ils gérés par des équipes internes ou AWS partenaires ? + Que se passe-t-il si cette application tombe en panne ? Qui est concerné ? Quel en est l'impact ? + Où se trouvent les utilisateurs ou les clients ? Comment accèdent-ils à l'application ? Quel est le nombre d'utilisateurs simultanés ? + Quand a eu lieu la dernière mise à jour technologique ? Une actualisation est-elle prévue dans le futur ? Dans l'affirmative, quand ? + Quels sont les risques et les problèmes connus liés à cette application ? Quel est l'historique des pannes et des incidents de gravité moyenne à élevée ? + Quel est le cycle d'utilisation (pendant les heures ouvrables) ? Quel est le fuseau horaire de fonctionnement ? + Quelles sont les périodes de gel des modifications ? + Quelle est la solution utilisée pour surveiller cette application ? ## Performance + Que montrent les informations sur le rendement recueillies ? L'utilisation est-elle pointue ou constante et prévisible ? Quels sont le délai, l'intervalle et la date des données de performance disponibles ? + Certaines tâches par lots planifiées font-elles partie de cette application ou interagissent-elles avec elle ? ## Cycle de vie des logiciels + Quel est le taux de variation actuel (hebdomadaire, mensuel, trimestriel ou annuel) ? + Quel est le cycle de vie du développement (par exemple, test, développement, assurance qualité, UAT, pré-production, production) ? + Quelles sont les méthodes de déploiement de l'application et de l'infrastructure ? + Qu'est-ce que l'outil de déploiement ? + Cette application ou infrastructure utilise-t-elle l'intégration continue (CI) /la livraison continue (CD) ? Quel est le niveau d'automatisation ? Quelles sont les tâches manuelles ? + Quelles sont les exigences en matière de licence pour l'application et l'infrastructure ? + Qu'est-ce que le contrat de niveau de service (SLA) ? + Quels sont les mécanismes de test actuels ? Quelles sont les étapes du test ? ## Migration + Quelles sont les considérations relatives à la migration ? À ce stade, tenez compte de tout élément à prendre en compte lors de la migration de cette application. Pour une évaluation plus complète et précise, obtenez des réponses à cette question auprès des différentes parties prenantes. Comparez ensuite leurs connaissances et leurs opinions. ## Résilience + Quelle est la méthode de sauvegarde actuelle ? Quels sont les produits utilisés pour la sauvegarde ? Quel est le calendrier de sauvegarde ? Quelle est la politique de conservation des sauvegardes ? + Quels sont l'objectif de point de reprise (RPO) et l'objectif de temps de restauration (RTO) actuels ? + Cette application dispose-t-elle d'un plan de reprise après sinistre (DR) ? Dans l'affirmative, quelle est la solution DR ? + Quand a eu lieu le dernier test DR ? ## Conformité et sécurité + Quels sont les cadres réglementaires et de conformité qui s'appliquent à cette application ? Quelles sont les dates du dernier et du prochain audit ? + Cette application héberge-t-elle des données sensibles ? Quelle est la classification des données ? + Les données sont-elles cryptées en transit ou au repos, ou les deux ? Qu'est-ce que le mécanisme de chiffrement ? + Cette application utilise-t-elle des certificats SSL ? Qu'est-ce que l'autorité émettrice ? + Quelle est la méthode d'authentification pour les utilisateurs, les composants et les autres applications et services ? ## Bases de données + Quelles sont les bases de données utilisées par cette application ? + Quel est le nombre habituel de connexions simultanées à la base de données ? Quels sont le nombre minimum et le nombre maximum de connexions ? + Quelle est la méthode de connexion (par exemple, JDBC, ODBC) ? + Les chaînes de connexion sont-elles documentées ? Dans l'affirmative, où ? + Quels sont les schémas de base de données ? + La base de données utilise-t-elle des types de données personnalisés ? ## Dépendances + Quelle est la dépendance entre les composants ? Notez toutes les dépendances qui ne peuvent pas être résolues et qui nécessiteront la migration des composants ensemble. + Les composants sont-ils répartis sur différents sites ? Quelle est la connectivité entre ces sites (par exemple, WAN, VPN) ? + Quelles sont les dépendances de cette application par rapport aux autres applications ou services ? + Quelles sont les dépendances opérationnelles ? Par exemple, les cycles de maintenance et de publication tels que l'application de correctifs aux fenêtres. # 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](https://aws.amazon.com/architecture/) 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](https://aws.amazon.com/builders-library/) contient plusieurs ressources sur la façon dont Amazon crée et exploite des logiciels. + [AWS La bibliothèque de solutions](https://aws.amazon.com/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](https://aws.amazon.com/prescriptive-guidance/) fournissent des stratégies, des guides et des modèles qui facilitent le processus de conception et les meilleures pratiques de migration. + [AWS Documentation](https://docs.aws.amazon.com/)contient des informations sur les AWS services, notamment des guides d'utilisation et des références d'API. + Le [centre de ressources Getting](https://aws.amazon.com/getting-started/) 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 Tower](https://aws.amazon.com/controltower/)constitue 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](prioritization-and-migration-strategy.md#migration-r-type) 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 ? ## Exigences 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. | **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 sur site. 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é | Gestion des identités et des accès AWS (JE SUIS) | | Authentification | Accès utilisateur | Amazon Cognito | | Certificates | 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 instances EC2 | AWS Backup | | DR | Résilience d'Amazon EC2 | Reprise après sinistre AWS Elastic | 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 CI/CD outils, 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 toutes les modifications apportées 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](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## 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](https://aws.amazon.com/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](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/) Pour la conteneurisation, vous pouvez utiliser [Amazon Elastic Container Service (Amazon ECS), Amazon [Elastic Kubernetes Service (Amazon](https://aws.amazon.com/eks/) EKS](https://aws.amazon.com/ecs/)) ou. [AWS Fargate](https://aws.amazon.com/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](https://aws.amazon.com/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 faciliter 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](https://aws.amazon.com/prescriptive-guidance/) 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 à la transition 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](https://calculator.aws/). 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.