Mejores prácticas para desarrollar e implementar una infraestructura de nube con AWS CDK

Esta es la guía para AWS CDK desarrolladores de la versión 2. La primera versión del CDK pasó a la etapa de mantenimiento el 1.° de junio de 2022 y no cuenta con soporte desde el 1.° de junio de 2023.

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.

Esta es la guía para AWS CDK desarrolladores de la versión 2. La primera versión del CDK pasó a la etapa de mantenimiento el 1.° de junio de 2022 y no cuenta con soporte desde el 1.° de junio de 2023.

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.

Con él AWS CDK, los desarrolladores o administradores pueden definir su infraestructura de nube mediante un lenguaje de programación compatible. Las aplicaciones de CDK deben organizarse en unidades lógicas, como la API, la base de datos y los recursos de supervisión y, opcionalmente, tener una canalización para las implementaciones automatizadas. Las unidades lógicas deben implementarse como constructos que incluyan lo siguiente:

Las pilas definen el modelo de implementación de estas unidades lógicas. Para obtener una introducción más detallada a los conceptos que hay detrás de CDK, consulte Empezando con la AWS CDK.

Esto AWS CDK refleja una consideración cuidadosa de las necesidades de nuestros clientes y equipos internos y de los patrones de falla que suelen surgir durante el despliegue y el mantenimiento continuo de aplicaciones complejas en la nube. Descubrimos que los fallos suelen estar relacionados con «out-of-band» cambios en una aplicación que no se han probado completamente, como los cambios de configuración. Por lo tanto, lo desarrollamos en AWS CDK torno a un modelo en el que toda la aplicación se define en código, no solo la lógica empresarial, sino también la infraestructura y la configuración. De esta forma, los cambios propuestos pueden revisarse detenidamente, probarse de manera exhaustiva en entornos que se asemejen en mayor o menor medida a los de producción y revertirse por completo si algo sale mal.

En el momento de la implementación, AWS CDK sintetiza un ensamblaje de nube que contiene lo siguiente:

Con CDK, cada confirmación realizada en la rama principal del control de versiones de la aplicación puede representar una versión completa, coherente e implementable de la aplicación. De este modo, la aplicación se puede implementar automáticamente cada vez que se realice un cambio.

La filosofía en la que se basa nos AWS CDK lleva a nuestras mejores prácticas recomendadas, que hemos dividido en cuatro amplias categorías.

Prácticas recomendadas de organizaciones

En las etapas iniciales de AWS CDK la adopción, es importante considerar cómo configurar su organización para el éxito. Se recomienda contar con un equipo de expertos que se encargue de entrenar y guiar al resto de la empresa a medida que adopta CDK. El tamaño de este equipo puede variar, desde una o dos personas en una empresa pequeña hasta un centro de excelencia (CCoE) en la nube completo en una empresa más grande. Este equipo es responsable de establecer estándares y políticas para la infraestructura en la nube de su empresa, y también de entrenar y guiar a los desarrolladores.

La CCo E podría proporcionar orientación sobre qué lenguajes de programación deberían usarse para la infraestructura de nube. Los detalles varían de una organización a otra, pero una buena política permite garantizar que los desarrolladores entienden y pueden mantener la infraestructura en la nube de la empresa.

La CCo E también crea una «landing zone» que define tus unidades organizativas en su interior AWS. Una landing zone es un AWS entorno multicuenta preconfigurado, seguro, escalable y basado en planes de mejores prácticas. Para unir los servicios que componen su zona de aterrizaje, puede usar AWS Control Tower, que configura y administra todo su sistema multicuentas desde una única interfaz de usuario.

Los equipos de desarrollo deberían poder usar sus propias cuentas para realizar pruebas e implementar nuevos recursos en estas cuentas según sea necesario. Los desarrolladores individuales pueden utilizar estos recursos como extensiones de su propia estación de trabajo de desarrollo. Con CDK Pipelines, AWS CDK las aplicaciones se pueden implementar a través de una cuenta de CI/CD en entornos de prueba, integración y producción (cada uno aislado en su AWS propia región o cuenta). Para ello, se fusiona el código de los desarrolladores en el repositorio canónico de la organización.

