Opciones de recuperación de desastres en la nube

Las estrategias de recuperación de desastres disponibles en AWS se pueden clasificar en términos generales en cuatro enfoques, que van desde un bajo coste y una complejidad menor al hacer copias de seguridad hasta estrategias más complejas que utilizan varias regiones activas. Es fundamental que pruebe de forma regular la estrategia de recuperación de desastres para que pueda aplicarla sin reparos, en caso de que sea necesario.

Ilustración 6: Estrategias de recuperación de desastres

En el caso de un desastre debido a la interrupción o pérdida de un centro de datos físico de una carga de trabajo de alta disponibilidad y buena arquitectura, es posible que solo necesite un enfoque de copia de seguridad y restauración para la recuperación de desastres. Si su definición de desastre va más allá de la interrupción o la pérdida de un centro de datos físico, es decir, más allá de una región o si está sujeto a requisitos regulatorios que lo exigen, debe considerar las opciones luz piloto, espera semiactiva y activa/activa en varios sitios.

Copia de seguridad y restauración

La copia de seguridad y la restauración son un enfoque adecuado para mitigar la pérdida o la corrupción de datos. Este enfoque también se puede utilizar para mitigar un desastre regional mediante la replicación de datos en otras regiones de AWS o para mitigar la falta de redundancia de las cargas de trabajo implementadas en una sola zona de disponibilidad. Además de los datos, debe volver a implementar la infraestructura, la configuración y el código de la aplicación en la región de recuperación. Para permitir que la infraestructura se vuelva a implementar rápidamente sin errores, debe implementar siempre con la infraestructura como código (IaC) mediante servicios como AWS CloudFormation o el AWS Cloud Development Kit (AWS CDK). Sin IaC, puede resultar complejo restaurar las cargas de trabajo en la región de recuperación, lo que aumentará el tiempo de recuperación y posiblemente superará el RTO. Además de los datos del usuario, asegúrese de realizar también una copia de seguridad del código y de la configuración, incluidas las imágenes de máquina de Amazon (AMI) que utiliza para crear instancias de Amazon EC2. Puede utilizar AWS CodePipeline para automatizar la reimplementación del código y la configuración de la aplicación.

Ilustración 7: Arquitectura de copia de seguridad y restauración

Servicios de AWS

Los datos de la carga de trabajo requerirán una estrategia de copia de seguridad que se ejecute periódicamente o que sea continua. La frecuencia con la que ejecute la copia de seguridad determinará el punto de recuperación alcanzable (que debe alinearse para cumplir con su RPO). La copia de seguridad también debería ofrecer una forma de restaurarla al momento dado en el que se realizó. La copia de seguridad con recuperación a un momento dado está disponible a través de los siguientes servicios y recursos:

• Instantánea de Amazon Elastic Block Store (Amazon EBS)

• Copia de seguridad de Amazon DynamoDB

• Instantánea de Amazon RDS

• Instantánea de base de datos de Amazon Aurora

• Copia de seguridad de Amazon EFS (cuando se usa AWS Backup)

• Instantánea de Amazon Redshift

• Instantánea de Amazon Neptune

Para Amazon Simple Storage Service (Amazon S3), puede utilizar la replicación entre diferentes regiones (CRR) de Amazon S3 para copiar objetos de forma asíncrona en un bucket de S3 en la región de recuperación de desastres de forma continua, a la vez que proporciona el control de versiones de los objetos almacenados para que pueda elegir su punto de restauración. La ventaja de la replicación continua de datos es que las copias de seguridad de los datos son prácticamente inmediatas, pero es posible que no proteja contra desastres, como la corrupción o ataques maliciosos a los datos (por ejemplo, la eliminación no autorizada de datos), así como las copias de seguridad puntuales. La replicación continua se trata en la sección Luz piloto en los servicios de AWS.

AWS Backup proporciona una ubicación centralizada para configurar, programar y supervisar las capacidades de copia de seguridad de AWS para los siguientes servicios y recursos:

• Volúmenes de Amazon Elastic Block Store (Amazon EBS)

• Instancias de Amazon EC2

• Bases de datos de Amazon Relational Database Service (Amazon RDS) (incluidas las bases de datos de Amazon Aurora)

• Tablas de Amazon DynamoDB

• Sistemas de archivos de Amazon Elastic File System (Amazon EFS)

