Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Evaluación de aplicaciones priorizadas Uno de los resultados clave de la etapa anterior, la identificación de la [cartera y la planificación inicial](portfolio-discovery-initial-planning.md), fue [priorizar un subconjunto de aplicaciones](prioritization-and-migration-strategy.md#prioritizing-applications) para una evaluación detallada. En esta sección se analiza la evaluación detallada de las solicitudes. Examinar los detalles de algunas aplicaciones desde el principio impulsará la aceleración. El proceso de evaluación y diseño de la futura arquitectura revela posibles obstáculos y aclara las tareas importantes que conducen a la migración a un ámbito más amplio. Estas tareas incluyen la recopilación de requisitos para establecer AWS bases, como la zona de aterrizaje AWS, o para extender y validar la zona de aterrizaje existente. Esta evaluación también es el momento de considerar las medidas y la estrategia de migración. Los principales resultados de esta etapa son los siguientes: + Lista validada de aplicaciones priorizadas + Arquitectura de estado actual documentada + La arquitectura objetivo inicial y la estrategia de migración documentadas para los candidatos a la migración + Patrones y herramientas de migración identificados + Requisitos de plataforma documentados (seguridad, AWS infraestructura y operaciones) + Consideraciones de transición documentadas para la planificación de la migración + Velocidad de ejecución estimada AWS # Comprender los requisitos detallados de los datos de evaluación En la siguiente tabla se describe la información necesaria para obtener una visión completa de la cartera de aplicaciones de la migración y su infraestructura asociada. En las tablas se utilizan las siguientes abreviaturas: + R, si es necesario + O, para opcional + N/A, si no se aplica **Aplicaciones** | **Nombre de atributo** | **Descripción** | **Estrategia de descubrimiento, diseño y migración** | **Velocidad de ejecución estimada** | **Nivel de fidelidad recomendado (mínimo)** | | --- |--- |--- |--- |--- | | Identificador único | Por ejemplo, el identificador de la aplicación. Suele estar disponible en sistemas de control e inventarios internos existentes CMDBs o de otro tipo. Considere la posibilidad de IDs crearlos únicos siempre que no estén definidos en su organización. | R | O | Alto | | Nombre de la aplicación | Nombre por el que su organización conoce esta aplicación. Incluya el nombre del proveedor comercial off-the-shelf (COTS) y del producto cuando proceda. | R | R | Alto | | ¿Es COTS? | Sí o no. Ya sea una aplicación comercial o un desarrollo interno | R | R | Alto | | Producto y versión de COTS | Nombre y versión del producto de software comercial | R | R | Alto | | Description (Descripción) | Función y contexto de la aplicación principal | R | O | Alto | | Criticidad | Por ejemplo, una aplicación estratégica o generadora de ingresos, o que respalde una función crítica | R | O | Alto | | Tipo | Por ejemplo, base de datos, gestión de relaciones con los clientes (CRM), aplicación web, multimedia o servicio compartido de TI | R | O | Alto | | Entorno | Por ejemplo, producción, preproducción, desarrollo, pruebas o entorno aislado | R | R | Alto | | Cumplimiento y normativa | Marcos aplicables a la carga de trabajo (por ejemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) y a los requisitos reglamentarios | R | O | Alto | | Dependencias | Dependencias ascendentes y descendentes de aplicaciones o servicios internos y externos | R | N/A | Alto | | Mapeo de infraestructuras | Mapeo de los activos and/or virtuales físicos que componen la aplicación | R | R | Alto | | Licencia | Tipo de licencia de software básico (por ejemplo, Microsoft SQL Server Enterprise) | R | R | Alto | | Costo | Costos de la licencia de software, las operaciones y el mantenimiento del software | N/A | R | Medio-alto | | Unidad de negocio | Por ejemplo, marketing, finanzas, ventas | R | O | Alto | | Datos del propietario | Información de contacto del propietario de la aplicación | R | O | Alto | | Tipo de arquitectura | Por ejemplo, aplicación web, microservicios de 2 o 3 niveles, arquitectura orientada a servicios (SOA) | R | R | Alto | | Objetivo de punto de recuperación (RPO), objetivo de tiempo de recuperación (RTO) y /acuerdo de nivel de servicio (SLA) | Atributos actuales de administración de servicios | R | R | Alto | | ¿Aplicación generadora de ingresos o aplicación estratégica empresarial? | Sí, si la aplicación influye directa o indirectamente en los ingresos de la empresa o la empresa la considera estratégica. | R | O | Medio-alto | | Número de usuarios (simultáneos) | Por ejemplo, usuarios internos o externos o usuarios/clientes internos and/or externos | R | R | Medio-alto | | User location (Ubicación del usuario) | Origen de las sesiones de los usuarios | R | R | Medio-alto | | Riesgos y problemas | Riesgos y problemas conocidos | R | O | Medio-alto | | Consideraciones sobre la migración | Cualquier información adicional que pueda ser relevante para la migración | R | R | Medio-alto | | Estrategia de migración | Por ejemplo, una de las AWS 6 R para la migración | R | R | Medio-alto | | Detalles de base de datos | Por ejemplo, compatibilidad con particiones, cifrado, replicación, extensiones y compatibilidad con Secure Sockets Layer (SSL) | R | R | Alto | | Equipos de Support | Por ejemplo, el nombre del equipo de operaciones de la aplicación | R | O | Medio-alto | | Solución de monitoreo | Producto utilizado para monitorizar esta aplicación | R | O | Medio-alto | | Requisitos de Backup | Programa de respaldo requerido en AWS | R | R | Medio-alto | | Información de DR | Por ejemplo, componentes de recuperación ante desastres para esta aplicación | R | R | Medio-alto | | AWS Requisitos objetivo | Por ejemplo, componentes, ubicación de cuentas, redes, seguridad | R | R | Alto | **Infraestructura** | | | | | | | --- |--- |--- |--- |--- | | **Nombre del atributo** | **Descripción** | **Estrategia de descubrimiento, diseño y migración** | **Velocidad de ejecución estimada** | **Nivel de fidelidad recomendado (mínimo)** | | Identificador único | Por ejemplo, el ID del servidor. Suele estar disponible en sistemas de control e inventarios internos existentes CMDBs o de otro tipo. Considere la posibilidad de IDs crearlos únicos siempre que no estén definidos en su organización. | R | O | Alto | | Nombre de la red | Nombre del activo en la red (por ejemplo, nombre de host) | R | O | Alto | | Nombre DNS (nombre de dominio completo o FQDN) | Nombre de DNS | O | O | Medio-alto | | Dirección IP y máscara de red | Direcciones IP and/or públicas internas | R | R | Alto | | Tipo de activo | Por ejemplo, servidor físico o virtual, hipervisor, contenedor, dispositivo o instancia de base de datos | R | R | Alto | | Product name (Nombre del producto) | Proveedor comercial y nombre del producto (p. ej. VMware ESXi, IBM Power Systems, Exadata) | R | R | Alto | | Sistema operativo | Por ejemplo, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Alto | | Configuración | CPU asignada, número de núcleos, subprocesos por núcleo, memoria total, almacenamiento, tarjetas de red | R | R | Alto | | Uso | Cantidad máxima y media de CPU, memoria y almacenamiento. Rendimiento de las instancias de base de datos. | R | R | Alto | | Licencia | Tipo de licencia básica (por ejemplo, RHEL Standard) | R | R | Alto | | ¿Es una infraestructura compartida? | Sí o No para indicar los servicios de infraestructura que proporcionan servicios compartidos, como el proveedor de autenticación, los sistemas de monitoreo, los servicios de respaldo y servicios similares | R | O | Alto | | Mapeo de aplicaciones | Aplicaciones o componentes de aplicaciones que se ejecutan en esta infraestructura | R | O | Alto | | Datos de comunicación | Por ejemplo, de servidor a servidor a nivel de proceso | R | N/A | Medio-alto | | AWS Requisitos objetivo | Por ejemplo, tipos de instancias, cuentas, subredes, grupos de seguridad, enrutamiento | R | R | Alto | | Estrategia, patrones y herramientas de migración | Por ejemplo, una de las 6 R para la migración, un patrón técnico específico o las herramientas de migración | R | O | Alto | | Riesgos y problemas | Riesgos y problemas conocidos | R | O | Medio-alto | # Evaluación detallada de la aplicación El objetivo de una evaluación detallada de la aplicación es comprender completamente la aplicación objetivo y su infraestructura asociada (cómputo, almacenamiento y red). Los datos de alta fidelidad son necesarios para evitar problemas. Por ejemplo, es habitual que las organizaciones den por sentado que comprenden completamente la aplicación. Esto es natural y es cierto en muchos casos. Sin embargo, para minimizar el riesgo para la empresa, es importante validar el conocimiento institucional y la documentación estática mediante la obtención de datos programáticos en la medida de lo posible. Esto solucionará el pesado trabajo del proceso de descubrimiento. Puede centrarse en los elementos de datos que provienen de fuentes alternativas, como la información específica de la empresa, las hojas de ruta estratégicas y otros. La clave es evitar cambios de última hora durante y después de la migración. Por ejemplo, al migrar, es importante evitar cambios basados en dependencias no identificadas que puedan requerir la inclusión de un servidor en una ola de migración en curso. Poco después de la migración, es importante evitar cambios en función de los requisitos de plataforma asociados para permitir el tráfico o implementar servicios adicionales. Este tipo de cambios no planificados aumentan el riesgo de problemas operativos y de seguridad. Recomendamos encarecidamente utilizar herramientas de descubrimiento programático para validar los patrones de tráfico y las dependencias al realizar evaluaciones detalladas de las aplicaciones. Al principio de la evaluación, debe identificar a las partes interesadas de la aplicación. Por lo general, son las siguientes: + Líderes de la unidad de negocio + Responsables de la aplicación + Arquitectos + Operaciones y soporte + Equipos de habilitación de la nube + Equipos de plataformas específicas, como computación, almacenamiento y redes Existen dos enfoques para el descubrimiento detallado. El descubrimiento descendente comienza con la aplicación, o incluso con el usuario, y llega hasta la infraestructura. Este es el enfoque recomendado cuando la identificación de la aplicación es clara. Por el contrario, el descubrimiento de abajo hacia arriba comienza con la infraestructura y llega hasta la aplicación o el servicio y sus usuarios. Este enfoque resulta útil cuando los programas de migración son impulsados por equipos de infraestructura y cuando el application-to-infrastructure mapeo no está claro. En general, es probable que utilice una combinación de ambos. Para profundizar en una aplicación, los diagramas de arquitectura existentes son un buen punto de partida. Si no están disponibles, cree uno basado en los conocimientos actuales. No hay que subestimar la importancia de esta tarea, ni siquiera para las estrategias de migración sencillas de rehospedar o reubicar. Trazar diagramas de arquitectura le ayuda a identificar las ineficiencias que pueden abordarse rápidamente con pequeños cambios en la nube. En función de si utiliza un enfoque descendente o ascendente, el diagrama inicial representará los componentes y servicios de la aplicación o los componentes de la infraestructura, como los servidores y los equilibradores de carga. Una vez identificados los componentes e interfaces principales, valídelos con datos programáticos de las herramientas de descubrimiento y las herramientas de supervisión del rendimiento de las aplicaciones. Las herramientas deben respaldar el análisis de dependencias y proporcionar información de comunicación entre los componentes. Se debe identificar cada componente que compone esta aplicación. A continuación, documente las dependencias con otras aplicaciones y servicios, tanto internos como externos. A falta de herramientas para validar las dependencias y el mapeo, se requiere un enfoque manual. Por ejemplo, puede iniciar sesión en los componentes de la infraestructura y ejecutar scripts para recopilar información de comunicación, como los puertos abiertos y las conexiones establecidas. Del mismo modo, puede identificar los procesos en ejecución y el software instalado. No subestime el esfuerzo que requiere el descubrimiento manual. Las herramientas programáticas pueden capturar e informar de la mayoría de las dependencias en unos pocos días, excepto las que se producen a intervalos más largos (normalmente un porcentaje pequeño). El descubrimiento manual puede tardar semanas en recopilar y combinar todos los puntos de datos y, aun así, puede ser propenso a errores y a la falta de datos. Proceda a obtener la información especificada en la sección de [requisitos de datos](understanding-detailed-assessment-data-requirements.md) para cada aplicación priorizada y la infraestructura mapeada. A continuación, utilice el siguiente cuestionario para guiarlo a través del proceso de evaluación detallado. Reúnase con las partes interesadas identificadas para analizar las respuestas a estas preguntas. ## General + ¿Cuál es el nivel de criticidad de esta aplicación? ¿Genera ingresos? ¿Se trata de una aplicación empresarial estratégica o de apoyo empresarial? ¿Se trata de un servicio de infraestructura central compartido por otros sistemas? + ¿Hay algún proyecto de transformación en curso para esta aplicación? + ¿Se trata de una aplicación orientada interna o externamente? ## Arquitectura + ¿Cuál es el tipo de arquitectura actual (por ejemplo, SOA, microservicios, monolito)? ¿Cuántos niveles tiene la arquitectura? ¿Está bien acoplada o débilmente acoplada? + ¿Cuáles son los componentes (por ejemplo, computación, bases de datos, almacenamiento remoto, balanceadores de carga, servicios de almacenamiento en caché)? + ¿Qué son las APIs? Descríbalos, incluidos el nombre de la API, las operaciones URLs, los puertos y los protocolos. + ¿Cuál es la latencia máxima tolerada entre los componentes y entre esta y otras aplicaciones o servicios? ## Operaciones + ¿En qué ubicaciones funciona esta aplicación? + ¿Quién opera la aplicación y la infraestructura? ¿Están gestionados por equipos internos o de AWS socios? + ¿Qué ocurre si esta aplicación deja de funcionar? ¿Quién está afectado? ¿Cuál es el impacto? + ¿Dónde se encuentran los usuarios o los clientes? ¿Cómo acceden a la aplicación? ¿Cuál es el número de usuarios simultáneos? + ¿Cuándo se actualizó la tecnología por última vez? ¿Está programada una actualización en el futuro? Si es así, ¿cuándo? + ¿Cuáles son los riesgos y problemas conocidos de esta aplicación? ¿Cuál es el historial de interrupciones e incidentes de gravedad media y alta? + ¿Cuál es el ciclo de uso (en horario laboral)? ¿Cuál es la zona horaria de funcionamiento? + ¿Cuáles son los períodos de congelación de cambios? + ¿Qué solución se utiliza para supervisar esta aplicación? ## Desempeño + ¿Qué muestra la información de rendimiento recopilada? ¿El uso es puntiagudo o constante y predecible? ¿Cuál es el marco temporal, el intervalo y la fecha de los datos de rendimiento disponibles? + ¿Hay trabajos por lotes programados que formen parte de esta aplicación o que interactúen con ella? ## ciclo de vida del software + ¿Cuál es la tasa de cambio actual (semanal, mensual, trimestral o anual)? + ¿Cuál es el ciclo de vida del desarrollo (por ejemplo, pruebas, desarrollo, control de calidad, UAT, preproducción, producción)? + ¿Cuáles son los métodos de despliegue de la aplicación y la infraestructura? + ¿Qué son las herramientas de despliegue? + ¿Esta aplicación o infraestructura utiliza integración continua (CI) o entrega continua (CD)? ¿Cuál es el nivel de automatización? ¿Cuáles son las tareas manuales? + ¿Cuáles son los requisitos de licencia para la aplicación y la infraestructura? + ¿Qué es el acuerdo de nivel de servicio (SLA)? + ¿Cuáles son los mecanismos de prueba actuales? ¿Cuáles son las etapas de prueba? ## Migración + ¿Cuáles son las consideraciones sobre la migración? Llegados a este punto, tenga en cuenta cualquier consideración a la hora de migrar esta aplicación. Para una evaluación más completa y precisa, obtenga respuestas a esta pregunta de las distintas partes interesadas. Luego, compare sus conocimientos y opiniones. ## Resiliencia + ¿Cuál es el método de respaldo actual? ¿Qué productos se utilizan para la copia de seguridad? ¿Cuál es el calendario de copias de seguridad? ¿Cuál es la política de retención de copias de seguridad? + ¿Cuáles son el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) actuales? + ¿Tiene esta aplicación un plan de recuperación ante desastres (DR)? Si es así, ¿cuál es la solución de recuperación ante desastres? + ¿Cuándo se realizó la última prueba de DR? ## Seguridad y conformidad + ¿Cuáles son los marcos normativos y de cumplimiento que se aplican a esta aplicación? ¿Cuáles son las fechas de la última auditoría y de la próxima? + ¿Esta aplicación aloja datos confidenciales? ¿Cuál es la clasificación de los datos? + ¿Los datos están cifrados en tránsito o en reposo, o ambos? ¿Cuál es el mecanismo de cifrado? + ¿Esta aplicación utiliza certificados SSL? ¿Qué es la autoridad emisora? + ¿Cuál es el método de autenticación para los usuarios, los componentes y otras aplicaciones y servicios? ## Bases de datos + ¿Qué bases de datos utiliza esta aplicación? + ¿Cuál es el número típico de conexiones simultáneas a la base de datos? ¿Cuál es el número mínimo y el número máximo de conexiones? + ¿Cuál es el método de conexión (por ejemplo, JDBC, ODBC)? + ¿Están documentadas las cadenas de conexión? Si es así, ¿dónde? + ¿Cuáles son los esquemas de las bases de datos? + ¿La base de datos utiliza tipos de datos personalizados? ## Dependencias + ¿Cuál es la dependencia entre los componentes? Tenga en cuenta las dependencias que no se puedan resolver y que requieran la migración de los componentes juntos. + ¿Los componentes están divididos en distintas ubicaciones? ¿Cuál es la conectividad entre estas ubicaciones (por ejemplo, WAN, VPN)? + ¿Cuáles son las dependencias de esta aplicación con otras aplicaciones o servicios? + ¿Cuáles son las dependencias operativas? Por ejemplo, los ciclos de mantenimiento y lanzamiento, como el parcheo de las ventanas. # AWS diseño de aplicaciones y estrategia de migración Diseñar y documentar el estado futuro de su aplicación es un factor clave para el éxito de la migración. Recomendamos crear un diseño para cualquier tipo de estrategia de migración, por simple o compleja que sea. La creación del diseño revelará posibles obstáculos, dependencias y oportunidades para optimizar la aplicación, incluso en los casos en que no se espera que la arquitectura cambie. También recomendamos abordar el estado futuro de la aplicación desde una perspectiva de estrategia de migración. AWS En esta etapa, asegúrese de definir el aspecto que tendrá la aplicación AWS como resultado de esta migración. El diseño resultante servirá de base para una evolución posterior a la migración. La siguiente lista contiene recursos para facilitar el proceso de diseño: + [AWS Architecture Center](https://aws.amazon.com/architecture/) combina herramientas y orientación, como el AWS Well-Architected Framework. Además, proporciona arquitecturas de referencia que puede usar para su aplicación. + [La Amazon Builders' Library](https://aws.amazon.com/builders-library/) contiene varios recursos sobre cómo Amazon crea y opera el software. + [AWS La biblioteca de soluciones](https://aws.amazon.com/solutions/) ofrece una colección de soluciones basadas en la nube, examinadas por expertos AWS, para decenas de problemas técnicos y empresariales. Incluye una amplia colección de arquitecturas de referencia. + AWS La [guía prescriptiva](https://aws.amazon.com/prescriptive-guidance/) proporciona estrategias, guías y patrones que ayudan al proceso de diseño y a las mejores prácticas de migración. + [AWS Documentation](https://docs.aws.amazon.com/)contiene información sobre AWS los servicios, incluidas las guías de usuario y las referencias de las API. + El [centro de recursos para empezar](https://aws.amazon.com/getting-started/) ofrece varios tutoriales prácticos e inmersiones profundas para aprender los aspectos básicos y empezar a desarrollar. AWS Según en qué punto de la transición a la nube se encuentre, es posible que ya existan AWS las bases. Entre estos AWS fundamentos se incluyen los siguientes: + Regiones de AWS han sido identificados. + Se han creado cuentas o se pueden obtener a pedido. + Se ha implementado una red general. + Se han desplegado AWS servicios fundamentales en las cuentas. Por el contrario, es posible que se encuentre en una fase temprana del proceso y que AWS las bases aún no estén establecidas. La falta de bases establecidas podría limitar el alcance del diseño de la aplicación o requerir más trabajo para definirlas. Si este es el caso, recomendamos definir e implementar el diseño fundamental de la landing zone en paralelo con el trabajo de diseño de la aplicación. El diseño de la aplicación ayuda a identificar requisitos como la Cuenta de AWS estructura, las redes, la nube privada virtual (VPCs), los rangos de enrutamiento entre dominios sin clases (CIDR), los servicios compartidos, la seguridad y las operaciones en la nube. [AWS Control Tower](https://aws.amazon.com/controltower/)proporciona la forma más sencilla de configurar y gobernar un AWS entorno seguro con múltiples cuentas, denominado landing zone. AWS Control Tower crea tu landing zone utilizando AWS Organizations, que proporciona una gestión y un gobierno continuos de las cuentas y la implementación de una experiencia basada en las AWS mejores prácticas trabajando con miles de clientes a medida que se trasladan a la nube. ## Estado futuro de la aplicación Comience por establecer la estrategia de migración inicial para esta aplicación. En este punto, la estrategia se considera inicial porque podría cambiar como parte del diseño del futuro estado, lo que puede revelar posibles limitaciones. Para validar las suposiciones iniciales, consulte el [árbol de decisiones de las 6](prioritization-and-migration-strategy.md#migration-r-type) R. Además, documente las posibles fases de migración. Por ejemplo, ¿se migrará esta aplicación en un solo evento (todos los componentes se migrarán al mismo tiempo)? ¿O se trata de una migración gradual (algunos componentes se migran más adelante)? Tenga en cuenta que las estrategias de migración para una aplicación determinada pueden no ser únicas. Esto se debe a que se pueden usar varios tipos de R para migrar los componentes de la aplicación. Por ejemplo, el enfoque inicial podría consistir en levantar y desplazar la aplicación sin cambios. Sin embargo, los componentes de una aplicación pueden residir en diferentes activos de infraestructura que podrían requerir diversos tratamientos. Por ejemplo, una aplicación se compone de tres componentes, cada uno de los cuales se ejecuta en un servidor independiente, y uno de los servidores ejecuta un sistema operativo heredado que no es compatible con la nube. Ese componente requerirá un enfoque de replataforma, mientras que los otros dos componentes, que se ejecutan en las versiones de servidor compatibles, se pueden realojar. Es fundamental asignar una estrategia de migración a cada componente de la aplicación y a la infraestructura asociada que se vaya a migrar. A continuación, documente el contexto y el problema, y vincule los artefactos existentes que definen el estado actual: + ¿Por qué se migra esta aplicación? + ¿Cuáles son los cambios propuestos? + ¿Cuáles son las ventajas? + ¿Existen riesgos o bloqueantes importantes? + ¿Cuáles son las desventajas actuales? + ¿Qué está dentro y fuera del alcance? ## Repetibilidad A lo largo del trabajo de diseño, considere cómo esta solución y la arquitectura de esta aplicación se pueden reutilizar para otras aplicaciones. ¿Se puede generalizar esta solución? ## Requisitos Documente los requisitos funcionales y no funcionales de esta aplicación, incluida la seguridad. Esto incluye los requisitos estatales actuales y futuros, según la estrategia de migración elegida. Utilice la información recopilada durante la evaluación detallada de la solicitud para guiar este proceso. ## Futura arquitectura Describa la arquitectura futura de esta aplicación. Considere la posibilidad de crear una plantilla de diagrama reutilizable que contenga los componentes básicos del entorno de origen (local) y el AWS entorno de destino (por ejemplo, el entorno de destino Región de AWS, la cuenta y las zonas de disponibilidad). VPCs Cree una tabla de los componentes que se van a migrar y los componentes que serán nuevos. Incluya otras aplicaciones y servicios (locales o en la nube) que interactúen con esta aplicación. En la siguiente tabla se muestran ejemplos de componentes. No representa una arquitectura de referencia ni una configuración aprobada. | **Nombre** | **Descripción** | **Detalles** | | --- |--- |--- | | Aplicación | Servicio externo (conexión entrante) | El servicio consume datos de la API expuesta. | | DNS | Resolución de nombres (interna) | Amazon Route 53 se implementó como parte de la configuración básica de la cuenta | | Equilibrador de carga de aplicación | Distribuye el tráfico entre los servicios de backend | Sustituye al balanceador de cargas local. Migre el grupo A. | | Seguridad de las aplicaciones | Protección contra DDoS | Implementado mediante el uso AWS Shield | | Security group (Grupo de seguridad) | Firewall virtual | Limite el acceso a las instancias de la aplicación en el puerto 443 (entrante). | | Servidor A | Interfaz | Realoje mediante Amazon Elastic Compute Cloud (Amazon EC2). | | Servidor B | Interfaz | Realoje mediante Amazon EC2. | | Servidor C | Lógica de la aplicación | Realoje mediante Amazon EC2. | | Servidor D | Lógica de la aplicación | Realoje mediante Amazon EC2. | | Amazon Relational Database Service (Amazon RDS) — Amazon Aurora | Base de datos | Sustituye a los servidores E y F | | Monitorización y alertas | Control de cambios | Amazon CloudWatch | | Registro de auditoría | Control de cambios | AWS CloudTrail | | Parcheo y acceso remoto | Mantenimiento | AWS Systems Manager | | Acceso a recursos | Control de acceso seguro | AWS Identity and Access Management (IAM) | | Autenticación | Acceso de usuario | Amazon Cognito | | Certificados | SSL/TLS | AWS Certificate Manager | | API 1 | API externa | Amazon API Gateway | | Almacenamiento de objetos | Alojamiento de imágenes | Amazon Simple Storage Service (Amazon S3) | | Credenciales | Gestión y alojamiento de credenciales | AWS Secrets Manager | | AWS Lambda función | Recuperación de las credenciales de la base de datos y las claves de API | AWS Lambda | | Puerta de enlace de Internet | Acceso saliente a Internet | Puerta de enlace de Internet a una VPC | | Subred privada 1 | Backend y base de datos | Zona de disponibilidad 1: VPC 1 | | Subred privada 2 | Backend y base de datos | Zona de disponibilidad 2: VPC 1 | | Subred pública 1 | Front-end | Zona de disponibilidad 1: VPC 1 | | Subred pública 2 | Front-end | Zona de disponibilidad 2: VPC 1 | | Servicios de Backup | Respaldo de bases de datos e instancias EC2 | AWS Backup | | DR | Resiliencia de Amazon EC2 | AWS Elastic Disaster Recovery | Una vez identificados los componentes, grafíquelos en un diagrama con la herramienta que prefiera. Comparta el diseño inicial con las principales partes interesadas en la aplicación, incluidos los propietarios de las aplicaciones, los arquitectos empresariales y los equipos de plataformas y migración. Considere la posibilidad de hacer las siguientes preguntas: + ¿El equipo está de acuerdo en general con el diseño? + ¿Los equipos de operaciones pueden apoyarlo? + ¿Se puede evolucionar el diseño? + ¿Hay otras opciones? + ¿El diseño cumple con las normas arquitectónicas y las políticas de seguridad? + ¿Falta algún componente (por ejemplo, repositorios de código, CI/CD herramientas, puntos finales de VPC)? ## Decisiones arquitectónicas Como parte del proceso de diseño, es probable que encuentre más opciones para la arquitectura general o para partes específicas de la misma. Documente estas opciones junto con la justificación de la opción preferida o seleccionada. Estas decisiones se pueden documentar como decisiones arquitectónicas. Asegúrese de que las opciones principales estén enumeradas y descritas con suficiente detalle para que un nuevo lector comprenda las opciones y los motivos de la decisión de utilizar una opción en lugar de otra. ## Entornos del ciclo de vida Documente cualquier cambio en los entornos actuales. Por ejemplo, los entornos de prueba y desarrollo se recrearán AWS y no se migrarán. ## Etiquetado Describa el etiquetado obligatorio y recomendado para cada componente de la infraestructura, así como el valor de etiquetado para este diseño. ## Estrategia de migración En este punto del diseño, deben validarse las suposiciones iniciales sobre la estrategia de migración. Confirme que existe consenso sobre la estrategia R elegida. Documente la estrategia general de migración de aplicaciones y las estrategias para los componentes individuales de la aplicación. Como se mencionó anteriormente, los diferentes componentes de la aplicación pueden requerir diferentes tipos de R para la migración. Además, alinee la estrategia de migración con los principales impulsores y resultados empresariales. Además, describa cualquier enfoque gradual de la migración, como el movimiento de componentes en diferentes eventos de migración. Para obtener más información sobre cómo determinar las 6 R, consulta las [recomendaciones de AWS Migration Hub estrategia](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Patrones y herramientas de migración Con una estrategia de migración definida para los componentes de la aplicación y la infraestructura, ahora puede explorar patrones técnicos específicos. Por ejemplo, se puede implementar una estrategia de realojamiento mediante herramientas de migración como. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Si no necesita replicar el estado o los datos, puede lograr el mismo resultado si vuelve a implementar la aplicación mediante una Amazon Machine Image (AMI) y una canalización de implementación de aplicaciones. Del mismo modo, para cambiar la plataforma o refactorizar (rediseñar) una aplicación, puede utilizar herramientas como [AWS App2Container](https://aws.amazon.com/app2container/), [AWS Database Migration Service (AWS DMS), ()](https://aws.amazon.com/dms/),. [AWS Schema Conversion ToolAWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)](https://aws.amazon.com/dms/schema-conversion-tool/) Para el almacenamiento en contenedores, puede utilizar [Amazon Elastic Container Service (Amazon ECS), Amazon](https://aws.amazon.com/ecs/) [Elastic Kubernetes Service (Amazon](https://aws.amazon.com/eks/) EKS) o. [AWS Fargate](https://aws.amazon.com/fargate/) Al volver a comprar, puede utilizar una AMI para un producto específico o una solución de software como servicio (SaaS) de. [AWS Marketplace](https://aws.amazon.com/marketplace/) Evalúe los diferentes patrones y opciones disponibles para lograr el objetivo. Tenga en cuenta los pros y los contras, así como la preparación operativa para la migración. Para facilitar el análisis, utilice las siguientes preguntas: + ¿Los equipos de migración pueden respaldar estos patrones? + ¿Cuál es el equilibrio entre costes y beneficios? + ¿Se puede mover esta aplicación, servicio o componente a un servicio gestionado? + ¿Cuál es el esfuerzo por implementar este patrón? + ¿Existe alguna normativa o política de cumplimiento que impida el uso de un patrón específico? + ¿Se puede reutilizar este patrón? Se prefieren los patrones reutilizables. Sin embargo, a veces un patrón se usará solo una vez. Considere el equilibrio entre el esfuerzo de un patrón de un solo uso y el de un patrón alternativo reutilizable. AWS La [guía prescriptiva](https://aws.amazon.com/prescriptive-guidance/) contiene una variedad de patrones y técnicas de migración. ## Gestión y operaciones del servicio Al crear diseños de aplicaciones para la migración AWS, tenga en cuenta la preparación operativa. Al evaluar los requisitos de preparación con sus equipos de aplicaciones e infraestructura, tenga en cuenta las siguientes preguntas: + ¿Están preparados para operarlo? + ¿Están definidos los procedimientos de respuesta a incidentes? + ¿Qué es el acuerdo de nivel de servicio (SLA) esperado? + ¿Se requiere la separación de funciones? + ¿Están preparados los diferentes equipos para coordinar las acciones de apoyo? + ¿Quién es responsable de qué? ## Consideraciones sobre la transición Teniendo en cuenta la estrategia y los patrones de migración, ¿qué es importante saber al momento de migrar la aplicación? La planificación de la transición es una actividad posterior al diseño. Sin embargo, documente cualquier consideración sobre las actividades y los requisitos que se puedan anticipar. Por ejemplo, documente el requisito de realizar una prueba de concepto, si corresponde, y describa los requisitos de prueba, auditoría o validación. ## Riesgos, suposiciones, problemas y dependencias Documente todos los riesgos, suposiciones y posibles problemas pendientes que aún no se hayan resuelto. Asigne una responsabilidad clara a estos elementos y realice un seguimiento del progreso para poder aprobar el diseño y la estrategia generales para su implementación. Además, documente las dependencias clave para implementar este diseño. ## Estimación del costo de ejecución Para estimar el costo de la AWS arquitectura objetivo, utilice la [calculadora de AWS precios](https://calculator.aws/). Añada los componentes de su infraestructura según lo definido en su diseño y obtenga un costo de ejecución estimado. Tenga en cuenta las licencias de software que se requieren para los componentes de la aplicación y que aún no están incluidas en los AWS servicios que utilizará.