Prácticas recomendadas de codificación

En esta sección se presentan las prácticas recomendadas para organizar el código. AWS CDK El siguiente diagrama muestra la relación entre un equipo y los repositorios de código, los paquetes, las aplicaciones y las bibliotecas de constructos de ese equipo.

Comience de forma sencilla y agregue complejidad solo cuando la necesite

El principal propósito de la mayoría de las prácticas recomendadas es simplificar al máximo las cosas, pero no demasiado. Agregue complejidad solo cuando sus requisitos exijan una solución más complicada. Con él AWS CDK, puede refactorizar el código según sea necesario para adaptarlo a los nuevos requisitos. No es necesario que diseñe por adelantado todos los escenarios posibles.

Alinéese con el marco de AWS Well-Architected

El AWS Well-Architected Framework define un componente como el código, la configuración AWS y los recursos que, en conjunto, cumplen con un requisito. El componente suele ser la unidad de responsabilidad técnica y está desacoplado de otros componentes. El término carga de trabajo se usa para identificar un grupo de componentes que, en conjunto, proporcionan valor de negocio. La carga de trabajo suele ser el nivel de detalle sobre el que hablan los líderes tecnológicos y comerciales.

Una AWS CDK aplicación se asigna a un componente según lo definido por el AWS Well-Architected Framework. AWS CDK las aplicaciones son un mecanismo para codificar y ofrecer las mejores prácticas de aplicaciones en la nube de Well-Architected. También puede crear y compartir componentes como bibliotecas de códigos reutilizables a través de repositorios de artefactos, como AWS CodeArtifact.

Cada aplicación comienza con un único paquete en un único repositorio

Un único paquete es el punto de entrada de su aplicación. AWS CDK Aquí, usted define cómo y dónde implementar las diferentes unidades lógicas de su aplicación. También define la canalización de CI/CD para implementar la aplicación. Los constructos de la aplicación definen las unidades lógicas de la solución.

Utilice paquetes adicionales para los constructos que utilice en más de una aplicación. (Los constructos compartidos también deben tener su propio ciclo de vida y estrategia de pruebas). Las dependencias entre los paquetes del mismo repositorio se administran mediante las herramientas de compilación de su repositorio.

Si bien es posible, no recomendamos colocar varias aplicaciones en el mismo repositorio, en especial cuando se utilizan canalizaciones de implementación automatizadas. De este modo, se aumenta el “radio de impacto” de los cambios durante la implementación. Cuando hay varias aplicaciones en un repositorio, los cambios en una aplicación provocan la implementación de las demás (aunque las otras no hayan cambiado). Además, una interrupción en una aplicación impide que se implementen las demás.

Mueva el código a los repositorios en función del ciclo de vida del código o de la propiedad del equipo

Cuando los paquetes comiencen a usarse en varias aplicaciones, muévalos a su propio repositorio. De esta forma, las cargas de trabajo de las aplicaciones que los utilizan pueden hacer referencia a los paquetes, y también se pueden actualizar en cadencias independientes de los ciclos de vida de las aplicaciones. Sin embargo, al principio podría tener sentido colocar todos los constructos compartidos en un repositorio.

Además, mueva los paquetes a su propio repositorio cuando diferentes equipos estén trabajando en ellos. Esto ayuda a aplicar el control de acceso.

Para consumir paquetes más allá de los límites del repositorio, necesitas un repositorio de paquetes privado, similar a NPM o Maven Central PyPi, pero interno en tu organización. También necesitas un proceso de publicación que compile, pruebe y publique el paquete en el repositorio de paquetes privado. CodeArtifactpuede alojar paquetes para los lenguajes de programación más populares.

Las dependencias de los paquetes del repositorio de paquetes las gestiona el administrador de paquetes de su idioma, como NPM for TypeScript or JavaScript applications. Su administrador de paquetes garantiza que las compilaciones sean repetibles. Para ello, graba las versiones específicas de cada paquete del que depende su aplicación. También le permite actualizar esas dependencias de manera controlada.