• Volúmenes de AWS Storage Gateway

• Amazon FSx for Windows File Server y Amazon FSx for Lustre

AWS Backup permite realizar copias de seguridad en todas las regiones, como, por ejemplo, en una región de recuperación de desastres.

Como estrategia de recuperación de desastres adicional para sus datos de Amazon S3, se recomienda que active el control de versiones de objetos de S3. El control de versiones de objetos protege sus datos en S3 de las consecuencias de las acciones de eliminación o modificación pues conserva la versión original anterior a la acción. El control de versiones de objetos puede ser una mitigación útil ante desastres provocados por errores humanos. Si utiliza la replicación de S3 para realizar copias de seguridad de los datos en su región de recuperación de desastres, entonces, de forma predeterminada, cuando se elimina un objeto en el bucket de origen, Amazon S3 añade un marcador de eliminación solamente en el bucket de origen. Este enfoque protege los datos de la región de recuperación de desastres de eliminaciones maliciosas en la región de origen.

Además de los datos, también debe realizar una copia de seguridad de la configuración y la infraestructura necesarias para volver a implementar su carga de trabajo y cumplir con su objetivo de tiempo de recuperación (RTO). AWS CloudFormation proporciona infraestructura como código (IaC) y le permite definir todos los recursos de AWS en su carga de trabajo para que pueda implementar y volver a implementar de manera fiable en varias cuentas y regiones de AWS. Puede realizar copias de seguridad de las instancias de Amazon EC2 utilizadas por su carga de trabajo como imágenes de máquina de Amazon (AMI). La AMI se crea a partir de instantáneas del volumen raíz de la instancia y de cualquier otro volumen de EBS adjunto a la instancia. Puede usar esta AMI para lanzar una versión restaurada de la instancia de EC2. Una AMI se puede copiar dentro de las regiones o entre ellas. O bien, puede usar AWS Backup para copiar copias de seguridad en cuentas y en otras regiones de AWS. La capacidad de copia de seguridad entre cuentas ayuda a protegerse de los desastres, como las amenazas internas o la vulnerabilidad de las cuentas. AWS Backup también agrega capacidades adicionales para la copia de seguridad de EC2; además de los volúmenes de EBS individuales de la instancia, AWS Backup también almacena y rastrea los siguientes metadatos: tipo de instancia, nube privada virtual (VPC) configurada, grupo de seguridad, rol de IAM, configuración de supervisión y etiquetas. Sin embargo, estos metadatos adicionales solo se utilizan para restaurar la copia de seguridad de EC2 en la misma región de AWS.

Todos los datos almacenados en la región de recuperación de desastres en forma de copias de seguridad deben restaurarse en el momento de la conmutación por error. AWS Backup ofrece capacidad de restauración, pero actualmente no permite programar ni automatizar la restauración. Puede implementar la restauración automática en la región de recuperación de desastres mediante el SDK de AWS para llamar a las API AWS Backup. Puede configurarla como un trabajo recurrente o desencadenar la restauración cada vez que se complete una copia de seguridad. En la siguiente figura se muestra un ejemplo de restauración automática con Amazon Simple Notification Service (Amazon SNS) y AWS Lambda.

Ilustración 8: Restauración y pruebas de copias de seguridad

nota

Su estrategia de copia de seguridad debe incluir probar las copias de seguridad. Consulte la sección Probar la recuperación de desastres para obtener más información. Consulte el laboratorio AWS Well-Architected Lab: Testing Backup and Restore of Data para obtener una demostración práctica sobre las pruebas de copia de seguridad y restauración.

Luz piloto

Con el enfoque de luz piloto se replican los datos de una región a otra y se almacena una copia de la infraestructura de carga de trabajo principal. Los recursos necesarios para poder replicar y hacer una copia de seguridad de los datos, como las bases de datos y el almacenamiento de objetos, siempre están disponibles. Otros elementos, como los servidores de aplicaciones, se cargan con código de aplicación y configuraciones, pero se apagan y solo se usan durante las pruebas o cuando se invoca la conmutación por error de recuperación de desastres. A diferencia del enfoque de copia de seguridad y restauración, la infraestructura principal siempre está disponible y siempre tiene la opción de aprovisionar rápidamente un entorno de producción a gran escala al encender y escalar los servidores de aplicaciones horizontalmente.

Ilustración 9: Arquitectura de luz piloto

El enfoque de luz piloto minimiza el coste continuo de la recuperación de desastres pues minimiza los recursos activos y simplifica la recuperación en el momento de un desastre porque todos los requisitos de la infraestructura central están en su lugar. Esta opción de recuperación requiere cambiar el enfoque de la implementación. Debe realizar cambios en la infraestructura central en cada región e implementar cambios en la carga de trabajo (configuración, código) simultáneamente en cada región. Este paso se puede simplificar automatizando las implementaciones y utilizando la infraestructura como código (IaC) para implementar la infraestructura en varias cuentas y regiones (implementación completa de la infraestructura en la región principal e implementación de infraestructura reducida verticalmente/desconectada en regiones de recuperación de desastres). Se recomienda usar una cuenta diferente por región para proporcionar el nivel más alto de aislamiento de recursos y seguridad (en el caso de que las credenciales comprometidas también formen parte de los planes de recuperación de desastres).

Con este enfoque, también debe mitigar ante desastres relacionados con datos. La replicación continua de datos lo protege contra algunos tipos de desastres, pero es posible que no lo proteja contra la corrupción o la destrucción de datos, a menos que su estrategia también incluya el control de versiones de los datos almacenados u opciones para la recuperación a un momento dado. Puede hacer una copia de seguridad de los datos replicados en la región del desastre para crear copias de seguridad puntuales en esa misma región.

Servicios de AWS

Además de utilizar los servicios de AWS que se tratan en la sección Copia de seguridad y restauración para crear copias de seguridad puntuales, puede considerar también los siguientes servicios para la estrategia de luz piloto.

En esta estrategia, la replicación continua de datos en bases de datos en vivo y almacenes de datos en la región de recuperación de datos es el mejor enfoque para un RPO bajo (cuando se usa además de las copias de seguridad puntuales que hemos comentado anteriormente). AWS proporciona replicación de datos asíncrona, continua y entre regiones mediante los siguientes servicios y recursos:

• Replicación de Amazon Simple Storage Service (Amazon S3)

• Réplicas de lectura de Amazon RDS

• Amazon Aurora Global Databases

• Tablas globales de Amazon DynamoDB

Con la replicación continua, las versiones de sus datos están disponibles casi de inmediato en su región de recuperación de datos. Los tiempos de replicación reales se pueden supervisar mediante funciones de servicio como el control de tiempo de replicación de S3 (S3 RTC) para objetos de S3 y funciones de administración de Amazon Aurora Global Databases.

Si no logra ejecutar una carga de trabajo de lectura y escritura desde la región de recuperación de desastres, debe promover una réplica de lectura de RDS para que se convierta en la instancia principal. Para las instancias de base de datos distintas de Aurora, el proceso tarda unos minutos en completarse y el reinicio forma parte del proceso. Para la replicación entre regiones (CRR) y la conmutación por error en RDS, el uso de la Amazon Aurora Global Databases proporciona varias ventajas. La base de datos global utiliza una infraestructura dedicada que deja sus bases de datos totalmente disponibles para servir a la aplicación. Además, puede replicarse en la región secundaria con una latencia típica de menos de un segundo (y dentro de una región de AWS es mucho menos de 100 milisegundos). Con Amazon Aurora Global Databases, si su región principal sufre una degradación o interrupción del rendimiento, puede promover una de las regiones secundarias para que asuma responsabilidades de lectura y escritura en menos de 1 minuto, incluso en el caso de una interrupción regional completa. La promoción puede ser automática y no se reinicia.

Se debe implementar una versión reducida verticalmente de la infraestructura de carga de trabajo principal con menos recursos o recursos más pequeños en su región de recuperación de desastres. AWS CloudFormation le permite definir la infraestructura e implementarla de manera coherente en las cuentas de AWS y en las regiones de AWS. AWS CloudFormation utiliza pseudoparámetros predefinidos para identificar la cuenta de AWS y la región de AWS en la que se implementa. Por lo tanto, puede implementar la lógica de condición en sus plantillas de CloudFormation para implementar solo la versión reducida verticalmente de su infraestructura en la región de recuperación de desastres. Para las implementaciones de instancias de EC2, una imagen de máquina de Amazon (AMI) proporciona información de la configuración del hardware y del software instalado. Puede implementar una canalización de Image Builder que cree las AMI que necesita y copiarlas tanto en su región principal como en la de copia de seguridad. Esto ayuda a garantizar que estas AMI doradas tengan todo lo que necesita para volver a implementar o escalar horizontalmente su carga de trabajo en una nueva región, en caso de desastre. Las instancias de Amazon EC2 se implementan en una configuración reducida verticalmente (menos instancias que en la región principal). Puede hibernar para detener las instancias de EC2, lo que significa que no paga gastos de EC2, solo paga por el almacenamiento utilizado. Para iniciar instancias de EC2, puede crear scripts mediante la interfaz de línea de comandos (CLI) o el SDK de AWS. Para escalar horizontalmente la infraestructura para admitir el tráfico de producción, consulte AWS Auto Scaling la sección Espera semiactiva.