Los paquetes compartidos necesitan una estrategia de pruebas diferente. En el caso de una sola aplicación, podría bastar con implementarla en un entorno de pruebas y confirmar que continúa funcionando. Pero los paquetes compartidos deben probarse por separado de la aplicación que los utilice, como si se estuvieran lanzando al público. (Es posible que su organización decida lanzar al público algunos paquetes compartidos).

Tenga en cuenta que un constructo puede ser arbitrariamente simple o complejo. Un Bucket es un constructo, pero también CameraShopWebsite podría ser uno.

Encuentre su infraestructura y código de tiempo de ejecución en el mismo paquete

Además de generar AWS CloudFormation plantillas para implementar la infraestructura, AWS CDK también incluye activos de tiempo de ejecución, como funciones Lambda e imágenes de Docker, y los implementa junto con su infraestructura. Esto hace posible combinar el código que define la infraestructura y el código que implementa la lógica de tiempo de ejecución en un solo constructo. Hacer esto es una práctica recomendada. No es necesario que estos dos tipos de código se encuentren en repositorios separados o incluso en paquetes separados.

Para desarrollar los dos tipos de código juntos, puede utilizar un constructo independiente que describa por completo una parte de la funcionalidad, incluidas su infraestructura y lógica. Con un constructo independiente, puede probar los dos tipos de código de forma aislada, compartir y reutilizar el código en todos los proyectos y versionar todo el código de forma sincronizada.

Prácticas recomendadas para constructos

Esta sección contiene las prácticas recomendadas para desarrollar constructos. Los constructos son módulos reutilizables y compatibles con la composición que encapsulan los recursos. Son los componentes básicos de las aplicaciones. AWS CDK

Modelado con constructos e implementación con pilas

Las pilas son la unidad de implementación: todos los elementos de una pila se implementan juntos. Por lo tanto, cuando cree las unidades lógicas de nivel superior de su aplicación a partir de varios AWS recursos, represente cada unidad lógica como un Construct, no como un Stack. Utilice las pilas únicamente para describir cómo deben componerse y conectarse los constructos en los distintos escenarios de implementación.

Por ejemplo, si una de sus unidades lógicas es un sitio web, los constructos que lo integran (como un bucket de Amazon S3, la API Gateway, las funciones de Lambda o las tablas de Amazon RDS) deben estar compuestas en un único constructo de alto nivel. Luego, ese constructo se instancia en una o más pilas para su implementación.

Al utilizar constructos para la compilación y pilas para la implementación, mejora el potencial de reutilización de su infraestructura y obtiene más flexibilidad a la hora de implementarla.

Configure con propiedades y métodos, no con variables de entorno

Las búsquedas de variables de entorno dentro de los constructos y las pilas son un antipatrón común. Tanto los constructos como las pilas deben aceptar un objeto de propiedades para permitir una configurabilidad completa en el código. De lo contrario, se crea una dependencia de la máquina en la que se ejecutará el código, lo que crea aún más información de configuración a la que hay que hacerle seguimiento y administrar.

En general, las búsquedas de variables de entorno deben limitarse al nivel superior de una aplicación. AWS CDK También deberían usarse para transmitir la información necesaria para ejecutarse en un entorno de desarrollo. Para obtener más información, consulte Entornos para AWS CDK.

Pruebas unitarias de su infraestructura

Para ejecutar de forma coherente un conjunto completo de pruebas unitarias en el momento de la compilación en todos los entornos, evite las búsquedas en la red durante la síntesis y modele todas las etapas de producción en código. (Estas prácticas recomendadas se describen más adelante). Si una sola confirmación siempre da como resultado la misma plantilla generada, puede confiar en las pruebas unitarias que escriba para confirmar que las plantillas generadas tienen el aspecto esperado. Para obtener más información, consulte AWS CDK Aplicaciones de prueba.

No cambie el ID lógico de los recursos con estado

Si se cambia el ID lógico de un recurso, se sustituirá por uno nuevo en la siguiente implementación. Esto no suele necesitarse para los recursos con estado, como las bases de datos y los buckets de S3, ni para la infraestructura persistente, como un Amazon VPC. Ten cuidado con cualquier refactorización del AWS CDK código que pueda provocar un cambio en el ID. Escribe pruebas unitarias que confirmen que la lógica IDs de tus recursos con estado permanece estática. El ID lógico deriva del id especificado al crear el constructo y de la posición de este en el árbol de constructos. Para obtener más información, consulte Lógico IDs.

Los constructos no son suficientes para garantizar la conformidad

Muchos clientes empresariales escriben sus propios contenedores para las construcciones de nivel 2 (las construcciones «seleccionadas» que representan AWS recursos individuales con prácticas recomendadas y predeterminadas integradas). Estos contenedores aplican las prácticas recomendadas de seguridad, como el cifrado estático y las políticas de IAM específicas. Por ejemplo, puede crear una MyCompanyBucket que luego utilice en sus aplicaciones en lugar del constructo habitual de Bucket de Amazon S3. Este patrón es útil para ofrecer directrices de seguridad al principio del ciclo de vida de desarrollo del software, pero no debe basarse en él como único medio de aplicación.

En su lugar, utilice AWS funciones como las políticas de control de servicios y los límites de permisos para reforzar las barreras de seguridad a nivel de la organización. Utilice Aspectos y AWS CDK herramientas como CloudFormation Guard para hacer afirmaciones sobre las propiedades de seguridad de los elementos de la infraestructura antes del despliegue. Úselo AWS CDK para lo que mejor sabe hacer.

Por último, tenga en cuenta que escribir sus propias construcciones «L2+» puede impedir que sus desarrolladores aprovechen AWS CDK paquetes como AWS Solutions Constructs o construcciones de terceros de Construct Hub. Por lo general, estos paquetes se basan en constructos AWS CDK estándar y no podrá usar los de su contenedor.

Prácticas recomendadas de la aplicación

En esta sección, analizamos cómo escribir sus AWS CDK aplicaciones, combinando construcciones para definir cómo se conectan sus recursos. AWS

Tome decisiones en el momento de la síntesis

Si bien AWS CloudFormation le permite tomar decisiones en el momento de la implementación (utilizando Conditions{ Fn::If }, yParameters) y AWS CDK le da cierto acceso a estos mecanismos, le recomendamos que no los utilice. Los tipos de valores que puede utilizar y los tipos de operaciones que puede realizar con ellos son limitados en comparación con lo que está disponible en el lenguaje de programación de uso general.

En su lugar, intente tomar todas las decisiones, como qué construcción crear una instancia, en su AWS CDK aplicación utilizando las if instrucciones del lenguaje de programación y otras funciones. Por ejemplo, una expresión común de CDK, que repite una lista y crea instancias de una construcción con valores de cada elemento de la lista, simplemente no es posible utilizar expresiones. AWS CloudFormation

AWS CloudFormation Tómatelo como un detalle de implementación que se AWS CDK utiliza para despliegues sólidos en la nube, no como un objetivo lingüístico. No estás escribiendo AWS CloudFormation plantillas en TypeScript Python, estás escribiendo código CDK que resulta que se usa CloudFormation para la implementación.

Utilice nombres de recursos generados en lugar de nombres físicos

Los nombres son un recurso valioso. Cada nombre solo se puede usar una vez. Por lo tanto, si codifica el nombre de una tabla o de un bucket en su infraestructura y aplicación, no podrá implementar esa parte de la infraestructura dos veces en la misma cuenta. (El nombre del que hablamos aquí es el nombre especificado, por ejemplo, por la propiedad del bucketName de un constructo de bucket de Amazon S3).

Y lo que es peor, no puede realizar cambios en el recurso que necesiten su sustitución. Si una propiedad solo se puede establecer en el momento de la creación del recurso, como KeySchema de una tabla de Amazon DynamoDB, entonces esa propiedad es inmutable. Se requiere un nuevo recurso para cambiar esta propiedad. Sin embargo, el nuevo recurso debe tener el mismo nombre para que sea una verdadera sustitución. No obstante, no puede tener el mismo nombre mientras el recurso existente siga usando ese nombre.