Para una configuración activa/en espera, como luz piloto, todo el tráfico va inicialmente a la región principal y cambia a la región de recuperación de desastres si la región principal ya no está disponible. Al utilizar los servicios de AWS hay que tener en cuenta dos opciones de administración del tráfico. La primera opción es usar Amazon Route 53. Con Amazon Route 53, puede asociar varios puntos de conexión de IP en una o más regiones de AWS con un nombre de dominio de Route 53. A continuación, puede dirigir el tráfico al punto de conexión apropiado de ese nombre de dominio. Las comprobaciones de estado de Amazon Route 53 supervisan estos puntos de conexión. Estas comprobaciones de estado le permiten configurar la conmutación por error de DNS para garantizar que el tráfico se envíe a puntos de conexión en buen estado.

La segunda opción es usar AWS Global Accelerator. Con AnyCast IP, puede asociar varios puntos de conexión a una o más regiones de AWS con las mismas direcciones IP estáticas. A continuación, AWS Global Accelerator dirige el tráfico al punto de conexión apropiado asociado a esa dirección. Las comprobaciones de estado de Global Accelerator supervisan los puntos de conexión. En función de estas comprobaciones de estado, AWS Global Accelerator comprueba automáticamente el estado de las aplicaciones y dirige el tráfico de los usuarios a un solo punto de conexión de la aplicación en buen estado. Global Accelerator ofrece latencias más bajas en el punto de conexión de la aplicación, ya que utiliza la extensa red de borde de AWS para colocar el tráfico en la red troncal de AWS lo antes posible. Global Accelerator también evita los problemas de almacenamiento en caché que pueden darse con los sistemas DNS (como Route 53).

CloudEndure Disaster Recovery

CloudEndure Disaster Recovery, disponible enAWS Marketplace, replica continuamente las aplicaciones alojadas en el servidor y las bases de datos alojadas en el servidor desde cualquier fuente en AWS mediante la replicación en el nivel de bloques del servidor subyacente. CloudEndure Disaster Recovery permite utilizar la nube de AWS como región de recuperación de desastres para una carga de trabajo local y su entorno. También se puede utilizar para la recuperación de desastres de cargas de trabajo alojadas en AWS si solo consisten en aplicaciones y bases de datos alojadas en EC2 (es decir, no en RDS). CloudEndure Disaster Recovery utiliza la estrategia de luz piloto, que conserva una copia de los datos y los recursos apagados en una Amazon Virtual Private Cloud (Amazon VPC) que se utiliza como área de almacenamiento provisional. Cuando se desencadena un evento de conmutación por error, los recursos por etapas se utilizan para crear automáticamente una implementación de capacidad completa en la Amazon VPC de destino que es la ubicación de recuperación.

Ilustración 10: Arquitectura de CloudEndure Disaster Recovery

Espera semiactiva

El enfoque de espera semiactiva implica garantizar que haya una reducción vertical, pero totalmente funcional, del entorno de producción en otra región. Este enfoque amplía el concepto de luz piloto y reduce el tiempo de recuperación porque la carga de trabajo siempre está activa en otra región. Este enfoque también permite realizar pruebas más fácilmente o implementar pruebas continuas para aumentar la confianza en la capacidad para recuperarse de un desastre.

Ilustración 11: Arquitectura de espera semiactiva

Nota: La diferencia entre la estrategia de luz piloto y deespera semiactiva a veces puede resultar difícil de entender. Ambas incluyen un entorno en su región de recuperación de desastres con copias de los activos principales de su región. La diferencia es que la estrategia de luz piloto no puede procesar solicitudes sin que se tomen medidas adicionales primero, mientras que la espera semiactiva puede gestionar el tráfico de inmediato (en niveles de capacidad reducidos). El enfoque de luz piloto requiere que encienda los servidores, posiblemente implementando una infraestructura adicional (no central) y escalando verticalmente, mientras que el enfoque de espera semiactiva solo requiere que se escale verticalmente (todo ya está implementado y en ejecución). Piense en sus necesidades de RTO y RPO a la hora de elegir entre estos enfoques.

Servicios de AWS

Todos los servicios de AWS cubiertos por copia de seguridad y restauración y luz piloto también se utilizan en la espera semiactiva para la copia de seguridad de datos, la replicación de datos, el enrutamiento de tráfico activo/en espera y la implementación de infraestructura, incluidas las instancias de EC2.

AWS Auto Scaling se utiliza para escalar recursos, incluidas las instancias de Amazon EC2, las tareas de Amazon ECS, el rendimiento de Amazon DynamoDB y las réplicas de Amazon Aurora en una región de AWS. Amazon EC2 Auto Scaling escala la implementación de la instancia de EC2 en las zonas de disponibilidad dentro de una región de AWS, lo que proporciona resiliencia en esa región. Utilice Auto Scaling para escalar horizontalmente su región de recuperación de desastres hasta una capacidad de producción completa, como parte de las estrategias de luz piloto o espera semiactiva. Por ejemplo, para EC2, debe aumentar la configuración de capacidad deseada en el grupo de Auto Scaling. Puede ajustar esta configuración manualmente a través de AWS Management Console, automáticamente a través del SDK de AWS o mediante la reimplementación de la plantilla de AWS CloudFormation con el nuevo valor de capacidad deseado. Puede utilizar los parámetros de AWS CloudFormation para facilitar la reimplementación de la plantilla de CloudFormation. Asegúrese de que las Service Quotas de su región de recuperación de desastres sean lo suficientemente altas como para no limitar el escalado vertical hacia la capacidad de producción.

Activa/activa en varios sitios

Puede ejecutar la carga de trabajo simultáneamente en varias regiones como parte de una estrategia activa/activa en varios sitios o espera activa/pasiva. La estrategia activa/activa en varios sirve el tráfico desde todas las regiones en las que se implementa, mientras que la estrategia de espera activa solo sirve el tráfico de una sola región. Las demás regiones solo se utilizan para la recuperación de desastres. Con una estrategia activa/activa en varios sitios, los usuarios pueden acceder a la carga de trabajo en cualquiera de las regiones en las que se implemente. Este enfoque es el más complejo y caro para la recuperación de desastres, pero puede reducir el tiempo de recuperación a casi cero en la mayoría de desastres con las opciones de tecnología e implementación correctas (sin embargo, la corrupción de datos puede necesitar depender de copias de seguridad, lo que generalmente resulta en un punto de recuperación distinto de cero). El modo de espera activa utiliza una configuración activa/pasiva en la que los usuarios se dirigen a una sola región y las regiones de recuperación de desastres no aceptan el tráfico. La mayoría de los clientes considera que si van a tener un entorno completo en la segunda región, tiene sentido usar el modo activo/activo. Alternativamente, si no desea utilizar ambas regiones para gestionar el tráfico de usuarios, la opción de espera semiactiva es más económica y menos compleja desde el punto de vista operativo.

Ilustración 12: Arquitectura activa/activa en varios sitios (cambie una ruta activa por inactiva para el modo de espera activa)

En la estrategia activa/activa en varios sitios, dado que la carga de trabajo se ejecuta en más de una región, no existe la conmutación por error. En este caso, las pruebas de recuperación de desastres se centrarían en cómo reacciona la carga de trabajo ante la pérdida de una región: ¿el tráfico se dirige fuera de la región que ha fallado? ¿Las otras regiones pueden gestionar todo el tráfico? También deben realizarse pruebas para detectar un desastre de datos. La copia de seguridad y la recuperación siguen siendo necesarias y deben probarse con regularidad. También se debe tener en cuenta que los tiempos de recuperación de un desastre de datos que implique corrupción, eliminación u ofuscación de datos siempre serán mayores que cero y el punto de recuperación siempre estará en algún momento antes de que se descubriera el desastre. Si se requiere la complejidad y el coste adicionales de una estrategia activa/activa en varios sitios (o espera activa) para mantener tiempos de recuperación casi iguales a cero, entonces se deben realizar esfuerzos adicionales para mantener la seguridad y evitar errores humanos para mitigar los desastres humanos.