Lo mejor es especificar la menor cantidad de nombres posible. Si omites los nombres de los recursos, se los AWS CDK generarán automáticamente sin problemas. Supongamos que tiene una tabla como recurso. A continuación, puede pasar el nombre de la tabla generada como una variable de entorno a su AWS Lambda función. En su AWS CDK aplicación, puede hacer referencia al nombre de la tabla comotable.tableName. Como alternativa, puedes generar un archivo de configuración en tu EC2 instancia de Amazon al iniciarla o escribir el nombre real de la tabla en el almacén de AWS Systems Manager parámetros para que la aplicación pueda leerlo desde allí.

Si el lugar donde lo necesitas es en otra AWS CDK pila, es aún más sencillo. Si suponemos que una pila define el recurso y otra pila necesita usarlo, se aplica lo siguiente:

Defina las políticas de eliminación y la retención de registro

AWS CDK Intenta evitar que pierdas datos mediante políticas que conservan todo lo que has creado de forma predeterminada. Por ejemplo, la política de eliminación predeterminada de los recursos que contienen datos (como los buckets de Amazon S3 y las tablas de bases de datos) consiste en no eliminar el recurso cuando se elimina de la pila. En su lugar, el recurso queda huérfano de la pila. Del mismo modo, el valor predeterminado de CDK es retener todos los registros para siempre. En los entornos de producción, estos valores predeterminados pueden resultar de inmediato en el almacenamiento de grandes cantidades de datos que en realidad no necesita y en la correspondiente factura de AWS .

Considere de manera minuciosa qué políticas quiere para cada recurso de producción y especifíquelas según corresponda. Use Aspectos y AWS CDK para validar las políticas de eliminación y registro de su pila.

Separe la aplicación en varias pilas según lo exijan los requisitos de implementación

No existe una regla estricta sobre la cantidad de pilas que necesita su aplicación. Por lo general, terminará tomando la decisión en función de sus patrones de implementación. Tenga en cuenta lo siguiente:

Confirme cdk.context.json para evitar un comportamiento no determinista

El determinismo es clave para el éxito AWS CDK de las implementaciones. Básicamente, una AWS CDK aplicación debería tener el mismo resultado siempre que se implemente en un entorno determinado.

Como tu AWS CDK aplicación está escrita en un lenguaje de programación de uso general, puede ejecutar código arbitrario, usar bibliotecas arbitrarias y realizar llamadas de red arbitrarias. Por ejemplo, puedes usar un AWS SDK para recuperar cierta información de tu AWS cuenta mientras sintetizas tu aplicación. Si lo hace, tenga en cuenta que tendrá que configurar las credenciales con requisitos adicionales, aumentará la latencia y habrá una posibilidad, por más pequeña que sea, de que se produzca un error cada vez que ejecute cdk synth.

Nunca modifiques tu AWS cuenta ni tus recursos durante la síntesis. Sintetizar una aplicación no debería tener efectos secundarios. Los cambios en la infraestructura solo deberían producirse en la fase de implementación, una vez que se haya generado la AWS CloudFormation plantilla. De esta forma, si hay algún problema, se AWS CloudFormation puede revertir automáticamente el cambio. Para realizar cambios que no se puedan realizar fácilmente dentro del AWS CDK marco, usa recursos personalizados para ejecutar código arbitrario en el momento de la implementación.

Incluso las llamadas de solo lectura estrictas no son siempre seguras. Tenga en cuenta lo que ocurre si cambia el valor devuelto por una llamada de red. ¿Qué parte de su infraestructura se verá afectará por eso? ¿Qué pasará con los recursos ya implementados? Estos son dos ejemplos de situaciones en las que un cambio repentino en los valores podría provocar un problema.

Estas situaciones pueden ser perniciosas, ya que el cambio AWS radical puede producirse tras meses o años de implementaciones satisfactorias. De repente, sus implementaciones están fallando “sin motivo alguno” y hace tiempo que olvidó lo que hizo y por qué.