Servicios de AWS

Todos los servicios de AWS cubiertos en copia de seguridad y restauración, luz piloto y espera semiactiva también se utilizan aquí para copias de seguridad de datos de un período de tiempo concreto, replicación de datos, enrutamiento de tráfico activo/activo e implementación y escalado de infraestructura, incluidas las instancias de EC2.

Para los escenarios activos/pasivos analizados anteriormente (luz piloto y espera activa), tanto Amazon Route 53 como AWS Global Accelerator se pueden usar para dirigir el tráfico de red hacia la región activa. Para la estrategia activa/activa aquí, ambos servicios también permiten la definición de políticas que determinen qué usuarios van a qué punto de conexión regional activo. AWS Global Accelerator le permite establecer una señalización del tráfico para controlar el porcentaje de tráfico que se dirige a cada punto de conexión de la aplicación. Amazon Route 53 admite este enfoque porcentual y también muchas otras políticas disponibles, incluidas las basadas en geoproximidad y latencia. Global Accelerator aprovecha automáticamente la extensa red de servidores de borde de AWS para incorporar el tráfico a la red troncal de AWS lo antes posible, lo que reduce la latencia de las solicitudes.

La replicación de datos con esta estrategia permite un RPO casi igual a cero. Los servicios de AWS, así como Amazon Aurora Global Databases, usan una infraestructura dedicada que deja sus bases de datos completamente disponibles para servir a la aplicación, y puede replicarse en una región secundaria con una latencia típica de menos de un segundo. Con las estrategias activa/pasiva, las escrituras se producen solo en la región principal. La diferencia con activa/activa es la forma en que se diseña la gestión de las escrituras en cada región activa. En general, las lecturas de los usuarios se diseñan para que se les sirva desde la región más cercana, lo que se conoce como lectura local. Con las escrituras, existen varias opciones:

• Una estrategia de escritura global dirige todas las escrituras a una sola región. En caso de que falle la región, se promovería a otra región para que acepte escrituras. La base de datos global de Aurora es adecuada para la escritura global, ya que admite la sincronización con réplicas de lectura en todas las regiones, y puede promover una de las regiones secundarias para que asuma responsabilidades de lectura y escritura en menos de 1 minuto.

• Una estrategia de escritura local dirige las escrituras a la región más cercana (de igual modo que las lecturas). Las tablas globales de Amazon DynamoDB admiten una estrategia de este tipo, lo que permite la lectura y escritura desde todas las regiones en las que se implemente la tabla global. Las tablas globales de Amazon DynamoDB usan una reconciliación del tipo prevalece el último escritor entre las actualizaciones simultáneas.

• Una estrategia de partición de escritura asigna escrituras a una región específica en función de una clave de partición (como el ID de usuario) para evitar conflictos de escritura. En este caso se puede utilizar la replicación de Amazon S3 configurada bidireccionalmente. Actualmente admite la replicación entre dos regiones. Al implementar este enfoque, asegúrese de habilitar la sincronización de modificación de réplicas en los buckets A y B para replicar los cambios de metadatos de réplica, como las listas de control de acceso a objetos (ACL), las etiquetas de objetos o los bloqueos de objetos en los objetos replicados. También puede configurar si desea o no replicar marcadores de eliminación entre buckets en sus regiones activas. Además de la replicación, su estrategia también debe incluir copias de seguridad en un momento dado para proteger contra eventos de corrupción o destrucción de datos.

AWS CloudFormation es una poderosa herramienta que permite aplicar una infraestructura implementada de manera consistente en las cuentas de AWS en varias regiones de AWS. AWS CloudFormation StackSets amplía esta funcionalidad al permitirle crear, actualizar o eliminar pilas de CloudFormation en varias cuentas y regiones con una sola operación. Aunque AWS CloudFormation utiliza YAML o JSON para definir la infraestructura como código, AWS Cloud Development Kit (AWS CDK) le permite definir la infraestructura como código utilizando lenguajes de programación familiares. El código se convierte en CloudFormation, que luego se utiliza para implementar recursos en AWS.