Afortunadamente, AWS CDK incluye un mecanismo denominado proveedores de contexto para registrar una instantánea de valores no deterministas. Esto permite que las futuras operaciones de síntesis produzcan exactamente la misma plantilla que cuando se implementaron por primera vez. Los únicos cambios en la nueva plantilla son aquellos que usted realizó en el código. Cuando utiliza el método .fromLookup() de un constructo, el resultado de la llamada se almacena en caché en cdk.context.json. Para asegurarse de que en las futuras ejecuciones de su aplicación CDK se utilice el mismo valor, debería confirmarlo con el control de versiones junto con el resto del código. El kit de herramientas CDK incluye comandos para administrar el caché de contexto, de modo que pueda actualizar entradas específicas cuando lo necesite. Para obtener más información, consulte Los valores de contexto y el AWS CDK.

Si necesita algún valor (de AWS o de otro lugar) para el que no haya un proveedor de contexto de CDK nativo, le recomendamos que escriba un script independiente. El script debe recuperar el valor y escribirlo en un archivo, y, luego, leerlo en la aplicación CDK. Ejecute el script solo cuando desee actualizar el valor almacenado, no como parte de su proceso de compilación habitual.

Deje que AWS CDK administren las funciones y los grupos de seguridad

Con los grant() prácticos métodos de la biblioteca de construcción de CDK de AWS, puede crear AWS Identity and Access Management roles que concedan acceso a un recurso a otro mediante permisos con un alcance mínimo. Por ejemplo, considere la siguiente línea:

amzn-s3-demo-bucket.grantRead(myLambda)

Esta línea única agrega una política al rol de la función de Lambda (que también se crea para usted). Ese rol y sus políticas son más de una docena de líneas CloudFormation que no tiene que escribir. Solo AWS CDK concede los permisos mínimos necesarios para que la función lea el contenido del bucket.

Si se requiere que los desarrolladores utilicen siempre funciones predefinidas creadas por un equipo de seguridad, la AWS CDK codificación se vuelve mucho más complicada. Sus equipos podrían perder mucha flexibilidad a la hora de diseñar sus aplicaciones. Una mejor alternativa es utilizar políticas de control de servicios y límites de permisos para garantizar que los desarrolladores se mantengan dentro de las barreras de protección.

Modele todas las etapas de producción en código

En AWS CloudFormation los escenarios tradicionales, el objetivo es producir un único artefacto parametrizado para que pueda implementarse en varios entornos de destino después de aplicar los valores de configuración específicos para esos entornos. En el CDK, puede y debe crear esa configuración en su código fuente. Cree una pila para su entorno de producción y una pila independiente para cada una de las demás etapas. A continuación, coloque los valores de configuración de cada pila en el código. Utilice servicios como Secrets Manager y Systems Manager Parameter Store para valores confidenciales que no desee registrar en el control de código fuente, utilizando los nombres o ARNs de esos recursos.

Al sintetizar la aplicación, el conjunto de nube creado en la carpeta cdk.out contiene una plantilla independiente para cada entorno. Toda la compilación es determinista. No hay out-of-band cambios en la aplicación y cualquier confirmación determinada siempre arroja exactamente la misma AWS CloudFormation plantilla y los recursos correspondientes. Esto hace que las pruebas unitarias sean mucho más fiables.

Mida todo

Lograr el objetivo de una implementación continua y completa, sin intervención humana, requiere un nivel de automatización alto. Esa automatización solo es posible con una supervisión exhaustiva. Para medir todos los aspectos de los recursos implementados, cree métricas, alarmas y paneles de control. No se limite a medir aspectos como el uso de la CPU y el espacio en el disco. Registre también las métricas de su empresa y utilícelas para automatizar las decisiones de implementación, como las reversiones. La mayoría de las construcciones de nivel 2 incluyen métodos AWS CDK prácticos que ayudan a crear métricas, como el metricUserErrors() método de la clase DynamoDB.Table.